Nếu không đi sâu vào một chủ đề dài có lẽ sẽ không phù hợp với diễn đàn lập trình, tôi sẽ cố gắng đề cập đến vấn đề này về cơ bản, nhưng vẫn cố gắng và bao quát các điểm.
Điều chính cần xem xét khi chuyển sang so sánh rộng là: "Công cụ tìm kiếm văn bản đầy đủ của cơ sở dữ liệu quan hệ 'XYZ' xếp chồng lên nhau như thế nào so với Lucene" .
Vì vậy, nếu bạn cân nhắc điều đó và đã có kinh nghiệm với khả năng "toàn văn" được tích hợp sẵn của các sản phẩm đó thì đó là những điều bạn nên được so sánh với táo "toàn văn" MongoDB.
Tóm lại, MongoDB cung cấp các khả năng toàn văn cơ bản, không khác nhiều so với các khả năng có trong các sản phẩm quan hệ. Như đã đề cập trong a :) , cơ sở vật chất còn mới, nhưng tốt hơn so với những gì đã có trước đây, không có gì cả.
Vào b :) , Lucene, và các dẫn xuất / đối tác (Solr / ElasticSearch, v.v.) nên được coi là một động vật hoàn toàn khác. Nơi bạn cần mã hóa mã hóa và gốc nâng cao, được xây dựng trong cơ sở vật chất cho "Tương tự như thế này" và số lượng khía cạnh trên các tìm kiếm. Trong những trường hợp đó, sản phẩm riêng biệt là nhu cầu cần thiết.
Tất nhiên có một số giải pháp xung quanh để lập chỉ mục dữ liệu từ các cửa hàng MongoDB trong Lucene, v.v. và thậm chí tùy chỉnh quá trình này không khó. Nhưng nó đang duy trì một phần chuyển động khác trong cơ sở hạ tầng của bạn.
Vì vậy, tôi không thực sự thấy điều này là cần thiết để so sánh Tìm kiếm văn bản MongoDB với Lucene, vì cuối cùng chúng tồn tại để làm những việc khác nhau, đó chỉ là vấn đề bạn cần cho ứng dụng của bạn. Chọn giải pháp tốt nhất cho bạn.
Điều duy nhất cần nói thêm là họ Lucene (và dẫn xuất) là những sản phẩm tuyệt vời. Đừng né tránh việc cho họ tham gia, ít nhất là để đánh giá. Các điểm trước đây là ở đó có nhiều sức mạnh hơn bất kỳ "Tìm kiếm Văn bản Cơ sở dữ liệu Chuẩn" nào. Hơn nữa, đường cong quản trị và học tập nhìn chung "không khó như bạn nghĩ". Có một vở kịch, nó có thể đáng để thực hiện.
