gre*_*ade 5 sql rdbms large-data-volumes
我正在开发一个必须存储非常大的数据集和相关参考数据的项目.我从未遇到过需要这么大的表的项目.我已经证明,至少有一个开发环境不能应对数据库层与复杂查询对应用程序层生成的视图所需的处理(具有多个内部和外部联接的视图,对具有9000万行的表进行分组,求和和求平均值) ).
我测试过的RDBMS是AIX上的DB2.失败的开发环境加载了将在生产中处理的卷的1/20.我确信生产硬件优于dev和staging硬件,但我不相信它会处理大量的数据和查询的复杂性.
在开发环境失败之前,需要花费超过5分钟的时间来返回由大型表格复杂查询(许多连接,大量分组,求和和平均)生成的小数据集(数百行).
我的直觉是数据库架构必须改变,以便视图当前提供的聚合作为非高峰批处理过程的一部分执行.
现在我的问题.声称有这类事情经验的人(我不这样认为)我的担心是没有根据的,我向我保证.是吗？现代RDBMS(SQL Server 2008,Oracle,DB2)能否应对我所描述的数量和复杂性(给定适当数量的硬件),还是我们处于谷歌BigTable等技术领域？
我希望得到那些实际上不得不在非理论层面上使用这种音量的人的答案.
数据的性质是金融交易(日期,金额,地理位置,业务),因此几乎所有数据类型都有代表.所有参考数据都被标准化,因此是多个连接.
我使用一些SQL Server 2008数据库,其中包含数十亿行的表.我们遇到的唯一真正的问题是磁盘空间,备份时间等问题.查询总是(并且仍然)总是很快,通常在<1秒范围内,即使有大量连接,聚合和重复,也不会超过15-30秒.等等.
关系数据库系统肯定可以处理这种负载,如果一个服务器或磁盘开始变得紧张,那么大多数高端数据库都有分区解决方案.
你没有在你的问题中提到关于数据如何被索引的任何内容,以及9次中有10次,当我听到关于SQL性能的抱怨时,不充分/不存在索引就是问题所在.
当您看到慢查询时,您应该始终做的第一件事就是拉出执行计划.如果您看到任何完整的索引/表扫描,行查找等,表明您的查询索引不足,或者写入的查询无法利用覆盖索引.低效连接(主要是嵌套循环)往往是第二常见的罪魁祸首,通常可以通过查询重写来解决这个问题.但是没有能够看到这个计划,这只是猜测.
所以问题的基本答案是肯定的,关系数据库系统完全能够处理这种规模,但是如果你想要更详细/更有帮助的东西,那么你可能想发布一个示例模式/测试脚本,或至少一个执行计划我们来看看.