DAX: A Widely Distributed Multi-tenant
Storage Service for DBMS Hosting
Rui Liu, Ashraf Aboulnaga, Kenneth Salem
Universit...
RDBMS in the Cloud
● Many cloud/non-cloud applications use
relational DBMS
○ easy-to-use
○ robust apps
○ good performance
...
DBMS Setting in Cloud
Storage service
DB Log
DBMS
● Data and log are stored in network accessible
storage
● On failure, a ...
DBMS Setting in Cloud
Storage service
DB Log
DBMS
● Data and log are stored in network accessible
storage
● On failure, a ...
DBMS Setting in Cloud
Storage service
DB Log
DBMS DBMS
● Data and log are stored in network accessible
storage
● On failur...
Data Center
Disaster Tolerance
● Current solutions: log shipping, storage
mirror or backup
○ Complex
○ Slow (synchronous)
...
Our Solution
Disaster tolerant storage for DBMS Hosting
DBMS DBMS
App AppApp App
Data Center
Storage service
DBMS DBMS
App...
DAX
Distributed Application-controlled
Consistent Store
● Block I/O interface to DBMS
● Quorum-based, multi-
master replic...
Baseline: Quorum Reads and Writes
● Block replication: N times across DAX
servers
○ servers and copies cover all data cent...
Local Read and Write Latencies
●N = 3, in a single data center
●Consistency penalty: waiting for more replicas is
slower
Wide-Area Read and Write Latencies
●N = 3, copies in Oregon and Virginia
●Much larger consistency penalty!
Goal of DAX
● Achieve the performance of R=1/W=1 while
maintaining consistency, durability, and
availability
Contributions...
Optimistic I/O
● Key observation
With R=W=1, most reads do not return stale data
○ Single writer
○ DBMS buffer pool
○ Para...
Client-Managed Durability
● Key observations
○ Transaction semantics dictate when writes
must be safe (Durable) and when t...
Client-Managed Durability
● DAX has two kinds of writes
○ Data write, without durability guarantee
○ Synchronized write th...
Consistency in DAX
● Key idea: make DAX look like an
unreplicated storage system with explicit
synchronization points for ...
Consistency Example
●Which write should each read see?
●R1 must see W3
●R2 can see W1, W2, or W3
●R3 must see the version ...
Experiment Configurations
●9 DAX servers
●6 replicas distributed in
1 EC2 region
(1 zone)
3 EC2 regions
r1 r2 r3 r4 r5
DBM...
Throughput with DAX
MySQL and DAX in Amazon EC2
TPC-C Workload - 9 DAX Nodes
Summary
● DAX: disaster-tolerant storage for DBMS
hosting
○ Scalable in storage capacity, bandwidth and the
number of data...
Upcoming SlideShare
Loading in …5
×

DAX: A Widely Distributed Multi-tenant Storage Service for DBMS Hosting

562 views
460 views

Published on

Talk in VLDB 2013

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
562
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

DAX: A Widely Distributed Multi-tenant Storage Service for DBMS Hosting

  1. 1. DAX: A Widely Distributed Multi-tenant Storage Service for DBMS Hosting Rui Liu, Ashraf Aboulnaga, Kenneth Salem University of Waterloo
  2. 2. RDBMS in the Cloud ● Many cloud/non-cloud applications use relational DBMS ○ easy-to-use ○ robust apps ○ good performance ○ possibility of scale-out (e.g., by sharding)
  3. 3. DBMS Setting in Cloud Storage service DB Log DBMS ● Data and log are stored in network accessible storage ● On failure, a new DBMS is launched
  4. 4. DBMS Setting in Cloud Storage service DB Log DBMS ● Data and log are stored in network accessible storage ● On failure, a new DBMS is launched
  5. 5. DBMS Setting in Cloud Storage service DB Log DBMS DBMS ● Data and log are stored in network accessible storage ● On failure, a new DBMS is launched
  6. 6. Data Center Disaster Tolerance ● Current solutions: log shipping, storage mirror or backup ○ Complex ○ Slow (synchronous) ○ Or, lost data (asynchronous) Storage service DB Log DBMS Data Center Storage service DB Log DBMSLog Shipping Mirror/Backup OR
  7. 7. Our Solution Disaster tolerant storage for DBMS Hosting DBMS DBMS App AppApp App Data Center Storage service DBMS DBMS App AppApp App Data Center Storage service
  8. 8. DAX Distributed Application-controlled Consistent Store ● Block I/O interface to DBMS ● Quorum-based, multi- master replication ● distributed, replicated “key- value store” ○ block ID ⇒ key ○ block contents ⇒ value DAX client library DBMS DAX
  9. 9. Baseline: Quorum Reads and Writes ● Block replication: N times across DAX servers ○ servers and copies cover all data center ● Reads and writes ○ Read: request N copies, return after 1 ≤ R ≤ N ○ Write: request N copies, return after 1 ≤ W ≤ N ● R = W = N/2 +1 ○ replicas distributed across data centers ○ write quorum includes at least one remote replica
  10. 10. Local Read and Write Latencies ●N = 3, in a single data center ●Consistency penalty: waiting for more replicas is slower
  11. 11. Wide-Area Read and Write Latencies ●N = 3, copies in Oregon and Virginia ●Much larger consistency penalty!
  12. 12. Goal of DAX ● Achieve the performance of R=1/W=1 while maintaining consistency, durability, and availability Contributions ● Performance optimization ○ Optimistic I/O - reduce read latency ○ Client-managed durability - hide write latency ● Novel consistency guarantee
  13. 13. Optimistic I/O ● Key observation With R=W=1, most reads do not return stale data ○ Single writer ○ DBMS buffer pool ○ Parallel writes ○ Network topology ● Solution R=W=1, detect stale data, recover from it ○ record data block version numbers; check against record when reading
  14. 14. Client-Managed Durability ● Key observations ○ Transaction semantics dictate when writes must be safe (Durable) and when the DBMS can tolerate unsafe writes ○ Database systems explicitly enforce data durability at necessary points ■ Durable means “replicated W times”
  15. 15. Client-Managed Durability ● DAX has two kinds of writes ○ Data write, without durability guarantee ○ Synchronized write that ensures durability of previous writes ● DBMS issues the synchronized write only when its transaction protocols demand it ● Time between data write and synchronized write enables latency hiding
  16. 16. Consistency in DAX ● Key idea: make DAX look like an unreplicated storage system with explicit synchronization points for updates ○ DAX’s clients (DBMS) are designed to work with this model ● Two guarantees: ○ DBMS sees the latest version as long as it is up ○ Exactly one version survives a database failure; it is the latest synchronized version, or later
  17. 17. Consistency Example ●Which write should each read see? ●R1 must see W3 ●R2 can see W1, W2, or W3 ●R3 must see the version seen by R2
  18. 18. Experiment Configurations ●9 DAX servers ●6 replicas distributed in 1 EC2 region (1 zone) 3 EC2 regions r1 r2 r3 r4 r5 DBMS r6 DBMS Virginia California Oregon r1 r2 r3 r4 r5 r6
  19. 19. Throughput with DAX MySQL and DAX in Amazon EC2 TPC-C Workload - 9 DAX Nodes
  20. 20. Summary ● DAX: disaster-tolerant storage for DBMS hosting ○ Scalable in storage capacity, bandwidth and the number of database tenants ● Data replication across data centers ● Optimistic I/O and client-managed durability to reduce request latencies ● DBMS-appropriate consistency guarantee, even across failures

×