![](https://csdnimg.cn/release/download_crawler_static/88258051/bg3.jpg)
that moves quickly towards any direction in a very deep
ocean (i.e., the huge database stored on X-Engine). The stor-
age engine needs to ensure that emerging hot records can
be retrieved from the deep water as quickly as possible and
cache them eectively.
Our contributions.
We introduce X-Engine in this pa-
per. X-Engine is an LSM-tree based storage engine for OTLP
databases that is designed to address the above challenges
faced by Alibaba’s e-commerce platform. It processes most
requests in the main memory by exploiting the thread-level
parallelism (TLP) in multi-core processors, decouples writes
from transactions to make them asynchronous, and decom-
poses a long write path into multiple stages in a pipeline
in order to increase the overall throughput. To address the
ood discharge problem, X-Engine exploits a tiered storage
approach to move records among dierent tiers taking ad-
vantage of a rened LSM-tree structure and optimized com-
paction algorithms. We also apply FPGA ooading on com-
pactions. Finally, to address the fast-moving current problem,
we introduce a multi-version metadata index which is up-
dated in a copy-on-write fashion to accelerate point lookups
in the tiered storage regardless of data temperatures. To
summarize, our contributions are:
•
We identify three major challenges for an OLTP stor-
age engine in processing e-commerce transactions, and
design X-Engine based on the LSM-tree structure.
•
We introduce a suite of optimizations for addressing
the identied problems, such as a rened LSM-tree data
structure, FPGA-accelerated compactions, asynchro-
nous writes in transactions, multi-staged pipelines,
and multi-version metadata index.
•
We evaluate X-Engine extensively using both standard
benchmarks and e-commerce workloads. Results show
that X-Engine outperforms both InnoDB and RocksDB
in e-commerce workloads during online promotions.
We also show that X-Engine has stood the test of the
tsunami of the Singles’ Day Shopping Festival.
This paper is organized as follows. Section 2 gives the
overview of X-Engine. Section 3 introduces the detailed de-
signs of our optimizations. We evaluate our design and opti-
mizations in Section 4, by comparing it against InnoDB and
RocksDB using MySQL. Finally, we discuss related work in
Section 5 and conclude in Section 6.
2 System Overview
X-Engine is a tiered OLTP storage engine based on an re-
ned LSM-tree structure. As discussed in Section 1, because
the data temperature in e-commerce transactional workloads
is constantly changing, we are motivated to dierentiate the
placement of records in dierent storage tiers to serve hot,
warm, and cold records respectively. This allows X-Engine to
tailer-design data structures and access methods according
to record temperatures (i.e., frequencies of being accessed in
a recent window). Furthermore, because e-commerce trans-
actions involve a large number of inserts and updates, we
adopt the LSM-tree due to its excellent write performance
[
27
]. However, we nd that a conventional LSM-tree is not
sucient for supporting e-commerce transactional work-
loads. Thus, we design and apply a suite of optimizations
in X-Engine to address the three previously identied chal-
lenges. X-Engine can be deployed on top of the POLARFS as
part of POLARDB [
4
]. POLARFS has utilized many emerging
techniques to achieve an ultra-low latency le system such
as RDMA and NVMe.
ActiveMemtable
Switch
RedoLogs
Caches
Extent Extent
Datafiles
ExtentExtent Extent Extent
Extent Extent Extent Extent
Warmdataon
NVM/SSD
Colddataon
SSD/HDD
Colddata
on
SSD/HDD
HotdataTier
Warm/colddataTier
FPGA
accelerated
compactions
Indexes
Flush
Writes
Reads
Immutable
memtable
Figure 2: The architecture of X-Engine.
Storage layout.
Figure 2 shows the architecture of X-
Engine. X-Engine partitions each table into multiple sub-
tables, and maintains an LSM-tree, the associated metasnap-
shots and indexes for each sub-table. X-Engine contains one
redo log per database instance. Each LSM-tree consists of a
hot data tier residing in main memory and a warm/cold data
tier residing in NVM/SSD/HDD (that are further partitioned
into dierent levels), where the term hot, warm, and cold
refers to data temperatures, representing the ideal access
frequencies of data that should be placed in the correspond-
ing tier. The hot data tier contains an active memtable and
multiple immutable memtables, which are skiplists storing
recently inserted records, and caches to buer hot records.
The warm/cold data tier organizes data in a tree-like struc-
ture, with each level of the tree storing a sorted sequence of
extents. An extent packages blocks of records as well as their
associated lters and indexes. We are exploring machine
learning techniques to identify appropriate data tempera-
tures, which is briey discussed in Appendix C and its full
details are out of the scope of this work.
X-Engine exploits redo logs, metasnapshots, and indexes
to support Multi-version Concurrency Control (MVCC) for
transaction processing. Each metasnapshot has a metadata
3