Vâng, tôi đã sử dụng nó cho chính xác những gì bạn đang mô tả. Chúng tôi có hai dịch vụ - một để đọc và một để viết, nhưng chỉ vì chúng tôi có nhiều người đọc. Tôi chắc rằng chúng tôi có thể làm điều đó chỉ với một dịch vụ (người viết) và nhúng trình đọc vào ứng dụng web và các dịch vụ.
Tôi đã sử dụng lucene.net làm trình chỉ mục cơ sở dữ liệu chung, vì vậy những gì tôi nhận lại được về cơ bản là id DB (để 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ững thứ tương tự mà không cần chạm vào cơ sở dữ liệu. Nó hoạt động tốt trong cả hai trường hợp, vì SQL có thể hơi chậm, vì bạn phải lấy ID, chọn ID, v.v. Chúng tôi đã giải quyết vấn đề 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 hàng loạt từ một tệp (là đầu ra từ lucene) sau đó 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ệ, bởi vì nó HOÀN TOÀN không phải là một, nhưng nó rất tốt với những gì nó làm. Đáng xem xét và, tôi được biết, không có vấn đề "rất tiếc, xin lỗi, bạn cần xây dựng lại chỉ mục của mình một lần nữa" như FTI của MS SQL.
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ôi nghĩ tổng cộng khoảng 20 GB chỉ mục lucene và 250 GB cơ sở dữ liệu SQL + tệp đính kèm.
Hiệu suất là tuyệt vời, nói ít nhất - chỉ cần đảm bảo rằng bạn đã suy nghĩ và điều chỉnh, các yếu tố hợp nhất của bạn (khi nó hợp nhất các phân đoạn chỉ mục). Không có vấn đề gì khi có nhiều hơn một phân đoạn, nhưng có thể xảy ra sự cố LỚN nếu bạn cố gắng hợp nhất hai phân đoạn có hàng triệu mục trong mỗi phân đoạn và bạn có một chuỗi người xem sẽ giết chết quá trình nếu nó mất quá nhiều thời gian ... .. (vâng, điều đó đã đá vào mông chúng tôi một lúc). Vì vậy, hãy giữ số lượng tài liệu tối đa cho mỗi thứ THẤP (tức là không đặt nó thành maxint như chúng tôi đã làm!)
CHỈNH SỬA Corey Trager đã ghi lại cách sử dụng Lucene.NET trong BugTracker.NET tại đây.
