5

Trong CMS, danh sách khách hàng được truy xuất bằng cách sử dụng truy vấn NDB thông thường khi đặt hàng. Để cho phép lọc tên, tên công ty và email, tôi tạo một số (đôi khi nhiều) chỉ mục. Tình hình không lý tưởng, nhưng khả thi.Sử dụng Datastore (NDB), API tìm kiếm hoặc cả hai cho chế độ xem dữ liệu?

Bây giờ, có (thử nghiệm) Search API. Dường như không có liên quan đến kho dữ liệu (hoặc NDB), nhưng dữ liệu của tôi đã có sẵn.

Tôi muốn sử dụng Tìm kiếm văn bản đầy đủ và đặt đồng thời nhiều bộ lọc trên nhiều trường, vì vậy tôi có nên giữ dữ liệu của mình trong Datastore và các phần trùng lặp của dữ liệu trong Tài liệu cho API tìm kiếm không? Hoặc, là search example suggests, bỏ qua toàn bộ kho dữ liệu.

Trả lời

6

Tôi không hoàn toàn chắc chắn phương pháp được đề xuất là gì để triển khai, nhưng API tìm kiếm dường như được sử dụng chủ yếu làm chỉ mục được quản lý bổ sung theo cách thủ công. Nó không lý tưởng trong hầu hết các tình huống để lưu trữ tất cả dữ liệu của bạn trong API tìm kiếm, vì bạn có thể dễ dàng loại bỏ các chỉ mục API tìm kiếm bằng các trường mà bạn không bao giờ cần lọc hoặc tìm kiếm, cũng như được thiết kế tốt để sử dụng tình huống viết thường xuyên là cần thiết.

Đề xuất cá nhân của tôi là để lại tất cả dữ liệu của bạn trong NDB và thiết kế các lớp để tạo tài liệu chứa dữ liệu có thể tìm kiếm có liên quan bằng API tìm kiếm, duy trì tính nhất quán giữa hai phương tiện bằng cách cập nhật phiên bản API tìm kiếm mỗi lần viết được thực hiện cho phiên bản kho dữ liệu (hoặc sử dụng các nhiệm vụ/crons hoặc một hệ thống tương tự nếu bạn đang viết dữ liệu rất nhiều). Bạn nên lưu trữ bất kỳ dữ liệu nào bạn có trong giao diện người dùng khi lọc trong tài liệu API tìm kiếm cho dữ liệu có liên quan đó, bằng cách tham gia kết quả API tìm kiếm theo cách thủ công và dữ liệu kho dữ liệu không cần thiết và sẽ làm chậm toàn bộ quá trình.

+0

Cảm ơn. Đó là một cách tiếp cận rất thiết thực và hữu ích cho vấn đề. – kvdb

Các vấn đề liên quan