想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.
关闭去年。
随着基于文档数据库的 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，但反之则不行。格兰特英格 Solr 的 post sums it up here.
MongoDB 等似乎服务于不需要搜索和/或分面的目的。对于摆脱 RDBMS 世界的程序员来说，这似乎是一个更简单且可以说更容易的过渡。除非你习惯了，否则 Lucene 和 Solr 的学习曲线会更陡峭。
使用 Lucene/Solr 作为数据存储的例子并不多，但 Guardian 取得了一些进展，并在一篇出色的 slide-deck 中总结了这一点。 ，但他们也没有完全加入 Solr 的潮流并“调查”将 Solr 与 CouchDB 结合起来。
最后，我将提供我们的经验，遗憾的是不能透露太多关于商业案例的信息。我们在几 TB 的数据规模上工作，这是一个近乎实时的应用程序。在研究了各种组合之后，决定坚持使用 Solr。到目前为止没有后悔(6 个月及以后)，也没有理由改用其他的。
总结:如果您没有搜索要求，Mongo 提供了一种简单而强大的方法。但是，如果搜索是您产品的关键，那么您最好还是坚持使用一种技术(Solr/Lucene)并对其进行优化 - 减少事件部件。
我的 2 美分，希望对您有所帮助。
关于mongodb - NoSQL (MongoDB) vs Lucene (或 Solr) 作为你的数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3215029/
相关文章：
mongodb - 如何在 MongoDB shell 中打印出 20 多个项目(文档)？
node.js - Mongoose 中的 "__v"字段是什么
sql - MongoDB 在 v4 之前不符合 ACID 的真正含义是什么？
javascript - cursor.forEach() 中的 "continue"
mongodb - 如何在 mongo 控制台中通过 ObjectId 搜索对象？
node.js - 如何在 Node.js Web 应用程序中管理 MongoDB 连接？
javascript - 如何使用 Node.js Mongoose 删除文档？
mongodb - 如何从 MongoDB 文档中完全删除字段？