Hacker News Reader

Comment by jamesblonde | Hacker News Reader

In a soon-to-be published online feature store benchmark with batched read/writes, NDB (RonDB) had 40% higher throughput and 40% lower latency than Aerospike. Then, RonDB offers a SQL API - you can scale partition-pruned index scans linearly (they localize to a single shard). Obviously, index scans across the whole cluster don't scale so well, neither do full-table scans, but there are tricks to use them and make them scale for not-so-big-data (such as fully-replicated tables - replicated at all nodes in the cluster).

View on HN

One of the features I like about Aerospike is the user defined functions (UDF), which are Lua functions that run directly in the cluster. Compared to pulling the data to my servers and performing the computation, UDFs are much more efficient.

Does RonDB have a similar capability?

Aerospike Community Edition is limited to 5TB per cluster, and I wonder if RonDB has a similar limitation?

Last, how does one compute RAM allocation per machine for RonDB? I assume it varies depending on the number of indexes that are defined? I assume you do not hold all data in memory, and you can take advantage of SSD or NVMe disks?

I'm asking because we utilize Aerospike heavily, and RonDB seems like an interesting alternative.

RonDB have an interpreter that can execute a set of simple things. It is mostly used to push filtering, to push increments/decrements. There is also a pushdown join processor in it. It wouldn't be very hard to build more functionality into the interpreter. The interpreted programs is created by the NDB API and executed by the data owner. Thus the intermediate parts like transaction handler has no idea what it is passing along.

RonDB Community is GPL v2 and there is no limitations to its use. Our business model is to provide the managed service of operating RonDB and providing support for that.

Thanks for taking the time to answer. Is there a way I can contact you offline to discuss estimated pricing for a specific scenario?

info at logicalclocks dot com

Regarding memory a very quick formula (more details exists in docs.rondb.com and in blogs) is around 25 bytes of overhead per row plus 15 bytes of overhead per primary key index and an additional 10 bytes per row per ordered index. Non-indexed columns can be disk-based and thus use SSDs or NVMe drives or networked storage. This is decided when creating the table.

oh batched '__') that makes sense.. clickhouse also fast if batched, but not fast when stormed with lots of small requests

Yep, this is a key difference between traditional SQL databases and key-value databases. SQL databases optimise specific queries and have a high overhead per query. Key-value databases have a low overhead per query and optimise on flows of queries instead of on a single query. RonDB is a key-value database with SQL capabilities, so has a bit of both.

Reply on news.ycombinator.com