How We Improved Our Performance Using ElasticSearch Plugins: Part 2

Tinder · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 2 trong hai bài; phần 1: Tinder 2019.

Bối cảnh

Mỗi query gợi ý phải gửi kèm danh sách bỏ qua (người đã xem gần đây, đã match), dùng terms query. Với người dùng rất tích cực, danh sách này dài.
Test hiệu năng: latency tăng rõ theo kích thước danh sách; trong mọi thành phần của query, đây là nút cổ chai lớn nhất. Cắt ngắn danh sách thì user thấy lại gợi ý cũ, nên bị loại.

Gửi danh sách đã nén (serialize) thay cho terms, giải nén trong ES.
So hai cách cắm vào ES:
- ActionPlugin (API _newsearch): node query xin thêm document từ data node rồi lọc sau khi xếp hạng. Dễ làm, nhưng chấm điểm thừa cho document sẽ bị bỏ, tăng tải node query và traffic nội bộ, cập nhật phải restart cụm.
- Script qua LoaderPlugin của phần 1: script giải nén danh sách ngay trên data node, trả điểm dưới min_score cho document cần bỏ. Không chấm thừa, không restart. Ở 125 QPS với danh sách 50k, cách này tốt hơn hẳn.
Chọn cấu trúc dữ liệu bằng đo: terms (gốc), hash set (to hơn cả giá trị thô), Bloom filter và RoaringBitmap (cả hai nhỏ hơn nhiều). Bloom nhanh hơn chút nhưng có dương tính giả, tức bỏ nhầm người; chọn RoaringBitmap vì chênh lệch nhỏ và không đổi logic nghiệp vụ.
Kết quả production (theo Tinder): latency giảm khoảng 80% ở mọi percentile; CPU node query và data node giảm khoảng 35% và 50%; network IO giảm khoảng 50%. Cụm có thêm nhiều headroom.

Lucene/ES không được thiết kế cho terms filter rất lớn; đẩy logic lọc vào hàm chấm điểm trên data node vừa bỏ được filter đắt vừa giữ đúng nghiệp vụ.

Tìm nút cổ chai bằng cách bỏ từng thành phần của query rồi đo, trước khi tối ưu (Hạ tầng tìm kiếm).
Cấu trúc xác suất (Bloom) chỉ dùng khi sai số chấp nhận được về nghiệp vụ; ở đây bỏ nhầm người là lỗi sản phẩm.
Tối ưu một query nóng trả về headroom cho cả cụm, tức hoãn được việc mua thêm máy (Chi phí hạ tầng và build vs buy).
Nền tảng nạp code nóng ở phần 1 là thứ làm vòng thử nhanh này khả thi.