2015-01-15 20 views
5

Cụ thể, tôi đang sử dụng Elasticsearch để phân trang, nhưng câu hỏi này có thể áp dụng cho bất kỳ cơ sở dữ liệu nào.Cách xử lý phân trang khi dữ liệu nguồn thay đổi thường xuyên

Elasticsearch cung cấp các phương pháp cho paginate search results với các tham số tiện dụng fromto.

Vì vậy, tôi chạy truy vấn get me the most recent data from result 1 to 10

Điều này rất hữu ích.

Người dùng nhấp chuột "trang kế tiếp" và truy vấn là: get me the most recent data from result 11 to 20

Vấn đề là trong thời gian giữa hai truy vấn, 2 kỷ lục mới đã được thêm vào cơ sở dữ liệu ủng hộ, có nghĩa là các kết quả phân trang sẽ trùng lặp (2 cuối cùng từ trang đầu tiên hiển thị dưới dạng hai trang đầu tiên trên trang thứ hai).

Giải pháp tốt nhất để tránh điều này là gì? Ngay bây giờ, tôi đang thêm bộ lọc vào truy vấn cho biết nó chỉ bao gồm kết quả sau kết quả cuối cùng của truy vấn trước đó. Nhưng nó chỉ có vẻ hackish.

Trả lời

5

Bộ lọc không phải là tùy chọn không đúng, nếu bạn đã lập chỉ mục một dấu thời gian có liên quan. Bạn phải theo dõi dấu thời gian đó ở phía máy khách để chuẩn bị các truy vấn của bạn một cách chính xác. Bạn cũng phải biết khi nào để thoát khỏi nó. Nhưng đó không phải là vấn đề không thể vượt qua.

API cuộn là tùy chọn vững chắc cho điều này, vì nó có hiệu quả chụp nhanh kịp thời ở bên Elasticsearch. Mục đích của API cuộn là cung cấp truy vấn tìm kiếm ổn định cho phân trang sâu, điều này phải giải quyết vấn đề chính xác về thay đổi mà bạn đang gặp phải.

Bạn bắt đầu một Scrolling Search bằng cách cung cấp truy vấn của mình và tham số scroll, mà Elasticsearch trả về scroll_id. Sau đó, bạn yêu cầu /_search/scroll cung cấp ID đó, mỗi ID sẽ trả về một trang kết quả và một số scroll_id mới cho yêu cầu tiếp theo.

(Lưu ý rằng bạn không muốn tìm kiếm scan gõ vào đây. Đó là sử dụng để trích xuất văn bản en masse, và không áp dụng bất kỳ phân loại.)

So với lọc, bạn làm vẫn có để theo dõi một giá trị: scroll_id cho trang kết quả tiếp theo của bạn. Việc dễ dàng hơn việc theo dõi dấu thời gian có phụ thuộc vào ứng dụng của bạn hay không.

Có những nhược điểm tiềm năng khác cần xem xét. Elasticsearch vẫn tồn tại ngữ cảnh cho tìm kiếm của bạn trên một nút duy nhất trong cụm. Conceivably này có thể tích lũy trong cụm của bạn, tùy thuộc vào mức độ bạn dựa vào tìm kiếm cuộn. Bạn sẽ muốn kiểm tra các tác động hiệu suất ở đó. Và nếu tôi nhớ chính xác, các tìm kiếm cuộn cũng không tồn tại thông qua lỗi nút hoặc khởi động lại.

Tài liệu ES cho số Scroll API cung cấp chi tiết tốt về tất cả các điều trên.

Tóm lại: lọc theo dấu thời gian thực sự không phải là lựa chọn không hợp lệ. API cuộn là một tùy chọn hợp lệ khác, được thiết kế cho một trường hợp sử dụng tương tự, nhưng không phải không có các hạn chế của nó.

+0

Cảm ơn bạn đã giải thích chi tiết. Vì lý do nào đó, tôi đã nghĩ rằng quét/di chuyển là điều tương tự, nhưng điều đó rõ ràng là không đúng! Di chuyển có vẻ như là một lựa chọn tốt khi bạn không có thứ gì đó giống như dấu thời gian mới nhất để lọc. – bradvido

+0

Hạn chế cho việc lọc dấu thời gian là nếu ai đó xóa tài liệu, bạn có thể bỏ qua tài liệu từ trang kết quả tiếp theo? – writofmandamus

+0

Lưu ý từ tài liệu API cuộn 'Cuộn không dành cho các yêu cầu người dùng thời gian thực,' – Ben

-1

Bạn cần sử dụng API quét cho việc này. Quét và cuộn API cho phép bạn thực hiện tìm kiếm và phân trang theo thời gian. Quét API -

+1

Sử dụng API quét có thể không phải là điều chính xác để thực hiện tại đây. Nó không áp dụng phân loại trên kết quả. – bittusarkar

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