關於處理/報告大量日誌文件類型數據的數據庫建議

Question

我們有一個應用程序可以爲其創建請求的文本日誌文件。在日誌文件中非常典型的東西，它是空格分隔的（日期，時間，url，http代碼，ip，用戶代理等）。

目前，我們每天在文本日誌文件中生成大約500k條目。

我們目前正在通過sed/awk/grep的文本文件進行大量的分析。然而，由於我們想要在多天內開始報告，因此這並不是真正的規模：

例如， - 多少次這樣做IP地址打這個URL在最近5天 - 造成500秒爲特定的URL

這是很容易做到定期進口到一個MySQL數據庫和拉這種類型的數據是什麼％的請求與選擇/分組。但是，即使有幾十萬行，查詢也相對較慢。

當談到一些新的無sql dbs（Casandra，Dynamo，BigTable）時，我是n00b，但是它們中的任何一個都適合這個嗎？我正在繼續閱讀他們，但也許這個船員有一些建議。

謝謝！

Answer 1

我們在工作中遇到了類似的問題，並通過將數據轉儲到基於列的數據庫中來解決此問題。這些類型的數據庫在您描述的分析查詢方面要好得多。有幾個選項：

http://en.wikipedia.org/wiki/Column-oriented_DBMS

我們已經有很好的經驗，InfiniDB：

http://infinidb.org/

我們使用這種方法設法約加快查詢。 10倍，但不是銀彈，最終你會再次遇到同樣的問題。

您可能還想看看對數據進行分區以提高性能。

Answer 2

有幾個原因，我不一定會看馬上到NoSQL的解決方案：

• 你是一個衆所周知的模式這聽起來像它不會被改變。

• 你似乎沒有太多的反規範化潛力，因爲你幾乎得到了一個單一的平臺結構。

• 您沒有提及應用程序可伸縮性（用戶數），只是查詢的大小。

這些都是NoSQL的三大'勝利'，就我所知。

這就是說，我不是專家，我不確定它不會使讀取更快，所以它絕對值得一試！