A Decade of Evolution of Alibaba's Databases - Part 1

Alibaba · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài là hồi ký của một trưởng nhóm database, viết nhân dịp Double 11 lần thứ 10 (2018, GMV hơn 30,8 tỷ USD). Phần lớn là trải nghiệm cá nhân; wiki chỉ lấy các mốc kỹ thuật. Phần 2: Alibaba 2019.

Bối cảnh

Double 11 tạo ra một đỉnh tải cực lớn đúng 00:00, và chính đỉnh đó định hướng công nghệ database của Alibaba suốt một thập kỷ.

Thay đổi chính

• Ba giai đoạn (theo Alibaba):
  1. 2005–2009, database thương mại: IBM minicomputer, Oracle, storage EMC ("IOE"). Một máy chủ, không có khả năng chịu thảm hoạ.
  2. 2010–2015, mã nguồn mở ("De-IOE"): middleware phân tán TDDL, AliSQL (nhánh MySQL), server x86 và SSD thay cho IOE. Nhờ đó họ scale out được, tự thêm tính năng vào kernel (vá hot row cho tồn kho, throttle SQL, thread pool), và triển khai active-active xuyên thành phố.
  3. 2016 trở đi, tự phát triển: X-DB, nhắm tới một database phân tán toàn cầu kiểu Spanner. Lý do: hiệu năng đọc/ghi lúc 00:00, chi phí SSD khi dữ liệu nóng và lạnh lẫn với nhau, và phần cứng mới (NVM, RDMA, FPGA).
• 2012, sự cố: lúc 00:00, tải lên DB tồn kho vượt năng lực và NIC của DB hàng hoá bị đầy băng thông. Đội chỉ biết chịu trận cho qua đỉnh. Hậu quả là bán vượt tồn kho hàng loạt, nhiều team mất hai tuần xử lý. Khi đó chưa có stress test toàn hệ thống; dung lượng ước theo kinh nghiệm của trưởng nhóm.
• 2013, hai thay đổi:
  • Hot row tồn kho: nhiều người cùng trừ tồn kho một sản phẩm, tức là cùng update một dòng dưới row lock. Kernel có hai cách giải, xếp hàng và kiểm soát đồng thời, cùng một ý: biến tranh chấp hỗn loạn thành hàng đợi có thứ tự.
  • Full-link stress test trên production bằng shadow table: dữ liệu test ghi vào bảng bóng song song trong hệ thống thật. Gần như đêm nào trước Double 11 cũng chạy. Có lúc ghi sai dữ liệu, ảnh hưởng báo cáo hôm sau, và làm hao tuổi thọ máy, SSD.
• Từ 2016, chi phí cho đỉnh tải:
  • dùng ECS trên public cloud cho Double 11;
  • chạy lẫn online và offline: ngày thường job offline chạy trên máy online; Double 11 thì online mượn tài nguyên offline. Điều kiện là tách compute khỏi storage ở tầng DB.
• 2017: bắt đầu tự động tối ưu SQL.

Vì sao (theo Alibaba)

Mỗi kỳ Double 11 đặt ra yêu cầu mà database thương mại rồi mã nguồn mở không đáp ứng được. Tự kiểm soát kernel cho phép vá đúng chỗ đau (hot row) và đưa chi phí đỉnh tải xuống.

Bài học cho SWE

• Đỉnh tải biết trước (Double 11, ngày lương của Monzo, World Cup của Twitter) là động lực mạnh nhất cho thay đổi kiến trúc. Sự cố năm đầu (2012) dẫn tới stress test toàn hệ thống năm sau.
• Hot row (một sản phẩm, một dòng) là dạng cực đoan của hot partition: shard thêm không giúp gì. Alibaba xếp hàng có thứ tự trong kernel; Shopify 2025 đi hướng khác: tách tồn kho thành nhiều dòng (mỗi đơn vị một dòng) và dùng SKIP LOCKED để khỏi tranh chấp một dòng (Hot partition và thundering herd).
• Stress test trên production bằng shadow table đổi được độ chính xác lấy rủi ro làm bẩn dữ liệu thật.
• Lộ trình thương mại → mã nguồn mở + middleware → tự phát triển là một ví dụ của Chọn database theo workload ở quy mô cực lớn.

Liên quan

• Chọn database theo workload
• Hot partition và thundering herd
• Sự cố và postmortem
• Cùng nhóm công ty: Ele.me 2020