#12 - Distributed SQL và sharding thực chiến (2026)

Mọi PostgreSQL hay MySQL instance đều có “trần”: 32-64 core CPU, 1-2 TB RAM, I/O ~100k IOPS. Khi dataset chạm 5-10 TB với QPS hàng trăm nghìn, bạn không thể chỉ nâng cấp phần cứng được nữa — phải chia shard hoặc chuyển sang distributed SQL. Bài này đi qua cái bức tranh 2026 và cách chọn đúng công cụ.

1. Bức tranh thật: khi nào single-node đủ?

Trước khi bỏ 3 tháng migrate sang distributed, hãy trả lời thật lòng các câu sau:

90% production hệ thống không cần distributed — vertical scale + indexing + read replicas giải quyết được. Chỉ khi đo được ROI rõ ràng mới làm.

2. Các lựa chọn 2026

  flowchart TD
  Start[Đã chạm trần single PG/MySQL?] -->|No| Tune[Tune & scale vertically]
  Start -->|Yes| Need{Cần gì?}

  Need -->|Giữ MySQL protocol<br/>scale out ngang| Vitess
  Need -->|Giữ PostgreSQL<br/>dataset lớn| Citus
  Need -->|Global ACID<br/>multi-region| CRDB
  Need -->|HTAP<br/>OLTP + analytics cùng cluster| TiDB
  Need -->|PG API<br/>geo-distributed| YB[YugabyteDB]
  Need -->|Không tự vận hành| Managed[Spanner / AlloyDB / Aurora DSQL]

  Vitess:::box
  Citus:::box
  CRDB[CockroachDB]:::box
  TiDB:::box
  YB:::box
  Managed:::box

  classDef box fill:#e3f2fd,stroke:#1565c0

2.1 Vitess — MySQL scale-out (YouTube, Slack, GitHub)

• Kiến trúc: router (vtgate) + shard (vttablet wrapping MySQL) + topo (etcd/zookeeper).
• Shard key gọi là vindex. Chọn kỹ — re-shard đắt.
• Bền vững: YouTube, Slack, GitHub, HubSpot chạy production scale.
• Khuyết: Không phải ACID xuyên shard mặc định (dùng 2PC phải bật rõ); query cross-shard chậm.

Khi nào chọn: bạn đã chạy MySQL ở scale lớn và không muốn đổi protocol/driver/ORM.

2.2 Citus — scale-out extension cho PostgreSQL (Microsoft)

• Distributed table: SELECT create_distributed_table('orders', 'customer_id');
• Reference table: bảng nhỏ replicate mọi node.
• Columnar storage: cột hoá cho OLAP trực tiếp trong PG.
• Co-location: 2 bảng cùng shard key → join local trong node.

-- Thiết lập cluster và phân tán bảng
CREATE EXTENSION citus;
SELECT citus_add_node('worker-1', 5432);
SELECT citus_add_node('worker-2', 5432);

SELECT create_distributed_table('orders', 'customer_id');
SELECT create_distributed_table('order_items', 'customer_id',
                                 colocate_with => 'orders');

-- Query tự động phân tán
SELECT customer_id, SUM(total)
FROM orders
WHERE created_at >= now() - INTERVAL '7 days'
GROUP BY customer_id;

Khi nào chọn: bạn đã dùng PostgreSQL, muốn scale-out không rời hệ sinh thái extension/driver/ORM đã có.

2.3 CockroachDB — distributed SQL native

• Kiến trúc: key-value Raft (replicate 3) + SQL layer.
• Global ACID: serializable isolation xuyên mọi shard/region.
• Geo-distributed: partition theo region (REGIONAL BY ROW), đọc local, write multi-region.
• PG wire protocol: driver PostgreSQL dùng được (gần như).
• Khuyết: latency p99 cao hơn PG thường (Raft consensus); transaction nặng có thể retry nhiều.

-- Multi-region table
CREATE TABLE users (
    id UUID PRIMARY KEY,
    region crdb_internal_region NOT NULL,
    email TEXT UNIQUE,
    name TEXT
) LOCALITY REGIONAL BY ROW;

-- Query chạy tại region của row
INSERT INTO users (id, region, email, name)
VALUES (gen_random_uuid(), 'us-east1', '[email protected]', 'A');

Khi nào chọn: global product cần low-latency local read, strong consistency xuyên region.

2.4 TiDB — HTAP (PingCAP)

• TiKV (row storage, Raft) cho OLTP + TiFlash (columnar, Raft learner) cho OLAP.
• MySQL-compatible: drop-in replacement ở hầu hết workload.
• TiFlash: bật cho một bảng → analytics queries tự động route sang columnar node.

-- TiDB + TiFlash cho HTAP
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Query OLAP tự dùng TiFlash, OLTP dùng TiKV
SELECT DATE(created_at), COUNT(*), SUM(total)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY DATE(created_at);

Khi nào chọn: bạn muốn chạy OLAP báo cáo trực tiếp trên OLTP DB mà không dựng ETL sang warehouse riêng.

2.5 YugabyteDB — PostgreSQL API + distributed KV

• Tương tự CockroachDB nhưng tương thích PG API sâu hơn (Foreign Keys, Triggers, Stored Procedures).
• DocDB engine (Raft + MVCC) bên dưới.

2.6 Managed: Spanner / AlloyDB / Aurora DSQL

• Google Spanner: chuẩn mực global distributed SQL, TrueTime API. Rất đắt.
• AlloyDB: “Spanner-like” nhưng PostgreSQL API, chỉ regional.
• Aurora DSQL (AWS, GA 2025): PostgreSQL-compatible, serverless, multi-region active-active.

Khi nào chọn: budget cho phép, team không muốn vận hành.

3. Thiết kế shard key — quyết định sống còn

Sai shard key → hotspot, re-shard cực đắt, query cross-shard chậm. 4 tiêu chí chọn shard key:

1. Cardinality cao — phân tán đều (tránh 1 shard nóng).
2. Immutable — đổi shard key phải move row, tránh update.
3. Join locality — các bảng hay join nên dùng cùng shard key để co-located.
4. Query pattern — nếu query chính chứa WHERE shard_key = X → hit đúng 1 shard.

Ví dụ đúng

customers(id)
orders(id, customer_id)         -- shard by customer_id
order_items(id, customer_id)    -- shard by customer_id, co-located với orders

• Query “đơn hàng của khách” hit 1 shard.
• Join orders ⋈ order_items ON customer_id local trong shard.

Ví dụ sai

orders(id, created_at)          -- shard by created_at (range)

• Hot shard: tất cả write mới dồn vào shard cuối (vì created_at tăng dần).
• Cách khắc phục: hash thêm (hash(customer_id) % 256) để rải đều, hoặc prefix với random bucket.

4. Chiến lược re-shard và migration

Re-shard cluster production là việc nhạy cảm. Không nên thủ công — tận dụng công cụ:

• Vitess: VReplication copy-then-switch, zero-downtime trên dữ liệu large.
• Citus: rebalance_table_shards() online.
• CockroachDB: auto-rebalance khi thêm node.

Quy trình chung khi migrate từ single PG → Citus/distributed:

1. Dùng logical replication (PG pub/sub) để stream sang cluster mới.
2. Application ghi dual-write vào cả hai (hoặc dùng proxy như PgBouncer + dual route).
3. Khi lag = 0, cutover read → mới. Giữ rollback path vài ngày.
4. Dừng ghi DB cũ, xoá publication.

5. Đo lường gì trong cluster distributed

Ngoài các metric single-node, thêm:

• Replication lag Raft (leader → followers)
• Hot shard (queries/sec/shard, bytes/shard)
• Cross-shard query % (should be < 5-10%)
• Leader imbalance (một node chứa quá nhiều range leader)
• Rebalance throttling (để không ảnh hưởng traffic)

Phần lớn distributed DB expose Prometheus metrics — plug vào Grafana + dashboard vendor-provided.

6. Câu hỏi thực chiến nhanh

Q: Đang chạy MySQL 5TB, write ~50k TPS, có phải distributed? A: Chưa chắc. MySQL 8.4 trên máy 64 core/256 GB có thể làm được. Thử tune redo log capacity, partition theo tháng, split read replica. Tính ROI cụ thể mới quyết định.

Q: Multi-region chọn gì? A: Nếu cần active-active write multi-region với strong consistency: CockroachDB, YugabyteDB, Spanner, Aurora DSQL. Nếu chỉ cần DR failover: primary-replica cross-region với MySQL Group Replication hoặc PostgreSQL streaming replication là đủ.

Q: Bỏ PG đi Cockroach, có đáng? A: Chỉ khi có nhu cầu multi-region thật sự. Cockroach pay cost latency (2-3× PG thường), tool ecosystem ít hơn, chi phí vận hành cao.

Q: Chia shard nhỏ hay to? A: Nhỏ (~50 GB mỗi shard) dễ rebalance và recovery, nhưng overhead metadata nhiều hơn. To (500 GB+) ít overhead nhưng rebalance lâu. Mặc định Vitess/Citus ~100-200 GB/shard là sweet spot.

7. Checklist trước khi go distributed

• Benchmark single-node đã tune hết mức (index, partition, replica)
• Đo thấy bottleneck rõ ràng (CPU / IO / DataSize / Network)
• Chọn ứng viên theo: protocol, consistency, latency, ops cost
• PoC benchmark với dữ liệu production (không synthetic)
• Thiết kế shard key: cardinality, immutable, join locality
• Plan migration 2 chiều (có rollback)
• Giám sát hotshard, Raft lag, cross-shard query, leader balance
• Review operational cost: runbook, on-call, backup distributed

Kết luận

Distributed SQL 2026 không còn là magic — nó là trade-off. Bạn trả latency cao hơn, độ phức tạp vận hành cao hơn, chi phí cao hơn để đổi lấy scale và high-availability. Nếu chưa thực sự đụng trần single-node hoặc chưa có nhu cầu geo-distributed, hãy tiếp tục PG/MySQL + read replica — 90% team ở mức đó là đủ.

Còn khi thật sự cần, 3 lựa chọn an toàn nhất 2026:

• MySQL scale: Vitess
• PostgreSQL scale: Citus (Azure/Microsoft) hoặc CockroachDB (nếu cần global)
• HTAP: TiDB

Bài tiếp theo: benchmark và load testing — công cụ, dataset, cách đọc số và cạm bẫy phổ biến.