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

Question

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

在该方案中,存在一组服务器节点.一个节点运行查询负载均衡器(让我们称之为A),其余节点运行典型的dbms,让我们统一调用这些节点N.

每个N都与其他N断开连接.即,N中的节点不需要与任何其他节点通信.每个N只与A连接.

这个过程就像这样

• 所有数据库查询都通过A传递.(我们假设现在A具有无限的吞吐量和处理能力)
• 甲检查每个查询(Q),并且确定它是否是一个将来自数据库或将写入到数据库的查询读的操作.(在sql中,read将是select和write将被更新)
• 如果Q是读操作,则将其转发到N中的一个节点
• 如果Q是写操作,则将其转发到N中的所有节点

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

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

关于这个想法的几个问题

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

Answer 1

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

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