前言
mycat是开源的分布式数据库系统，但实际上，按我的理解，只是一个类似于jdbc的数据库管理中间件。通过mycat可以进行增删改查，但是由于本身还未完善，数据库中小部分比较复杂的语句，到目前的1.6版本都还没有实现。
对于mycat，有人对于官网，那是又爱又恨，总的来说，我认为官网所提供的文档，在前面的前两章，关于架构部分，还是说得很不错的，但是文档中对于实际操作和运行却是模糊不已，而且错字颇多。
也是为了自身的学习所需要，所以做了本博文。虽然有大部分是依据官网来，但是具体操作部分，的确是我真心实意所做。博客大多数以官网文档整理为主。
mycat概述
1.从定义和分类来看，它是一个开源的分布式数据库系统，是一个实现了MySQL 协议的Server。
前端用户可以把它看作是一个数据库代理，用MySQL 客户端工具和命令行访问，而其后端可以用MySQL 原生（Native）协议与多个MySQL 服务器通信，也可以用JDBC 协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N 个小表，存储在后端MySQL 服务器里或者其他数据库里。
2.从最终用户看，无论是那种存储方式，在Mycat 里，都是一个传统的数据库表，支持标准的SQL 语句进行数据的操作。
对前端业务系统来说，可以大幅降低开发难度，提升开发速度，在测试阶段，可以将一个表定义为任何一种Mycat 支持的存储方式，比如MySQL 的MyASIM表、内存表、或者MongoDB、LevelDB 以及号称是世界上最快的内存数据库MemSQL 上。
3.对于DBA 来说，Mycat 就是MySQL Server，而Mycat 后面连接的MySQL Server，就好象是MySQL 的存储引擎。
如InnoDB，MyISAM等，因此，Mycat 本身并不存储数据，数据是在后端的MySQL 上存储的，因此数据可靠性以及事务等都是MySQL 保证的，简单的说，Mycat 就是MySQL 最佳伴侣，它在一定程度上让MySQL 拥有了能跟Oracle PK 的能力。
备注：Database Administrator，简称DBA，数据库管理员
4.对于软件工程师来说,Mycat 就是一个近似等于MySQL 的数据库服务器，你可以用连接MySQL 的方式去连接Mycat（除了端口不同，默认的Mycat 端口是8066 而非MySQL 的3306，因此需要在连接字符串上增加端口信息）
大多数情况下，可以用你熟悉的对象映射框架使用Mycat，但建议对于分片表，尽量使用基础的SQL 语句，因为这样能达到最佳性能，特别是几千万甚至几百亿条记录的情况下。
5.对于架构师来说,Mycat 是一个强大的数据库中间件，不仅仅可以用作读写分离、以及分表分库、容灾备份，而且可以用于多租户应用开发、云平台基础设施、让你的架构具备很强的适应性和灵活性，借助于即将发布的Mycat 智能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表映射到不同存储引擎上，而整个应用的代码一行也不用改变
官网总结mycat如下：
- 彻底开源的，面向企业应用开发的大数据库集群
- 支持事务、ACID、可以替代MySQL的加强版数据库
- 可为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
- 内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
- 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
- 新颖的数据库中间件产品
数据库切分概述
OLTP 和OLAP
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
两者的区分，以表格来说明：
| OLTP | OLAP | |
|---|---|---|
| 英文名 | On-Line Transaction Processing | On-Line Analytical Processing |
| 描述 | 也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。 | 通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。 |
| 系统功能 | 日常交易处理 | 统计、分析、报表 |
| DB 设计 | 面向实时交易类应用 | 面向统计分析类应用 |
| 数据处理 | 当前的, 最新的细节的, 二维的分立的 | 历史的, 聚集的, 多维的集成的, 统一的 |
| 实时性 | 实时读写要求高 | 实时读写要求低 |
| 事务 | 强一致性 | 弱事务 |
| 分析要求 | 低、简单 | 高、复杂 |
关系型数据库和Nosql数据库
针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与NoSQL 数据库。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的oracle、DB2、MS SQL Server 和mysql 都属于这类传统数据库。
NoSQL 数据库，全称为Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种NoSQL 都有其特有的使用场景及优点。
优缺点比较
| 关系型数据库 | NoSQL 数据库 | |
|---|---|---|
| 特点 | -数据关系模型基于关系模型，结构化存储，完整性约束。 -基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作。 -采用结构化的查询语言（SQL）做数据读写。 -操作需要数据的一致性，需要事务甚至是强一致性。 |
-非结构化的存储。 -基于多维关系模型。 -具有特有的使用场景。 |
| 优点 | -保持数据的一致性（事务处理） - 可以进行join等复杂查询。 - 通用化，技术成熟。 |
-高并发，大数据下读写能力较强。 - 基本支持分布式，易于扩展，可伸缩。 - 简单，弱结构化存储。 |
| 缺点 | -数据读写必须经过sql 解析，大量数据、高并发下读写性能不足。 - 对数据做读写，或修改数据结构时需要加锁，影响并发操作。 - 无法适应非结构化存储。 - 扩展困难。 - 昂贵、复杂。 |
-join 等复杂操作能力较弱。 - 事务支持较弱。 - 通用性差。 - 无完整约束复杂业务场景支持较差。 |
虽然在云计算时代，传统数据库存在着先天性的弊端，但是NoSQL 数据库又无法将其替代，NoSQL 只能作为传统数据的补充而不能将其替代，所以规避传统数据库的缺点是目前大数据时代必须要解决的问题。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷，但是由于目前开源或者商用的传统数据库基本不支持大规模自动扩展，所以就需要借助第三方来做处理，那就是数据切分，下面就来分析一下如何进行数据切分。
数据切分
概念
通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式，数据的垂直（纵向）切分和数据的水平（横向）切分。
数据的垂直（纵向）切分
按照不同的表（或者Schema）来切分到不同的数据库（主机）之上。
最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面。
如下所示：
系统被切分成了，用户，订单交易，支付几个模块。
以此，可以将这几个模块分到不同的库，或不同的主机上。
一个架构设计较好的应用系统，其总体功能肯定是由很多个功能模块所组成的，而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。
但是往往系统之有些表难以做到完全的独立，存在这扩库join 的情况，对于这类的表，就需要去做平衡，是数据库让步业务，共用一个数据源，还是分成多个库，业务之间通过接口来做调用。在系统初期，数据量比较少，或者资源有限的情况下，会选择共用数据源，但是当数据发展到了一定的规模，负载很大的情况，就需要必须去做分割。
一般来讲业务存在着复杂join 的场景是难以切分的，往往业务独立的易于切分。如何切分，切分到何种程度是考验技术架构的一个难题。
优点
- 拆分后业务清晰，拆分规则明确。
- 系统之间整合或扩展容易。
- 数据维护简单
缺点
- 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
- 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
- 事务处理复杂。
垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以就需要水平拆分来做解决。
数据的水平（横向）切分
根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面。
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，如图：
至于按照什么样的规则拆分，就看自己业务的设计
拆分数据就需要定义分片规则。关系型数据库是行列的二维模型，拆分的第一原则是找到拆分维度。
例子
从会员的角度来分析，商户订单交易类系统中查询会员某天某月某个订单，那么就需要按照会员结合日期来拆分，不同的数据按照会员ID 做分组，这样所有的数据查询join 都会在单库内解决；
如果从商户的角度来讲，要查询某个商家某天所有的订单数，就需要按照商户ID 做拆分；但是如果系统既想按会员拆分，又想按商家数据，则会有一定的困难。如何找到合适的分片规则需要综合考虑衡量。
切分原则都是根据业务找到适合的切分规则分散到不同的库，下面用用户ID 求模举例：
优点
- 拆分规则抽象好，join 操作基本可以数据库做。
- 不存在单库大数据，高并发的性能瓶颈。
- 应用端改造较少。
- 提高了系统的稳定性跟负载能力。
缺点
- 拆分规则难以抽象。
- 分片事务一致性难以解决。
- 数据多次扩展难度跟维护量极大。
跨库join 性能较差。
数据切分四原则
第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库Join 的可能。
第四原则：由于数据库中间件对数据Join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量 少使用多表Join。
Mycat中概念
数据库中间件
Mycat 是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。
由于前面讲的对数据进行分片处理之后，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成了整个完整的数据库存储。
如上图所表示，数据被分到多个分片数据库后，应用如果需要读取数据，就要需要处理多个数据源的数据。如果没有数据库中间件，那么应用将直接面对分片集群，数据源切换、事务处理、数据聚合都需要应用直接处理，原本该是专注于业务的应用，将会花大量的工作来处理分片后的问题，最重要的是每个应用处理将是完全的重复造轮子。
所以有了数据库中间件，应用只需要集中与业务处理，大量的通用的数据聚合，事务，数据源切换都由中间件来处理，中间件的性能与处理能力将直接决定应用的读写性能，所以一款好的数据库中间件至关重要。
逻辑库（schema）
数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。
在云计算时代，数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个独立或者是共享的物理库，常见的如阿里云数据库服务器RDS。
逻辑表（table）
对应用来说，读写数据的表就是逻辑表
逻辑表分四类：分片表、非分片表、全局表、ER 表。
分片表
数据表切分后的一个部分(原表的一个真子集)
分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。
非分片表
没有分片的表，就是非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。
E-R表
保留了实体关系特性的表，就是ER表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat 中的ER 表即是来源于此。根据这一思路，提出了基于E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据Join 不会跨库操作。
表分组（Table Group）是解决跨分片数据join 的一种很好的思路，也是数据切分规划的重要一条规则。
全局表
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性：
- 变动不频繁
- 数据量总体变化不大
数据规模不大，很少有超过数十万条记录。
对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以Mycat 中通过数据冗余来解决这类表的join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。
数据冗余是解决跨分片数据join 的一种很好的思路，也是数据切分规划的另外一条重要规则。
分片节点(dataNode)
每个表分片所在的数据库就是分片节点
数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点（dataNode）。
节点主机(dataHost)
分片节点所在的服务器就是节点主机
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）
为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（dataHost）。
分片规则(rule)
分片规则就是切分数据的规则
一个大表被分成若干个分片表，就需要一定的规则，这样按照某种业务规则把数据分到某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度.
全局序列号(sequence)
保证数据全局唯一性标识的外部机制就是全局序列号
数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号（sequence）。
单机(单实例)环境下的主键约束在分布式环境中将失效，因此得通过外部机制以全局视角来保证数据唯一性
多租户
多租户技术也叫多重租凭技术，就是在确保用户间数据隔离的前提下实现在多用户环境中共用相同系统或程序等软硬件资源的一种软件架构技术。
多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。在云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。
web 中广范使用的 VirtualHost 就是一种典型的多租户技术，多租户技术是为了更充分的使用到现有资源，同时不失权限控制的一种技术。
- 独立数据库
- 共享数据库，隔离数据架构
- 共享数据库，共享数据架构
隔离级别越来越低，共享程度越来越高，均摊成本越来越低
总结
我的目的是为了学习去应用，为了去粗取精，所以将大部分的内容都从官网去掉了。
本文的主要目的是为了让看的人了解一下切分的两种切分，这两种切分，垂直切分，我们可以看做是业务切分。水平切分，可以看做大表分库（按字段的不同值分到不同库中）。而mycat1.6还没有自主实现库内分表，根据官网描述，库内分表的实现由mysql的从5.5版本以后去支持。所以1.6版本的mycat并不支持。
总的来说，mycat按我个人理解，是一个类似于jdbc的访问后端数据库的工具，唯一的好处就是进行分片处理，使得在搜索查询上的效率提高，对于百万级以及千万级的数据的查询来说，比只用传统的jdbc的单表查询方式高效得多。
或许我们可以这样想想，你要找一个住在亚洲的中国的广西柳州的一个名叫tqw的人。如果你按照全世界的一张大大的表，一个一个的找，找到才返回，你要从70亿的人口的表中去找，查询的基数据过大，效率必然很低。而mycat就相当于一个文件夹，帮你把同样区域的划分在一个区域内。你要找这个人吧，你先去亚洲的那个文件夹，里面还有一些文件夹，你取出中国的文件夹，同理从中国文件夹中选择出广西的文件夹。然后从柳州的文件夹中去查这个人。这样的话，你只要查的就那么一点区域，你试想，从亿级的级别查询和从万级的数据查询，谁能找到得快。
下一次mycat文章，将教如何搭建mycat的windows环境或linux环境。