首页 文章

NoSQL（MongoDB）与Lucene（或Solr）作为您的数据库

提问于
浏览 次
262

随着基于文档的数据库的NoSQL运动的增长，我最近看了MongoDB . 我注意到与如何将项目视为“文档”有惊人的相似之处，就像Lucene（和Solr的用户）一样 .

所以，问题是： Why would you want to use NoSQL (MongoDB, Cassandra, CouchDB, etc) over Lucene (or Solr) as your "database"?

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

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

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

MongoDB的限制让我想起了使用MemCached，但我可以使用Microsoft的Velocity，并且对MongoDB有更多的分组和列表收集功能（我认为） . 无法比内存中的缓存数据更快或可扩展 . 甚至Lucene都有一个内存提供商 .

MongoDB（以及其他）确实具有一些优势，例如API的易用性 . 新建文档，创建ID并存储它 . 完成 . 好，易于 .

mongodb solr lucene memcached nosql

9 回答

  • 236

    我们一起使用MongoDB和Solr，它们表现良好 . 您可以找到我的blog post here，其中我描述了我们如何一起使用这些技术 . 这是一段摘录：

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

    回复于
  • 12

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

    • 几乎可以在很多情况下使用Lucene / Solr代替MongoDB，但反之亦然 . 格兰特英格索尔的post sums it up here.

    • MongoDB等似乎用于不需要搜索和/或分面的目的 . 对于从RDBMS世界中解脱的程序员来说，这似乎是一个更简单，更容易过渡的过渡 . 除非习惯了，Lucene＆Solr的学习曲线越来越陡峭 .

    • 使用Lucene / Solr作为数据存储区的例子并不多，但Guardian已经取得了一些进展，并在一个优秀的slide-deck中总结了这一点，但它们也完全不依赖于Solr的浪潮和将Solr与CouchDB相结合的"investigating" .

    • 最后，我将提供我们的经验，遗憾的是无法透露很多关于商业案例的信息 . 我们的工作范围是几TB数据，即近实时应用程序 . 在调查各种组合后，决定坚持使用Solr . 到目前为止没有遗憾（6个月和数量），并没有理由转向其他一些 .

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

    我的2美分，希望有所帮助 .

    回复于
  • 0

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

    在这里，Lucene / Solr占据了大量时间，特别是使用FilterQuery缓存，性能非常出色 .

    回复于
  • 4

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

    • mongo是c，lucene / solr是java

    • 也许lucene可以使用一些mongo libs

    • 也许mongo可以重写一些lucene算法，另见：

    • http://clucene.sourceforge.net/

    • http://lucy.apache.org/

    • lucene支持各种doc格式

    • mongo专注于JSON（BSON）

    • lucene使用不可变文档

    • 单个字段更新是一个问题，如果它们可用

    • lucene索引是复杂的合并操作不可变的

    • mongo查询是javascript

    • mongo没有文本分析器/标记器（AFAIK）

    • mongo doc size是有限的，这可能与lucene相反

    • mongo聚合操作可能在lucene中没有位置

    • lucene有跨文档存储字段的选项，但这不是一回事

    • solr以某种方式提供聚合/统计和SQL /图形查询

    回复于
  • 34

    @ mauricio-scheffer提到Solr 4 - 对于那些对此感兴趣的人，LucidWorks将Solr 4描述为"the NoSQL Search Server"并且在http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/有一个视频，他们详细介绍了NoSQL（ish）功能 . （-ish是因为他们的无模式版本实际上是一个动态模式 . ）

    回复于
  • 1

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

    而且性能很重要 . 如果您不提交，则您对solr的更改不会生效，如果你每次都承诺，性能会受到影响 .

    solr中没有交易 .

    由于solr有这些缺点，有时候nosql是更好的选择 .

    回复于
  • 22

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

    使用这种混合方法，您可以真正拥有两全其美的功能，例如全文搜索和快速读取，以及可靠的数据存储，也可以具有超快的写入速度 .

    设置有点技术性，但有很多可以集成到solr中的oplog零售商 . 看看本文中的范围是什么 .

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

    回复于
  • 24

    由于没有其他人提及它，让我补充一点，MongoDB是无模式的，而Solr强制执行模式 . 因此，如果文档的字段可能会发生变化，那么选择MongoDB而不是Solr的原因就在于此 .

    回复于
  • 12

    如果您只想使用键值格式存储数据，则不建议使用Lucene，因为其反向索引会浪费太多磁盘空间 . 由于磁盘中的数据保存，其性能比Nois数据库（例如redis）慢得多，因为redis将数据保存在RAM中 . Lucene的最大优势是它支持大量查询，因此可以支持模糊查询 .

    回复于

相关问题