爲什麼日誌存儲在平面文件中，而不是數據庫（SQL）？

爲什麼Web服務器和其他技術使用平面文件進行日誌記錄，而不是某種數據庫，無論是通過SQL還是某種KVS或「NoSQL」解決方案？爲什麼日誌存儲在平面文件中，而不是數據庫（SQL）？

使用平面文件有什麼好處（速度，延遲，寫入時間等），還是我只是缺少什麼？

來源

2011-02-25 Mike Trpcic

您無法保證在服務器上擁有數據庫。

如果數據庫是問題的一部分，您如何看待日誌。

如果數據庫不是問題的一部分，使用任何舊的文本編輯器查看日誌仍然更簡單。

爲什麼使用複雜的簡單作品。當首次開發Apache（等）時，開源（免費，無處不在）的數據庫不可用。

等等，等等

來源

2011-02-25 03:34:19 mickeyf

如果我可以附和：數據庫設計用於密集的讀/寫操作，而日誌基本上是一個永遠只寫，只讀應急的努力。由於這種使用不匹配，部署事務性RDBMS來存儲日誌通常是巨大的矯枉過正。 – 2011-02-25 06:51:17

首先，它很容易寫。
這很簡單...寫入文件是出錯的最不可能的事情之一。
由於簡單，它很快。這既適用於磁盤寫入，也適用於執行操作的CPU時間。

很多這也是一個遺產。雖然數據庫服務器和具有100G存儲容量（如果不是TB）和內存容量的數據庫的機器數量充沛，但如果不是常態，大多數經驗豐富的服務器都會從系統資源被低得多的負載充分利用的時間開始歡呼。

但大多數情況下這很容易。爲什麼依靠SQLite（作爲簡單的嵌入式SQL服務），確保您的許可證是兼容的，您維護了適當的版本，並且沒有潛在的錯誤或安全問題......爲了除了順序插入以外什麼也不做？

KISS。日誌分析工具不應該是日誌寫入的一部分。

來源

2011-02-25 03:39:08

有一個永恆的原則，說移動部件越少，出現問題的點越少。您最小化依賴關係，從而最大限度地減少可能出現錯誤的地方。它的速度也很快，因爲它很簡單，而且一個高負載的服務器不會讓日誌陷入停滯狀態。有趣的是，查理斯·林德伯格的單引擎飛機在大西洋上不間斷地飛行時也是如此，當時還有許多其他更大的飛機在他面前失敗。保持簡單:)

來源

2011-02-25 03:44:54 chesles

雖然其餘的答案在這裏是真實的（KISS principal等），但我看到一個項目，日誌填滿了服務器的硬盤驅動器，他們必須構建自動化來清理日誌。要解決這個問題，可能需要實現滾動備份/最大日誌大小功能，或者執行計劃任務（cron）來移動或刪除日誌。

沒有免費的午餐。

來源

2011-02-25 04:08:30

這就是我們在工作中停止使用數據庫日誌的原因。

try 
{ 
    tx.Begin(); 
    // Exception here! 
    tx.Commit(); 
} 
catch(Exception ex) 
{ 
    LogToDB(ex); 
    tx.Rollback(); 
}

每當我們在數據庫連接中發生異常時，日誌記錄就被回滾。

（我想我不應該總是說......正當回滾日誌後發生儘管如此，這是一段時間的混亂！）

來源

2012-01-31 21:34:24

爲什麼日誌存儲在平面文件中，而不是數據庫（SQL）？

回答

相關問題