需要一个存档日志和实时搜索功能的解决方案

Question

我一直在考虑以下选项。

1. senseidb [http://www.senseidb.com]这需要一个固定的架构，也需要数据网关。因此没有简单的方法来推送数据但提供数据流。我的数据未被删除，并且所有日志中的公共属性非常少

2. riak [http://wiki.basho.com/Riak-Search.html]

3. vertica - 成本因素？

4. Hbase（+ Hadoop生态系统+ lucene） - 这里的主要缺点是在单机上这没有多大意义，我不确定围绕此构建的自由文本搜索功能

主要要求是 1.它必须承受数千个传入的归档请求，同时构建实时索引，允许最终用户进行自由文本搜索

1. 存储（日志存档+索引）必须是最优的

Answer 1

有许多专门的日志存储和索引，我不知道我必须将日志记录到正常的数据存储中。

如果你有很多钱，那就很难击败Splunk。

如果您更喜欢开源选项，请查看ServerFault discussion。 logstash + ElasticSearch似乎是一个非常强大的选择，并且应该像日志一样增长。

Answer 2

您是否考虑过这些实施方案。将Lucene和Hadoop集成在一起可能会有所帮助。

http://www.cloudera.com/blog/2011/09/hadoop-for-archiving-email/ http://www.cloudera.com/blog/2012/01/hadoop-for-archiving-email-part-2/

因此，您的用例可以使用日志文件和索引参数来代替电子邮件。

Answer 3

对于2-3 TB的数据听起来像中间的＆＃34;＆＃34;案件。如果是所有数据，我不建议进入BigData / NoSQL冒险。
我认为具有全文搜索功能的RDBMS应该在良好的硬件上运行。我建议按时间进行一些积极的分区，以便能够处理2-3 TB的数据。如果没有分区，那就太麻烦了。同时 - 如果您的数据将按天划分，我认为数据大小适合MySQL。
考虑到以下注释，数据大小约为10-15TB，并考虑到某些复制的需要将乘以此数字x2-x3。我们还应该考虑从数据大小估计数十个百分比的索引大小。可能有效的单节点解决方案可能比集群更昂贵，主要是因为许可成本。
据我所知，现有的Hadoop / NoSQL解决方案无法满足您的开箱即用需求，主要是因为要编制索引的文档数量。在外壳中 - 每个日志都是一个文档。 （http://blog.mgm-tp.com/2010/06/hadoop-log-management-part3/）
所以我认为解决方案将在一段时间内聚合日志，并将其作为一个文档进行威胁。
对于这些日志包的存储，HDFS或Swift可能是一个很好的解决方案。