System-Design | Haihao Sun's Homepage

DDIA Chapter 7 - Transaction

Mon, 07 Oct 2024 00:00:00 +0000

ACID

Atomicity: All or nothing.
Consistency: Invariants must always be true (This is from application perspective).
Isolation: Transactions are executed in a way that their operations do not interfere with each other.
Durability: Once commited, data will not be forgetten.

Weak Isolation Levels

Read Committed (To combat dirty read)

What is dirty read?

Read a data that has not been committed by a transaction.

Implement Read Committed

Lock on write.
Lock on read (performance hit).
Remember old + new value.

Snapshot Isolation and Repeatable Read (To combat nonrepeatable read)

What is nonrepetabale read?

Alice read account A (50).
Alice executes A = A + 10.
Alice executes B = B - 10.
Alice read account B (40).
Sum is 50 + 40 which is not 100.

Snapshot Isoltion

Each transaction sees the snapshot of the database at the start of the transaction.
MVCC(Multi-version concurrency control).

Preventing Lost Updates

Atomic write operations.
Explicit locking.
Automotically deleting lost updates.
Compare and set.
Conflict resolution and replica.

Serializability (To combat phantom)

Write Skew and Phantoms

oncall-rotation in emergency room.

Pattern

select
decide how to continue based on select
INSERT, UPDATE, DELTE

Actual Serial Execution

Every transaction must be small and fast for performance.
It is limited to use cases where the active dataset can fit in memory for performance.
Write throughput must be low enough to be handled on a single CPU core, or else transactions need to be partitioned without requiring cross-partition coordination.
Cross-partition transactions are possible, but there is a hard limit to the extent to which they can be used.

Two-Phase Locking

read: acquire the lock in shared mode, if exclusive exists, wait.
write: acquire the lock in exclusive mode.
read then write: acquire in shared first, then exclusive.
commit or abort: hold until abort or commit

Serializable Snapshot Isolation (SSI)

Goal of SSI: full serializability with small perf penalty compared to snapshot isolation.
Used in single-node (PostgreSQL 9.1) and distributed, may become the new default.

Pessimistic versus optimistic concurrency control

2PL is pessimistic
SSI is optimistic: When a transaction wants to commit, the database checks isolation violations
If there is enough spare capacity, and if contention between transactions is not too high, optimistic concurrency control techniques perform better
On top of snapshot isolation, SSI adds an algorithm for detecting serialization conflicts among writes and determining which transactions to abort.

Decisions based on an outdated premise A premise is a fact that was true at the beginning of the transaction. How does the database know if a query result might have changed?

Detecting stale MVCC reads

The database needs to track when a transaction ignores another transaction’s writes due to MVCC visibility rules.
Check any of the ignored writes has been committed and abort if so.
Wait until committing because read-only won’t write skew, and other write transactions might be aborted.
Key is to avoid unnecessary aborts.

Detecting writes that affect prior reads

DB track ephemeral information about transactions reading data on index, or at the table level.
When a transaction writes, notify existing reader of that data
Check other writes commit when commit reader.
(Question: why not notify existing reader when committing the other writer transaction?)

Performance of serializable snapshot isolation

The rate of aborts significantly affects the overall performance of SSI. So SSI requires short read-write transactions, but it’s less sensitive to slow transactions than two-phase locking or serial execution.

source:

DDIA Chapter 6 - Partition

Sun, 06 Oct 2024 00:00:00 +0000

Two types of partition techniques

Key Range Partition

How: [a-c], [d-e], …
Pros: Efficient for range query.
Cons: Hot spot.

Hash Partition

How: hash first, then use range.
Pros: Distribute load evenly.
Cons: Range query is inefficient.

Hybrid

How: one part -> partition, the other part -> sort order.

Partitioning Secondary Indexes

Partitioning Secondary Indexes by Document

Database can perform indexing automatically.
Note: in KV-only DB, application level secondary indexing is prone to inconsistency.
Each partition maintains its own secondary indexes.
A.K.A. local index.
Need to send the query to all partitions, and combine all the results you get back (scatter/gather).
Read queries are expensive, and prone to latency amplification. But widely used.
Recommend structure the partitioning scheme so that secondary index queries can be served from a single partition.

Partitioning Secondary Indexes by Term

A global index must also be partitioned (term-partitioned).
Partition the index by the term itself, or using a hash of the term.
Pro: more efficient read (no scatter/gather).
Con: write slower and more complicated, require distributed transaction.
Updates to global secondary indexes are asynchronous, e.g., Amazon DynamoDB.

Strategies for Rebalancing

How not to do it: hash mod N

Problem: move data more than necessary

Fixed number of partitions

Create many more partitions than there are nodes, and assign several partitions to each node.
The new node can steal a few partitions from every existing node.
The number of partitions is usually fixed when the database is first set up and not changed afterward.
If partitions are very large, rebalancing and recovery from node failures become expensive. But if partitions are too small, they incur too much overhead.

Request Routing

Strategy for routing

Send requests to all nodes, and if we do not get result, reoute to next node.
Implement a routing tier which knows which node has the specific partition.
Client knows the partition.

How does the component make the routing decision

Zookeeper which is a service that knows the partition.
Gossip protocol.
Mannual rebalance.

source:

DDIA Chapter 5 - Repliation

Sat, 05 Oct 2024 00:00:00 +0000

Importance of Replication

Fault Tolerance: keep the system running, even when one machine (or several machines) go down.
Disconnected operation: Allow an application to continue to work when there is a network interruption.
Latency: Placing data geographically close to users, so users can interact with it with a lower latency.
Scalability: Being able to handle higher volume of reads than a single machine could handle.

Three main approaches to replication

Single-leader replication: Clients send write operation to a single node(leader), which sends a stream of data change to other replicas(followers). Reads can be performed on any replica, but reads from followers might be stale.
Multi-leader replication: Clients send each write to onoe of several leader nodes, any of which can accept writes. The leaders send streams of data change events to each other and any follower nodes.
Leaderless replication: Clients send each write to several nodes, and read from several nodes in parallel in order to detect and correct nodes with stale data. w + r > n.

Three interesting effects can be caused by replication lag

Read-after-write consistency

Users should always see data that they submit themselves.

Solution:

When read something that user can modify, read from leader.
Track update time t, and from t to t + 1 minutes, read from leader(essentially wait for replica picking up the data from leader).
Track the logical timestamp and compare it with follower node, if smaller, than find another node.

Monotonic reads

After users have seen the data at one point in time, they shouldn’t later see the data from ealier point in time.

Solution:

Always read from a single replica.

Consistent prefix reads

Users should see data in a state that makes causal sense: for example, an answer should come after a question.

Solution:

Write to the same partition.

Finally, we discussed the concurrency issues that are inherent in multi-leader and leaderless replication approaches: because such systems allow multiple writes to happen concurrently, conflicts may occur. We examined an algorithm that a database might use to determine whether one operation happened before another, or whether they happened concurrently. We also touched on methods for resolving conflicts by merging together concurrently written values. In the next chapter we will continue looking at data that is distributed across multiple machines, through the counterpart of replication: splitting a large dataset into partitions.

From DDIA chapter 5.