我们正在设计一个用于临时分析的表格，该表格将捕获随时间推移收到的 claim 的无数值字段。表结构本质上是(伪代码):
table_huge (
claim_key int not null,
valuation_date_key int not null,
value_1 some_number_type,
value_2 some_number_type,
[etc...],
constraint pk_huge primary key (claim_key, valuation_date_key)
);
所有值字段均为数字。要求是: 该表应包含至少 12 年(希望更多)的已受理 claim 。每项 claim 都应在 claim 开始日期和当前日期之间的每个月末有一个估价日期。典型的 claim 起始量范围为每年 50,000 到 100,000。
将所有这些加起来，我预计一个表的行数约为 1 亿，并且根据业务需求，多年来可能会增长到 5 亿。该表将每个月重建。消费者只会选择。除了每月刷新之外，不会发生任何更新、插入或删除。
我是从业务(消费者)方面出发的，但我有兴趣在降低 IT 成本的同时保留此表的分析值(value)。我们并不是非常关心表的快速返回，但偶尔需要对其进行几十次查询并在一三天内获得所有结果。
为了便于讨论，让我们假设技术栈处于现代硬件的第 80 个百分位数，我不知道。
我的问题是:
- 考虑到对大容量表的查询频率较低，索引的成本 yield 比是否会变得过高？
- SO 社区是否有超过 100M 行表的经验并且可以 提供有关如何管理的提示？
- 我应该将数据库技术问题留给 IT 来解决还是应该 认真考虑限制业务需求(为什么？)？
我知道这些问题有点软，我希望读者理解这不是我可以在构建之前测试的命题。
如果需要任何说明，请告诉我。感谢阅读!
最佳答案
首先:如果将技术问题留给 IT 部门，则希望它“能够正常工作”- 特别是如果您的预算允许“80% 当前”的硬件水平。
我确实有过在入门级和过时的硬件上处理 MySQL 中超过 2 亿行的经验，我总是感到非常惊讶。
一些提示:
在每月刷新时，加载没有非主索引的表，然后创建它们。搜索甜蜜点，并行创建多少个索引最有效。在日期少得多(大约 10M)的项目中，与天真的“创建表，然后加载数据”方法相比，这种加载时间减少了 70%
尝试掌握并发查询的数量和复杂性:这会影响您的硬件决策(较少的并发 = 较少的 IO，更多的 CPU)
假设您有 20 个 64 位的数字字段，乘以 200M 行:如果我可以正确计算，这就是 32GB 的有效负载。用便宜的磁盘换取 64G 内存，永远不会有 IO 瓶颈。
确保将表空间设置为只读
关于database - 100M行表的性能(Oracle 11g)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10730261/