How Upstash Redis Search Works?

Upstash · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bài của nhà cung cấp mô tả nội bộ một tính năng; nhận định là theo Upstash, không có số liệu hiệu năng.

Bối cảnh

• Redis lưu và trả dữ liệu nhanh nhưng truy vấn thì khó: sorted set giả lập vài mẫu truy cập, còn lại phải scan. Với Upstash Redis (bền mặc định, hay được dùng làm DB chính), đây là giới hạn lớn. Upstash Redis Search thêm full-text, toán tử truy vấn và aggregation trên dữ liệu Redis.

Thay đổi chính

• Index theo key prefix: mỗi index theo dõi một hay nhiều prefix, có schema cố định sau khi tạo. Lệnh Redis chạy trước; chỉ khi lệnh thành công và đổi trường thuộc schema mới sinh tài liệu cho index (trường thừa bỏ qua, trường thiếu không điền mặc định). Một lệnh có thể sinh cập nhật cho nhiều index. Không có bước "gửi sang search" riêng.
• Bền trước khi trả lời: tài liệu được ghi vào queue trên đĩa trước, rồi mới thử đưa vào một Go channel nhỏ làm đầu queue trong bộ nhớ. Channel đầy thì không chờ: một goroutine nền đọc tiếp từ đĩa đẩy vào channel tới khi đuổi kịp. Sau khi tài liệu đã bền trên đĩa thì trả kết quả lệnh Redis; việc index chạy bất đồng bộ.
• Tantivy trên kho KV được nhân bản: lõi là Tantivy (thư viện search Rust). Tantivy chỉ cần một Directory ghi file một lần và đọc theo khoảng, nên Upstash viết Directory trên chính kho key-value được nhân bản toàn cầu của họ: chia file thành trang 8 KB, mỗi trang một key. Segment bất biến được nhân bản như dữ liệu thường, nên index ở us-east-1 query được từ region khác.
• Ranh giới Go ↔ Rust: DB viết bằng Go gọi Tantivy qua cgo, và Tantivy lại gọi ngược về Go để đọc/ghi trang. Không giữ con trỏ Go trong Rust được (chỉ được ghim trong thời gian một lời gọi; map, channel, interface không ghim được), nên dùng cgo.Handle (một số nguyên Go tự ánh xạ về giá trị).
• Fork Tantivy cho multi-tenant: mặc định Tantivy chạy nhiều thread index và thread merge cho mỗi index; một tiến trình Upstash chứa hàng nghìn DB, mỗi DB nhiều index, nên không scale. Họ fork, mở vài struct nội bộ để viết writer chạy hoàn toàn foreground: một segment mở, append tới khi đạt kích thước, chạy trên thread của goroutine bảo trì của index đó; giữ phần fork nhỏ để dễ bảo trì.
• Commit: segment đang chờ được commit theo thời gian hoặc khi người dùng yêu cầu; commit xong thì file bất biến, cắt queue trên đĩa tới sequence đã commit, reload searcher. Crash giữa lúc ghi segment thì không phân tích từng trường hợp ghi dở: tạo segment mới và phát lại queue từ lần commit cuối.

Vì sao

• Theo Upstash, search nằm trong DB và dùng chung storage nhân bản thì không cần hệ search riêng, không cần đồng bộ hai nơi; index là dữ liệu dẫn xuất có thể dựng lại từ queue (Hạ tầng tìm kiếm, Tách compute khỏi storage).
• Gom tài liệu vào một segment mở rồi commit theo lô, thay vì mỗi tài liệu một segment (Batching và khấu hao round-trip).

Bài học cho SWE

• Ghi việc dẫn xuất vào log bền trước khi trả lời, xử lý bất đồng bộ sau, và giữ log tới khi kết quả đã commit; phục hồi = phát lại.
• Một thư viện có lớp trừu tượng storage tốt (Directory) cho phép đặt nó lên hạ tầng bền sẵn có.
• Mô hình thread mặc định của thư viện có thể không hợp với multi-tenant; fork tối thiểu thay vì viết lại.

Liên quan

• Multi-tenancy và cô lập tenant
• PlanetScale 2026 · Upstash 2026 · Upstash 2026 · ScyllaDB 2026 (FFI Rust)
• Hạ tầng tìm kiếm · Tách compute khỏi storage · Batching và khấu hao round-trip