我有一个 MySQL 数据库，每秒插入 2000 个新行。这些行表示传感器在该特定时刻的值。
计划是使用 Chart.js 将这些数据转化为图形表示形式。当然，显示每个数据点是没有意义的，而且查询速度慢得离谱。
我的问题是，在这种情况下采取什么适当的路线？这是我的想法:
假设所需的数据分辨率是当天1 分钟间隔、15 分钟间隔、30 分钟间隔、1 小时间隔和全天的值的运行平均值。
- 创建一个 cron 作业脚本来解析两个时间段之间的可用值。将上述间隔存储在与原始值分开的数据库中的5 个各自的表中。
- 在 cron-job 脚本执行平均作业以确定间隔值时，从生产数据库中清除/存档原始值。
通过这种方法，事情可以保持整洁，并且可以很容易地以图形表示方式显示数据。这是我发现问题的地方:
- 如果我们要过滤图表以查看上个月的每日值，则必须检查 31 个表格以获取要显示的值。
- 随着分辨率的减小和周期的延长，问题呈指数级增长。
我可能是在兔子洞里陷得太深了。我会采纳您可能读到的任何好的读物。
最佳答案
对您的设置的一些建议
数据库设置
使用临时(登台)表收集新记录。最好你应该
范围分区 此表包含使用插入时间戳的最佳聚合间隔(例如分钟)。插入时间戳与测量时间戳(称为传感器时间戳)相反，对于区分非常重要 - 请参阅下面的讨论。使用相同的分区架构定义详细信息表，并使用传感器时间戳作为分区键。
根据需要定义聚合表，并根据传感器时间戳进行分区。仔细检查您需要什么级别。这不是 由请求的报告定义，但通过性能您可以查询数据。
例如30 分钟级别似乎有些过大，因为您可以从15 分钟级别有效地查询它。
处理
每分钟运行一次的后台作业处理声明表的一个分区(即一分钟增量)和
插入详细信息表中的所有行
使用从阶段表计算出的增量更新所有聚合表
这里你应该小心。计数、求和和平均值没有问题，但对于不同计数，您必须使用 HyperLogLog 的某种实现这只会产生估计数据。
您还应该检查是否必须处理延迟的数据条目，即您的增量中还包含具有旧传感器时间戳的数据。 您必须刷新与这些时间戳相关的所有聚合间隔。
Example: In your process data inserted at 10:01 the oldest sensor entry is 09:59, so you must refresh three minutes aggregation (09:59, 10:00 and 10:01) and two 15 minutes aggregations (9:45 and 10:00) etc.
每日收盘
为了解决delta处理可能出现的不准确问题(请参阅上面的 HyperLogLog，但包括所有其他类型)，您可以定期 丢弃聚合的最后一部分并从详细表中准确地重新计算它们。
这将消除“错误累积”的问题 - 这个概念也称为 Lambda Architecture .
保留历史
所有表都定义了滚动窗口策略 - 即数据将保留多长时间。
聚合表由报告要求控制。
详细信息表仅用作备份，如果出现问题，您恢复聚合数据的可能性(有限)。 因此，只要经济上有意义，就设置它。
仅使用DROP PARTITION(不使用删除)删除旧数据。
您可以对声明表应用循环分区，即仅使用时间作为分区键，而不使用日期部分。 这将简化分区维护 - 您将使用 TRUNCATE PARTITION 来删除数据。
报告
您的聚合将每分钟完成一次，这意味着最低聚合始终是一致的。 相反，最后 15 分钟的聚合通常不完整，仅包含几分钟的数据。
您应该设计一些规范化概念来处理这个问题。看到成功事件的数量在最后一刻钟内大幅下降，这让人不太高兴。
祝你好运!
关于mysql - 处理大数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59699362/