Hi Dragon —
There was a question recently about using Aerospike for IP ranges. It’s over here:
Storing each IP address as a 32-bit number is practical in Aerospike, as that is only 4B keys thus the indexes would be only 256G of memory if fully populated — which is won’t be. An optimization of storing information by Class C yields only 4M keys, which requires only 0.25G of RAM. You can then use columns - Aerospike Bins - to store information on the entire class C, or individual IP addresses. As Aerospike uses a sparse representation, if you have only a few addresses in a class C, this is quite efficient. If you are doing a lot of reads, each read is a single KV lookup, touches a minimal number of servers, is extraordinarily parallel, and performs very well.
An alternate pattern is to think of the problem in a more relational way. If your geo information is supplied as a “network” (with a unique name and a range), you can insert a row per network, use the integer form of the IP address in a column, index that column, and look up using range queries — just like you would do in a relational or SQL system (but it’ll be parallel and distributed).
These general patterns are discussed in that other forum topic.
In either case, I suggest you use GeoJSON for the actual geo data — we’ll be adding support for GeoJSON, so you’ll be able to “reverse index” in a future release — ie, create an index on that column, and find IP addresses associated with a location — if you’re interested in that kind of feature. While this feature isn’t imminent, it is “soon”.