随着企业采用云原生架构,话题自然转向我们如何让数据库能够横向扩展。答案可能是更认真地打量TiDB。 TiDB是一款采用Apache 2.0许可证发布的开源NewSQL数据库。因为它使用MySQL协议,现有的应用程序能够使用任何MySQL连接件连接到它,大多数SQL功能保持一样(连接、子查询和事务等)。 然而底层还是存在差异。如果你的架构基于拥有读取副本的MySQL,你会看到TiDB的工作方式略有不同。本文介绍了TiDB和MySQL的五大差异。 1.TiDB原生分发查询执行和存储 若是MySQL,通过复制进行横向扩展很常见。通常一个拥有许多从数据库的MySQL主数据库,每个从数据库有完整的数据副本。使用应用程序逻辑或ProxySQL等技术,查询路由到相应的服务器(可以将查询从主数据库卸载到从数据库,只要这么做很安全)。 横向扩展复制非常适用于读取密集的工作负载,因为查询执行可以在复制从数据库之间划分。然而,这对写入密集的工作负载来说成了瓶颈,因为每个副本要有完整的数据副本。换一个角度来看,MySQL复制机制横向扩展SQL处理,但无法横向扩展存储。(顺便说一下,对于传统复制以及Galera Cluster和群组复制等较新的解决方案而言也是如此。) TiDB的工作方式略有不同:
对于学习TiDB的MySQL用户来说,更简单的解释是,TiDB服务器好比智能代理,将SQL转换成发送给TiKV的批量键值请求。TiKV服务器使用基于范围的分区(range-based partitioning)来存储你的表。范围自动平衡以使每个分区保持在96MB(默认值,但可配置),每个范围可以存储在不同的TiKV服务器上。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 |
|
来自: liang1234_ > 《TiDB》