Hacker News Reader

Comment by kyleblarson | Hacker News Reader

Would love to know how this performs compared with analogous PostGIS operations on a similar sized set of geos.

It is a little bit apples and oranges. This is a simple point-in-plane index, PostGIS is a full-blown geospatial data modeling capability. PostGIS is going to be much slower but it is also doing much more as part of the process so that it is useful for sophisticated spatial applications. PostGIS is not fast relative to comparable systems but this particular comparison is not fair because PostGIS is expected to do so much more.

That said, I have also implemented large-scale point-in-plane indexing systems, though not in a while. Per CPU core, you can encode and index around 20M geo-points per second if the implementation is good.

We're using Redis Geo to track customers who are "online" so that we can easily retrieve a list of users who are online and in the area. The user's permanent location is stored in a SQL database for permanent storage.

How do you deal with locations close to boundaries? Isn't that still a problem with comparing geohashes for proximity?

This is handled by the Redis implementation (and most others AFAIK). So it returns the right items regardless of the query position or the items position. Redis has tests in place for this.

It's great to see you (jandrewrogers) of SpaceCurve reply to correctly to the question! Your blog post on why Geospatial Databases are Hard has long influenced me and a handful of others I've run into thinking about all of this.

Geohashed (X+Y) points in Redis is only peripherally related to actual geospatial database concerns, particularly big-data or ("NoSQL") spatial database concerns - how do you efficiently index anything other than point data (polygons, multi_polygons), or ask spatial queries (e.g., nearest neighbors) is not even close to being addressed.

Blog post here for reference: http://www.jandrewrogers.com/2015/03/02/geospatial-databases...

Reply on news.ycombinator.com