|forest 874028fcb5||1 month ago|
|benchmark||1 month ago|
|LICENSE.md||1 month ago|
|README.md||1 month ago|
|benchmarks.jpg||1 month ago|
|go.mod||1 month ago|
|go.sum||1 month ago|
|main.go||1 month ago|
|opengl_boilerplate.go||1 month ago|
This demo was based on Golang OpenGL tutorial by kylewbanks.com.
It's called "modular" because it doesn't have any indexing logic inside, you bring your own index. It simply defines a mapping from two-dimensional space (
[x,y] as integers) to 1-dimensional space (a single string of bytes for a point, or a handful of byte-ranges for a rectangle). You can use these strings of bytes (keys) and byte-ranges (query parameters) in any database to implement a spatial index.
Read amplification for range queries is ~2x-3x in terms of IOPS and bandwidth compared to a 1-dimensional query.
But that constant factor on top of your fast key/value database is a low price to pay for a whole new dimension, right? It's certainly better than the naive approach.
The benchmarks are part of this repository.
I benchmarked the spatial index against a tuned version of the "One range query for every row in the rectangle" approach I talk about in my blog post linked above, which I am calling the
Sliced index, with various slice sizes.
For a test dataset, I used goleveldb to store approximately 1 million keys, each with a 4-kilobyte random value. During the benchmarks, each database index was approximately 3.5GB in size, and the test application was consuming about 30MB of memory.