MySQL扩展解决方案（复制，群集）

Question

在启动时，我正在为我们的数据库考虑扩展解决方案。MySQL至少使我感到困惑（至少对我而言），MySQL具有MySQL群集，复制和MySQL群集复制（来自5.1.6版），它是MySQL群集的异步版本。MySQL手册解释了其集群FAQ中的一些差异，但是很难确定何时使用它们中的一个。

我将不胜感激那些熟悉这些解决方案之间的区别以及优点和缺点以及何时建议使用每种解决方案的人的任何建议。

Answer 1

我一直在做很多关于可用选项的阅读。我还亲自推荐了高性能MySQL第二版。

这是我设法拼凑而成的：

聚类

一般而言，集群是将负载分布在许多服务器上，这些服务器在外部应用程序中似乎是一台服务器。

MySQL NDB集群

MySQL NDB
Cluster是一个具有同步复制和自动数据分割功能的分布式，无内存的，无共享的存储引擎（对不起，我从高性能书上借来的字面意思是，但它们放在那儿很好）。对于某些应用程序来说，这可能是一个高性能的解决方案，但是Web应用程序通常无法在其上很好地工作。

主要问题在于，除了非常简单的查询（仅涉及一个表）之外，群集通常还必须在多个节点上搜索数据，从而使网络延迟蔓延，并显着减慢查询的完成时间。由于该应用程序将群集视为一台计算机，因此无法告诉它从哪个节点获取数据。

此外，内存需求对于许多大型数据库而言并不可行。

连续红杉

这是MySQL的另一种群集解决方案，它充当MySQL服务器之上的中间件。它提供同步复制，负载平衡和故障转移。它还可以确保请求始终从最新副本中获取数据，并自动选择具有新数据的节点。

我读了一些不错的东西，总的来说，这听起来很有希望。

联邦

联合类似于集群，因此我也在这里进行了介绍。MySQL通过联合存储引擎提供联合。与NDB群集解决方案类似，它仅适用于简单查询-
但对于复杂查询，群集甚至更糟（因为网络延迟要高得多）。

复制和负载平衡

MySQL具有在不同服务器上创建数据库复制的内置功能。这可用于许多用途-在服务器之间分配负载，热备份，创建测试服务器和故障转移。

复制的基本设置涉及一台主服务器主要处理写操作，而一个或多个从服务器仅处理读操作。master-
master
配置的更高级的变化是，它允许通过同时写入多个服务器来扩展写入。

每种配置都有其优缺点，但是它们共同面临的一个问题是复制滞后-
由于MySQL复制是异步的，因此并非所有节点始终都具有最新数据。这要求应用程序了解复制，并结合复制感知查询才能按预期工作。对于某些应用程序来说，这可能不是问题，但是如果您始终需要最新的数据，事情就会变得有些复杂。

复制需要一些负载平衡以在节点之间分配负载。这可以像对应用程序代码进行某些修改一样简单，也可以使用专用的软件和硬件解决方案。

分片和分割

分片是扩展数据库解决方案的常用方法。您将数据拆分为较小的碎片，并将其散布在不同的服务器节点上。这需要应用程序知道对数据存储的修改才能有效地工作，因为它需要知道在哪里可以找到所需的信息。

有可用的抽象框架来帮助处理数据分片，例如Hibernate
Shards，它是Hibernate
ORM的扩展（不幸的是，它是Java的。我正在使用PHP）。HiveDB是另一个这样的解决方案，它也支持分片重新平衡。

其他

狮身人面像

Sphinx是全文搜索引擎，其功能远不止测试搜索。对于许多查询，它比MySQL快得多（尤其是对于分组和排序），并且可以并行查询远程系统并汇总结果-
这使其在分片中非常有用。

通常，狮身人面像应与其他扩展解决方案一起使用，以获取更多可用的硬件和基础架构。不利的一面是，您再次需要应用程序代码来了解sphinx，以便明智地使用它。

摘要

伸缩解决方案因需要它的应用程序的需求而异。对于我们和大多数Web应用程序，我相信复制（可能是多主服务器）是负载平衡器分配负载的一种方式。为了能够水平扩展，还必须对特定问题区域（巨大的表）进行分片。

我还将对Continentant Sequoia进行一下测试，看看它是否能够真正实现它所承诺的目标，因为它将对应用程序代码进行的更改最少。