NoQuery (MongoDB) so với Lucene (hoặc Solr) làm cơ sở dữ liệu của bạn

Với phong trào NoQuery đang phát triển dựa trên cơ sở dữ liệu dựa trên tài liệu, tôi đã xem xét MongoDB gần đây. Tôi đã nhận thấy sự tương đồng đáng kinh ngạc với cách coi các vật phẩm là "Tài liệu", giống như Lucene (và người dùng Solr).

Vì vậy, câu hỏi: Tại sao bạn muốn sử dụng NoQuery (MongoDB, Cassandra, CouchDB, v.v.) trên Lucene (hoặc Solr) làm "cơ sở dữ liệu" của bạn?

Những gì tôi (và tôi chắc chắn rằng những người khác đang tìm kiếm trong một câu trả lời là một số so sánh sâu sắc của họ. Chúng ta hãy bỏ qua các cuộc thảo luận cơ sở dữ liệu quan hệ cùng nhau, vì chúng phục vụ một mục đích khác nhau.

Lucene cung cấp một số lợi thế nghiêm trọng, chẳng hạn như hệ thống tìm kiếm và trọng lượng mạnh mẽ. Không đề cập đến các khía cạnh trong Solr (mà Solr sẽ sớm được tích hợp vào Lucene, yay!). Bạn có thể sử dụng các tài liệu Lucene để lưu trữ ID và truy cập các tài liệu giống như MongoDB. Trộn nó với Solr và bây giờ bạn có được một giải pháp cân bằng tải dựa trên WebService.

Bạn thậm chí có thể so sánh các nhà cung cấp bộ đệm ngoài luồng như Velocity hoặc MemCached khi nói về lưu trữ dữ liệu tương tự và khả năng mở rộng của MongoDB.

Các hạn chế xung quanh MongoDB nhắc nhở tôi về việc sử dụng MemCached, nhưng tôi có thể sử dụng Velocity của Microsoft và có nhiều khả năng phân nhóm và liệt kê danh sách hơn MongoDB (tôi nghĩ). Không thể nhận được bất kỳ tốc độ nhanh hơn hoặc có thể mở rộng hơn dữ liệu bộ nhớ đệm trong bộ nhớ. Ngay cả Lucene cũng có một nhà cung cấp bộ nhớ.

MongoDB (và những người khác) có một số lợi thế, chẳng hạn như dễ sử dụng API của họ. Mới lập một tài liệu, tạo một id và lưu trữ nó. Làm xong. Tốt đẹp và dễ dàng.

Đây là một câu hỏi tuyệt vời, một cái gì đó tôi đã suy nghĩ khá nhiều. Tôi sẽ tóm tắt những bài học của tôi đã học:

1. Bạn có thể dễ dàng sử dụng Lucene / Solr thay cho MongoDB cho tất cả các tình huống, nhưng không phải ngược lại. Bài viết của Grant Ingersoll tổng hợp nó ở đây.

2. MongoDB, vv dường như phục vụ một mục đích mà không có yêu cầu tìm kiếm và / hoặc faceting. Nó dường như là một quá trình chuyển đổi đơn giản hơn và dễ dàng hơn cho các lập trình viên cai nghiện từ thế giới RDBMS. Trừ khi ai đó quen với nó, Lucene & Solr có một đường cong học tập dốc hơn.

3. Không có nhiều ví dụ về việc sử dụng Lucene / Solr làm kho dữ liệu, nhưng Guardian đã thực hiện một số bước tiến và tóm tắt điều này trong một sàn trượt tuyệt vời , nhưng họ cũng không tham gia vào việc nhảy hoàn toàn vào băng nhóm Solr và "điều tra" kết hợp Solr với CouchDB.

4. Cuối cùng, tôi sẽ cung cấp kinh nghiệm của chúng tôi, tiếc là không thể tiết lộ nhiều về trường hợp kinh doanh. Chúng tôi làm việc trên quy mô của một vài TB dữ liệu, một ứng dụng gần thời gian thực. Sau khi điều tra các kết hợp khác nhau, quyết định gắn bó với Solr. Không hối tiếc cho đến nay (6 tháng và đếm) và không thấy lý do gì để chuyển sang một số khác.

Tóm tắt: nếu bạn không có yêu cầu tìm kiếm, Mongo cung cấp một cách tiếp cận đơn giản và mạnh mẽ. Tuy nhiên, nếu tìm kiếm là chìa khóa cho sản phẩm của bạn, bạn có khả năng tốt hơn nên gắn bó với một công nghệ (Solr / Lucene) và tối ưu hóa cái quái vật đó - ít bộ phận chuyển động hơn.

2 xu của tôi, hy vọng rằng đã giúp.

Bạn không thể cập nhật một phần tài liệu trong solr. Bạn phải đăng lại tất cả các trường để cập nhật tài liệu.

Và vấn đề hiệu suất. Nếu bạn không cam kết, thay đổi của bạn thành solr sẽ không có hiệu lực, nếu bạn cam kết mỗi lần, hiệu suất sẽ bị ảnh hưởng.

Không có giao dịch trong solr.

Vì solr có những nhược điểm này, đôi khi nosql là lựa chọn tốt hơn.

Chúng tôi sử dụng MongoDB và Solr cùng nhau và chúng hoạt động tốt. Bạn có thể tìm thấy bài đăng trên blog của tôi ở đây nơi tôi đã mô tả cách chúng tôi sử dụng các công nghệ này cùng nhau. Đây là một đoạn trích:

[...] Tuy nhiên, chúng tôi quan sát thấy hiệu suất truy vấn của Solr giảm khi kích thước chỉ mục tăng. Chúng tôi nhận ra rằng giải pháp tốt nhất là sử dụng cả Solr và Mongo DB cùng nhau. Sau đó, chúng tôi tích hợp Solr với MongoDB bằng cách lưu trữ nội dung vào MongoDB và tạo chỉ mục bằng Solr để tìm kiếm toàn văn. Chúng tôi chỉ lưu trữ id duy nhất cho mỗi tài liệu trong chỉ mục Solr và truy xuất nội dung thực tế từ MongoDB sau khi tìm kiếm trên Solr. Nhận tài liệu từ MongoDB nhanh hơn Solr vì không có máy phân tích, ghi điểm, v.v ... []]

Ngoài ra, xin lưu ý rằng một số người đã tích hợp Solr / Lucene vào Mongo bằng cách lưu trữ tất cả các chỉ mục trong Solr và cũng giám sát các hoạt động oplog và xếp tầng các cập nhật có liên quan vào Solr.

Với phương pháp lai này, bạn thực sự có thể có cả hai thế giới tốt nhất với các khả năng như tìm kiếm toàn văn bản và đọc nhanh với kho dữ liệu đáng tin cậy cũng có thể có tốc độ ghi nhanh.

Đó là một chút kỹ thuật để thiết lập nhưng có rất nhiều thợ may oplog có thể tích hợp vào solr. Kiểm tra những gì rangespan đã làm trong bài viết này.

http://den normalised.com/home/mongodb-pub-sub-USE-the-replication-oplog.html

Từ kinh nghiệm của tôi với cả hai, Mongo rất tuyệt cho việc sử dụng đơn giản, dễ hiểu. Nhược điểm chính của Mongo mà chúng tôi phải chịu là hiệu suất kém đối với các truy vấn không dự đoán được (bạn không thể tạo chỉ mục mongo cho tất cả các kết hợp bộ lọc / sắp xếp có thể, bạn không thể đơn giản).

Và tại đây, nơi Lucene / Solr chiếm ưu thế thời gian lớn, đặc biệt là với bộ nhớ đệm FilterQuery, Hiệu suất rất nổi bật.

Vì không có ai khác đề cập đến nó, nên tôi thêm rằng MongoDB không có lược đồ, trong khi Solr thi hành một lược đồ. Vì vậy, nếu các trường trong tài liệu của bạn có thể thay đổi, đó là một lý do để chọn MongoDB thay vì Solr.

@ mauricio-scheffer đã đề cập đến Solr 4 - đối với những người quan tâm đến điều đó, LucidWorks đang mô tả Solr 4 là "Máy chủ tìm kiếm NoQuery" và có một video tại http://www.lucidworks.com/webinar-solr-4-the-nosql -search-server / nơi họ đi vào chi tiết về các tính năng của NoQuery (ish). (The -ish dành cho phiên bản schemaless của họ thực sự là một lược đồ động.)

Nếu bạn chỉ muốn lưu trữ dữ liệu bằng định dạng khóa-giá trị, Lucene không được khuyến nghị vì chỉ mục đảo ngược của nó sẽ lãng phí quá nhiều không gian đĩa. Và với việc lưu dữ liệu trong đĩa, hiệu suất của nó chậm hơn nhiều so với cơ sở dữ liệu NoQuery như redis vì redis lưu dữ liệu trong RAM. Ưu điểm nhất đối với Lucene là nó hỗ trợ nhiều truy vấn, vì vậy các truy vấn mờ có thể được hỗ trợ.

Các giải pháp của bên thứ ba, như đuôi op-log mongo rất hấp dẫn. Một số suy nghĩ hoặc câu hỏi vẫn còn về việc các giải pháp có thể được tích hợp chặt chẽ hay không, giả sử viễn cảnh phát triển / kiến ​​trúc. Tôi không mong đợi thấy một giải pháp tích hợp chặt chẽ cho các tính năng này vì một số lý do (hơi suy đoán và có thể làm rõ và không cập nhật với các nỗ lực phát triển):

• mongo là c ++, lucene / solr là java
  • có lẽ lucene có thể sử dụng một số libs mongo
  • có lẽ mongo có thể viết lại một số thuật toán lucene, xem thêm:
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• lucene hỗ trợ các định dạng tài liệu khác nhau
  • mongo tập trung vào JSON (BSON)
• lucene sử dụng tài liệu bất biến
  • cập nhật trường đơn là một vấn đề, nếu chúng có sẵn
• chỉ số lucene là bất biến với ops hợp nhất phức tạp
• truy vấn mongo là javascript
• mongo không có máy phân tích văn bản / mã thông báo (AFAIK)
• kích thước tài liệu mongo bị giới hạn, có thể đi ngược lại với hạt cho lucene
• ops tập hợp mongo có thể không có chỗ trong lucene
  • lucene có các tùy chọn để lưu trữ các trường trên các tài liệu, nhưng đó không phải là điều tương tự
  • solr bằng cách nào đó cung cấp tổng hợp / thống kê và truy vấn SQL / đồ thị

MongoDB Atlas sẽ sớm có một công cụ tìm kiếm dựa trên lucene. Thông báo lớn được đưa ra tại hội nghị MongoDB World 2019 tuần này. Đây là một cách tuyệt vời để khuyến khích sử dụng nhiều hơn sản phẩm MongoDB Atlas có doanh thu cao của họ.

Tôi đã hy vọng thấy nó được đưa vào MongoDB Enterprise phiên bản 4.2 nhưng không có tin tức gì về việc đưa nó vào dòng sản phẩm tại chỗ của họ.

Thêm thông tin ở đây: https://www.mongodb.com/atlas/full-text-search