【51CTO.com快译】随着企业采用云原生架构，话题自然转向我们如何让数据库能够横向扩展。答案可能是更认真地打量TiDB。
TiDB是一款采用Apache 2.0许可证发布的开源NewSQL数据库。因为它使用MySQL协议，现有的应用程序能够使用任何MySQL连接件连接到它，大多数SQL功能保持一样(连接、子查询和事务等)。
然而底层还是存在差异。如果你的架构基于拥有读取副本的MySQL，你会看到TiDB的工作方式略有不同。本文介绍了TiDB和MySQL的五大差异。
1.TiDB原生分发查询执行和存储
若是MySQL，通过复制进行横向扩展很常见。通常一个拥有许多从数据库的MySQL主数据库，每个从数据库有完整的数据副本。使用应用程序逻辑或ProxySQL等技术，查询路由到相应的服务器(可以将查询从主数据库卸载到从数据库，只要这么做很安全)。
横向扩展复制非常适用于读取密集的工作负载，因为查询执行可以在复制从数据库之间划分。然而，这对写入密集的工作负载来说成了瓶颈，因为每个副本要有完整的数据副本。换一个角度来看，MySQL复制机制横向扩展SQL处理，但无法横向扩展存储。(顺便说一下，对于传统复制以及Galera Cluster和群组复制等较新的解决方案而言也是如此。)
TiDB的工作方式略有不同：
- 查询执行通过一层TiDB服务器来处理。对SQL处理进行横向扩展可通过添加新的TiDB服务器来实现，使用Kubernetes ReplicaSets很容易完成这个操作。这是因为TiDB服务器是无状态的，其TiKV存储层负责所有数据持久性。
- 表的数据自动分片成小块，并在TiKV服务器之间分配。每个数据区域(分片在TiKV中的名称)的三个副本保留在TiKV集群中，但没有TiKV服务器需要完整的数据副本。使用MySQL术语：每个TiKV服务器同时既是主系统又是从系统，因为对于某些数据区域而言，它将包含主副本，对于其他数据区域而言，它将包含辅助副本。
- TiDB支持跨数据区域的查询，用MySQL术语来说就是跨分片查询。关于不同区域所在位置的元数据由Placement Driver(任何TiDB集群的管理服务器组件)来维护。所有操作都完全符合ACID，跨两个区域改动数据的操作分两个阶段进行提交。
对于学习TiDB的MySQL用户来说，更简单的解释是，TiDB服务器好比智能代理，将SQL转换成发送给TiKV的批量键值请求。TiKV服务器使用基于范围的分区(range-based partitioning)来存储你的表。范围自动平衡以使每个分区保持在96MB(默认值，但可配置)，每个范围可以存储在不同的TiKV服务器上。Placement Driver服务器跟踪哪些范围位于何处，一旦某个范围变得太大或太热，自动重新平衡。
这种设计有横向扩展复制的几个优点：
- 可独立扩展SQL处理层和数据存储层。对于许多工作负载来说，你会在遇到一个瓶颈之前遇到另一个瓶颈。
- 可通过添加节点(针对SQL和数据存储都是如此)逐步扩展。
- 更好地利用硬件。要将MySQL扩展成一个主系统和四个副本，就得拥有数据的五个副本。TiDB只使用三个副本，热点可通过Placement Driver自动重新平衡。
2. TiDB的存储引擎是RocksDB
自2010年以来，MySQL的默认存储引擎一直是InnoDB。在内部，InnoDB使用B +树数据结构，这类似传统商业数据库使用的数据结构。
相比之下，TiDB使用RocksDB作为TiKV的存储引擎。RocksDB对于大型数据集而言有优势，因为它可以更有效地压缩数据，而且索引在内存中再也装不下时，插入性能并不会降低。
请注意，MySQL和TiDB都支持新的存储引擎可供使用的API。比如说，Percona Server和MariaDB都支持RocksDB这个选项。
3. TiDB用Prometheus/Grafana收集指标
跟踪关键指标是维护数据库运行状况的一个重要部分。 MySQL将这些快速变化的指标集中在Performance Schema中。Performance Schema是一组内存表，可通过常规SQL查询来进行查询。
如果是TiDB，做出将信息发送给***服务的战略性选择，而不是将指标保留在服务器内。Prometheus + Grafana是当今运维团队中很常见的技术堆栈，附带的图表易于自行创建阈值或针对警报配置阈值。
TiDB指标
4. TiDB处理DDL好得多
如果我们暂时忽略MySQL中并非所有的数据定义语言(DDL)变化都是联机的，运行分布式MySQL系统时更大的挑战是，同时针对所有节点外化模式变更。设想一下你有10个分片并添加一列，但每个分片要花不同的时间来完成改动。没有分片，这个挑战仍然存在，因为副本会在主系统之后处理DDL。
TiDB使用谷歌F1论文阐述的协议来实现联机DDL。简而言之，DDL变更分解成更小的过渡阶段，那样它们可以防止数据损坏情况，系统可以容忍单个节点每次最多支持一个DDL版本。
5. TiDB为HTAP工作负载而设计
MySQL团队传统上将注意力集中于为联机事务处理(OLTP)查询优化性能上。也就是说，MySQL团队花更多的时间使较简单的查询更好地执行，而不是使所有或复杂的查询更好地执行。这种方法没有任何问题，因为许多应用程序只使用简单的查询。
TiDB旨在跨混合事务/分析处理(HTAP)查询都能很好地执行。对于希望实时分析数据的那些人来说，这是一大卖点，因为那样不需要MySQL数据库和分析数据库之间的批量加载。
结论
以上是我在MySQL界接触15年、继而关注TiDB的五大观察结果。虽然其中许多涉及内部差异，但我建议看看关于MySQL兼容性的TiDB说明文档。它描述了可能影响你应用程序的任何差异方面的一些细节。
原文标题：Meet TiDB: An open source NewSQL database，作者：Morgan Tocker
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
