我們目前正在開發一個API，我們希望爲我們的客戶提供一個分析儀表板，以查看每個月/每天/每小時的呼叫度量。分析儀表板戰略
我們認爲目前的策略是給每個呼叫保存到一個客戶單獨的表（如calls_了{client_id}）由於歷史原因，有一個彙總表含的呼叫數量爲給定的時間（例如calls_summary）每個客戶一天。
然後，每天一個cron作業將創建一個XML文件，其中包含每個客戶端的最後一天的調用摘要，儀表板將使用它們而不是數據庫。因此，將使用數據庫的唯一分析任務將是cron作業。
對於基礎架構，我們正在考慮MySQL複製和從站作爲分析數據庫。
該策略對真實的Web統計有用嗎？ 你可以提出任何調整，甚至完全不同的嗎？
表現明智，爲每個客戶端創建一個單獨的表是一個壞主意。對於經典的做法是如下因素：
client: id, name, address, ...
call: id, client_id, created_at, duration, ...
calls_summary: id, client_id, date_start, date_end, nb_calls
現在，如果你想獲取客戶端的所有來電，你是這樣的：
SELECT * FROM client
LEFT JOIN call ON call.client_id = client.id
WHERE client.id = 42
或者：
SELECT * FROM call where client_id = 42
我沒有看到使用xml的任何理由，您的cron可能只是更新calls_summary表。
保存歷史原因
號不要打破規範化的規則，除非你有很好的理由每次調用客戶端單獨的表（如calls_了{client_id}）。它不會提高性能，實際上可能是非常有害的。這肯定會讓你的代碼更復雜，因此不太可靠。
它可能值得存檔在歷史記錄的基礎上，但除非你知道你會遇到性能問題，我建議不要這樣做。
通過一切手段將數據預整合到另一個表（假設您獲得的行數減少至少95％）。但是除非你需要這種格式的數據，否則不要費力地把它轉換成XML。
至於您如何預先合併......或者使用基於期間的合併（例如按日期彙總）或使用標記來記錄哪些記錄已經合併。
您運行合併的頻率越低，對性能的影響就越大。但是頻繁運行它會導致爭用/鎖定問題。
不知道很多關於數據的結構和數量或預算，可用性和及時性方面的限制，很難提供最佳解決方案。但如果是我，我可能會使用3個mysqld層 - 一個提供事務性寫入功能，一個複製這些數據並生成合並數據，另一個提供對合並數據的讀訪問權限（主模塊< - >主模塊< - >奴隸）
謝謝！我們決定將數據預先整合到三個不同的表格中（每小時，每天和每月）。 Cron工作將填充每日和每月表格，並且觸發器會在每次通話時增加小時表格中的計數器。 – user991005
感謝您的回答，但是對於我的所有客戶都有一個單一的呼叫表是不會錯的？假設有1000個客戶，每個客戶有1個電話，這意味着有1b個記錄。我相信從單個表格中選擇一個客戶端的所有調用會比每個唯一表中的選擇更重，對吧？ – user991005