Cache-Conscious Concurrency Control of Main-Memory Indexes on Shared-Memory Multiprocessor Systems

1. Cache-Conscious Concurrency Control of Main-Memory Indexes on Shared-Memory Multiprocessor Systems By: Sang K. Cha, Sangyong Hwang, Kihong Kim and Kunjoo Kwon Presenter: Kaloian Manassiev

2. Presentation Plan • Need for main-memory DBs • Special considerations for in-memory operation • Main-memory indexing structures and concurrency control • OLFIT • Evaluation • Conclusions

3. Slide borrowed from time4change by Sang K. Cha Main Memory DBMS • Database resident in memory • Read transactions simply read the in-memory data. • Update transactions do in-memory updates and write update log to the log disk. • Occasionally, checkpoint the dirty pages of the in-memory database to the disk-resident backup DB to shorten the recovery time. MMDBMS Primary DB Checkpointing Logging Log Backup DB

4. Large Buffer record Index Blocks Data Blocks disk address Database Log Slide borrowed from time4change by Sang K. Cha Q: Is Disk Database with large buffer the same as Main Memory Database? • No! • Complex mapping between disk and memory • E.g., traversing index blocks in buffer requires bookkeeping the mapping between disk and memory addresses • Disk index block design is not optimized against hardware • cache misses.

5. Slide borrowed from time4change by Sang K. Cha Cache behavior of commercial DBMS(on Uniprocessor Pentium II Xeon) Anastassia Ailamaki et al, DBMSs on a Modern Processor: Where does time go?, VLDB 99 • Memory related delays: 40-80% of execution time. • Data accesses on caches: 19-86% of memory stalls. • Multiprocessor cache behavior? • Probably worse because of coherence cache misses

6. Main-memory database index structures • Plain old B+-Tree – too much data stored in the nodes => low fanout, which incurs cold and capacity cache misses

7. Main-memory database index structures (2) • T-Tree – small amount of data stored in the nodes, but traversal mainly touches the two end keys in the node => poor L2 cache utilisation … …

8. Main-memory database index structures (3) • CSB+-Tree – keeps only one child pointer per node and combines child nodes with a common parent into a group • Increased fanout, cache-conscious, reduces the cache miss rate and improves the search performance CSB+-tree: 23 34 47 58 Does not consider concurrent operations!

9. Concurrency control • Lock coupling

10. Concurrency control (2) • Blink-Tree • Removes the need for lock coupling by linking each node to its right neighbour

11. Concurrency control (3) • Tree-Level Locking

12. Concurrency control (4) • Physical Versioning • Use Copy-On-Write so that updaters do not interfere with concurrent readers • Severely limits the performance when the update load is high • Needs garbage collection mechanism to release the dead versions

13. OLFIT • Probability of update with 100% insert workload (10 Million keys)

14. OLFIT (1) • Node structure CCINFO

15. OLFIT (2) • Node read

16. OLFIT (3) • Node update

17. OLFIT (4) • Node split • Node deletion • Registers the node into a garbage collector ?

18. Evaluation • Algorithms & parameters

19. Evaluation (1) • Search performance

20. Evaluation (2) • Insert & delete (pure update) performance

21. Evaluation (2) • Varying update ratio performance (ST)

22. Evaluation (3) • Varying update ratio performance (MT)

23. Conclusions (pros) • Good algorithm, does not interfere with readers or other updaters • Minimises L2 cache misses • Avoids operating system locking calls • If used in a database, should put the database transactional concurrency control on top of it

24. Conclusions (cons) • Uses busy waiting • The evaluation only considers very small key sizes, so busy waiting is not a problem • It would be interesting and more validating to see the performance of this algorithm when the key sizes are longer, as is the case with databases. Then, the cost of busy waiting and retries will be more pronounced

25. Questions?