Web应用程序接收数百万个请求，并导致在SQL Server 2008中每30秒生成数百万行插入

Question

我目前正在解决我们的网络应用程序每30秒至少收到一百万个请求的情况。因此，这些请求将导致在5个表之间生成3-5百万行插入。这是非常重要的负担。目前我们正在使用多线程来处理这种情况（速度稍快但无法获得更好的CPU吞吐量）。然而，未来负荷肯定会增加，我们也必须考虑到这一点。从现在起6个月后，我们正在考虑我们目前正在接收的负载大小的两倍，我目前正在寻找一种可扩展的可能的新解决方案，并且应该足够容易以适应此负载的任何进一步增加。         目前使用多线程我们使整个调试场景非常复杂，有时我们遇到跟踪问题的问题。

仅供参考我们已经在使用上一篇文章中提到的SQL Builk插入/复制

Sql server 2008 - performance tuning features for insert large amount of data

然而，我正在寻找能够解决这种情况的更有能力的解决方案（我认为应该有一个）。

注意：我不是在寻找任何代码段或代码示例。我只是在寻找一个我可能会使用的概念的大图，我相信我可以进一步采用优雅的解决方案：）

此外，解决方案应该更好地利用线程和进程。而且我不希望我的线程/进程因为某些其他资源而等待执行某些事情。

任何建议都将深受赞赏。

更新：并非每个请求都会导致插入...但是大多数请求都会导致一些SQL操作。应用程序执行不同类型的事务，这将导致大量的批量SQL操作。我更关注插入和更新。 并且这些操作不一定是实时的，可能会有一点滞后......但是实时处理它们将会非常有用。

Answer 1

您是否可以对数据库进行分区以便插入数据？插入后如何使用这些数据？客户或地理位置或其他因素对数据有自然的偏好吗？

由于您使用的是SQL Server，我建议您获得有关SQL Server的高可用性和高性能的几本书。内部书籍也有帮助。亚马逊有很多这样的。这是一个复杂的主题，需要太多的深度才能在公告板上进行简单的回答。但基本上高性能设计有几个关键，包括硬件选择，分区，正确的索引，正确的查询等。为了有效地做到这一点，你必须深入了解SQL Server在幕后做什么以及变化如何产生重大影响在表现。

Answer 2

我认为您的问题更倾向于获得更好的CPU吞吐量，从而获得更好的性能。所以我可能会看到像 Asynchronous Processing 这样的东西，其中一个线程永远不会闲置，你可能必须以链表或任何其他适合的数据结构的形式维护一个队列你的编程模型。

这样做的方法是你的线程会尝试立即执行一个给定的工作，如果有任何东西阻止他们这样做，那么他们会把这个工作推入队列，这些推送的项目将根据如何处理它将项目存储在容器/队列中。

在您的情况下，因为您已经在使用批量SQL操作，所以应该采用这种策略。

知道这是否对你有帮助。

Answer 3

由于您不需要实时插入/更新，因此您可能会考虑使用两个数据库;一个用于读取，一个用于写入。与拥有OLTP数据库和OLAP数据库类似：

阅读数据库：

• 尽可能多地索引，以最大限度地提高读取性能。
• 如果性能需要，可能会非规范化。
• 并非总是最新。

插入/更新数据库：

• 根本没有索引。这将有助于最大化插入/更新性能
• 尝试尽可能正常化。
• 始终保持最新状态。

您基本上将所有插入/更新操作定向到插入/更新数据库。然后，您将创建一个发布过程，该过程将以特定时间间隔将数据移动到读取数据库。当我在过去看到这个数据时，通常会在夜间基础上移动数据，因为很少有人会使用该网站。移动数据有很多选项，但我首先要看SSIS。

这取决于你做一些事情的能力：

• 已读取数据最多一天过时
• 在合理的时间内完成每晚阅读数据库更新过程。