在SQL Server中管理大数据

Question

我们的团队面临着在插入表中的sql server块上查询大量数据的问题。

我们正在开发一个.NET项目，其中涉及保存和查询大量数据。 该项目包含两个数据库，一个是实时数据库，另一个是历史数据库，两个都是SQL Server数据库，它们位于不同的计算机上。 这两个数据库具有完全相同的表结构，并且只有四个表。

实时数据库包含少量的实时数据，并且内部数据正在不断更新。 历史数据库包含所有更新历史记录。 当项目运行时，它将把更新查询发布到实时数据库，并将查询插入历史数据库。 每天将在历史数据库中执行大约200万次插入。 查询是异步执行的。

历史数据库也将用于数据检索和报告目的。 人们将在服务器上运行查询，他们将运行哪些查询是我们无法控制的。 我们现在面临的问题是，当运行返回大量行的查询时，连接池将在很短的时间内充满，结果将发生连接超时并且数据丢失。

我们尝试调整表上的索引，以增加连接池的最大大小并增加超时时间，但是它们中的任何一个都不能首先解决问题。 在生产中，该项目将运行5年，届时数据库中将有40亿行。

我想我的真正问题是人们通常如何在SQL Server中处理大数据，如何在具有数百万或数十亿行的表上同时管理插入和选择。

Answer 1

您的体系结构存在一个基本错误，即它不将历史数据库视为实时数据库。 尽管名称如此，它实际上是因为数据是实时插入的。 称其为您将要进行的内容，并拆分插入内容和更新内容，但仍然需要针对当前体系结构的修复程序。

要解决此问题，您可以在概念上添加/重新配置第三个数据库，这将在时间上分离插入。 您可以创建一个作业（例如SSIS程序包）以在非高峰时间将行批量插入数据库中，而不是实时提供历史数据库。 可能是一天一次，例如凌晨2点，也可能是一天多次。 这取决于您的业务。 假设非高峰传输和查询发生在不同的时间，则定期批量加载将允许快速批量传输，而不会减慢对历史数据执行的查询。 需要权衡的是您的历史数据不能达到第二个，但这可能就足够了。 当然，您需要将实时插入存储在两次传输之间的某个位置。 这就是为什么我提到了第三个数据库，但是您可以将临时存储折叠到您的实时数据库中，而不会影响后端用户。

这是经常做的事情，可以在野外直接回答您的最后一个问题。 您通常通过某种时期转移过程来分离交易处理数据库（实时数据库）和分析处理数据库（历史数据库，OLAP，数据仓库等），这通常会试图避免交易处理和查询的方式通过一些预定的任务。 您还可以使用排队系统（例如MSMQ，RabbitMQ等）作为实时数据库和历史数据库之间的中间存储。 这将使两个数据库解耦，同时还允许更实时地查询历史数据。

如果计划的批量传输或队列不可行，则可以取消规范化。 找出要收集的数据以及如何对其进行汇总，并专门为那些查询创建非规范化表。

祝好运。