DocumentStores（单独）是否适合搜索文档？答案

【问题标题】：Are DocumentStores (alone) good for searching documents?DocumentStores（单独）是否适合搜索文档？
【发布时间】：2012-07-28 03:01:30
【问题描述】：

我目前正在考虑如何最好地将网络爬取结果存储在数据库中。在另一个问题中，建议将面向文档的数据库用于网络爬虫项目：Database for web crawler in python?

现在我想知道 map/reduce 是否是这种分类和价值生成的正确方法。至少它似乎能够做这样的事情（map 仅用于分类，如年份或作者，map/reduce 用于计算数值，目前我想不出一个例子）。

但是，map-reduce / DocumentStores 是否也能够为我提供给定单词的正确文档？在关系数据库中，我必须在某些表上使用 JOIN，然后获取包含这些单词的文档：

SELECT * FROM docs d 
JOIN doc_words dw ON dw.doc_id = d.id 
JOIN words w ON dw.word_id = w.id 
WHERE w.word = 'foo'

我猜 DocumentStores 不能进行这样的操作，因为它们不支持全文索引并且不打算有很多引用/关系。

混合多个系统是不是更好的选择？例如。一个用于按单词搜索，一个用于按不同值（如果存在）搜索（如出版年份、作者……）？我认为 DocumentStores 对于存储元数据并不是那么糟糕，因为有时有特定的值，有时没有（如果需要，只要一个服务器的文档太多，DocumentStores 很容易在多个服务器上使用）。然而，我不确定实现搜索文档集合（包括网页、pdf、图像，它们总是具有不同的元数据，但通常还需要全文索引）的最佳方法是什么。

提出一个明确的问题：我应该将另一个数据库系统与 DocumentStores 一起使用，还是单独使用 DocumentStores（如何快速搜索单词？）还是单独使用另一个数据库系统？

PS：另一个例子是网页之间的链接，也不能很好地保存在 DocumentStores 中。不过，OrientDB 可能会解决这个问题，因为它似乎结合了图形数据库和面向文档的数据库。

【问题讨论】：

标签： database nosql web-crawler document-oriented-db

【解决方案1】：

结帐RavenDB。它是一个带有 Map/Reduce 查询的文档数据库，底层使用 Lucene，因此在 Map/Reduce 查询中也完全支持全文搜索。

还支持自定义 Lucene 分析器，因此还有很大的空间进行进一步的全文扩展。

Includes 和 Live Projections 等其他功能可能会为您提供其他所有功能，但缺少一个简单的 Map/Reduce。

【讨论】：

听起来很酷，不幸的是我只使用Linux（我不想用单声道运行它，因为我不确定它是否足够稳定等等......）。不知道只有 windows 的开源软件存在 :D 也许其他人会对此感到高兴。
正在努力确保对 Mono 的全面支持。在这一点上，它运行顺利，没有已知问题，但永远不能太小心:)

【解决方案2】：

请参阅 MarkLogic - 专为搜索文档而设计。 http://developer.marklogic.com/products/marklogic-server/which-nosql

【讨论】：