我目前正在处理我们的web应用程序每30秒接收至少一百万个请求的情况。因此，这些请求将导致在5个表之间生成3-5百万行插入。这是一个相当沉重的负担。目前，我们正在使用多线程来处理这种情况(它更快一些，但无法获得更好的CPU吞吐量)。然而，未来的负荷肯定会增加，我们也必须考虑到这一点。从现在起6个月后，我们看到的负载大小是目前的两倍，我目前正在寻找一种可能的新解决方案，该解决方案可扩展，并且应该足够容易地适应此负载的任何进一步增加。目前使用多线程，我们使整个调试场景变得相当复杂，有时我们在跟踪问题上遇到问题。
仅供参考，我们已经在使用前一篇文章中提到的SQL内置插入/复制
Sql server 2008 -插入大量数据的性能调优特性
然而，我正在寻找一个更有能力的解决方案(我认为应该有一个)，将解决这种情况。
注意:我不寻找任何代码片段或代码示例。我只是在寻找一个概念的大画面，我可能会使用，我相信我可以进一步采取一个优雅的解决方案:)
解决方案还应该更好地利用线程和进程。我不希望我的线程/进程因为其他资源而等待执行某事。
如有任何建议，我将不胜感激。
Update:不是每个请求都会导致insert…然而，其中大多数将导致一些SQL操作。应用程序执行不同类型的事务，这将导致大量的批量sql操作。我更关心的是插入和更新。这些操作不一定是实时的，可能会有一点延迟……然而，实时处理它们会很有帮助。
我认为你的问题更倾向于获得更好的CPU吞吐量，这将导致更好的性能。因此，我可能会考虑类似于异步处理的东西，其中线程永远不会闲置，您可能必须以链表或任何其他适合您编程模型的数据结构的形式维护队列。
这将工作的方式是你的线程将尝试立即执行给定的任务，如果有任何东西会阻止它们这样做，那么它们将把该任务推入队列，这些推入的项目将根据它在容器/队列中存储项目的方式进行处理。
在你的情况下，因为你已经在使用批量sql操作，你应该很好地使用这个策略。
让我知道这是否对你有帮助。
是否可以对数据库进行分区，以便将插入分散到各处?插入后如何使用这些数据?是否根据客户、地理位置或其他因素对数据进行自然划分?
既然你正在使用SQL server，我建议你买几本关于SQL server高可用性和高性能的书。内部手册也可能有所帮助。亚马逊有一堆这样的东西。这是一个复杂的问题，在公告栏上给出一个简单的答案需要太多的深度。但基本上，高性能设计有几个关键，包括硬件选择、分区、正确索引、正确查询等。为了有效地做到这一点，您必须深入了解SQL Server在底层做了什么，以及更改如何在性能上产生巨大差异。
由于您不需要实时插入/更新，您可能会考虑使用两个数据库;一个用于读，一个用于写。类似于OLTP数据库和OLAP数据库:
读数据库:
- 尽可能多地索引，以最大化读取性能。
- 如果性能需要，可能会反规范化。
- 不总是最新的
插入/更新数据库:
- 没有索引。这将有助于最大化插入/更新性能 尽量正常化。
- 始终保持最新。
您将基本上直接所有插入/更新操作到插入/更新数据库。然后，您将创建一个发布进程，以特定的时间间隔将数据移动到读取数据库。当我在过去看到这种情况时，数据通常是在晚上很少有人使用该网站时转移的。有许多移动数据的选项，但我将从SSIS开始。
这取决于你做几件事的能力:
- 已读取的数据超过日期一天 在合理的时间内完成你的夜间读取数据库更新过程。