Lessons from our journey to enable global code search with Elasticsearch on GitLab.com

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

Phần 1 trong hai bài; phần 2 (7/2019): GitLab 2019.

Bối cảnh

• Bản tự host của GitLab đã có tích hợp Elasticsearch (global search, code search) vài năm, nhưng GitLab.com, instance lớn nhất, vẫn chưa bật được.
• Hai việc phải làm: giảm kích thước index và làm cho quản trị dễ hơn. Index lúc đó tốn khoảng 66% dung lượng của chính các repo, chưa tính replica: rào cản lớn nhất.

Thay đổi chính (các ngõ cụt và hướng đi)

• Forcemerge để lấy lại chỗ của soft delete: xoá document trong Elasticsearch chỉ đánh dấu, chỗ được lấy lại khi merge; index có thể phình thêm tới 50% vì vậy. Nhưng forcemerge là lệnh chặn, làm hiệu năng sụt nặng khi chạy: bỏ, chỉ tinh chỉnh merge.
• Edge NGram: để tìm theo tiền tố (từ, SHA commit) dùng NGram dài tối đa 40. Không giảm được cho SHA; thử giảm cho code tiết kiệm 7–15% với kết quả mâu thuẫn, chưa đổi vì chưa chắc chất lượng tìm kiếm không giảm.
• Tách index theo loại document: mọi loại đang chung một index vì lọc quyền theo project sau khi Elasticsearch trả kết quả từng dòng thì quá đắt. Tách index không tiết kiệm chỗ (Elasticsearch 6 đã xử lý tốt sparse field) nhưng index nhanh hơn rõ và re-index từng model dễ hơn.
• Quản trị: mọi thao tác phải làm trực tiếp trên cụm; tích hợp là tất cả hoặc không (bật cho mọi project hoặc không project nào); đổi schema đòi re-index toàn bộ ngay; dữ liệu index hỏng (ví dụ Sidekiq sập) chỉ sửa được bằng re-index cả cụm.
• Hướng tiếp: giao diện quản trị trong GitLab, bật theo từng project, cho phép tắt code indexing (giữ tìm issue/MR), cân nhắc cụm Elasticsearch riêng theo group (như Gitaly theo project) để cụm không quá lớn và một cụm hỏng chỉ ảnh hưởng một group.
• Quyết định: chuyển toàn bộ thời gian engineer từ giảm index sang cải thiện quản trị, để bật index chọn lọc và tự dùng trên production (dogfooding).

Bài học cho SWE

• Chi phí lưu trữ của index tìm kiếm có thể ngang cỡ dữ liệu gốc; NGram và soft delete là hai nguồn phình chính (Hạ tầng tìm kiếm, Chi phí hạ tầng và build vs buy).
• Lọc quyền sau khi tìm (post-filter) đắt ở quy mô lớn, nên ràng buộc cách tổ chức index.
• Tính năng "tất cả hoặc không" không bật được trên instance lớn nhất; cần đường bật dần để thu dữ liệu thật.

Liên quan

• Cùng công ty: GitLab 2019 · GitLab 2019 · GitLab 2019
• Hạ tầng tìm kiếm · Chi phí hạ tầng và build vs buy