自定義統計信息的最佳做法

Question

我坐在一個需要建立統計模塊的環境中，該統計模塊可以存儲用戶相關的統計信息。

基本上，所有存儲的都是一個事件標識符，一個日期時間對象，這個事件被觸發的次數以及與之交互的對象的ID。

我以前做過類似的系統，但從來沒有任何必須存儲大量信息的東西。

我的建議是數據庫中的簡單tabel。 等。 「統計」 含有下列行

• ID（主，自動增量）
• 量（整數）
• 事件（枚舉 - （列表中單擊，查看，接觸）
• 日期時間（日期時間）
• OBJECT_ID（整數）

通常情況下，這種方法效果很好，使我能夠存儲在一個給定的TIMEF關於對象的統計數據RAME（插入一個新的日期時間每隔一小時或15分鐘，這樣的統計數據會更新每隔15分鐘），

現在，我的問題是：

• 是那裏有更好的方法或實現 和建設的更優化的方法一個自定義統計模塊。
• 由於這個新網站會收到大量的流量，我該如何解決對象id上的索引會導致更慢的更新響應時間的矛盾
• 您甚至可以實現諸如etc. analytics這樣的實時統計嗎？這完全是關於服務器的大小和處理能力嗎？或者有最佳做法。

我希望我的問題是可以理解的，我期待着在這個話題上更加明智。 此致敬意。 Jonas

Answer 1

我相信你會碰到的一個問題是你想要兩個交易和分析的世界。在小型案例中，這很好，但是當你開始擴展時，特別是500M +記錄的領域。

我會建議將兩者分開，您會生成事件並跟蹤事件本身。然後，您將運行分析查詢來獲取諸如每個對象交互的事件計數等事情。您可以定期將這些計數或其他度量標準計算彙總到報表中。

對於跟蹤事件，您可以將它們保存在事件發生表中，或者在數據庫之前執行此跟蹤，然後將定期聚合提供給數據庫。想一想使用收集代理生成事件的監控系統的世界，然後聚合層將週期性度量快照寫入分析區域（例如，CollectD到StatsD /石墨到Whisper）

免責聲明，我是一個InfiniDB架構師 不確定您使用的是哪種數據源，但是隨着您的成長和確定歷史數量等等......您可能會遇到大多數人在收集事件數據或監控數據時通常會遇到的大小問題。如果您在MySQL/MariaDB/PostegreSQL中，我建議您查看InfiniDB（開源柱狀MPP數據庫以進行分析）;它是完全開放源代碼（GPLv2），將提供您在數十億用TB查詢數據以及回答這些分析問題時所需的性能。