有效地存儲和檢索報告的大量彙總數據

Question

問題如下。我們實時收集一些數據，比方說每秒100個條目。我們希望有實時報告。報告應以小時爲單位提供數據。我們所要做的只是創建一些輸入數據，並有一些智能索引，這樣我們就可以輕鬆地爲像「給我value2 for featureA = x，featureB = y，2012-01-01 09:00 - 10:00「

爲了避免太多的I/O操作，我們在內存中彙總數據（這意味着我們總結），然後將它們刷新到數據庫。讓我們說每10秒左右發生一次，這對我們的實時報告來說是可以接受的延遲。因此基本上，在SQL方面，我們最終得到了20個（或更多）像這樣的表（好吧，我們可以通過組合總和來減少它們，但它不會產生很大的差別）：

1. 時間，FeatureA，FeatureB，FeatureC，值1，值，valu3
2. 時間，FeatureA，精選，值4，值5
3. 時間，FeatureC，FeatureE，value6，value7
4. 等

（我沒有說解決方案必須是SQL，我只提供這個來解釋手頭的問題。）時間列是時間戳（具有小時精度），特徵列是系統實體的一些ID，並且值是整數值（計數）。

所以現在問題就出現了。由於數據的本質，即使我們將它們聚合在一起，仍然有太多的插入到這些聚集表中。這是因爲有些數據是稀疏的，這意味着對於每100個條目，我們有一些聚合表有50個條目。我知道我們可以通過升級硬件來實現，但我覺得我們可以通過更智能的存儲機制來做得更好。例如，我們可以使用SQL數據庫，但我們不需要其大部分功能（事務，連接等）。

因此，在這種情況下，我的問題如下。你們如何處理高流量流量的實時報告？谷歌以某種方式爲網頁分析做這件事，畢竟它是可能的。這裏有任何祕密武器？我們願意接受任何解決方案 - 無論是Hadoop & Co，NoSQL，集羣還是其他任何解決方案。

Answer 1

除了分解收集和報告/分析的存儲需求之外，我們曾經做過的事情之一是查看值經常發生重大更改的頻率以及如何使用數據。

不知道你的數據是什麼樣的，但報告和分析通常在尋找重要的模式。在寬容外，反之亦然，特別是振盪。 現在儘管收集「無限量」的數據量可能是值得稱道的，但如果您想分析它，當您遇到有限的實施限制時，必須做出選擇。

我在製造環境中做過這樣的事情。我們有兩個層次的分析。一個用於控制粒度達到我們所能承擔的最高水平的控制。然後，隨着數據在過去得到進一步發展，我們將其彙總進行彙報。

我遇到了你看起來已經超過幾次的問題，雖然數據丟失令人惋惜，但抱怨它的成本要多得多。

，所以我不會看這個問題從根本看法技術角度，而是從實際的業務之一。從企業相信自己能負擔得起多少開始，並看看你能給它多少錢。