用於網絡訪問日誌的實時數據倉庫

我們正在考慮建立一個數據倉庫系統來加載我們的Web服務器生成的Web訪問日誌。這個想法是實時加載數據。用於網絡訪問日誌的實時數據倉庫

對於用戶，我們希望呈現數據的折線圖並使用戶能夠使用維度向下鑽取。

問題是如何平衡和設計系統，以便;

（1）中的數據可以被提取並提供給實時（< 2秒）的用戶，

（2）數據可以在每小時和每一天的基礎上被聚集，並

（2）大量的數據仍然可以被存儲在倉庫中，以及

我們當前的數據速率是大約10〜每秒訪問這使我們每天〜800K行。我使用MySQL和簡單的星型模式進行的簡單測試表明，當我們擁有超過800萬行時，我的quires開始花費超過2秒。

是否有可能從這個樣子，一個「簡單」的數據倉庫獲取實時查詢性能，仍然有它存儲了大量的數據（這將是很好能夠從未扔掉任何數據）

是否有方法將數據聚合到更高分辨率的表格中？

我有一種感覺，這不是一個真正的新問題（儘管我已經搜索了很多）。也許有人會指出這樣的數據倉庫解決方案？想到的是Splunk。

也許我在抓太多。

UPDATE

我的模式是這樣的;

尺寸：
- 客戶端（IP地址）
- 服務器
- 網址
事實;
- 時間戳（以秒計）
- 字節發送

來源

2009-12-30 jrydberg

非常非常有趣的問題。這是豪華的，我不知道，但也想了解這一點... – 2009-12-30 22:23:43

聽起來不像這將是一個問題。 MySQL 是非常快。

對於存儲日誌數據，使用MyISAM表 - 它們更快，非常適合Web服務器日誌。（我認爲InnoDB是目前新安裝的默認設置 - InnoDB的外鍵和所有其他功能對於日誌表來說不是必需的）。您也可以考慮使用merge表格 - 您可以將單個表格保持爲可管理的大小，同時仍然可以將它們全部作爲一個大表格訪問。

如果您仍然無法跟上，那麼按照該順序爲自己增加內存，更快的磁盤，RAID或更快的系統。

另外：千萬不要扔掉數據可能是一個壞主意。如果每一行的長度大約爲200字節，那麼每年至少要討論50 GB的數據，只是針對原始日誌記錄數據。如果你有索引，乘以至少兩個。再次乘以（至少）兩次備份。

如果需要，您可以保留所有內容，但在我看來，您應該考慮將原始數據存儲幾周，並將彙總數據存儲幾年。對於任何更舊的東西，只需存儲報告。（也就是說，除非法律要求遵守，否則可能不會超過3 - 4年）。

來源

2009-12-30 22:47:39 Seth

感謝您的答案。將更多地研究MySQL。這個想法是使用星型模式，其中日誌行的時間戳放入事實表中。這樣可以保持每個日誌條目數據的低，但是如何聚合這種數據呢？一個客戶很可能永遠不會再請求同一個實體，所以同一個（客戶，資產，服務器）行永遠不會在表中存在兩次。 – jrydberg 2009-12-30 22:53:28

爲了收集數據，我需要製作一個包含大量列的單個表 - 如果您做了比這更好的任何事情，則必須花費時間打開其他表並在服務器處於加載狀態時進行計算。既然你表示你已經遇到了麻煩，你可能想盡可能簡化。如果您建立了一個從服務器來進行規範化和聚合（從日誌記錄中分離報告），那麼您可以進一步減少主負載。 – Seth 2010-01-01 21:10:24

Seth上面的答案是一個非常合理的答案，我相信如果您投資於適當的知識和硬件，它有很高的成功機會。

Mozilla做了很多web服務分析。我們每小時跟蹤詳細信息，並使用商用數據庫產品Vertica。這種方法非常有效，但由於它是一種專有商業產品，因此它具有不同的相關成本。

您可能想要調查的另一項技術是MongoDB。它是一個文檔存儲數據庫，它具有一些特性，使其非常適合這種用例。也就是說，封頂集合（做MongoDB的上限集合更多信息搜索）

而且對於像跟蹤的頁面訪問量快速增值業務，打等 http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics

來源

2009-12-31 02:13:29

謝謝，我已經看過MongoDB來保存我的非關係數據。也許這對其他事情也是一個很好的匹配。對每一個事實都有一個獨特的維度，例如客戶端IP地址，這是不好的做法嗎？正如我所看到的，這使得不可能將數據聚合到較低分辨率的表格中。或者我錯過了什麼？ – jrydberg 2009-12-31 10:02:43

如果您要存儲的是客戶端IP地址，則可以將其存儲爲退化維度。由於基數很高，它仍然很難看，但它可以完成。如果可以的話，您可能希望避免將它作爲單獨維度，因爲加入兩個極高基數表對性能來說非常困難。 – 2010-01-01 21:37:06

另外，考慮分區，特別是如果您的查詢主要訪問最新的數據;你可以 - 例如 - 設置〜5.5M行的每週分區。

如果按每天和每小時進行彙總，請考慮使用日期和時間維度 - 您沒有列出它們，因此我假設您不使用它們。這個想法是不在查詢中有任何功能，如HOUR（myTimestamp）或DATE（myTimestamp）。日期維度應與事實表一樣進行分區。

有了這個，查詢優化器可以使用分區修剪，所以表的總大小不會像以前那樣影響查詢響應。

來源

2009-12-31 12:24:51

我是否正確理解你在查詢中不應該使用任何函數？他們對性能有多大影響？針對時間維度進行連接更快嗎？ – jrydberg 2009-12-31 16:31:12

是的，這是正確的 - 請記住，必須爲每一行數據評估函數。正確設置時，WHERE子句只包含維度表字段，常量和'= < ><= > = AND';如果你有一個函數，然後在維度表中預先計算。 – 2009-12-31 16:59:24

同樣爲查詢優化器使用分區修剪，只允許使用'= < ><= > = BETWEEN'。當優化器使用分區修剪時，只掃描包含WHERE數據的分區，而忽略其他分區 - 方式更快。 – 2009-12-31 17:07:10

這已經成爲一個相當普遍的數據倉庫應用程序。我已經運行了一年，每天支持2000萬到1億行，響應時間爲0.1秒（來自數據庫），超過Web服務器一秒。這甚至不在一個巨大的服務器上。

你的數據量不是太大，所以我不認爲你需要非常昂貴的硬件。但我仍然會選擇多核，64位和大量內存。

但是，您希望主要打擊彙總數據而不是詳細數據 - 特別是對於數天，數月等時間序列圖表。可以通過異步過程定期在數據庫中創建彙總數據，或者在類似情況下如果用於轉換數據的ETL過程創建聚合數據，這通常最適合。請注意，聚合通常只是您的事實表的一個分組。

正如其他人所說 - 分區是訪問詳細數據時的一個好主意。但這對於彙總數據來說不那麼重要。此外，依賴預先創建的尺寸值比功能或存儲的特效要好得多。這兩者都是典型的數據倉庫策略。

關於數據庫 - 如果是我，我會嘗試Postgresql而不是MySQL。原因主要是優化器成熟：postgresql可以更好地處理您可能運行的各種查詢。 MySQL更容易對五路連接感到困惑，當你運行一個子查詢時，自下而上等。如果這個應用程序價值很多，那麼我會考慮一個商業數據庫，比如db2，oracle，sql server。然後你會得到額外的功能，如查詢並行，針對聚合表的自動查詢重寫，額外的優化器複雜度等。

來源

2010-01-06 17:57:37 KenFar

用於網絡訪問日誌的實時數據倉庫

回答

相關問題