Database Reference
In-Depth Information
Chapter 32
In-Memory OLTP Internals
Hekaton is the code name of an in-memory OLTP engine introduced in SQL Server 2014. It is an Enterprise Edition
feature, and it is available only in the 64-bit version of SQL Server. Hekaton is Greek for one hundred, which was the
target performance improvement goal of the project. Even though this goal has yet to be achieved, it is not uncommon
to see a 10X-30X system-throughput increase when in-memory OLTP is used.
This chapter discusses the internal architecture of in-memory OLTP, the in-memory and on-disk storage format
for memory-optimized data and the concurrency model used in Hekaton.
Why Hekaton?
Way back, when SQL Server and other major databases were originally designed, hardware was very expensive.
Servers used to have just one or very few CPUs, and a small amount of installed memory. Database servers had to
work with data that resided on disk and load it to memory on demand.
The situation has dramatically changed over time. During the last 30 years, memory prices have dropped by a
factor of 10 every five years. Hardware became more affordable. It is now entirely possible to buy a server with 32 cores
and 1TB of RAM for less than $50,000. While it is also true that databases have become larger, it is often possible that
active operational data fits into the memory.
Obviously, it is beneficial to have data cached in the buffer pool. It reduces the load on the I/O subsystem and
improves system performance. However, when systems work under heavy concurrent load, it is often not enough.
SQL Server manages and protects page structures in memory, which introduces large overhead and does not scale well.
Even with row-level locking, multiple sessions cannot modify data on the same data page simultaneously and must
wait for each other.
Perhaps the last sentence needs to be clarified. Obviously, multiple sessions can modify data rows on the same
data page, holding exclusive (X) locks on different rows simultaneously. However, they cannot update on-page and in-row
data simultaneously because it could corrupt the page structure. SQL Server addresses this problem by protecting pages
with latches . Latches work in a similar manner to locks, protecting internal SQL Server data structures by serializing
access to them; only one thread can update data on the data page in memory at any given point of time.
Note
It limits the improvements that can be achieved with the current database systems architecture. Although you can
scale hardware by adding more CPUs with a larger number of logical cores per CPU, that serialization quickly becomes a
bottleneck and limiting factor in improving system scalability. Likewise, you cannot improve performance by increasing
the CPU clock speed as the silicon chips would melt down. Therefore, the only feasible way to improve database system
performance is by reducing the number of CPU instructions that need to be executed to perform an action.
 
 
Search WWH ::




Custom Search