|
| 1 | +--- |
| 2 | +title: Design |
| 3 | +description: Architected for fast key-value storage in Go |
| 4 | +"og:title": "Design - Badger" |
| 5 | +--- |
| 6 | + |
| 7 | +We wrote Badger with these design goals in mind: |
| 8 | + |
| 9 | +- Write a key-value database in pure Go |
| 10 | +- Use latest research to build the fastest KV database for data sets spanning |
| 11 | + terabytes |
| 12 | +- Optimize for modern storage devices |
| 13 | + |
| 14 | +Badger’s design is based on a paper titled |
| 15 | +[WiscKey: Separating Keys from Values in SSD-conscious Storage](https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf). |
| 16 | + |
| 17 | +## References |
| 18 | + |
| 19 | +The following blog posts are a great starting point for learning more about |
| 20 | +Badger and the underlying design principles: |
| 21 | + |
| 22 | +- [Introducing Badger: A fast key-value store written natively in Go](https://dgraph.io/blog/post/badger/) |
| 23 | +- [Make Badger crash resilient with ALICE](https://dgraph.io/blog/post/alice/) |
| 24 | +- [Badger vs LMDB vs BoltDB: Benchmarking key-value databases in Go](https://dgraph.io/blog/post/badger-lmdb-boltdb/) |
| 25 | +- [Concurrent ACID Transactions in Badger](https://dgraph.io/blog/post/badger-txn/) |
| 26 | + |
| 27 | +## Comparisons |
| 28 | + |
| 29 | +| Feature | Badger | RocksDB | BoltDB | |
| 30 | +| ----------------------------- | -------------------------------------- | ---------------------------- | ------- | |
| 31 | +| Design | LSM tree with value log | LSM tree only | B+ tree | |
| 32 | +| High Read throughput | Yes | No | Yes | |
| 33 | +| High Write throughput | Yes | Yes | No | |
| 34 | +| Designed for SSDs | Yes (with latest research<sup>1</sup>) | Not specifically<sup>2</sup> | No | |
| 35 | +| Embeddable | Yes | Yes | Yes | |
| 36 | +| Sorted KV access | Yes | Yes | Yes | |
| 37 | +| Pure Go (no Cgo) | Yes | No | Yes | |
| 38 | +| Transactions | Yes | Yes | Yes | |
| 39 | +| ACID-compliant | Yes, concurrent with SSI<sup>3</sup> | No | Yes | |
| 40 | +| Snapshots | Yes | Yes | Yes | |
| 41 | +| TTL support | Yes | Yes | No | |
| 42 | +| 3D access (key-value-version) | Yes<sup>4</sup> | No | No | |
| 43 | + |
| 44 | +<sup>1</sup> The WiscKey paper (on which Badger is based) saw big wins with |
| 45 | +separating values from keys, significantly reducing the write amplification |
| 46 | +compared to a typical LSM tree. |
| 47 | + |
| 48 | +<sup>2</sup> RocksDB is an SSD-optimized version of LevelDB, which was designed |
| 49 | +specifically for rotating disks. As such RocksDB's design isn't aimed at SSDs. |
| 50 | + |
| 51 | +<sup>3</sup> SSI: Serializable Snapshot Isolation. For more details, see the |
| 52 | +blog post [Concurrent ACID Transactions in |
| 53 | +Badger](https://dgraph.io/blog/post/badger-txn/) |
| 54 | + |
| 55 | +<sup>4</sup> Badger provides direct access to value versions via its Iterator |
| 56 | +API. Users can also specify how many versions to keep per key via Options. |
| 57 | + |
| 58 | +## Benchmarks |
| 59 | + |
| 60 | +We've run comprehensive benchmarks against RocksDB, BoltDB, and LMDB. The |
| 61 | +benchmarking code with detailed logs are in the |
| 62 | +[badger-bench](https://github.com/dgraph-io/badger-bench) repo. |
0 commit comments