Amazon Aurora DSQL — Distributed SQL Serverless cho kiến trúc Multi-Region

Posted on: 4/26/2026 4:14:44 PM

Mục lục

• Bối cảnh: Tại sao cần Distributed SQL?
• Aurora DSQL là gì?
• Kiến trúc Disaggregated 5 tầng
• Vòng đời một Transaction
• Multi-Region Active-Active
• Optimistic Concurrency Control
• So sánh: Aurora DSQL vs Spanner vs CockroachDB
• Chi phí & Free Tier
• Hạn chế cần biết
• Tích hợp với .NET 10
• Khi nào nên dùng Aurora DSQL?
• Kết luận

Bối cảnh: Tại sao cần Distributed SQL?

Khi hệ thống vượt ra khỏi biên giới một data center duy nhất — vì lý do latency cho user toàn cầu, compliance yêu cầu data residency, hoặc đơn giản là business cần 99.999% uptime — mô hình database truyền thống với primary-replica bắt đầu bộc lộ giới hạn. Failover mất hàng chục giây, cross-region read stale, write chỉ đi qua một region duy nhất.

Distributed SQL giải quyết bài toán này: một cụm database phân tán trên nhiều Availability Zone (AZ) hoặc nhiều Region, vẫn đảm bảo ACID transactions với strong consistency, đồng thời scale-out ngang khi tải tăng.

Aurora DSQL là gì?

Amazon Aurora DSQL là dịch vụ cơ sở dữ liệu SQL phân tán, serverless, tương thích PostgreSQL, được AWS ra mắt chính thức (GA) vào tháng 5/2025. Đây là sản phẩm đầu tiên trong dòng Aurora được thiết kế từ đầu cho kiến trúc active-active multi-region.

Kiến trúc Disaggregated 5 tầng

Điểm khác biệt cốt lõi của Aurora DSQL so với database truyền thống là kiến trúc disaggregated — tách rời hoàn toàn compute, transaction validation, journaling, routing và storage thành 5 tầng độc lập. Mỗi tầng scale riêng, deploy riêng, security boundary riêng.

graph TD
    Client["🖥️ Client App"] -->|"PostgreSQL wire protocol"| QP["Query Processor
(QP)"]

    subgraph DSQL["Aurora DSQL Engine"]
        QP -->|"Buffered writes
at commit time"| ADJ["Adjudicator
(OCC Validator)"]
        ADJ -->|"Commit approved"| JRN["Journal
(Durable Log)"]
        JRN -->|"Ordered stream"| XB["Crossbar
(Stream Merger)"]
        XB -->|"Chronological writes"| STG["Storage Nodes
(Range-partitioned)"]
        QP -->|"Direct reads"| STG
    end

    style Client fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style QP fill:#e94560,stroke:#fff,color:#fff
    style ADJ fill:#2c3e50,stroke:#fff,color:#fff
    style JRN fill:#2c3e50,stroke:#fff,color:#fff
    style XB fill:#16213e,stroke:#fff,color:#fff
    style STG fill:#e94560,stroke:#fff,color:#fff
    style DSQL fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
  

1. Query Processor (QP)

Mỗi client connection được gán một PostgreSQL engine riêng. QP xử lý toàn bộ SQL parsing, planning, execution tại local. Điều đặc biệt: QP buffer tất cả write operations cho đến khi transaction commit — không gửi từng write riêng lẻ. QP duy trì một shard map để biết data nằm ở storage node nào, và push predicate xuống storage layer để filter/aggregate ngay tại nguồn.

2. Adjudicator

Đây là "trọng tài" quyết định transaction được commit hay abort. Adjudicator thực thi Optimistic Concurrency Control (OCC): khi QP gửi commit request, Adjudicator kiểm tra xem có transaction nào khác đã modify cùng key range không. Mỗi Adjudicator phụ trách một tập key range cụ thể. Trong multi-region, các Adjudicator ở các region khác nhau giao tiếp để detect conflict xuyên region.

3. Journal

Mỗi Journal gắn với đúng một Adjudicator. Khi transaction được approve, Journal ghi durable log và replicate sang các AZ khác. Đây là điểm mà durability được đảm bảo — client nhận acknowledge ngay khi Journal ghi xong.

4. Crossbar

Crossbar nhận các luồng dữ liệu từ nhiều Journal, merge theo thứ tự thời gian (không phải thứ tự transaction), rồi route xuống storage. Thiết kế này cho phép storage luôn nhận writes theo đúng chronological order, đơn giản hoá logic snapshot isolation.

5. Storage Nodes

Data được phân bố theo range-partitioning dựa trên primary key. Mỗi storage node giữ nhiều replica phân tán trên các AZ. QP đọc trực tiếp từ storage node (không qua Adjudicator/Journal), nên read latency rất thấp.

Vòng đời một Transaction

sequenceDiagram
    participant App as Application
    participant QP as Query Processor
    participant ADJ as Adjudicator
    participant JRN as Journal
    participant XB as Crossbar
    participant STG as Storage

    App->>QP: BEGIN + SQL statements
    QP->>STG: Read rows (direct)
    STG-->>QP: Row data
    Note over QP: Buffer all writes locally
    App->>QP: COMMIT
    QP->>ADJ: Submit write set + read set
    ADJ->>ADJ: OCC validation (check conflicts)
    alt No conflict
        ADJ->>JRN: Persist commit record
        JRN->>JRN: Replicate across AZs
        JRN-->>App: COMMIT OK
        JRN->>XB: Stream committed data
        XB->>STG: Apply writes (chronological)
    else Conflict detected
        ADJ-->>App: ABORT (serialization failure)
        Note over App: Retry transaction
    end
  

Những điểm đáng lưu ý:

• Read operations: đi thẳng từ QP đến Storage, không qua Adjudicator → read latency cực thấp, không bị cross-AZ overhead
• Write operations: buffer tại QP, chỉ gửi một lần tại commit time → giảm network round-trip
• Commit latency: chỉ phụ thuộc vào Adjudicator validation + Journal replication, không phải số lượng write statements trong transaction
• Transaction timeout: tối đa 300 giây (5 phút)
• Transaction size: giới hạn 10 MiB và 3.000 row modifications

Multi-Region Active-Active

Đây là killer feature của Aurora DSQL. Không giống Aurora Global Database (1 primary region + read-only secondaries), DSQL cho phép cả 2 region đều đọc-ghi đồng thời.

graph LR
    subgraph US["US East (Primary Write)"]
        QP1["Query Processor"] --> ADJ1["Adjudicator"]
        ADJ1 --> JRN1["Journal"]
        STG1["Storage"]
    end

    subgraph EU["EU West (Primary Write)"]
        QP2["Query Processor"] --> ADJ2["Adjudicator"]
        ADJ2 --> JRN2["Journal"]
        STG2["Storage"]
    end

    subgraph W["Witness Region"]
        WIT["Witness Node"]
    end

    ADJ1 <-->|"Cross-region
conflict check"| ADJ2
    JRN1 <-->|"Sync replication"| JRN2
    ADJ1 <-->|"Quorum"| WIT
    ADJ2 <-->|"Quorum"| WIT

    style US fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style EU fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style W fill:#f8f9fa,stroke:#e0e0e0,color:#2c3e50
    style QP1 fill:#e94560,stroke:#fff,color:#fff
    style QP2 fill:#e94560,stroke:#fff,color:#fff
    style ADJ1 fill:#2c3e50,stroke:#fff,color:#fff
    style ADJ2 fill:#2c3e50,stroke:#fff,color:#fff
    style JRN1 fill:#16213e,stroke:#fff,color:#fff
    style JRN2 fill:#16213e,stroke:#fff,color:#fff
    style STG1 fill:#e94560,stroke:#fff,color:#fff
    style STG2 fill:#e94560,stroke:#fff,color:#fff
    style WIT fill:#ff9800,stroke:#fff,color:#fff
  

Cách hoạt động:

• Read operations: serve tại local region, không cross-region latency → trải nghiệm user tương đương database local
• Write operations: tại commit time, phát sinh 2 round-trip cross-region (Adjudicator check + Journal sync). Latency phụ thuộc khoảng cách giữa 2 region (US East ↔ EU West ≈ 70-80ms/RTT → commit latency ≈ 140-160ms)
• Witness Region: không serve traffic, chỉ tham gia quorum và đóng vai trò tiebreaker khi network partition xảy ra

Optimistic Concurrency Control

Aurora DSQL sử dụng OCC thay vì pessimistic locking truyền thống. Đây là quyết định kiến trúc then chốt:

Hệ quả thực tế cho developer:

• Application bắt buộc phải handle retry logic khi nhận serialization failure (SQL state 40001)
• Tránh hot key writes (nhiều transaction cùng update một row) — dùng UUID random làm primary key thay vì auto-increment
• Không có SELECT ... FOR UPDATE — redesign flow nếu đang dùng pessimistic locking

// Retry pattern cho OCC trong .NET
async Task ExecuteWithRetry(Func<Task> action, int maxRetries = 5)
{
    for (int i = 0; i < maxRetries; i++)
    {
        try
        {
            await action();
            return;
        }
        catch (PostgresException ex) when (ex.SqlState == "40001")
        {
            if (i == maxRetries - 1) throw;
            await Task.Delay(Random.Shared.Next(10, 50 * (i + 1)));
        }
    }
}

So sánh: Aurora DSQL vs Spanner vs CockroachDB

Chi phí & Free Tier

Aurora DSQL sử dụng đơn vị DPU (Distributed Processing Unit) — gộp compute và I/O vào một metric duy nhất:

Điểm đặc biệt về pricing:

• Scale-to-zero: khi không có traffic, chi phí compute = $0 (chỉ trả storage)
• Multi-region write: DPU cho writes được tính gấp đôi (replicate sang region kia), nhưng không phát sinh data transfer fee riêng
• Storage replication: 3-AZ replication trong cùng region đã bao gồm trong giá $0.33/GB
• Free tier: 100K DPU + 1GB storage/tháng — đủ cho dev environment hoặc side project nhỏ

Hạn chế cần biết

Các tính năng PostgreSQL KHÔNG được hỗ trợ:

• Foreign Keys — phải enforce ở application layer
• Triggers — dùng application event hoặc Change Data Capture thay thế
• Views (kể cả materialized views)
• Sequences — dùng UUID v7 (time-ordered) thay auto-increment
• PL/pgSQL — chỉ hỗ trợ pure SQL user-defined functions
• JSON/JSONB data types — phải dùng TEXT + serialize ở application
• Extensions (PostGIS, pg_trgm, ...)
• Temp tables

Giới hạn kiến trúc:

• Tối đa 2 write regions (+ 1 witness) — Spanner và CockroachDB không giới hạn
• Isolation level cố định Repeatable Read — không thể chuyển sang Read Committed hay Serializable
• Transaction tối đa 300 giây, 10 MiB, 3.000 row modifications
• Không mix DDL và DML trong cùng transaction
• Region coverage còn hạn chế (đang mở rộng dần)

Tích hợp với .NET 10

Aurora DSQL tương thích PostgreSQL wire protocol, nên bạn dùng Npgsql (driver PostgreSQL cho .NET) như bình thường. Điểm khác biệt chính: authentication dùng AWS IAM token thay vì password tĩnh.

using Amazon.DSQL;
using Amazon.DSQL.Model;
using Npgsql;

// Tạo auth token
var client = new AmazonDSQLClient();
var token = await client.GenerateDbConnectAuthTokenAsync(
    new GenerateDbConnectAuthTokenRequest
    {
        Hostname = "your-cluster.dsql.us-east-1.on.aws",
        Region = "us-east-1"
    });

// Kết nối Npgsql như PostgreSQL thông thường
var connStr = new NpgsqlConnectionStringBuilder
{
    Host = "your-cluster.dsql.us-east-1.on.aws",
    Port = 5432,
    Database = "postgres",
    Username = "admin",
    Password = token,
    SslMode = SslMode.Require
}.ConnectionString;

await using var conn = new NpgsqlConnection(connStr);
await conn.OpenAsync();

// CRUD operations — standard PostgreSQL syntax
await using var cmd = new NpgsqlCommand(
    "INSERT INTO orders (id, customer_id, total, status) VALUES ($1, $2, $3, $4)",
    conn);
cmd.Parameters.AddWithValue(Guid.NewGuid());
cmd.Parameters.AddWithValue(customerId);
cmd.Parameters.AddWithValue(total);
cmd.Parameters.AddWithValue("pending");
await cmd.ExecuteNonQueryAsync();

// Schema design tối ưu cho Aurora DSQL
// Dùng UUID v7 thay auto-increment (tránh hot key)
public class Order
{
    public Guid Id { get; set; } = Guid.CreateVersion7();
    public Guid CustomerId { get; set; }
    public decimal Total { get; set; }
    public string Status { get; set; } = "pending";
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
}

// SQL: không có SERIAL, không có FK constraint
// CREATE TABLE orders (
//     id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
//     customer_id UUID NOT NULL,
//     total NUMERIC(18,2) NOT NULL,
//     status TEXT NOT NULL DEFAULT 'pending',
//     created_at TIMESTAMPTZ NOT NULL DEFAULT now()
// );
// CREATE INDEX idx_orders_customer ON orders (customer_id);
// CREATE INDEX idx_orders_status ON orders (status, created_at);

Khi nào nên dùng Aurora DSQL?

Phù hợp:

• Ứng dụng cần active-active multi-region với strong consistency (e-commerce toàn cầu, fintech, inventory management)
• Workload read-heavy, write-moderate với low contention
• Team muốn zero infrastructure management — không provision, không patch, không capacity planning
• Greenfield projects có thể thiết kế schema phù hợp với constraints của DSQL
• Development/staging environments cần scale-to-zero để tiết kiệm chi phí

Không phù hợp:

• Ứng dụng legacy phụ thuộc nặng vào foreign keys, triggers, PL/pgSQL
• Workload cần high-contention writes vào cùng một row (hot key pattern)
• Cần >2 write regions
• Cần JSONB, PostGIS, full-text search với tsvector
• Ứng dụng cần multi-cloud portability (chọn CockroachDB)

Kết luận

Amazon Aurora DSQL đại diện cho bước tiến quan trọng trong lĩnh vực distributed database: lần đầu tiên AWS cung cấp một true distributed SQL database với active-active multi-region, serverless scale-to-zero, và PostgreSQL compatibility — tất cả trong một managed service.

Kiến trúc disaggregated 5 tầng là nền tảng cho khả năng scale độc lập từng component. OCC loại bỏ deadlock nhưng yêu cầu application xử lý retry. Multi-region thêm 2 RTT cho writes nhưng reads vẫn local.

Tuy nhiên, DSQL vẫn còn non trẻ: giới hạn 2 write regions, thiếu nhiều tính năng PostgreSQL quen thuộc, và region coverage chưa rộng. Đây là lựa chọn tuyệt vời cho greenfield projects trên AWS cần global availability, nhưng chưa phải "PostgreSQL killer" cho mọi workload.

Với tốc độ phát triển hiện tại — Playground mới vào Q1/2026, driver connectors mở rộng, region mới liên tục — Aurora DSQL rất đáng để theo dõi trong 12-18 tháng tới.

Tham khảo

• Amazon Aurora DSQL — Official Product Page
• Introducing Amazon Aurora DSQL — AWS Database Blog
• Everything You Don't Need to Know About Aurora DSQL: Part 2 — AWS Blog
• Aurora DSQL is Now Generally Available — AWS News Blog
• What is Amazon Aurora DSQL? — AWS Documentation
• Aurora DSQL — A First Comparison with CockroachDB
• Aurora DSQL Comparison with Spanner — DeNA Engineering
• AWS Expands Aurora DSQL with Playground Updates — InfoQ
• Using .NET to Interact with Amazon Aurora DSQL — AWS Docs