怎么理解MySQL垂直和水平切分

本文主要介绍“如何理解MySQL的纵横分割”。在日常操作中，相信很多人对于如何理解MySQL纵横分割都有疑问。边肖查阅了各种资料，整理出简单易用的操作方法，希望能帮你解答“如何理解MySQL纵横分割”的疑惑！接下来，请和边肖一起学习！

复制的限制：一旦数据库太大，尤其是写得太频繁，单个主机无法支持时，我们仍然会遇到扩展的瓶颈。数据分段(分片):通过一定的特定条件将存储在同一个数据库中的数据分散到多个数据库(主机)中，从而达到分散单个设备负载的效果。数据分段还可以提高系统的整体可用性，因为在单个设备崩溃后，只有部分整体数据不可用，而不是所有数据。

的数据分段(分片)模式

一种是根据不同的表(或Schema)将数据划分到不同的数据库(主机)中，这可以称为数据的垂直(vertical)分段；另一种是将同一表中的数据按照一定条件按照表中数据的逻辑关系拆分成多个数据库(主机)。这种分段称为数据的水平(水平)分段。

垂直分段：

一个架构设计良好的应用系统的整体功能必须由许多功能模块组成，每个功能模块所需的数据对应数据库中的一个或多个表。在架构设计中，各功能模块之间的交互点越不统一，系统的耦合度越低，系统各模块的可维护性和扩展性越好。有了这样的系统，更容易实现数据的垂直分割。

一般来说，如果是负载比较低，表关联比较频繁的系统，数据库可能会让步。将几个相关模块组合起来减少应用程序工作的方案可以减少更多的工作量，是一种可行的方案。垂直分裂的一个例子：

1.用户模块表：用户、用户配置文件、用户组、用户相册

2.小组讨论表：小组，小组消息，小组消息内容，顶级消息

3.相册相关表：照片、相册、相册关系、照片评论

4.事件信息表：事件

小组讨论模块和用户模块主要通过用户或小组关系进行关联。一般会用用户id或者nick_name和组的id进行关联，模块之间的接口不会带来太多麻烦。

相册模块仅通过用户与用户模块相关联。这两个模块之间的关联基本都有用户id关联的内容，简单明了，界面清晰。

事件模块可能与每个模块相关，但它们只关注每个模块中对象的ID信息，这也可以很容易地拆解。

垂直分割的优势

数据库拆分简单明了，拆分规则明确；

应用模块清晰，易于集成；

数据易于维护和定位；

垂直分割的缺点

部分表关联无法在数据库级别完成，需要在程序中完成；

对于访问极其频繁、数据量巨大的表，仍然存在性能瓶颈，可能达不到要求。

事务处理相对更复杂；

分割达到一定程度后，可扩展性会受到限制。

过度阅读分割可能会使系统过渡变得复杂和难以维护。

水平分割

将频繁访问的表按照某个字段的某个规则分散到多个表中，每个表都包含一些数据。

比如上面的：所有的数据都是和用户关联的，所以我们可以根据用户把不同用户的数据横向拆分到不同的数据库中。

目前互联网上非常流行的Web2.0类型网站的大部分数据都可以通过会员用户信息进行关联。也许很多核心表非常适合按成员ID水平分割数据。像论坛社区讨论系统，更容易细分，按照论坛号横向细分数据非常容易。分割后，库与库之间基本不会有交互。

水平分割的优势

表关联基本可以在数据库中完成；

不存在一些数据量很大、负载很高的表遇到瓶颈的问题；

应用端整体架构变化相对较少；

事务处理相对简单；

只要能够很好地定义分割规则，基本上很难满足可扩展性的限制；

水平分割的缺点

分割规则相对比较复杂，很难抽象出一个能满足整个数据库的分割规则。

后来数据维护的难度增加了，人工定位数据更加困难。

应用系统各模块耦合度比较高，可能会对后续数据的迁移和拆分造成一定的困难。

两种分割的组合：

一般来说，我们的数据库中的所有表很难通过一个(或几个)字段联系起来，因此很难简单地通过数据的水平分割来解决所有问题。然而，垂直分割只能解决一些问题。对于那些负载非常高的系统，即使是单个表也无法通过单个数据库主机来承受其负载。我们必须同时使用垂直和水平分割方法。

每个应用系统的负载都在逐步增加。性能瓶颈初期，大多数架构师和DBA都会选择先纵向拆分数据，因为这种成本是第一位的，最符合这一时期追求的最大投入产出比。然而，随着

业务的不断扩张，系统负载的持续增长，在系统稳定一段时期之后，经过了垂直拆分之后的数据库集群可能又再一次不堪重负，遇到了性能瓶颈。

如果我们再一次像最开始那样继续细分模块，进行数据的垂直切分，那我们可能在不久的将来，又会遇到现在所面对的同样的问题。而且随着模块的不断的细化，应用系统的架构也会越来越复杂，整个系统很可能会出现失控的局面。

这时候我们就必须要通过数据的水平切分的优势，来解决这里所遇到的问题。而且，我们完全不必要在使用数据水平切分的时候，推倒之前进行数据垂直切分的成果，而是在其基础上利用水平切分的优势来避开垂直切分的弊端，解决系统复杂性不断扩大的问题。而水平拆分的弊端（规则难以统一）也已经被之前的垂直切分解决掉了，让水平拆分可以进行的得心应手。

示例数据库:

假设在最开始，我们进行了数据的垂直切分，然而随着业务的不断增长，数据库系统遇到了瓶颈，我们选择重构数据库集群的架构。如何重构？考虑到之前已经做好了数据的垂直切分，而且模块结构清晰明确。而业务增长的势头越来越猛，即使现在进一步再次拆分模块，也坚持不了太久。

==>选择了在垂直切分的基础上再进行水平拆分。

==>在经历过垂直拆分后的各个数据库集群中的每一个都只有一个功能模块，而每个功能模块中的所有表基本上都会与某个字段进行关联。如用户模块全部都可以通过用户ID进行切分，群组讨论模块则都通过群组ID来切分，相册模块则根据相册ID来进切分，最后的事件通知信息表考虑到数据的时限性（仅仅只会访问最近某个事件段的信息），则考虑按时间来切分。

数据切分以及整合方案.

数据库中的数据在经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是如何来让这些数据源得到较好的整合，其中存在两种解决思路：

在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；
通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；

第二种方案,虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常有帮助的。针对第二种方案，可以选择的方法和思路有：

1.利用MySQLProxy 实现数据切分及整合.

可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它，目前具备的功能主要有连接路由，Query分析，Query过滤和修改，负载均衡，以及基本的HA机制等。MySQLProxy 本身并不具有上述所有的这些功能，而是提供了实现上述功能的基础。要实现这些功能，还需要通过我们自行编写LUA脚本来实现。

原理:MySQLProxy 实际上是在客户端请求与MySQLServer 之间建立了一个连接池。所有客户端请求都是发向MySQLProxy，然后经由MySQLProxy 进行相应的分析，判断出是读操作还是写操作，分发至对应的MySQLServer 上。对于多节点Slave集群，也可以起做到负载均衡的效果。

2.利用Amoeba实现数据切分及整合

Amoeba是一个基于Java开发的，专注于解决分布式数据库数据源整合Proxy程序的开源框架，Amoeba已经具有Query路由，Query过滤，读写分离，负载均衡以及HA机制等相关内容。Amoeba主要解决的以下几个问题：

数据切分后复杂数据源整合；
提供数据切分规则并降低数据切分规则给数据库带来的影响；
降低数据库与客户端的连接数；
读写分离路由；

AmoebaFor MySQL 主要是专门针对MySQL数据库的解决方案，前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说，AmoebaForMySQL 和一个MySQL数据库没有什么区别，任何使用MySQL协议的客户端请求，都可以被AmoebaFor MySQL 解析并进行相应的处理。

Proxy程序常用的功能如读写分离，负载均衡等配置都在amoeba.xml中进行。Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由，路由规则可以在rule.xml进行设置。

3.利用HiveDB实现数据切分及整合

HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架，只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题，同时支持数据的冗余及基本的HA机制。

HiveDB的实现机制与MySQLProxy 和Amoeba有一定的差异，他并不是借助MySQL的Replication功能来实现数据的冗余，而是自行实现了数据冗余机制，而其底层主要是基于HibernateShards 来实现的数据切分工作。数据切分与整合中可能存在的问题

引入分布式事务的问题?

一旦数据进行切分被分别存放在多个MySQLServer中之后，不管我们的切分规则设计的多么的完美（实际上并不存在完美的切分规则），都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer 中了。

==>将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。

跨节点Join的问题?

==>先从一个节点取出数据,然后根据这些数据,再到另一个表中取数据.
==>使用Federated存储引擎,问题是:乎如果远端的表结构发生了变更，本地的表定义信息是不会跟着发生相应变化的。

跨节点合并排序分页问题?

==>Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。但是排序分页就不太一样了，排序分页的数据源基本上可以说是一个表（或者一个结果集），本身并不存在一个顺序关系，所以在从多个数据源取数据的过程是完全可以并行的。这样，排序分页数据的取数效率我们可以做的比跨库Join更高，所以带来的性能损失相对的要更小。

到此，关于“怎么理解MySQL垂直和水平切分”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注网站，小编会继续努力为大家带来更多实用的文章！