hey*_*ol1 3 storage table sql-server-2016
我正在开发一种软件解决方案，需要将源自许多 PLC（可编程逻辑控制器，用于控制传送带和机器人等工业机器）的原始数据点存储到 SQL Server 数据库中。我主要关心的是如何正确存储大量原始数字数据。
每个数据点具有以下属性：
我从中收集数据的每个 PLC 可能有多达 500 个数据点，我想计划支持数千个 PLC。这意味着，我每年至少有 15,768,000,000,000 个数据点（每年 31,536,000 个点 * 500 个点 * 1000 个 plcs）。我目前为每种数据类型（bool、int、float、string）都有一个表。为了减少记录和存储的数量，我为每条记录存储了 4 个数据点 [ID、DateTime、DataGroupID、Value1、Value2、Value3、Value4]。
我实现了这个，它运行良好（使用我最大的表进行约 7200 万条记录的快速查询），尽管它不是很灵活（更改数据类型需要在表之间移动数据，重新分组数据需要表/列更改，等等。）
因此，我想提高灵活性的想法是保留数据类型特定的表，而只是将每个数据点存储为自己的记录。bigint 的最大大小（记录 ID 的数据类型）的一些简短数学表明我有很多可用的 ID。尽管存储要求和查询性能仍然是一个问题。我应该担心使用这种方法的任何事情吗？有更好的选择吗？
我担心的根源是我根本没有体验过巨大的数据库/表，所以虽然我知道几百万条记录很小，但我仍然不知道一个过顶的表会是什么样子。此外，数据的存储是我的软件的基础，因此更新需要大量工作才能实现。
让我们从基础开始：
您是否应该每年在关系数据库中存储 16 万亿个原始数据点？可能不是。想一想之后您将用它做什么，以及这些查询会是什么样子。关系数据库非常适合与其他表有关系并且需要频繁插入/更新/删除或由常见报告工具读取的数据，但它不太适合这里。
如果您不在 RDBMS 中执行此操作，那么您在何处执行此操作？ 认识时间序列数据库，这是专为此目的而设计的。示例包括Graphite和InfluxDB。
如果必须这样做，您应该注意什么？任何类型的维护都将极具挑战性 - 索引重建、统计更新、备份、CHECKDB 等。相反，请考虑将数据拆分为更小的卷的动态分片设计。例如，在数据仓库领域，大表通常按日期范围（2017Q3、2017Q2、2017Q1 等）进行拆分，因此如果您需要为新传入的数据添加新列，您只需修改当前表。出于报告目的，您可以将所有表合并到一个视图中 - 但请注意，对万亿行表的任何类型的临时查询都可能具有挑战性。（如果有人想要订购并且没有支持索引，那么天堂会帮助您 - 再见，tempdb 驱动器空间。）