NoSQL (MongoDB) vs Lucene(或Solr)作为您的数据库

随着基于文档数据库的NoSQL运动的发展，我最近研究了MongoDB。我注意到在如何将项目视为“文档”方面有惊人的相似之处，就像Lucene(以及Solr的用户)所做的那样。

所以，问题是:为什么你想要使用NoSQL (MongoDB, Cassandra, CouchDB等)而不是Lucene(或Solr)作为你的“数据库”?

我(我相信其他人也一样)想要的答案是对它们进行深入的比较。让我们一起跳过关系数据库的讨论，因为它们有不同的用途。

Lucene提供了一些重要的优势，比如强大的搜索和权重系统。更不用说Solr中的facet了(Solr很快就要被集成到Lucene中了!)你可以使用Lucene文档来存储id，并像MongoDB一样访问这些文档。将它与Solr混合使用，您现在就得到了一个基于webservice的负载均衡解决方案。

在讨论MongoDB类似的数据存储和可伸缩性时，您甚至可以将Velocity或MemCached等进程外缓存提供商进行比较。

MongoDB的限制让我想起了使用MemCached，但是我可以使用微软的Velocity，并且比MongoDB拥有更多的分组和列表收集能力(我认为)。没有比在内存中缓存数据更快或可伸缩的方法了。甚至Lucene也有内存提供商。

MongoDB(和其他)确实有一些优势，比如它们的API易于使用。新建一个文档，创建一个id，并存储它。完成了。很简单。

74522 次浏览
小开
最佳答案

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

  1. 你可以很容易地在所有情况下使用Lucene/Solr代替MongoDB，但反之亦然。Grant Ingersoll的的帖子总结在这里

  2. MongoDB等似乎服务于不需要搜索和/或faceting的目的。对于从RDBMS世界中解脱出来的程序员来说，这似乎是一种更简单、更容易的过渡。除非你已经习惯了Lucene &Solr的学习曲线更陡峭。

  3. 使用Lucene/Solr作为数据存储的例子并不多，但Guardian已经取得了一些进展，并在幻灯片中总结了这一点，但他们也没有完全加入Solr的行列，并“研究”将Solr与CouchDB结合起来。

  4. 最后，我将提供我们的经验，不幸的是，不能透露太多的商业案例。我们处理几TB的数据，这是一个近乎实时的应用程序。在研究了各种组合后，决定坚持使用Solr。至今没有遗憾(6个月&计数)，并且认为没有理由换到其他公司。

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

我的两分钱，希望能有所帮助。

小开

在solr中不能部分更新文档。为了更新文档，您必须重新发布所有字段。

性能很重要。如果不提交，则对solr的更改不会生效，如果每次都提交，则性能会受到影响。

在solr中没有事务。

由于solr有这些缺点，有时NoSQL是更好的选择。

更新: Solr 4+开始支持提交和软提交。参考最新的文档https://lucene.apache.org/solr/guide/8_5/

小开

另外请注意，有些人已经将Solr/Lucene集成到Mongo中，将所有索引存储在Solr中，并监视oplog操作，并将相关更新级联到Solr中。

使用这种混合方法，您可以真正兼得全文搜索和快速读取等功能，并使用可靠的数据存储，同时还可以具有惊人的写入速度。

设置起来有点技术性，但是有很多oplog tailer可以集成到solr中。看看rangespan在本文中做了什么。

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

小开

由于没有人提到它，让我补充一下，MongoDB是无模式的，而Solr强制使用模式。因此，如果文档的字段可能会发生变化，这是选择MongoDB而不是Solr的一个原因。

小开

我们同时使用MongoDB和Solr，它们的性能很好。你可以找到我的这里是博客文章，我描述了我们如何一起使用这些技术。以下是节选:

< p >[…然而，我们观察到，当索引时，Solr的查询性能下降 尺寸增加。我们意识到最好的解决方案是同时使用Solr和Solr 和Mongo DB合作。然后，我们通过存储将Solr与MongoDB集成 内容到MongoDB和创建索引使用Solr全文 搜索。我们只在Solr索引中存储每个文档的唯一id 并在Solr上搜索后从MongoDB中检索实际内容。 从MongoDB获取文档比Solr更快，因为没有 分析，评分等[…]

小开

从我的经验来看，Mongo非常适合简单、直接的使用。Mongo的主要缺点是在意料之外的查询上性能很差(你不能为所有可能的过滤/排序组合创建Mongo索引，你就是不能)。

在这方面，Lucene/Solr大受欢迎，特别是在FilterQuery缓存方面，性能非常出色。

小开

@mauricio-scheffer提到了Solr 4——对于那些感兴趣的人，LucidWorks将Solr 4描述为“NoSQL搜索服务器”，http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/上有一个视频，他们详细介绍了NoSQL(ish)特性。(ish代表他们版本的无模式实际上是一种动态模式。)

小开

如果你只是想用键值格式存储数据，不建议使用Lucene，因为它的倒立索引会浪费太多的磁盘空间。由于数据保存在磁盘上，它的性能比NoSQL数据库(如redis)慢得多，因为redis将数据保存在RAM中。Lucene最大的优势是它支持大量的查询，因此可以支持模糊查询。

小开

第三方解决方案，比如mongo op-log尾巴是有吸引力的。假设从开发/体系结构的角度来看，仍然存在一些关于解决方案是否可以紧密集成的想法或问题。我不希望看到这些功能的紧密集成解决方案，原因有几个(有些推测和有待澄清，并且没有跟上开发进度):

  • mongo是c++， lucene/solr是Java
    • 也许lucene需要一些芒果
    • 也许mongo可以重写一些lucene算法，参见:
      • http://clucene.sourceforge.net/
      • http://lucy.apache.org/
        • 李< / ul > < / > 李< / ul > < / >
      • lucene支持各种doc格式
        • mongo专注于JSON (BSON)
          • 李< / ul > < / > lucene使用不可变文档
          • 单个字段更新是一个问题，如果它们可用的话
            • 李< / ul > < / >
          • 通过复杂的合并操作，Lucene索引是不可变的
          • Mongo查询是javascript
          • mongo没有文本分析器/标记器(AFAIK)
          • Mongo文档的大小是有限的，这可能会违背lucene的谷物
            • mongo聚合操作可能在lucene中没有位置
            • Lucene有跨文档存储字段的选项，但这不是一回事
            • solr以某种方式提供聚合/统计和SQL/图形查询
              • 李< / ul > < / >
小开

MongoDB Atlas很快就会有一个基于lucene的搜索引擎。这一重大消息是在本周的2019年MongoDB世界会议上宣布的。这是鼓励他们更多使用高收入的MongoDB Atlas产品的好方法。

我希望它能被应用到MongoDB企业版4.2中，但目前还没有将其应用到他们的on-prem产品线的消息。

更多信息:https://www.mongodb.com/atlas/full-text-search


提交答案