1. OLTP和OLAP
对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
（1）OLTP
联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
（2）OLAP
联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
2. 关系型数据库和NOSQL数据库
（1）关系型数据库
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的 oracle、DB2、MS SQL Server 和 mysql 都属于这类传统数据库。
（2）NoSQL 数据库
NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。
3. 数据切分
指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）
上面，以达到分散单台设备负载的效果。
（1）垂直切分
根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的垂直（纵向）切分。
优点：
• 拆分后业务清晰，拆分规则明确；
• 系统之间整合或扩展容易；
• 数据维护简单。
缺点：
• 部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度；
• 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高；
• 事务处理复杂
（2）水平切分
按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的水平（横向）切分
几种典型的分片规则包括：
• 按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；
• 按照日期，将不同月甚至日的数据分散到不同的库中；
• 按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中
优点：
• 拆分规则抽象好，join 操作基本可以数据库做；
• 不存在单库大数据，高并发的性能瓶颈；
• 应用端改造较少；
• 提高了系统的稳定性跟负载能力。
缺点：
• 拆分规则难以抽象；
• 分片事务一致性难以解决；
• 数据多次扩展难度跟维护量极大；
• 跨库 join 性能较差。
但共同的特点缺点有：
• 引入分布式事务的问题；
• 跨节点 Join 的问题；
• 跨节点合并排序分页问题；
• 多数据源管理问题。
针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，
在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
4. MyCat是什么
(1)一个强大的数据库中间件。介于数据库与应用之间，进行数据处理与交互的中间服务。(2)支持用MySQL客户端工具和命令访问。
(3)支持用MySQL原生协议与多个MySQL服务器通信。
(4)用JDBC协议与大多数主流数据库服务器如MySQL、SQL Server、Oracle、DB2、PostgreSQL、MongoDB等通信。
(5)用作读写分离、分库分表、容灾备份、多租户应用开发等场景。
(6)适合1000亿条以下的单表规模。
5. MyCat的表
（1）逻辑表
读写数据的表就是逻辑表。
（2）分片表
是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。
（3）非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表
（4）ER表
子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据 Join 不会跨库操作。
（5）全局表
所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。 字典表具有以下几个特性：
• 变动不频繁；
• 数据量总体变化不大；
• 数据规模不大，很少有超过数十万条记录。
6. 多租户解决方案
数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个
独立或者是共享的物理库，常见的如阿里云数据库服务器 RDS。
（1）独立数据库
一个租户一个数据库，用户数据隔离级别最高，安全性最好，但成本也高。
优点：为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
缺点：增大了数据库的安装数量，随之带来维护成本和购置成本的增加。
（2）共享数据库，隔离数据架构
即多个或所有租户共享 Database，但是每个租户一个 Schema。
优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。
缺点：如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；如果需要跨租户统计数据，存在一定困难。
（3）共享数据库，共享数据架构
即租户共享同一个 Database、同一个 Schema，但在表中通过 TenantID 区分租户的数据。
这是共享程度最高、隔离级别最低的模式。
优点：三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；数据备份和恢复最困难，需要逐表逐条备份和还原；如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
7. 分片join
（1）全局表
字典表具有以下几个特性：
• 变动不频繁
• 数据量总体变化不大
• 数据规模不大，很少有超过数十万条记录。
，全局表具有以下特性：
• 全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
• 全局表的查询操作，只从一个节点获取
• 全局表可以跟任何一个表进行 JOIN 操作
（2）ER Join
基于 E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分
片上。customer 采用 sharding-by-intfile 这个分片策略，分片在 dn1,dn2 上，orders 依赖父表进行分片，两个表的关联关系为 orders.customer_id=customer.id。于是数据分片和存储的示意图如下：
分片 Dn1 上的的 customer 与 Dn1 上的 orders 就可以进行局部的 JOIN 联合，Dn2 上也如此，再合并两个节点的数据即可完成整体的 JOIN。
（3）Share join
ShareJoin 是一个简单的跨分片 Join,基于 HBT 的方式实现。目前支持 2 个表的 join,原理就是解析 SQL 语句，拆分成单表的 SQL 语句执行，然后把各个节点的数据汇集。
（4）Spark/Storm Join
mycat 调用 spark,storm的 api,把数据传送到 spark,storm，在 spark,storm 进行 join,在把数据传回 mycat,mycat 在返回给客户端。
8. 全局***
全局sequence保证自增主键的全局唯一。
(1)本地文件方式
缺点：当 MyCAT 重新发布后，配置文件中的 sequence 会恢复到初始值。
优点：本地加载，读取速度较快。
(2)数据库方式
在数据库中建立一张表，存放 sequence 名称(name)，sequence 当前值(current_value)，步长(incrementint 类型每次读取多少个 sequence，假设为 K)等信息；
(3) 本地时间戳方式
ID= 64 位二进制 (42(毫秒)+5(机器 ID)+5(业务编码)+12(重复累加)
换算成十进制为 18 位数的 long 类型，每毫秒可以并发 12 位二进制的累加。
(4)分布式 ZK ID 生成器
9. 分片规则
（1）分片枚举 sharding-by-intfile
通过在配置文件中配置可能的枚举 id，自己配置分片固定分片 hash 算法 。
（2）固定分片hash算法func1
类似于十进制的求模运算，区别在于是二进制的操作,是取 id 的二进制低 10 位，即 id 二进制&1111111111。此算法的优点在于如果按照 10 进制取模运算，在连续插入 1-10 时候 1-10 会被分到 1-10 个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度
（3）范围约定 rang-long
提前规划好分片字段某个范围属于哪个分片
（4）取模 mod-long
对分片字段求摸运算。
（5）按日期（天）分片sharding-by-date
（6）取模范围约束 sharding-by-pattern
此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布。
（7）截取数字做 hash 求模范围约束 sharding-by-prefixpattern
此规则支持数据符号字母取模。
（8）应用指定sharding-by-substring
此规则是在运行阶段有应用自主决定路由到那个分片。
（9）截取数字hash 解析sharding-by-stringhash
截取字符串中的 int 数值 hash 分片。
（10）一致性 hash sharding-by-murmur
一致性 hash 预算有效解决了分布式数据的扩容问题。
（11）按单月小时拆分 sharding-by-hour
此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多 24 个分片，最少 1 个分片，一个月完后下月从头开始循环
（12）范围求模分片 auto-sharding-rang-mod
先进行范围分片计算出分片组，组内再求模。优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题。综合了范围分片和求模分片的优点，分片组内使用求模可以保证组内数据比较均匀，分片组之间是范围分片可以兼顾范围查询。最好事先规划好分片的数量，数据扩容时按分片组扩容，则原有分片组的数据不需要迁移。由于分片组内数据比较均匀，所以分片组内可以避免热点数据问题。
（13）日期范围 hash 分片 range-date-hash
思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成 hash 方法。先根据日期分组，再根据时间 hash 使得短期内数据分布的更均匀。优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题。要求日期格式尽量精确些，不然达不到局部均匀的目的
（14）冷热数据分片 sharding-by-hotdate
根据日期查询日志数据 冷热数据分布 ，最近 n 个月的到实时交易库查询，超过 n 个月的按照 m 天分片。
（15）自然月分片 sharding-by-month
按月份列分区 ，每个自然月一个分片