database - 100M行表的性能(Oracle 11g)

Question

我们正在设计一个用于临时分析的表格，该表格将捕获随时间推移收到的 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 来解决还是应该认真考虑限制业务需求(为什么？)？

我知道这些问题有点软，我希望读者理解这不是我可以在构建之前测试的命题。

如果需要任何说明，请告诉我。感谢阅读!

Answer 1

首先:如果将技术问题留给 IT 部门，则希望它“能够正常工作”- 特别是如果您的预算允许“80% 当前”的硬件水平。

我确实有过在入门级和过时的硬件上处理 MySQL 中超过 2 亿行的经验，我总是感到非常惊讶。

一些提示:

• 在每月刷新时，加载没有非主索引的表，然后创建它们。搜索甜蜜点，并行创建多少个索引最有效。在日期少得多(大约 10M)的项目中，与天真的“创建表，然后加载数据”方法相比，这种加载时间减少了 70%

• 尝试掌握并发查询的数量和复杂性:这会影响您的硬件决策(较少的并发 = 较少的 IO，更多的 CPU)

• 假设您有 20 个 64 位的数字字段，乘以 200M 行:如果我可以正确计算，这就是 32GB 的有效负载。用便宜的磁盘换取 64G 内存，永远不会有 IO 瓶颈。

• 确保将表空间设置为只读