Migration from HBase to MyRocks at Quora

Quora · 2021 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

• Quora có hai kho dữ liệu chính, MySQL (đã tự shard dọc và ngang) và HBase (key-value, 3 cluster để cô lập). Hai hệ rất phức tạp và không chia sẻ được kiến thức hay công cụ với nhau.
• HBase được truy cập từ Python và C++ (qua Thrift) với p99 rất "giật".
• Lý do chuyển sang MyRocks (MySQL + RocksDB): ngắn hạn là p99 đọc tốt hơn, ít timeout hơn; 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. Đây cũng là lý do chọn MyRocks thay vì một hệ RocksDB khác (Rocksandra, Rocksplicator). Họ được truyền cảm hứng từ việc Facebook cũng chuyển HBase sang MyRocks.

Thay đổi chính

• Schema: khoá chính (rowkey, column family, column, timestamp), tương ứng mô hình của HBase. Đơn giản và linh hoạt; đã cân nhắc rồi loại các phương án gộp cột vào JSON (khó versioning) hay mỗi column family một bảng. 64 shard cố định, shard theo hash của rowkey để cân tải.
• Mô phỏng tính năng của HBase:
  • TTL: dùng TTL của MyRocks với một cột ttl_ts; đặt timestamp lùi về quá khứ để mỗi column family có TTL riêng trong cùng một bảng;
  • versioning: cột ts, kèm job dọn bản cũ hằng ngày;
  • check-and-set: cột cas_version cùng hàng với giá trị để cập nhật nguyên tử.
• "dataservice" (gRPC) làm trung gian cho client C++.
• Bulk load: MyRocks không nhập được file SST, nên Spark sinh CSV rồi LOAD DATA. Để việc nạp không làm chậm lượt đọc: không dùng replication cho bulk load mà nạp lần lượt vào từng host trong partition, xoay thứ tự host để luôn đọc từ một host không đang nạp; khoá bằng ZooKeeper để không nạp đồng thời nhiều bảng; bảng load_data_status dùng khi khôi phục host.
• Quy trình migrate mỗi bảng: ghi kép → backfill bằng INSERT IGNORE (không đè dữ liệu ghi kép) → shadow read ~5% so sánh, log chỗ lệch → cắt sang MyRocks làm nguồn sự thật (vẫn ghi kép và đọc bóng HBase để quay lại được) → sau một thời gian mới xoá bảng HBase. Bảng đầu tiên giữ HBase thêm 6 tháng cho chắc.
• Tinh chỉnh:
  • một bảng thông báo lưu cả danh sách vào một cột (đọc–sửa–ghi lại cả danh sách, ghi vài TB/ngày cho một bảng vài chục GB), tách mỗi phần tử một cột thì giảm khuếch đại ghi vài bậc độ lớn; một bảng khác thì làm ngược lại (gộp danh sách) nên bulk load nhanh gấp ~8 lần;
  • IN (...) thay cho chuỗi OR; truy vấn theo khoảng thay cho danh sách IN dài (CPU ~25% → ~15%);
  • cấu hình InnoDB vẫn quan trọng: replication của MyRocks dùng bảng InnoDB nội bộ, đổi innodb_flush_log_at_trx_commit trên slave giảm hơn 60% CPU.

Kết quả

• p99 ổn định hơn hẳn: một bảng ~80ms → dưới 4ms; bảng đầu tiên hết ~50 lỗi timeout/phút.
• Hơn 85% QPS key-value đã đi qua MyRocks, còn hơn 100 bảng ít traffic trên HBase.
• Bonus: việc so sánh dữ liệu làm lộ một bug có sẵn trong một job offline cho kết quả không xác định.

Bài học cho SWE

• Giảm số loại kho dữ liệu là một lý do chính đáng để migrate: chia sẻ kiến thức và công cụ quan trọng ngang hiệu năng. Cùng tinh thần "chuyên môn vận hành là tài sản" trong Chọn database theo workload.
• Mẫu ghi kép → backfill → đọc bóng → cắt → giữ đường lui là mẫu chung (Slack 2020, Shopify 2026).
• Mô hình dữ liệu quyết định khuếch đại ghi: cùng một dạng dữ liệu (danh sách) có thể cần lưu ngược nhau tuỳ cách dùng.

Liên quan

• Chọn database theo workload
• Migration không downtime