← Series hub ← Prev • Next →

Bài 4: Tầng Dữ liệu - Sự trỗi dậy của TiDB và NewSQL

Dù có bao nhiêu tầng Cache hay Queue, trạm dừng chân cuối cùng của mọi dữ liệu vẫn là Cơ Sở Dữ Liệu (Database) làm nguồn chân lý gốc (Source of Truth). Với hàng chục triệu đơn hàng và hàng tỷ bản ghi được sinh ra mỗi ngày, RDBMS truyền thống (như MySQL đơn độc) trở thành nút thắt cổ chai nguy hiểm nhất do kiến trúc B+Tree phình to khiến IOPS của ổ cứng chạm trần.

1. Nỗi khổ của MySQL Sharding

Trong giai đoạn trước đây, để mở rộng MySQL, Shopee (và các ông lớn khác) áp dụng kỹ thuật Database Sharding (Phân mảnh DB gốc).

  • Họ chia một bảng Orders khổng lồ ra hàng trăm DB vật lý. Ví dụ: Dùng thuật toán Hashing trên user_id (user_id % 100) để đẩy đơn hàng của user đó vào shard số 0 tới 99.
  • Cơn ác mộng phát sinh:
    • Nếu chia theo user_id, thì việc cho Seller (người bán) truy vấn tất cả đơn hàng của cửa hàng họ sẽ yêu cầu phải scan chéo qua hàng trăm DB (Scatter-Gather queries), cực kỳ chậm chạp.
    • Vấn đề Distributed Transactions (Giao dịch phân tán - 2PC) trở thành cực hình khi cần update dữ liệu liên quan nằm trên 2 DB khác nhau.
    • Khi cạn dung lượng và cần thêm DB vật lý mới, việc migrate chuyển dữ liệu mất hàng tháng trời lập trình và đối soát.

2. Giải pháp NewSQL với TiDB

Để chấm dứt sự khổ sở của việc tự viết code Sharding, Shopee đã dần chuyển đổi các core services sang TiDB - một cơ sở dữ liệu NewSQL mã nguồn mở. Nó mang lại khả năng mở rộng không giới hạn của NoSQL, nhưng vẫn giữ lại sức mạnh ACID và SQL của Relational DB.

Kiến trúc độc đáo của TiDB phân tách hoàn toàn tầng Tính toán (Compute) và Lưu trữ (Storage):

  • TiDB Server (Compute Layer): Đóng vai trò như các Node không trạng thái (Stateless). Chúng nhận câu lệnh MySQL từ app, parse SQL và lên kế hoạch thực thi (Execution Plan), sau đó gọi xuống tầng dưới. Tầng này có thể scale-out bằng cách thêm Docker container thoải mái.
  • TiKV (Storage Layer): Lưu trữ dữ liệu thực sự dưới dạng Key-Value phân tán. Dữ liệu được chia nhỏ thành các Region (kích thước khoảng 96MB).
  • Auto-Sharding & Replication: Thuật toán đồng thuận Raft đảm bảo mỗi Region luôn có 3 bản sao chép (Replica) trên 3 ổ cứng vật lý khác nhau. Khi dữ liệu lớn lên, TiKV tự động split vùng dữ liệu và phân bổ chúng đều ra các máy chủ mới cắm vào mà không cần kỹ sư viết một dòng code can thiệp nào.
graph TD
    App[Shopee Backend] -->|Standard MySQL Protocol| TiDB[TiDB Server<br/>(Stateless SQL Engine)]
    App -->|MySQL Protocol| TiDB2[TiDB Server 2]
    
    subgraph "TiDB Cluster (NewSQL)"
        TiDB --> PD[Placement Driver<br/>Routing & Metadata]
        TiDB2 --> PD
        
        PD -.-> TiKV1[(TiKV Node 1<br/>Raft Leader)]
        PD -.-> TiKV2[(TiKV Node 2<br/>Raft Follower)]
        PD -.-> TiKV3[(TiKV Node 3<br/>Raft Follower)]
        
        TiDB --> TiKV1
        TiDB2 --> TiKV2
        
        TiFlash[(TiFlash<br/>Columnar Storage for OLAP)] -.->|Raft Learner| TiKV1
    end

3. Kiến trúc HTAP (Hybrid Transactional and Analytical Processing)

Một “vũ khí” cực mạnh của hệ sinh thái TiDB là TiFlash. Thay vì phải dùng hệ thống ETL chạy xuyên đêm để bốc dữ liệu từ DB bán hàng sang Data Warehouse (ví dụ Snowflake/Hadoop) để làm báo cáo thống kê, TiFlash tự động copy dữ liệu từ TiKV (định dạng hàng - Row-based) sang định dạng Cột (Column-based) theo thời gian thực (Real-time). Điều này cho phép bộ phận vận hành Shopee có thể chạy các lệnh SELECT ... GROUP BY phức tạp phân tích hàng tỷ hóa đơn diễn ra trong ngày Flash Sale ngay lập tức, mà không làm treo các giao dịch mua hàng của người dùng.

Bài học cho Dev: Đừng tự tay “phát minh lại bánh xe” bằng cách viết code Sharding thủ công ở tầng Application nếu công ty không có đội ngũ khổng lồ bảo trì. Các giải pháp NewSQL như TiDB hoặc CockroachDB là xu hướng tương lai để xử lý Dữ liệu Lớn (Big Data) một cách trong suốt.