Một trong những case study kinh điển nhất trong giới Database Engineering là quyết định "động trời" của Uber vào năm 2016: Từ bỏ PostgreSQL (vốn được mệnh danh là RDBMS tiên tiến nhất thế giới) để chuyển toàn bộ dữ liệu cốt lõi sang MySQL. Tại sao một gã khổng lồ công nghệ lại đi lùi về một công nghệ tưởng chừng "kém cỏi" hơn?

Bài viết này sẽ mổ xẻ các nút thắt kỹ thuật mà Uber gặp phải với Postgres và bài học đắt giá về việc "Đừng tin vào Hype, hãy nhìn vào Use-case".

1. Kiến trúc sơ khai: Chuyến đi êm ả cùng Postgres

Ở giai đoạn đầu, Uber dùng PostgreSQL cho gần như mọi thứ. Nó hoạt động tuyệt vời. Postgres hỗ trợ PostGIS siêu mạnh để tính toán vị trí bản đồ (điều cốt lõi của Uber).

Nhưng khi lượng chuyến đi bùng nổ lên hàng triệu chuyến mỗi ngày, hệ thống bắt đầu bộc lộ những điểm yếu chí mạng liên quan đến cách PostgreSQL lưu trữ dữ liệu dưới đĩa cứng.

2. Nút thắt cổ chai #1: Kiến trúc MVCC của PostgreSQL

Để xử lý nhiều transaction đồng thời mà không bị lock lẫn nhau, các Database dùng kỹ thuật MVCC (Multi-Version Concurrency Control).

Khi bạn UPDATE một dòng trong MySQL, nó ghi đè trực tiếp lên dữ liệu cũ (hoặc ghi vào Undo Log). Nhưng ở PostgreSQL, khi bạn UPDATE, nó KHÔNG xóa dòng cũ. Nó tạo ra một dòng hoàn toàn mới (Row version mới) và ẩn dòng cũ đi.

Hậu quả tại Uber: Cứ mỗi giây, vị trí tài xế được update liên tục. Bảng driver_locations sinh ra hàng triệu "dòng rác" (dead tuples). Postgres có một tiến trình gọi là VACUUM để dọn dẹp đống rác này, nhưng tốc độ sinh rác của Uber nhanh gấp chục lần tốc độ dọn dẹp. Kết quả là ổ cứng đầy nhanh chóng và database chậm đi thảm hại.

3. Nút thắt cổ chai #2: Cập nhật Index khổng lồ (Write Amplification)

Đây là đòn chí mạng khiến Uber quyết định dứt áo ra đi. PostgreSQL liên kết Index trực tiếp tới địa chỉ vật lý của dòng dữ liệu trên đĩa. Giả sử bảng của bạn có 10 Indexes. Khi bạn update Cột A, Postgres tạo ra một dòng dữ liệu vật lý mới (do MVCC ở trên). Vì dòng vật lý thay đổi vị trí, Postgres phải CẬP NHẬT LẠI TOÀN BỘ 10 INDEXES để trỏ về vị trí mới, dù cho bạn không hề đụng chạm gì đến 9 cột kia!

Hiện tượng này gọi là Write Amplification (Khuếch đại thao tác Ghi). 1 lệnh UPDATE nhỏ bé sinh ra 10 lệnh UPDATE xuống đĩa cứng. Hệ thống I/O của Uber bị quá tải hoàn toàn.

4. Tại sao MySQL (InnoDB) lại giải quyết được?

MySQL (sử dụng engine InnoDB) có kiến trúc MVCC khác hẳn.

Thứ nhất, nó update dữ liệu "in-place" (ghi đè trực tiếp), nên không sinh ra dòng rác vật lý nhiều như Postgres. Thứ hai, các Secondary Indexes của MySQL không trỏ tới vị trí vật lý trên đĩa. Chúng trỏ tới Primary Key (ID) của dòng. Khi một dòng di chuyển vật lý trên đĩa, chỉ cần Primary Key không đổi, MySQL không cần cập nhật lại bất kỳ Secondary Index nào! Kết quả: Ở Uber, MySQL giảm thiểu Write Amplification xuống mức tối đa. Các lệnh UPDATE liên tục không làm hệ thống sập nguồn.

5. Uber tự xây dựng hệ sinh thái Schemaless trên MySQL

Tuy nhiên, MySQL không hoàn hảo (thiếu PostGIS, thiếu một số tính năng advanced). Để bù đắp, Uber đã xây dựng một lớp (layer) nằm phía trên MySQL gọi là Schemaless. Schemaless là một Datastore thiết kế riêng của Uber:

Client không gửi lệnh SQL trực tiếp. Dữ liệu lưu dưới dạng JSON blob. Schemaless tự động Sharding (phân mảnh dữ liệu) ra hàng ngàn server MySQL nhỏ lẻ bên dưới.

6. Bài học rút ra (Takeaways)

Câu chuyện của Uber không có nghĩa là MySQL tốt hơn PostgreSQL. Cả hai đều là những kiệt tác kỹ thuật. Thực tế, rất nhiều công ty khác (như Instagram, Reddit) vẫn dùng Postgres để xử lý hàng tỷ request mỗi ngày.

Bài học cốt lõi:

Hiểu sâu về Engine: Đừng chỉ học lệnh SQL. Hãy tìm hiểu xem DB lưu dữ liệu xuống đĩa cứng như thế nào (B-Tree, LSM Tree, MVCC). Write-heavy vs Read-heavy: Postgres cực kỳ mạnh ở các truy vấn phân tích phức tạp, JOIN nhiều bảng. Nhưng với Use-case của Uber (UPDATE cực kỳ nhanh và liên tục vào cùng một dòng - vị trí tài xế), kiến trúc của InnoDB (MySQL) lại vô tình phù hợp hơn rất nhiều.