Mọi PostgreSQL hay MySQL instance đều có “trần”: 32-64 core CPU, 1-2 TB RAM, I/O ~100k IOPS.

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:

Tín hiệu single-node còn dưAction
CPU <70% p99, memory <80%, IO util <80%Tiếp tục tune/index
Query chậm ở vài bảng cụ thểPartition, index, materialized view
Write > 30k TPS ổn địnhXem xét replication + read split
Write > 100k TPS ổn địnhBắt đầu PoC distributed
Dataset > 5 TB + random accessSharding hoặc distributed
Cần multi-region low-latency writeDistributed SQL bắt buộc

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', 'a@b.com', '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.

Shard key đúng: co-locate orders theo customer_id

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.

Shard key sai: hot shard do tăng dần theo thời gian

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

Distributed SQL là trade-off đắt, không phải giải pháp mặc định

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.

Câu hỏi hay gặp

CAP theorem áp dụng thế nào với các distributed DB?

Trả lời: CockroachDB/TiDB: CP (consistency + partition tolerance, sacrifice availability khi network partition). Cassandra/ScyllaDB: AP (tunable consistency, default eventual). Vitess/Citus: kế thừa từ MySQL/PG, strong consistency trong shard, cross-shard transaction có thể kém. Thực tế 2026: hầu hết chọn CP + tunable availability (CockroachDB multi-region).

Shard key chọn sai phải reshard, cost bao nhiêu?

Trả lời: Rất cao. Vitess hỗ trợ online resharding nhưng vẫn tốn tuần-tháng cho TB-scale data. CockroachDB tự rebalance nhưng đổi primary key = recreate table. Rule: chọn shard key immutable, high-cardinality, và match query pattern (tenant_id thường là safe default cho SaaS).

Cross-shard JOIN có chấp nhận được không?

Trả lời: Tránh tối đa. Cross-shard = scatter-gather, latency tăng tuyến tính với số shard. Nếu cần JOIN: (1) co-locate related tables cùng shard key; (2) denormalize; (3) dùng materialized view/CQRS. Analytical cross-shard query nên đẩy sang OLAP (ClickHouse, BigQuery).

Bài tiếp theo: Benchmark và load testing database, công cụ, cách đọc số đúng.