This document discusses approaches to scaling in-memory databases on multicore hardware. There are two main approaches: employing a symmetric database engine where a single process uses multiple threads across cores to access shared memory, and employing a partitioned database engine where the database is divided into partitions managed by dedicated cores. A challenge is that cache coherency limits scalability as it does not scale to thousands of cores. The document recommends a software-hardware co-design approach, avoiding centralized critical sections, leveraging hardware message passing, and using techniques like optimistic concurrency control to improve scalability on high core count systems.

1. The Goal: In-Memory Database Scalability
core core
ore core
core core
core core
core core
ore core
core core
core core
core core
ore core
core core
core core
core core
ore core
core core
core corecore
Multicores
(CMP) Multisocket
Multicores
 How can DBMS engine scale across
hardware islands ?
in-memory database on multicore

2. Two Approaches to In-Memory Database
Scalability on Multicore
 Employing a Symmetric Database Engine
 Example Systems: SILO and Hekaton
 Employing a Partitioned Database Engine
 Example Systems: DORA, PLP, ATraPos and H-Store
in-memory database on multicore

3. A Symmetric Database Engine Architecture
 Symmetric Database Engine using Shared Memory
 Database Process consists of
multiple transaction threads
each running on a separate core
 Transaction threads access the
entire shared memory with cache
coherency enabled
 Transaction Engine takes care
about Serializability
 Processor takes care about Cache
Coherency
in-memory database on multicore

4. A Partitioned Database Engine Architecture
 Partitioned Database as Primary Scalability Mechanism
 Database is divided into multiple partitions
each managed by a dedicated core
 A partition is owner of its data and indexes
 A centralized routing table is required
to route transactions to partitions
 Multi-partition transactions is executed
by migrating transactions between
cores
 Partitioning may be static or dynamic
 dynamic re-partitioning mechanism
enables to load balance partition
access
 All partitions must reside in shared
memory with Cache Coherency enabled
in-memory database on multicore

5. Problem: Cache Coherency Limits Scalability
 Cache Coherency Mechanism (CCM) limits processor
scalability
 Cache Coherency of thousand cores is not feasible
 Problem: How can a DBMS engine scale in the
presence of non-coherent hardware islands ?
Hardware Island with CCM Hardware Island with CCM
CCM
in-memory database on multicore

6. In-memory Database on Thousand cores
The paper: Staring Into The Abyss: An Evaluation Of
Concurrency Control With One Thousand Cores
concludes with the following observation
 Software-hardware co-design is the only solution to
address the performance issues resulting from high
core count. For certain functionalities, specialized
hardware can significantly improve performance while
reducing power consumption
 The next slides provides some design guidelines
in-memory database on multicore

7. System Design Principles
 Avoid many of the centralized critical sections present
in classic database engines (see next slide)
 Be sensitive to the cost of Cache Coherency (CC)
Do you really need CC enabled on all cores?
 Leveraging hardware message passing for efficient
thread synchronization (inter-core communication);
example the TILE-Gx processor family
in-memory database on multicore

8. Avoid Centralized Critical Sections
 Avoid centralized contention points and make all
synchronization scale with the data, allowing larger
databases to support more concurrency.
 Use lightweight locking mechanism and eliminate the
bottleneck of a centralized lock manager, by co-
locating locks with each DB record
 Use optimistic based concurrency control possibly
combined with multi-version mechanism
 Use transaction’s local memory - private workspace -
to cache its write-set and avoid installing writes until
commit time
in-memory database on multicore