我正在开发一个必须存储非常大的数据集和相关参考数据的项目。我从未遇到过需要这么大的表的项目。我已经证明，至少有一个开发环境不能应对数据库层与复杂查询对应用程序层生成的视图所需的处理（具有多个内部和外部联接的视图，对具有9000万行的表进行分组，求和和求平均值） ）。
我测试过的RDBMS是AIX上的DB2。失败的开发环境加载了将在生产中处理的卷的1/20。我确信生产硬件优于dev和staging硬件，但我不相信它会处理大量的数据和查询的复杂性。
在开发环境失败之前，需要花费超过5分钟的时间来返回由大型表格复杂查询（许多连接，大量分组，求和和平均）生成的小数据集（数百行）
我的直觉是数据库架构必须更改，以便视图当前提供的聚合作为非高峰批处理过程的一部分执行。
现在提出我的问题。声称有这类事情经验的人（我不这样认为）我的担心是没有根据的，我向我保证。是吗？现代RDBMS（SQL Server 2008，Oracle，DB2）能否应对我所描述的数量和复杂性（给定适当数量的硬件），还是我们处于Google BigTable等技术领域？
我希望得到那些实际上不得不在非理论层面上使用这种音量的人的答案。
数据的性质是金融交易（日期，金额，地理位置，业务），因此几乎所有数据类型都有代表。所有参考数据都被标准化，因此是多个连接。
答案 0 :(得分：5)
我使用一些SQL Server 2008数据库，其中包含数十亿行的表。我们遇到的唯一真正的问题是磁盘空间，备份时间等问题。查询总是（并且仍然是）快速，通常在＆lt; 1秒范围，即使有大量连接，聚合等，也不会超过15-30秒。
关系型数据库系统绝对可以处理这种负载，如果一台服务器或磁盘开始变形，那么大多数高端数据库都有分区解决方案。
你没有在你的问题中提到有关数据如何被索引的内容，以及9次中有10次，当我听到有关SQL性能的抱怨时，不充分/不存在索引就是问题。
当您看到慢查询时，您应该始终做的第一件事就是拉出执行计划。如果您看到任何完整的索引/表扫描，行查找等，表明您的查询索引不足，或者写入的查询无法利用覆盖索引。低效连接（主要是嵌套循环）往往是第二常见的罪魁祸首，通常可以通过查询重写来解决这个问题。但是没有能够看到这个计划，这只是猜测。
所以问题的基本答案是是的，关系数据库系统完全能够处理这种规模，但是如果你想要更详细/更有帮助的东西，那么你可能想发布一个示例模式/测试脚本，或者至少是我们要查看的执行计划。
答案 1 :(得分：2)
看起来你正在从标准化数据中反复计算相同的数据。在这种情况下加速处理的一种方法是使SQL保持良好的报告和关系以及一致性等，并使用每{x分钟计算一次的OLAP Cube。基本上，您定期构建一个非规范化数据的大表，允许快速查找。关系数据被视为主数据，但Cube允许在任何一点从数据库中检索快速预先计算的值。
答案 2 :(得分：2)
9000万行应该是大约90GB，因此你的瓶颈就是磁盘。 如果您很少需要这些查询，请按原样运行它们。
如果您经常需要这些查询，则必须拆分数据并预先计算您的数据部分的平均值和平均值，这些数据不会发生变化（或自上次以来没有变化）。
例如，如果您处理过去N年（包括今天）的历史数据，您可以一次处理一个月（或一周，一天），并将总计和平均值存储在某处。然后在查询时，您只需要重新处理包含今天的句点。
有些RDBMS可以控制何时更新视图（在选择时，在源更改时，离线），如果复杂的分组求和和平均实际上足够简单，数据库无法正确理解，理论上，它可以在合理的时间内，在源表中的每次插入/更新/删除时更新视图中的几行。
答案 3 :(得分：1)
如果这只是您数据的1/20，那么您几乎肯定需要研究更具可扩展性和效率的解决方案，例如Google的Big Table。看看NoSQL
我个人认为MongoDB在NoSQL和RDMS之间是一个很棒的。它不是关系型的，但它提供了比简单文档存储更多的功能。
答案 4 :(得分：1)
在我们SQL Server 2005上的数据仓库中的维度（Kimball方法论）模型中，我们经常在一个月的分区中拥有包含那么多行的事实表。
有些事情是即时的，有些事情需要一段时间，这取决于操作以及合并了多少星星以及发生了什么。
相同的模型在Teradata上表现不佳，但我的理解是，如果我们在3NF中重新建模，Teradata并行化将会更好地工作。 Teradata安装的成本比SQL Server安装成本高出许多倍，因此它只是表明建模和匹配您的数据和流程与底层功能集的关系有多大差异。
如果不了解您的数据，以及目前的数据建模方式以及您做出的索引选择，则很难再说些什么。