Update: Elasticsearch lessons learnt for Advanced Global Search

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

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

Bối cảnh

Bế tắc "con gà quả trứng": muốn giảm kích thước index thì cần dữ liệu từ một deployment thật, mà chưa có deployment thật vì index quá lớn. Phản hồi khách và test nhỏ không đủ; dogfooding là cách tốt nhất.

Index chọn lọc theo project và group (từ bản 12.0), để bật trên GitLab.com mà không phải index tất cả.
Ngày 24/6/2019 bật cho group gitlab-org: khoảng 500 project, 2,2 triệu document, 15 GB, dễ quản trị. Việc index lần đầu không suôn sẻ như mong đợi.
Trước khi bật chạy Production Readiness Review: lộ ra nhiều bug cũ và regression mới, sửa trong 12.0.
Staging lệch xa production: staging làm mới lần cuối hơn một năm trước, chỉ khoảng 150 project, nên một số bug và vấn đề scale chỉ lộ trên production; sửa ưu tiên ở 12.1, 12.2.
Tự động hoá quản trị: khi thêm group/project vào danh sách index, GitLab tự xếp hàng tác vụ backfill, và tự gỡ record khi bị bỏ khỏi danh sách (trước đó phải chạy tay chuỗi rake task chậm, sai bước là kết quả thiếu); cấu hình số shard và replica ngay trong admin; thêm nút "Start indexing".
Còn lại: khó xem trạng thái index của một project (support cần để trả lời "sao không tìm thấy"); đổi schema vẫn re-index tất cả, không scale khi index lớn; mục tiêu là quản lý thay đổi index như migration database. Trách nhiệm tích hợp chuyển sang một nhóm khác (Editor, Create stage).

Bật tính năng nặng trên production bằng phạm vi nhỏ có chọn lọc (một group nội bộ) để có dữ liệu thật và dogfood (Deploy và release an toàn).
Staging nhỏ và cũ không lộ vấn đề scale; biết rõ staging lệch production bao xa.
Đổi schema index bằng re-index toàn bộ là cách đơn giản nhất nhưng không scale; cần migration index online, như Atlassian 2026 làm sau này (Hạ tầng tìm kiếm, Atlassian 2026).
Backfill và dọn dẹp index phải tự động theo vòng đời của dữ liệu nguồn.