Tile38
s2geometry
Tile38 | s2geometry | |
---|---|---|
9 | 26 | |
8,902 | 2,185 | |
- | 1.1% | |
7.0 | 5.8 | |
13 days ago | about 6 hours ago | |
Go | C++ | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Tile38
-
Show HN: TG – Fast geometry library in C
[2] https://github.com/tidwall/tile38
-
PostgreSQL: No More Vacuum, No More Bloat
Experimental format to help readability of a long rant:
1.
According to the OP, there's a "terrifying tale of VACUUM in PostgreSQL," dating back to "a historical artifact that traces its roots back to the Berkeley Postgres project." (1986?)
2.
Maybe the whole idea of "use X, it has been battle-tested for [TIME], is robust, all the bugs have been and keep being fixed," etc., should not really be that attractive or realistic for at least a large subset of projects.
3.
In the case of Postgres, on top of piles of "historic code" and cruft, there's the fact that each user of Postgres installs and runs a huge software artifact with hundreds or even thousands of features and dependencies, of which every particular user may only use a tiny subset.
4.
In Kleppmann's DDOA [1], after explaining why the declarative SQL language is "better," he writes: "in databases, declarative query languages like SQL turned out to be much better than imperative query APIs." I find this footnote to the paragraph a bit ironic: "IMS and CODASYL both used imperative query APIs. Applications typically used COBOL code to iterate over records in the database, one record at a time." So, SQL was better than CODASYL and COBOL in a number of ways... big surprise?
Postgres' own PL/pgSQL [2] is a language that (I imagine) most people would rather NOT use: hence a bunch of alternatives, including PL/v8, on its own a huge mass of additional complexity. SQL is definitely "COBOLESQUE" itself.
5.
Could we come up with something more minimal than SQL and looking less like COBOL? (Hopefully also getting rid of ORMs in the process). Also, I have found inspiring to see some people creating databases for themselves. Perhaps not a bad idea for small applications? For instance, I found BuntDB [3], which the developer seems to be using to run his own business [4]. Also, HYTRADBOI? :-) [5].
6.
A usual objection to use anything other than a stablished relational DB is "creating a database is too difficult for the average programmer." How about debugging PostgreSQL issues, developing new storage engines for it, or even building expertise on how to set up the instances properly and keep it alive and performant? Is that easier?
I personally feel more capable of implementing a small, well-tested, problem-specific, small implementation of a B-Tree than learning how to develop Postgres extensions, become an expert in its configuration and internals, or debug its many issues.
Another common opinion is "SQL is easy to use for non-programmers." But every person that knows SQL had to learn it somehow. I'm 100% confident that anyone able to learn SQL should be able to learn a simple, domain-specific, programming language designed for querying DBs. And how many of these people that are not able to program imperatively would be able to read a SQL EXPLAIN output and fix deficient queries? If they can, that supports even more the idea that they should be able to learn something different than SQL.
----
1: https://dataintensive.net/
2: https://www.postgresql.org/docs/7.3/plpgsql-examples.html
3: https://github.com/tidwall/buntdb
4: https://tile38.com/
5: https://www.hytradboi.com/
-
Your Data Fits in RAM
I actually worked on a project that did this. We used a database called "Tile38" [1] which used an R-Tree to make geospatial queries speedy. It was pretty good.
Our dataset was ~150 GiB, I think? All in RAM. Took a while to start the server, as it all came off disk. Could have been faster. (It borrowed Redis's query language, and its storage was just "store the commands the recreate the DB, literally", IIRC. Dead simple, but a lot of slack/wasted space there.)
Overall not a bad database. Latency serving out of RAM was, as one should/would expect, very speedy!
[1]: https://tile38.com/
-
Redcon - Redis compatible server framework for Rust
I ported it from Go and use it for my Tile38 project.
- Tile38 - a geolocation data store, spatial index, and realtime geofence
- Path hints for B-trees can bring a performance increase of 150% – 300%
- How do I implement push notifications on a 10 mile radius from a certain user?
s2geometry
-
Hexagons and Hilbert Curves – The Horrors of Distributed Spatial Indices
I experimented with geospatial Hilbert Curves as a Postgres extension [0] for PostGIS using the S2 [1] spherical geometry library. S2 uses a scale free cell coverage pattern that is numbered using six interlocking space filling Hilbert Curves [2].
By having both high level (cell) and low level (cell id) geometries it was a very powerful library which allowed projection from the hilbert space into a Postgres spatial index (spgist) including various trees, like noted in this article. It appears to be still quite active in development.
[0] https://github.com/michelp/pgs2
[1] https://s2geometry.io/
[2] https://s2geometry.io/devguide/s2cell_hierarchy
- Show HN: TG – Fast geometry library in C
- Unum: Vector Search engine in a single file
-
Understanding Geohashes
If you check the h3geo comparison page, you should see plenty of alternatives to geohash, such as s2 or even h3 itself.
- Evaluation of Location Encoding Systems
-
Inscribed angle theorem in 3D/higher dimension
See some discussion I started at https://github.com/google/s2geometry/issues/190
-
An Interactive Explanation of Quadtrees
> It was quite hard for me to find open-source implementations of linear quadtrees.
You probably know this, but the S2 library has one: https://github.com/google/s2geometry
-
Why doesn’t my pokèstop show up?
https://s2geometry.io shows how this works
-
Needing advice to improve geodesic calculation time
If your points are distributed globally, however, I'd suggest using something like s2geometry (calculates over a sphere instead of an ellipsoid which is much faster + already has something called S2ClosestPointQuery).
-
What is the best data structure for this problem?
Some alternative solutions are S2 from Google and H3 from Uber. These don't have the same issues as geohash because they work on a 3-d model of the geoid and not a 2-d cylindrical projection like Geohash.
What are some alternatives?
vitess - Vitess is a database clustering system for horizontal scaling of MySQL.
h3 - Hexagonal hierarchical geospatial indexing system
go-mysql-elasticsearch - Sync MySQL data into elasticsearch
S2 geometry - S2 geometry library in Go
ledisdb - A high performance NoSQL Database Server powered by Go
0.30000000000000004 - Floating Point Math Examples
goleveldb - LevelDB key/value database in Go.
s2 - Node.js JavaScript / TypeScript bindings for Google S2
groupcache - groupcache is a caching and cache-filling library, intended as a replacement for memcached in many cases.
Kyrix - Interactive details-on-demand data visualizations at scale
kingshard - A high-performance MySQL proxy
sled - the champagne of beta embedded databases