NoSQL（MongoDB）vs Lucene（或Solr）作为数据库

280

随着基于文档数据库的NoSQL运动不断发展，我最近研究了MongoDB。我已经注意到与Lucene（和Solr的用户）一样，如何将项目视为“文档”也有惊人的相似之处。

所以，问题是：为什么要在Lucene（或Solr）上使用NoSQL（MongoDB，Cassandra，CouchDB等）作为“数据库”？

我在寻找答案时（我确信其他人正在寻找）是对它们的一些深入比较。让我们一起跳过关系数据库的讨论，因为它们有不同的用途。

Lucene具有一些重要的优点，例如强大的搜索和权重系统。更不用说Solr中的方面了（是的，Solr即将集成到Lucene中，是的！）。您可以使用Lucene文档来存储ID，并像访问MongoDB一样访问文档。将其与Solr混合使用，您现在可以获得基于WebService的负载平衡解决方案。

在谈论类似的数据存储和MongoDB的可伸缩性时，您甚至可以对诸如Velocity或MemCached之类的进程外缓存提供程序进行比较。

关于MongoDB的限制使我想起使用MemCached，但是我可以使用Microsoft的Velocity，并且对MongoDB具有更多的分组和列表收集功能（我认为）。没有比在内存中缓存数据更快或可扩展的方法。甚至Lucene都有一个内存提供程序。

MongoDB（和其他）确实具有一些优势，例如易于使用它们的API。新建一个文档，创建一个ID，然后存储它。做完了 好，易于。

mongodb  solr  lucene  memcached  nosql 
— eduncan911
source
8
— bajafresh4life
4
谢谢，但是那不能回答我的问题：那就是为什么我的数据库使用MongoDB而不是Lucene？它们都处理文档，但是Lucene有一些非常强大的搜索选项。+1，但实际上是找到了一个相关问题。我在Stackoverflow上搜索了几次，但没有给出接近的比较。
— eduncan911
您如何使用提供与MongoDB类似功能的Lucene？您是否将其绑定到关系数据库进行存储？
— 菲利普·廷尼
1
@Philip：这是一个假想的问题。为什么不使用Lucene作为文档存储？您将获得更多的搜索能力和可伸缩性（与Solr混合使用，使Lucene更加易于使用）。
— eduncan911

Answers:

249

这是一个很大的问题，我已经深思了一下。我将总结我的经验教训：

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

  2. MongoDB等似乎用于不需要搜索和/或构面的目的。对于程序员从RDBMS世界中解毒而言，这似乎是一个更简单且可以说更容易的过渡。除非习惯了Lucene和Solr，否则学习曲线会更陡峭。

  3. 没有很多使用Lucene / Solr作为数据存储的示例，但Guardian取得了一些进展，并在一个出色的幻灯片中对其进行了总结，但是对于完全跳上Solr潮流并“研究”结合Solr的做法，他们也不是无所事事。与CouchDB。

  4. 最后，我将提供我们的经验，很遗憾，我无法透露很多有关业务案例的信息。我们正在处理几TB的数据规模，这是一种近乎实时的应用程序。在研究了各种组合之后，决定坚持使用Solr。到目前为止，没有任何遗憾（六个月及以上），也没有理由改用其他产品。

简介：如果您没有搜索要求，Mongo提供了一种简单而强大的方法。但是，如果搜索是您提供产品的关键，那么您最好还是坚持使用一项技术（Solr / Lucene）并对其进行优化，减少运动部件。

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

— 米科斯
source
10
Solr没有地图缩小功能。因此，报告，统计数据，分数计算等是不可能的！仅当您拥有/可以威胁您的数据作为文本数据时，才使用Solr
— Roland Kofler
8
Solr没有内置的map-reduce，但是您可以将其与Hadoop结合使用。architects.dzone.com/articles/solr-hadoop-big-data-love
— Mikos，
6
Map-reduce不，但是它确实具有跨多个solr服务器并行运行查询并汇总这些结果的能力。因此，尽管它没有通用的map-reduce功能，但它已经用并行搜索查询map-reduce编写了您要编写的内容。
— chubbsondubs 2012年
@Roo：可以选择使用Lucene作为主要数据库并以某种方式与MongoDB创建聚合索引吗？还是没有道理？和Mikos：一个不错的答案，并为实际体验提供+1。
— 绝望的鬼脸
2
从solr6开始，它支持带有并行表达式的map reduce功能
— Divyang Shah
36

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

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

Solr中没有事务。

由于solr具有这些缺点，因此有时nosql是更好的选择。

— 彼得·朗
source
13
MongoDB也没有事务。
— user183037 2011年
1
Solr或Lucene具有实时搜索功能，因此提交不是问题。
— mihaicc 2012年
1
@ user183037在MongoDB中，文档中的任何更新都是Atomic。仅供参考，Lucene也没有交易（就您而言）
— Aravind Yarram
48
这个答案变得不正确。Solr 4+确实支持部分更新，并且软提交/接近实时消除了大多数“旧式” Solr提交问题。
— Mauricio Scheffer
1
他们增加了对MongoDB 4上交易的支持。–
— Jonas
26

我们一起使用MongoDB和Solr，它们表现良好。您可以在这里找到我的博客文章，其中我描述了我们如何一起使用这项技术。摘录如下：

[...]但是，我们观察到，当索引大小增加时，Solr的查询性能会降低。我们意识到最好的解决方案是同时使用Solr和Mongo DB。然后，通过将内容存储到MongoDB中并使用Solr进行全文搜索创建索引，我们将Solr与MongoDB集成在一起。我们仅在Solr索引中存储每个文档的唯一ID，并在Solr上搜索后从MongoDB中检索实际内容。从MongoDB获取文档比从Solr更快，因为没有分析器，评分等。[...]

— 帕文·加辛扎德（Parvin Gasimzade）
source
3
好的博客文章。是的，这正是我过去在早期SQL和MySql数据存储中使用Lucene的方式（在Lucene中存储ID，并从数据存储中检索复杂类型）。但是从技术上讲，这个问题是探索两者之间的差异，而不是确切地讲如何使用“两全其美”。+1以这种方式使用它，因为它实际上是使用大量数据的唯一真实方法。
— eduncan911
感谢您的答复。我知道问题是关于选择Nosql而不是Lucene，但在这里我想表明，以混合方式使用它们而不是一个选择另一个，这会带来更好的结果。
— Parvin Gasimzade
2
您还记得（现在是1.5年后）查询性能下降这么多以至于您开始考虑添加MongoDB时Solr数据库的大致大小吗？（是10,000个文档还是10,000,000个文档？）
— KajMagnus
非常有帮助。我在GIS中工作，因此能够以这种方式将全文与空间搜索结合起来非常有趣。我们已经使用过MongoDB和Postgres，并且我一直在考虑Solr。
— John Powell
2
@ParvinGasimzade博客文章链接无效。您能否提供其他链接或来源？
— 遗忘了
24

还请注意，有些人通过将所有索引存储在Solr中，还监视oplog操作并将相关更新级联到Solr中，从而将Solr / Lucene集成到Mongo中。

使用这种混合方法，您可以真正实现两全其美，并具有诸如全文本搜索和具有可靠数据存储的快速读取功能，这些数据存储还可以提供极快的写入速度。

设置有些技巧，但是有很多oplog尾板可以集成到solr中。查看本文的rangepan。

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

— 普拉斯·戈文（Prasith Govin）
source
如果我理解正确，那么使用MongoDB（除了Solr）的原因是MongoDB具有更快的插入+读取速度吗？您是否还表示MongoDB具有更可靠的数据存储？（或者您指的是Solr？）—您最初是从什么开始的？仅MongoDB，仅Solr，还是同时使用Mongo + Solr？
— KajMagnus
12

根据我的经验，Mongo非常适合简单，直接的用法。我们遭受的主要Mongo劣势是无法预料的查询性能不佳（您无法为所有可能的过滤器/排序组合创建mongo索引，而您无法创建）。

在Lucene / Solr大获成功的地方，尤其是使用FilterQuery缓存时，性能非常出色。

— 贾拉耶尔
source
10

既然没有人提到它，那么让我补充一下，MongoDB是无架构的，而Solr则实施了架构。因此，如果您的文档字段可能会更改，那就是选择MongoDB而不是Solr的原因之一。

— 水彩画
source
6
恕我直言，这不是真的。Solr确实具有中定义的架构schema.xml，但是它也具有“动态字段”，即其类型是通过通配符确定的字段，因此您可以将所有匹配的字段（例如，*_i索引为整数字段）进行索引。添加文档时，您可以使文档包含诸如count_i，那样的字段foo_i，bar_i这些字段都被理解为整数字段，而没有出现在schema.xml字面上。我会说，它的模式很少。有关更多信息，请参见youtube.com/watch?v=WYVM6Wz-XTw。
— 流量
我必须回过头来用+1来解决这个问题，因为这是正确的-Solr中的架构更改始终位于PITA中，以与其他数据存储保持同步。
— eduncan911 2014年
4
Solr具有支持架构或无模式的功能！
— Krunal
1

如果只想使用键值格式存储数据，则不建议使用Lucene，因为其反向索引会浪费太多磁盘空间。而且，由于将数据保存在磁盘中，其性能比RedSQL等NoSQL数据库要慢得多，因为Redis将数据保存在RAM中。Lucene的最大优点是它支持很多查询，因此可以支持模糊查询。

— 张洪岩
source
1

像mongo op-log tail这样的第三方解决方案很有吸引力。假设从开发/架构的角度来看，关于解决方案是否可以紧密集成仍然存在一些想法或问题。由于某些原因，我不希望看到针对这些功能的紧密集成的解决方案（有些投机性，并且需要澄清，而不是最新的开发工作）：

  • mongo是c ++，lucene / solr是java
  • lucene支持各种文档格式
    • mongo专注于JSON（BSON）
  • lucene使用不可变的文档
    • 单字段更新（如果可用）是一个问题
  • lucene索引对于复杂的合并操作是不可变的
  • mongo查询是javascript
  • mongo没有文本分析器/标记器（AFAIK）
  • mongo doc的大小有限，可能与lucene的使用背道而驰
  • Mongo Aggregation Ops在Lucene中可能没有位置
    • lucene可以选择在文档之间存储字段，但这不是一回事
    • solr以某种方式提供聚合/统计信息和SQL /图形查询
— 达伦·韦伯
source
0

MongoDB Atlas即将推出基于Lucene的搜索引擎。重大公告是在本周的MongoDB World 2019大会上宣布的。这是鼓励更多使用其高收入MongoDB Atlas产品的好方法。

我希望看到它加入到MongoDB Enterprise版本4.2中，但是没有消息将其引入其本地产品线。

此处提供更多信息：https : //www.mongodb.com/atlas/full-text-search

— 加里·鲁索
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.