250 likes | 475 Views
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. Presentation Plan. Need for main-memory DBs Special considerations for in-memory operation
E N D
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
Presentation Plan • Need for main-memory DBs • Special considerations for in-memory operation • Main-memory indexing structures and concurrency control • OLFIT • Evaluation • Conclusions
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
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.
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
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
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 … …
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!
Concurrency control • Lock coupling
Concurrency control (2) • Blink-Tree • Removes the need for lock coupling by linking each node to its right neighbour
Concurrency control (3) • Tree-Level Locking
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
OLFIT • Probability of update with 100% insert workload (10 Million keys)
OLFIT (1) • Node structure CCINFO
OLFIT (2) • Node read
OLFIT (3) • Node update
OLFIT (4) • Node split • Node deletion • Registers the node into a garbage collector ?
Evaluation • Algorithms & parameters
Evaluation (1) • Search performance
Evaluation (2) • Insert & delete (pure update) performance
Evaluation (2) • Varying update ratio performance (ST)
Evaluation (3) • Varying update ratio performance (MT)
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
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