NoSQL（MongoDB）与Lucene（或Solr）作为您的数据库[关闭]答案

【问题标题】：NoSQL (MongoDB) vs Lucene (or Solr) as your database [closed]NoSQL（MongoDB）与Lucene（或Solr）作为您的数据库[关闭]
【发布时间】：2011-03-14 00:04:16
【问题描述】：

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

那么，问题来了：为什么要使用 NoSQL（MongoDB、Cassandra、CouchDB 等）而不是 Lucene（或 Solr）作为“数据库”？

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

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

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

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

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

【问题讨论】：

见stackoverflow.com/questions/2546494/…
谢谢，但这并不能回答我的问题：我的数据库为什么要使用 MongoDB 而不是 Lucene？它们都处理文档，但 Lucene 有一些非常强大的搜索选项。 +1 虽然实际上是为了找到一个相关的问题。我在 Stackoverflow 上搜索了几次，但没有得出一个接近的比较。
你是如何使用 Lucene 的，它提供了类似于 MongoDB 的功能？您是否将其绑定到关系数据库进行存储？
@Philip：这是一个假设性问题。为什么不使用 Lucene 作为您的文档存储？您将获得更多的搜索能力和可扩展性（与 Solr 混合使用时，使 Lucene 更易于使用）。

标签： mongodb solr lucene memcached nosql

【解决方案1】：

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

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

solr中没有交易。

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

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

【讨论】：

MongoDB 也没有事务。
Solr 或 Lucene 具有实时搜索功能，因此提交不是问题。
@user183037 在 MongoDB 中，文档中的任何更新都是原子的。仅供参考，Lucene 也没有交易（在你的意义上）
此答案已不正确。 Solr 4+ 确实支持部分更新，并且软提交/接近实时消除了大多数“旧式”Solr 提交的问题。
他们在 MongoDB 4 上添加了对事务的支持。

【解决方案2】：

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

在几乎所有情况下，您都可以轻松地使用 Lucene/Solr 代替 MongoDB，但反之则不行。格兰特英格索尔的post sums it up here.
MongoDB 等似乎服务于不需要搜索和/或分面的目的。对于摆脱 RDBMS 世界的程序员来说，这似乎是一个更简单且可以说更容易的过渡。除非你习惯了，否则 Lucene 和 Solr 的学习曲线会更陡峭。
使用 Lucene/Solr 作为数据存储的例子并不多，但 Guardian 已经取得了一些进展，并在出色的 slide-deck 中总结了这一点，但他们也没有完全加入 Solr 潮流并“调查”将 Solr 与 CouchDB 相结合。
最后，我将提供我们的经验，遗憾的是无法透露太多有关业务案例的信息。我们在几 TB 的数据规模上工作，这是一个近乎实时的应用程序。在研究了各种组合之后，决定坚持使用 Solr。到目前为止没有后悔（6 个月及以后），也没有理由改用其他的。

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

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

【讨论】：

Solr 没有地图缩减功能。因此，无法进行报告、统计、分数计算等！仅当您拥有/可以威胁您的数据为文本数据时才使用 Solr
Solr 没有内置 map-reduce，但可以与 Hadoop 结合使用。 architects.dzone.com/articles/solr-hadoop-big-data-love
Map-reduce 否，但它确实能够跨多个 solr 服务器并行运行查询并聚合这些结果。因此，虽然它没有通用的 map-reduce，但它已经编写了您将使用 map-reduce 编写的内容，这是并行搜索查询。
@Roo：是否可以选择使用 Lucene 作为主数据库并以某种方式使用 MongoDB 创建聚合索引？或者这没有意义？和 Mikos：很好的答案和对现实世界经验提及的 +1。
从 solr6 开始，它支持使用并行表达式的 map reduce 功能

【解决方案3】：

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

我希望看到它被引入 MongoDB Enterprise 4.2 版，但没有消息将它引入他们的本地产品线。

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

【讨论】：

【解决方案4】：

第三方解决方案，如 mongo op-log tail 很有吸引力。假设从开发/架构的角度来看，关于解决方案是否可以紧密集成的一些想法或问题仍然存在。出于以下几个原因，我不希望看到针对这些功能的紧密集成的解决方案（有些推测，有待澄清，与开发工作不同步）：

mongo是c++，lucene/solr是java
- 也许 lucene 可以使用一些 mongo 库
- 也许 mongo 可以重写一些 lucene 算法，另见：
  - http://clucene.sourceforge.net/
  - http://lucy.apache.org/
lucene 支持多种文档格式
- mongo 专注于 JSON (BSON)
lucene 使用不可变文档
- 单个字段更新是个问题（如果可用）
lucene 索引对于复杂的合并操作是不可变的
mongo 查询是 javascript
mongo 没有文本分析器/标记器 (AFAIK)
mongo 文档大小有限，这可能与 lucene 不符
mongo 聚合操作可能在 lucene 中没有位置
- lucene 具有跨文档存储字段的选项，但这不是一回事
- solr 以某种方式提供聚合/统计和 SQL/图形查询

【讨论】：

【解决方案5】：

如果你只是想用key-value格式存储数据，不推荐Lucene，因为它的倒排索引会浪费太多的磁盘空间。并且由于数据保存在磁盘中，它的性能比 Redis 等 NoSQL 数据库慢很多，因为 redis 将数据保存在 RAM 中。 Lucene 最大的优势就是支持很多查询，所以可以支持模糊查询。

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

我们将 MongoDB 和 Solr 一起使用，它们的性能很好。你可以找到我的blog post here，我在其中描述了我们如何一起使用这些技术。摘录如下：

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

【讨论】：

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

【解决方案8】：

根据我对这两者的经验，Mongo 非常适合简单、直接的使用。我们遭受的主要 Mongo 缺点是在意外查询上的性能很差（您无法为所有可能的过滤器/排序组合创建 mongo 索引，您根本做不到）。

在 Lucene/Solr 盛行的地方，尤其是 FilterQuery 缓存，性能非常出色。

【讨论】：

【解决方案9】：

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

【讨论】：

恕我直言，这并不完全正确。 Solr 确实有schema.xml 中定义的模式，但它也有“动态字段”，即类型通过通配符确定的字段，因此您可以将所有匹配的字段，例如*_i 索引为整数字段。添加文档时，您可以拥有包含 count_i、foo_i、bar_i 等字段的文档，这些字段都被理解为整数字段，而不会出现在 schema.xml 中。我会说，非常无模式。更多信息请参见youtube.com/watch?v=WYVM6Wz-XTw。
我必须回来并用 +1 来提高它，因为这是真的 - Solr 中的架构更改一直在 PITA 中以与其他数据存储保持同步。
Solr 有一个特性，支持 schema 或 no-schema！

【解决方案10】：

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

通过这种混合方法，您可以真正实现两全其美的功能，例如全文搜索和快速读取以及可靠的数据存储，同时还具有极快的写入速度。

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

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

【讨论】：

如果我理解正确的话，你之所以使用MongoDB（除了Solr），是因为MongoDB的插入+读取速度更快？您是否还指出 MongoDB 具有更可靠的数据存储？（或者你指的是 Solr？）——你最初是从什么开始的？只有 MongoDB，只有 Solr，还是同时使用 Mongo + Solr？