5 ms·

SableDb – Fast, persistent database supporting Redis API

114 points by SableDb 3y ago

marcosdly 3y ago
Written in Rust™
- vdfs 3y ago
  unsafe fn main() { ... }
  - eatonphil 3y ago
    Not that I see? https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/main.rs https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/...
    - topbanana 2y ago
      RocksDB is written in C++ and runs in-process. That's just like having a load of unsafe Rust code.
      - deleted 2y ago
        [deleted]
      - SableDb 2y ago
        So does OpenSSL, Bytes crates, WinAPI and many many other crates used by many Rust applications. Does this make applications written in Rust less "Rusties"? IMO, the networking, threading and "tasks" ("green threads") in SableDb code base are the most risky part of writing a server and by choosing Rust, the risk of memory issues is reduced to minimum without scarifying performance
- xedrac 2y ago
  So it's a Redis API written in Rust, but the underlying database is all C++. It seems like a nice project, but perhaps a little misleading to say it's written in Rust.
  - zackangelo 2y ago
    If anyone is interested in a Rust-based on-disk KV store, I've come across sled[0] a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well. [0] https://github.com/spacejam/sled https://github.com/spacejam/sled
    - SableDb 2y ago
      See my previous comment. Sled was considered, and it was the main KV storage in early implementation. I kept the adapter approach in the code, so switching back to sled should be pretty easy (or even converting it to full in-memory)
  - SableDb 2y ago
    The storage itself uses the rust binding for RocksDb However, I did have a branch (in another repo) that uses other different storage, some are purely written in Rust, like "dash" (which is full in-memory), "sled" and "speedb". I eventually decided to stick with RocksDb since its well mature and maintained by some giant companies like Meta. The user code (the one I wrote) is all Rust. Also, one could also argue that the `bytes` crate that is heavily utilized in the code base of SableDb, uses plenty of `unsafe` code, does this make it less "Rust" ?
jitl 3y ago
It would be informative to compare to memory only Redis and persistent Redis on the same hardware with the same benchmark suite. Even if SableDb is slower since it’s durably persisted, it would still be useful to consider the tradeoff versus ephemeral or weakly persisted implementation of the same API.
- CyanLite2 3y ago
  It's slower than Garnet. https://microsoft.github.io/garnet/docs/benchmarking/results-resp-bench https://microsoft.github.io/garnet/docs/benchmarking/results...
  - dlahoda 2y ago
    most self reports are false. there should be 3rd party eval.
  - jitl 2y ago
    I don’t see SableDB mentioned in your link, and my comment is specifically about comparing using the same benchmark. Comparing across benchmarks is usually foolish since there’s so many factors that are different and performance scales non-linearly over the factors. For example the Garnet benchmark uses machines with 72 Azure vCPUs, the SableDB one uses AWS machines with 16 vCPUs. Besides, I don’t expect SableDB to be faster than weakly persisted systems like Redis or I guess Garnet. The cool thing about SableDB is that it (looks?) durable - although the docs don’t make specific promises, they do mention some things in passing that imply RocksDb transactions. Each command seems to flush its changes to durable storage before succeeding. That’s very different from Redis et al even with their “append only file” / WAL turned on - the AOF is written asynchronously so you will still lose data on crash. Redis also deletes random data when under memory/storage pressure. Again, I want to understand trade-offs not “find the fastest web scale database”. I’m sure /dev/null is faster than Garnet.
hivacruz 3y ago
How does it compare to Kvrocks, which use RocksDB as the storage backend too? https://github.com/apache/kvrocks/ https://github.com/apache/kvrocks/
- SableDb 2y ago
  It performs better and uses different design choices (for example: SableDb uses tokio's local task per connection, and in general it uses green threads to make the code more readable and easy to maintain). I will release some design documents later on (hopefully this month). Remember that is a one man project (hopefully, not for long), so it takes time to organize everything :)
  - theossuary 2y ago
    I like the idea of doing thread local execution of Tokyo tasks; I assume that means SableDb is mostly single threaded? Was this to reduce complexity, or for some other reason? I'm looking forward to the design doc on this!
    - SableDb 2y ago
      It is multi-threaded (configurable, you can set it to a specific number configuration file, or use the magic value 0 where SableDb decides based on the number of cores divided by 2). Each incoming connection is assigned to a worker thread, and two tokio tasks are created for the connection (one for reading and another for writing). Using tokio allowed me to use the `async` code without using "callback hell" so the code looks clean and readable in a single glance without the need to follow callbacks
      - super_user 2y ago
        Hi SableDb. I am looking for a tech cofounder in databases. Probably not the best place to ask for a cofounder. :-) Regardless, would you be interested?
        2y ago
dboreham 2y ago
imho LSM (which is what RocksDB is) is not the optimal storage manager for this application. Should be a B-tree-like thing.
- pgwhalen 2y ago
  What do you mean by “this application”? There’s no application here, it’s just a database, right? Or do you mean that LSMs shouldn’t be a foundation for a database?
  - woooooo 2y ago
    LSM are write-optimized, most deployments of Redis are read-heavy situations.
rafaelturk 2y ago
SableDB - Written in Rust, well kind of: RocksDB engine is written entirely in C++
welder 2y ago
Looks promising, but needs support for more than just strings and lists. I personally use hashes, sorted-sets, and sets more than lists in production apps, and probably others too? https://github.com/sabledb-io/sabledb/issues/7 https://github.com/sabledb-io/sabledb/issues/7
- SableDb 2y ago
  Absolutely, adding more commands is my goal Completing a full-sync replication is my first priority (I have currently implemented a WAL tailing from primary -> replica) but tailing from a snapshot is the ideal solution IMO here. Once this in place, adding "hash" commands (hset, hget etc) is the next family of commands. I open sourced it hopefully to get help from people out there :)

114 points by SableDb 3y ago

marcosdly 3y ago

Written in Rust™

vdfs 3y ago
unsafe fn main() { ... }
- eatonphil 3y ago
  Not that I see? https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/main.rs https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/...
  - topbanana 2y ago
    RocksDB is written in C++ and runs in-process. That's just like having a load of unsafe Rust code.
    - deleted 2y ago
      [deleted]
    - SableDb 2y ago
      So does OpenSSL, Bytes crates, WinAPI and many many other crates used by many Rust applications. Does this make applications written in Rust less "Rusties"? IMO, the networking, threading and "tasks" ("green threads") in SableDb code base are the most risky part of writing a server and by choosing Rust, the risk of memory issues is reduced to minimum without scarifying performance
xedrac 2y ago
So it's a Redis API written in Rust, but the underlying database is all C++. It seems like a nice project, but perhaps a little misleading to say it's written in Rust.
- zackangelo 2y ago
  If anyone is interested in a Rust-based on-disk KV store, I've come across sled[0] a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well. [0] https://github.com/spacejam/sled https://github.com/spacejam/sled
  - SableDb 2y ago
    See my previous comment. Sled was considered, and it was the main KV storage in early implementation. I kept the adapter approach in the code, so switching back to sled should be pretty easy (or even converting it to full in-memory)
- SableDb 2y ago
  The storage itself uses the rust binding for RocksDb However, I did have a branch (in another repo) that uses other different storage, some are purely written in Rust, like "dash" (which is full in-memory), "sled" and "speedb". I eventually decided to stick with RocksDb since its well mature and maintained by some giant companies like Meta. The user code (the one I wrote) is all Rust. Also, one could also argue that the `bytes` crate that is heavily utilized in the code base of SableDb, uses plenty of `unsafe` code, does this make it less "Rust" ?

jitl 3y ago

It would be informative to compare to memory only Redis and persistent Redis on the same hardware with the same benchmark suite. Even if SableDb is slower since it’s durably persisted, it would still be useful to consider the tradeoff versus ephemeral or weakly persisted implementation of the same API.

CyanLite2 3y ago
It's slower than Garnet. https://microsoft.github.io/garnet/docs/benchmarking/results-resp-bench https://microsoft.github.io/garnet/docs/benchmarking/results...
- dlahoda 2y ago
  most self reports are false. there should be 3rd party eval.
- jitl 2y ago
  I don’t see SableDB mentioned in your link, and my comment is specifically about comparing using the same benchmark. Comparing across benchmarks is usually foolish since there’s so many factors that are different and performance scales non-linearly over the factors. For example the Garnet benchmark uses machines with 72 Azure vCPUs, the SableDB one uses AWS machines with 16 vCPUs. Besides, I don’t expect SableDB to be faster than weakly persisted systems like Redis or I guess Garnet. The cool thing about SableDB is that it (looks?) durable - although the docs don’t make specific promises, they do mention some things in passing that imply RocksDb transactions. Each command seems to flush its changes to durable storage before succeeding. That’s very different from Redis et al even with their “append only file” / WAL turned on - the AOF is written asynchronously so you will still lose data on crash. Redis also deletes random data when under memory/storage pressure. Again, I want to understand trade-offs not “find the fastest web scale database”. I’m sure /dev/null is faster than Garnet.

hivacruz 3y ago

How does it compare to Kvrocks, which use RocksDB as the storage backend too? https://github.com/apache/kvrocks/ https://github.com/apache/kvrocks/

SableDb 2y ago
It performs better and uses different design choices (for example: SableDb uses tokio's local task per connection, and in general it uses green threads to make the code more readable and easy to maintain). I will release some design documents later on (hopefully this month). Remember that is a one man project (hopefully, not for long), so it takes time to organize everything :)
- theossuary 2y ago
  I like the idea of doing thread local execution of Tokyo tasks; I assume that means SableDb is mostly single threaded? Was this to reduce complexity, or for some other reason? I'm looking forward to the design doc on this!
  - SableDb 2y ago
    It is multi-threaded (configurable, you can set it to a specific number configuration file, or use the magic value 0 where SableDb decides based on the number of cores divided by 2). Each incoming connection is assigned to a worker thread, and two tokio tasks are created for the connection (one for reading and another for writing). Using tokio allowed me to use the `async` code without using "callback hell" so the code looks clean and readable in a single glance without the need to follow callbacks
    - super_user 2y ago
      Hi SableDb. I am looking for a tech cofounder in databases. Probably not the best place to ask for a cofounder. :-) Regardless, would you be interested?
      - 2y ago

dboreham 2y ago

imho LSM (which is what RocksDB is) is not the optimal storage manager for this application. Should be a B-tree-like thing.

pgwhalen 2y ago
What do you mean by “this application”? There’s no application here, it’s just a database, right? Or do you mean that LSMs shouldn’t be a foundation for a database?
- woooooo 2y ago
  LSM are write-optimized, most deployments of Redis are read-heavy situations.

rafaelturk 2y ago

SableDB - Written in Rust, well kind of: RocksDB engine is written entirely in C++

welder 2y ago

Looks promising, but needs support for more than just strings and lists. I personally use hashes, sorted-sets, and sets more than lists in production apps, and probably others too? https://github.com/sabledb-io/sabledb/issues/7 https://github.com/sabledb-io/sabledb/issues/7

SableDb 2y ago
Absolutely, adding more commands is my goal Completing a full-sync replication is my first priority (I have currently implemented a WAL tailing from primary -> replica) but tailing from a snapshot is the ideal solution IMO here. Once this in place, adding "hash" commands (hset, hget etc) is the next family of commands. I open sourced it hopefully to get help from people out there :)