It's now possible to do:
SCAN fleet WHERE "properties.speed < 25 || properties.speed > 50"
Uses javascript-like syntax using the https://github.com/tidwall/expr package.
Automatically reference fields and GeoJSON properties:
SET fleet truck1 FIELD speed 65 POINT -112 33
Can be queried:
SCAN fleet WHERE "speed > 50"
SCAN fleet WHERE "id == 'truck1'"
SCAN fleet WHERE "speed > 50 && id == 'truck1'"
This commit allows for performing WHERE on the object's GeoJSON
properties member.
For example:
SET fleet truck1 OBJECT '{"type":"Feature","geometry":{"type":"Point","coordinates":[-112,33]},"properties":{"speed":50}}'
You can now do:
SCAN fleet WHERE properties.speed > 50
Prior to this commit all objects in the Collection data structures
were boxed in an Go interface{} which adds an extra 8 bytes per
object and requires assertion to unbox.
Go 1.18, released early 2022, introduced generics, which allows
for storing the objects without boxing. This provides a extra
boost in performance and lower in-memory footprint.
This commit updates to the latest btree and rtree.
The rtree algorithm has been modified in `tidwall/rtree@v1.7`
which now keeps internal and leaf rect sorted by the min-x
coordinate. This make for much faster (up to 50%) faster
searches and replacements, but slightly slower inserts.
Because of the R-tree update, the tests needed to be updated to
account for the change in order for undeterministic WITHIN and
INTERSECTS commands.
?ssl=true previously would require the user to provide a cacertfile
stripping the option to use the hosts ca set.
bumping sarama to version 1.36.0
bumping alpine to 3.16.2
fix: tls path
This commit changes the logic for managing the expiration of
objects in the database.
Before: There was a server-wide hashmap that stored the
collection key, id, and expiration timestamp for all objects
that had a TTL. The hashmap was occasionally probed at 20
random positions, looking for objects that have expired. Those
expired objects were immediately deleted, and if there was 5
or more objects deleted, then the probe happened again, with
no delay. If the number of objects was less than 5 then the
there was a 1/10th of a second delay before the next probe.
Now: Rather than a server-wide hashmap, each collection has
its own ordered priority queue that stores objects with TTLs.
Rather than probing, there is a background routine that
executes every 1/10th of a second, which pops the expired
objects from the collection queues, and deletes them.
The collection/queue method is a more stable approach than
the hashmap/probing method. With probing, we can run into
major cache misses for some cases where there is wide
TTL duration, such as in the hours or days. This may cause
the system to occasionally fall behind, leaving should-be
expired objects in memory. Using a queue, there is no
cache misses, all objects that should be expired will be
right away, regardless of the TTL durations.
Fixes#616
tidwall