Chọn database theo workload

Bài toán

Không có database tốt nhất, chỉ có database hợp với mẫu đọc/ghi ở một quy mô cụ thể. Mẫu đó thay đổi khi sản phẩm lớn lên. Ngoài ra, chuyên môn vận hành của đội cũng là một phần của "workload".

Diễn tiến theo thời gian

• 2005→2016 · Alibaba: thương mại (IBM/Oracle/EMC) → "De-IOE" sang MySQL tự sửa (AliSQL) + middleware TDDL để scale out và tự vá kernel (hot row, throttle SQL) → tự phát triển X-DB nhắm kiểu Spanner. Mỗi bước do đỉnh tải Double 11 và chi phí lưu trữ dẫn dắt. Alibaba 2019

• 2009 · Stack Overflow: giữa lúc mọi người đổ sang NoSQL, giữ SQL Server. Theo HighScalability: NoSQL bắt lập trình viên tự viết aggregate, secondary index, giao dịch vượt một record, tự cập nhật mọi bản denormalize khi lỗi giữa chừng; chỉ đáng khi cần ghi khối lượng rất lớn. Stack Overflow 2009

• 2009 · LinkedIn: Voldemort theo hướng Dynamo vì không có GFS độ trễ thấp để làm Bigtable; không cố thay Hadoop, DB quan hệ hay search. LinkedIn 2009

• 2011 · Instagram: cân nhắc vài giải pháp NoSQL, cuối cùng giữ Postgres và tự shard. Instagram 2011

• 2011 · Twilio: lưu trữ dữ liệu là bài toán khó nhất của SaaS cần scale; khuyên tách thành phần có/không trạng thái, tránh lưu khi được, archive mạnh tay, chọn SQL hay KV/S3 theo bài toán. Twilio 2011

• 2011 · Pinterest: giai đoạn tăng gấp đôi mỗi 1,5 tháng chạy năm công nghệ DB với 3 kỹ sư, mỗi cái hỏng một kiểu; kiến trúc lại về MySQL, Redis, Memcache, Solr theo tiêu chí trưởng thành, đơn giản, ít kiểu hỏng. Ca tệ nhất của clustering: secondary mới tự nhận là primary ở 80%, mất 20% dữ liệu không biết phần nào. Pinterest 2013

• 2011→2015 · LinkedIn: Oracle (đắt, ALTER TABLE cần DBA, failover có downtime) + Voldemort → Espresso: document store trên MySQL/InnoDB, partition key quyết định phạm vi transaction, secondary index cập nhật đồng bộ, change stream gốc qua Databus; khoảng 30 ứng dụng năm 2015. LinkedIn 2015

• 2011 · Pinterest: Sau khi vài hệ NoSQL hỏng nặng năm 2011, chọn MySQL trưởng thành, lưu object dạng JSON blob để thêm field không cần ALTER; theo tác giả, startup nên tránh đồ mới. Pinterest 2015

• 2012→2017 · Grab: RDS MySQL từ đầu; phân tích đi MySQL → Redshift → data lake S3 + EMR + Presto. Theo Grab, dưới 10 kỹ sư vận hành toàn bộ nhờ managed service. Grab 2017

• 2012 · MemSQL: theo hai nhà sáng lập (cựu Facebook), Memcached đã giải đọc nhanh từ RAM còn ghi nhanh thì chưa; MemSQL giả định dữ liệu vừa RAM rồi chọn mọi thứ theo đó: lock-free, skip list thay B-tree, MVCC, SQL biên dịch sang C++. Cái giá lúc đầu: SQL hạn chế, chỉ READ COMMITTED, chưa có giao dịch xuyên shard. Benchmark của họ bị cộng đồng MySQL phản bác. MemSQL 2012

• 2012→2018 · Netflix: Lịch sử xem trên Cassandra (ghi:đọc khoảng 9:1): mỗi hội viên một wide row + EVCache, tới 2012 là một trong các cụm lớn nhất; tách LiveVH (gần đây, không nén) và CompressedVH (cũ, nén một cột, chunk khi lớn), gộp nền bằng ghi phiên bản mới rồi mới xoá cũ. Dữ liệu giảm khoảng 6 lần, latency đọc khoảng 5 lần. Netflix 2018

• 2012→2014 · LinkedIn: Pinot thay Oracle/Voldemort cho phân tích hướng member (Who's Viewed Your Profile, vài chục ms): kho cột, nén theo dimension, Kafka + Hadoop, segment theo thời gian. LinkedIn 2014

• 2013 · Instagram: hơn 100 lần tải mà vẫn Postgres; dùng tính năng sẵn có (partial/functional index, pg_reorg, WAL-E) thay vì đổi DB. Instagram xử lý phân mảnh do MVCC bằng pg_reorg, cũng là vấn đề Uber nêu năm 2016. Instagram 2013

• 2013 · Jepsen: Theo Kingsbury, Cassandra hợp ghi dữ liệu bất biến/dạng log (CQL set an toàn), không hợp cập nhật tại chỗ vì last-write-wins; counter lệch tới 50% khi partition. Jepsen 2013

• 2014 · SoundCloud: tự viết Roshi (khoảng 5.000 dòng Go) thay vì dùng Cassandra cho stream; theo SoundCloud, với bài toán hẹp và rõ, lời giải chuyên biệt rẻ hơn chi phí dịch bài toán sang hệ tổng quát và vận hành nó. SoundCloud 2014

• 2014 · Netflix: mỗi engine một vai trên cùng DW ở S3: Pig/Hive cho ETL production, Presto cho khám phá tương tác (cache không giúp vì truy vấn rời rạc trên 10 PB), Teradata cho báo cáo; Presto không làm được thì user quay về Hive/Pig. Chọn Presto sau benchmark bằng query thật của chính họ. Netflix 2014

• 2015→2017 · Discord: MongoDB một replica set, chọn cố ý để ra sản phẩm trong 2 tháng nhưng luôn chừa đường thoát. 11/2015 đạt 100 triệu tin thì dữ liệu + index không còn vừa RAM. Discord phân tích workload trước (đọc ngẫu nhiên, đọc/ghi 50/50, ba kiểu server rất khác nhau) và đặt yêu cầu (scale tuyến tính, tự failover, ít bảo trì, p95 dưới 80ms, không cache tin trong Redis). Chỉ Cassandra thoả hết. Discord 2017

• 2015 · Wix: "MySQL là NoSQL tốt hơn" cho bài toán key/value (URL → site): blob cho mọi trường không index, không join, không transaction, mỗi query đọc một dòng. Khoảng 100 triệu bản ghi mỗi bảng, đọc 1–1,5 ms, active-active 3 DC. Theo Wix, nhiều người chọn NoSQL vì hype mà quên chi phí vận hành. Wix 2015

• 2015 · Riot Games: chat LoL chọn MySQL lúc đầu vì quen; khi primary quá tải gặp đủ ba dấu hiệu: chỉ scale dọc được (FusionIO), SPOF, schema migration cần hàng giờ downtime. Xét MySQL shard, MySQL Cluster, Cassandra; chọn Riak (AP) và giải xung đột ghi bằng CRDT; slow query ở một shard từ hàng chục nghìn xuống dưới 50 mỗi ngày. Riot Games 2015

• 2015 · Airbnb: Nebula: delta store DynamoDB cho ghi realtime + snapshot HFile tĩnh cho dữ liệu lớn, gộp sau một API versioned; median khoảng 10 ms, đổi kho vật lý mà ứng dụng không biết. Airbnb 2016

• 2015 · Pinterest: Bài quan điểm của Marty Weiner: sau khi chạy cùng lúc bảy kho (MySQL, MongoDB, Cassandra, Membase, Redis...), Pinterest tái kiến trúc về MySQL; tiêu chí quan trọng nhất sau yêu cầu cơ bản là độ trưởng thành, đừng là người dùng lớn nhất của một công nghệ. Theo tác giả, chỉ MySQL chưa từng làm họ mất dữ liệu; nhưng không dùng MySQL cho feed, log, vector. Pinterest 2015

• 2016 · Uber: Postgres → MySQL (nền của Schemaless). Theo Uber, với Postgres 9.2:

  • khuếch đại ghi vì index trỏ vị trí vật lý;
  • replication vật lý tốn băng thông xuyên vùng;
  • một bug làm hỏng replica;
  • replica không có MVCC thật;
  • không nâng cấp được giữa các bản major.

  MySQL/InnoDB thắng nhờ index trỏ khoá chính, replication logic, buffer pool, thread-per-connection. Bài này gây tranh cãi và dựa trên bản cũ. Uber 2016

• 2016 · Dropbox: build vs buy. Với ~500 PB và tăng 12 lần trong 4 năm, họ rời S3 cho nội dung file và tự xây Magic Pocket. Theo Dropbox, lý do là hiệu năng (tuỳ biến cả stack) và unit economics, đồng thời vẫn giữ AWS ở nơi hợp lý (ví dụ dữ liệu ở châu Âu). Dropbox 2016

• 2016 · Zomato: feed từ Redis (khi đó thiếu HA phân tán) sang Cassandra; mẫu truy cập phải đổi thành đọc một lần vì latency kết nối Cassandra cao hơn khoảng 10–15 lần. Lần đầu thất bại vì EBS giới hạn IO. Zomato 2016

• 2016 · Expedia: DynamoDB với capacity đặt trước không hợp tải ảnh về theo đợt không đoán được độ lớn: vượt capacity gây lỗi (chỉ retry cứu dữ liệu), thời đó chỉ giảm capacity được bốn lần mỗi ngày, autoscaling cần 10 phút vượt ngưỡng. Team chuyển sang Aurora (hai năm sau một team khác của Expedia đi chiều ngược lại, Cassandra sang DynamoDB). Expedia 2016

• 2016 · Uber: số dư sổ cái cần nhất quán mạnh mà MySQL shard tự làm khi đó không bảo đảm được, nên dựng trên DynamoDB, mỗi thực thể một dòng khoảng 1 KB chứa mọi tài khoản con (dọn tài khoản số dư 0 để giữ cỡ dòng); về sau yêu cầu kiểm toán dẫn tới LedgerStore tự làm (bài 8/2026). Uber 2026

• 2016 · Medium: DynamoDB là kho chính nhưng có khoá nóng khi bài viral, nên Redis đứng trước; Aurora cho dữ liệu mới cần truy vấn linh hoạt; Neo4j (1 master, 2 replica) cho quan hệ người–bài–tag để gợi ý; Redshift cho phân tích. Medium 2016

• 2016 · Netflix (billing): tách một Oracle dùng chung theo nhu cầu nhất quán: subscriber sang Cassandra (multi-region; các thực thể liên quan gom vào một column family, đọc một lần ghi một lần để có tính nguyên tử), thanh toán cần ACID sang MySQL tự chạy trên EC2 vì RDS giới hạn 6 TB, Aurora còn beta, PostgreSQL thiếu người và chặn đường sang Aurora. Netflix 2016 Netflix 2016 Netflix 2016

• 2016→2018 · Netflix: Video preview và mở ra 130 nước làm kho lịch sử xem tăng 30% một quý; thương lượng với bên dùng dữ liệu nào cần ở mức chi tiết nào bao lâu, bỏ preview quá ngắn, ngôn ngữ chỉ lưu thay đổi, TTL ngắn cho dữ liệu tăng nhanh. Netflix 2018

• 2016→2023 · LinkedIn: LIquid: graph DB quan hệ, cạnh là bộ ba chuỗi, một writer append vào graph log, index băm wait-free trong RAM, Datalog; theo LinkedIn, property graph và triple store không có compound edge n-ngôi. 270 tỷ cạnh, 2 triệu query/giây (2023). LinkedIn 2020 LinkedIn 2020 LinkedIn 2023

• 2017→2023 · Discord: Cassandra 12 → 177 node, nhiều toil: hot partition, compaction tụt hậu, GC của JVM. Đến 2020 các DB khác đã sang ScyllaDB; cụm tin nhắn đi cuối cùng (5/2022), còn 72 node, p99 đọc 40–125ms → 15ms. Discord 2023

• 2017→2018 · Alibaba: tách compute khỏi storage cho DB để mượn tài nguyên co giãn dịp đỉnh tải (dời compute không phải dời dữ liệu); điều kiện là mạng nhanh: 25 Gbit/s rồi RDMA. Alibaba 2019

• 2017 · Walmart: theo Walmart, với Cassandra thì thiết kế schema có tác động lớn nhất; phải "quên" thói quen RDBMS: tránh đọc/ghi cả hàng, tránh đọc-sửa-ghi collection (tombstone), và tách Solr ra khỏi cụm Cassandra (cuối cùng thay bằng SolrCloud). Walmart 2017

• 2017 · LinkedIn (Venice): Voldemort Read-Only (đẩy batch bất biến từ Hadoop) → Venice phục vụ cả batch lẫn stream: storage node không nhận ghi online, chỉ ingest từ Kafka, nên mất hết replica vẫn dựng lại được; dùng Helix chung với Espresso. LinkedIn 2017

• 2018 · Slack: JSON blob trong một bảng nóng (55 KB+) gây tải cho bảng dùng chung và làm cache bị invalidate cả khối; chuyển sang EAV (mỗi tuỳ chọn một hàng). Slack 2018

• 2018 · Expedia: đánh giá Cassandra → DynamoDB: đổi khả năng tinh chỉnh (latency dưới 1 ms, batch nguyên tử) lấy vận hành managed và capacity planning tính được (khi đó 3.000 RCU / 1.000 WCU mỗi partition). Không nên chuyển nếu cần latency rất thấp, item lớn, hay soi được hot spot. Expedia 2018

• 2018 · SoundCloud: bộ đếm lượt nghe theo Lambda Architecture tăng dần trên Cassandra (SSTable cho batch, counter cho realtime); thử database cột, Fenwick tree, dịch vụ có trạng thái trên Kafka đều không đủ latency mili giây hoặc quá phức tạp, nên giữ thiết kế cũ. SoundCloud 2018

• 2018 · Alibaba: theo Alibaba, PolarDB (cùng hướng Aurora) chọn một writer, nhiều reader trên storage dùng chung thay vì database phân tán ghi đa điểm, vì đủ cho đa số OLTP mà né được độ phức tạp phân tán. Alibaba 2018

• 2018 · Walmart: nhánh stream của dashboard còn hàng cần kho chịu upsert dày (tới khoảng 100 MB/giây) mà vẫn quét toàn bảng mỗi 6 giờ; chọn Cassandra, theo Walmart vì RDBMS không cho upsert và đọc đủ ổn định và team đã quen Cassandra. Walmart 2018

• 2018 · Netflix: dữ liệu observability chọn kho theo cách đọc và tốc độ ghi; một tập dữ liệu để ở Elasticsearch cho dễ index nhiều trường, khi ghi tăng thì index chậm tới mức dữ liệu chưa có lúc query, chuyển sang Cassandra với ba khoá đọc định sẵn; dữ liệu cũ giữ ở Hive (rẻ nhưng phải quét). Netflix 2018

• 2018 · Bumble: kho lỗi client chọn Elasticsearch thay vì ClickHouse dù ClickHouse ghi nhanh và nén chuỗi tốt hơn: đầu 2018 ClickHouse chưa có xoá và cập nhật theo điều kiện (cần cho giữ sáu tháng và pipeline xử lý bất đồng bộ) và full-text search; đã có sẵn cụm Elasticsearch cho log. Cái giá: JVM và GC (gặp khi nâng 6.8 → 7.5), nén chuỗi kém. Sentry sau đó chuyển sang ClickHouse. Bumble 2020

• 2018 · LinkedIn: đồ thị phụ thuộc phần mềm (1,3 tỷ node, 4,8 tỷ cạnh) bỏ graph DB thương mại sang Espresso: đồ thị mỗi version bất biến và query biết trước, nên tính sẵn (cả chiều ngược) và lưu document là đủ. LinkedIn 2018

• 2019 · Walmart: lớp đọc lịch sử đơn hàng chia truy vấn thành bốn hình dạng, mỗi hình dạng một kho trên Azure: tra khoá và lọc metadata → Cosmos DB, facet/group-by → Azure Search (latency cao), tổng hợp streaming → Databricks; Azure SQL bị loại vì không scale trong test. Walmart 2019

• 2019 · Airbnb: scheduler job hẹn giờ chỉ cần "tìm job quá hạn rồi đẩy đi": đúng hình dạng partition key + sort key của DynamoDB; 1.000 QPS với dưới 1/3 chi phí instance RDS chạy Quartz, chỉnh throughput theo mùa. Airbnb 2019

• 2020 · CapitalOne: phân loại kho trước khi chọn mô hình nhân bản: system of record, system of reference, read-only, nội dung tĩnh, cache, session state; mức hợp với active-active tăng dần theo thứ tự đó. CapitalOne 2020

• 2020 · Walmart: Retail Graph: trích và liên kết thực thể chạy batch trên Hadoop on-prem (thư viện → REST API và Hive UDF), nạp hàng loạt vào Cosmos DB trên Azure; so LPG với RDF, chọn LPG. Walmart 2020

• 2021 · Quora: HBase → MyRocks. Lý do dài hạn là gom về một họ công nghệ để dùng chung kiến thức và công cụ với MySQL; p99 một bảng giảm ~80ms → dưới 4ms. Quora 2021

• 2021 · Wix: Cassandra tự quản (partition theo chatroom bị hot spot, phải thêm secondary index và materialized view, ít người biết vận hành) → DynamoDB. Theo Wix: hiểu dữ liệu trước, gác công nghệ quen sang một bên. Wix 2021

• 2021 · CapitalOne: đổi PostgreSQL sang DynamoDB chỉ vì một thuộc tính (active-active đa region); trả giá bằng thiết kế bảng theo access pattern, không có null và kiểu ngày, kém cho reporting. CapitalOne 2021

• 2021 · Zerodha: workload ghi theo đợt (99% ghi ban đêm) cho phép tắt autovacuum và tự vacuum theo cron, bỏ foreign key và ID tự tăng, denormalize để tránh JOIN trên bảng tỷ dòng; theo Zerodha, phần lớn vấn đề RDBMS là index và vacuum chứ không phải thiếu database phân tán. Zerodha 2021

• 2021 · PayPal: quan hệ giữa tài khoản quá lớn để duyệt bằng DB quan hệ; vendor và dự án mã nguồn mở graph không đạt scale/latency nên tự xây graph DB real-time: Gremlin làm ngôn ngữ query, tầng lưu trữ viết lại trên Aerospike, tách ba tầng real-time / interactive / analytics theo latency PayPal 2021

• 2022 · Grab: từ ghi đồng bộ vào DynamoDB + Aurora và giữ mãi, sang tách OLTP/OLAP:

  • DynamoDB cho đơn đang chạy (GSI dạng sparse, TTL 3 tháng, adaptive capacity cho hot key);
  • MySQL RDS cho lịch sử (partition theo tháng, giữ 6 tháng);
  • Kafka nối hai bên, xử lý trùng và sai thứ tự.

  Grab 2022

• 2022 · Gojek: dịch vụ tìm tài xế: Postgres không chịu được vị trí cập nhật vài giây một lần (re-index mỗi lần ghi) → Redis Cluster với lọc geo bằng Lua; chọn PA/EL, đổi tính đầy đủ lấy availability và latency. Gojek 2022

• 2022 · Doximity: câu hỏi đồ thị (bạn cấp 1–2, đồng nghiệp chung) đưa sang Neo4j cạnh DB quan hệ; cụm 1 leader ghi + 2 follower đọc, client chỉ được đọc (header access mode), ghi đi qua Kafka. Doximity 2022

• 2022 · Discord: Workload đọc nhiều nên chỉ tối ưu latency đọc của ScyllaDB, chấp nhận ghi chậm và không resize nóng; chọn đĩa theo đúng chiều đó (đọc Local SSD, bền nhờ Persistent Disk). Discord 2022

• 2023 · Twitter: bỏ framework tự xây Gizzard, chuyển sang MySQL + Vitess vì SLO và chi phí bảo trì. Twitter 2023

• 2023 · Deno: Deno KV xây trên FoundationDB (sharding, replication, serializable đã kiểm chứng) và tự thêm transaction layer cho cấu hình theo tenant, kiểu dữ liệu JS, giao dịch không tương tác. Deno 2023

• 2024 · Figma: loại CockroachDB, TiDB, Spanner, Vitess và NoSQL. Theo Figma: mô hình quan hệ phức tạp, chuyên môn RDS Postgres tích luỹ nhiều năm, chỉ còn vài tháng đường băng. Họ hẹn đánh giá lại NewSQL khi có thời gian. Figma 2024

• 2024→2026 · Inngest (vì sao đổi): viết tiêu chí trước (đúng trong điều kiện thật, scale ngang, cách ly noisy neighbor, vận hành rẻ, quay lui được giữa rollout) rồi mới so. Chọn FoundationDB vì ACID ghi xuống đĩa, đa luồng, đường đọc tách khỏi đường ghi, đã kiểm chứng ở Apple và Snowflake. Inngest 2026

• 2024 · Trigger.dev: dùng Postgres làm job queue (Graphile Worker) được, tới khi vacuum không theo kịp bảng có tỷ lệ xoá cao. Năm 2026 họ rời Aurora sang Postgres trên NVMe cục bộ (PlanetScale Metal), vì trên ổ mạng vacuum tranh I/O với production và đổi tham số phải reboot cả cụm. Trigger.dev 2024 Trigger.dev 2026

• 2024 · TigerBeetle: theo TigerBeetle, database đa dụng (Postgres, MySQL, SQLite) không scale được workload ghi sổ kép vì khoá dòng giữ qua round-trip tới ứng dụng; họ dựng database riêng với debit/credit là primitive, 8000 giao dịch mỗi request, chạy trong deterministic simulator. Đây là lập luận của nhà cung cấp, chưa có so sánh trên cùng workload. TigerBeetle 2024

• 2025 · Shopify: chiều ngược với "dùng kho chuyên dụng cho tốc độ": đưa reservation từ Redis về MySQL để có ACID với sổ tồn kho, nhờ SKIP LOCKED (trước đây không làm được). Theo Shopify, DB đang có có thể đủ cho loại khoá loại trừ lẫn nhau với throughput cao. Shopify 2026

• 2025 · Airbnb: data warehouse cho ba trụ sản phẩm: tách mô hình cho khái niệm đặc thù (listing, availability), gộp cho khái niệm xuyên suốt (thanh toán, tin nhắn); cấm mô hình lai. Airbnb 2025

• 2025 · Cloudflare: Workers KV có hàng trăm tỷ giá trị, trung vị 288 byte: với object dưới 1 KB, database hiệu quả hơn object storage, nên backend mới là distributed database (shard nhiều cụm, nhân 3), object lớn tới 25 MiB tự chuyển sang R2. Cloudflare 2025

• 2025 · PlanetScale: khi chọn giữa Postgres và MySQL, xét cả cách CDC tương tác với HA: slot của Postgres có thể ghim WAL và chặn switchover, GTID của MySQL thì không. Theo PlanetScale. PlanetScale 2025

• 2025 · Cockroach Labs: cùng một LSM, workload value lớn (hàng rộng, JSONB) trả giá compaction cao hơn hẳn; Pebble tách value lớn ra blob file (v25.4) và tách sớm phiên bản MVCC cũ, nhưng truy vấn AS OF SYSTEM TIME của optimizer ăn bớt phần lợi. Cockroach Labs 2026

• 2025 · Mercari: chọn DB cho Global App bằng ma trận 11 tiêu chí có trọng số rồi YCSB (200 triệu dòng, CPU khoảng 65% cho mọi DB): AlloyDB thắng latency, throughput và giá; Spanner giữ cho phần cần nhất quán mạnh toàn cầu; CockroachDB để xét sau (p99 dao động, vận hành phức tạp hơn). Lý do chiến lược: tránh khoá vào Google Cloud, dùng hệ sinh thái PostgreSQL. Mercari 2025 Mercari 2025

• 2026 · Inngest: queue từ Valkey (RAM, thao tác đơn luồng) sang FoundationDB (transaction, trên đĩa): backlog lớn không còn là "khẩn cấp về bộ nhớ", nhiều executor lấy việc song song được. Inngest 2026

• 2026 · PlanetScale (nhà cung cấp): trục shard tường minh hay tự động: theo họ, Spanner, CockroachDB, Yugabyte giấu khoá shard nhưng khó đoán vị trí dữ liệu và latency, và không phải Postgres thật. PlanetScale 2026

• 2026 · TigerBeetle: lập luận cho database chỉ làm OLTP (debit/credit, số nguyên thay vì chuỗi), working set nóng trong một replicated state machine scale dọc, dữ liệu lịch sử trên object storage ("diagonal scaling"). Bài của nhà cung cấp. TigerBeetle 2026

• 2026 · GitHub: thay mô hình N bản repo trên đĩa cục bộ bằng object storage (Azure Blob) làm lớp bền, compute tối ưu cho thông lượng và latency; mất một worker chỉ như cache miss thay vì dựng lại bản sao. GitHub 2026

• 2026 · ScyllaDB: API tương thích DynamoDB không đủ: SDK của AWS giả định một endpoint managed nên dồn mọi request vào một node ScyllaDB. Driver Rust mới học topology và cân tải phía client, throughput cao hơn khoảng 58% (theo ScyllaDB, cụm 3 node). ScyllaDB 2026

• 2026 · Memgraph (nhà cung cấp): vector index nhúng trong graph DB thay cho vector store riêng: chung snapshot/WAL, khoá là con trỏ đỉnh, một bản vector; đánh đổi là giành RAM với đồ thị (bản 3.8.0 giảm 66–76% RAM so với bản trước). Memgraph 2026

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

Quy tắc rút ra

1. Phân tích mẫu truy vấn và traffic, viết yêu cầu, rồi mới chọn DB (Discord 2017, Grab 2022).
2. Lựa chọn "để ra sản phẩm nhanh" là hợp lệ nếu biết mình đang vay nợ và có đường thoát (Discord với MongoDB).
3. Tách đường ghi nóng khỏi đường phân tích khi một DB không tối ưu được cả hai (Grab).
4. Chuyên môn vận hành là tài sản. Figma và Slack ở lại với engine quen thuộc vì lý do này.
5. Build vs buy phụ thuộc quy mô: dùng cloud khi còn nhỏ; tự xây chỉ khi quy mô và workload đặc thù đủ bù chi phí (Dropbox ~500 PB).
6. Đổi DB không tự giải quyết vấn đề truy cập. Discord nói hot partition vẫn có thể xảy ra trên Scylla nên thêm data service phía trên.
7. Lý do đổi DB của một công ty là đánh đổi trong bối cảnh của họ, không phải phán quyết về engine (Uber).
8. Retention là quyết định kiến trúc: giữ mọi thứ mãi mãi tốn tiền (Grab).
9. Xem lại quyết định cũ khi engine tiến bộ. Shopify đưa reservation từ Redis về MySQL nhờ SKIP LOCKED, điều không làm được 5 năm trước; Twitter thay Gizzard tự xây bằng Vitess.
10. Kho chuyên dụng cho tốc độ có thể làm mất tính nguyên tử với nguồn sự thật (Shopify: Redis và sổ tồn kho trên MySQL không cùng transaction).
11. Giảm số loại kho dữ liệu là lý do chính đáng để migrate (Quora HBase → MyRocks để dùng chung kiến thức và công cụ với MySQL; Shopify gom về MySQL).
12. Database tính theo capacity đặt trước hợp tải đều; tải đột biến không đoán được độ lớn thì cân nhắc hệ khác (Expedia 2016 rời DynamoDB sang Aurora). Giới hạn này thuộc về mô hình tính tiền thời đó, nên kiểm lại với phiên bản hiện tại. Expedia 2016

Câu hỏi mở

• Uber chọn MySQL, còn Instagram và Figma gắn bó với Postgres ở quy mô lớn. Từ toàn văn, các yếu tố Uber nêu (nhiều index + nhiều update, replication xuyên vùng, nâng cấp major) không được Figma nhắc tới; Figma thì dùng logical replication để nâng cấp major (Figma 2023). Có thể là do khác workload và Postgres đã tiến bộ sau 9.2, nhưng chưa có nguồn đối chiếu trực tiếp. Cần ingest phản hồi của cộng đồng Postgres năm 2016.
• Liên hệ: Vector search và index ANN (vector index nhúng trong DB hay kho riêng), Sharding và tách database, Hot partition và thundering herd, Query planner và hiệu năng truy vấn (plan sai vì thống kê trước khi kết luận phải đổi DB).