Building a Columnar Database on RAMCloud: Database Design for the Low-Latency Enabled Data Center

139 Pages·2016·3.351 MB·English

by  Christian Tinnefeld (auth.)

In-Memory Data Management Research
Christian Tinnefeld
Building
a Columnar
Database on
RAMCloud
Database Design for the Low-Latency
Enabled Data Center
In-Memory Data Management Research
Series editor
Prof. Dr. Dr. h.c. Hasso Plattner
Hasso Plattner Institute
Potsdam, Germany
More information about this series at http://www.springer.com/series/11642
Christian Tinnefeld
Building a Columnar
Database on RAMCloud
Database Design for the Low-Latency
Enabled Data Center
123
Christian Tinnefeld
HassoPlattner Institute
University of Potsdam
Potsdam
Germany
ISSN 2196-8055 ISSN 2196-8063 (electronic)
In-Memory Data ManagementResearch
ISBN978-3-319-20710-0 ISBN978-3-319-20711-7 (eBook)
DOI 10.1007/978-3-319-20711-7
LibraryofCongressControlNumber:2015943368
SpringerChamHeidelbergNewYorkDordrechtLondon
©SpringerInternationalPublishingSwitzerland2016
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpart
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
orinformationstorageandretrieval,electronicadaptation,computersoftware,orbysimilarordissimilar
methodologynowknownorhereafterdeveloped.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publicationdoesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexemptfrom
therelevantprotectivelawsandregulationsandthereforefreeforgeneraluse.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authorsortheeditorsgiveawarranty,expressorimplied,withrespecttothematerialcontainedhereinor
foranyerrorsoromissionsthatmayhavebeenmade.
Printedonacid-freepaper
SpringerInternationalPublishingAGSwitzerlandispartofSpringerScience+BusinessMedia
(www.springer.com)
I thank my parents Gerd and Margret
for their love and support
Preface
In the field of disk-based parallel database management systems exists a great
variety of solutions based on a shared-storage or a shared-nothing architecture.
In contrast, main memory-based parallel database management systems are domi-
nated solely by the shared-nothing approach as it preserves the in-memory per-
formance advantage by processing data locally on each server. We argue that this
unilateral development is going to cease due to the combination of the following
three trends: (a) Nowadays, network technology features remote direct memory
access(RDMA)andnarrowstheperformancegapbetweenaccessingmainmemory
inside a server and of a remote server to and even below a single order of mag-
nitude. (b) Modern storage systems scale gracefully, are elastic, and provide
high-availability.(c)AmodernstoragesystemsuchasStanford’sRAMCloudeven
keeps all data resident in main memory. Exploiting these characteristics in
the context of a main-memory parallel database management system is desirable.
TheadventofRDMA-enablednetworktechnologymakesthecreationofaparallel
main memory DBMS based on a shared-storage approach feasible.
Thisworkdescribesbuildingacolumnardatabaseonsharedmainmemory-based
storage. It discusses the resulting architecture (Part I), the implications on query
processing(PartII),andpresentsanevaluationoftheresultingsolutionintermsof
performance,high-availability, and elasticity (Part III).
We use Stanford’s RAMCloud as shared-storage, and the self-designed and
developed in-memory AnalyticsDB as relational query processor on top.
AnalyticsDBencapsulatesdataaccessandoperatorexecutionviaaninterfacewhich
allows seamless switching between local and remote main memory, while
RAMCloud provides not only storage capacity, but also processing power.
Combining both aspects allows pushing-down the execution of database operators
into the storage system. We describe how the columnar data processed by
AnalyticsDB is mapped to RAMCloud’s key-value data model and how the
advantages ofcolumnardata storage can be preserved.
The combination of fast network technology and the possibility to execute
databaseoperatorsinthestoragesystemopensthediscussionforsiteselection.We
construct a system model that allows the estimation of operator execution costs in
vii
viii Preface
terms of network transfer, data processed in memory, and wall time. This can be
used for database operators that work on one relation at a time—such as a scan or
materialize operation—to discuss the site selection problem (data pull vs. operator
push). Since a database query translates to the execution of several database
operators, it is possible that the optimal site selection varies per operator. For the
execution of a database operator that works on two (or more) relations at a time,
suchasajoin,thesystemmodelisenrichedbyadditionalfactorssuchasthechosen
algorithm(e.g.Grace-vs.DistributedBlockNestedLoopJoinvs.Cyclo-Join),the
data partitioning of the respective relations, and their overlapping as well as the
allowed resource allocation.
We present an evaluation on a cluster with 60 nodes where all nodes are con-
nected via RDMA-enabled network equipment. We show that query processing
performance is about 2.4x slower if everything is done via the data pull operator
execution strategy (i.e. RAMCloud is being used only for data access) and about
27 % slower if operator execution is also supported inside RAMCloud (in com-
parison to operating only on main memory inside a server without any network
communication at all). The fast-crash recovery feature of RAMCloud can be lev-
eragedtoprovidehigh-availability,e.g.aservercrashduringqueryexecutiononly
delaysthequeryresponseforaboutonesecond.Oursolutioniselasticinawaythat
it can adapt to changing workloads (a) within seconds, (b) without interruption
of the ongoing query processing, and (c) without manual intervention.
Palo Alto, CA, USA Christian Tinnefeld
April 2015
Contents
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Research Questions and Scope. . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Related Work and Background. . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Current Computing Hardware Trends . . . . . . . . . . . . . . . . . . . 7
2.1.1 Larger and Cheaper Main Memory Capacities . . . . . . . . 9
2.1.2 Multi-Core Processors and the Memory Wall. . . . . . . . 10
2.1.3 Switch Fabric Network and Remote
Direct Memory Access . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 In-Memory Database Management Systems. . . . . . . . . . . . . . 16
2.2.1 Column- and Row-Oriented Data Layout. . . . . . . . . . . 17
2.2.2 Transactional Versus Analytical Versus Mixed
Workload Processing . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 State-of-the-Art In-Memory Database
Management Systems. . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Parallel Database Management Systems. . . . . . . . . . . . . . . . . 22
2.3.1 Shared-Memory Versus Shared-Disk
Versus Shared-Nothing. . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 State-of-the-Art Parallel Database
Management Systems. . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.3 Database-Aware Storage Systems. . . . . . . . . . . . . . . . 29
2.3.4 Operator Placement for Distributed
Query Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Cloud Storage Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 State-of-the-Art Cloud Storage Systems. . . . . . . . . . . . 38
2.4.2 Combining Database Management and Cloud
Storage Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
ix
x Contents
Part I A Database System Architecture for a Shared
Main Memory-Based Storage
3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 System Architecture—Requirements, Assumptions,
and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 AnalyticsDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3 Stanford’s RAMCloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Mapping from Columnar Data to RAMCloud Objects. . . . . . . 53
4.2 Main Memory Access Costs and Object Sizing . . . . . . . . . . . 54
5 Data Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Database Operators in AnalyticsDB . . . . . . . . . . . . . . . . . . . 63
5.2 Operator Push-Down into RAMCloud. . . . . . . . . . . . . . . . . . 64
5.3 From SQL Statement to Main Memory Access. . . . . . . . . . . . 65
Part II Database Operator Execution on a Shared
Main Memory-Based Storage
6 Operator Execution on One Relation. . . . . . . . . . . . . . . . . . . . . 69
6.1 Evaluating Operator Execution Strategies. . . . . . . . . . . . . . . . 72
6.2 Optimizing Operator Execution . . . . . . . . . . . . . . . . . . . . . . 75
6.3 Implications of Data Partitioning . . . . . . . . . . . . . . . . . . . . . 75
7 Operator Execution on Two Relations. . . . . . . . . . . . . . . . . . . . 79
7.1 Grace Join. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 Distributed Block Nested Loop Join . . . . . . . . . . . . . . . . . . . 83
7.3 Cyclo Join. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.4 Join Algorithm Comparison. . . . . . . . . . . . . . . . . . . . . . . . . 87
7.5 Parallel Join Executions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Part III Evaluation
8 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.1 Analytical Workload: Star Schema Benchmark. . . . . . . . . . . . 95
8.2 Mixed Workload: Point-of-Sales Customer Data. . . . . . . . . . . 98
9 High-Availability Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10 Elasticity Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103