NoSQL(MongoDB)与Lucene(或Solr)作为您的数据库

随着基于文档的数据库的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并存储它.完成.好,易于.

1> Mikos..：

---

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

在几乎所有情况下,您都可以轻松地使用Lucene/Solr代替MongoDB,但反之亦然.Grant Ingersoll的帖子总结了这里.

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

使用Lucene/Solr作为数据存储区的例子并不多,但Guardian已经取得了一些进展,并在一个优秀的幻灯片中总结了这一点,但他们也完全不依赖于Solr的浪潮和"调查"结合Solr与CouchDB.

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

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

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

---

Solr没有map reduce功能.因此,报告,统计,分数计算等是不可能的!仅当您有/可以将数据作为文本数据威胁时才使用Solr

---

Solr没有内置map-reduce,但您可以与Hadoop结合使用.http://architects.dzone.com/articles/solr-hadoop-big-data-love

---

Map-reduce no,但它确实能够跨多个solr服务器并行运行查询并聚合这些结果.因此虽然它没有通用的map-reduce,但它已经用map-reduce编写了你要编写的内容,这是并行搜索查询.

---

从solr6开始，它支持带有并行表达式的map reduce功能

2> Peter Long..：

---

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

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

solr中没有交易.

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

---

这个答案变得不正确.Solr 4+支持部分更新,软提交/近实时消除了"旧式"Solr提交的大部分问题.

---

MongoDB也没有事务.

3> Parvin Gasim..：

---

我们一起使用MongoDB和Solr,它们表现良好.你可以在这里找到我的博客文章,其中我描述了我们如何一起使用这些技术.这是一段摘录:

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

---

好博客文章.是的,这正是我过去使用旧版SQL和MySql数据存储区(在Lucene中存储ID,并从数据存储中检索复杂类型)的方法.从技术上讲,这个问题是探讨两者之间的差异 - 而不是如何使用"两全其美".+1以这种方式使用它,因为它确实是使用大量数据的唯一真正方式.

4> 小智..：

---

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

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

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

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

5> mjalajel..：

---

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

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

6> Aquarelle..：

---

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

---

恕我直言,这不是真的.Solr确实有`schema.xml`中定义的模式,但它也有'动态字段',即字段的类型是通过通配符确定的,所以你可以将所有字段匹配,比如,`*_i`索引为整数字段.在添加文档时,您可以使文件具有"count_i","foo_i","bar_i"等字段,这些字段都被理解为整数字段,而不会出现在`schema.xml`中.我会说,相当无架构.有关详细信息,请参阅http://www.youtube.com/watch?v=WYVM6Wz-XTw.

---

Solr有一个支持模式或无模式的功能!

7> 小智..：

---

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