我失去了在：Hadoop的，HBase的，Lucene的，Carrot2，Cloudera的，蒂卡，动物园管理员，Solr的，凯塔，层叠，POI ...
当你阅读一个你经常可以确保每个人的工具将被提及。
我不希望你的每一个工具向我解释 - 千万不要。 如果你能帮助我缩小这套对我特殊的情况将是巨大的。 到目前为止，我不知道这上面的将适合，它看起来像（一如既往）有做什么做的更多，其中一个方法。
该方案是：500GB - 〜存储在Hadoop中的文件20 TB。 多种格式的文本文档：电子邮件，DOC，PDF，ODT。 关于存储在SQL数据库（发件人，收件人，日期，部门等）的文件主要来源这些文件的元数据会的ExchangeServer（电子邮件和附件），但不是唯一的。 我们搜索：用户需要能够对这些文件做复杂的全文搜索。 Basicaly他会提出一些搜索配置面板（Java桌面应用程序，Web应用程序不） - 他会设定日期范围，文档类型，发件人/接受者，关键字等 - 触发搜索，并得到所产生的文件列表（和每个文档信息为什么它包括在搜索结果中，即哪些关键字在文件中找到）。
哪些工具，我应该考虑和不呢？ 问题的关键是发展，只有最小的必要“胶水” -code这样的解决方案。 我在SQLdbs精通，但与Apache和相关技术相当不舒服。
基本工作流程是这样的：的ExchangeServer /其它来源 - >从DOC / PDF转换/ ... - >重复数据删除 - > Hadopp + SQL（元数据） - >编译/更新的指数< - 通过搜索该文档（和做快） - >本的搜索结果
谢谢！
使用Solr会是一个不错的选择。 我已经用它为你上述类似的情况。 您可以使用Solr的真正巨大的数据作为其分布式索引服务器。
但要获得关于所有的这些文件格式，你应该使用其他工具的元数据。 基本上，您的工作流程将是这个。
1）使用Hadoop集群来存储数据。
2）使用图/ redcue提取在Hadoop集群数据
3）DO文档识别（识别文档类型）
4）提取从这些文件的元数据。
5）在Solr的服务器索引元数据，存储在数据库中的信息摄取
6）Solr的服务器分布式索引服务器，因此每个摄入，你可以创建一个新片段或索引。
7）当搜索需要对所有指数法搜索。
8）Solr的支持所有复杂的搜索，所以你不必让自己的搜索引擎。
9）它也确实为传呼你为好。
我们通过使用Solr的“次级索引”到HBase的做正是这一点为我们的一些客户。 更新HBase的被发送到Solr，您可以查询反对。 通常人们用HBase的开始，然后移植搜索上。 听起来像是你知道从一开始去搜索是你想要的，所以你可能可以嵌入副索引从您的管道为食HBase的。
您可能会发现尽管这只是使用Solr的做了你所需要的一切。
另一个项目看是莉莉， http://www.lilyproject.org/lily/index.html ，它已经完成了一个分布式数据库集成Solr的工作。
另外，我不明白为什么你不希望使用浏览器这种应用。 你所描述的方位搜索到底是什么。 虽然你当然可以设置一个与服务器通信的桌面应用程序（解析JSON）并显示在厚客户端GUI的结果，所有这些工作都已经为你在浏览器中完成。 而且，Solr的还有一个免费的面搜索系统开箱：沿教程只是跟着。
使用Solr（去http://lucene.apache.org/solr ）是一个很好的解决方案，但准备要处理一些非显而易见的事情。 首先是正确规划索引。 数据的数TB几乎一定会需要对Solr的多个碎片的合理性能的任何级别，你将负责管理这些自己。 它提供分布式搜索（做查询过多个碎片），但这只是成功的一半。
ElasticSearch（ http://www.elasticsearch.org/ ）是另一种流行的选择，但我没有与它有关的规模多少经验。 它使用相同的Lucene的引擎，所以我期望的搜索功能设置是相似的。
的解决方案的另一个类型是一样的东西SenseiDB - 从LinkedIn开源 - 这使得大量数据的全文搜索功能（也基于Lucene的），以及成熟的规模：
http://senseidb.com
他们的确已经做了很多的搜索工作，在那里和我随便使用的是非常有前途的。
假设所有的数据已经在Hadoop中，您可以编写一个拉一个一致的架构友好的格式转换成SenseiDB数据一些定制的MR工作。 SenseiDB已经提供了Hadoop的MR索引，你可以看看。
唯一需要注意的是它是一个有点复杂的设置，但很多时候救你的缩放问题上 - 尤其是在索引性能和刻面的功能。 它还提供集群的支持，如果HA对你很重要-这是仍处于Alpha为Solr的（Solr的4.x的是阿尔法ATM）。
希望帮助，祝你好运！
更新：
我问是谁更精通ElasticSearch比我的朋友，它也有集群和再平衡的基础上的机器，你有碎片的＃的优势。 这是对Solr的一个明确的胜利 - 特别是如果你正在处理的数据的TB的。 唯一的缺点是在ElasticSearch文档的当前状态极不理想很多。
作为一个侧面说明，你不能说这些文件都存储在Hadoop中，它们被存储在一个分布式文件系统（最有可能HDFS既然你提到的Hadoop）。
关于搜索/索引：Lucene是用您的方案的工具。 你可以使用它的索引和搜索。 这是一个Java库。 还有一个相关的项目（称为SOLR）是它允许你通过Web服务访问索引/检索系统。 所以，你也应该看看Solr的，因为它允许不同类型的文件（Lucene的把你的肩膀上解释文档（PDF，Word等）的责任，但你，也许已经可以做到这一点）的处理
