存儲很多日誌文件

Question

我有一個系統，通過http（> 10k生產者，每天10個日誌，每行〜100行）接收來自不同地方的日誌文件。

我想存儲他們能夠計算雜項。統計他們每晚，出口他們（按到貨日期或第一行內容排序）...

我的問題是：什麼是最好的方式來存儲他們？

• 純文本文件（適當的鎖），每個上傳的文件一個文件，每天一個目錄/生產
• 純文本文件，每天一個（大）文件對所有生產商（這裏的問題將是索引和鎖定）
• 數據庫表中的文本（MySQL是首選內部原因）（PB與DB淨化爲刪除可能會很長！）
• 數據庫表，每行文本一個記錄與分片
• 數據庫（每天一張桌子），允許簡單的數據清除。 （這是分區，但我有權訪問（即內部支持）的MySQL版本不支持它）
• 基於文檔的數據庫àla couchdb或mongodb（問題可能與索引/成熟度/攝入速度有關）

有什麼建議嗎？

Answer 1

我會選擇第一個解決方案。

我不明白你爲什麼需要數據庫。似乎所有你需要的是掃描數據。將日誌保持在最「原始」狀態，然後對其進行處理，然後每天創建一個tarball。

聚合的唯一原因是減少文件數量。在某些文件系統上，如果將多於N個文件放入目錄中，性能會迅速下降。檢查你的文件系統，如果是這種情況，請組織一個簡單的2級層次結構，比如說，使用生產者ID的前2位數字作爲第一級目錄名稱。

Answer 2

我會每次上傳一個文件，並按照您的建議寫入一個目錄/日。在一天結束時，對文件運行處理，然後tar.bz2目錄。

tarball仍然可以搜索，並且可能會很小，因爲日誌通常可以很好地壓縮。

對於總體數據，您正在討論的是每天未壓縮的1GB [已糾正的10MB]。這可能會壓縮到100MB或更少。我用bzip2在日誌文件上看到了200倍的壓縮率。您可以輕鬆將壓縮數據存儲在文件系統上多年，無需擔心。對於額外的處理，你可以編寫腳本來搜索壓縮的tarball並生成更多的統計信息。

Answer 3

根據我的經驗，如果我們談論數據庫解決方案，單個大型表執行速度比幾個鏈接錶快得多。特別是在寫入和刪除操作上。例如，將一個表拆分爲三個鏈接表會使性能下降3-5倍。這很粗糙，當然這取決於細節，但通常這是風險。數據量變得非常大時，情況會變得更糟。國際海事組織（IMO）最好的方式來存儲日誌數據不是平面文本，而是採用結構化的形式，以便日後可以進行有效的查詢和格式化。管理日誌文件可能會很痛苦，特別是當它們有很多並且來自許多來源和位置時。查看我們的solution，IMO它可以爲您節省大量的開發時間。

Answer 4

既然您想存儲它們以便能夠計算misc。在他們的統計晚間，導出它們......你期待100,000個文件，每天（按到達時間或第一行內容的日期排序）在共10,000,000行：

我建議：

1. 使用以下格式將所有文件存儲爲常規文本文件：yyyymmdd/producerid/fileno。
2. 在一天結束時，清除數據庫，並加載當天的所有文本文件。
3. 加載文件後，很容易從數據庫獲取統計信息，並以任何需要的格式發佈。 （甚至可能是另一個「統計」數據庫）。你也可以生成圖表。
4. 爲了節省空間，您可以壓縮每日文件夾。由於它們是文本文件，它們會壓縮得很好。

因此，您只能使用數據庫來輕鬆地聚合數據。如果流程不起作用，您也可以通過執行相同的步驟重新生成報告。

Answer 5

（聲明：我對MongoDB的工作）

我覺得MongoDB是用於記錄的最佳解決方案。它的速度非常快，因爲它可能比您發送數據的速度更快。您可以對數據（例如日期或日誌級別的範圍）以及索引和字段或字段組合進行有趣的查詢。這也很好，因爲你可以隨機添加更多的字段到日誌（「哎呀，我們想要一個這樣的堆棧跟蹤字段」），它不會造成問題（就像平面文本文件一樣）。

就穩定性而言，很多人已經在生產中使用MongoDB（請參閱http://www.mongodb.org/display/DOCS/Production+Deployments）。在我們開始使用1.0之前，我們只需添加更多功能。