处理大量插入表中的大型数据集的策略答案

【问题标题】：Strategy to handle large datasets in a heavily inserted into table处理大量插入表中的大型数据集的策略
【发布时间】：2011-03-23 13:05:57
【问题描述】：

我有一个 Web 应用程序，它有一个 MySql 数据库，其中一个 device_status 表看起来像这样......

deviceid | ... various status cols ... | created

此表每天插入多次（每台设备每天 2000 多个（预计到年底将有 100 多个设备））

基本上，当设备上发生任何事情时，此表都会获得记录。

我的问题是我应该如何处理一个会很快变大的表？

当这张表有超过 1000 万行时，我是否应该放松一下，希望数据库在几个月后能正常运行？然后在它有 1 亿行的一年？这是最简单的，但看起来像一个太大的表会导致性能很差。
我是否应该在一段时间（一个月、一周）后归档旧数据，然后让 Web 应用程序查询实时表以获取最近的报告，并同时查询实时表和存档表以获取涵盖更长时间的报告跨度。
我是否应该有一个每小时和/或每天的汇总表来汇总设备的各种状态？如果我这样做，触发聚合的最佳方法是什么？克朗？数据库触发器？另外我可能还需要存档。

必须有更优雅的解决方案来处理此类数据。

【问题讨论】：

随着时间的推移，这些数据中有多少对您有价值？您需要随时准备好所有这些吗？监控几天和更长的时间间隔内使用的空间 - 它是否一致，在可用空间用完之前可以运行多长时间？
旧数据不是很有价值，但应用程序将需要每个设备在设备生命周期内每个状态组合的总计。但就报告特定设备每小时甚至每天“废话”多少次而言，粒度应该绰绰有余。 “直到可用空间用完”是什么意思？
数据库中的数据占用硬盘空间。随着写入的内容越来越多，硬盘驱动器上也没有存档 - 最终，您将耗尽空间。
Gotcha.. 应该不会太糟糕，因为该表只有 5 列，其中 3 列是小整数，但你是绝对正确的。归档必须在某个时候进行。
我看到了一个类似问题的答案，并认为我将实现与此类似的东西。 stackoverflow.com/questions/842329/…

【解决方案1】：

在跟踪广告客户在我的网站上看到的观看次数时，我遇到了类似的问题。最初，我为每个视图插入一个新行，正如您在此处预测的那样，这很快导致表格变得不合理（以至于它确实导致了性能问题，最终导致我的托管公司关闭该网站一段时间）几个小时后，我才解决了这个问题）。

我采用的解决方案类似于您的#3 解决方案。我没有在出现新视图时插入新记录，而是更新相关时间范围的现有记录。就我而言，我会记录每个广告的每日记录。为您的应用使用什么时间范围将完全取决于您的数据的具体情况和您的需求。

除非您需要专门跟踪过去一小时内的每个事件，否则您可能会过度使用它来存储它们并在以后汇总。不必费心 cron 作业来执行常规聚合，您可以简单地检查具有匹配规范的条目。如果找到，则更新匹配行的计数字段，而不是插入新行。

【讨论】：