Slog: Serializable, Low-Latency, Geo-Replicated Transactions
This newspaper is yesteryear Kun Ren, Dennis Li, together with Daniel Abadi, together with it appeared at VLDB 2019.
This newspaper is nearly providing strict serializability inward geo-replicated databases. Strict serializability implies that all reads within a transaction must run into the value of whatever writes that committed before the transaction began, no affair where that write was performed world-wide. Furthermore, if a transaction, A, begins later (in existent time) transaction B completes, no customer tin run into the number of A without the number of B.
Since a strict serializability organization behaves similar it is running on a unmarried auto processing transactions sequentially, this reduces application code complexity together with bugs. However, strict serializability comes with a cost. Current state-of-the-art geo-replicated systems cannot supply strict serializability alongside depression latency writes together with high transactional throughput.
To accomplish all 3 (strict-serializability, low-latency writes together with high transactional throughput), SLOG uses locality inward access patterns to assign a domicile percentage to each information granule. Reads together with writes to nearby information occur rapidly, without cross-region communication. However, reads together with writes to remote data, together with transactions that access information from multiple regions (i.e., multi-home transactions), must pay cross-region communication costs. Nonetheless, SLOG uses a deterministic architecture to motion most of this communication exterior of conflict boundaries, enabling these transactions to last processed at high throughput. More specifically, SLOG relies on deterministic processing to avoid 2 stage commit. Once all parties concord to the plan, processing occurs (mostly) independently on each node, with the organization relying on the plan's determinism inward guild to avoid replica divergence.
Unfortunately, inward guild to practise a deterministic excogitation of execution, to a greater extent than cognition nearly the transaction is needed prior to processing it relative to traditional nondeterministic systems. Most importantly, the entire transaction (information regarding which information volition last accessed yesteryear the transaction) must last introduce during this planning process.
SLOG borrows the deterministic architecture from Calvin, together with is implemented leveraging the opened upward source Calvin codebase. However, SLOG improves on Calvin inward the next ways. In Calvin, every transaction, no affair where it originates from, is sequenced yesteryear a global Paxos process. This enables Calvin to bring consummate cognition of the input to the organization piece planning how a batch of transactions volition last executed. Of course, this comes at the terms of requiring every transaction to pay the cross-region latency to piece of work Paxos across regions. SLOG removes the global Paxos procedure inward guild to cut back latency, only this causes unawareness of transactions submitted to replicas located inward dissimilar regions during the planning of transaction processing. We volition run into how SLOG coordinates the transactions, classifying them equally single-home together with multi-home, with equally footling communication equally possible.
In my summary below I work many sentences lifted from the paper. The newspaper is good written, together with I wouldn't last able to amend on many of these explanations.
Each percentage maintains a local input log which is implemented via Paxos across its servers. This local log solely contains transactions that are expected to modify information mastered at that region. This input log is sent to all other regions inward batches. Each batch is labeled with a sequence number, together with the other regions work this sequence number to ensure that they bring non missed whatever batches from that region. Regions work deterministic transaction processing to replay the local log from other regions. By continuously replaying local logs from other regions, the organization is able to back upward local snapshot reads of information mastered at other regions at whatever desired bespeak inward the versioned history.
All 3 batches seem inward the global log of all 3 regions. However, the guild inward which these batches seem inward the 3 respective global logs is different. The solely guarantee is that 1-2 volition seem later 1-1, since they originated from the same region. If all transactions are single-home, together with so it is guaranteed that each region's local log volition access a disjoint laid of database organization granules (i.e., transactions across local logs practise non conflict with each other). Therefore, the express flat to which the global logs are ordered differently across dissimilar regions volition non crusade replica divergence.
This beingness a deterministic organization ensures that all information progress through the same sequence of updates at every replica, without runtime coordination. Since domicile metadata is purpose of the information granule, the metadata is updated at the same bespeak within the sequence of updates of that granule at every region. Therefore, whatever assumed single-home transaction that is non genuinely single-home volition last exposed equally non-single-home independently at each percentage (i.e., each percentage volition independently, without coordination, let on that it is non single-home, together with volition all concord to abort the transaction without whatever cross-region communication). The transaction is together with so restarted equally a multi-home transaction. Similarly, if an assumed single-home transaction is indeed single-home, only the assumed domicile is incorrect, all regions volition run into the wrong domicile together with counter notation together with independently concord to abort the transaction.
The representative inward the figure assumes that the code for the multihome transaction is already disseminated to the regions, together with it solely shows the dissemination of the LockOnlyTxn to the regions. At Region 0, InsertIntoLocalLog(T2) is called later it has placed single-home T1 into its local log. It thus places its generated LockOnlyTxn for T2 later T1. InsertIntoLocalLog(T2) is called at Region 1 betwixt placing unmarried domicile transactions T3 together with T4 into its local log together with thus places the LockOnlyTxn for T2 it generates there. T2's LockOnlyTxns are ordered differently at each percentage is non problematic since LockOnlyTxns ever access disjoint information together with thus commute.
SLOG's deterministic locking scheme acquires all locks prior to processing a transaction together with releases all locks later commit. Thus it is a shape of two-phase locking (2PL). In whatever schedule produced yesteryear a 2PL implementation, if locks are held until later the transaction commits, together with all reads read the value of the most recent write to that information item, together with so the resulting schedule is strictly serializable.
The work of a global log for multi-home transaction ordering was an interesting bespeak of give-and-take inward our Zoom reading group. We discussed whether it could last possible to guild the multi-home transactions yesteryear other means, say using version vectors included inward their metadata. The global log provides a fundamental bespeak which increases latency, equally nosotros volition run into inward the latency graphs inward the evaluation.
However, caution is required equally this representative demonstrates: Region 2 places the local log from percentage 0 that contains T3new before the local log entry from percentage 1 that contains T2. Thus, it sees a dissimilar series order: T1, T3, T2. This leads to potential replica divergence. The counter purpose of the metadata is used to circumvent this danger. Prior to requesting a lock on a granule, SLOG compares the counter that was written into the transaction metadata yesteryear the LookupMaster at the percentage the transaction was submitted to with the electrical flow counter inward storage at that region. If the counter is likewise low, it tin last certainly that the LookupMaster that annotated the transaction had out of appointment mastership information, together with the transaction is similar a shot aborted (every percentage volition independently come upward to this same conclusion). If the counter is likewise high, the transaction blocks until the percentage has processed a number of remaster requests for that information granule equal to the difference betwixt the counters.
We tin run into that SLOG is non able to practise equally high throughput equally Calvin, because Calvin uses a unmarried bespeak for serialization together with does non bring aborts ever. On the other hand, due to just the same reason, nosotros run into that SLOG improves the latency of Calvin inward WAN. Notice inward the latency graph that for 100% multi-home transactions, SLOG latency degrades to that of Calvin.
Here SLOG is compared with Spanner. One bespeak to give-up the ghost on inward heed is that Spanner supports SQL-API together with to a greater extent than full general transactions, whereas SLOG is restricted to work a deterministic architecture.
Here is the newspaper presentation video from our Zoom reading group.
This newspaper is nearly providing strict serializability inward geo-replicated databases. Strict serializability implies that all reads within a transaction must run into the value of whatever writes that committed before the transaction began, no affair where that write was performed world-wide. Furthermore, if a transaction, A, begins later (in existent time) transaction B completes, no customer tin run into the number of A without the number of B.
Since a strict serializability organization behaves similar it is running on a unmarried auto processing transactions sequentially, this reduces application code complexity together with bugs. However, strict serializability comes with a cost. Current state-of-the-art geo-replicated systems cannot supply strict serializability alongside depression latency writes together with high transactional throughput.
To accomplish all 3 (strict-serializability, low-latency writes together with high transactional throughput), SLOG uses locality inward access patterns to assign a domicile percentage to each information granule. Reads together with writes to nearby information occur rapidly, without cross-region communication. However, reads together with writes to remote data, together with transactions that access information from multiple regions (i.e., multi-home transactions), must pay cross-region communication costs. Nonetheless, SLOG uses a deterministic architecture to motion most of this communication exterior of conflict boundaries, enabling these transactions to last processed at high throughput. More specifically, SLOG relies on deterministic processing to avoid 2 stage commit. Once all parties concord to the plan, processing occurs (mostly) independently on each node, with the organization relying on the plan's determinism inward guild to avoid replica divergence.
Unfortunately, inward guild to practise a deterministic excogitation of execution, to a greater extent than cognition nearly the transaction is needed prior to processing it relative to traditional nondeterministic systems. Most importantly, the entire transaction (information regarding which information volition last accessed yesteryear the transaction) must last introduce during this planning process.
SLOG borrows the deterministic architecture from Calvin, together with is implemented leveraging the opened upward source Calvin codebase. However, SLOG improves on Calvin inward the next ways. In Calvin, every transaction, no affair where it originates from, is sequenced yesteryear a global Paxos process. This enables Calvin to bring consummate cognition of the input to the organization piece planning how a batch of transactions volition last executed. Of course, this comes at the terms of requiring every transaction to pay the cross-region latency to piece of work Paxos across regions. SLOG removes the global Paxos procedure inward guild to cut back latency, only this causes unawareness of transactions submitted to replicas located inward dissimilar regions during the planning of transaction processing. We volition run into how SLOG coordinates the transactions, classifying them equally single-home together with multi-home, with equally footling communication equally possible.
In my summary below I work many sentences lifted from the paper. The newspaper is good written, together with I wouldn't last able to amend on many of these explanations.
SLOG overview
SLOG uses a master-oriented architecture, where every information exceptional is mastered at a unmarried "home" replica. Writes together with linearizable reads of a information exceptional must last directed to its domicile replica. Each SLOG percentage contains a number of servers over which information stored at that percentage is partitioned (and replicated). Some of this information is mastered yesteryear that percentage (it is the domicile percentage for that data) together with the residue is a replica of information from a dissimilar domicile region.Each percentage maintains a local input log which is implemented via Paxos across its servers. This local log solely contains transactions that are expected to modify information mastered at that region. This input log is sent to all other regions inward batches. Each batch is labeled with a sequence number, together with the other regions work this sequence number to ensure that they bring non missed whatever batches from that region. Regions work deterministic transaction processing to replay the local log from other regions. By continuously replaying local logs from other regions, the organization is able to back upward local snapshot reads of information mastered at other regions at whatever desired bespeak inward the versioned history.
Single-home transactions
- When a percentage receives a transaction to process, it sends a message to its Lookup Master to obtain its cached value for the domicile of each granule accessed yesteryear the transaction. The returned locations are stored within the transaction code. If every granule is currently mapped to the same domicile region, the transaction becomes initially assumed to last a single-home transaction, together with is shipped to that region.
- Once the (assumed) single-home transaction reaches its domicile region, it is appended into an in-memory batch of transactional input on the server at which it arrives, together with this server appends this batch to that region's input log via Paxos.
- A dissever Paxos procedure interleaves batches from the local log with batches from the local logs that are received from other regions inward guild to practise that region's persuasion of the global log.
All 3 batches seem inward the global log of all 3 regions. However, the guild inward which these batches seem inward the 3 respective global logs is different. The solely guarantee is that 1-2 volition seem later 1-1, since they originated from the same region. If all transactions are single-home, together with so it is guaranteed that each region's local log volition access a disjoint laid of database organization granules (i.e., transactions across local logs practise non conflict with each other). Therefore, the express flat to which the global logs are ordered differently across dissimilar regions volition non crusade replica divergence.
This beingness a deterministic organization ensures that all information progress through the same sequence of updates at every replica, without runtime coordination. Since domicile metadata is purpose of the information granule, the metadata is updated at the same bespeak within the sequence of updates of that granule at every region. Therefore, whatever assumed single-home transaction that is non genuinely single-home volition last exposed equally non-single-home independently at each percentage (i.e., each percentage volition independently, without coordination, let on that it is non single-home, together with volition all concord to abort the transaction without whatever cross-region communication). The transaction is together with so restarted equally a multi-home transaction. Similarly, if an assumed single-home transaction is indeed single-home, only the assumed domicile is incorrect, all regions volition run into the wrong domicile together with counter notation together with independently concord to abort the transaction.
Multi-home transactions
- All multi-home transactions, no affair where they originate, must last ordered with honor to each other. For this SLOG employs a global log for ordering the multihome transactions with honor to other multi-home transactions together with sends them to the regions where they are ordered with honor to single-home transactions.
- A multi-home transaction exists inward several dissimilar locations inward a region's global log. There volition last an entry containing the code for that transaction, together with and so separately volition come upward several LockOnlyTxns entries, i from each percentage that houses information expected to last accessed yesteryear that transaction. The code tin showtime to last processed when it arrives, only it volition block whenever it tries to access information for which the corresponding LockOnlyTxn has soundless to complete.
- LockOnlyTxns be to specify how the multi-home transaction should last ordered relative to single-home transactions at that region. Depending on where the LockOnlyTxn gets placed inward the local log of that region, it volition ensure that the multi-home transaction volition let on the writes of all transactions before than it inward the local log, together with none of the writes from transactions later it. When the percentage has all the locks inward its log, it executes the code.
The representative inward the figure assumes that the code for the multihome transaction is already disseminated to the regions, together with it solely shows the dissemination of the LockOnlyTxn to the regions. At Region 0, InsertIntoLocalLog(T2) is called later it has placed single-home T1 into its local log. It thus places its generated LockOnlyTxn for T2 later T1. InsertIntoLocalLog(T2) is called at Region 1 betwixt placing unmarried domicile transactions T3 together with T4 into its local log together with thus places the LockOnlyTxn for T2 it generates there. T2's LockOnlyTxns are ordered differently at each percentage is non problematic since LockOnlyTxns ever access disjoint information together with thus commute.
SLOG's deterministic locking scheme acquires all locks prior to processing a transaction together with releases all locks later commit. Thus it is a shape of two-phase locking (2PL). In whatever schedule produced yesteryear a 2PL implementation, if locks are held until later the transaction commits, together with all reads read the value of the most recent write to that information item, together with so the resulting schedule is strictly serializable.
The work of a global log for multi-home transaction ordering was an interesting bespeak of give-and-take inward our Zoom reading group. We discussed whether it could last possible to guild the multi-home transactions yesteryear other means, say using version vectors included inward their metadata. The global log provides a fundamental bespeak which increases latency, equally nosotros volition run into inward the latency graphs inward the evaluation.
Dynamic remastering
SLOG does non require whatever remastering of information to procedure multi-home transactions, only does perform dynamic information remastering equally access patterns alter over time. A remaster asking updates metadata of a unmarried information granule together with is thus a single-home transaction. The asking is sent to the domicile percentage for that granule, which volition insert the asking inward its local log, which volition eventually crusade the asking to seem inward the global logs of all regions. When each percentage processes this asking inward its global log, it updates the granule metadata. The Lookup Master of that percentage is also asynchronously updated to reverberate the novel mastership information.
However, caution is required equally this representative demonstrates: Region 2 places the local log from percentage 0 that contains T3new before the local log entry from percentage 1 that contains T2. Thus, it sees a dissimilar series order: T1, T3, T2. This leads to potential replica divergence. The counter purpose of the metadata is used to circumvent this danger. Prior to requesting a lock on a granule, SLOG compares the counter that was written into the transaction metadata yesteryear the LookupMaster at the percentage the transaction was submitted to with the electrical flow counter inward storage at that region. If the counter is likewise low, it tin last certainly that the LookupMaster that annotated the transaction had out of appointment mastership information, together with the transaction is similar a shot aborted (every percentage volition independently come upward to this same conclusion). If the counter is likewise high, the transaction blocks until the percentage has processed a number of remaster requests for that information granule equal to the difference betwixt the counters.
Evaluation
Since SLOG relies on deterministic processing, it was implemented over the opened upward source Calvin codebase [2], yesteryear adding the 2 Paxos logs per percentage together with the Lookup Master index, together with processing transactions equally described above.
We tin run into that SLOG is non able to practise equally high throughput equally Calvin, because Calvin uses a unmarried bespeak for serialization together with does non bring aborts ever. On the other hand, due to just the same reason, nosotros run into that SLOG improves the latency of Calvin inward WAN. Notice inward the latency graph that for 100% multi-home transactions, SLOG latency degrades to that of Calvin.
Here SLOG is compared with Spanner. One bespeak to give-up the ghost on inward heed is that Spanner supports SQL-API together with to a greater extent than full general transactions, whereas SLOG is restricted to work a deterministic architecture.
Here is the newspaper presentation video from our Zoom reading group.
0 Response to "Slog: Serializable, Low-Latency, Geo-Replicated Transactions"
Post a Comment