Tile38 is a geolocation data store, spatial index, and realtime geofence | Hacker News Reader

Tile38 is a geolocation data store, spatial index, and realtime geofence

tile38.com

47 pointstidwall8 comments

Previous discussion 11 days ago: https://news.ycombinator.com/item?id=11227662

Shoot. I think I did a no-no. I kept the same title as the previous discussion.

This new post is a link to an entirely new documentation website for the project, not just a Github link. People asked about robust docs for the project and I've been killing myself over the past week or so with it.

I was hoping that this new topic would be of interest to both technical and less technical people.

I will check it out, thanks for the update... good docs aren't easy.

This is really neat, but the high-availability story is concerning--it's the first thing I look at with new services, especially datastores. "Leader-follower" is very easy to implement, but quorum-based election has gotten super easy to deal with over the last couple years and is much better for redundancy, while--being optional--doesn't necessarily have to sacrifice single-node performance for trivial cases.

If it wasn't Go, which I don't enjoy writing, I might consider taking some time this weekend to do it myself, but I don't have a real need for a geolocation store right now and don't have enough interest to overcome having to use Go.

Thanks a ton for the kind words. I have a raft branch that I've been working on for a while, but the performance is not yet there.

Currently the replication model is a good place to start with basic redundancy. The scaling features are high on my priority list.

I'm glad to hear that - I can see some really useful applications for this, and I'll be watching it with interest. A transition step that might make the current replication model more generally useful might be to have a quorum tool (internal, delegating to Consul/ZK/whatever, etc.) just for leader election and use the existing leader/follower logic for that.

Is this a single node solution?

I might still have per-city sharding for most bogey-in-motion, but would that be practical?

I'm working on cluster enhancements with a raft quorum. This is still a work-in-progress but should be pretty cool when it's ready.

Reply on news.ycombinator.com