2010-03-30 41 views
34

Trên một dự án mới, tôi cần sử dụng một cách linh hoạt để thực hiện tìm kiếm. Người tìm kiếm này sẽ là một phần rất quan trọng (và lớn) của dự án. Là hợp lý hoặc thuận tiện thay thế cơ sở dữ liệu quan hệ + Lucene với MongoDb?MongoDB có phải là lựa chọn hợp lệ cho db + lucene quan hệ không?

chỉnh sửa: Ok, tôi sẽ làm rõ: Tôi không hỏi về rủi ro, tôi có thể trả mức giá đó trong dự án này. Quan điểm của tôi là: MongoDB có định hướng đến loại điều này không? Tôi có thể làm cho một công cụ tìm kiếm đầy đủ với cùng một hiệu quả như tôi có thể nhận được trên Lucene ?. Một người bạn chỉ cho tôi ra MongoDB là thay thế, nhưng tôi không thấy liệu hiệu năng Lucene có đi kèm với thay thế tài liệu không (và sau đó, tôi cũng sẽ thấy nó trong MongoDB), hoặc ngược lại, chỉ số đảo ngược và tối ưu hóa là hoàn toàn độc lập định hướng tài liệu.

+0

2 xu của tôi: Tôi sẽ có một cách tiếp cận theo cấu trúc, trong đó bạn có thể có khả năng thay đổi nguồn dữ liệu cơ bản –

+1

Ok, tôi sẽ làm rõ: Tôi không hỏi về rủi ro, tôi có thể trả giá đó dự án. Quan điểm của tôi là: MongoDB có định hướng đến loại điều này không? Tôi có thể làm cho một công cụ tìm kiếm đầy đủ với cùng một hiệu quả như tôi có thể nhận được trên Lucene ?. Một người bạn chỉ cho tôi ra MongoDB là thay thế, nhưng tôi không thấy liệu hiệu năng Lucene có đi kèm với tài liệu thay thế không (và sau đó, tôi cũng sẽ thấy nó trong MongoDB), hoặc ngược lại, chỉ số đảo ngược và tối ưu hóa hoàn toàn độc lập định hướng tài liệu. – Hugo

Trả lời

1

Tôi không quen thuộc với MongoDB nên tôi không thể trả lời trực tiếp câu hỏi nhưng tôi muốn lưu ý rằng không giống như Lucene (khoảng mười tuổi) và cơ sở dữ liệu quan hệ (đã tồn tại hàng chục năm) MongoDB là ít hơn ba tuổi.

Ở giai đoạn này của trò chơi, có khả năng vẫn đang trưởng thành. Nó có thể phù hợp với nhu cầu của bạn (và tôi tò mò muốn xem liệu có ai quen thuộc với việc sử dụng nó sẽ kêu vang ở đây) nhưng bạn sẽ cần phải đưa yếu tố này vào phương trình của bạn. Bạn có sẵn lòng trả giá để sử dụng công nghệ tiên tiến không?

Thậm chí nếu nó có đủ ổn định và hiệu quả, bạn có thể gặp phải sự cố với sự hỗ trợ hạn chế dưới dạng trang web/hướng dẫn, v.v. (do cơ sở người dùng nhỏ). Bạn cũng đang tận dụng cơ hội nó sẽ bị ngưng.

Có thể đáng để tận dụng cơ hội này, nhưng bạn cần phải làm như vậy với đôi mắt mở và không bị mù bởi hiệu ứng "oh, nhìn vào đồ chơi mới sáng bóng".

+0

Chắc chắn Kris, tôi nhận thấy rằng, trong trường hợp cụ thể này, tôi có thể trả giá đó. Cảm ơn. – Hugo

+0

Nếu đồ chơi bị ngưng, anh ta luôn có thể di chuyển dữ liệu đến RDBMS :) –

-7

Không, không phải vì MongoDB không quan hệ.

0

Lucene là sản phẩm được thiết lập và ổn định. Than ôi như vậy vẫn chưa đúng với MongoDB. Vì vậy, tôi sẽ nghĩ rằng Lucene cộng với một RDBMS là một lựa chọn ít rủi ro hơn nhiều.

Tất nhiên, ở một mức độ nhất định, nó phụ thuộc vào bản chất của dự án: quan trọng như thế nào là "rất quan trọng (và lớn)"? Một điều nữa là, bạn có kinh nghiệm trước đây của MongoDB (tôi đoán là không)? Nếu bạn có thể tiếp cận với những người có chuyên môn thì điều đó sẽ giảm thiểu rủi ro.

2

Look của thể nhưng chậm hơn (see here)

  • Bạn sẽ phải làm tách từ và bắt nguồn tự của bạn.
  • Xếp hạng của các truy vấn 'đòi hỏi người dùng cung cấp mã để làm như vậy'
19

Về mặt kỹ thuật bạn có thể làm tìm kiếm văn bản đầy đủ với MongoDB, nhưng bạn đang bỏ lỡ rất nhiều điều mà một nhà cung cấp tìm kiếm văn bản đầy đủ có thể cung cấp. Tôi yêu MongoDB, nhưng tôi sẽ kết hợp nó với một nhà cung cấp tìm kiếm văn bản đầy đủ (chẳng hạn như Lucene hoặc Sphinx) nếu thời gian để thực hiện là tất cả một mối quan tâm. Tôi nghĩ khả năng thuận tiện để lập chỉ mục mảng từ MongoDB là tốt hơn để gắn thẻ và tìm kiếm dựa trên gắn thẻ hơn tìm kiếm toàn văn.

Tìm kiếm (Lấy thông tin) không chỉ là lấy bất kỳ tài liệu nào phù hợp, nếu bạn muốn kết quả tìm kiếm của bạn có bất kỳ sự liên quan nào, bạn cần một thứ gì đó dọc theo dòng TF-IDF, đối sánh cụm từ (các từ trong một chuỗi số điểm cao hơn) hoặc bất kỳ số kỹ thuật IR nào khác để cải thiện độ chính xác tìm kiếm. Nếu bạn sử dụng MongoDB, bạn sẽ cần phải thực hiện tất cả từ đầu.

Nếu bạn thực sự muốn thực hiện tất cả từ đầu nhưng không bận tâm với mặt lưu trữ thô, MongoDB khá gần với cửa hàng DB tốt nhất mà bạn có thể triển khai trên đầu (không thể nghĩ nhiều), nhưng điều đó vẫn không làm cho nó trở thành một lựa chọn tuyệt vời.

-1

Sau khi tham dự Devoxx năm 2011 và tham dự một bài thuyết trình từ 10gen, tôi đã viết một blog nhỏ so sánh MongoDB với RDBMS cơ sở dữ liệu. MongoDB là một trong những Nosql dbs.As phổ biến được nêu trong các câu trả lời trước MongoDB là một NoSQL db, khác với các cơ sở dữ liệu chủ đạo hiện có của rdbms.

http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql

2

MongoDB là một NoSQL, Lucene và Solr là công cụ tìm kiếm, và thêm một điều cần so sánh là bộ nhớ đệm như terracota cùng với ehcache. Tất cả đều có mục đích riêng.

Nếu tìm kiếm cùng với tìm kiếm văn bản đầy đủ là bắt buộc, các cài đặt phù hợp như hiển thị kết quả có khớp văn bản trong xếp hạng sản phẩm nhiều hơn so khớp văn bản trong desctription và nhiều tính năng dựa trên văn bản như vậy. Ngoài ra xếp hạng, phù hợp, âm thanh như nhau macthing, một phần từ phù hợp vv vv. Tất cả những điều này được xử lý tốt nhất bởi các hệ thống lưu trữ dựa trên tìm kiếm như SOLR và Lucene.

Nếu tiêu chí của bạn chỉ là truy xuất dữ liệu và bạn không cần các đối tượng dữ liệu bản trình bày của mình có độ bền cao thì chỉ cần sử dụng bộ nhớ cache lke Terracota.

Nếu bạn cần truy xuất nhanh hơn và cũng cần phải tổng hợp và tổng hợp dữ liệu trong một nguồn dữ liệu và cũng cần dữ liệu tổng hợp để bền thì sử dụng NOSQL như Mongodb.

Các vấn đề liên quan