最适合实时大容量处理 API 的数据库架构

Question

我有一个服务应该支持许多用户之间的实时交互（数千个实时）。我在 IIS 7.5 上使用 .NET 4 和 MSSQL 2008。

数据库只包含几个没有高使用率或数据的表 - 但是一个表增长非常快（每次使用都会每秒更新一条新记录）。

在我的服务器负载测试中，它在一小时左右的时间内增长到超过 400,000 条记录 - 我的性能在大约 2 小时内从 200 毫秒 RTT 下降到 800 毫秒 RTT。

我应该如何建立我的数据库来支持这个？也许问题出在另一个地方？

现在它适用于一个数据库中的所有表，但我想也许我应该将“重”表移动到一个新的数据库以提高性能。它应该工作吗？这是明智之举吗？

我已经考虑将该表移动到 NoSQL - 会有所帮助吗？

欢迎任何想法！

Answer 1

您是否为每个请求都往返于数据库？如果是这样，性能随着表增长而恶化的典型原因是陈旧的统计数据，例如，当表很小时有意义的查询计划一旦增长就不是最佳的。检查查询计划。还要检查您是否启用了自动统计信息创建、更新和异步更新。我假设您已经在使用聚集索引。

除非您 a) 了解您正在等待的是什么并且 b) 不同的数据库缓解了这一点，否则将您的热表移动到不同的数据库是没有意义的。例如，如果您正在等待 I/O，也许移动到存储在不同磁盘上的不同数据库可能会有所帮助 - 但如果它通过相同的存储控制器运行，则可能不会。如果您正在等待 CPU，那么这将无济于事，您需要添加 CPU 或将其移至另一台主机。如果您正在等待锁争用，那么这将无济于事，您将需要使用更合适的隔离级别。因此，首先，执行必要的分析以查看您的 SQL Server 在哪里花费了时间。

但还要考虑每个查询是否都需要到数据库的往返，例如在 C# 中，有提供O(1)访问的数据结构。这可能是一个更好的方法。