TDDL中间件、数据库分库(垂直分区)、分表(水平分区)学习
目录
1. 引言 2. TDDL简介 3. TDDL编程
1. 引言
0x1: 为什么要进行分库、分表
在大多数系统中，数据库是系统中最不容易"scale out"的一层，一般来说，在系统的架构优化中会经过如下阶段
1. 一个从单一 DB server 对于一个刚上线的互联网项目来说，由于前期活跃用户数量并不多，并发量也相对较小 2. 到 Master / Salve(主从读写分离) 一个 Master节点对应多个 Salve 节点 1) Master: 接收Write操作请求，并将更新后的数据"复制"到Salve中 2) Salve: 接收Read操作请求，并接收来自Master的数据同步操作 3. 到垂直分区(分库) 根据业务自身的不同，将原本冗余在一个数据库内的业务表拆散，将数据分别存储在不同的数据库中，同时仍然保持 Master/Salve 模式，简单来说就是"尽量减少一个库中表的数量(如何减少要遵循业务的逻辑)" 4. 到分区(Partition) 将一个业务表拆分成多个子表，比如 user_table0 、 user_table1 、 user_table2。子表之间通过某种"契约关联"在一起，每一张子表均按段位进行数据存储，比如 user_table0 存储 1-10000 的数据，而user_table1存储
10001-20000 的数据，最后 user_table3 存储 20001-30000 的数据。经过水平分区设置后的业务表，必然能够将原本一张表维护的海量数据分配给 N 个子表进行存储和维护 5. 分表(Sharding) Shsrding是一种架构思想，它的思想是从分区的思想而来，但数据库分区基本上是数据对象级别的处理，比如表和索引的分区，每个子数据集上能够有不同的物理存储属性，还是单个数据库范围内的操作，而 Sharding 是能够跨数据库
，甚至跨越物理机器的。 需要特别注意的是，任何技术都是在合适的场合下能发挥应有的作用，Sharding 也一样 1) 联机游戏、IM、BSP都是比较适合Sharding 的应用场景。其共性是抽象出来的数据对象之间的关联数据很小 2) 在IM的场景下，每个用户如果抽象成一个数据对象，完全可以独立存储在任何一个地方，数据对象是 Share Nothing的 3) 在Blog的场景下，服务提供商的站点内容，基本为用户生成内容(UGC)，完全可以把不同的用户隔离到不同的存储集合，而对用户来说是透明的 这个"Share Nothing" 是从数据库集群中借用的概念，举例来说，有些类型的数据粒度之间就不是"Share Nothing"的，比如类似交易记录的历史表信息，如果一条记录中既包含卖家信息与买家信息，如果随着时间推移，买、卖家会
分别与其它用户继续进行交易，这样不可避免的两个买卖家的信息会分布到不同的Sharding DB上，而这时如果针对买卖家查询，就会跨越更多的Sharding，开销就会比较大
需要明白的是: sharding是一种思想，它有相对应的实现技术，spider storage engine就是实现Sharding理念的一项技术
Relevant Link:
http://blog.csdn.net/c929833623lvcha/article/details/7564747 http://qq85609655.iteye.com/blog/2035176 http://heylinux.com/archives/1004.html http://blog.csdn.net/bluishglc/article/details/6274841 http://www.chinacloud.cn/upload/2014-09/14091111146746.pdf http://like-eagle.iteye.com/blog/704629 http://blog.csdn.net/column/details/sharding.html http://blog.csdn.net/bluishglc/article/details/7970268 http://blog.csdn.net/bluishglc/article/details/6161475
0x2: 水平分区(分表 Sharding)存在的技术问题
我们知道，目前比较成熟的数据存储水平扩容方案是Sharding技术，那么在实施Sharding技术的过程中，会遇到哪些技术难点呢？
在数据库存储架构改造的过程中，Master/salve以及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如
1. 不能跨越多个分区join查询数据 2. 跨分区join查询带来的额外的网络IO负载 3. 如何平衡各个shards的负载等等
这个时候就需要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化
2. TDDL简介
淘宝根据自身业务需求研发了TDDL(Taobao Distributed Data Layer)框架，主要用于解决
1. 分库分表场景下的访问路由(持久层与数据访问层的配合) 2. 异构数据库之间的数据同步 3. 它是一个基于集中式配置的JDBC DataSource实现，具有 1) 分库分表 2) Master/Salve 3) 动态数据源配置等功能
从本质上将，TDDL是一种DAL中间件，类似的产品有
1. Hibernate Shards 2. Ibatis-Sharding 3. ..
TDDL 位于数据库和持久层之间，它直接与数据库建立交道
对数据库进行分库分表处理，应用层连接多个数据源，中间有一个叫做DBRoute的技术对数据库进行统一的路由访问。DBRoute对数据进行多库的操作、数据的整合，让应用层像操作一个数据源一样操作多个数据库。但是随着数据量的增长，对于库表的分法有了更高的要求，数据查询的中间件就要能够承担这个重任了，它对上层来说，必须像查询一个数据库一样来查询数据，还要像查询一个数据库一样快(每条查询要求在几毫秒内完成)，TDDL就承担了这样一个工作
1. 数据库主备和动态切换 2. 带权重的读写分离 3. 单线程读重试 4. 集中式数据源信息管理和动态变更 5. 剥离的稳定jboss数据源 6. 支持mysql和oracle数据库 7. 基于jdbc规范，很容易扩展支持实现jdbc 规范的数据源 8. 无server、client-jar形式存在，应用直连数据库 9. 读写次数、并发度流程控制、动态变更 10. 可分析的日志打印、日志流控、动态变更
待续
Relevant Link:
http://qq85609655.iteye.com/blog/2035176
3. TDDL编程
Copyright (c) 2014 LittleHann All rights reserved
