Serializable (Database)

IT 위키
Betripping (토론 | 기여)님의 2024년 12월 12일 (목) 07:49 판 (Created page with "'''Serializable''' is the highest level of isolation in database transaction management, ensuring that the outcome of concurrent transactions is equivalent to some sequential (serial) execution of those transactions. It prevents issues like dirty reads, non-repeatable reads, and phantom reads, guaranteeing the consistency of the database. ==Key Concepts== *'''Isolation Level:''' Serializable is one of the Isolation Levels defined in the SQL standard, providing the st...")
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)

Serializable is the highest level of isolation in database transaction management, ensuring that the outcome of concurrent transactions is equivalent to some sequential (serial) execution of those transactions. It prevents issues like dirty reads, non-repeatable reads, and phantom reads, guaranteeing the consistency of the database.

Key Concepts[편집 | 원본 편집]

  • Isolation Level: Serializable is one of the Isolation Levels defined in the SQL standard, providing the strictest transaction isolation.
  • Serial Schedule: A transaction schedule is serializable if its outcome is the same as a serial schedule where transactions are executed sequentially without overlapping.
  • Concurrency Control: Techniques like locking, timestamp ordering, or validation are used to enforce serializability.

Problems Prevented by Serializable[편집 | 원본 편집]

Serializable isolation eliminates the following concurrency issues:

  • Dirty Reads: Transactions cannot read uncommitted changes made by other transactions.
  • Non-Repeatable Reads: Ensures that data read once by a transaction remains consistent during its execution.
  • Phantom Reads: Prevents the appearance of new rows or disappearance of rows that affect query results during a transaction.

Example of Serializable Isolation[편집 | 원본 편집]

The following table demonstrates how Serializable isolation prevents anomalies in a banking system:

Step Transaction A (T1) Transaction B (T2) Explanation
1 BEGIN TRANSACTION BEGIN TRANSACTION Both transactions start.
2 SELECT SUM(balance) FROM accounts; - T1 calculates the total balance.
3 - UPDATE accounts SET balance = balance - 100 WHERE id = 1; T2 deducts $100 from account 1.
4 - UPDATE accounts SET balance = balance + 100 WHERE id = 2; T2 adds $100 to account 2.
5 - COMMIT; T2 commits its changes.
6 SELECT SUM(balance) FROM accounts; - T1 reads the total balance again.
Result (Non-Serializable) $1000 - Without Serializable isolation, T1 could see an inconsistent total balance due to T2's changes.
Result (Serializable) $1100 - With Serializable isolation, T1's second query is blocked until T2 completes, ensuring consistent results.

Techniques to Achieve Serializable Isolation[편집 | 원본 편집]

Several methods are employed to enforce serializability:

  1. Two-Phase Locking (2PL):
    • Requires transactions to acquire all necessary locks before releasing any of them.
    • Includes strict or rigorous variants to prevent cascading rollbacks.
  2. Timestamp Ordering:
    • Assigns timestamps to transactions and ensures that operations occur in timestamp order to prevent conflicts.
  3. Validation-Based Concurrency Control:
    • Validates transaction read and write sets at commit time to ensure no conflicts exist.
  4. Serializable Snapshot Isolation (SSI):
    • Extends snapshot isolation to detect and prevent conflicts between concurrent transactions.

Performance Implications[편집 | 원본 편집]

While Serializable isolation guarantees consistency, it comes with trade-offs:

  • Reduced Concurrency: Higher isolation restricts parallelism, leading to potential performance bottlenecks.
  • Increased Lock Contention: Locking-based approaches can result in higher contention, especially in write-heavy workloads.
  • Complexity: Implementing serializability, particularly in distributed systems, is complex and resource-intensive.

Use Cases[편집 | 원본 편집]

Serializable isolation is critical in applications where consistency is more important than performance:

  • Financial Systems: Ensures accurate accounting and prevents anomalies in concurrent transactions.
  • Inventory Management: Prevents inconsistencies in stock levels during concurrent updates.
  • Critical Reporting: Guarantees consistent data snapshots for regulatory or analytical reports.

Advantages[편집 | 원본 편집]

  • Data Consistency: Provides the strongest guarantees for maintaining database integrity.
  • Error Prevention: Eliminates complex anomalies that can arise in concurrent transactions.

Limitations[편집 | 원본 편집]

  • Performance Overhead: Restricts concurrency, which may lead to slower transaction throughput.
  • Implementation Complexity: Challenging to implement efficiently, especially in distributed or large-scale systems.
  • Not Always Necessary: Applications with lower consistency requirements may not benefit from Serializable isolation.

See Also[편집 | 원본 편집]