Appearance
3 基础概念
3.1 逻辑库
逻辑库是相对物理库而言的，一般的开发人员如果要操作数据库都是直接连接具体的数据库，这里的数据库就是物理库。如果是采用LIBRA访问数据库，对开发人员来说并不用需要关注具体的物理库，LIBRA内部相当于给开发人员提供了一个数据库，这个数据库相对于物理上的真实的数据库，我们称之为逻辑库。一般在云上提供的数据库都是逻辑库，但从开发人员使用的角度来看几乎无差别。
3.2 逻辑表
3.2.1 逻辑表
既然有逻辑库，那么就会有逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表，可以是数据切分后分布在一个或多个分片库中，也可以不做数据切分，只由一个表构成。
3.2.2 分片表
分片表，指通过一定的切分规则，将数据切分到到多个数据库的表，这样，每个分片只有一部分数据，所有分片构成了完整的数据。分片表通常都是一些数据量非常大的表。 例如配置中的t_node就属于分片表，数据按照规则被分到dn1,dn2两个分片节点(dataNode)上。
xml
<table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1,dn2" rule="rule1" />3.2.3 非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。 如下配置中t_node，只存在于分片节点（dataNode）dn1上。
xml
<table name="t_node" primaryKey="vid" autoIncrement="true" dataNode="dn1" />3.2.4 ER表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，LIBRA中的ER表即是来源于此。根据这一思路，提出了基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据JOIN不会跨库操作。表分组（Table Group）是解决跨分片数据JOIN的一种很好的思路，也是数据切分规划的重要一条规则。
3.2.5 全局表
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性：
变动不频繁
数据量总体变化不大
数据规模不大，很少有超过数十万条记录。
对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以LIBRA中通过数据冗余来解决这类表的JOIN，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。数据冗余是解决跨分片数据JOIN的一种很好的思路，也是数据切分规划的另外一条重要规则。
3.4 分片节点(dataNode)
数据切分后，一个大表被分到不同的分片数据库上面，每个具体的分片在物理上就对应一个分片节点（dataNode），在分片节点中一般会定义分片跟真实的物理存储的对应关系。
3.5 节点主机(dataHost)
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）,为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（dataHost）。
3.6 分片规则(rule)
前面讲了数据切分，一个大表被分成若干个分片，就需要一定的规则，这样按照某种业务规则把数据分到某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。分片规则包含两种重要的属性：分片键 和 分片算法。通俗的讲，就是依据什么信息（分片键的值），按什么逻辑（分片算法）进行拆分。
3.7 全局序列号(sequence)
数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号（sequence）。不同的业务场景对序列号的要求也是不一样的，有些只需要保证全局唯一，有些还有顺序的要求。
3.7 示例
如下结合一些银行业务给出一些示例，以便于大家更好的理解。
3.7.1 Table概述
主要业务表
- 客户表(client)
- 帐户表(account)
- 交易流水表(tranhist)
- 机构表(organization)
- 柜员表(teller)
- 尾箱表(trailbox)
表的分类
- 客户、账户两张表构成ER表
- 账户、交易流水两张表也构成ER表
- 机构表为全局表
- 柜员、尾箱两张表为普通表
3.7.2 表结构
下面给出上述表的具体表结构（仅是示例而已），后续的一些示例也是基于这个表结构的。
3.7.2.1 机构信息表(organization)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| orgNO | VARCHAR2(20) | 机构代码 |
| OrgName | VARCHAR2(20) | 机构名 |
| OrgType | CHAR(1) | 机构类型 1核算机构2 营业机构 3 汇总机构 4 管理机构 5虚拟机构 |
| openDate | DATE | 开业日期 |
| legalPerson | VARCHAR2(20) | 法人代码 |
3.7.2.2 柜员表(teller)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| tellerNO | VARCHAR2(20) | 柜员号 |
| tellerName | VARCHAR2(20) | 柜员名 |
| orgNo | VARCHAR2(10) | 所属机构 |
| Status | CHAR(1) | 柜员状态 A-有效 D-删除 |
| tellerLevel | SMALLINT | 柜员级别 0~9 9为最高级别 |
| legalPerson | VARCHAR(20) | 法人代码 |
3.7.2.3 尾箱(trailbox)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| boxNO | VARCHAR2(20) | 尾箱代码 |
| tellerNo | VARCHAR2(20) | 使用柜员 |
| orgNo | VARCHAR2(20) | 所属机构 |
| BoxClass | CHAR(1) | 尾箱类别 C：现金尾箱； V：凭证尾箱； B：组合尾箱 默认值为B |
| BoxType | CHAR(1) | 尾箱类型 B：机构尾箱； T：柜员尾箱 |
| Status | CHAR(1) | 尾箱状态 N：未使用 Y：已使用 D：已封存 默认值为N |
| createDate | DATE | 创建日期 |
| legalPerson | VARCHAR2(20) | 法人代码 |
3.7.2.4 客户信息表(client)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| clientNO | VARCHAR2(20) | 客户号 |
| clientType | SMALLINT | 客户类型 1：个人 2：公司 3：政府 4：内部 5：金融机构 6：其他 默认1。 |
| clientName | VARCHAR2(50) | 客户名 |
| address | VARCHAR2(100) | 地址 |
| status | CHAR | 客户状态 A-活动 B-冻结 C-关闭 默认A |
| createDate | DATE | 创建日期 |
| legalPerson | VARCHAR2(20) | 法人代码 |
3.7.2.5 账户信息表(account)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| acctNO | VARCHAR2(20) | 账号 |
| clientNO | VARCHAR2(20) | 客户号 |
| acctClass | SMALLINT | 账户类别 1：一类账户 2：二类账户 3：三类账户 |
| ledgerType | CHAR(1) | 总账类型 I-内部账 N-往帐 V-来帐 |
| Balance | NUMBER | 账户余额 |
| orgNo | VARCHAR2(20) | 所属机构 |
| legalPerson | VARCHAR2(20) | 法人代码 |
3.7.2.6 交易流水表(tranhist)
| 列名 | 数据类型 | 说明 |
|---|---|---|
| seqNO | VARCHAR2(20) | 流水号 |
| acctNO | VARCHAR2(20) | 账号 |