The last significant features we shipped dealt with out-of-order data ingestion, and we focused our efforts on hitting the highest write-throughput that we could achieve for that release. Our latest feature highlight adds space as a new dimension that our database can manage and allows users to work with data sets that have spatial and time components.
We shipped an initial implementation with software release version 6.0.5, and we've updated our demo instance so anyone can test these features out. To help with running queries on this sort of data, we've included an example data set which simulates 250,000 moving objects, and we've provided examples in the SQL editor to demo common types of queries.
This blog post is mainly for people who work with geospatial data struggling with performance, are looking for new tooling, or need to track changes in geodata over time. This post should also be interesting for those who want to read about how we added geospatial support to our time series database from a technical perspective.
#What are geohashes?
Geohashes work by dividing the Earth into 32 separate grids, and each grid is assigned an alphanumeric character. We can increase the precision by sub-dividing each grid into 32 again and adding a new alphanumeric character. The result is a base32 alphanumeric string that we call a geohash, with greater precision obtained with longer-length strings.
To support geospatial data, we added a new
geohash type which would allow
special handling of geohashes. We'll take a look at the syntax we introduced in
the language additions section below, but
first, let's get an idea of what a geohash represents in terms of geographic
area, we can take a few examples and compare the resulting grid size:
|5,000km × 5,000km|
|156km × 156km|
|1.22km × 0.61km|
|37.2mm × 18.6mm|
To place geohashes on a map, we need to know the bounding coordinates of the corners of each grid. There's a very helpful script by Chris Veness that allows users to input latitude and longitude coordinates and maps the equivalent geohash. In this case, the precision of the returned geohash is based on the decimal places of the lat/long coordinates.
The inverse calculation from geohash to latitude and longitude follows a similar logic but instead requires creating a bounding box comprising four corners of the grid. To calculate the geohash bounding box and place it on a map, we can use a function similar to this example:
Once we have the coordinates in latitude and longitude, we can use standard mapping tools to visualize geohashes by creating bounding boxes like the following example, which uses plotly via Python:
#QuestDB geohash syntax and storage
The syntax we chose for column definitions follows the format
geohash(<precision>) where precision can be between one and twelve characters
or directly binary values. Precision is specified as
may be either
c for char or
b for bits (
c being shorthand for 5 x
For example, the geohash
u33d8b is represented by six characters, so we can
store this in a
We decided against using strings to represent geohash values as this is
inefficient for both storage and value comparison, so we chose to add geohash
literals. The literal syntax that we use has the format of a single
prefixing the geohash value for chars and two
## hashes for binary:
In terms of storage for geohash values internally, we use four different categories based on how much storage each geohash would require. We break geohashes down into the following types internally:
- Up to 7-bit geohashes are stored as 1
- 8-bit to 15-bit geohashes are stored in 2
- 16-bit to 31-bit geohashes are stored in 4
- 32-bit to 60-bit geohashes are stored in 8
There may be cases where you need the control over storage provided by binary
values but would prefer to work with character-formatted geohashes. We can do
this by including a suffix in the format
bits is the number of
bits from 1-60. This way, you can choose specific binary column precision for
storage, but the values passed around use char notation with lower precision:
#Optimizing for common usage patterns
Adding space as a dimension was one side of the problem, but we considered that many use cases would track moving objects, and common usage patterns would likely require more than optimized storage and ingestion only. Tracking moving objects, for instance, is a different problem than stationary entities with a fixed location (like a lookup table). We wanted to enable users to have performant query execution on the change of location of an entity over time. Optimizing these kinds of queries has two obvious solutions:
- perform a geohash lookup first, then search these results by time, or
- search the data by time range, then perform a geohash search within the results
We benchmarked these scenarios and chose a time-based search first, followed by geohash lookup for performance reasons, as we avoid scanning all non-indexed rows first. Because timestamp columns are already indexed, we leverage high-performance time-based search and filter the resulting (smaller) data sets. The most significant performance penalty that we incur is lifting data from the disk in the first place, so we try to avoid this.
#Functions and operators
We focused on internal optimizations for the
used in aggregate queries to make them execute faster. The optimization is
currently restricted to
SAMPLE BY queries, and the functions need to be called
on symbol types with an index. The result is that there is a faster execution
time when you would like to retrieve the first or last-known value for a given
symbol) within an aggregate bucket.
To illustrate why this is useful, one example on our demo instance uses
SAMPLE BY 15m to split the results into 15-minute aggregate buckets. When we
last(lat) function here, we avoid lifting all data from the disk for
lat column, but instead read the row ID based on the timestamp index and
instead pick the last value within our aggregate bucket:
In order to take a snapshot of moving objects within a certain area, we
within operator which evaluates if a comma-separated list of
geohashes is equal to or within another geohash. This operator works on
LATEST BY queries on indexed columns, the
device_id column in this snippet,
The implementation of
within was designed to be used with additional
time-based filtering, so that we can efficiently sample data sets in terms of
time and space. The query performance of slicing time and space in this way
should be fast enough to power real-time mapping tools which make use of UI
sliders to jog through slices of time:
We wanted high-performance prefix-based searches that can execute across
hundreds of thousands of unique values for this operator. To perform this in a
non-naive way, have a 'map-reduce' approach which splits keys into groups and
performs operations upon such groups in parallel. For
within, a task
processing queue slices a range of geohashes, and our worker pool performs
We use SIMD across most of our subsystems and use this method for any bulk data processing. The prefix matching illustrated above has vectorized equivalent so that we can perform this search operation massively in parallel:
One of the benefits of SIMD-based data processing is that we do not have to rely on external indexes. This follows our original ethos of not introducing additional data structures until absolutely necessary.
#What we learned
As we began working with geospatial data sets, we found that there tends to be a lot of data noise in specific scenarios. Specifically, we saw noisy data when objects send location updates but are not moving for a particular time. Our initial implementation does not solve this completely, but we are looking at ways to add mechanisms that discard similar entries within certain bounds to eliminate duplication of records.
When adding our test data set with 250k objects, we estimated the number of unique symbols that QuestDB could easily handle was 100k or less before encountering performance issues. The example data set we are currently using shows that we can store and query up to 250k unique symbol values or more.
Adding support for geospatial data was a great challenge for us, and we think we found novel approaches for the storage model and optimizations for common usage patterns that yielded surprisingly good performance results. We're happy to share our findings, and we're eagerly awaiting feedback on these features, which you can try directly on our live demo or via our latest releases.
If you have have feedback or questions about this article, feel free ask in our Slack Community or browse the project on GitHub where we welcome contributions of all kinds.