TiDB测试小结
最近调研了下TiDB，总体对这门基于关系型的分布式方案做了一些相对全面的测试。
首先对我来说，我觉得能够开发数据库，而且能够有很深的技术情结，真是一件很cool的事情，我比较欣赏极客精神，同时满足了业务，也在技术上的价值得以体现，这种模式值得很多开源项目参考借鉴。
首先，让我感兴趣的不是TiDB的NewSQL角色，而是对TiDB的发展过程，TiDB的架构演进对于理解TiDB技术还是很有帮助的，也对我们的工作和实践具有一定的借鉴。如果让我来总结，我觉得有几个里程碑事件对我的触发较大。
① 设计MySQL分布式存储引擎。
整个项目从2015年4月份开始，初期是写一个MySQL分布式存储引擎，来期望达到分布式的基本需求，但是性能差强人意，同时存储引擎层对优化器层面，事务模型层的支持非常有限，所以初期的架构设计没有达到预期。
② 兼容MySQL协议，自上而下实现
后期的架构设计对标MySQL协议，自上而下重写，完全兼容MySQL协议，实现Server层的基本需求。
TiDB 0.5版本的架构如下：
③ 存储引擎引入HBase
初期的TiDB是没有存储引擎的，数据都是在内存层面，接入HBase，也是一个战略选型，主要是为了初步验证SQL层的实现是否稳定。
④ 使用Rust重写Etcd 里的 Raft
KV存储层使用Rust来实现，主要的难点就是对Etcd的Raft实现使用Rust完全重写，我觉得这是最cool的一件事情了，难度可想而知，但是做成了会发现成就满满。
⑤ 接入RocksDB
RocksDB是一个单机的key-value engine，前身其实是LevelDB，是Google在2011年左右开源的key-value的存储引擎。RocksDB的数据结构是LSM Tree是一个对写非常友好，在机器内存比较大的时候读性能会非常好的数据结构。
技术架构层面，TiDB和Oracle中的RAC其实很像（组件和功能），当然最大的不同就是一个是分布式，弹性扩缩容，另外一个是集成共享式。
我测试的时候使用了如下的部署架构。
测试的过程中，对TP，AP业务做了一些基本的测试和性能压测，对高可用，弹性扩缩容，滚动升级，备份恢复也做了一些基本的覆盖测试。
优点的内容很明显，可以从部署安装感觉到，很多新技术都在大规模使用了。
亮点功能如下:
① 支持多种部署方式（离线部署，在线部署，docker部署）
② 监控部署一体化
③ 快速部署
④ 备份恢复,定制了主流工具mydumper,myloader,
⑤ 增量复制syncer
⑥ 实时备份和恢复的特性 TiDB的binlog方案，和kafka对接
⑦ 承接AP的业务，基于spark
⑧ 弹性扩缩容
⑨ 滚动升级
⑩ 读写混合，单不只局限于密集型写入
11 Tidb重新部署，原有的数据不会删除，如果优惠复用起来
12 故障自动恢复
13 产品定制能力强，定制了将近30个参数，针对TiDB的使用需求
还有一些细节的小错误或者问题，后续和朋友对接集中反馈下。
从我的理解来看，目前的TiDB的业务切入点可以作为对已有的MySQL方案的补充，甚至可以做到透明的集群方案，无论你是采用了PXC,MHA,还是MGR，整个过程都可以通过级联的方式衔接起来。
另外一个切入点应该是大数据部分，目前从我的测试来看，TiDB是乐观锁，对于AP业务的支持其实需求是更大一些，所以能够对接到大数据平台，能够实现一些基本的数据流转甚至数据下沉至大数据，都是一些不错的点。
