我们的团队面临着查询插入表中的sql server块上的大量数据的问题。
我们正在开发一个涉及保存和查询大量数据的.NET项目。该项目包含两个数据库，一个是Realtime数据库，另一个是Historical数据库，两个都是SQL Server数据库，它们位于不同的机器上。这两个数据库具有完全相同的表结构，并且只有四个表。
Realtime DB包含少量实时数据，内部数据不断更新。历史数据库包含所有更新历史记录。当项目运行时，它将向Realtime DB发送更新查询，并将查询插入到历史数据库中。每天将在Historical DB上执行大约200万个插入。查询是异步执行的。
历史数据库也将用于数据检索和报告目的。人们将在服务器上运行查询，他们将运行的查询是我们无法控制的。我们现在面临的问题是，当一个返回大量行的查询正在运行时，连接池将在短时间内满，因此会发生连接超时并且数据将丢失。
我们尝试在表上调整索引，增加连接池的最大大小并增加超时时间，但它们都不会主要解决问题。在生产中，项目将运行5年，届时数据库中将有40亿行。
我想我真正的问题是人们通常如何处理SQL服务器中的大数据，如何在具有数百万或数十亿行的表上同时管理插入和选择。
答案 0 :(得分：3)
您的体系结构存在一个基本错误，因为它不会将历史数据库视为实时数据库。实际上，尽管名称如此，因为数据是实时插入的。按照您的意愿调用它并拆分插入和更新，但您仍需要修复当前的体系结构。
要解决此问题，您可以概念性地为第三个数据库添加/重新配置，这将在时间上解耦插入。您可以创建一个作业（例如SSIS包），在非高峰时间批量插入数据库，而不是实时提供历史数据库。这可能是每天一次，比如凌晨2点，或者一天多次。这取决于您的业务。假设非高峰转移和查询在不同时间发生，定期批量加载将允许快速批量转移，同时不会减慢对历史数据执行的查询。权衡的是你的历史数据不是第二个，但这可能足够好。当然，您需要在转移之间存储实时插入。这就是我提到第三个数据库的原因，但您可以简单地将该临时存储折叠到实时数据库中，而不会影响后端用户。
这是经常做的事情，直接回答你的最后一个问题。您将事务处理db（实时数据库）与分析处理（历史数据库，OLAP数据仓库等）通过某些期间传输过程分开，该过程试图避开事务处理和查询，通常通过一些预定的任务。您还可以使用排队系统（例如MSMQ，RabbitMQ等）作为实时和历史数据库之间的中间存储。这将解耦两个数据库，同时还允许更接近实时查询历史数据。
如果计划的批量传输或队列不是可行的选项，您可以进行非规范化。确定收集哪些数据以及如何聚合这些数据并专门为这些查询创建非规范化表。
祝你好运。