Introducing Espresso - LinkedIn's hot new distributed document store

LinkedIn · 2015 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• Trước Espresso, LinkedIn dùng Oracle (dữ liệu chính, nhất quán mạnh) và Voldemort (key-value). Phần lớn dữ liệu chính không cần đủ tính năng RDBMS nhưng lại cần đọc-sau-ghi và một change capture stream có thứ tự theo timeline cho xử lý nearline/offline.
• Theo LinkedIn, Oracle gây đau ở: schema evolution bằng ALTER TABLE cần DBA; cấp thêm shard là việc tay; failover giữa data center (master/slave) cần DBA và có downtime; phần cứng và license đắt.
• Năm 2011 team Distributed Data Systems chốt yêu cầu: scale ngang bằng thêm node, đọc-sau-ghi + đọc eventual, secondary index luôn khớp dữ liệu, transaction trong một partition, tự chịu lỗi máy, schema evolution không downtime, change stream, bulk ingest từ Hadoop.
• Năm 2015: khoảng 30 ứng dụng (Member Profile, InMail, một phần homepage và mobile), hơn chục cụm, hàng triệu record/giây lúc đỉnh, hàng trăm TB dữ liệu gốc.

Thay đổi chính

• Mô hình dữ liệu phân cấp: database → table → collection → document. Schema database/table bằng JSON, document bằng Avro. Khoá nhiều phần, phần đầu là partition key (ví dụ MailboxID, rồi MessageID); mọi document cùng partition key là một collection và được transaction khi ghi trong một request.
• Router stateless: băm partition key ra partition, tra bảng routing cache cục bộ (cập nhật qua ZooKeeper), scatter-gather cho multi-get.
• Storage node: storage engine cắm được, production dùng MySQL/InnoDB; binlog MySQL vừa để replicate trong cụm vừa làm nguồn cho Databus. Secondary index cập nhật đồng bộ với dữ liệu gốc.
• Helix quản lý cụm: từ state model (mỗi partition một master, n slave, không hai replica cùng node) tính IdealState rồi phát transition. Node chết thì ephemeral node ZooKeeper mất, slave được nâng lên master; trong khoảng ngắn partition không nhận ghi nhưng router vẫn đọc từ slave.
• SCN 64 bit mỗi partition (32 bit generation tăng mỗi lần đổi master + 32 bit sequence) làm đồng hồ cho replication và Databus.
• Data Replicator (consumer Databus, quản bằng Helix, checkpoint ở ZooKeeper) chuyển commit sang cụm ở data center khác, batch theo partition cho đường WAN.
• Snapshot service khôi phục backup thành file Avro để ETL vào HDFS và bootstrap consumer Databus mới (Databus chỉ giữ buffer cố định); việc này cũng kiểm tra backup ngay khi tạo.

Vì sao

• Một kho duy nhất có change stream gốc giúp search index, cache và data center khác đều đi theo cùng một log thay vì mỗi nơi tự đồng bộ.

Bài học cho SWE

• Chọn đơn vị transaction bằng partition key: nhóm dữ liệu hay sửa cùng nhau (một hộp thư) vào một partition và chấp nhận không có transaction xuyên partition.
• Dựng document store trên MySQL thay vì viết storage engine: phần mới là routing, quản lý cụm và change capture.
• Generation trong số thứ tự giúp phân biệt ghi của master cũ và master mới sau failover.

Liên quan

• LinkedIn 2015 · LinkedIn 2013 (Databus) · LinkedIn 2017 (Helix dùng lại) · LinkedIn 2019 (thay Databus làm CDC cho Espresso) · LinkedIn 2018 (bỏ graph DB sang Espresso)
• Chọn database theo workload · Sharding và tách database · Failover, replica và dự phòng dữ liệu · Độ tin cậy và multi-region