Ý chính: Chỉ mục tìm kiếm là bản dữ liệu phục vụ đọc nhanh. Nó phải có thể được dựng lại từ nguồn dữ liệu chuẩn.
Thuật ngữ trong bài: Index: cấu trúc dữ liệu dành cho tìm kiếm; relevance: mức độ phù hợp của kết quả; reindex: tạo lại toàn bộ chỉ mục.
Bài toán thực tế
Cập nhật chỉ mục ngay trong luồng ghi làm người dùng phải chờ và vẫn có thể mất thay đổi khi lỗi. Dùng chung chỉ mục cũng có nguy cơ lộ dữ liệu giữa khách hàng. Khi cấu trúc thay đổi, hệ thống cần tạo chỉ mục mới mà không dừng tìm kiếm.
Điểm dễ bị bỏ qua
Chỉ mục tìm kiếm là một mô hình đọc có thể dựng lại, không phải nguồn dữ liệu chuẩn. Luồng ghi nghiệp vụ không nên phụ thuộc vào việc cập nhật chỉ mục thành công.
Mỗi tài liệu cần mã khách hàng và phiên bản nguồn; khi mapping thay đổi, hệ thống xây chỉ mục mới song song, kiểm tra chất lượng rồi chuyển alias thay vì sửa trực tiếp chỉ mục đang phục vụ.
Luồng xử lý
Thay đổi chuẩn→Outbox hoặc CDC
Indexing sự kiện bền vững→Indexer
Transform có phiên bản→Search chỉ mục
Read model theo khách hàng
Thiết kế và triển khai
Document có phiên bản
Cơ sở dữ liệu sequence hoặc phiên bản đối tượng nghiệp vụ ngăn sự kiện trễ ghi đè trạng thái mới.
Tách lược đồ khỏi alias
Tạo không thể thay đổi chỉ mục phiên bản và để stable read alias trỏ vào phiên bản active.
Đo relevance offline và online
Dùng labelled truy vấn cho precision/recall rồi xác nhận click hoặc kết quả thành công, không tối ưu engagement mù quáng.
Đi sâu vào thiết kế
Deletion là luồng hạng nhất
Privacy deletion phải xóa primary data, chỉ mục, cache và bản sao lưu theo chính sách kèm evidence bền vững.
Dựng lại năng lực xử lý là resilience
Nếu không thể dựng lại toàn chỉ mục trong phục hồi objective, hệ derived đang phụ thuộc chưa kiểm thử vào trạng thái hiện tại.
Cách triển khai
- Ghi nhận thay đổi đã commit bằng Outbox hoặc CDC thay vì cập nhật chỉ mục ngay trong giao dịch người dùng.
- Mỗi tài liệu trong chỉ mục phải có mã khách hàng và phiên bản nguồn do máy chủ quản lý.
- Xây chỉ mục mới song song, kiểm chứng chất lượng rồi chuyển alias trong một thao tác nguyên tử.
Mã minh họa: Dựng chỉ mục mới và chuyển alias
create index products_v3(mapping_v3)
bulk index snapshot with sourceVersion
consume changes after snapshot watermark
compare counts, samples and query set
atomic alias products_read: v2 -> v3Giữ chỉ mục cũ trong một khoảng quay lui hữu hạn và tiếp tục cập nhật cả hai cho tới khi việc chuyển đổi đã được kiểm chứng.
Rủi ro cần tính trước
- Cập nhật đến muộn làm một tài liệu đã xóa xuất hiện trở lại.
- Thiếu bộ lọc khách hàng khiến kết quả chứa tài liệu của khách hàng khác.
- Dựng lại chỉ mục đọc quá nhanh và làm quá tải cơ sở dữ liệu nguồn.
Nên theo dõi gì?
| Tín hiệu | Điều tín hiệu cho biết |
|---|---|
| Độ trễ lập chỉ mục theo loại sự kiện | Đo độ mới của kết quả và rủi ro xóa chậm. |
| Số phiên bản cũ bị từ chối | Cho biết sự kiện sai thứ tự đã được phát hiện và chặn. |
| Tỷ lệ không có kết quả và tỷ lệ tìm kiếm thành công | Theo dõi chất lượng kết quả từ hành vi thực tế của người dùng. |
Cách kiểm chứng
- Độ trễ và reorder chỉ mục sự kiện quanh cập nhật và delete.
- Chạy negative truy vấn chéo khách hàng ở search client layer thấp nhất.
- Dựng lại chỉ mục volume gần production trong khi write tiếp tục.
Đưa vào production từng bước
Bổ sung sự kiện bền vững và phiên bản tài liệu vào chỉ mục hiện tại trước. Xây mapping mới song song, so sánh trên một tập truy vấn đại diện và chuyển một nhóm khách hàng nhỏ qua alias trước khi chuyển toàn bộ.
Checklist trước khi vận hành
- Search không trở thành nguồn dữ liệu chuẩn cho transaction.
- Delete và privacy sự kiện có propagation objective được đo.
- Relevance thay đổi được đánh giá bằng truy vấn set cố định và nghiệp vụ chỉ số.
Điều cần nhớ
Nền tảng tìm kiếm đáng tin khi dữ liệu có thể dựng lại, độ mới được công bố rõ và chất lượng kết quả được đo bằng truy vấn thực tế.