HN Explorer

Show HN: SliceUp - building the world's fastest time series database in Rust

8 points by jaupe ↗ HN
We want to share that we are ambitiously building the world's fastest time-series database... and we're using Rust! It's called SliceUp and it's already significantly faster than the current fastest - kdb (http://kx.com). We still have a lot more query optimizations and novel features that we want to add to make it even faster.

There's a small demo/tech intro video of our database on our website (http://www.sliceup.co) that shows some query examples and its speed compared to kdb.

Rust is the key ingredient to achieving our goal of being the fastest time-series database. The killer feature for us is Rust's algebraic data types that can express query syntax trees and pattern matching to analyse queries for optimisations - while still being a systems programming language to build such low-level software.

We would like to thank the Rust community for all the great packages and libraries that we've used.

Your feedback is welcomed. You can sign up to our private beta via our website if you're interested to have early access to our private beta.

2 comments

[ 1.9 ms ] story [ 17.0 ms ] thread
fatihky
Hi, would you share a benchmark for your database? Doing billion taxi benchmark is an option I think. Kdb's billion taxi benchmark[1] says that Kdb is the fastest among the databases that only work with cpu. You could also talk about Mark Litwintschik.

[1]: http://tech.marksblogg.com/billion-nyc-taxi-kdb.html

crzwdjk
Having tried to build a much simpler jankier version of the same thing, I agree that Rust is great for a) performance and b) making compilers for query languages. In particular, algebraic data types are great for representing syntax trees and matching is great for operating on them, with optimization represented as transformations from one tree to another. My compiler had a couple of two passes, one to parse the query into a parse tree and the other to do some type checking and name resolution. The execution engine operated on this second tree form, which was fast enough for my purposes.

I'm curious what your queries get compiled into and how you end up doing optimization on them: are they parse trees, or bytecode, or native code (is that what "JIT optimizations" refers to)?