Future of FoundationDB Storage Engines
summary
Redwood implements a versioned B+ tree atop a new versioned pager to persist multiple committed versions on disk so read-only transactions can extend past the current five‑second window by trading disk for history. It adds prefix compression to cut key space, raises write parallelism vs SQLite’s serialized B‑tree, and reduces disk reads per key with a high branching factor and indirection page table. Prototype lives on master, experimental but functional.
AI-written summary · about
chapters (18)
- 0:00FoundationDB SUMMIT
- 0:20Overview
- 1:19FDB Storage Architecture
- 3:31Current Storage Engines
- 4:31Motivation
- 5:44Multi-Version Layer
- 8:41Missing' Requirements
- 9:18More About 'ssd' Storage Engine
- 11:13B+Tree vs LSM
- 12:29Redwood Storage Engine
- 12:57Copy-On-Write B+Tree Intro
- 14:39Limit Cow using Indirection
- 15:30Redwood Versioned Pager
- 16:22Redwood Versioned B+Tree
- 20:23Non-Linear Prefix Compression
- 20:50Prefix Compressed Binary Tree
- 23:05Prefix Compressed B+Tree
- 24:48Conclusion
related talks
21mRedwood Storage Engine Update
17mA New Radix-Tree Based Memory Storage Engine
46mFoundationDB: The Best-Kept Secret of New Distributed Architectures!
18mFoundationDB Record Layer: Open Source Structured Storage on FoundationDB
50mBuilding the Next-Generation Backend on FoundationDB
18mPerformance Profiling in FoundationDB
25mBuild Anything with FoundationDB
34mFoundationDB, the Black Knight