overview strong consistency traditional approach proposed approach implementation experiments 2
Post on 21-Dec-2015
223 views
TRANSCRIPT
![Page 1: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/1.jpg)
Strongly consistent replication for a bargainKonstantinos Krikellas (Greenplum)
Sameh Elnikety (Microsoft Research)
Zografoula Vagena (University of Southern Denmark)
Orion Hodson (Microsoft Research)
![Page 2: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/2.jpg)
2
Overview
Strong consistency Traditional approach Proposed approach Implementation Experiments
![Page 3: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/3.jpg)
3
Introduction
Standalone database:
Need for higher performance
RequestRequestRequest
DB
![Page 4: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/4.jpg)
4
Replicated databases
Need to keep multiple database instances synchronized
Replication
Middleware
DB
RequestRequestRequest
DB
DB
![Page 5: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/5.jpg)
5
Replication Transparency
The replicated database should ideally provide the same behaviour as the standalone database
Correctness – performance tradeoff
![Page 6: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/6.jpg)
6
Transaction Scenario:
“I have transferred £1m to your account”
Transfer £1m to trader Y’s
account
Transaction is complete
“Let me check it”
No update to your account
“Are you kidding me ???”
Trader X
Trader Y
![Page 7: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/7.jpg)
7
Strong Consistency
After a transaction commits, its results must be visible to all subsequent transactions
Natively provided by centralized systems.
Imposes a performance penalty in replicated systems.
![Page 8: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/8.jpg)
8
Providing Strong Consistency Traditional Way:
Eager update propagation
Our Proposal: Lazy update propagation The replicated DBMS hides
inconsistent replica states from the clients
![Page 9: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/9.jpg)
9
Traditional Implementation Each transaction must be
committed to all replicas in the same global order
Replication
Middleware
COMMIT
COMMIT
COMMITTED
COMMITTED
COMMIT
COMMIT
COMMITTED
COMMITTED
DB
DB
DB
![Page 10: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/10.jpg)
10
Overview of Our Approach
Transaction updates are lazily propagated
Each replica delays the start of incoming transactions until it is synchronized
![Page 11: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/11.jpg)
11
Strong Consistency Provision
The dispatcher keeps the latest database state that is visible to users
Transaction start is delayed until the replica reaches this state
![Page 12: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/12.jpg)
12
How It Works
Dispatcher
Proxy
SQL Serve
r
Certifier
Transaction History
#1 Transaction #2 Transaction #3 Transaction #4 Transaction #5 Transaction #6 Transaction #7 Transaction #8 Transaction
Proxy
SQL Serve
r
Proxy
SQL Serve
r
COM
MIT
COM
MIT
COM
MITTE
D
COM
MIT
TED
WRITESET
v.7
v.6
v.5
v.7
v.8
v.8 BEGIN v.8
v.8
WRIT
ES
T
![Page 13: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/13.jpg)
13
System Properties
Advantages: Replicas are enforced to synchronize The replicated database provides
strong consistency
Drawbacks: Transaction start may be delayed Response times are penalized
![Page 14: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/14.jpg)
14
Exploiting Metadata
Each transaction accesses a subset of the tables comprising the database
Only those tables need to synchronize before the transaction starts
![Page 15: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/15.jpg)
15
Table Versions
Transaction
writeset
Database
version
Table A
version
Table B
version
Table C
version
1 1 1 1
A 2 2 1 1
B,C 3 2 3 3
A,B 4 4 4 3
A,C 5 5 4 5
C 6 5 4 6
C 7 5 4 7
![Page 16: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/16.jpg)
16
Using Table Versions
For each specific transaction, the dispatcher picks a database version that: contains the necessary updates for
the participating tables is smaller than or equal to the latest
database version
![Page 17: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/17.jpg)
17
Example
Database Tables [ A, B, C, D, E, F, G ] Version vector [ 9, 12, 15, 18, 7, 6, 16]
Transaction Tables [ A, E, F ] Version vector [ 9, 7, 6 ]
Use version 9 instead of 18 to synchronize the replica for this transaction
![Page 18: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/18.jpg)
18
Advantages
Shorter response times Better scalability The replicated DBMS still provides
strong consistency
![Page 19: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/19.jpg)
19
Experimental evaluation
Compare the following consistency configurations: Session consistency (SessionC) Strong consistency with:
Eager update propagation (EagerSC)
Lazy update propagation - database version (CoarseSC)
Lazy update propabation - table version (FineSC)
![Page 20: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/20.jpg)
20
Benchmark: TPC-W
Web application (online book store)
Database schema consists of 10 tables
Database size: ~800 MB 13 transaction templates:
Read-only : 9 Update: 4
Update transaction mixes: 5%, 20%, 50%
Metric : transactions per second (TPS)
![Page 21: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/21.jpg)
21
Experimental ResultsTPC-W – 20% Updates
1 2 3 4 5 6 7 80
200
400
600
800
1000
1200
SessionCCoarseSCFineSCEagerSC
Number of replicas
TP
S
![Page 22: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/22.jpg)
22
Experimental ResultsTPC-W – 50% Updates
1 2 3 4 5 6 7 80
100
200
300
400
500
600
700
SessionCCoarseSCFineSCEagerSC
Number of replicas
TP
S
![Page 23: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/23.jpg)
23
In the paper:
Breakdown of replication overhead Full set of results for the three
transaction mixes of the TPC-W benchmark
Use of both throughput and response time as a metric
![Page 24: Overview Strong consistency Traditional approach Proposed approach Implementation Experiments 2](https://reader030.vdocuments.mx/reader030/viewer/2022032522/56649d6a5503460f94a482b1/html5/thumbnails/24.jpg)
24
Conclusion
Strong consistency – an important correctness property
A replicated DBMS can efficiently provide strong consistency by combining: Lazy update propagation Replica synchronization at transaction
start Experimental evaluation.