Cấu hình Lucene.Net với SQL Server

Question

Có ai đã sử dụng Lucene.NET thay vì sử dụng tìm kiếm toàn văn đi kèm với máy chủ sql không?

Nếu vậy tôi sẽ quan tâm đến cách bạn triển khai nó.

Ví dụ: bạn có viết dịch vụ cửa sổ truy vấn cơ sở dữ liệu mỗi giờ sau đó lưu kết quả vào chỉ mục lucene.net không?

Answer 1

Có, tôi đã sử dụng nó cho chính xác những gì bạn mô tả. Chúng tôi có hai dịch vụ - một cho đọc, và một cho viết, nhưng chỉ vì chúng tôi có nhiều độc giả. Tôi chắc rằng chúng tôi có thể thực hiện nó chỉ với một dịch vụ (nhà văn) và nhúng trình đọc vào ứng dụng và dịch vụ web.

Tôi đã sử dụng lucene.net làm chỉ mục cơ sở dữ liệu chung, vì vậy những gì tôi nhận được về cơ bản là DB id (để lập chỉ mục email) và tôi cũng sử dụng nó để lấy lại đủ thông tin để điền kết quả tìm kiếm hoặc như vậy mà không cần chạm vào cơ sở dữ liệu. Nó làm việc rất tốt trong cả hai trường hợp, tho SQL có thể hơi chậm, vì bạn khá nhiều phải có một ID, chọn một ID vv. Chúng ta đã làm việc này bằng cách tạo một bảng tạm thời (chỉ với hàng ID trong đó) và chèn số lượng lớn từ một tệp (đó là đầu ra từ lucene) rồi tham gia vào bảng thông báo. Nhanh hơn rất nhiều.

Lucene không hoàn hảo, và bạn phải suy nghĩ một chút bên ngoài hộp cơ sở dữ liệu quan hệ, vì nó HOÀN TOÀN không phải là một, nhưng nó rất rất tốt ở những gì nó làm. Đáng xem, và, tôi đã nói, không có "oops, xin lỗi, bạn cần phải xây dựng lại chỉ số của bạn một lần nữa" vấn đề mà MS SQL của FTI nào.

BTW, chúng tôi đã xử lý 20-50 triệu email (và khoảng 1 triệu tệp đính kèm duy nhất), tổng cộng khoảng 20GB chỉ mục lucene tôi nghĩ và 250 + GB cơ sở dữ liệu SQL + tệp đính kèm.

Hiệu suất thật tuyệt vời, để nói ít nhất - chỉ cần đảm bảo bạn suy nghĩ và tinh chỉnh các yếu tố hợp nhất của bạn (khi hợp nhất các phân đoạn chỉ mục). Không có vấn đề gì trong việc có nhiều phân đoạn, nhưng có thể có vấn đề LỚN nếu bạn cố gắng hợp nhất hai đoạn có các mục 1mil trong mỗi đoạn và bạn có một chuỗi người theo dõi sẽ giết quá trình nếu mất quá nhiều thời gian ... .. (vâng, điều đó đã đá vào mông của chúng tôi một lúc). Vì vậy, giữ số lượng tài liệu tối đa cho mỗi thinggie LOW (nghĩa là, không đặt nó thành maxint như chúng tôi đã làm!)

EDIT Corey Trager ghi lại cách sử dụng Lucene.NET trong BugTracker.NET here.

Answer 2

Tôi nghĩ rằng bài viết này là một điểm khởi đầu tốt:

http://www.aspfree.com/c/a/braindump/working-with-lucene-net/

Answer 3

tôi đã không làm được điều đó chống lại cơ sở dữ liệu nào, câu hỏi của bạn là kinda mở.

Nếu bạn muốn tìm kiếm một db và có thể chọn sử dụng Lucene, tôi cũng đoán rằng bạn có thể kiểm soát khi dữ liệu được chèn vào cơ sở dữ liệu. Nếu vậy, có rất ít lý do để thăm dò ý kiến ​​của db để tìm hiểu xem bạn có cần reindex hay không, chỉ cần lập chỉ mục khi bạn chèn, hoặc tạo một bảng xếp hàng có thể được sử dụng để cho biết những gì cần lập chỉ mục.

Tôi nghĩ chúng ta không cần một người lập chỉ mục khác là không biết gì về những gì nó đang làm, và reindexing mọi lúc, hoặc sử dụng tài nguyên lãng phí.

Answer 4

Tôi đã sử dụng Lucene.NET cùng với MySQL. Cách tiếp cận của tôi là lưu trữ khóa chính của bản ghi db trong tài liệu Lucene cùng với văn bản được lập chỉ mục.Trong mã giả có vẻ như:

• cửa hàng kỷ lục:

  chèn văn bản, dữ liệu khác để bàn
  nhận mới nhất ID chèn vào
  tạo tài liệu Lucene
  đặt (ID, văn bản) vào Lucene tài liệu cập nhật chỉ mục lucene

• Truy vấn
  tìm kiếm chỉ số lucene
  cho mỗi doc Lucene trong kết quả thiết lập dữ liệu tải từ DB bằng ID lưu trữ kỷ lục của

Chỉ cần lưu ý, tôi chuyển từ Lucene để Sphinx do đó hiệu suất tuyệt vời

Answer 5

Tôi đã sử dụng lucene.net cũng như công cụ lưu trữ, vì dễ dàng phân phối và thiết lập các máy thay thế với chỉ mục hơn cơ sở dữ liệu, nó chỉ là bản sao hệ thống tệp, bạn có thể lập chỉ mục trên một máy và chỉ sao chép các tệp mới vào các máy khác để phân phối chỉ mục. Tất cả các tìm kiếm và chi tiết được hiển thị từ chỉ mục lucene và cơ sở dữ liệu chỉ được sử dụng để chỉnh sửa. Thiết lập này đã được chứng minh là một giải pháp có khả năng mở rộng cho nhu cầu của chúng tôi.

Về sự khác biệt giữa máy chủ sql và lucene, vấn đề chính với máy chủ sql 2005 tìm kiếm văn bản đầy đủ là dịch vụ được tách rời khỏi công cụ quan hệ, tham gia, đặt hàng, tổng hợp và lọc giữa kết quả toàn văn và quan hệ các cột rất tốn kém về hiệu năng, Microsoft tuyên bố rằng vấn đề này đã được giải quyết trong máy chủ sql 2008, tích hợp tìm kiếm toàn văn bản bên trong công cụ quan hệ, nhưng tôi chưa thử nghiệm nó. Họ cũng làm cho toàn bộ tìm kiếm văn bản trở nên trong suốt hơn, trong các phiên bản trước, các phần tử gốc, từ dừng và một số phần khác của việc lập chỉ mục như một hộp đen và khó hiểu, và trong phiên bản mới dễ dàng hơn để xem chúng hoạt động ra sao. Với kinh nghiệm của tôi, nếu máy chủ sql đáp ứng yêu cầu của bạn, nó sẽ là cách dễ nhất, nếu bạn mong đợi rất nhiều sự tăng trưởng, truy vấn phức tạp hoặc cần kiểm soát toàn bộ tìm kiếm văn bản đầy đủ, bạn có thể xem xét làm việc với lucene từ bắt đầu bởi vì nó sẽ dễ dàng hơn để mở rộng và cá nhân hóa.