Scaling Time Series Data Storage — Part II

Phần 2/2. Phần 1: Netflix 2018.

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

Bối cảnh

• 1/2016 Netflix mở ra 130 nước, 20 ngôn ngữ; cuối 2016 thêm video preview khi duyệt trên TV. Kiến trúc phần 1 coi mọi dữ liệu xem như nhau.
• Cuối 2016 kho dữ liệu này tăng 30% trong một quý; rollout preview bị hoãn vì ảnh hưởng tới nó. Cụm Cassandra đã lớn nhất và gần giới hạn kích thước mà ít ai vượt qua được.
• Client library lấy toàn bộ dữ liệu rồi mới lọc theo loại/thời gian/mức chi tiết ở phía client: thừa dữ liệu truyền và p99 dao động mạnh.

Thay đổi chính

• Phân tích truy cập: ba loại dữ liệu (xem đầy đủ, xem preview, ngôn ngữ phụ đề/lồng tiếng); mọi loại đều chủ yếu đọc dữ liệu gần đây, càng cũ càng cần ít chi tiết. Thương lượng với bên dùng dữ liệu nào cần ở mức chi tiết nào trong bao lâu.
• Shard cụm theo loại dữ liệu, rồi với dữ liệu xem đầy đủ shard theo tuổi: Recent (vài ngày), Past (vài ngày đến vài năm), Historical (chỉ bản tóm tắt). Mỗi loại tăng trưởng độc lập, client đơn giản đi.
• Giảm dữ liệu: không lưu preview quá ngắn (không phải tín hiệu); ngôn ngữ chỉ lưu lựa chọn đầu và các thay đổi (đa số người dùng chỉ một bản ghi); TTL ngắn hơn cho preview và ngôn ngữ.
• Dùng lại Live + Compressed ở phần 1; cụm dữ liệu cũ lưu nén hoàn toàn (đổi CPU lúc đọc lấy chi phí lưu trữ).
• Xoay dữ liệu giữa cụm bất đồng bộ: đọc Recent thấy bản ghi quá hạn thì xếp task chuyển sang Past (gộp, nén, ghi phiên bản mới, xoá bản cũ, chunk nếu lớn), có gom lô để không chạy mỗi lần đọc; tương tự Past → Historical (tóm tắt lại).
• Đọc song song các cụm và ghép lại; bản tóm tắt ở Historical không chứa vài năm gần đây nên phải bổ sung từ Recent/Past.
• Cache EVCache dựng giống kiến trúc lưu trữ, hit rate gần 99%; cache "Summary" giữ tóm tắt nén của toàn bộ lịch sử.
• Kết quả sơ bộ (hơn nửa chặng migrate): chỉ riêng shard theo loại đã cải thiện compaction, GC, latency; dư địa cho ít nhất 5 lần tăng trưởng; tiết kiệm nhờ nén và TTL. API cũ vẫn chạy (tương thích ngược), API mới cho tập con cần client đổi, nên server và từng client migrate độc lập.

Vì sao

• Mục tiêu chịu 5 lần tăng trưởng với chi phí hợp lý và latency dễ đoán; một cụm chung cho mọi loại dữ liệu trộn lẫn tốc độ tăng khác nhau.

Bài học cho SWE

• Phân loại dữ liệu theo cách dùng (loại, tuổi, mức chi tiết) trước khi scale phần cứng; một phần lớn dữ liệu có thể không cần giữ.
• Đẩy bộ lọc từ client vào thiết kế lưu trữ.
• Giữ API cũ tương thích để tách tiến độ server khỏi tiến độ client.

Liên quan

• Chọn database theo workload · Sharding và tách database · Cache và invalidation