6

我正在开发一个必须存储非常大的数据集和相关参考数据的项目。我从来没有遇到过需要这么大的表的项目。我已经证明，至少有一个开发环境无法在数据库层处理对应用层生成的视图的复杂查询（具有多个内部和外部连接的视图、分组、求和和对具有 9000 万行的表进行平均）所需的处理）。

我测试过的 RDBMS 是 AIX 上的 DB2。失败的开发环境加载了将在生产中处理的卷的 1/20。我确信生产硬件优于开发和登台硬件，但我只是不相信它能够应对庞大的数据量和查询的复杂性。

在开发环境失败之前，需要超过 5 分钟才能返回一个小数据集（数百行），该数据集是由针对大型表的复杂查询（许多连接、大量分组、求和和平均）生成的。

我的直觉是数据库架构必须改变，以便视图当前提供的聚合作为非高峰批处理的一部分执行。

现在我的问题。声称有过这种事情经历的人（我没有）向我保证，我的恐惧是没有根据的。他们是吗？现代 RDBMS（SQL Server 2008、Oracle、DB2）能否应对我所描述的体积和复杂性（给定适当数量的硬件），或者我们是否处于像 Google 的 BigTable 这样的技术领域？

我希望从那些实际上不得不在非理论层面上使用这种卷的人那里得到答案。

数据的性质是金融交易（日期、金额、地理位置、业务），因此几乎所有数据类型都被表示。所有的参考数据都是标准化的，因此是多个连接。

4

5 回答 5

5

我使用一些 SQL Server 2008 数据库，其中包含数以十亿计的行数的表。我们遇到的唯一真正的问题是磁盘空间、备份时间等。查询总是（并且仍然是）很快，通常在 < 1 秒的范围内，即使有大量的连接、聚合和很快。

关系数据库系统绝对可以处理这种负载，如果一台服务器或磁盘开始紧张，那么大多数高端数据库都有分区解决方案。

您的问题中没有提到任何关于数据如何被索引的问题，当我听到关于 SQL 性能的抱怨时，十分之九，索引不足/不存在是问题所在。

当您看到缓慢的查询时，您应该始终做的第一件事就是拉起执行计划。如果您看到任何完整的索引/表扫描、行查找等，这表明您的查询索引不足，或者编写的查询无法利用覆盖索引。低效的连接（主要是嵌套循环）往往是第二个最常见的罪魁祸首，通常可以通过查询重写来解决这个问题。但看不到计划，这一切都只是猜测。

所以你的问题的基本答案是肯定的，关系数据库系统完全有能力处理这个规模，但是如果你想要更详细/有用的东西，那么你可能想要发布一个示例模式/测试脚本，或者至少一个执行计划我们去看看。

于 2010-04-07T02:54:30.410 回答
3

9000 万行应该是大约 90GB，因此你的瓶颈是磁盘。如果您很少需要这些查询，请按原样运行它们。

如果您经常需要这些查询，则必须拆分数据并预先计算未更改（或自上次以来未更改）的部分数据的分组求和和平均。

例如，如果您处理最近 N 年直到今天（包括今天）的历史数据，您可以一次处理一个月（或一周、一天）并将总数和平均值存储在某处。然后在查询时您只需要重新处理包括今天在内的时间段。

一些 RDBMS 让您可以控制何时更新视图（在选择时、在源更改时、离线时），如果您复杂的分组求和和平均实际上足够简单，数据库可以正确理解，理论上它可以更新一些在合理的时间内在源表中每次插入/更新/删除时视图中的行。

于 2010-06-24T09:14:03.007 回答
2

看起来您正在从标准化数据一遍又一遍地计算相同的数据。在这种情况下加快处理速度的一种方法是保持 SQL 具有良好的报告、关系和一致性等，并使用每 x 分钟计算一次的OLAP Cube 。基本上，您会定期构建一个非规范化数据的大表，以便快速查找。关系数据被视为主数据，但 Cube 允许在任何一点从数据库中快速检索预先计算的值。

于 2010-04-07T03:01:02.307 回答
1

在我们基于 SQL Server 2005 的数据仓库中的维度（Kimball 方法）模型中，我们经常在一个月的分区中拥有包含那么多行的事实表。

有些事情是即时的，有些事情需要一段时间，这取决于操作以及正在组合多少颗星以及发生了什么。

相同的模型在 Teradata 上表现不佳，但我的理解是，如果我们在 3NF 中重新建模，Teradata 并行化会工作得更好。Teradata 安装比 SQL Server 安装贵很多倍，因此它只是显示了差异建模以及将数据和流程与基础功能集匹配的重要性。

如果不了解有关您的数据的更多信息，以及它当前的建模方式以及您做出的索引选择，就很难再说什么了。

于 2010-04-07T02:41:01.753 回答
1

如果这只是您数据的 1/20，那么您几乎肯定需要寻找更具可扩展性和效率的解决方案，例如 Google 的 Big Table。看看NoSQL

我个人认为 MongoDB 是介于 NoSQL 和 RDMS 之间的优秀产品。它不是关系型的，但它提供了比简单的文档存储更多的功能。

于 2010-04-07T00:53:55.527 回答