分析仪表板策略

Question

我们目前正在开发一个 API，我们希望为客户提供一个分析仪表板，以查看他们每月/每天/每小时的呼叫指标。

我们当前认为的策略是将每个呼叫保存到客户端单独的表（例如，calls_{client_id}）中，因为历史原因，并有一个汇总表（例如，calls_summary），其中包含每个呼叫在一天中给定小时的呼叫数量。客户。

然后，每天 cron 作业将创建一个 xml 文件，其中包含每个客户端最后一天的调用摘要，仪表板将使用它们而不是数据库。因此，唯一使用数据库的分析任务将是 cron 作业。

对于基础设施，我们正在考虑 MySQL 复制和从属数据库作为分析数据库。

该策略对于真实的网络统计有用且有效吗？ 你能提出任何调整，甚至是完全不同的调整吗？

Answer 1

由于历史原因，将每个调用保存到客户端单独的表（例如calls_{client_id}）

否。除非有充分的理由，否则不要违反规范化规则。它不会提高性能，实际上可能非常有害。它肯定会使您的代码更加复杂，从而降低可靠性。

逐个周期地归档旧记录可能是值得的，但除非您知道会遇到性能问题，否则我建议您不要这样做。

无论如何，将数据预先合并到另一个表中（前提是行数减少至少 95%）。但是，除非您需要该格式的数据，否则不必费心将其转换为 XML。

至于如何预合并......要么使用基于期间的合并（例如按日期汇总），要么使用标记来记录哪些记录已经合并。

运行整合的频率越低，对性能的影响就越大。但如果运行得太频繁，就会遇到争用/锁定问题。

如果不了解数据的结构和数量，或者预算、可用性和及时性方面的限制，就很难提供最佳的解决方案。但如果是我，我可能会选择 3 层 mysqld - 一层提供事务写入功能，一层复制该数据并生成整合数据，一层提供对整合数据的读取访问（master <-> master <-> 奴隶）

Answer 2

就性能而言，为每个客户端创建单独的表不是一个好主意。经典的方法如下：

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 可能只是更新 requests_summary 表。