开源分布式 NewSQL数据库TiDB简介

一、TiDB 简介

• SQL支持 （TiDB 是 MySQL 兼容的）
• 水平线性弹性扩展
• 分布式事务
• 跨数据中心数据强一致性保证
• 故障自恢复的高可用

---

---

不支持的特性

• • 但是不做任何事情（pass through）。
  • 不支持对enum类型的列进行修改
  • 存储过程
  • 视图
  • 触发器
  • 自定义函数
  • 外键约束
  • 全文索引
  • 空间索引
  • 非 UTF8 字符集

DDL

• • • Create Database
    • Drop Database
    • Create Table
    • Drop Table
    • Add Index
    • Drop Index
    • Add Column
    • Drop Column
    • Alter Column
    • Change Column
    • Modify Column
    • Truncate Table
    • Rename Table
    • Create Table Like

• • Add/Drop primary key 操作目前不支持。
  • Add Index/Column 操作不支持同时创建多个索引或列。
  • Drop Column 操作不支持删除的列为主键列或索引列。
  • Add Column 操作不支持同时将新添加的列设为主键或唯一索引，也不支持将此列设成 auto_increment 属性。
  • Change/Modify Column 操作目前支持部分语法，细节如下：
    • 在修改类型方面，只支持整数类型之间修改，字符串类型之间修改和 Blob 类型之间的修改，且只能使原类型长度变长。此外，不能改变列的 unsigned/charset/collate 属性。这里的类型分类如下：
      • 具体支持的整型类型有：TinyInt，SmallInt，MediumInt，Int，BigInt。
      • 具体支持的字符串类型有：Char，Varchar，Text，TinyText，MediumText，LongText。
      • 具体支持的 Blob 类型有：Blob，TinyBlob，MediumBlob，LongBlob。
    • 在修改类型定义方面，支持的包括 default value，comment，null，not null 和 OnUpdate，但是不支持从 null 到 not null 的修改。
    • 支持 LOCK [=] {DEFAULT|NONE|SHARED|EXCLUSIVE} 语法，

---

四、事务

Load data

• 语法：
  LOAD DATA LOCAL INFILE 'file_name' INTO TABLE table_name
  {FIELDS | COLUMNS} TERMINATED BY 'string' ENCLOSED BY 'char' ESCAPED BY 'char'
  LINES STARTING BY 'string' TERMINATED BY 'string'
  (col_name ...);

  其中 ESCAPED BY 目前只支持 ‘//‘。

• 事务的处理：
  TiDB 在执行 load data 时，默认每 2 万行记录作为一个事务进行持久化存储。如果一次 load data 操作插入的数据超过 2 万行，那么会分为多个事务进行提交。如果某个事务出错，这个事务会提交失败，但它前面的事务仍然会提交成功，在这种情况下一次 load data 操作会有部分数据插入成功，部分数据插入失败。而 MySQL 中会将一次 load data 操作视为一个事务，如果其中发生失败情况，将会导致整个 load data 操作失败。

---

功能说明

---

• 首先，系统既要满足 OLAP 还要满足 OLTP 的基本需求；
• 其次，新系统要尽量降低业务的使用要求；
• 最后，新系统最好能够与现有的 Hadoop 体系相结合。

• 数据体量大，增速快，存储系统需要能够灵活的水平扩展；
• 有复杂查询，BI 方面的需求，可以根据索引，例如城市、渠道等，进行实时统计；
• 数据存储要具备高可用、高可运维性，实现自动故障转移。

去哪儿数据存储方案现状

8、万达网络

1. 风控相关业务数据实时入库
2. 实时风控规则计算
3. 通过 BI 工具分析风控历史数据
4. ETL 入库到 Hadoop 数据仓库
5. 应用开发侧需要兼容 MySQL，降低应用改造门槛

• 基于 MySQL 主从复制方式的高可用方案，容易出现诸如接入层脑裂和数据不一致的风险。
• 基于 MySQL Proxy 中间件的方案，缺少对分库分表后的跨库跨表的分布式事务支持以及对复杂JOIN 的良好支持，因此也无法满足业务上风控规则实时计算和复杂查询的需求以及对业务团队的 BI 需求的支持。
• 基于 MySQL Proxy 中间件的方案需要业务代码的开发妥协，需要显式设计和指定分库分表的切分规则和路由配置，开发改造和运维成本显著增高。
• 在实时风控平台的高并发高性能的对外服务过程中，在线灵活扩容的相关工作在 MySQL Proxy 中间件架构中无法高效和可靠的实施。

1. 借助 TiDB 的分布式计算和存储引擎，集群对外服务的处理能力大大增强，高并发实时的风控规则计算能够轻松的处理完，相比较原来的 MySQL Galera Cluster 方案，单位处理性能提升了数倍。并且数据库集群获得了线性提升和扩展的能力。
2. 集群整体 QPS（万级起）和 Latency (毫秒级) 对风控的实时性要求做出了技术保证。
3. 无需考虑分库分表，对业务应用透明无侵入，应用开发和维护变得直观且简单。业务相关数据量规模和请求即便高速增长，也无需担心应用的复杂调整和运维的风险。
4. TiDB 针对分布式事务和强一致性的完善设计以及对各种 JOIN 模式的支持，使得实时风控类和 BI 分析类的业务应用能够高效运行。