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瓶颈。

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

Answer 2

您可以考虑使用anchor modeling方法来存储更改。

考虑到有很多预期的重复行，约95％ - 将行数从100M提高到仅5M，消除了大部分问题。

此时它主要是缓存考虑因素，如果是整个表 可以某种方式适应缓存，事情发生得相当快。

对于“低”数据卷，以下结构的查询速度比普通表慢;在某一点上（随着数据量的增长），它变得更快。这一点取决于几个因素，但可能很容易测试。请查看此white-paper about anchor modeling - 请参阅第10页的图表。

在锚建模方面，它相当于

建模工具有自动代码生成，但它似乎只支持MS SQL服务器，尽管下拉列表中也有ORACLE。它仍然可以用作代码助手。

在支持代码方面，您需要（最低）

1. 最新透视图（自动生成）

2. 时间点功能（自动生成）

3. 将从中加载此结构的临时表（see tutorial用于数据仓库加载）

4. 加载功能，从登台表到结构

5. 修剪每个属性的函数，以删除任何重复值

通过遵循自动生成的代码模式很容易创建所有这些。

Answer 3

由于没有持续的更新/插入，索引永远不会产生负面的性能影响，只有正数（对于此大小的表格，会有多个数量级）。

更关键的是，架构存在严重缺陷。你想要的是

Claim
    claim_key
    valuation_date

ClaimValue
    claim_key (fk->Claim.claim_key)
    value_key
    value

这样更节省空间，因为它只存储您实际拥有的值，并且当单个行的值数超过您分配的列数时不需要更改架构。

Answer 4

使用分区概念＆amp;在您执行的每个查询上应用分区键将保存，从而提高性能。

在我们公司，我们通过分区概念解决了大量的性能问题。

另外一个设计解决方案是，如果我们知道表格会非常大，请尽量不要在表格上施加更多约束。在你执行之前处理逻辑在桌面上没有多列，以避免行链接问题。