可扩展数据库系统，Critique要求

Question

我正在寻找为我的网站后端构建可扩展的数据库解决方案。我最近一直在阅读有关数据库设计的内容，我似乎已经开发了一个可能有用的想法。我认为这是一种使用同步数据维护n个数据库的新方法，但我可能错了。所以我要求评估这个想法并告诉我它是否疯狂。 （或者如果它已经存在并且已经实施）

在此方案中，有一组服务器节点。一个节点运行查询负载均衡器（让我们称之为 A ），其余节点运行典型的dbms，让我们统一调用这些节点 N 。

每个N都与其他N断开连接。 ie） N 中的节点不需要与任何其他节点通信。每个 N 仅与 A 建立连接。

这个过程就像这样

• 所有数据库查询都通过 A 传递。 （我们现在假设 A 具有无限的吞吐量和处理能力）
• A 检查每个查询（ Q ）并确定它是否是将从数据库或将写入数据库的查询中读取的操作。 （在sql中，读取将被选中， write 将被更新）
• 如果 Q 是读取操作，请将其转发到 N
中节点的一个 >
• 如果 Q 是 write 操作，请将其转发到 N
中节点的所有 >

假设它已正确实施，这会导致 N 中的所有节点都具有同步的数据库内容。只读数据的查询需要发送到一个节点。

这个想法似乎特别适合我，因为在我的系统中，写操作很少，不到1％。

关于这个想法的几个问题

• 从理论的角度来看，这样的计划是否有意义？
• 如果这确实有意义，是否已经实施了商业或免费解决方案？

Answer 1

许多读取的少数写入的典型设置是具有读取/写入主数据库和n个只读数的从属数据库。复制由RBDMS处理。只读查询可以在所有n个只读节点之间进行负载平衡，如果您的读/写主机暂时关闭，至少您的应用程序将能够为读取操作提供服务。您不需要中央“A”代理来确定查询是读取还是写入。发出查询的客户端应该足够聪明，知道它是在读还是写。这样你就不会在“A”服务器上出现瓶颈。

您提出的设置有明显的缺陷，如果您同时写入n个节点，如果其中一个或多个写入失败怎么办？

Answer 2

您的方案仅适用于无限可用节点。你是如何处理节点停机的？如果某个节点因任何原因而关闭并错过了更新，则会在下次询问时提供脏数据。

Answer 3

不是您问题的直接答案，但SQL Server 2008已经支持与您所描述的内容等效的内容。它被称为Peer-to-Peer Transactional Replication。我相信其他RDBMS也可以。我认为MySQL称之为主 - 主复制。