需要解決方案來歸檔日誌並具有實時搜索功能

Question

我一直在考慮以下選項。

1. senseidb [http://www.senseidb.com]這需要一個固定的模式還數據網關。所以沒有簡單的方法來推送數據，但提供數據流。我的數據是unstuctured和對面有各種日誌

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

3. Vertica的很少共同的屬性 - 成本因素？

4. HBase的（+的Hadoop生態系統+ Lucene的） - 主要在這裏缺點是單臺機器上這不會太大意義，我不肯定的自由文本搜索功能解決此

主要要求待建的 1.它必須維持數以千計的傳入請求的備案，並在同一時間構建實時索引，這將使最終用戶做自由文本搜索

1. 存儲（日誌歸檔+指數）已經成爲最佳

Answer 1

你有沒有想過這些實現方式。爲您整合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 2

對於2-3 TB的數據聽起來像是一個「在中間」的情況。如果這是我不建議進入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可能是一個很好的解決方案。

Answer 3

有一些專門的日誌存儲和索引，我不知道我會塞滿日誌到一個正常的數據存儲必然。

如果你有很多錢，很難擊敗Splunk。

如果您更喜歡開源選項，請查看ServerFault discussion。 logstash + ElasticSearch似乎是一個非常強大的選擇，並且會隨着日誌的增長而增長。