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

2018-06-04 16:25:35

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

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

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

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

谈到MongoDB的类似数据存储和可伸缩性时，您甚至可以比较Velocity或MemCached之类的超级缓存提供程序。

MongoDB的限制让我想起使用MemCached，但是我可以使用微软的Velocity，并且对MongoDB有更多的分组和列表收集能力（我认为）。无法获得比在内存中缓存数据更快或可伸缩的内容。即使Lucene有一个内存提供者。

MongoDB（和其他）确实有一些优点，比如API的易用性。新建一个文档，创建一个ID并存储它。完成。好，易于。

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

几乎所有情况下，您都可以轻松使用Lucene / Solr来代替MongoDB，但反之亦然。格兰特英格索尔的文章总结了这里。

MongoDB等似乎用于没有搜索和/或刻面要求的目的。对于从RDBMS世界中脱离出来的程序员而言，这似乎更简单并且可以说更容易。除非用过它，否则Lucene＆Solr的学习曲线会更陡。

使用Lucene / Solr作为数据存储的例子并不多，但Guardian已经取得了一些进展，并在一个出色的幻灯片集中对此进行了总结，但他们也没有充分考虑Solr的潮流和“调查”Solr与CouchDB。

最后，我会提供我们的经验，但不幸的是不能透露更多有关商业案例。我们按几TB数据的规模开展工作，这是一个接近实时的应用程序。在调查各种组合后，决定坚持Solr。到目前为止没有遗憾（6个月和计数），并且没有理由切换到其他。

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

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

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

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

solr中没有交易。

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

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

借助这种混合方法，您可以真正拥有两全其美的功能，例如全文搜索和快速读取功能，同时具有可靠的数据存储，并具有极高的写入速度。

这是一个技术设置，但有很多oplog tailers可以集成到solr。看看这篇文章中做了什么rangespan。

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

链接地址: http://www.djcxy.com/p/15151.html