TiDB 实例测试分析

首先对于我来说，我觉得能够开发数据库并且拥有一个深厚的技术复杂性。这是一件非常酷的事情。我欣赏极客精神。满足了业务，体现了技术价值。这个模型值得很多开源项目参考。

首先，我感兴趣的不是 TiDB 的 NewSQL 角色，而是 TiDB 的发展历程。 TiDB 的架构演进对于理解 TiDB 技术还是很有帮助的，对我们的工作和实践也有启示。有一定参考作用。如果要我总结的话，我认为有以下几点：w 里程碑事件让我更加兴奋。

①设计MySQL分布式存储引擎。

整个项目于2015年4月启动，初期是编写一个MySQL分布式存储引擎，以满足分布式的基本需求。然而，表现却不尽如人意。同时，存储引擎层不如优化器层和事务模型。层支持非常有限，因此最初的架构设计没有达到预期。

②兼容MySQL协议，自上而下实现

后期架构设计基于MySQL协议，自上而下重写，完全兼容MySQL协议，实现Server层的基本需求。

TiDB 0.5 版本的架构如下：

③ HBase 引入存储引擎

早期，TiDB没有存储引擎。他们都在记忆里层面，接入HBase也是一个策略选择，主要是初步验证SQL层的实现是否稳定。

④ Etcd中使用Rust重写Raft

KV存储层是用Rust实现的。主要困难是使用 Rust 完全重写 Etcd 的 Raft 实现。我认为这是最酷的事情。这很难想象，但如果你做到了，你会发现它充满成就。

⑤ 连接RocksDB

RocksDB 是一个独立的键值引擎。它的前身其实是LevelDB，是Google在2011年左右开源的键值引擎，价值的存储引擎。 RocksDB的数据结构是LSM Tree，对于写入非常友好，并且在机器内存比较大的情况下具有非常好的读取性能。

从技术架构上来说，TiDB 中的 RAC 和 Oracle 其实很像（组件和功能），当然最大的区别就是一个是分布式的一个是弹性伸缩，一个是集成共享。

我在测试时使用了以下部署架构。

测试过程中，对TP、AP业务进行了一些基础测试和性能压力测试，以及高可用、弹性扩缩容、滚动升级、备份等和恢复。做了一些基本的覆盖测试。

优势显而易见。从部署和安装就可以感受到。许多新技术正在大规模应用。

重点功能如下：

①支持多种部署方式（离线部署、在线部署、docker部署）

②一体化监控与部署

③快速部署

④备份恢复，定制主流工具mydumper、myloader，

⑤增量复制同步器

⑥实时备份与恢复recovery 特色 TiDB 的 binlog 解决方案，与 kafka 对接

⑦ 承接 AP 业务s，基于spark

⑧灵活扩缩容

⑨滚动升级

⑩混合读写，不仅仅局限于精读

11 Tidb 重新部署，原有数据不会被删除，如果折扣重复使用

12 故障自动恢复

13.产品具有强大的定制能力。定制了近30个参数，以满足TiDB的使用需求。

细节上也存在一些小错误或问题。跟进朋友以提供集中反馈。向下。

以我的理解，目前的 TiDB 业务入口点可以作为现有 MySQL 解决方案的补充，甚至可以是一个透明的集群解决方案，无论你使用 PXC、MHA、还是 MGR，整个进程可以通过级联连接。

另一个切入点应该是大数据部分。从我目前的测试来看，TiDB 是乐观锁，对 AP 业务的支持需求其实更大，所以能够对接大数据平台，能够实现一些基础的数据传输，甚至数据下沉到大数据，都是一个优点。

读完这篇《TiDB实例测试分析》这篇文章就介绍完了。如果你想掌握本文的知识点，你还是需要自己动手。只有通过实际使用你才能理解。如果您想了解更多相关内容的文章，请关注行业资讯频道。