MySQL之可扩展性(七)

可扩展性

通过集群扩展

理想的扩展方案时单一逻辑数据库能够存储尽可能多的数据，处理尽可能多的查询，并如期望的那样增长。许多人的第一想法就是建立一个"集群"或者"网格"来无缝处理这些事情，这样应用就无须去做太多工作，也不需要知道数据到底存在哪台服务器上。随者云计算的流行，自动扩展——根据负载或数据大小变化动态地在集群中增加/移除服务器——变得越来越有趣。网上出现了许多被称为NoSQL的技术。许多NoSQL的支持者发表了一些奇怪且未经证实的观点，例如"关系型模型无法进行扩展"，或者"SQL无法扩展"。随者新概念的出现，也出现了一些新的术语。最近谁没有听说过最终一致性、BASE、矢量时钟，或者CAP理论呢？
但随者时间推移，理性开始主键回归。经验表名许多NoSQL数据库太过于简单，并且无法完成很多工作。同时一些基于SQL的技术开始出现——例如451集团(451 Group)的Matt Aslett所提到的NewSQL数据库。SQL和NewSQL到底有什么区别呢？NewSQL数据库中的SQL及相关技术都不应该成为问题。而可扩展性问题在关系型数据库中是一个是线上的难题，但新的实现正表现出越来越好的结果。所有的旧事物都变成新的了嘛？是，但也不是。许多关系型数据库集群的高性能涉及正在倍构建到系统的更底层，在NoSQL数据库中，特别是使用键——值存储时，这一点很明显。例如NDB Cluster并不是一个SQL数据库;它是一个可扩展的数据库，使用其原生API来控制，通常是使用NoSQL，但也可以通过在前端使用MySQL存储引擎来支持SQL。它是一个完全分布式、非共享高性能、自动分片并且不存在单点故障的事务型数据库服务器。最近几年正变得更强大、更复杂，用途也更广泛。同时，NoSQL数据库也逐渐看起来越来越像关系型数据库。有些甚至还开发了类SQL查询语言。未来典型的集群数据库可能更像是SQL和NoSQL的混合体，有多种存取机制来满足不同的使用需求。所以，我们可以从NoSQL中汲取优点，但SQL仍然会保留在集群数据库中。
和MySQL结合在一起的集群或分布式数据库技术大致包括:NDB Cluster、Clustrix、Percona XtraDB Cluster、Galera、Schooner Active Cluster、Continuent Tungsten、ScaleBase、ScaleArc、dbShards、Xeround、Akiban、VoltDB,以及GenieDB。这或多或少以MySQL为基础，或通过MySQL进行控制，或是和MySQL相关。
在开始前，需要指出，可扩展性、高可用性、事务性等是数据库系统的不同特性。许多人会感到困惑并将这些当作是相同的东西，但事实上不是。可扩展的数据库并不一定非常优秀，除非它能保证高性能，谁愿意牺牲高可用性来进行扩展呢？这些特性的组合堪称数据库的必杀技，但这很难实现。最后，除NDB Cluster外，大多数NewSQL集群产品都是比较新的事物。其他产品还没有看到足够多的生产环境部署以完全获知其优点和限制。尽管它们提到了MySQL协议或其他与MySQL相关的地方，但它们毕竟不是MySQL,所以这里仅仅稍微提一下，然后需要自己来判断它们是否适用。

1.MySQL Cluster(NDB Cluster)

MySQL Cluster是两项技术的结合:NDB数据库，以及作为SQL前端的MySQL存储引擎。NDB是一个分布式、具备容错性、非共享的数据库，提供同步复制以及节点间的数据自动分片。NDB Cluster存储引擎将SQL转换为NDB API调用，但遇到NDB不支持的操作时，就会在MySQL服务器上执行(NDB是一个键——值数据存储，无法执行类似连接或者聚合的操作)。NDB是一个非常复杂的数据库，和MySQL几乎完全不同。在适用NDB时甚至可以不需要MySQL:你可以把它作为一个独立的键——值数据库服务器。它的两点包括非常高的写入和按键查询吞吐量。NDB可以基于键的哈希自动决定哪个节点应该存储给定的数据。当通过MySQL来控制NDB时，行的主键就是键，其他的列是值。
因为它基于一些新的技术，并且集群具有容错性和分布式特性，所以管理NDB需要非常专业和特殊的技能。有许多动态变化的部分，还有类似升级集群或增加节点的操作必需正确执行以防止意外的问题。NDB是一项开源技术，但也可以从Oracle购买商业支持。商业支持中包括能够获得专门的集群管理产品Cluster Manager，可以自动执行一些枯燥且棘手的任务(Severalnines同样提供了一个集群管理产品)
MySQL Cluster正在迅速地增加越来越多地特性和功能。例如在最近的版本中，它开始支持更多类型的集群变更而无须停机操作，并且能够在数据存储的节点上执行一些特定类型的查询，以减少数据传递给MySQL层并在其中执行查询的必要性。(这个特性已由关联下推(push-down join)更名为自适应查询本地化(adaptive query localization)。)
NDB曾经相对其他MySQL存储引擎具有完全不同的性能特性，但最近的版本更加通用化了。它正在成为越来越多应用的更好的解决方案，包括游戏和移动应用。我们必须强调，NDB是一项重要的技术，能够支持全球最大的关键应用，这些应用处于极高的负载下，具有非常严苛的延迟要求以及不间断要求。举个例子，世界上任何一个通过移动电话网络呼叫的电话使用的就是NDB,并且不是临时方案——对于许多移动电话提供商而言，它是一个主要的并且非常重要的数据库。NDB需要一个快速且可靠的网络来连接节点。为了获得最好的性能，最好使用特定的高速连接设备。由于大多数情况下需要内存操作，因此服务器间需要大量的内存。那么它有什么缺点呢？复杂查询现在支持得不是很好，例如那些有很多关联和聚合得查询。所以不要指望用它来做数据仓库。NDB是一个事务型系统，但不支持MVCC，所以读操作也需要加锁，也不做任何得死锁检测。如果发生死锁，NDB就以超市返回的方式来解决。还有很多你应该知道的要点和警告，可以专门写一本书了，最好的办法就是阅读手册

2.Clustrix

Clustrix是一个分布式数据库，支持MySQL协议，所以它可以直接替代MySQL。除了协议外，它是一个全新的技术，并非建立在MySQL的基础之上，它是一个完全支持ACID，支持MVCC的事务型SQL数据库，主要用于OLTP负载场景，Clustrix在节点间进行数据分片以满足容错性，并对查询进行分发，在节点上并发执行，而不是将所有节点上取得的数据集中起来执行。集群可以在线扩展节点来处理更多的数据或负载。在某些方面Clustrix和MySQL Cluster很像；关键的不同点是，Clustrix是完全分布式执行并且缺少顶层的"代理"或者集群前端的查询协调器(query coordinator)。Clustrix本身能够理解MySQL协议，所以无须MySQL来进行协议转换。相比较而言，MySQL cluster是由三个部分组成的:MySQL、NDB集群存储引擎，以及NDB
实验评估和性能测试表明，Clustrix能够提供高性能和可扩展性。Clustrix看起来是一项比较有前景的技术

3.ScaleBase

ScaleBase是一个软件代理，处于应用和多个后端MySQL服务器之间。它会把发起的查询进行分裂，并将其分发到后端服务器并发执行，然后汇集结果返回给应用。

4.GenieDB

GenieDB最开始用于地理上分布部署的NoSQL文档存储。现在它也有一个SQL层，可以通过MySQL存储引擎进行控制。它包含了很多技术，包括本地内存缓存、消息层，以及持久化磁盘数据存储。将这些技术汇集在一起，就可以使用松散的最终一致性，让应用在本地快速执行查询，或是通过分布式集群(会增加网络延迟)来保证最新的数据视图。
通过存储引擎实现的MySQL兼容层不能提供100%的MySQL特性，但对于支持类似Joomla!WordPress，以及Drupal这样的应用已经够用了。MySQL存储引擎的用处主要是使GenieDB能够结合存储引擎获得对ACID的支持，例如InnoDB。GenieDB本身并不是ACID数据库

5.Akiban

对Akiban最好的描述应该使查询加速器。它通过存储物理数据来匹配查询模式，使得低开销的跨表关联操作成为可能。尽管类似反范式话(denormalization)，但数据层并不是冗余的，所以这和预先计算关联并存储结果的方式是不同的，关联表中元组是互相交错的，所以能够按照关联顺序进行顺序扫描。这就要求管理员确定查询模式能够从所谓的"表组(table grouping)"技术中受益，并需要为查询优化涉及表组。目前建议的系统架构是将Akiban配置为MySQL主库的备库，并用它来为可能较满的查询提供服务。加速系数是一到两个数量级。但是还没有看到生产环境部署或者相关的实验评估

向内扩展

处理不断增长的数据和负载最简单的办法是对不再需要的数据进行归档和清理，这种操作可能会带来显著的成效，具体取决于工作负载和数据特性。这种做法并不用来代替其他策略，但可以作为争取时间的短期策略，也可以作为处理大数据量的长期计划之一。在设计归档和清理策略时需要考虑到如下几点:

• 1.对应用的影响
  一个设计良好的归档系统能够在不影响事务处理的情况下，从一个高负载的OLTP服务器上移除数据。这里的关键是能高效地找到要删除的行，然后一小块一小块地移除。通常需要平衡一次归档的行数和事务的大小，以找到一个锁竞争和事务负载量的平衡。还需要设计归档任务在必要的时候让步于事务处理
• 2.要归档的行
  当知道某些数据不再使用后，就可以立刻清理或归档它们。也可以设计应用去归档那些几乎不怎么使用的数据。可以把归档的数据置于核心表父进附近通过视图来访问，或完全转移到别的服务器上
• 3.维护数据一致性
  当数据间存在联系时，会导致归档和清理工作更加复杂。一个设计良好的归档任务能够保证数据的逻辑一致性.或至少在应用需要时能够保证一致，而无须在大量事务中包含多个表。当表之间存在关系时，哪个表首先归档是个问题。在归档时需要考虑孤立行的影响。可以选择违背外键约束(可以通过执行SET FOREIGN_KEY_CHECKS=0禁止InnoDB的外键约束)或暂时把"悬空指针"(dangling pointer)记录放到一边。如果应用层认为这些相关联的表具有层次关系，那么归档的顺序也应该和它一样。例如，如果应用总是先检查订单再检查发货单，就先归档订单。应用应该看不到孤立的发货单，因此接下来就可以将返货但归档。
• 4.避免数据丢失
  如果是再服务器间归档，归档期间可能就无法做分布式事务，也有可能将数据归档到MyISAM或其他非事务型的存储引擎中。因此，为了避免数据丢失，再从源表中删除时，要保证已经在目标机器上保存。将归档数据单独写到一个文件里也是个好主意。可以将归档任务设计为能够随时关闭或重启，并且不会引起不一致或索引冲突之类的错误。
  5.解除归档(unarchiving)
  可以通过一些解除归档策略来减少归档的数据量。它可以帮助你归档那些不确定是否需要的数据，并在以后可以通过选项进行回退。如果可以设置一些检查点让系统来检查是否有需要归档的数据，那么这应该时一个很容易实现的策略。例如，要对不活跃的用户进行归档，检查点就可以设置在登录验证时。如果因为用户不存在导致登录失败，可以去检查归档数据中是否存在该用户，如果有，则从中取出来并完成登录。
  Percona Toolkit包含的工具pt-archiver能够帮助你有效地归档和清理MySQL表，但不提供解除归档功能

保持活跃数据独立

即使并不真的把老数据转移到别的服务器，许多应用也能受益于活跃书数据和非活跃数据的隔离。这有助于高效利用缓存，并为活跃和不活跃的数据使用不同的硬件或应用架构.下面列举了几种做法:

• 1.将表划分为几个部分
  分表是一个比较明智的办法，特别是整张表无法完全加载到内存时。例如，可以把users表划分为active_users和inactive_users表。你可能认为这并不需要，因为数据库本身只缓存"热"数据，但事实上这取决于存储引擎。如果用的是InnoDB，每次缓存一页，而一页能存储100个用户，但只有10%是活跃的，那么这时候InnoDB可能认为所有的页都是"热"的——因此每个"热"页的90%将被浪费掉。将其拆分成两个表可以明显改善内存利用率
• 2.MySQL分区
  MySQL5.1本身提供了对表进行分区的功能，能够帮助把最近的数据留在内存中
• 3.基于时间的数据分区。
  如果应用不断有心数据进来，一般心数据总是比旧数据更加活跃。例如，我们知道博客服务的流量大多是最近七天发表的文章和评论。更新的大部分是相同的数据集。因此这些数据被完整地保留在内存中，使用复制来保证在主库失效时有一份可用的备份。其他数据则完全可以放到别的地方去。我们也看到过这样一种设计，在两个节点的分片上存储用户数据，心数据总是进入"活跃节点"，该节点使用更大的内存和快速硬盘。另外一个节点存储旧数据，使用非常大(但比较慢)的硬盘。应用假设不会太需要旧数据。对于很多应用而言这是合理的假设，依靠10%的最新数据能够满足90%或更多的请求。可以通过动态分片来轻松实现这种策略。例如，分片目录可能定义如下:

CREATE TABLE users (
user_id int unsigned not null,
shard_new int unsigned not null,
shard_archive int unsigned not null,
archive_timestamp timestamp,
PRIMARY KEY (user_id)
);

通过一个归档脚本将旧数据从活跃节点转移到归档节点，当移动用户数据到归档节点时，更新archive_timestamp列的值。shard_new和shard_archive列记录存储数据的分片号