一、数据处理分类
1. 海量数据处理，按照使用场景主要分为两种类型：
联机事务处理（OLTP）
面向交易的处理系统，其基本特征是原始数据可以立即传送到计算机中心进行处理，并在很短的时间内给出处理结果。简单地说，主要是对数据的插入、修改、删除，所以对事物和实时性要求比较高。
联机分析处理（OLAP）
通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。简单地说，主要是对海量数据的查询统计分析
2. OLTP和OLAP的比较
| OLTP | OLAP | |
| 系统功能 | 日常交易处理 | 统计、分析、报表 |
| DB设计 | 面向实时交易类应用 | 面向统计分析类应用 |
| 数据处理 | 当前的、最新细节的、二维的分立的 | 历史的、聚集的、多维集成的、统一的 |
| 实时性 | 实时读写要求高 | 实时读写要求低 |
| 事物 | 强一致性 | 弱事物 |
| 分析要求 | 低、简单 | 高、复杂 |
二、常用数据库分类
传统数据库：
Oracle、Mysql、SQLserver、DB2
NoSQL数据库：
临时性键值存储——Redis、Memcached
永久性键值存储——Redis、ROMA
面向文档存储——MongoDB、CouchDB
面向列存储——Cassandra、HBase
传统数据库与NoSQL数据库对比：
| 传统数据库 | NoSQL数据库 | |
| 特点 |
数据关系模型基于关系模型、结构化存储、完整性约束。 基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作。 采用结构化的查询语言（SQL）做数据读写。 操作需要数据的一致性，需要事物甚至是强一致性。 |
非结构化的存储。 基于多维关系模型。 具有特定的使用场景。 |
| 优点 |
保持数据的一致性（事物处理）。 可以进行join等复杂查询。 通用化，技术成熟。 |
高并发，大数据下读写分离能力较强。 基本支持分布式，易于扩展，可伸缩。 简单，弱结构化存储。 |
| 缺点 |
数据读写需要经过sql解析，大量数据、高并发下读写性能不足。 对数据做读写，或修改数据结构时需要加锁，影响并发操作。 无法适应非结构化存储。 扩展困难。昂贵、复杂。 |
Join等复杂操作能力较弱。 事物支持较弱。 通用性差。 无法完整约束复杂业务场景支持较差。 |
三、分库分表
1. 常规未进行分库分表的情况
2. 解决上面的这种情况的方法——分库分表
把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储于多个表上
分库分表的目的：分散单台设备的负载
3. 数据切分
分库分表的基本思想：数据切分
数据切分（Sharding）根据其切分规则的类型，可以分为两种切分模式：
垂直（纵向）切分：
将不同的表（或者Schema）拆分到不同的数据库（主机）上。
说明：这种切分方式是根据业务来切分的，比如我有2个系统，分别是订单支付系统和用户信息系统，在之前所有的表都是在一个库里面，现在做业务拆分，就把订单支付相关的表都放在订单支付的库里面，用户信息相关的表都放在用户信息的库里面
水平（横向）切分：
根据表中数据的逻辑关系，将同一张表中的数据安装某种条件拆分到多台数据库（主机）的同一表结构的表中。
说明：这种拆分方式是拆表的，简单的说，就是根据表中的某个字段对表进行拆分，比如我有一个订单表，随着年份的变化数据量越来越大，这个时候就需要根据年份来把表中的数据拆分到不同数据库（主机）的订单表里面去了
垂直（纵向）切分与水平（横向）切分的比较：
| 垂直切分 | 水平切分 | |
| 特点 |
规则简单，实施方便。 业务之间耦合度非常低，相互影响很小。 根据不同的表来进行拆分，对应用程序的影响也更小。 |
将同一个表中的不同数据拆分到不同的数据库。 对应用程序来说，表的命名比垂直拆分更复杂。 后期的数据维护也会复杂。 |
| 优点 |
系统之间的整合或扩展容易。 拆分后业务清晰，拆分规则明确。 数据维护简单。 |
拆分规则抽象好，Join操作基本可以数据库做。 不存在单库大数据和高并发性能瓶颈。 应用端改造较少。 提高了系统的稳定性跟负载能力。 |
| 缺点 |
部分业务无法join，只能通过接口方式解决，提高了系统复杂度。 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。 事务处理复杂。 |
拆分规则难以抽象。 分片事物一致性难以解决。 数据多次扩展跟维护量极大。 跨库Join性能较差。 |
4. 分库分表需要应对的技术难题
4.1 分布式全局唯一id
解决方法：
1）数据库自增：针对同一张表，在每个数据库建表的时候设置步长（step）
2）UUID/GUID
3）Redis Increment
4）MongoDB ObjectId（类似UUID的方式）
5）Zookeeper分布式锁
6）Twitter的Snowflake（又叫雪花算法）
7）Ticket Server（数据库生存方式，Flickr采用的就是这种方式）
4.2 分片规则和策略
1）分片字段的选择
2）分片规则
3）数据迁移，容量规划，扩容等
4.3 跨分片技术问题
1）跨分片的排序分页 limit 1 5
2）跨分片函数处理
3）跨分片join
4.4 跨分片事物问题
1）强一致性问题
2）弱一致性问题/最终一致性
5. 分库分表中间件有哪些
1）Cobar
Cobar是来自阿里的mysql中间件,但是现在已经很久没有更新了，它可以在分布式的环境下看上去像传统数据库一样为您提供海量数据服务
2）Sharding JDBC
当当应用框架ddframe中，从关系型数据库模块dd-rdb中分离出来的数据库水平分片框架，实现透明化数据库分库分表访问
3）TDDL
淘宝根据自身业务需求研发了TDDL（Taobao Distributed Data Layer 外号头都大了）框架，主要用于解决分库分表场景下的访问路由（持久层与数据访问层的配合）以及异构数据库之间的数据同步，它是一个基于集中式配置的JDBC DataSource实现，具有分库分表、读写分离（Master/Salve）、动态数据源配置等功能。
4）Mycat
一个开源的分布式数据库系统，实现了mysql协议的服务器。前端用户可以把它看作是一个数据库代理，用mysql客户端工具和命令行访问，而其后端可以用mysql原生协议与多个mysql服务器通信，也可以用jdbc协议与大多数主流数据库服务器通信
这几种中间件的对比：
6. mycat分库分表中间件解决分库分表过程中面对的各种技术问题
6.1 分布式全局唯一id
多种分布式全局唯一id的实现方式
6.2 分片规则和策略
多种分片规则和策略，甚至可以自定义
6.3 跨分片技术问题
多种分片规则和策略，甚至可以自定义
6.4 跨分片事物问题
单库内保证事物的完整性，跨库事物弱XA（最终一致性）
mycat其他特点：
1）可以通过mycat统一管理所有数据源，后端数据库集群对前端应用程序透明
2）独创的ER关系分片，解决ER分片难处理问题
3）采用全局分片技术，每个节点同时并发插入和更新数据，每个节点都可以读取数据
4）通过人工智能的Catlet支持分片复杂SQL实现以及存储过程支持等