mycat配置分库分表
1.数据库切分概述
1.1 OLTP和OLAP
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处（OLAP）。
联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
对于两者的主要区别可以用下表来说明：
| OLTP |
OLAP |
|
| 系统功能 | 日常交易处理 | 统计，分析，报表 |
| DB设计 | 面向实时交易类应用 | 面向统计分析类应用 |
| 数据处理 | 当前的,最新的细节的，二维的分立的 | 历史的，聚集的，多维的集成的，统一的 |
| 实时性 | 实时读写要求高 | 实时读写要求低 |
| 事物 | 强一致性 | 弱事物 |
| 分析要求 | 低、简单 | 高、复杂 |
1.2 关系型数据库和NoSQL数据库
针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与NoSQL数据库。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的
oracle、DB2、MS SQL Server和mysql都属于这类传统数据库.
NoSQL数据库，全称为Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要
非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键
值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种NoSQL
都有其特有的使用场景及优点。
oracle，mysql等传统的关系数据库非常成熟并且已大规模商用，为什么还要用NoSQL数据库呢?主要是由于随着互联网发展，
数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单
机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的NoSQL产品，NoSQL
根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高。
下面分析下两者的特点，及优缺点：
| 关系型数据库 | NoSQL数据库 | |
| 特点 | - 数据关系模型基于关系模型，结构化存储，完整性约束。 - 基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作。 - 采用结构化的查询语言（SQL）做数据读写。 - 操作需要数据的一致性，需要事务甚至是强一致性。 |
- 非结构化的存储。 - 基于多维关系模型。 - 具有特有的使用场景。 |
| 优点 | - 保持数据的一致性（事务处理） - 可以进行join等复杂查询。 - 通用化，技术成熟。 |
- 高并发，大数据下读写能力较强。 - 基本支持分布式，易于扩展，可伸缩。 - 简单，弱结构化存储。 |
| 缺点 | - 数据读写必须经过sql解析，大量数据、高并发下读写性能不足。 - 对数据做读写，或修改数据结构时需要加锁，影响并发操作。 - 无法适应非结构化存储。 - 扩展困难。 - 昂贵、复杂。 |
- join等复杂操作能力较弱。 - 事务支持较弱。 - 通用性差。 - 无完整约束复杂业务场景支持较差 |
虽然在云计算时代，传统数据库存在着先天性的弊端，但是NoSQL数据库又无法将其替代，NoSQL只能作为传统数据的补充而不能将其替代，
所以规避传统数据库的缺点是目前大数据时代必须要解决的问题。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷，但是由
于目前开源或者商用的传统数据库基本不支持大规模自动扩展，所以就需要借助第三方来做处理，那就是本书要讲的数据切分，下面就来分析一下
如何进行数据切分。
1.3 何为数据切分？
简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载
的效果。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）
之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库
（主机）上面，这种切分称之为数据的水平（横向）切分。垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常
低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来
进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同
数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
1.3.1 垂直切分
垂直切分分为基于表的切分以及基于字段的切分；一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，
分布到不同的数据库上面，这样也就 将数据或者说压力分担到不同的库上面。 或者一个表中字段过多,可以将联系不太紧密的字段切分开来，用主
键来做联系；
下图是粘贴的一个基于字段切分的例子:
下面来分析下垂直切分的优缺点：
优点：
拆分后业务清晰，拆分规则明确。
系统之间整合或扩展容易。
数据维护简单。
缺点：
部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
事务处理复杂。
由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以就需要水平拆分来做解决。
1.3.2 水平切分
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以
将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。如图:
拆分数据就需要定义分片规则。关系型数据库是行列的二维模型，拆分的第一原则是找到拆分维度。比如：从会员的角度来分析，商户订单交易类
系统中查询会员某天某月某个订单，那么就需要按照会员结合日期来拆分，不同的数据按照会员ID做分组，这样所有的数据查询join都会在单库内解决；
如果从商户的角度来讲，要查询某个商家某天所有的订单数，就需要按照商户ID做拆分；但是如果系统既想按会员拆分，又想按商家数据，则会有一定
的困难。如何找到合适的分片规则需要综合考虑衡量。几种典型的分片规则包括：
按照用户ID求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中。
按照日期，将不同月甚至日的数据分散到不同的库中。
按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。
如图，切分原则都是根据业务找到适合的切分规则分散到不同的库，下面用用户ID求模举例：
既然数据做了拆分有优点也就优缺点。
优点有：
拆分规则抽象好，join操作基本可以数据库做。
不存在单库大数据，高并发的性能瓶颈。
应用端改造较少。
提高了系统的稳定性跟负载能力。
缺点有：
拆分规则难以抽象。
分片事务一致性难以解决。
数据多次扩展难度跟维护量极大。
跨库join性能较差。
前面讲了垂直切分跟水平切分的不同跟优缺点，会发现每种切分方式都有缺点，但共同的特点缺点有：
引入分布式事务的问题。
跨节点Join的问题。
跨节点合并排序分页问题。
多数据源管理问题。
针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据
的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候。确实，这是
一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来说，是非常有帮助的。
Mycat 通过数据切分解决传统数据库的缺陷，又有了NoSQL易于扩展的优点。通过中间代理层规避了多数据源的处理问题，对应
用完全透明，同时对数据切分后存在的问题，也做了解决方案。下面章节就分析，mycat的由来及如何进行数据切分问题。
由于数据切分后数据Join的难度在此也分享一下数据切分的经验：
第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库Join的可能。
第四原则：由于数据库中间件对数据Join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表Join。
2. 水平切分
这里做一个简单的切分配置, 128/129/130/131 4个数据库服务, 128+129为一组,其中128为写库,129为读库，130+131为一组，130写库,131读库。关于主从和读写的配置可以参考
http://www.cnblogs.com/zrlbiog/p/8041947.html
http://www.cnblogs.com/zrlbiog/p/8118775.html.
理解了切分概念之后，然后了解标签的作用就很好实现一个简单的切分了，标签的介绍可以看<mycat权威指南>,或者http://www.cnblogs.com/zrlbiog/p/8118775.html.
schema.xml
<?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat="http://org.opencloudb/"> <schema name="TD_OA" checkSQLschema="false" sqlMaxLimit="100"> <!-- auto sharding by id (long) --> <table name="user" dataNode="dn1,dn2" rule="rule2" /> </schema> <dataNode name="dn1" dataHost="dataHostName_1" database="worm" /> <dataNode name="dn2" dataHost="dataHostName_2" database="worm" /> <dataHost name="dataHostName_1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <!-- can have multi write hosts --> <writeHost host="hostM1" url="192.168.228.128:3306" user="root" password="123456"> <!-- can have multi read hosts --> <readHost host="read1" url="192.168.228.129:3306" user="root" password="123456"/> </writeHost> </dataHost> <dataHost name="dataHostName_2" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <!-- can have multi write hosts --> <writeHost host="hostM2" url="192.168.228.130:3306" user="root" password="123456"> <!-- can have multi read hosts --> <readHost host="read2" url="192.168.228.131:3306" user="root" password="123456"/> </writeHost> </dataHost> </mycat:schema>
rule.xml
<tableRule name="rule2"> <rule> <columns>user_id</columns> <algorithm>mod-long</algorithm> </rule> </tableRule>
这里配置的是mod-long 取模切分规则；配置的根据id对2取模，因此向mycat虚拟库中插入数据会分别将数据插入128以及130，虚拟表获取数据是从129以及131
如上图，10条数据,两个库各5条. 手动向131和129库中各新增新增一条数据,观察mycat虚拟表发现有这两条信息,证明是从129以及131读数据
