在我正在工作的初创公司,我们正在考虑为我们的数据库扩展解决方案.事情变得有些令人困惑(至少对我来说)与MySQL,它有MySQL集群,复制和MySQL集群复制(来自版本5.1.6),这是MySQL集群的异步版本.MySQL手册解释了其群集常见问题解答中的一些差异,但很难确定何时使用其中一个.
我很感激那些熟悉这些解决方案之间的差异以及优缺点的人的建议,以及何时建议使用每个解决方案.
我一直在阅读有关可用选项的大量内容.我也得到了高性能MySQL第二版,我强烈推荐.
这就是我设法拼凑的东西:
一般意义上的群集是将许多服务器上的负载分配给外部应用程序作为一个服务器.
MySQL NDB Cluster是一个分布式,内存中,无共享的存储引擎,具有同步复制和自动数据分配功能(请原谅我从高性能书中借用它,但是他们非常好地说明了这一点).它可以是某些应用程序的高性能解决方案,但Web应用程序通常不能很好地工作.
主要问题是,除了非常简单的查询(只触及一个表)之外,群集通常必须在多个节点上搜索数据,从而允许网络延迟进入并显着减慢查询的完成时间.由于应用程序将群集视为一台计算机,因此无法告诉它从哪个节点获取数据.
此外,内存中的要求对许多大型数据库都不可行.
这是MySQL的另一个集群解决方案,它充当MySQL服务器之上的中间件.它提供同步复制,负载平衡和故障转移.它还确保请求始终从最新副本获取数据,自动选择具有最新数据的节点.
我已经阅读了一些有关它的好东西,总的来说听起来非常有前景.
联合类似于聚类,所以我也在这里拉扯它.MySQL通过联合存储引擎提供联合.与NDB集群解决方案类似,它仅适用于简单查询 - 但更糟糕的是复杂的集群(因为网络延迟要高得多).
MySQL具有内置的能力,可以在不同的服务器上创建数据库的复制.这可用于许多事情 - 在服务器之间分配负载,热备份,创建测试服务器和故障转移.
复制的基本设置涉及一个主服务器主要处理写操作,一个或多个从服务器只处理读操作.更高级的变体是主 - 主配置,它允许通过让多个服务器同时写入来扩展写入.
每种配置都有它的优点和缺点,但它们共享的一个问题是复制滞后 - 因为MySQL复制是异步的,并非所有节点都始终拥有最新的数据.这要求应用程序了解复制并合并复制感知查询以按预期工作.对于某些应用程序,这可能不是问题,但如果您总是需要最新鲜的数据,那么事情会变得有些复杂.
复制需要一些负载平衡来分割节点之间的负载.这可以像对应用程序代码的一些修改或使用专用软件和硬件解决方案一样简单.
分片是用于扩展数据库解决方案的常用方法.您将数据拆分为较小的分片,并将它们分布在不同的服务器节点上.这要求应用程序了解对数据存储的修改以便有效地工作,因为它需要知道在哪里可以找到所需的信息.
有一些抽象框架可用于帮助处理数据分片,例如Hibernate Shards,Hibernate ORM的扩展(不幸的是在Java中.我正在使用PHP).HiveDB是另一种支持分片重新平衡的解决方案.
Sphinx是一个全文搜索引擎,可用于测试搜索.对于许多查询,它比MySQL快得多(特别是对于分组和排序),并且可以并行查询远程系统并聚合结果 - 这使得它在使用分片时非常有用.
通常,sphinx应与其他扩展解决方案一起使用,以获得更多可用的硬件和基础架构.缺点是你需要应用程序代码才能知道sphinx明智地使用它.
扩展解决方案根据需要的应用程序的需求而有所不同.对于我们和大多数Web应用程序,我认为复制(可能是多主机)是分配负载的负载均衡器的方法.特定问题区域(大表)的分割也是能够水平扩展的必要条件.
我还要给Continuent Sequoia一个镜头,看看它是否能真正做到它所承诺的,因为它将涉及对应用程序代码的最少量更改.
免责声明:我没有使用MySQL Cluster,所以我只是从我所听到的.
MySQL Cluster是一种HA(高可用性)解决方案.这很快,因为它全部都在内存中,但真正的卖点是可用性.没有单一的失败点.另一方面,通过复制,如果主机发生故障,您必须切换到副本,并且可能会有少量停机时间.(尽管DRBD解决方案是另一种具有高可用性的替代方案)
群集要求整个数据库适合内存.这意味着集群中的每台机器都需要有足够的内存来存储整个数据库.因此,这对于非常大的数据库来说不是一个可行的解决方案(或者至少它是一个非常昂贵的解决方案).
我认为除非HA非常重要(读:可能不是),否则它比它的价值更麻烦(和金钱).复制通常是更好的方法.
编辑:我忘了还提到Cluster不允许外键,范围扫描比其他引擎慢.这是一个关于MySQL Cluster的已知限制的链接
京公网安备 11010802040832号 | 京ICP备19059560号-6 