3 ms·

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

47 points by tidwall 11y ago

officialchicken 11y ago
Previous discussion 11 days ago: https://news.ycombinator.com/item?id=11227662 https://news.ycombinator.com/item?id=11227662
- tidwall 11y ago
  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.
  - officialchicken 11y ago
    I will check it out, thanks for the update... good docs aren't easy.
gopalv 11y ago
Is this a single node solution? I might still have per-city sharding for most bogey-in-motion, but would that be practical?
- tidwall 11y ago
  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.
eropple 11y ago
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.
- tidwall 11y ago
  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.
  - eropple 11y ago
    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.

47 points by tidwall 11y ago

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

tidwall 11y ago
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.
- officialchicken 11y ago
  I will check it out, thanks for the update... good docs aren't easy.

gopalv 11y ago

Is this a single node solution? I might still have per-city sharding for most bogey-in-motion, but would that be practical?

tidwall 11y ago
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.

eropple 11y ago

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.

tidwall 11y ago
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.
- eropple 11y ago
  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.