Khi ghi và dữ liệu vượt sức một máy, sharding chia bảng ngang qua nhiều máy chủ. Đo thật với postgres_fdw: bảng phân tán 1 triệu dòng qua 2 shard, truy vấn theo shard key chỉ route tới một máy (Foreign Scan), nhưng truy vấn theo cột khác fan-out tới mọi shard. Ba cách tiếp cận và vì sao chọn shard key là quyết định khó đảo ngược. PostgreSQL 16.
Discord chứa hàng nghìn tỷ tin nhắn. Bài toán khó: một kênh nóng biến thành một partition khổng lồ. Cách giải: khoá phân mảnh (channel_id, bucket). Bài này dựng THẬT trên ScyllaDB, tạo cả hai schema và dùng nodetool đo trực tiếp: partition nóng 315KB/14.237 cell với đọc 2.106µs, còn bucket chỉ 29KB/1.109 cell đọc 207µs.
Chia khoá cho N node bằng hash%N nghe hợp lý — cho tới khi thêm một node và gần như MỌI khoá phải chuyển chỗ. Dynamo (2007) giải bằng consistent hashing. Bài này dựng THẬT một Redis Cluster 3 node (16384 hash slot), nạp 20.000 khoá, thêm node thứ 4 và đo trực tiếp: chỉ 24,9% khoá phải dời (~1/N) thay vì ~75% của modulo.
Ở quy mô sharded, cần ID duy nhất mà không có điểm sinh trung tâm (nút thắt). Instagram gói vào 64 bit: 41 bit timestamp + 13 bit shard + 10 bit sequence, sinh ngay trong Postgres bằng PL/pgSQL. Bài này dựng THẬT đúng scheme đó: ID tăng theo thời gian, 50.000 ID không trùng, và trích được shard từ chính con số ID.
Một triệu khoá, cụm 10 node, thêm thành 11 rồi bớt về 9. Modulo chuyển 90,9% và 90,0% khoá — gần như toàn bộ cache miss hoặc toàn bộ dữ liệu di chuyển. Vòng băm với 1.000 node ảo chuyển 9,0% và 10,1%, sát lý tưởng; jump hash 9,0% và 10,0% với 0 byte bảng. Nhưng vòng băm có hai bẫy đo được: ít node ảo thì một node gánh 27 lần node khác (3,185× so với 0,118×), và hàm băm trộn kém — FNV-1a trên chuỗi node-i#j — làm các điểm ảo dính chùm, lệch 3,026× dù có 100 node ảo. Jump hash cân nhất (1,005×) nhưng chỉ thêm bớt được node cuối; vòng băm bớt node giữa chỉ chuyển đúng khoá của node đó.
Năm container PostgreSQL 16 làm năm mảnh, 200.000 sự kiện của 100.000 user. Chia theo khoảng user_id đẹp với khoá đều (lệch 1,00) nhưng với khoá Zipf thì mảnh đầu ôm 187.329 dòng, lệch 3,75; hash cũng lệch 1,54 vì user #0 một mình chiếm 13,5% dữ liệu. Muối top-10 user nóng hạ xuống 1,25, đổi lại đọc user nóng phải hỏi 4 mảnh. Chia theo thời gian dồn mọi dòng mới vào một mảnh: ghi chậm 1,6 lần. Thêm mảnh thứ 5: mod N dời 79,9% khoá, jump hash dời 20,0%; dời thật 39.684 dòng mất 251 ms, bộ đọc chỉ hỏi vị trí mới trượt 47,8%, đọc kép mới rồi cũ trượt 0.