Avoid pitfalls in scaling your Cassandra cluster: lessons and remedies

Walmart · 2017 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Bối cảnh

Nhiều team ở Walmart dùng Cassandra làm nguồn dữ liệu chính, đọc ghi hàng chục tới hàng trăm nghìn ops/giây. Theo bài, để tới được đó họ phải "quên" nhiều mẹo của thế giới RDBMS và chấp nhận schema trông "lạ" nhưng nhanh hơn.

Năm cái bẫy và cách xử lý

1. Partition không đều: quan hệ cha-con với cha làm partition key, con làm clustering key; có cha một con, có cha một triệu con, gây hot spot, mutation bị bỏ, áp lực compaction. Sửa: thêm shard key vào partition key (mỗi shard tối đa 1.000 con, giữ partition dưới khoảng 10 MB với hàng khoảng 10 KB). Phân trang có sẵn: mỗi shard là một trang. Theo Walmart, thiết kế schema có tác động lớn nhất trong mọi tối ưu.
2. Tách mối quan tâm: dùng Solr chung với Cassandra cho secondary index; mỗi mutation làm Solr đọc cả partition (vài MB) vào RAM, gây timeout. Tách cụm và ghi vào Solr qua Kafka thì Cassandra thuần hết timeout; phần Cassandra + Solr vẫn tệ nên cuối cùng thay bằng SolrCloud.
3. Đọc/ghi cả hàng: Cassandra coi ghi lại cùng giá trị là một mutation (last write wins), làm đọc phải xem nhiều SSTable và tăng compaction. Dùng proxy theo dõi trường thay đổi khi ghi; đọc chọn cột thay vì cả hàng.
4. Collection: đọc-sửa-ghi lại cả list sinh nhiều tombstone; ưu tiên Set/Map (tránh read-before-write); collection luôn đọc nguyên khối.
5. Tinh chỉnh driver: chỉ dùng DC cục bộ thì đặt kết nối tới host remote bằng 0; shuffleAmongReplica chia tải đều hơn (đổi lại nhiều read-repair hơn).

Bài học cho SWE

• Với Cassandra, mô hình dữ liệu theo câu truy vấn quan trọng hơn mọi tinh chỉnh; mang thói quen RDBMS sang sẽ trả giá (Chọn database theo workload).
• Giới hạn kích thước partition bằng shard key nhân tạo là cách chuẩn chống hot partition (Hot partition và thundering herd).
• Đừng bắt một cụm gánh hai workload khác bản chất (lưu trữ và index full-text).

Liên quan

• Chọn database theo workload
• Hot partition và thundering herd