talk-lmdb#b-plus-trees-mvcc-and-memory-mapped-file1 2 3At 2:45 LMDB uses B+ trees, MVCC, and a memory mapped file talk-lmdb#b-plus-trees-mvcc-and-memory-mapped-file1 2 3
talk-lmdb#single-writer-multiple-reader1 2At 3:50 it is a single writer model, but multiple readers talk-lmdb#single-writer-multiple-reader1 2
talk-lmdb#single-writer-no-deadlocks1At 4:05 because it's single writer you never run into any deadlocks talk-lmdb#single-writer-no-deadlocks1
talk-lmdb#batched-writes1At 4:45 we support batched writes, which is just a way of saying we support multiple writes with in one transaction talk-lmdb#batched-writes1
talk-lmdb#no-write-ahead-log-no-compaction1 2At 5:17 there is no write ahead log, no compaction talk-lmdb#no-write-ahead-log-no-compaction1 2
At six it is a read only memory map
talk-lmdb#os-cache1At 6:10 because we are using the OS cache, there is no wasted memory anywhere talk-lmdb#os-cache1
At 11:40 inspired by an append-only Btree that came from FreeBSD
talk-lmdb#sequential-io-is-fast1At 1320 this kind of thing does a lot of IO, but it is fast because it is sequential talk-lmdb#sequential-io-is-fast1
talk-lmdb#shadow-buffer1At 1436 for LMDB we only have two root nodes and we ping pong between them like a shadow buffer talk-lmdb#shadow-buffer1
At 1545 they used two Btrees. One for user data, and the other for tracking the lists of the page ideas that have just been freed
At 1710 if you hold a read transaction open for a long time then the writes are a pure append-only model for the duration of that, so you typically don't want to do that
talk-lmdb#readers-no-locks-but-still-need-to-track1At 1710 even though readers don't take locks, you still need to track their transactions so that you know which memory cannot be freed yet talk-lmdb#readers-no-locks-but-still-need-to-track1
talk-lmdb#fsync-and-data-loss1 2At 1820 they actually perform two fsyncs per commit. The first is to sync all the pages, and the second is to sync the meta-page. If the system crashes between writing the pages and the meta page, then that transaction is lost but the previous ones are not talk-lmdb#fsync-and-data-loss1 2
talk-lmdb#thread-local-storage1At 19 All the reader slots are stored in thread-local storage talk-lmdb#thread-local-storage1
19:45 key comparisons in reverse byte order
At 2050 a special append mode
At 2205 sub databases. It is what SQL light uses for its index tables
Multiple values for a single key at 2245. Must be sorted
At 2330 you can do a hot back up which takes a read transaction, so it is basically a snapshot. You are bound only by the performance of your I/O. On the Lenix it writes multiple files or multiple times probably multiple times because of the 2 GB per Wright limitation. The slide calls this atomic hot back up
At 26LMDB bags I am cash do you be in an experiment and it's even faster at Reed's than the original ma'am cash because mom cash takes locks.
At 2850 he shows both asynchronous for a performance in Saint Ritas for a performance, where they do and at the sink after each commit
At 35 on a 16 core CPU, the Berkeley DB gets asymptotic because of the lock overhead. Something about CPUs slots
Add 36 when you start crossing socket boundaries then your performance really goes in the tank