NoSQL (MongoDB) vs Lucene (或 Solr) 作为你的数据库 [英] NoSQL (MongoDB) vs Lucene (or Solr) as your database

问题描述

随着基于文档数据库的 NoSQL 运动不断发展，我最近关注了 MongoDB.我注意到与如何将项目视为文档"有惊人的相似之处，就像 Lucene(和 Solr 的用户)所做的那样.

With the NoSQL movement growing based on document-based databases, I've looked at MongoDB lately. I have noticed a striking similarity with how to treat items as "Documents", just like Lucene does (and users of Solr).

那么，问题来了:为什么要使用 NoSQL(MongoDB、Cassandra、CouchDB 等)而不是 Lucene(或 Solr)作为数据库"?

我(我相信其他人)在答案中寻找的是对它们的一些深入比较.让我们一起跳过关系数据库讨论，因为它们有不同的目的.

What I am (and I am sure others are) looking for in an answer is some deep-dive comparisons of them. Let's skip over relational database discussions all together, as they serve a different purpose.

Lucene 提供了一些重要的优势，例如强大的搜索和权重系统.更不用说 Solr 中的方面(Solr 很快就会集成到 Lucene 中，耶！).您可以使用 Lucene 文档来存储 ID，并像 MongoDB 一样访问文档.将它与 Solr 混合，您现在可以获得基于 WebService 的负载平衡解决方案.

Lucene gives some serious advantages, such as powerful searching and weight systems. Not to mention facets in Solr (which Solr is being integrated into Lucene soon, yay!). You can use Lucene documents to store IDs, and access the documents as such just like MongoDB. Mix it with Solr, and you now get a WebService-based, load balanced solution.

在谈到 MongoDB 的类似数据存储和可扩展性时，您甚至可以比较 Velocity 或 MemCached 等进程外缓存提供程序.

You can even throw in a comparison of out-of-proc cache providers such as Velocity or MemCached when talking about similar data storing and scalability of MongoDB.

MongoDB 的限制让我想起了使用 MemCached，但我可以使用 Microsoft 的 Velocity，并且比 MongoDB 拥有更多的分组和列表收集能力(我认为).无法比在内存中缓存数据更快或可扩展.甚至 Lucene 也有内存提供程序.

The restrictions around MongoDB reminds me of using MemCached, but I can use Microsoft's Velocity and have more grouping and list collection power over MongoDB (I think). Can't get any faster or scalable than caching data in memory. Even Lucene has a memory provider.

MongoDB(和其他)确实有一些优势，例如 API 易于使用.新建一个文档，创建一个 id 并存储它.完毕.很好很容易.

MongoDB (and others) do have some advantages, such as the ease of use of their API. New up a document, create an id, and store it. Done. Nice and easy.

推荐答案

这是一个很好的问题，我已经思考了很多.我将总结我的经验教训:

This is a great question, something I have pondered over quite a bit. I will summarize my lessons learned:

1. 在几乎所有情况下，您都可以轻松地使用 Lucene/Solr 代替 MongoDB，但反之则不行.Grant Ingersoll 的帖子在这里总结了这一点.

MongoDB 等似乎服务于不需要搜索和/或分面的目的.对于摆脱 RDBMS 世界的程序员来说，这似乎是一个更简单且可以说更容易的过渡.除非你习惯了 Lucene &Solr 的学习曲线更陡峭.

MongoDB etc. seem to serve a purpose where there is no requirement of searching and/or faceting. It appears to be a simpler and arguably easier transition for programmers detoxing from the RDBMS world. Unless one's used to it Lucene & Solr have a steeper learning curve.

使用 Lucene/Solr 作为数据存储的例子并不多，但 Guardian 已经取得了一些进展，并在一篇出色的 slide-deck，但他们也没有完全加入 Solr 的潮流并调查"将 Solr 与 CouchDB 结合起来.

There aren't many examples of using Lucene/Solr as a datastore, but Guardian has made some headway and summarize this in an excellent slide-deck, but they too are non-committal on totally jumping on Solr bandwagon and "investigating" combining Solr with CouchDB.

最后，我将提供我们的经验，遗憾的是不能透露太多关于商业案例的信息.我们在几 TB 的数据规模上工作，这是一个近乎实时的应用程序.在研究了各种组合之后，决定坚持使用 Solr.到目前为止没有后悔(6 个月及以后)，也没有理由改用其他的.

Finally, I will offer our experience, unfortunately cannot reveal much about the business-case. We work on the scale of several TB of data, a near real-time application. After investigating various combinations, decided to stick with Solr. No regrets thus far (6-months & counting) and see no reason to switch to some other.

总结:如果你没有搜索需求，Mongo 提供了一个简单的 &强大的方法.但是，如果搜索是您产品的关键，那么您最好还是坚持使用一种技术(Solr/Lucene)并对其进行优化 - 减少活动部件.

Summary: if you do not have a search requirement, Mongo offers a simple & powerful approach. However if search is key to your offering, you are likely better off sticking to one tech (Solr/Lucene) and optimizing the heck out of it - fewer moving parts.

我的 2 美分，希望对您有所帮助.

My 2 cents, hope that helped.

这篇关于NoSQL (MongoDB) vs Lucene (或 Solr) 作为你的数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！