TiDB是分布式数据库解决方案选项之一,它对外以MySQL 协议提供关系数据库存储服务,而核心是NoSQL技术实现分布式存储和分布式计算。单从对外提供兼容 MySQL服务这个角度看,可以吸引庞大的MySQL用户群来尝试使用。
基于MySQL的很多项目,目前面临的一个瓶颈是随着数据量越来越大,存储空间扩展和查询性能都面临比较大的问题。一台服务器的存储容量总归是有限的,如何能有效利用其他服务器的存储资源?还有计算资源等。
一般场景下MySQL是搭建了主从环境,这意味着写数据时必须要写到主服务器上,其他从服务器可以同步到最新的数据。这样就可以通过查询从服务器实现读写分离,大大减轻主服务器的压力。
但随着数据量不断增长,主服务器和从服务器的存储都会出现难以满足的情况,这时可能会考虑数据分区的方案把数据库分拆成多个,分别存储到不同服务器上,但这需要迁移大量数据,可能在考虑不周的情况下会多次迁移数据,这在数据量到一定规模时迁移数据耗时会很长。而且应用程序往往也要适应这种数据库分拆做改动,成本可能很高。
有没有一种解决方案能弹性扩张数据库的存储资源和计算资源,也不需要复杂的数据分区以及改动相关应用程序?
这就是Tidb 的解决方案,底层的数据存储和计算资源可以动态扩展,前端的数据访问服务是以兼容MySQL的协议开放出来,堪称完美。
据Tidb官方介绍,他们在兼容MySQL方面花了相当的精力,据说是直接用MySQL的单元测试代码来测试他们的代码,保证完美兼容。
Tidb希望满足100% OLTP数据库以及80%的OLAP数据库应用场景,期待他们能达成。
同类产品比较:
MyCat是一个数据库中间层产品,通过数据库分区技术能提供一个理论上无限扩展的大数据库,背后核心还是MySQL,可以作为过度方案。
最优使用经验:
更多资料:https://www.pingcap.com/。
近年来,随着数据量的高速增长,传统的数据也从集中走向分布式,对数据进行了分片,由此也诞生了众多优秀的分布式数据库中间件(Mycat、sharding-jdbc),使得业务数据做到了分布式。
然而TIDB从根本上解决了并实现了分布式数据库,高度兼容MySQL,不需要任何中间件,也无需改变业务开发人员已有的习惯和程序。如果你仅仅关注的是你的业务实现,也不要认为TIDB很神秘,你就把他当做一个单机版的MySQL数据库使用就行了,几乎无需修改代码。
不支持的天条
- 存储过程(如果即使支持,也不要使用存储过程,难于移植和扩展)
- 视图
- 触发器
- 自定义函数
- 外键约束
- 全文索引
- 空间索引
- 非UTF-8字符集
差异性天条
- 表上必须要有唯一索引或者主键
- 自增列(auto_increment)只确保唯一,没有顺序性概念;所以在insert的时候不要设置自增列的值
- 事务隔离级别采用的是可重复读(TIDB与MySQL和Oracle的可重复读是有区别的,TIDB的可重复读隔离机制个人觉得类似于串行化)
- Select …for update 不会给数据枷锁,只是在更新本事务提交时报错而已
- 事务大小限制
- 单条 KV entry 不超过 6MB
- KV entry 的总条数不超过 30w(官网建议值10000,但是要具体到表上的索引,根据索引数量好像是2倍关系的递减)
- KV entry 的总大小不超过 100MB
- DML语句
- 基本MySQL语句都支持,开发中只碰到格式化后的select count(1)报错
- DDL语句
- 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 的修改。
个人建议
- 索引
- 业务字段即使多个字段组合构成唯一索引时,必须建成唯一索引
- 减少join的使用,尽量在业务层面实现join,如果非要使用关联字段要求要索引
- 组合索引,数据区分度高的字段在最前面
- 语句
- 禁止使用存储过程
- 不要使用count(列),尽量使用count(1)
- Sum函数注意null
- 不得使用级联操作(TIDB也不支持)
- 不建议使用truncate
- 分批删除使用limit