Sql 大型集合的主键设计和分区

我目前正在为sql server设计一个数据库，需要处理大量数据

上下文如下所示：
由4680个芯片组成的子组作为唯一ID
每个芯片由66个点组成，具有通过/失败布尔值
每个点作为3个值（x、y、半径）

因此，每20分钟我需要插入一个子集，对应308'880个点，这个24/24小时7/7天，持续10年，产生80亿个点（我知道这听起来很多…）

我考虑过像这样使用复合键：
SUBSTRAT（INT-ID）
芯片（INT-FK\u-SUBSTRATID，ROWNUMBER-INT，COLNUMBER-INT）
点（INT-FK_-SUBSTRATID，CHIPROWNUMBER-INT，CHIPCOLNUMBER-INT，ROWNUMBER-INT，COLNUMBER-INT）

对于芯片和斑点，列号和行号在1-30之间迭代

我也在考虑把所有的斑点信息放到芯片表中。我真的不知道在这种情况下什么是最好的，因为我从来没有遇到过这么多的数据

我想知道如何在这些表上使用分区，数据需要有一个良好的响应时间，比如说30天，所以我计划添加一个字段InsertDate来对其进行分区

编辑：
至于数据的使用，芯片信息将在30天内用于决定是否继续生产子芯片。
现货信息将用于按需对x、y偏差进行统计分析
现场和芯片信息应根据需要检索至少10年 所有数据都需要保存，以符合FDA的要求

---

谢谢大家的建议

我将听取其他人对关键设计的主要问题的意见，但我想回答有关插入和读取性能的问题

当您需要高效地写入和读取大型数据集时，最好使用单独的专用读写数据库。我们的想法是有两种不同的模式——一种是为快速写作而优化的模式，另一种是为快速阅读而优化的模式。然后，将处理输入数据的作业放在一起，并将其移到可读的数据库/表中。取舍是您的写入数据不能立即可用（延迟取决于您喜欢如何处理写入）

---

该方法与CQR类似（但不完全相同）。要点是，拥有专门的读写组件可以让每个组件都能根据自己的角色进行高度调整。

其中一条重要信息是每20分钟为每个芯片添加一次数据（如果我理解正确的话）。任何设计都需要考虑到这样一个事实，即除非聚集索引能够在末尾添加新记录，否则可能会出现显著的碎片。如果你在索引上有大量的填充和定期维护来重建它，这可能没问题。@AndyNichols是的，你很清楚，4680芯片和308'880点每20分钟一次添加一次。