TiDB实例测试分析

本文小编为大家详细介绍“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业务的支持其实需求是更大一些，所以能够对接到大数据平台，能够实现一些基本的数据流转甚至数据下沉至大数据，都是一些不错的点。

读到这里，这篇“TiDB实例测试分析”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注行业资讯频道。