处理数十亿条记录的推荐数据库类型

Posted 2023-04-14

【中文标题】处理数十亿条记录的推荐数据库类型

【英文标题】：Recommended database type to handle billion of records

【发布时间】：2011-09-01 12:16:13

【问题描述】：

我开始从事一个项目，该项目必须重用一个 Microsoft SQL Server 2008 旧数据库，该数据库有一个包含超过 7,000,000 条记录的表。

最后几分钟对该表进行了查询，我想知道其他类型的数据库（即非关系型）是否会更好地处理这个问题。

你有什么推荐的？无论如何，有没有办法提高关系数据库的性能？

谢谢

更新：

我正在使用 Navicat 执行这个简单的查询：

SELECT DISTINCT [NROCAJA]
FROM [CAJASE]

如此复杂的东西和子查询不是问题。我还想知道是否缺少索引是问题所在，但该表似乎已编入索引：

史诗般的失败：

数据库在远程服务器中！！查询实际上需要 5 秒（我仍然认为这是很多时间，但现在问题不同了）。所用时间的 99% 是网络传输。无论如何感谢您的回答:)

【问题讨论】：

7M 记录不算多 - 如果您能提供更多信息，我们可以查看索引、计划等。

这太笼统了，无法回答。但是，如果构造正确，SQL Server 可以很好地处理数十亿条记录表。我猜你没有合适的索引来启动。

@elitalon - 编辑后，在 7,000,000 行表中，NROCAJA 有多少个 DISTINCT 值？如果相对较少，则可以使用递归 CTE 来优化它，或者您可以使用索引视图 (related)，如果有很多，则很可能是网络问题推回数据.

另外，您是否在该表上发生了并发数据修改？您的选择查询可能会遇到阻塞。或者您可能没有足够的 RAM，并且每次需要查找瓶颈时都需要从磁盘中导入数据。我建议阅读一本关于性能调优的书。

SELECT COUNT (DISTINCT [NROCAJA]) FROM [CAJASE] 需要多长时间？这将做同样的工作，但会消除大部分网络流量。另外，如果这仍然需要很长时间，请尝试 SELECT COUNT (DISTINCT [NROCAJA]) FROM [CAJASE] WITH (NOLOCK) 看看是否阻塞可能是罪魁祸首。

【参考方案1】：

700 万是 SQL Server 的小型数据库，它通过适当的设计轻松处理 TB 级数据。很可能你的设计很糟糕，缺少索引，硬件很差，查询性能很差。不要将数据库开发人员的无能归咎于 SQL Server。

【讨论】：

我根本没有责怪 SQL Server，这只是关于我被告知要使用的额外信息。另外，我通常要求替代关系数据库而不是特定引擎:)

【参考方案2】：

分析您的查询 - 700 万条记录并不是一个很大的数字，因此您很可能缺少索引或执行的复杂子查询在数据集扩展时表现不佳。

我认为您还不需要重新设计整个系统。

【参考方案3】：

您选择“distinct”这一事实可能是个问题。也许将这些不同的值移动到它自己的表中以避免重复。