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

Question

我们正在设计一个用于临时分析的表格,该表格将随着时间的推移捕获所收到的索赔的无数值字段.表结构本质上是(伪ish代码):

   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个近期(希望更多)的截取索赔.每项索赔应具有在索赔开始与当前日期之间发生的每个月末的估价日期.典型的索赔开始量为每年5万至10万.

加上所有这些我计划一个行数大约为1亿的表,并且可能会根据业务需求多年增长到5亿.该表将每月重建一次.消费者只会选择.除每月刷新外,不会发生更新,插入或删除.

我是从业务(消费者)方面来的,但我有兴趣在保留此表的分析价值的同时降低IT成本.我们并不是绝对关心表格的快速回报,但有时需要在其中抛出几十个查询并在一天或三天内获得所有结果.

为了论证,让我们假设技术堆栈,我不知道,在现代硬件的第80百分位.

我的问题是:

• 考虑到对高容量表的查询频率较低,是否存在指数成本效益过大的问题？
• SO社区是否有+ 100M行表的经验,可以提供有关如何管理的提示？
• 我是否将数据库技术问题留给IT解决,还是应该认真考虑抑制业务需求(以及为什么？)？

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

如果需要任何说明,请告诉我.谢谢阅读!

Answer 1

首先:如果将技术问题留给IT,预计这将"正常工作" - 特别是如果您的预算允许"80%当前"硬件级别.

我确实有入门级和过时硬件在MySQL中有200M +行的经验,而且我总是很惊讶.

一些提示:

• 在每月刷新时,加载没有非主索引的表,然后创建它们.寻找甜点,并行创造多少指数创作效果最佳.在一个日期少得多(约10M)的项目中,与天真的"创建表,然后加载数据"方法相比,减少了70%的加载时间

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

• 假设你有20个数字字段,每个64位,超过200M行:如果我能正确计算,那么这是32GB的有效载荷.针对64G RAM交易便宜的磁盘,永远不会有IO瓶颈.

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