Project Voldemort: Scaling Simple Storage at LinkedIn

LinkedIn · 2009 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Bối cảnh

• LinkedIn bắt đầu bằng một DB lớn và cụm front-end (cộng một đồ thị xã hội trong RAM trên máy riêng). DB được tách thành các service riêng cho profile, search, nhóm, network update, công ty; có read replica nhưng chưa có cách scale ghi.
• Tính năng nhiều ghi như Who's Viewed My Profile (ghi nhiều ngang đọc) và dữ liệu tính offline (profile tương tự, tập cặp rất lớn) không vừa mô hình đó.

Thay đổi chính

• Xem xét Bigtable nhưng không có GFS độ trễ thấp; chọn hướng Dynamo của Amazon: KV phân tán, độ trễ thấp, sẵn sàng cao. Không cố thay Hadoop (phân tích), DB (query phức tạp) hay search.
• Open source khoảng 2/2009, gần 50 đóng góp từ bên ngoài.
• Hướng tiếp: thêm node dần, hỗ trợ dữ liệu batch tính từ Hadoop, client ngôn ngữ khác.

Kết quả (2009)

• Các ứng dụng hàng trăm triệu đọc/ghi mỗi ngày giảm độ trễ từ hơn 400 ms xuống dưới 10 ms, trong khi lưu nhiều dữ liệu hơn.

Bài học cho SWE

• Tách DB theo tính năng giải được đọc (replica) nhưng không giải được ghi; KV kiểu Dynamo cho dữ liệu truy cập theo key là bước tiếp theo phổ biến.

Liên quan

• LinkedIn 2015 · LinkedIn 2015 (thay Voldemort cho dữ liệu chính) · LinkedIn 2017 (thay Voldemort Read-Only) · LinkedIn 2014
• Chọn database theo workload · Sharding và tách database