您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 数据库 > 正文

带你走近TiDB:一款开源NewSQL数据库

发表于:2018-11-20 作者:布加迪编译 来源:51cto

带你走近TiDB:一款开源NewSQL数据库

随着企业采用云原生架构,话题自然转向我们如何让数据库能够横向扩展。答案可能是更认真地打量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是一款采用Apache 2.0许可证发布的开源NewSQL数据库。因为它使用MySQL协议,现有的应用程序能够使用任何MySQL连接件连接到它,大多数SQL功能保持一样(连接、子查询和事务等)。

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