3 ms·

The log is always written, what's not written asap is changes on the tree (changes go into the buffers first and then trickle down when buffers are full).

• leif 11y ago
  This is the critical insight. TokuDB uses a write-ahead log which is synced according to the configuration, and can be made as immediate as full fsync on commit. This provides the strongest durability available on a single machine. Where TokuDB gets its speed boost is by delaying the random reads associated with updating the indexing structure (the Fractal Tree). The buffers are written to disk on checkpoint, but because they're buffers, the potentially random writes are localized to a smaller number of nodes high in the tree, which minimizes the number of disk seeks required. Since sequential I/O is cheaper than random, the sequential writes to the write-ahead log are very fast, so even in very strict durability configurations, TokuDB can easily outperform databases which use random writes to update the indexing structures, such as the B-trees used by InnoDB and most other RDBMSes. More details here: https://www.percona.com/blog/2011/09/22/write-optimization-myths-comparison-clarifications/ https://www.percona.com/blog/2011/09/22/write-optimization-m...