Làm thế nào để thiết lập Lucene/Solr cho một ứng dụng web B2B?

Question

Given:

• 1 cơ sở dữ liệu cho mỗi khách hàng (kinh doanh của khách hàng)
• 5000 khách hàng
• Khách hàng có từ 2-2.000 người dùng (trung bình là ~ 100 người dùng/khách hàng)
• 100k đến 10 triệu bản ghi cho mỗi cơ sở dữ liệu
• Người dùng cần tìm kiếm các bản ghi đó thường xuyên (đó là cách tốt nhất để điều hướng dữ liệu của họ)

thông tin Có thể có liên quan:

• Một số khách hàng mới mỗi tuần (bất cứ lúc nào trong giờ làm việc)
• Nhiều máy chủ web và máy chủ cơ sở dữ liệu (người dùng có thể đăng nhập thông qua bất kỳ máy chủ web)
• Hãy ở lại thuyết bất khả tri của ngôn ngữ hoặc sql thương hiệu, vì Lucene (và Solr) có một bề rộng của hỗ trợ

Ví dụ:

Joel Spolsky cho biết trong Podcast #11 rằng sản phẩm ứng dụng web được lưu trữ trên máy chủ của mình, FogBugz On-Demand, sử dụng Lucene. Anh ấy có hàng nghìn khách hàng theo yêu cầu. Và mỗi khách hàng đều có cơ sở dữ liệu riêng của họ.

Họ sử dụng index per client and store it in the client's database. Tôi không chắc chắn về các chi tiết. Và tôi không chắc đây có phải là một bản mod nghiêm trọng cho Lucene hay không.

Các Câu hỏi:

Làm thế nào bạn sẽ thiết lập Lucene tìm kiếm để mỗi khách hàng chỉ có thể tìm kiếm trong cơ sở dữ liệu của nó?

Bạn sẽ thiết lập (các) chỉ mục như thế nào?
Bạn lưu trữ chỉ mục ở đâu?
Bạn có cần thêm bộ lọc cho tất cả các truy vấn tìm kiếm không?
Nếu khách hàng bị hủy, bạn sẽ xóa chỉ mục của họ (một phần của) như thế nào? (Điều này có thể tầm thường - không chắc chắn chưa)

Giải pháp có thể:

Hãy một chỉ số cho từng khách hàng (cơ sở dữ liệu)

• Pro: Tìm kiếm nhanh (hơn một-Index- Phần mềm for-all method). Các chỉ số có liên quan đến kích thước của dữ liệu của khách hàng.
• Con: Tôi không chắc chắn điều này đòi hỏi gì, và tôi cũng không biết điều này có nằm ngoài phạm vi của Lucene hay không.

Có chỉ mục duy nhất, khổng lồ với trường database_name. Luôn bao gồm database_name làm bộ lọc.

• Pro: Không chắc chắn. Có lẽ tốt cho hỗ trợ kỹ thuật hoặc thanh toán dept để tìm kiếm tất cả các cơ sở dữ liệu cho thông tin.
• Con: Tìm kiếm chậm hơn (so với phương pháp chỉ mục cho mỗi khách hàng). Bảo mật thiếu sót nếu bộ lọc truy vấn bị xóa.

Một điều cuối cùng:
tôi cũng sẽ chấp nhận một câu trả lời có sử dụng Solr (phần mở rộng của Lucene). Có lẽ nó phù hợp hơn cho vấn đề này. Không chắc.

Answer 1

Bạn đã triệu tập tôi từ FogBugz StackExchange. Tên tôi là Jude, tôi là kiến ​​trúc sư tìm kiếm hiện tại cho FogBugz.

Dưới đây là một phác thảo sơ bộ như thế nào FogBugz Về kiến ​​trúc tìm kiếm Nhu cầu được thiết lập [1]:

• Vì những lý do liên quan đến di chuyển dữ liệu, an ninh, vv, chúng tôi giữ tất cả các của chúng tôi trên cơ sở dữ liệu Nhu cầu và chỉ mục riêng biệt.
• Trong khi chúng ta sử dụng Lucene (Lucene.NET, thực sự), chúng tôi đã modded backend của nó khá đáng kể để nó có thể lưu trữ chỉ mục của nó hoàn toàn trong cơ sở dữ liệu. Ngoài ra, bộ nhớ cache cục bộ được duy trì trên mỗi máy chủ web để các lần truy cập cơ sở dữ liệu không cần thiết có thể tránh được bất cứ khi nào có thể.
• Bộ lọc của chúng tôi gần như hoàn toàn dựa trên cơ sở dữ liệu (vì chúng được sử dụng bởi các khía cạnh của FogBugz bên ngoài tìm kiếm), do đó trình phân tích tìm kiếm của chúng tôi phân tách các truy vấn thành các thành phần toàn văn và không phải toàn văn, thực thi tra cứu và kết hợp kết quả. Đây là một chút không may, vì nó không có nhiều tối ưu hóa hữu ích mà Lucene có khả năng tạo ra.

Có một vài lợi ích đối với những gì chúng tôi đã làm. Quản lý tài khoản khá đơn giản, vì dữ liệu khách hàng và chỉ mục của chúng được lưu trữ ở cùng một nơi. Tuy nhiên, có một số từ khóa phủ định, chẳng hạn như một tập hợp các tìm kiếm trường hợp thực sự phức tạp, hoạt động kém hơn các tiêu chuẩn tối thiểu của chúng tôi. Nhìn lại, tìm kiếm của chúng tôi thật tuyệt vời và được thực hiện tốt trong thời gian đó. Tuy nhiên, nếu tôi làm lại, tôi sẽ ngăn cản cách tiếp cận này. Đơn giản, trừ khi tên miền tìm kiếm của bạn là rất đặc biệt hoặc bạn sẵn sàng dành một nhà phát triển để tìm kiếm nhanh chóng, bạn có thể sẽ bị vượt trội bởi một sản phẩm tuyệt vời như ElasticSearch, Solr hoặc Xapian.

Nếu tôi đã làm ngày hôm nay, trừ khi miền tìm kiếm của tôi đã vô cùng đặc biệt, tôi sẽ có thể sử dụng ElasticSearch, Solr, hoặc Xapian cho giải pháp tìm kiếm cơ sở dữ liệu toàn văn hậu thuẫn của tôi. Do đó, điều đó phụ thuộc vào nhu cầu phụ trợ của bạn (nền tảng, loại truy vấn, khả năng mở rộng, dung sai cho một bộ quirks khác, v.v.)

Về chủ đề của một chỉ mục lớn so với nhiều chỉ mục rải rác:! Cả hai đều có thể hoạt động. Tôi nghĩ rằng quyết định thực sự nằm với loại kiến ​​trúc bạn đang tìm kiếm để xây dựng, và loại hiệu suất bạn cần. Bạn có thể khá linh hoạt nếu bạn quyết định rằng một phản hồi tìm kiếm 2 giây là hợp lý, nhưng một khi bạn bắt đầu nói rằng bất cứ điều gì trên 200ms là không thể chấp nhận được, các tùy chọn của bạn bắt đầu biến mất khá nhanh. Trong khi duy trì một chỉ mục tìm kiếm lớn cho tất cả khách hàng của bạn có thể lớn hơn hiệu quả hơn so với việc xử lý nhiều chỉ mục nhỏ, nó không nhất thiết phải nhanh hơn (như bạn đã chỉ ra). Cá nhân tôi cảm thấy rằng, trong một môi trường an toàn, lợi ích của việc giữ dữ liệu khách hàng của bạn được tách ra không được đánh giá thấp. Khi chỉ mục của bạn bị hỏng, nó sẽ không làm cho mọi tìm kiếm dừng lại; các lỗi nhỏ ngớ ngẩn sẽ không hiển thị dữ liệu nhạy cảm; tài khoản người dùng ở lại mô-đun - dễ dàng hơn để trích xuất một tập hợp các tài khoản và đưa chúng vào một máy chủ mới; v.v.

Tôi không chắc chắn nếu điều đó đã trả lời câu hỏi của bạn, nhưng tôi hy vọng rằng tôi ít nhất là thỏa mãn sự tò mò của bạn :-)

[1]: Trong năm 2013, FogBugz bắt đầu cung cấp năng lượng khả năng tìm kiếm và lọc với ElasticSearch. Chúng tôi thích nó.

Answer 2

Tôi vẫn chưa rõ chính xác những gì người dùng cơ sở dữ liệu 5K đang tìm kiếm, tại sao bạn cần Lucene và kích thước dữ liệu trong mỗi cơ sở dữ liệu. Nhưng tôi sẽ mất một cái dù sao:

1. Bạn nên xem Multicore Solr (mỗi lõi = 1 chỉ mục) và bạn có một URL duy nhất để truy vấn. Xác thực sẽ vẫn là một vấn đề và một cách (hackish) để tiếp cận nó sẽ làm cho URL khó đoán.

2. Máy chủ web của bạn có thể truy vấn cá thể/lõi của Solr tùy thuộc vào những gì họ có quyền truy cập.

Tôi khuyên bạn nên tránh xa cách tiếp cận bộ lọc và tạo một chỉ mục lớn kết hợp tất cả cơ sở dữ liệu.

HTH

Answer 3

Shalin Shekhar Mangar trả lời tôi trên Solr-user mailing list và qua email cá nhân. Shalin là người đóng góp cho Solr và là tác giả của cuốn sách sắp tới Solr in Action.

trả lời của Ngài trên mailing list:

Làm thế nào bạn thiết lập các chỉ số (es)?

Tôi muốn xem xét thiết lập nhiều lõi cho từng khách hàng. Bạn có thể cần phải thiết lập các nô lệ cũng tùy thuộc vào lưu lượng truy cập tìm kiếm.

Bạn lưu trữ chỉ mục ở đâu?

Thiết lập lõi 5K trên một hộp sẽ không hoạt động. Vì vậy, bạn sẽ cần phải phân vùng các khách hàng vào nhiều hộp mỗi có một tập con của lõi.

Bạn có cần thêm bộ lọc cho tất cả các truy vấn tìm kiếm không?

Nope, nhưng bạn sẽ cần phải gửi truy vấn tới máy chính xác (có lẽ một DB lập bản đồ sẽ giúp)

Nếu một khách hàng bị hủy bỏ, làm thế nào bạn sẽ xóa của họ (một phần của) mục lục? (điều này có thể tầm thường - chưa chắc chắn)

Với các lõi khác nhau cho mỗi khách hàng, điều này khá dễ dàng.

trả lời của Ngài bằng cách email:

tôi đã làm việc trên một use-case tương tự trong quá khứ và chúng tôi sử dụng phương pháp tiếp cận đa lõi với một số tối ưu hóa nặng ở phía Solr. Xem http://wiki.apache.org/solr/LotsOfCores - Tôi chưa thể đẩy những thay đổi này vào Solr.