Tôi biết đã có những câu hỏi trong quá khứ về SQL 2005 so với Lucene.NET nhưng kể từ năm 2008 đã xuất hiện và họ đã thực hiện rất nhiều thay đổi và tự hỏi liệu bất cứ ai có thể cho tôi ưu/khuyết điểm (hoặc liên kết đến một bài báo).Tìm kiếm toàn văn SQL Server 2008 (FTS) so với Lucene.NET
Tôi đã xây dựng một cơ sở kiến thức có kích thước trung bình (có thể 2GB văn bản được lập chỉ mục) trên đầu trang của SQL Server 2005 FTS vào năm 2006 và hiện đã chuyển nó sang iFTS 2008. Cả hai tình huống đã làm việc tốt cho tôi, nhưng động thái từ năm 2005 đến năm 2008 thực sự là một sự cải thiện đối với tôi.
Tình huống của tôi KHÔNG giống với StackOverflow theo nghĩa là tôi đã lập chỉ mục dữ liệu chỉ được làm mới hàng đêm, tuy nhiên tôi đã cố gắng kết hợp các kết quả tìm kiếm từ nhiều câu lệnh CONTAINSTABLE lại với nhau và tới các bảng quan hệ. Trong năm 2005 FTS, điều này có nghĩa là mỗi CONTAINSTABLE sẽ phải thực hiện tìm kiếm của nó trên chỉ mục, trả lại kết quả đầy đủ và sau đó có công cụ DB kết nối các kết quả đó với các bảng quan hệ (điều này là tất cả trong suốt đối với tôi, nhưng nó đã được xảy ra và tốn kém cho các truy vấn). IFTS 2008 đã cải thiện tình trạng này vì tích hợp cơ sở dữ liệu cho phép nhiều kết quả CONTAINSTABLE trở thành một phần của kế hoạch truy vấn đã thực hiện nhiều tìm kiếm hiệu quả hơn.
Tôi nghĩ rằng cả động cơ FTS năm 2005 và 2008, cũng như Lucene.NET, có sự cân bằng kiến trúc sẽ sắp xếp tốt hơn hoặc tồi tệ hơn cho rất nhiều hoàn cảnh dự án - Tôi vừa may mắn rằng bản nâng cấp đã làm việc có lợi cho tôi. Tôi hoàn toàn có thể thấy lý do tại sao iFTS 2008 sẽ không hoạt động trong cùng một cấu hình như năm 2005 cho bản chất OLTP cao của một trường hợp sử dụng như StackOverflow.com. Tuy nhiên, tôi sẽ không giảm khả năng rằng iFTS 2008 có thể bị cô lập khỏi tải giao dịch chèn nặng ... nhưng nó cũng có vẻ như nó có thể là nhiều công việc để thực hiện điều đó khi chuyển sang Lucene.NET ... và Hệ số của Lucene.NET khó bỏ qua;)
Dù sao, với tôi, sự dễ dàng và hiệu quả của iFTS của SQL 2008 trong phần lớn các tình huống có thể làm yếu tố 'cool' của Lucene (mặc dù nó rất dễ sử dụng) đã không bao giờ được sử dụng nó trong một hệ thống sản xuất vì vậy tôi đang đặt bình luận về điều đó). Tôi sẽ rất thú vị khi biết Lucene có hiệu quả hơn bao nhiêu (đã trở thành hiện thực? Nó được triển khai ngay bây giờ?) Trong StackOverflow hay các tình huống tương tự.
này có thể giúp: http://blog.stackoverflow.com/2008/11/sql-2008-full-text-search-problems/
Đã không sử dụng SQL Server 2008 cá nhân, mặc dù dựa trên rằng blog entry, nó trông giống như chức năng tìm kiếm toàn văn là chậm hơn so với nó là vào năm 2005.
chúng tôi sử dụng cả hai khả năng tìm kiếm toàn văn, nhưng theo ý kiến của tôi nó phụ thuộc vào chính dữ liệu và nhu cầu của bạn.
chúng tôi mở rộng với máy chủ web và do đó tôi thích lucene, vì tôi không có nhiều tải trên máy chủ sql.
để bắt đầu bằng không và muốn có toàn văn bản tìm kiếm, tôi thích giải pháp máy chủ sql hơn, vì tôi nghĩ nó rất nhanh để có kết quả, nếu bạn muốn lucene bạn phải thực hiện nhiều hơn lúc bắt đầu (và cũng nhận được một số bí quyết).
Máy chủ SQL FTS sẽ dễ quản lý hơn cho việc triển khai nhỏ. Vì FTS được tích hợp với DB, RDBMS xử lý việc cập nhật chỉ mục một cách tự động. Con ở đây là bạn không có một giải pháp mở rộng rõ ràng ngắn của nhân rộng của DB. Vì vậy, nếu bạn không cần phải mở rộng quy mô, SQL Server FTS có lẽ là "an toàn hơn". Về mặt chính trị, hầu hết các cửa hàng sẽ thoải mái hơn với một giải pháp SQL Server thuần túy.
Về phía Lucene, tôi sẽ ủng hộ SOLR qua thẳng Lucene. Với một trong hai giải pháp, bạn phải tự làm việc nhiều hơn để cập nhật chỉ mục khi dữ liệu thay đổi, cũng như tự ánh xạ dữ liệu đến chỉ mục SOLR/Lucene. Ưu điểm là bạn có thể dễ dàng mở rộng bằng cách thêm các chỉ mục bổ sung. Bạn có thể chạy các chỉ mục này trên các máy chủ Linux rất gọn gàng, giúp loại bỏ một số chi phí giấy phép. Nếu bạn sử dụng tuyến Lucene/SOLR, tôi sẽ đặt tất cả dữ liệu bạn cần trực tiếp vào chỉ mục, thay vì đặt con trỏ trở lại DB trong chỉ mục. Bạn có thể bao gồm dữ liệu trong chỉ mục không thể tìm kiếm được, vì vậy, ví dụ: bạn có thể có sẵn HTML hoặc XML được lưu trữ sẵn trong chỉ mục và phân phối nó dưới dạng kết quả tìm kiếm. Với phương pháp này, DB của bạn có thể ngừng hoạt động nhưng bạn vẫn có thể phục vụ kết quả tìm kiếm ở chế độ bị ngắt kết nối.
Tôi chưa bao giờ thấy sự so sánh hiệu suất giữa hai đầu giữa SQL Server 2008 và Lucene, nhưng rất thích xem một.
Một lưu ý mà bạn cần nhớ là loại ràng buộc tìm kiếm nào bạn có ngoài ràng buộc toàn văn. Nếu bạn đang làm những ràng buộc mà lucene không thể cung cấp, thì bạn gần như chắc chắn sẽ muốn sử dụng FTS. Một trong những điều tốt đẹp về năm 2008 là họ đã cải thiện sự tích hợp của FTS với các truy vấn máy chủ sql chuẩn để hiệu suất nên tốt hơn với cơ sở dữ liệu hỗn hợp và ràng buộc FT so với năm 2005.