Sharding và tách database

Bài toán

Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.

Diễn tiến theo thời gian

• 2004 · Facebook (Meta): shard tự nhiên ngay từ đầu: mỗi trường đại học một database, web server dùng chung. Về sau, ở quy mô fleet, quản lý shard thành một hệ riêng (Shard Manager, hàng chục triệu shard). Meta 2025

• 2006 · YouTube: (Qua HighScalability) Một server → master + read slave → partition → shard theo user; slave đơn luồng tụt sau master, tạm tách pool xem video được ưu tiên; shard giảm 30% phần cứng, replica lag về 0. YouTube 2007

• 2009 · Stack Overflow: không shard, không NoSQL: kiến trúc hai tầng, một SQL Server, nâng RAM lên 48 GB khi chạm giới hạn. Theo HighScalability, đây là "điểm ngọt" của scale up (user tự giới hạn, ít media, không đồ thị xã hội), còn nhiều đường lùi (cache, denormalize, partition một phần) trước khi phải scale out. Stack Overflow 2009

• 2009 · LinkedIn: DB đã tách theo tính năng (profile, search, nhóm) có read replica nhưng không scale được ghi; Voldemort (KV kiểu Dynamo) cho Who's Viewed My Profile và dữ liệu tính offline, hơn 400 ms → dưới 10 ms. LinkedIn 2009

• 2010 · Twitter: MySQL đi từ một instance nhỏ → một instance lớn → nhiều cluster lớn; sau đó thay dần bằng Cassandra hoặc MySQL shard ngang (Gizzard). Việc này kéo theo nhu cầu tự sinh ID, xem Sinh ID phân tán. Twitter 2010

• ~2010→2026 · Etsy: ~1.000 shard MySQL, 425 TB, 1,7 triệu req/s. ORM tự viết gán shard ngẫu nhiên và lưu ánh xạ trong một index DB, thành điểm hỏng chung và khiến scale ngang mất nhiều tháng. Họ chuyển sang hash vindex của Vitess, dùng SQLite cho ánh xạ cũ. Etsy 2026

• 2011 · Instagram: cân nhắc NoSQL rồi giữ Postgres. Hàng nghìn shard logic (mỗi cái là một schema Postgres) ánh xạ vào ít máy vật lý, nên thêm máy chỉ cần dời shard. Instagram 2011

• 2011→2012 · Pinterest: thử Cassandra, Membase, Mongo rồi bỏ; preshard theo dự báo 5 năm (8 máy × 512 DB, mọi DB có mọi bảng), ID 64 bit nhúng shard ID, dữ liệu của user nằm cùng shard; tăng tải thì dựng slave rồi tách. Theo Pinterest, sharding thủ công thắng clustering vì thuật toán đặt dữ liệu chỉ nửa trang code, trong khi cluster manager làm họ sập 4 lần. Pinterest 2013

• 2011→2015 · LinkedIn (Espresso): băm partition key (ví dụ MailboxID) ra số partition cố định mỗi database; router stateless tra bảng routing cập nhật qua ZooKeeper; Helix dời partition khi thêm node; số thứ tự SCN giữ theo partition chứ không theo instance MySQL vì partition di chuyển giữa node. LinkedIn 2015

• 2011 · Pinterest: 4.096 shard ảo (database db00000…) trên 8 cặp MySQL master-master, map dải trong ZooKeeper; dữ liệu không bao giờ rời shard, thêm máy bằng chuyển nguyên shard; join ở tầng ứng dụng; chỉ đọc/ghi master (bài 2015, chạy từ đầu 2012). Pinterest 2015

• 2012 · Zillow: chia khách của nền tảng website môi giới vào các DB server bằng consistent hashing (HyperDB + Flexihash) để thêm server chỉ phải dời một phần nhỏ khách. Zillow 2012

• 2013 · Twitter: shard theo thời gian (đầy DB thì mở DB mới) dồn mọi lượt ghi vào một master, gây hot spot. T-Bird hash tweet qua Gizzard để rải đều cả đọc lẫn ghi. Twitter 2013

• 2014 · Twilio: trước khi shard, tách dữ liệu theo vòng đời (cuộc gọi đang chạy, ghi nhiều; và đã xong, đọc nhiều) và đặt service trước DB để chỉ một chỗ biết cách shard. Khoá AccountSid, ánh xạ range + lookup để tách riêng account lớn. Shard mới làm slave của cụm cũ, chuyển đọc trước, ghi sau. Twilio 2014

• 2014 · WhatsApp (qua HighScalability): Mnesia không dùng transaction: băm record → partition → fragment → một process duy nhất xử lý record đó, replication một chiều; đa số service chia 32 phần, node theo cặp primary/secondary, "đảo" Mnesia thu về 2 node để thao tác schema chạy được khi có tải. Partition theo luỹ thừa 2: 64 được, 128 không thực tế. WhatsApp 2014

• 2014→2016 · LinkedIn: FollowFeed over-partition 720 partition (chia hết cho nhiều số) để cụm 40, 45, 60, 80, 360 máy đều được, rebalance chỉ là di chuyển nguyên partition; cùng một hàm partition cho Kafka ingest và cho broker định tuyến query. LinkedIn 2016

• 2015–2018 · Shopify: shard DB rồi phát hiện code lặp qua mọi shard làm một shard hỏng là hỏng toàn nền tảng. Pod: mỗi request chỉ chạm một pod (tập shop trên datastore cô lập); Sorting Hat ở load balancer route request tới đúng pod. Shopify 2018

• 2015→2016 · Ele.me: DB đơn hàng 1 primary + 5 secondary không chịu được khuyến mãi, thêm một cột cần dừng 3–5 giờ. Shard hai chiều × 120 shard (định tuyến theo user, merchant hoặc order ID); phần tốn công nhất là sửa SQL không có khoá shard. Chuyển với khoảng 10 phút chặn ghi. Ele.me 2020

• 2015 · Vitess (YouTube): shard MySQL theo khoảng trên keyspace ID (băm khoá thành giá trị 8 byte, mỗi shard một khoảng) nên không cần bảng tra và đổi số shard là chia lại khoảng. Theo Vitess, trong một năm YouTube đã reshard gần như mọi database MySQL; Vitess 2.0 đưa việc này lên Kubernetes. Vitess 2015

• 2015 · Booking.com: đo parallel replication của MySQL/MariaDB trên workload production để xem có tránh được sharding không: chỉ tăng ghi 25% đến 110% tuỳ môi trường, xa mức 3 đến 10 lần cần cho máy 12–40 core. Kết luận của Booking: không phải lời giải dài hạn. Booking.com 2015

• 2015 · Airbnb: tách dọc thay vì shard ngang: hộp thư tin nhắn (gần 1/3 số ghi của DB MySQL chính) chuyển sang DB riêng bằng cách tạo read replica rồi promote trên RDS, không viết code migrate; chuẩn bị bằng query analyzer và thu hồi quyền DB để chắc không còn join chéo. Hai tuần, dưới 7,5 phút downtime của riêng hộp thư, ghi trên DB chính giảm 33%. Airbnb 2015

• 2015→2017 · Slack (Enterprise Grid): mô hình shard theo team không chứa được dữ liệu xuyên team; organization có shard riêng băm theo ID organization, DM/group DM chuyển sang đó, mọi team ID và user ID cũ (cả trong blob) đổi sang ID mới. Migration theo khách hàng bằng handler validate/transform/insert idempotent, chạy trên job queue riêng, tốc độ do chính rate limiter đặt. Slack 2017

• 2016 · Square: Cash App hết cách scale một MySQL (cache, chuyển dữ liệu cũ, replica, phần cứng) nên shard bằng Vitess; split đầu tiên 11/2017 là vertical split qua replay binlog, dưới một giây downtime. Square 2018

• 2016 · Airbnb: Sau khi tách database theo chức năng, trần mới là số kết nối: mô hình một thread mỗi kết nối của MySQL trói số app server vào giới hạn của RDS. Tầng proxy pool kết nối (hơn 15 service, hàng trăm instance) cho phép scale app ngang mà không tăng thread DB. Airbnb 2016

• 2016→2018 · Netflix: Cụm Cassandra lịch sử xem gần giới hạn kích thước: shard cụm theo loại dữ liệu (xem đầy đủ, preview, ngôn ngữ) rồi theo tuổi (Recent, Past, Historical chỉ tóm tắt), xoay dữ liệu giữa cụm bất đồng bộ khi đọc, đọc song song và ghép; API cũ giữ tương thích. Netflix 2018

• 2017 · Discord: với Cassandra, "shard" nằm ở partition key (channel_id, bucket); bucket ~10 ngày để partition dưới 100MB. Thiết kế key quyết định mọi thứ. Discord 2017

• 2017→2020 · Slack: shard MySQL theo workspace (active-active hai data center) vỡ vì khách doanh nghiệp chạm trần phần cứng, vì Enterprise Grid/Slack Connect, và vì hot spot. Họ chuyển sang Vitess, đổi khoá shard theo dữ liệu (ví dụ channel id). Năm 2020 Vitess phục vụ 99% traffic, đỉnh 2,3 triệu QPS, p99 11ms. Slack 2020

• 2018 · Dropbox: Edgestore (hàng nghìn node MySQL, 10 triệu request/giây) gom dữ liệu đi cùng nhau vào một colo/shard, nhưng quan hệ chia sẻ giữa người dùng không gom được; thêm transaction chéo shard bằng 2PC thay cho cơ chế tầng ứng dụng. Chỉ 5–10% transaction là chéo shard. Dropbox 2018

• 2019→2021 · GitHub: sau replica, ProxySQL và vài DB riêng, lõi vẫn là cluster mysql1. Họ dùng schema domain + linter query/transaction để tách ảo, rồi dời 130 bảng bận nhất một lần bằng write-cutover. Tải mỗi host giảm 50% dù traffic vẫn tăng (950K → 1,2M query/giây). GitHub 2021

• 2019 · Figma: một DB instance; tuyên bố cần một tầng DB scale ngang. Trên thực tế họ tách dọc trước (2020–2022), shard ngang sau (2023). Figma 2019

• 2019 · Tinder: một index Elasticsearch → 40–100 geoshard cân theo load score trên S2/Hilbert; một query 100 dặm chỉ chạm vài shard. Theo Tinder, xử lý được gấp 20 lần lượng tính toán. Tinder 2019

• 2019 · Tinder (triển khai): shard là index trong một cluster (không phải nhiều cluster) vì Elasticsearch sẵn query nhiều index; chốt cỡ bằng performance test từng biến. Document dời giữa shard khi user đổi vị trí, nên cần thứ tự ghi theo key qua partition Kafka, đọc nhất quán mạnh (GET + Index thay vì Reindex) và refeed từ nguồn sự thật. Tinder 2019 Tinder 2019

• 2019 · Atlassian: Jira gom tenant thành các nhóm nhỏ (shard) rải khắp thế giới, vẫn một DB mỗi tenant; ánh xạ tenant → vị trí nằm ở một service riêng (TCS). Atlassian 2019

• 2020→2022 · Figma: một RDS Postgres lớn nhất (CPU >65% giờ cao điểm) → replica, PgBouncer, DB mới cho tính năng mới → tách dọc khoảng 12 nhóm bảng, chọn bảng theo AAS (tác động) và mức cô lập. Figma 2023

• 2020→2021 · Notion: tín hiệu shard là vacuum kẹt và nguy cơ TXID wraparound. Shard ở tầng ứng dụng theo workspace ID, gồm mọi bảng nối tới block để giữ transaction; 480 shard logic / 32 DB (480 có nhiều ước số, nên thêm host từng bước nhỏ). Theo Notion: nên shard sớm hơn, vì chờ tới khi quá tải thì migration nào cũng phải tiết kiệm. Notion 2021

• 2020 · Riot Games (VALORANT): để chịu 2 triệu người mỗi shard, dữ liệu người chơi chia theo service sở hữu (mất transaction nguyên tử giữa các phần, phải dùng ledger, idempotency, trạng thái khoá trung gian), rồi trong mỗi service chia trước thành 64 bảng theo hash ID: thêm DB chỉ là dời bảng (2 × 32 → 4 × 16). Việc nền không gắn request chia thành 256 phần, instance tự nhận phần qua Redis. Riot Games 2020

• 2020 · Quora: Từ vertical sharding (chuyển bảng giữa partition, map trong ZooKeeper) sang horizontal sharding theo bảng, range-based, tên T_shard_x_y; chỉ ba bảng lớn cần shard; tách shard bằng EXCHANGE PARTITION. Quora 2020

• 2020→2022 · Etsy: Thanh toán từ bốn DB chưa shard (hai DB đã ở cấu hình GCP cao nhất) sang Vitess: 23 bảng, hơn 40 tỉ dòng, 40 shard. Ledger shard theo shop_id (thêm cột, backfill hàng tỉ dòng); DB thanh toán chính không phải cây nên dùng khoá sẵn có, reference_id làm shardifier đa hình thay vì thiết kế lại mô hình; chỉ chuyển bảng nóng nhất đã giảm 60% tải. Scatter query sau switch làm query tăng 40 lần, sửa bằng secondary (lookup) vindex. Etsy 2023 Etsy 2023 Etsy 2023

• 2020 · Asana: Shard theo domain (tenant) từ 2015 giúp đặt tenant vào vùng khác; phần khó là shard toàn cục (user, thành viên domain) mà mọi session cần. Asana 2020

• 2021 · Zerodha: shard DB 20 TB theo năm tài chính bằng postgres_fdw (loại Citus vì phải thêm cột vào mọi bảng): snapshot EC2 thành shard, xoá partition năm cũ trên primary và thay bằng foreign table; xong dưới hai giờ, không đổi schema; dữ liệu cũ dời sang máy rẻ hơn mỗi năm. Zerodha 2021

• 2022→2024 · Figma: một số bảng vài TB, tỷ hàng: vacuum gây sự cố, sắp vượt IOPS tối đa của RDS. Họ shard ngang trên RDS Postgres:

  • colo (nhóm bảng chung khoá shard);
  • hash khoá shard;
  • shard logic bằng view trước, vật lý sau;
  • DBProxy hỗ trợ một tập SQL phủ ~90% query.

• 2022→2024 · Cloudflare: tách dọc dữ liệu DNS (40% dung lượng) khỏi cluster Postgres dùng chung cfdb; tách khái niệm "zone" khỏi "record" là phần khó nhất; bảng mới partition theo mod(zone_id, n). Cloudflare 2024

• 2022→2023 · Buildkite: chuẩn bị shard DB Pipelines theo organization ID thì đổi khoá chính bảng mới sang UUIDv7 để khỏi phải phối hợp sinh số nguyên giữa các DB; chưa cần nhét số shard vào ID. Buildkite 2023

• 2022→2023 · Notion: 32 shard Postgres vượt 90% CPU, gần trần IOPS, PgBouncer chạm giới hạn kết nối. Reshard lên 96 máy nhỏ hơn bằng cách dời logical schema (15 → 5 mỗi máy), logical replication (bỏ index lúc chép: 3 ngày → 12 giờ), shard luôn tầng PgBouncer, dark read so kết quả, failover từng DB có replication ngược để lùi. Không downtime nhận thấy; chia nhỏ hơn làm lộ rõ workspace ngoại lai. Notion 2023

• 2022 · Slack: query theo khoá không phải shard key (thành viên của một GDM trên bảng shard theo user) thành scatter query hỏi mọi shard; bình thường bị cache che, khi cache mất thì nhân tải lên N lần và gây sự cố 2-22-22. Sửa bằng đọc từ bảng shard theo channel (dữ liệu ghi theo hai khoá). Slack 2022

• 2023 · Twitter: URS từng xây trên Gizzard (framework shard MySQL của 2010–2013) được chuyển sang MySQL + Vitess; VTGate (proxy stateless, hàng trăm instance trên Mesos) dùng chủ yếu để scale đọc lên hàng triệu QPS. Twitter 2023

• 2023 · etcd: (hướng dẫn của maintainer) quota DB mặc định 2 GB, khuyến nghị tối đa 8 GB vì boltDB map cả file vào bộ nhớ; vượt quota là mất khả năng ghi. Khi một loại dữ liệu chiếm áp đảo (ví dụ khoảng 971.000 Kubernetes event so với 51.000 pod), tách nó ra cụm etcd riêng bằng --etcd-servers-overrides thay vì chỉ tăng quota. OpenAI đã làm vậy ở 2.500 node năm 2018. etcd (CNCF) 2023

• 2023 · Stripe: DocDB (MongoDB, hơn 2.000 shard) có Data Movement Platform migrate từng chunk giữa shard: import theo thứ tự index (ghi nhanh 10 lần), replication hai chiều qua CDC, chuyển traffic bằng version token dưới 2 giây; dùng để tách, gộp shard dùng ít (1,5 PB, giảm khoảng 3/4 số shard năm 2023), nâng phiên bản, đổi tenancy. Stripe 2024

• 2024 · Inngest: shard queue chính quá tải CPU làm mọi thao tác chậm; dựng công cụ dời account giữa các shard queue, thử trên account của chính mình rồi chuyển khách theo lô. Account đã chuyển có P95 10–50 ms. Inngest 2024

• 2024 · Neon (nhà cung cấp): database-per-user ở mức cô lập nhất là mỗi khách một bản sao toàn bộ hệ thống; theo Neon chỉ đáng khi có data residency hoặc khách cần tự quyết nhịp nâng cấp, không nên vì tuỳ biến riêng. Neon 2024

• 2025 · Notion: khoá workspace ID và kiến trúc "nhiều mạng cô lập" được tái dùng cho data residency: thêm region là thêm ô, cùng mẫu với Shopify pod. Notion 2026

• 2026 · Uber: placement shard trong M3DB: từ rải tự do (blast radius gần cả cụm) sang subcluster sở hữu lát shard riêng; thuật toán tham lam chọn shard nhường đi để tránh skew; giữ interface cấp instance để tránh "bootstrapping storm". Uber 2026

  Bảng đầu tiên mất 9 tháng. Figma 2024

• 2026 · Inngest: queue trên FoundationDB chia logical shard khoảng 20.000 account; ánh xạ account → shard cache trong Redis. Dời account trong cùng database chỉ đổi quyền sở hữu (không chép item); khác database thì chép kèm ID ổn định và xử lý trùng. Inngest 2026

• 2026 · PlanetScale (tổng quan lịch sử): YouTube: một primary → replica → shard trong ứng dụng → tách tầng định tuyến thành Vitess (khoảng 2010); Facebook 2008 có khoảng 1.800 node MySQL shard theo user. Postgres đi sau: PL/Proxy của Skype (2007), shard logic của Instagram (2012), Citus (2011/2016). PlanetScale 2026

• 2026 · Trigger.dev: tách theo nóng/lạnh thay vì theo khoá: 99% run xong trong 8,4 ngày, nên run cũ ở lại DB cũ, run mới ở DB mới; ID mới mang ký tự region và version để định tuyến. Lý do phải tách: đĩa NVMe lớn nhất (60 TB) không chứa nổi 56 TB đang tăng. Trigger.dev 2026

• 2026 · Atlassian: hơn 300 cụm OpenSearch (1,7 PB): tách tenant lớn khỏi index dùng chung và tăng shard khi tenant lớn lên là việc hằng ngày, nên dựng AOSC để resharding online; routing key tuỳ chỉnh làm phức tạp việc phát lại delete. Atlassian 2026

• 2026 · TigerBeetle: phản biện sharding cho OLTP có tranh chấp: sharding phá cache locality của giao dịch chéo key và đụng định luật Amdahl; theo TigerBeetle, một cụm ngang khoảng 1 triệu USD/năm thua một node Postgres khi tranh chấp 10%, thậm chí 1% hay 0%. TigerBeetle 2026

• 2026 · PlanetScale: một lý do khác cho sharding: database rất lớn có backup quá 12 giờ và restore mất nhiều ngày; Neki chia Postgres thành shard để mỗi shard backup và restore độc lập (theo PlanetScale). PlanetScale 2026

• 2026 · Redis: Redis Cluster chia key vào 16.384 hash slot; resharding là dời slot. Trước 8.4 dời từng key bằng MIGRATE (redirect -ASK, TRYAGAIN cho lệnh nhiều key, lỗi giữa chừng để lại trạng thái phải xử lý tay); 8.4 chép cả slot rồi chuyển quyền nguyên tử: theo benchmark của Redis, 3 → 4 shard trong 6,4 giây, nhanh tới 30 lần. CLUSTER SLOT-STATS cho biết slot nào nóng. Redis 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Thứ tự kinh điển: scale dọc → replica → tách dọc → shard ngang. Figma và GitHub đi đúng thứ tự này; mỗi bước mua thêm đường băng cho bước sau.
2. Tách logic trước, tách vật lý sau. GitHub dùng linter; Figma tách PgBouncer rồi mới tách dữ liệu, và dùng view trước khi tách vật lý; Instagram tạo nhiều shard logic hơn số máy.
3. Khoá shard là quyết định đắt nhất. Khoá theo thời gian (Twitter) và theo khách hàng (Slack) đều tạo hot spot về sau. Xem Hot partition và thundering herd.
4. Có thể giữ engine quen thuộc và thêm một tầng phía trên: Slack/GitHub giữ MySQL + Vitess, Figma giữ Postgres + DBProxy. Lý do chung: chuyên môn vận hành nhiều năm và hàng nghìn query đang có.
5. Chỉ hỗ trợ một tập con có chủ đích (Figma bỏ transaction xuyên shard) để dự án làm xong được.
6. Shard xong chưa phải là cô lập lỗi. Code lặp qua mọi shard thì một shard hỏng là hỏng tất cả; cần mỗi request chỉ chạm một shard/pod (Shopify), và placement có giới hạn phạm vi (Uber subcluster).
7. Tầng sharding tự xây có vòng đời: Gizzard (Twitter 2010) được thay bằng Vitess (2023), cũng là lựa chọn của Slack và GitHub.
8. Bảng tra cứu shard là điểm hỏng chung tiềm ẩn (index DB của Etsy). Gán shard bằng thuật toán (hash) thì bỏ được bảng tra; dữ liệu cũ có thể tra qua bản copy chỉ đọc trên từng node.
9. Chọn khoá shard theo mẫu truy vấn tự nhiên (Tinder: vị trí với bán kính tối đa) và cân theo tải thực.
10. Khoá shard có thể đổi giá trị thì dời shard là việc thường ngày. Cần thứ tự ghi theo key (partition Kafka), đọc nhất quán mạnh ở cả kho ánh xạ lẫn kho đích, và cách dựng lại từ nguồn sự thật (refeed). Tinder 2019
11. Chia theo trục thời gian khi truy cập dồn vào dữ liệu gần: Zerodha 2021 tách năm tài chính cũ sang máy rẻ bằng postgres_fdw, gần như không đổi query.
12. Chưa cần shard thì đừng shard: scale up cộng cache, denormalize vẫn đủ cho một lớp bài toán khá lớn (Stack Overflow 2009, vẫn đúng năm 2016).
13. Thời gian backup và restore cũng là lý do để chia nhỏ: một máy quá lớn để restore kịp thì chia shard để mỗi phần backup và restore độc lập (PlanetScale Neki 2026). PlanetScale 2026

Câu hỏi mở

• Sharding có hợp với OLTP tranh chấp cao không? TigerBeetle 2026 cho rằng với tranh chấp chỉ 1–10%, một cụm shard đắt vẫn thua một node Postgres, và đề xuất scale dọc phần nóng + tiering phần lạnh (TigerBeetle 2026). Các nguồn khác (Figma, Slack, GitHub) shard thành công nhưng workload ít giao dịch chéo shard. Đây là bài của nhà cung cấp và benchmark không công bố trong bài, nên chưa kết luận.
• Discord chọn đổi DB (Mongo → Cassandra → Scylla), còn Figma/Slack giữ engine và thêm proxy. Một phần câu trả lời: Discord có mô hình dữ liệu đơn giản (tin nhắn theo kênh), Figma có mô hình quan hệ phức tạp (Figma 2024). Cần thêm nguồn để kiểm chứng. Xem Chọn database theo workload.
• Resharding khi đang chạy: đã có Shopify Pod Mover (dời cả pod trong khoảng một phút, Shopify 2018) và Uber (nhường shard tránh skew, Uber 2026). Notion 2023 kể đầy đủ một lần reshard 32 → 96 không downtime bằng dời logical schema, logical replication và replication ngược (Notion 2023). Còn thiếu chi tiết kỹ thuật của Pod Mover và bài Slack về chuyển cả shard.
• Liên hệ: Hạ tầng tìm kiếm (shard index tìm kiếm), Query planner và hiệu năng truy vấn (vắt kiệt một DB: plan, thống kê, index trước khi chia).
• Liên hệ: Multi-tenancy và cô lập tenant (shard theo tenant: pod, DB mỗi tenant, tách tenant lớn, dời tenant giữa shard).