关闭。这个问题是基于意见的。它目前不接受答案。想改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引用来回答它。去年关闭。改进这个问题
随着基于基于文档的数据库的 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 并存储它。完毕。好，易于。
这是一个很好的问题，我已经思考了很多。我将总结我的经验教训：
在几乎所有情况下，您都可以轻松地使用 Lucene/Solr 代替 MongoDB，但反之则不然。 Grant Ingersoll 的帖子在这里进行了总结。 MongoDB 等似乎服务于不需要搜索和/或分面的目的。对于摆脱 RDBMS 世界的程序员来说，这似乎是一个更简单且可以说更容易的过渡。除非人们习惯了 Lucene 和 Solr 的学习曲线更陡峭。使用 Lucene/Solr 作为数据存储的例子并不多，但 Guardian 已经取得了一些进展，并在一个出色的幻灯片中总结了这一点，但他们也没有完全加入 Solr 的潮流并“调查”结合 Solr与 CouchDB。最后，我将提供我们的经验，遗憾的是不能透露太多关于商业案例的信息。我们在几 TB 的数据规模上工作，这是一个近乎实时的应用程序。在研究了各种组合之后，决定坚持使用 Solr。到目前为止没有遗憾（6 个月和计数），并且没有理由切换到其他人。
摘要：如果您没有搜索要求，Mongo 提供了一种简单而强大的方法。但是，如果搜索是您产品的关键，那么您最好坚持使用一种技术（Solr/Lucene）并优化它——减少活动部件。
我的 2 美分，希望对您有所帮助。
您不能部分更新 solr 中的文档。您必须重新发布所有字段才能更新文档。
性能很重要。如果您不提交，您对 solr 的更改不会生效，如果您每次都提交，性能会受到影响。
solr 中没有交易。
由于 solr 有这些缺点，所以有时 NoSQL 是更好的选择。
更新：Solr 4+ 开始支持提交和软提交。参考最新文档 https://lucene.apache.org/solr/guide/8_5/
我们一起使用 MongoDB 和 Solr，它们表现良好。您可以找到我的 blog post here，其中我描述了我们如何一起使用这些技术。这是一段摘录：
[...] 但是，我们观察到 Solr 的查询性能会随着索引大小的增加而降低。我们意识到最好的解决方案是同时使用 Solr 和 Mongo DB。然后，我们将 Solr 与 MongoDB 集成，将内容存储到 MongoDB 中，并使用 Solr 创建索引以进行全文搜索。我们只将每个文档的唯一 ID 存储在 Solr 索引中，并在 Solr 上搜索后从 MongoDB 中检索实际内容。从 MongoDB 获取文档比 Solr 更快，因为没有分析器、评分等。 [...]
另请注意，有些人通过将所有索引存储在 Solr 中并监视 oplog 操作并将相关更新级联到 Solr 中，将 Solr/Lucene 集成到 Mongo 中。
使用这种混合方法，您可以真正拥有两全其美的功能，例如全文搜索和快速读取以及可靠的数据存储，同时还具有超快的写入速度。
设置起来有点技术性，但是有很多 oplog tailer 可以集成到 solr 中。查看 rangepan 在本文中做了什么。
http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html
根据我对这两者的经验，Mongo 非常适合简单、直接的使用。我们遭受的主要 Mongo 缺点是意外查询的性能不佳（您无法为所有可能的过滤器/排序组合创建 mongo 索引，您不能）。
在 Lucene/Solr 盛行的地方，尤其是使用 FilterQuery 缓存，性能非常出色。
由于没有其他人提到它，让我补充一点，MongoDB 是无模式的，而 Solr 强制使用模式。因此，如果您的文档字段可能会发生变化，这就是选择 MongoDB 而不是 Solr 的原因之一。
schema.xml 中定义的模式，但它也有“动态字段”，即类型通过通配符确定的字段，因此您可以将所有匹配的字段（例如 *_i）索引为整数字段。添加文档时，您可以拥有包含 count_i、foo_i、bar_i 等字段的文档，这些字段都被理解为整数字段，而不会出现在 schema.xml 中。我会说，非常无模式。有关更多信息，请参见 youtube.com/watch?v=WYVM6Wz-XTw。
@mauricio-scheffer 提到了 Solr 4 - 对于那些对此感兴趣的人，LucidWorks 将 Solr 4 描述为“NoSQL 搜索服务器”，http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/ 上有一段视频，其中详细介绍了 NoSQL(ish) 功能。 （-ish 是因为他们的无模式版本实际上是一个动态模式。）
如果只想用key-value格式存储数据，不推荐Lucene，因为它的倒排索引会浪费太多磁盘空间。并且由于数据保存在磁盘中，它的性能比 Redis 等 NoSQL 数据库慢得多，因为 redis 将数据保存在 RAM 中。 Lucene 最大的优势是它支持很多查询，所以可以支持模糊查询。
MongoDB Atlas 很快就会有一个基于 lucene 的搜索引擎。本周的 MongoDB World 2019 会议上宣布了这一重大消息。这是鼓励更多使用其高收入 MongoDB Atlas 产品的好方法。
我希望看到它融入 MongoDB Enterprise 4.2 版，但没有消息将其引入他们的本地产品线。
更多信息：https://www.mongodb.com/atlas/full-text-search
第三方解决方案，如 mongo op-log tail 很有吸引力。假设从开发/架构的角度来看，关于解决方案是否可以紧密集成的一些想法或问题仍然存在。出于以下几个原因，我不希望看到针对这些功能的紧密集成的解决方案（有些投机性，有待澄清，并且与开发工作不同步）：
mongo 是 c++，lucene/solr 是 java 也许 lucene 可以使用一些 mongo 库，也许 mongo 可以重写一些 lucene 算法，另见：http://clucene.sourceforge.net/ http://lucy.apache.org/
也许 lucene 可以使用一些 mongo 库
也许 mongo 可以重写一些 lucene 算法，另见：http://clucene.sourceforge.net/ http://lucy.apache.org/
http://clucene.sourceforge.net/
http://lucy.apache.org/
lucene 支持各种文档格式 mongo 专注于 JSON (BSON)
mongo 专注于 JSON (BSON)
lucene 使用不可变文档单字段更新是一个问题，如果它们可用
单个字段更新是一个问题，如果它们可用
lucene 索引对于复杂的合并操作是不可变的
mongo 查询是 javascript
mongo 没有文本分析器/标记器（AFAIK）
mongo doc 的大小是有限的，这可能会与 lucene 背道而驰
mongo 聚合操作可能在 lucene 中没有位置 lucene 具有跨文档存储字段的选项，但这与 solr 以某种方式提供聚合/统计和 SQL/图形查询不同
lucene 具有跨文档存储字段的选项，但这不是一回事
solr 以某种方式提供聚合/统计和 SQL/图形查询
关注公众号
不定期副业成功案例分享
