3

我们正在设计一个用于临时分析的表格，该表格将随着时间的推移为收到的索赔捕获无数的值字段。表结构本质上是（伪代码）：

   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 年（希望更多）的已受理索赔。每项索赔都应在索赔开始和当前日期之间的每个月末都有一个估价日期。典型的索赔起始量为每年 50k-100k。

将所有这些加起来，我预测了一个行数约为 1 亿的表，并且根据业务需求，可能会在几年内增长到多达 5 亿。该表将每月重建。消费者只会选择。除了每月刷新外，不会发生更新、插入或删除。

我是从业务（消费者）方面来的，但我有兴趣在降低 IT 成本的同时保留此表的分析价值。我们并不太关心表格的快速返回，但偶尔需要向它抛出几十个查询并在一三天内获得所有结果。

为了论证的缘故，让我们假设技术堆栈是，我不知道，在现代硬件的 80% 中。

我的问题是：

  • 考虑到对大容量表的查询频率较低，索引的成本效益是否会变得过高？
  • SO 社区是否有使用 +100M 行表的经验并且可以提供有关如何管理的提示？
  • 我是否应该将数据库技术问题留给 IT 部门来解决，还是应该认真考虑限制业务需求（为什么？）？

我知道这些都是一些软性问题，我希望读者明白这不是我可以在构建之前测试的命题。

如果需要任何澄清，请告诉我。谢谢阅读！

4

4 回答 4

6

首先：如果将技术问题留给 IT 部门，预计这将“正常工作”——尤其是如果您的预算允许“当前 80%”的硬件水平。

我确实有在入门级和过时硬件上使用 MySQL 中超过 200M 行的经验，我总是很惊讶。

一些提示：

  • 在每月刷新时，加载没有非主索引的表，然后创建它们。寻找最佳点，并行创建多少索引效果最好。在日期少得多（约 10M）的项目中，与天真的“创建表，然后加载数据”方法相比，这减少了 70% 的加载时间

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

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

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

于 2012-05-24T02:50:14.180 回答
3

您可以考虑仅存储更改的锚建模方法。

考虑到有这么多预期的重复行，大约 95%——将行数从 100M 减少到只有 5M，消除了您的大部分顾虑。

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

对于“低”数据量，以下结构的查询速度比普通表慢；在某一时刻（随着数据量的增长）它变得更快。这一点取决于几个因素，但它可能很容易测试。看看这份关于锚建模的白皮书——参见第 10 页的图表。

在此处输入图像描述

就anchor-modeling而言，它相当于

在此处输入图像描述

该建模工具具有自动代码生成功能，但目前似乎完全支持 MS SQL 服务器，尽管下拉菜单中也有 ORACLE。它仍然可以用作代码助手。

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

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

  2. 时间点函数（自动生成）

  3. 将从中加载此结构的临时表（请参阅数据仓库加载教程）

  4. 加载函数，从临时表到结构

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

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

于 2012-05-25T13:34:38.207 回答
1

在没有持续更新/插入的情况下，索引永远不会产生负面的性能影响，只会产生积极的影响（对于这种大小的表来说是很多数量级）。

更关键的是，该模式存在严重缺陷。你想要的是

Claim
    claim_key
    valuation_date

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

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

于 2012-05-24T02:41:53.207 回答
0

使用分区概念并在您执行的每个查询上应用分区键将节省更多的性能改进。

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

另一种设计解决方案是，如果我们知道表格将非常大，请尽量不要在执行之前对表格应用更多约束并在逻辑中处理并且表格上没有很多列以避免行链接问题。

于 2015-03-27T20:38:34.980 回答