高性能数据库查询

Question

我有一个.NET桌面应用程序，它由分布在加拿大各地的5000名用户使用。其中一个功能是使用我们从数据库中获得的一些参数与一些调制解调器通信。

此功能的独特之处在于：

1-它应该非常快，因为它正在与调制解调器工具通信，而这些调制解调器上有超时，而我们无法控制这一点。

2-我们从数据库中读取的信息非常大，它们具有所有调制解调器类型的参数，大约有2000个。

3-这些信息变化不是很频繁。他们可能每个月只改变一次。

处理这个问题的最佳方法是什么？

我想在应用程序启动时请求所有这些信息，并将其保存在内存中，但我对此犹豫不决，因为这可能需要时间，因为有大量的信息。

我们在工作中的标准是，无论何时我们想要与数据库通信时都有WCF服务，但我可以得到该规则的例外，但同时，如果可能的话，坚持该规则是很好的。

我的问题是，我们可以在服务器端做WCF服务缓存吗？因此，如果一个客户端请求一种调制解调器类型的数据，它将在缓存中供以后的所有请求使用？考虑到我们有多个服务器用于WCF服务，因此使用此设置的缓存将更加复杂。

WCF缓存(如果可能)是最好的答案吗？

如果我们绕过WCF直接访问数据库，我们能获得什么好处吗？

请指教，因为这是一个非常关键的问题。

Answer 1

为什么不让所有客户端都拥有自己的数据副本呢？您自己说过，它不会频繁更改。您可以将其放在轻量级数据库中，如SQLite；或XML文件中。

然后，您可以使用版本化方案。将版本号与本地数据一起存储。启动应用程序时，使用When服务向中心服务器询问最新数据的当前版本号。如果版本号不同，请下载新的数据集。

这样，如果中央SQL服务器宕机(或者网络连接丢失、延迟过高等)，您的应用程序也可以正常工作。

每当性能很关键时(例如，如果在时间范围内没有收到答复，事情就不会正常工作)，我真的会尽量避免依赖网络。

Answer 2

我要说的是，对于任何基于性能的应用程序，您需要查看通过网络传输的数据量，并在可能的情况下限制它。

对于WCF，请查看实际的请求结构，并确定是请求本身还是请求中的数据是一个限制因素。

一些建议:远离任何看起来像XML的东西。如果有必要，请使用JSON表示法，如果可能，甚至只使用简单的CSV记录格式。例如："value1"，"value2"...

如果数据不经常更改，您可以让初始请求传入它当前拥有的数据的版本号，并让服务器确定它是否具有最新版本。这可能会从根本上减少你必须发送的数据量。顺便说一句，这就是大多数缓存系统的工作方式。

Answer 3

首先，我会像你平常一样写这篇文章。我怀疑这可能根本不是什么问题--检查的唯一方法就是实现它并进行性能分析，看看这里是否真的存在性能瓶颈。我理解想要防止调制解调器挂起，但调制解调器设备上的超时不是令人难以置信的短，而且通常是可配置的，以使更长。

我们从数据库中读取的信息非常大，它们具有适用于所有调制解调器类型的参数，大约有2000个。

2000个调制解调器的调制解调器参数看起来不像是一个巨大的信息量--最多，我预计这是几兆字节的数据。如果是这种情况，请将其加载到服务器上的内存中，以使WCF服务更快。

也就是说，如果客户端知道他们将使用的调制解调器的类型，那么他们总是可以在第一次使用这些调制解调器之前，通过线路拉取这些调制解调器类型所需的信息。并不是每个客户端都会与所有2000种调制解调器类型进行接口，因此只有几种类型需要是本地的。由于这种更改不频繁，因此甚至可以将其缓存在本地应用程序存储中，从而避免了重新获取数据的需要。