我们目前正在开发API,我们希望为客户提供分析仪表板,以查看每月/每天/每小时的呼叫指标。
我们认为当前的策略是出于历史原因将每个调用保存到客户端单独的表(例如,calls_ {client_id}),并且有一个汇总表(例如,calls_summary),其中包含给定小时的调用次数。每个客户的一天。
然后,每天一个cron作业将创建一个xml文件,其中包含每个客户端的最后一天调用的摘要,仪表板将使用它们而不是数据库。因此,唯一将使用数据库的分析任务将是cron作业。
对于基础设施,我们将MySQL复制和奴隶视为分析数据库。
该策略对实际网络统计有用且有效吗? 你可以提出任何调整,甚至完全不同的调整吗?
答案 0 :(得分:1)
出于历史原因,将每次调用保存到客户端单独的表(例如,calls_ {client_id})
没有。除非你有充分的理由,否则不要违反正常化的规则。它不会提高性能,实际上可能非常有害。它肯定会使您的代码更复杂,因此不太可靠。
可能值得逐个归档旧记录,但除非您知道您将遇到性能问题,否则我建议不要这样做。
通过各种方式将数据预合并到另一个表中(假设您正在减少ni行数至少95%)。但除非您需要这种格式的数据,否则不要费心将其转换为XML。
至于如何预先合并......要么使用基于期间的合并(例如按日期汇总),要么使用标记记录哪些记录已经合并。
运行整合的频率越低,对性能的影响就越大。但是经常运行它会导致争用/锁定问题。
在不了解数据的结构和数量或预算,可用性和及时性方面的限制的情况下,很难提供最佳解决方案。但如果是我,我可能会使用3个mysqld层 - 一个提供事务写入工具,一个复制此数据并生成合并数据,另一个提供对统一数据的读取访问权限(master< - > master) < - >奴隶)
答案 1 :(得分:0)
性能方面,为每个客户端创建一个单独的表是一个坏主意。对此的经典方法是:
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表。