THE PIT AND THE PENDULUM - NUS Computer Science Research … · 2019. 1. 15. · THE PIT AND THE...

Lorenzo Alvisi

THE PIT AND THE PENDULUM

Performance

A CLASSIC HORROR STORY

Database Programmer

Ease of

Programming

Database Programmer

Ease of

ProgrammingPerformance

Ease of


Database Programmer

CONCURRENCY Pierre Franc Lamy Young girl on a balcony (1911)

Carlo Carrà Concurrency, Woman on a balcony (1912)

ACID TRANSACTIONS:SIMPLE AND POWERFUL

ACID Txn

z := x+y

y++

x := 0

Txn

Txn

Txn

Txn

Txn

Txn

TxnTxn

Txn

Txn

Txn

Txn

Txn

Atomicity

Consistency

Isolation

Durability

PERFORMANCE VIA WEAKER ISOLATION GUARANTEES

Database System Default Isolation Strongest Isolation

MySQL Cluster Read Committed Read Committed

SAP HANA Read Committed Snapshot Isolation

Google Spanner Serializability Serializability

VoltDB Serializability Serializability

Oracle 12C Read Committed Snapshot Isolation

MemSQL Read Committed Read Committed

SQL Server Read Committed Serializability

Postgres Read Committed Serializability

ANSI SQL-92 ISOLATION LEVELS

• Defined in terms of three phenomena that can lead to violations of serializability

• Motivated by weakening locking implementations of serializability

• Designed to be implementation independent (greater flexibility/better performance)

Isolation LevelProscribed PhenomenaDirty Read

Fuzzy Read Phantom

Read Uncommitted

Read Committed

Repeatable Read

(Anomaly) Serializable

DIRTY READS

R(A)

R(B)

R(A)

W(A)

T1 T2

BEGIN

BEGIN

COMMIT

ABORT

A = 5

A = 12

A = 12W(A)

W(B)

A = 15

‣ T1 modifies a data item.

‣ T2 reads that data item before T1

commits or aborts.

‣ If T1 then aborts, T2 has read a data item that was never committed and so never really existed.

Root: Write-Read conflict

FUZZY READSA.K.A. NON-REPEATABLE READS

R(A)

R(A)

W(A)

T1 T2

BEGIN

BEGIN

COMMIT

COMMIT

A = 5

A = 10

A = 10

‣ T1 reads a data item.

‣ T2 then modifies or deletes that data item and commits.

‣ If T1 then attempts to reread the item, it receives a modified value or discovers the item was deleted.

Root: Read-Write conflict

THE PHANTOM MENACE

T1 T2

BEGIN

SELECT MAX (salary)FROM players

WHERE team = ‘Juve’

COMMIT

SELECT MAX (salary)FROM players

WHERE team = ‘Juve’

BEGIN

COMMIT

INSERT INTO players (salary = 30M, team = ‘Juve’)

8M

30M

On July 10 2018…

Non-repeatable predicate-based reads

‣ T1 reads a set of data items satisfying <search condition>.

‣ T2 then creates data items that satisfy T1’s <search condition> and commits.

‣ If T1 then repeats its read with the same <search condition>, it gets a different set of data

WHAT’S NOT TO LIKE?

• Ambiguous descriptions of proscribed behaviors

Berenson et al, SIGMOD ‘95

R(A)

R(B)

R(A)

W(A)

T1 T2

BEGIN

BEGIN

COMMIT

ABORT

A = 5

A = 12

A = 12W(A)

W(B)

A = 15

• Strict Interpretation (prohibits anomaly)‣ A1: W1[X] … R2[X] … (A1 and C2 in any order)

• Broad Interpretation (prohibits phenomenon)‣ P1: W1[X] … R2[X] … ((A1 or C1) and (A2 or C2) in any order)

Dirty Reads

similar distinctions for P2 (NR reads) and P3 (Phantoms)

PHENOMENA OR ANOMALIES?

• Non serializable‣ T2 reads the wrong balance

• Yet fine by Strict Interpretation A1…‣ W1[X] … R2[X] … (A1 and C2 in any order)‣ T1 does not abort!

• but violates Broad Interpretation P1

‣ W1[X] … R2[X] … ((A1 or C1) and (A2 or C2) in any order)

T1 T2

BEGIN BEGIN

COMMIT

COMMIT

R(Y=50)

R(X= 50)

R(X = 10)R(Y = 50)

W(Y = 90)

W(X = 10)

Dirty Reads

PHENOMENA OR ANOMALIES?

• Non serializable‣ T1 reads the wrong balance

• Yet fine by Strict Interpretation A2…‣ R1[X] … W2[X] … C2 … R1[X] … C1

‣ No transaction reads same value twice

• but violates Broad Interpretation P2

‣ R1[X] … W2[X] … ((A1 or C1) and (A2 or C2) in any order)

T1 T2

BEGIN BEGIN

COMMIT

COMMIT

R(Y=90)

R(X= 50)R(X = 50)

R(Y = 50)W(Y = 90)

Non-repeatable Reads

W(X = 10)

ANSI isolation levels should be intended

to proscribe phenomena,

not anomalies

WHAT’S NOT TO LIKE?• ANSI SQL phenomena are weaker than their

locking counterpart

Isolation Level Read Locks Write Locks

Locking Read Uncommitted None Long† write locks

Locking Read Committed

Short* read locks (both) Long write locks

Locking Repeatable Read

Long item locksShort predicate locks Long write locks

Locking Serializable

Long read locks (both) Long write locks

Long†: Released after transaction commitsShort*: Released after operation ends

ANSI P3 should prevent phantoms due to

deletions and updates, not just creations

WHAT’S NOT TO LIKE?• ANSI SQL phenomena are weaker than their

locking counterpart

Isolation Level Read Locks Write Locks

Locking Read Uncommitted None Long† write locks

Locking Read Committed

Short* read locks (both) Long write locks

Locking Repeatable Read

Long item locksShort predicate locks Long write locks

Locking Serializable

Long read locks (both) Long write locks


still

DIRTY WRITES

W(A)

T1 T2

BEGIN

BEGIN

COMMIT

COMMIT

A = 10W(A)

A = 15

Root: Write-Write conflicts

‣ T1 modifies a data item

‣ T2 further modifies that data item before T1 commits or aborts.

‣ Conflicting writes can interleave, violating invariants

B = 10W(B)

W(B) B = 15

ANSI isolation levels should include

phenomenon P0P0: W1[X]…W2[X]…(C1or A1) and (C2 or A2) in any order

ANSI-92 ISOLATION LEVELS, POST CRITIQUE

Locking Isolation Level

Proscribed Phenomena

Read locks on data items and phantoms

Write locks on data items and phantoms

Degree 0 none none Short* write locks

Degree 1 = Locking READ UNCOMMITTED

P0 none Long† write locks

Degree 2 = Locking READ COMMITTED P0, P1 Short read locks Long write locks

Locking REPEATABLE READ P0, P1, P2 Long data-item read locks;

Short phantom read locks Long write locks

Degree 3 = Locking SERIALIZABLE P0, P1, P2, P3 Long read locks Long write locks


AND YET…

• “P0, P1, P2, and P3 are a disguised version of locking”

‣ no implementation independence

‣ Preventing concurrent execution of conflicting operations approach rules out optimistic and multi version implementations

• P0: W1[X] … W2[X] … (C1 or A1)‣ rules out optimistic implementations

‣ similar argument holds for P1, P2. P3

THE RUB• Phenomena expressed through single object histories

• but consistency often involves multiple objects

• Same guarantees for running and committed transactions• but optimistic approaches thrive on the difference

• Definition in terms of objects, not versions • no support for multiversion systems

SNAPSHOT ISOLATION

• T reads from a snapshot of committed values at T’s start time

• T’s own writes are reflected in its snapshot

• When ready to commit, T receives a commit time

• T commits if its updates do not conflict with those of any transaction which committed in the interval between T’s start time and commit time

WRITE SKEW ANOMALY

T1: Change green to red

T2: Change red to green

WRITE SKEW ANOMALY



WRITE SKEW ANOMALY



* *

* *

* *

* *

Serial

or

GENERALIZED ISOLATION DEFINITIONS

• Executions modeled as histories‣ a partial order of read/write operations that respects

order of operations in each transaction ‣ a total order << of object versions created by

committed transactions

Adya et al, SIGMOD ‘95

SERIALIZATION GRAPH• Every history is associated with a Direct

Serialization Graph (DSG)‣ nodes are committed transactions

‣ edges express different types of direct conflicts - write-read - write-write- read-write

‣ edge expresses temporal relation

- start

(anti-dependency)

(dependency)

Tis�! Tj : ci < sj

}Tiww��! Tj

Tiwr��! Tj

Tirw��! Tj

READ UNCOMMITTED

Proscribes P0: W1[X] … W2[X] … (C1 or A1)

Now, proscribes G0: DSG(H) contains a directed cycle consisting exclusively of WW edges

Concurrent transactions can modify the same object (as long as they don’t all commit)

T1 T2ww

ww

STRONGER ISOLATION LEVELS

• No aborted reads‣ T2 cannot read value of aborted T1

• No intermediate reads‣ T2 cannot read value of T1 that T1 then overwrites

• No circularity in DSG graph‣ edges in cycle depend on isolation level

SNAPSHOT ISOLATION

• DSG(H) proscribes:

T1 T2

T1 T2 T3

T2 T3T1

wr<latexit sha1_base64="5lgCNYoEvSuUCWWv76le0GQx+h0=">AAAB3nicdVDLTgJBEOzFF+IL9ehlIjHxtNkVg3qSxItHNK6QAMHZYRYmzD4y06shhLMXDSeN3+PJX/Az/AMH0AM+KumkUlWd6Ro/kUKj47xbmbn5hcWl7HJuZXVtfSO/uXWt41Qx7rFYxqrmU82liLiHAiWvJYrT0Je86vfOxn71list4ugK+wlvhrQTiUAwika6vFOtfMG1nQnI/6Rw+vE6ugGASiv/1mjHLA15hExSreuuk2BzQBUKJvkw10g1Tyjr0Q4fTO4bkj0jtUkQKzMRkok6k6Oh1v3QN8mQYlf/9MbiX149xeC4ORBRkiKP2PShIJUEYzIuS9pCcYaybwhlSpgLCetSRRmaL8mZ6o5dLB26RYf8Jt/VvQP7xHYvnEK5BFNkYQd2YR9cOIIynEMFPGAQwAM8wbNFrXvr0RpNoxnra2cbZmC9fALyLIv6</latexit><latexit sha1_base64="wmU8E1cA4jstcm221QNSh70es60=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV0xqJUkNpZoXCEBQmaHWZgw+8jMXQ0h1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza0rHSWKcZdFMlI1j2ouRchdFCh5LVacBp7kVa93Ovar11xpEYWX2I95M6CdUPiCUTTSxY1qZXNOwZ6A/E9yJ+/Po0b+46XSyr422hFLAh4ik1TrumPH2BxQhYJJPsw0Es1jynq0wweT+4Zkz0ht4kfKTIhkos7kaKB1P/BMMqDY1T+9sfiXV0/QP2oORBgnyEM2fchPJMGIjMuStlCcoewbQpkS5kLCulRRhuZLMqa6XSiWDpyiTX6T7+rufuG44JzbuXIJpkjDDuxCHhw4hDKcQQVcYODDHTzAo0WtW+veGk2jKetrZxtmYD19AlkqjdY=</latexit><latexit sha1_base64="wmU8E1cA4jstcm221QNSh70es60=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV0xqJUkNpZoXCEBQmaHWZgw+8jMXQ0h1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza0rHSWKcZdFMlI1j2ouRchdFCh5LVacBp7kVa93Ovar11xpEYWX2I95M6CdUPiCUTTSxY1qZXNOwZ6A/E9yJ+/Po0b+46XSyr422hFLAh4ik1TrumPH2BxQhYJJPsw0Es1jynq0wweT+4Zkz0ht4kfKTIhkos7kaKB1P/BMMqDY1T+9sfiXV0/QP2oORBgnyEM2fchPJMGIjMuStlCcoewbQpkS5kLCulRRhuZLMqa6XSiWDpyiTX6T7+rufuG44JzbuXIJpkjDDuxCHhw4hDKcQQVcYODDHTzAo0WtW+veGk2jKetrZxtmYD19AlkqjdY=</latexit><latexit sha1_base64="wmU8E1cA4jstcm221QNSh70es60=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV0xqJUkNpZoXCEBQmaHWZgw+8jMXQ0h1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza0rHSWKcZdFMlI1j2ouRchdFCh5LVacBp7kVa93Ovar11xpEYWX2I95M6CdUPiCUTTSxY1qZXNOwZ6A/E9yJ+/Po0b+46XSyr422hFLAh4ik1TrumPH2BxQhYJJPsw0Es1jynq0wweT+4Zkz0ht4kfKTIhkos7kaKB1P/BMMqDY1T+9sfiXV0/QP2oORBgnyEM2fchPJMGIjMuStlCcoewbQpkS5kLCulRRhuZLMqa6XSiWDpyiTX6T7+rufuG44JzbuXIJpkjDDuxCHhw4hDKcQQVcYODDHTzAo0WtW+veGk2jKetrZxtmYD19AlkqjdY=</latexit><latexit sha1_base64="wmU8E1cA4jstcm221QNSh70es60=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV0xqJUkNpZoXCEBQmaHWZgw+8jMXQ0h1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza0rHSWKcZdFMlI1j2ouRchdFCh5LVacBp7kVa93Ovar11xpEYWX2I95M6CdUPiCUTTSxY1qZXNOwZ6A/E9yJ+/Po0b+46XSyr422hFLAh4ik1TrumPH2BxQhYJJPsw0Es1jynq0wweT+4Zkz0ht4kfKTIhkos7kaKB1P/BMMqDY1T+9sfiXV0/QP2oORBgnyEM2fchPJMGIjMuStlCcoewbQpkS5kLCulRRhuZLMqa6XSiWDpyiTX6T7+rufuG44JzbuXIJpkjDDuxCHhw4hDKcQQVcYODDHTzAo0WtW+veGk2jKetrZxtmYD19AlkqjdY=</latexit><latexit sha1_base64="oQz48/yjCuf3H6Z5cROKYh6eUCg=">AAAB3nicdVDLSgMxFL1TX7W+qi7dBIvgashYqboruHFZxbGFtpRMmmlDMw+SO0opXbtRXCl+kr/g35g+XNTHgcDhnBPuPTdIlTRI6aeTW1peWV3Lrxc2Nre2d4q7e3cmyTQXPk9UohsBM0LJWPgoUYlGqgWLAiXqweBy4tfvhTYyiW9xmIp2xHqxDCVnaKWbB90pljyXTkH+JyWYo9YpfrS6Cc8iESNXzJimR1Nsj5hGyZUYF1qZESnjA9YTo+l+Y3JkpS4JE21fjGSqLuRYZMwwCmwyYtg3P72J+JfXzDA8b49knGYoYj4bFGaKYEImZUlXasFRDS1hXEu7IeF9phlHe5KCrU7dcuXUK1Pym3xX90/cC9e7pqVqZX6DPBzAIRyDB2dQhSuogQ8cQniCV3hzmPPoPDsvs2jOmf/ZhwU4718tcIkZ</latexit>


s<latexit sha1_base64="WoQu8beNs9O+s6/rb3O/5y4h/lY=">AAAB3XicdVDLTgJBEOzFF+IL9ehlIjHxtNkVg3qSxItHSFwhAQKzQy9MmH1kZtaEEK5eNHrR+D+e/AU/wz9wAD3go5JOKlXVma7xE8GVdpx3K7OwuLS8kl3Nra1vbG7lt3euVZxKhh6LRSzrPlUoeISe5lpgPZFIQ19gzR9cTPzaDUrF4+hKDxNshbQX8YAzqo1UVe18wbWdKcj/pHD+8frYAYBKO//W7MYsDTHSTFClGq6T6NaISs2ZwHGumSpMKBvQHo6m543JgZG6JIilmUiTqTqXo6FSw9A3yZDqvvrpTcS/vEaqg9PWiEdJqjFis4eCVBAdk0lX0uUSmRZDQyiT3FxIWJ9KyrT5kZyp7tjF0rFbdMhv8l3dO7LPbLfqFMolmCELe7APh+DCCZThEirgAQOEO3iCZ6tj3Vr31sMsmrG+dnZhDtbLJx8Wi3o=</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="3HkhEnNDHb92/BXAbRnIAIrc89M=">AAAB3XicdVDLSgMxFL2pr1pfVZdugkVwNcxYqboruHHZgmMLbamZNNOGZh4kd4RSunWjuFL8JX/BvzF9uKiPA4HDOSfce26QKmnQdT9JbmV1bX0jv1nY2t7Z3SvuH9yZJNNc+DxRiW4GzAglY+GjRCWaqRYsCpRoBMPrqd94ENrIJL7FUSo6EevHMpScoZXqplsseY47A/2flGCBWrf40e4lPItEjFwxY1qem2JnzDRKrsSk0M6MSBkfsr4Yz9ab0BMr9WiYaPtipDN1KcciY0ZRYJMRw4H56U3Fv7xWhuFlZyzjNEMR8/mgMFMUEzrtSntSC45qZAnjWtoNKR8wzTjaixRsddcpV869skt/k+/q/plz5Xh1t1StLG6QhyM4hlPw4AKqcAM18IGDgCd4hTdyTx7JM3mZR3Nk8ecQlkDevwBaS4iZ</latexit>

cycles consisting of write-write or write-read dependencies

a write-read or write-write edge without a start edge

a cycle consisting of write-read/ write-write/start-edges, and a single read-write edge

wr

wr

wr

ww

ww

rw

s

s s

ww

ALL’S WELL? ALL’S WELL?

T1 T2

BEGINBEGIN

COMMITCOMMIT

W(X= 10)

W(Y= 90)

W(Y= 50)

W(X= 80)

T1 T2

BEGINBEGIN

COMMITCOMMIT

R(Y= 50)R(X = 10)

W(X = 90)

W(Y=80)

TheoryConflict Serializability

MySQL Community Edition

Multiversion SerializabilityRococo

Anomaly SerializabilityOracle 12C

WHY THE CONFUSION?

Semantic gap between how isolation guarantees are defined and how they are experienced by application programmers

Definiti Percepti

In terms of histories and operations

invisible

Properties of

≠

How isolation properties

are formalized

How applications perceive them

DON’T KNOW MUCH ABOUT HISTORIES

• Applications experience isolation guarantees as contracts specifying which values they can read (i.e. which states they can observe)

• Low-level read/write operations are instead

‣ invisible to applications

‣ encourage system-specific definitions

A STATE-BASED DEFINITION

• Isolation guarantees as constraints on read states‣ states consistent with what the application observed

Crooks et al, 2017

R2(Y0) R2(Z1)X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

A STATE-BASED DEFINITIONCrooks et al, 2017

• Isolation guarantees as constraints on read states‣ states consistent with what the application observed

• Each transaction is associated with a set of candidate read states

• At commit, transaction must pass a commit test that narrows down which read states are acceptable

R2(Y0) R2(Z1)X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

A STATE-BASED DEFINITION

A storage system guarantees a specific isolation level I if it can produce an execution (a sequence of atomic state transitions) that

• is consistent with every transaction’s read states

• satisfies the commit test for I, for every transaction

Crooks et al, 2017

If no read state prove suitable for some transaction, then I does not hold

PARENT STATES AND COMPLETE STATES

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

X: X1Y: Y2Z: Z1

T0 T2 TSe


• Parent state sp of T: state from which T commits

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

X: X1Y: Y2Z: Z1

T0 T2 TSe



• Complete state for T: a read state for all read ops in T

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

X: X1Y: Y2Z: Z1

T0 T2 T

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

T0 T2 TR(Z1)R(Y1)

Se



• Complete state for T: a read state for all read ops in T

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

X: X1Y: Y2Z: Z1

T0 T2 T

X: X0Y: Y0Z: Z0

X: X0Y: Y1Z: Z1

X: X0Y: Y2Z: Z1

T0 T2 TR(Z1)R(Y1)

Se

SERIALIZABILITY

SERIALIZABILITY

• Given a set of transactions T and their read states, serializability holds if there exists execution e such that for all T in T

COMPLETEe,T (sp)

SNAPSHOT ISOLATION

T1 T2

T1 T2 T3

T2 T3T1

ww<latexit sha1_base64="9Im5UUolgAN5RROfcG25irxKxTU=">AAAB3nicdVDLTgJBEOzFF+IL9ehlIjHxtNlVg3qSxItHNK6QAMHZYRYmzD4y0yshhLMXDSeN3+PJX/Az/AMH0AM+KumkUlWd6Ro/kUKj47xbmbn5hcWl7HJuZXVtfSO/uXWj41Qx7rFYxqrqU82liLiHAiWvJorT0Je84nfPx37ljist4uga+wlvhLQdiUAwika66vWa+YJrOxOQ/0nh7ON1dAsA5Wb+rd6KWRryCJmkWtdcJ8HGgCoUTPJhrp5qnlDWpW0+mNw3JHtGapEgVmYiJBN1JkdDrfuhb5IhxY7+6Y3Fv7xaisFJYyCiJEUeselDQSoJxmRclrSE4gxl3xDKlDAXEtahijI0X5Iz1R37sHjkHjrkN/mu7h3Yp7Z76RRKRZgiCzuwC/vgwjGU4ALK4AGDAB7gCZ4tat1bj9ZoGs1YXzvbMAPr5RP5iYv/</latexit><latexit sha1_base64="gXwapw3M6Cp4F16cVswLZjF6R/Q=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV01qJUkNpZoXCEBQmaHWZgw+8jMXQkh1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza1rHSWKcZdFMlJVj2ouRchdFCh5NVacBp7kFa97NvYrN1xpEYVX2I95I6DtUPiCUTTSZa/XzOacgj0B+Z/kTt+fR/X8x0u5mX2ttyKWBDxEJqnWNceOsTGgCgWTfJipJ5rHlHVpmw8m9w3JnpFaxI+UmRDJRJ3J0UDrfuCZZECxo396Y/Evr5agf9wYiDBOkIds+pCfSIIRGZclLaE4Q9k3hDIlzIWEdaiiDM2XZEx1u3BQPHQObPKbfFd39wsnBefCzpWKMEUadmAX8uDAEZTgHMrgAgMf7uABHi1q3Vr31mgaTVlfO9swA+vpE2CHjds=</latexit><latexit sha1_base64="gXwapw3M6Cp4F16cVswLZjF6R/Q=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV01qJUkNpZoXCEBQmaHWZgw+8jMXQkh1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza1rHSWKcZdFMlJVj2ouRchdFCh5NVacBp7kFa97NvYrN1xpEYVX2I95I6DtUPiCUTTSZa/XzOacgj0B+Z/kTt+fR/X8x0u5mX2ttyKWBDxEJqnWNceOsTGgCgWTfJipJ5rHlHVpmw8m9w3JnpFaxI+UmRDJRJ3J0UDrfuCZZECxo396Y/Evr5agf9wYiDBOkIds+pCfSIIRGZclLaE4Q9k3hDIlzIWEdaiiDM2XZEx1u3BQPHQObPKbfFd39wsnBefCzpWKMEUadmAX8uDAEZTgHMrgAgMf7uABHi1q3Vr31mgaTVlfO9swA+vpE2CHjds=</latexit><latexit sha1_base64="gXwapw3M6Cp4F16cVswLZjF6R/Q=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV01qJUkNpZoXCEBQmaHWZgw+8jMXQkh1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza1rHSWKcZdFMlJVj2ouRchdFCh5NVacBp7kFa97NvYrN1xpEYVX2I95I6DtUPiCUTTSZa/XzOacgj0B+Z/kTt+fR/X8x0u5mX2ttyKWBDxEJqnWNceOsTGgCgWTfJipJ5rHlHVpmw8m9w3JnpFaxI+UmRDJRJ3J0UDrfuCZZECxo396Y/Evr5agf9wYiDBOkIds+pCfSIIRGZclLaE4Q9k3hDIlzIWEdaiiDM2XZEx1u3BQPHQObPKbfFd39wsnBefCzpWKMEUadmAX8uDAEZTgHMrgAgMf7uABHi1q3Vr31mgaTVlfO9swA+vpE2CHjds=</latexit><latexit sha1_base64="gXwapw3M6Cp4F16cVswLZjF6R/Q=">AAAB3nicdVC7TgJBFL2LL8QXamkzkZhQkV01qJUkNpZoXCEBQmaHWZgw+8jMXQkh1DYaKo3fo42/4GdY2DuAFvg4yU1Ozjk3c894sRQabfvNSs3NLywupZczK6tr6xvZza1rHSWKcZdFMlJVj2ouRchdFCh5NVacBp7kFa97NvYrN1xpEYVX2I95I6DtUPiCUTTSZa/XzOacgj0B+Z/kTt+fR/X8x0u5mX2ttyKWBDxEJqnWNceOsTGgCgWTfJipJ5rHlHVpmw8m9w3JnpFaxI+UmRDJRJ3J0UDrfuCZZECxo396Y/Evr5agf9wYiDBOkIds+pCfSIIRGZclLaE4Q9k3hDIlzIWEdaiiDM2XZEx1u3BQPHQObPKbfFd39wsnBefCzpWKMEUadmAX8uDAEZTgHMrgAgMf7uABHi1q3Vr31mgaTVlfO9swA+vpE2CHjds=</latexit><latexit sha1_base64="loY2TxzbvySFTQbK9jPKOmw3ar0=">AAAB3nicdVDLSgMxFL1TX7W+qi7dBIvgashYqboruHFZxbGFtpRMmmlDMw+SO5ZSunajuFL8JH/BvzF9uPB1IHA454R7zw1SJQ1S+uHklpZXVtfy64WNza3tneLu3p1JMs2FzxOV6EbAjFAyFj5KVKKRasGiQIl6MLic+vV7oY1M4lscpaIdsV4sQ8kZWulmOOwUS55LZyD/kxIsUOsU31vdhGeRiJErZkzToym2x0yj5EpMCq3MiJTxAeuJ8Wy/CTmyUpeEibYvRjJTv+VYZMwoCmwyYtg3P72p+JfXzDA8b49lnGYoYj4fFGaKYEKmZUlXasFRjSxhXEu7IeF9phlHe5KCrU7dcuXUK1Pym3xV90/cC9e7pqVqZXGDPBzAIRyDB2dQhSuogQ8cQniEF3h1mPPgPDnP82jOWfzZh29w3j4BNM2JHg==</latexit>



s<latexit sha1_base64="WoQu8beNs9O+s6/rb3O/5y4h/lY=">AAAB3XicdVDLTgJBEOzFF+IL9ehlIjHxtNkVg3qSxItHSFwhAQKzQy9MmH1kZtaEEK5eNHrR+D+e/AU/wz9wAD3go5JOKlXVma7xE8GVdpx3K7OwuLS8kl3Nra1vbG7lt3euVZxKhh6LRSzrPlUoeISe5lpgPZFIQ19gzR9cTPzaDUrF4+hKDxNshbQX8YAzqo1UVe18wbWdKcj/pHD+8frYAYBKO//W7MYsDTHSTFClGq6T6NaISs2ZwHGumSpMKBvQHo6m543JgZG6JIilmUiTqTqXo6FSw9A3yZDqvvrpTcS/vEaqg9PWiEdJqjFis4eCVBAdk0lX0uUSmRZDQyiT3FxIWJ9KyrT5kZyp7tjF0rFbdMhv8l3dO7LPbLfqFMolmCELe7APh+DCCZThEirgAQOEO3iCZ6tj3Vr31sMsmrG+dnZhDtbLJx8Wi3o=</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="p3L8L4+zcvVyUZH/FKE5E7jri7s=">AAAB3XicdVC7TgJBFL2LL8QXamkzkZhQbXbFoFaS2FhC4goJEJwdLjBh9pGZWRNCaG002mj8H238BT/Dwt4BtMDHSW5ycs65mXvGjwVX2nHerNTc/MLiUno5s7K6tr6R3dy6UFEiGXosEpGs+VSh4CF6mmuBtVgiDXyBVb9/OvarVygVj8JzPYixGdBuyDucUW2kimplc67tTED+J7mT9+f7Rv7jpdzKvjbaEUsCDDUTVKm668S6OaRScyZwlGkkCmPK+rSLw8l5I7JnpDbpRNJMqMlEncnRQKlB4JtkQHVP/fTG4l9ePdGdo+aQh3GiMWTThzqJIDoi466kzSUyLQaGUCa5uZCwHpWUafMjGVPdsQvFA7fgkN/ku7q3bx/bbsXJlYowRRp2YBfy4MIhlOAMyuABA4QbeIBH69K6tm6tu2k0ZX3tbMMMrKdPhgWNVg==</latexit><latexit sha1_base64="3HkhEnNDHb92/BXAbRnIAIrc89M=">AAAB3XicdVDLSgMxFL2pr1pfVZdugkVwNcxYqboruHHZgmMLbamZNNOGZh4kd4RSunWjuFL8JX/BvzF9uKiPA4HDOSfce26QKmnQdT9JbmV1bX0jv1nY2t7Z3SvuH9yZJNNc+DxRiW4GzAglY+GjRCWaqRYsCpRoBMPrqd94ENrIJL7FUSo6EevHMpScoZXqplsseY47A/2flGCBWrf40e4lPItEjFwxY1qem2JnzDRKrsSk0M6MSBkfsr4Yz9ab0BMr9WiYaPtipDN1KcciY0ZRYJMRw4H56U3Fv7xWhuFlZyzjNEMR8/mgMFMUEzrtSntSC45qZAnjWtoNKR8wzTjaixRsddcpV869skt/k+/q/plz5Xh1t1StLG6QhyM4hlPw4AKqcAM18IGDgCd4hTdyTx7JM3mZR3Nk8ecQlkDevwBaS4iZ</latexit>

wr

wr

wr

ww

ww

rw

s

s s

• DSG(H) proscribes:

SNAPSHOT ISOLATION

• Given a set of transactions T and their read states, snapshot isolation holds if there exists execution e such that for all T in T

COMPLETE9s 2 Se. ^ e,T (s)

SNAPSHOT ISOLATION

• Given a set of transactions T and their read states, snapshot isolation holds if there exists execution e such that for all T in T

COMPLETE9s 2 Se. ^ e,T (s)

�(s, sp) WT\ = ;^( )

Read-Uncommitteddirty reads: one transaction may see uncommitted state of another transaction

Read-Committedno dirty reads or writes, but allows for non-repeatable reads

Repeatable Readsnon-repeatable range reads

It-That-Shall-Not-Be-Nameddirty writes - transaction modifies item previously modified by undecided transaction

Snapshot Isolationnone of the above, but write skew

PERFORMANCE VIA WEAKER ISOLATION GUARANTEES

Basically Available, Soft state, Eventually consistentBASE

Transaction GuaranteesBASE Storage (e.g. put, get)

Implement Consistency

Storage Interface

Basically Available, Soft state, Eventually consistent

ACID Storage

Application

BASE

Custom code for better performance

Complexity gets quickly out of control

A CLASSIC HORROR STORY

Database Programmer

Ease of


Help!

Transfer

c ≥ $10?

c := c-$10

s := s+$10Transfer

c ≥ $10?

c := c-$10

s := s+$10

MORE CONCURRENCY !Transfer

Part1c ≥ $10?

c := c-$10

Part2s := s+$10

Transfer

Part1c≥$10?

c := c-$10

Part2s := s+$10

TimeMORE COMPLEXITY!

Read c

Read s

Balance

Transfer

c ≥ $10?

c := c-$10

s := s+$10

MORE COMPLEXITY!Transfer

Read c

Read s

Balance

Part1c ≥ $10?

c := c-$10

Part2s := s+$10

Finer Isolation for one transactionmay affect all transactions!

Performance vs Complexity

Better Performance

More Interleavings

Greater Complexity

Vilfredo Pareto

NOT ALL TRANSACTIONS ARE CREATED EQUAL

• Many transactions are not run frequently

• Many transactions are lightweight

20% of the causesaccount for

80% of the effects


Better Performance

More Interleavings

Greater Complexity


More Interleavingsselectively


More Interleavingsselectively

SALT

+


Use a flexible abstraction

Acid txn

alkaline txn

alkaline txn

BASE transactionalkaline txn

alkaline txn

BASE TRANSACTION

Different Isolation guarantees fordifferent types of transactions

AtomicityDurability}

SALT ISOLATION

To ACID transactions:a single, monolithic ACID transaction

To BASE transactions:a sequence of small ACID transactions

BASE WITH BASE

Fine Isolation granularitybetween BASE transactions

BASE 1

BASE 2

BASEBASE

BASE WITH ACID

ACID

Coarse Isolation granularity to ACID transactions

HOW WELL DOES IT WORK ?

How does the performance of Salt compare

to ACID?How much

programming effort is required to get that performance?

PERFORMANCE GAIN

Late

ncy

(ms)

200

150

100

5

0

250Fusion Ticket

0 1000 2000 3000 4000 5000 6000 7000 8000Throughput (transactions/sec)

ACIDSalt

6.5x

Late

ncy

(ms)

2000

1500

1000

500

0 0 2000 4000 6000 8000 10000 12000

Throughput (transactions/sec)

ACID Salt

TPC-C

6.6X

Configuration• Emulab Cluster (Dell Power Edge R710)• 10 shards, 3-way replicated

Running on MYSQL Cluster

PROGRAMMING EFFORT VS PERFORMANCE

Fusion Ticket

Thro

ughp

ut (t

rans

actio

ns/se

c) 10000

8000

6000

4000

2000

0

Number of BASE-ified transactionsACID 1 2 Raw ops

… …

3

6.5x 7.2x

TPC-C

Thro

ughp

ut (t

rans

actio

ns/se

c)

10000

8000

6000

4000

2000

0

Number of BASE-ified transactions1 2 3 4ACID BASE

12000

Programming BASE transactions is still hard!

AND YET…

ACIDI

ACIDI

ACIDI

ACIDI

ACID

WHAT DO PROGRAMMERS WANT?

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI

ACIDI ACID

I

ACIDI

ACIDI

ACIDI

ACIDI

ACID

WE LOVE ACID

Use a flexible implementation


Use a flexible abstraction

CALLAS

Uniform Abstraction

Ease of Programming

Uniformity

Ease of ProgrammingConservative Mechanism

Uniform Implementation

THE PRICE OF UNIFORMITY

MODULAR CONCURRENCY CONTROL

Cross-Group CC

Implementation

ACID Abstraction

Txn

Txn

Txn

Txn

Txn

Txn

Insight 1: Decouple Abstraction and Implementation

Specializedin-group CC

MODULAR CONCURRENCY CONTROL

Cross-Group CC

Implementation

ACID Abstraction

Txn

Txn

Txn

Txn

Txn

Txn

Insight 2: Separation of Concerns

Limited Scope

Aggressive Optimizations

Specializedin-group CC

CORRECTNESS ACROSS GROUPS

Goal: No dependency cycles over all transactions

1. No cycles within each group

2. No cycles spanning multiple groups Nexus locks

Never conflictfor transactions in the same group

Always conflictfor transactions in different groups

(unless both reading)

Minimal interference with group-specific CC

ISOLATION ACROSS GROUPS

A SUBTLE PROBLEM

Txn 1

W(A)

W(C)

Txn 2

W(A)

W(B) Txn 3

W(B)

W(C)

T1

T3

T2Group 1

Group 2

AA

B

Time

B C

C

TRADITIONAL LOCKING

Txn 1

W(A)

W(C)

Txn 2

W(A)

W(B)

T1

T3

T2

Txn 3

W(B)

W(C)

Timeties depends on to completes before

C1

C2

C3

A

AB

B C

C

A SUBTLE PROBLEM

Txn 1

W(A)

W(C)

Txn 2

W(A)

W(B) Txn 3

W(B)

W(C)

T1

T3

T2Group 1

Group 2

AA

B

Time

B C

C

A REFINEMENTA REFINEMENT

depends onT2 T1

T2 T1 completescannot start before

Nexus Lock Release Order

release its nexus locks

releases its nexus locks

ENFORCE LOCK RELEASE ORDER

Txn 1

W(A)

W(C)

Txn 3

W(B)

W(C)

T1

T3

T2Time

C1

A

C

Txn 2

W(A)

W(B)A B

B

C

ISOLATION WITHIN GROUPS

Increase in-group concurrencywhile maintaining safety

TRANSACTION CHOPPING

Txn 1

R(A)

W(A)

W(B)

Txn 2

W(A)

W(C)

Txn1-1

R(A)

W(A)

Txn 2-2

W(B)

Txn 2-1

W(A)

Txn 2-2

W(C)

Static Analysis

Shasha et al. ’95TRANSACTION CHOPPING

Txn 1

R(A)

W(A)

W(B)

Txn 2

W(A)

W(C)

Shasha et al. ’95


R(A)

W(A)

W(B)

W(A)

W(C)s

ss

c

c

Shasha et al. ’95

No SC cycle among all transactions


R(A)

W(A)

W(B)

s

c W(A)

W(C)

s

+MCC:within each group

Shasha et al. ’95

SELF CONFLICT

Txn 1

W(A)

W(B)

W(C)

Txn 1’

W(A)

W(B)

W(C)

c

c

cW(A)

W(B)

W(C)

s

s

W(A)

W(B)

W(C)

s

s W(A)

W(B)

W(C)

W(A)

W(B)

W(C)

c

SELF CONFLICT

A NEW CC MECHANISM: RUNTIME PIPELINING

c

c

cW(A)

W(B)

W(C)

s

s

W(A)

W(B)

W(C)

s

sW(A)

W(B)

W(C)

W(A)

W(B)

W(C)

RUNTIME PIPELINING

c

c

cW(A)

W(B)

W(C)

s

s

W(A)

W(B)

W(C)

s

sW(A)

W(B)

W(C)

W(A)

W(B)

W(C)

Accurate Detection

RUNTIME PIPELINING

W(C)

R(B)

R(D)

W(A)

T1 T2

R(A)

R(B)

W(B)

W(C) W(C)

R(B)

R(D)

W(A)

T1 T2

R(A)

R(B)

W(B)

W(C)

dep

HOW TO GROUP

tx

txn

txn

txn

txn

txn

txn

tx

tx

tx

tx

txn

txn

txn

txn

Default Group

Group 1Group 2

HOW WELL DOES IT WORK?

This talk…

End-to-endperformance

…but of course there’s more

What are therelative merits

of Callas’ variousoptimizations?

What is the overhead of nexus locks?

What is the effect of using

different groupings?

CALLAS PERFORMANCE

Thro

ughp

ut (t

rans

actio

ns/se

c) 20000

16000

12000

8000

4000

0TPC-C Fusion Ticket 3

MyS

QL

Clus

ter

TC

TC+M

CC

Calla

s

Salt

Salt

Calla

s

TC+M

CC

MyS

QL

Clus

ter

TC

BENEFIT OVER ACID BASELINETh

roug

hput

(tra

nsac

tions

/sec) 20000

16000

12000

8000

4000


MyS

QL

Clus

ter

TC

TC+M

CC

Calla

s

Salt

Salt

Calla

s

TC+M

CC

TCMyS

QL

Clus

ter


Thro

ughp

ut (t

rans

actio

ns/se

c) 20000

16000

12000

8000

4000


MyS

QL

Clus

ter

TC

TC+M

CC

Calla

s

Salt

Salt

Calla

s

TC+M

CC

TCMyS

QL

Clus

ter

TRANSACTION CHOPPING + MCC

Thro

ughp

ut (t

rans

actio

ns/se

c) 20000

16000

12000

8000

4000


MyS

QL

Clus

ter

TC

TC+M

CC

Calla

s

Salt

Salt

Calla

s

TC+M

CC

TCMyS

QL

Clus

ter

CALLAS: MCC + RUNTIME PIPELINING

Thro

ughp

ut (t

rans

actio

ns/se

c) 20000

16000

12000

8000

4000


MyS

QL

Clus

ter

TC

TC+M

CC

Calla

s

Salt

Salt

Calla

s

TC+M

CC

TCMyS

QL

Clus

ter

WITHIN 5% OF SALTTh

roug

hput

(tra

nsac

tions

/sec) 20000

16000

12000

8000

4000


MyS

QL

Clus

ter

SC C

ycle

SC+G

roup

ing

Calla

s

Salt

Salt

Calla

s

SC+G

roup

ing

SC C

ycle

MyS

QL

Clus

ter

CONCLUSION

Cross-Group CC

Implementation

ACID Abstraction

txn

tx

tx

tx

tx

tx

THE PIT AND THE PENDULUM - NUS Computer Science Research … · 2019. 1. 15. · THE PIT AND THE...

Documents

Transcript of THE PIT AND THE PENDULUM - NUS Computer Science Research … · 2019. 1. 15. · THE PIT AND THE...