Optimizing Elasticsearch for Low Latency, Real-Time Recommendations

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

Bối cảnh

Gợi ý xuất hiện trong kết quả tìm kiếm, module gợi ý ở trang chi tiết nhà, các collection cá nhân hoá. Trước đây phần lớn (ngoài kết quả tìm kiếm) tính batch; năm 2022 chuyển phần lớn sang realtime để bắt kịp listing mới và sở thích mới nhất.

Service rt-recs (Java + Python): kiểm cache Redis → lấy hồ sơ người dùng (cập nhật gần realtime) → Elasticsearch sinh tối đa 100 ứng viên từ khoảng 1,3 triệu listing với điểm liên quan từ một mô hình tuyến tính theo hồ sơ → service Python chấm điểm, thường trả dưới 10 kết quả → ghi cache. Mỗi bước có timeout Hystrix. Sinh ứng viên là phần tốn thời gian nhất và hay timeout.
Đo bằng _stats/search: thời gian chia 40/60 giữa phase query và fetch, nghĩa là fetch đáng tối ưu.
Đổi cách lấy trường từ _source (đọc cả JSON gốc rồi lọc) sang doc values (lưu theo cột, lấy đúng trường cần). A/B 50% rồi rollout: CPU rt-recs −38,7%, dropout Elasticsearch −54,7%, latency −11,5% p50, −22,2% p95, −25,6% p99, giảm phí truyền dữ liệu AWS.
Cache: không dùng request cache của ES (đã có Redis cho cả response); query cache đạt 63% hit nhờ UI có các khoảng giá/diện tích gợi ý sẵn.
Ưu tiên latency đọc hơn độ tươi: cập nhật từ streaming được rate limit và gom bulk (kích thước bulk tìm bằng load test); tăng refresh interval (mặc định 1 s) để query cache sống lâu hơn, chấp nhận dữ liệu cũ một chút.

Elasticsearch được chọn vì cần sắp xếp theo điểm liên quan tuỳ biến cho từng request (Hạ tầng tìm kiếm).
Mỗi lần refresh làm mất query cache, nên đổi độ tươi lấy tỉ lệ hit (Cache và invalidation); gom ghi thành bulk để bớt áp lực lên cụm phục vụ đọc (Batching và khấu hao round-trip).

Đo thời gian theo từng phase trước khi tối ưu; ở đây phase fetch, không phải query, là chỗ đáng sửa.
Chỉ lấy đúng trường cần từ store dạng cột thay vì lấy cả document.
Ghi rõ đánh đổi độ tươi/latency và tinh chỉnh bằng load test.