C# 使用分布式web服务查询多个数据库

我有一个关于最佳实践的快速问题，特别是关于以下场景的预期性能：

如果我想从包含示意图上相同的sql数据库的多个服务器查询数据，那么让每个服务器提供一个单一客户端应用程序可以使用的web方法是否是一个合适（且相对快速）的解决方案

数据只需要在客户端进行整合，在客户端，必须串行（或并行）使用多个web方法才能向客户端提供数据。每个服务器还将实现实体框架作为ORM

---

性能是我主要关心的问题，当我们开始扩展到越来越多的服务器时，性能是否会变得太慢

问题不在于性能，而在于可靠性。随着需要查询以向客户端返回响应的服务数量的增加，可靠性降低。假设您的数据库有99%的可用性（整个一年中用于维护、修补和升级的总停机时间不到4天）。如果您需要查询客户看到的5个数据库，而实际可用性仅为95%，那么您的站点每年几乎有18天会出现故障。在10个数据库中，可用性为90%（下降35天），50台服务器骤降到60%，这意味着您的站点无法使用

这就是为什么这种扩展场景中的驱动力是可靠性，这只能通过解耦数据库来实现。通常的技巧是为数据库实现一个异步消息传递总线来进行通信，并且让每个到站点的请求只在其本地碎片上连接，永远不要为每个请求查询多个数据库

有关如何在大规模情况下实现这一点的更详细解释，请参阅

---

本SIGMOD 2009主题演讲依次介绍了Facebook如何实现类似的结果：使用memcached和MySQL分区。

如果示意图上相同的数据驻留在不同的数据库中，那么您是否研究过表分区并将所有数据存储在一个数据库中？这可能会有帮助

在您当前的场景中，我建议您使用ORM/ADO.Net从不同的数据库服务器获取数据，然后在应用程序中逻辑地合并它们

---

在SQL Server 2005中，通过web服务公开数据，但我不建议因为web服务本身会给您带来性能损失，因为您正在跨越应用程序边界。

为什么不在数据库中执行此“数据库”工作？也许使用SSIS之类的东西。你是什么意思？对不起，我对这一切还比较陌生。这是数据库相互镜像/复制的地方，还是有某种“主”数据库整合了所有其他数据库？如果是这样的话，这是一个可能的解决方案，但我对这个选择很好奇。我现在必须使用有限的资源。SSIS是一个工具，它可以做一些事情，例如，将五个相同的模式数据库复制到一个目标。你关于可靠性的观点是有道理的，我想我要做的是创建一个新的数据库，以预定的时间间隔从所有其他数据库中提取数据。因为关系数据需要通过业务逻辑层，所以我认为我必须使用web服务。这不仅仅是sql数据的直接复制。