代码之家 › 专栏 › 技术社区 › grenade

RDBMS的实际大小限制

large-data-volumes rdbms sql

grenade · 技术社区 · 16 年前

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

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

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

现在回答我的问题。那些声称有过这种经历(我没有)的人向我保证,我的恐惧是毫无根据的。是吗?现代RDBMS(sqlserver2008、Oracle、DB2)能否应对我所描述的数量和复杂性(给定适当数量的硬件),或者我们是否处于像Google的BigTable这样的技术领域?

数据的性质是金融交易(日期、金额、地理位置、业务),因此几乎所有的数据类型都表示出来。所有的参考数据都是标准化的,因此存在多重连接。

5 回复 | 直到 16 年前

Aaronaught 16 年前

我使用一些SQLServer2008数据库,其中包含行数为数十亿的表。我们遇到的唯一真正的问题是磁盘空间、备份时间等问题。查询总是很快(现在仍然如此),通常在<1秒范围,即使是重连接、聚合等,也不会超过15-30秒。

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

在你的问题中,你没有提到任何关于数据如何被索引的问题,10次中有9次,当我听到关于SQL性能的抱怨时,结果证明索引不足/不存在是问题所在。

当你看到一个缓慢的查询时,你应该做的第一件事就是调出执行计划。如果您看到任何完整的索引/表扫描、行查找等,这表明您的查询没有足够的索引,或者是编写的查询无法利用覆盖索引。低效的连接(主要是嵌套循环)往往是第二大罪魁祸首,通常可以通过查询重写来解决这个问题。但在看不到计划的情况下,这一切都只是猜测。

是的,关系数据库系统完全能够处理这种规模 ,但是如果您想要更详细/有用的内容,那么您可能需要发布一个示例模式/测试脚本,或者至少一个执行计划供我们查看。

Dima Tisnek 15 年前

9000万行应该是90GB左右,因此您的瓶颈是磁盘。

如果你经常需要这些查询,你必须分割你的数据,并预先计算你的数据部分没有改变(或没有改变,因为上次)的gouping总和和平均数。

例如,如果您处理过去N年(包括今天)的历史数据,您可以一次处理一个月(或一周、一天),并将总计和平均值存储在某处。然后在查询时只需要重新处理包含今天的时段。

Billy ONeal IS4 16 年前

Earlz 16 年前

我个人认为MongoDB是NoSQL和RDMS之间令人敬畏的中间产物。它不是关系型的,但是它提供了比简单的文档存储更多的特性。

Cade Roux 16 年前

在SQLServer2005数据仓库中的多维(Kimball方法)模型中,我们通常在一个月分区中有这么多行的事实表。

有些事情是瞬间发生的,有些事情需要一段时间,这取决于操作、有多少恒星被合并以及发生了什么。

同样的模型在Teradata上的性能很差,但我的理解是,如果我们用3NF重新建模,Teradata并行化将工作得更好。Teradata安装的成本是sqlserver安装的许多倍,因此它只是展示了建模以及将数据和流程与底层功能集匹配有多大的不同。

如果不了解更多关于您的数据的信息,以及它当前是如何建模的,以及您做了哪些索引选择,就很难说什么了。