Xử lý số lượng lớn các id trong Solr

Question

Tôi cần thực hiện tìm kiếm trực tuyến trong Solr tức là người dùng cần phải tìm danh sách người dùng đang trực tuyến với các tiêu chí cụ thể.

Làm thế nào tôi đang xử lý này: chúng tôi lưu trữ các id của người dùng trong một bảng và tôi gửi tất cả các id người đang truy cập trong yêu cầu Solr như

&fq=-id:(id1 id2 id3 ............id5000) 

Vấn đề với phương pháp này là khi id trở thành lớn, Solr đang mất quá nhiều thời gian để giải quyết và chúng tôi cần chuyển yêu cầu lớn qua mạng.

Một giải pháp có thể được sử dụng để tham gia vào Solr nhưng thay đổi dữ liệu trực tuyến thường xuyên và tôi không thể lập chỉ mục dữ liệu mỗi lần (nói 5-10 phút, ít nhất là một giờ).

Giải pháp khác Tôi nghĩ rằng việc kích hoạt truy vấn này nội bộ từ Solr dựa trên tham số nhất định trong URL. Tôi không có nhiều ý tưởng về Solr internals vì vậy không biết làm thế nào để tiến hành.

Answer 1

Với cam kết mềm của Solr4, cam kết đã trở nên đủ rẻ để có thể lưu trữ trực tiếp cờ "trực tuyến" trong hồ sơ người dùng và chỉ có & fq = online: true trên truy vấn của bạn. Điều đó làm giảm chi phí liên quan đến việc gửi 5000 id qua dây và phân tích chúng, và cho phép Solr tối ưu hóa truy vấn một chút. Bất cứ khi nào ai đó đăng nhập hoặc đăng xuất, hãy đặt trạng thái của họ và đặt commitWithin trên bản cập nhật. Đó là giá trị một shot, anyway.

Answer 2

Bất kỳ giải pháp mạnh mẽ nào sẽ bao gồm việc đưa dữ liệu của bạn đến gần SOLR (hàng loạt) và sử dụng nó trong nội bộ. KHÔNG chạy một yêu cầu rất lớn trong khi tìm kiếm, đó là độ trễ thấp. Bạn nên phát triển bộ lọc của riêng mình; Bộ lọc sẽ lưu trữ dữ liệu người dùng trực tuyến một lần trong một thời gian (mỗi phút). Nếu dữ liệu thay đổi RẤT thường xuyên, hãy xem xét việc triển khai PostFilter.

Bạn có thể tìm thấy một ví dụ tốt về thực hiện lọc tại đây: http://searchhub.org/2012/02/22/custom-security-filtering-in-solr/

Answer 3

Chúng tôi làm việc xung quanh vấn đề này bằng cách thực hiện sharding của dữ liệu.

Về cơ bản, mà không đi nặng nề vào mã chi tiết:

• Viết mã lập chỉ mục của riêng bạn
  • sử dụng consistent hashing để quyết định ID đi mà Solr máy chủ
  • index mỗi dữ liệu người dùng với phân đoạn có liên quan (nó có thể là một vài máy)
  • đảm bảo bạn có dự phòng
• Query Solr mảnh
  • Do truy vấn sharded trong Solr sử dụng shards tham số
  • Bắt đầu một EmbeddedSolr và sử dụng nó để làm một truy vấn sharded
  • Solr sẽ truy vấn tất cả các mảnh và hợp nhất các kết quả, nó cũng cung cấp timeout nếu bạn cần phải hạn chế thời gian truy vấn cho mỗi phân đoạn

Ngay cả với tất cả những gì tôi đã nói ở trên, tôi không tin Solr là một sự phù hợp tốt cho việc này .Solr không thực sự phù hợp cho các tìm kiếm trên các chỉ mục liên tục thay đổi và nếu bạn chủ yếu tìm kiếm theo ID hơn là công cụ tìm kiếm thì không cần thiết.

Đối với dự án của chúng tôi, chúng tôi về cơ bản thực hiện tất cả các chỉ mục xây dựng, cân bằng tải và công cụ truy vấn và sử dụng Solr chủ yếu là lưu trữ. Nhưng chúng tôi đã bắt đầu sử dụng Solr khi sharding là flaky và không thực hiện, tôi không chắc chắn trạng thái của nó là ngày hôm nay.

Lưu ý cuối cùng, nếu tôi đang xây dựng hệ thống này ngay từ đầu mà không có tất cả công việc chúng tôi đã thực hiện trong 4 năm qua, tôi khuyên bạn nên sử dụng bộ nhớ cache để lưu trữ tất cả người dùng hiện đang trực tuyến (nói memcached hoặc redis) thời gian yêu cầu Tôi chỉ đơn giản là lặp qua tất cả chúng và lọc ra theo các tiêu chí. Việc lọc theo tiêu chí có thể được lưu trữ một cách độc lập và cập nhật dần dần, cũng lặp lại trên 5000 bản ghi không nhất thiết phải tốn nhiều thời gian nếu logic phù hợp rất đơn giản.

Answer 4

một giải pháp có thể sử dụng tham gia trong Solr nhưng dữ liệu trực tuyến thay đổi thường xuyên và tôi không thể index dữ liệu mỗi lần (nói 5-10 phút, nó phải là tại-ít nhất một giờ)

Tôi nghĩ rằng bạn có thể sử dụng rất tốt Solr tham gia, nhưng sau một chút ngẫu hứng.

Giải pháp, tôi đề xuất như sau:

You can have 2 Indexes (Solr Cores) 

1. Primary Index (The one you have now) 
2. Secondary Index with only two fields , "ID" and "IS_ONLINE" 

Bây giờ bạn có thể cập nhật chỉ số Secondary thường xuyên (theo thứ tự của giây) và giữ nó trong đồng bộ với bảng mà bạn có, để lưu trữ người dùng trực tuyến .

LƯU Ý: Chỉ số này thứ ngay cả khi cập nhật thường xuyên, sẽ không làm suy giảm hiệu suất bất kỳ miễn là chúng ta làm những tinh chỉnh cần thiết như việc sử dụng các truy vấn thích hợp trong delta-nhập khẩu vv

Bây giờ bạn có thể thực hiện một Solr join trên ID trên hai chỉ mục này để đạt được những gì bạn muốn. Dưới đây là link về cách thực hiện các mối liên hệ giữa các chỉ số Solr/Solr.