共计 1549 个字符，预计需要花费 4 分钟才能阅读完成。
本文丸趣 TV 小编为大家详细介绍“TiDB 实例测试分析”，内容详细，步骤清晰，细节处理妥当，希望这篇“TiDB 实例测试分析”文章能帮助大家解决疑惑，下面跟着丸趣 TV 小编的思路慢慢深入，一起来学习新知识吧。
首先对我来说，我觉得能够开发数据库，而且能够有很深的技术情结，真是一件很 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 实例测试分析”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注丸趣 TV 行业资讯频道。
