Building the Activity Graph, Part 2

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

Bối cảnh

FollowFeed index mọi Activity thành danh sách theo thời gian của từng actor, key là URN của actor. Bản ghi TimelineRecord phải nhỏ để index vừa RAM.
Feature của nội dung (nhãn chất lượng/spam, ngôn ngữ...) cần cho lọc và ranking. Nhét feature vào mỗi TimelineRecord thì tốn 8 byte con trỏ ngay cả khi trống, và một bài phổ biến được like/share nhiều lần sẽ có feature lặp lại ở nhiều bản ghi, sửa một nhãn phải sửa nhiều chỗ.

Lưu feature dạng chuẩn hoá trong các store riêng trên mỗi searcher node: EntityFeatureStore (EFS) = Bloom filter + cache Caffeine + RocksDB. Mỗi request cần hàng trăm nghìn lookup, nên lookup phải tính bằng nano giây.
Không bao giờ khởi động lạnh: một RocksDB riêng ("CachedKeysStore") ghi danh sách key đang nằm trong cache; khởi động lại thì nạp lại đúng các key đó trước khi nhận traffic.
Lookup âm: với nhãn chất lượng, hơn 99,99999% lookup không có giá trị. Caffeine không cache kết quả rỗng nên dùng giá trị sentinel, nhưng tốn RAM; thay bằng Bloom filter đứng trước (false positive 1%).
Bloom filter của Guava không thread-safe; khoá đọc-ghi thành nút cổ chai nên LinkedIn viết bản lock-free và được merge vào Guava.
Decoration nhanh hơn: dữ liệu ở LinkedIn được chuẩn hoá, bản ghi tham chiếu nhau bằng URN (urn:li:member:123), thư viện "deco" của frontend phải giải URN đệ quy qua nhiều vòng gọi mạng tuần tự. PathsToRoots của Activity Graph chính là đường deco sẽ đi, nên lấy trước toàn bộ URN tổ tiên rồi giải song song.

Dữ liệu thưa: Bloom filter trước cache rẻ hơn nhiều so với cache cả kết quả rỗng.
Lưu danh sách key nóng để khởi động lại không phải trả giá cache lạnh.
Dữ liệu chuẩn hoá bằng tham chiếu thì phải tính chi phí "decorate" lúc đọc; biết trước đường tham chiếu là gom được round-trip.