SQL Server 时间序列建模海量数据收集答案

【问题标题】：SQL Server Time Series Modelling Huge datacollectionSQL Server 时间序列建模海量数据收集
【发布时间】：2015-09-04 09:37:33
【问题描述】：

我必须为 100-1000 台设备（至少要监控 20 个参数）实施数据收集以重放电气参数。这相当于大量的数据收集，因为它将基于非常类似于时间序列。我必须支持 1 秒的分辨率。考虑 1 年 [365*24*60*60*1000]=31536000000 行。我做了我的研究，但仍然有几个问题

由于数据量很大，最好将数据保存在同一个表中，还是应该将表分开。 [数据结构相同]或者我应该依赖索引？
数据插入也会非常频繁，但我仍然可以批量处理它们最好的方法是什么？是否直接写入同一个数据库还是使用临时数据库进行写入和同步？
SQL Server 是否有针对选择、更新和插入进行时间序列优化的特定架构建议？任何开箱即用对日平均值有帮助吗？或特定的常见聚合函数我可以写我自己的，但只是想知道这是一个标准问题，所以他们可能有一些开箱即用的最佳实践和示例。**

如果有任何帮助，请告诉我，在此先感谢

【问题讨论】：

您是使用 SQL Server 还是 MySQL 作为后端服务器？
我更喜欢 SQL 但我也可以根据任何反馈考虑使用 mysql

标签： sql .net sql-server time-series

【解决方案1】：

1) 您可能想探索分区的使用。这将允许非常有效的插入（如果您正确进行分区，它是一个元操作）并且非常快（2）。您可能想要探索列存储索引，因为数据（一旦收集）将永远不会改变，并且您将拥有非常大的数据集。分区和列存储需要一个学习曲线，但它非常可行。 Internet 上有很多代码描述了 SQL Server 中日期函数的使用。

【讨论】：

OP 可能需要去那里，但我不同意这是必要的第一步。我有一些超过 40 亿的表，插入时间没有下降。如果索引不分段插入是 O(1)。
他有 410 亿行，我们不知道行有多宽。
酷，我只是认为先到这里是过早的优化。测试常规表是否需要 410 亿以及插入是否降级很容易。

【解决方案2】：

这是一个很大的数字，但我会从一张桌子开始，看看它是否能撑得住。如果将其拆分为多个表，它仍然是相同数量的数据。

您是否需要跨设备搜索？如果没有，您可以为每个设备创建一个单独的表。

我有一些审计表不是那么大但仍然很大并且没有任何问题。如果数据按时间顺序加载，则将日期设置为聚簇索引的第一（或唯一）列。

如果 PK 是日期，则设备很好，但如果您可以在同一秒内获得两个读数，您就无法做到这一点。如果这是 PK，那么您是否可以按该排序加载数据。即使您必须每秒进行一次加载。您只是无法承受将那么大的表碎片化。如果您无法按排序加载，则采用 50% 的填充因子。

如果您不能拥有 PK，那么只需使用日期作为聚集索引而不是 PK，并在设备上放置一个非聚集索引。

我有一些 3,000,000,000 的表，我可以在没有其他索引的情况下通过 PK 加载。从第 1 行到第 3,000,000,000 行的插入没有可测量的降级。

【讨论】：