Mycat中的核心概念
Mycat中的核心概念
1.数据库中间件
Mycat 是一个开源的分布式数据库系统，但是由于真正的数据库需要存储引擎，而 Mycat 并没有 存储引擎，所以并不是完全意义的分布式数据库系统。Mycat 是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。有了数据库中间件，应用只需要集中与业务处理，大量的通用的数据聚合，事务，数据源切换都由中间件来处理，中间件的性能与处理能力将直接决定应用的读写性能，所以一款好的数据库中间件至关重要。
2.逻辑库(schema)
对实际应用来说，并不需要知道中间件的存在，业务开发人员只需要知道 数据库的概念，所以数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。
3.逻辑表（table）
1）逻辑表
既然有逻辑库，那么就会有逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表，可 以是数据切分后，分布在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成。
2）分片表
分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所 有分片构成了完整的数据。 例如在 mycat 配置中的 t_node 就属于分片表，数据按照规则被分到 dn1,dn2 两个分片节点(dataNode) 上。 <table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1,dn2" rule="rule1" />
3）非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那 些不需要进行数据切分的表。 如下配置中 t_node，只存在于分片节点（dataNode）dn1 上。 <table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1" />
4）ER 表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关 系，Mycat 中的 ER 表即是来源于此。根据这一思路，提出了基于 E-R 关系的数据分片策略，子表的记录与所关 联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据 Join 不会跨 库操作。 表分组（Table Group）是解决跨分片数据 join 的一种很好的思路，也是数据切分规划的重要一条规则。
5）全局表
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特 性： • 变动不频繁 • 数据量总体变化不大 • 数据规模不大，很少有超过数十万条记录。 对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关 联，就成了比较棘手的问题，所以 Mycat 中通过数据冗余来解决这类表的 join，即所有的分片都有一份数据的拷 贝，所有将字典表或者符合字典表特性的一些表定义为全局表。 数据冗余是解决跨分片数据 join 的一种很好的思路，也是数据切分规划的另外一条重要规则。
4.分片节点(dataNode)
数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点 （dataNode）。
5.节点主机(dataHost)
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库， 这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）,为了规避单节点主机并发数限 制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（dataHost）。
6.分片规则(rule)
前面讲了数据切分，一个大表被分成若干个分片表，就需要一定的规则，这样按照某种业务规则把数据分到 某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。
7.全局序列号(sequence)
数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据 唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号（sequence）。
8.多租户
多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的 系统或程序组件，并且仍可确保各用户间数据的隔离性。在云计算时代，多租户技术在共用的数据中心以单一系 统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云 计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。 多租户在数据存储上存在三种主要的方案
1)独立数据库
这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。 优点： 为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求； 如果出现故障，恢复数据比较简单。 缺点： 增大了数据库的安装数量，随之带来维护成本和购置成本的增加。 这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对 的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品 走低价路线，这种方案一般对运营商来说是无法承受的。
2)共享数据库，隔离数据架构
这是第二种方案，即多个或所有租户共享 Database，但是每个租户一个 Schema。 优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。 缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据； 如果需要跨租户统计数据，存在一定困难。
3)共享数据库，共享数据架构
这是第三种方案，即租户共享同一个 Database、同一个 Schema，但在表中通过 TenantID 区分租户的数 据。这是共享程度最高、隔离级别最低的模式。 优点： 三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。 缺点： 隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量； 数据备份和恢复最困难，需要逐表逐条备份和还原。 如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最 适合。
三月 30, 2017. Created by XMind