非常慢的数据库服务器的模式答案

【问题标题】：Pattern for very slow DB Server非常慢的数据库服务器的模式
【发布时间】：2010-09-28 14:52:33
【问题描述】：

我正在构建一个 Asp.net MVC 站点，其中我有一个用于 Web 应用程序的快速专用服务器，但数据库存储在一个非常繁忙的 Ms Sql Server 中，许多其他应用程序都在使用它。

另外如果web服务器很快，应用响应时间很慢，主要是db服务器响应慢。

我无法更改数据库服务器，因为在 Web 应用程序中输入的所有数据最终都需要到达那里（出于备份原因）。

该数据库仅从 webapp 使用，我想找到一种缓存机制，其中所有数据都缓存在 web 服务器上，并且更新异步发送到 db。

在读取的数据库数据和插入的数据之间建立直接对应关系对我来说并不重要：就像阅读 StackOverflow 上的问题和插入后不需要立即显示的新插入问题一样）。

我想在 WCF 服务之间构建一个中间层，该服务将在慢速数据库服务器和本地服务器（可能是 Sqllite 或 SqlExpress 之一）之间交换和同步数据。

解决这个问题的最佳模式是什么？

【问题讨论】：

标签： sql-server asp.net-mvc design-patterns architecture caching

【解决方案1】：

我会做你已经在考虑的事情。为应用程序使用另一个数据库，并且仅将当前数据库用于备份目的。

【讨论】：

【解决方案2】：

你的瓶颈是什么？读数据还是写数据？

如果您担心读取数据，那么使用像 memcached 这样的基于内存的数据缓存机制会提高性能，因为大多数主流和最大的网站都这样做。 Scaling facebook hi5 with memcached 是一本好书。此外，实现应用程序端页面缓存将丢弃由应用程序进行的查询，从而触发较低的数据库负载和更好的响应时间。但这不会对数据库服务器负载产生太大影响，因为您的数据库还有其他一些重度用户。

如果写入数据是瓶颈，那么实现某种异步中间件存储服务似乎是必要的。如果您在前端服务器上有快速和慢速响应定时数据存储，那么使用轻量级数据库存储，如 mysql 或 postgresql（可能不是那么轻量级；））并使用您的真实数据库作为您站点的从属复制服务器是一个不错的选择给你。

【讨论】：

如果瓶颈是写入，那么您需要知道 DB 服务器是否可以在一天内跟上 Web 应用的速度。如果没有，那么数据库服务器永远不会与您一起扩展。如果可以，那你就有机会了。但是为什么DB机器这么慢呢？担心这个！
这才是真正的问题。为什么 db 跟不上 webapp？需要更好的硬件？需要负载均衡？在现实生活中，有些情况是你没有机会解决的。这就是变通方法的用武之地。系统管理是一门处理这些非理性情况的艺术。

【解决方案3】：

有许多复制技术可以为您提供正确的结果。通过在配置的“Web”端安装 SQL Server 实例，您可以选择：

从 Web 端（发布者）到数据库服务器端（订阅者）进行快照复制。您需要在 Web 服务器上安装付费版本的 SQLServer。我从未使用过这种配置，但它可能会在预定的同步时间使用大量 Web 服务器资源
在数据库服务器端（发布者）和 Web 端（订阅者）之间进行合并（或事务，如果请求）复制。然后，您可以使用免费版本的 MS-SQL Server，并根据您对网络服务器出现故障时可能丢失的数据的容忍度来安排同步过程的运行。

【讨论】：

【解决方案4】：

我想知道你是否可以改进它，在你的 Web 端添加一个 MDF 文件，而不是处理其他 IP 中的服务器......

只需添加一个SQL 2008 Server Express Edition文件并尝试，只要不传递4Gb数据就可以了，当然还有更多限制，但只是为了速度，为什么不尝试呢？

【讨论】：

【解决方案5】：

您还应该考虑所涉及的网络交换机。如果数据库服务器正在与多个 Web 服务器通信，那么它可能会受到网络连接速度的限制。如果它们仅通过 100mb 网络交换机连接，那么您可能也需要考虑升级它。

【讨论】：

【解决方案6】：

WCF 服务对于这个问题将是一个非常糟糕的工程解决方案 - 当您可以使用标准 SQLServer 连接机制来确保数据正确传输时，为什么要自己制作。日志传送将按选定的时间间隔发送数据。

这样，你得到了快速的本地sql server，而数据在慢速的备份服务器中被正确的保存了。

您应该调查一下缓慢的 sql server，性能问题可能与它的负载无关，而更多地与您要求它使用的查询和索引有关。

【讨论】：

【解决方案7】：

我曾经遇到过这个问题，我们决定结合使用数据仓库（即每隔一段时间从数据库中提取数据并将其存储在单独的只读数据库中）和通过 Windows 服务进行消息队列（用于更新。）

这出奇地好，因为 MSMQ 确保可靠的消息传递（更新不会丢失），并且数据仓库确保数据在本地数据库中可用。

不过，这仍然取决于几个因素。如果您有大量数据要传输到您的 Web 应用程序，则可能需要一些时间来重建仓库，并且您可能需要考虑数据复制或事务日志传送。此外，在重建仓库并处理消息之前，更改是不可见的。

另一方面，该解决方案具有可扩展性，并且相对容易实施。（例如，您可以使用集成服务将数据拉入仓库，并使用 BL 层来处理更改。）

【讨论】：