【WOT2018】PingCAP CTO黄东旭：TiDB数据库的四大应用场景分析

【WOT2018】PingCAP CTO黄东旭：TiDB数据库的四大应用场景分析

在“大数据处理技术”分会场，PingCAP CTO黄东旭以《How can HTAP help you：A TiDB Story》为主题展开精彩分享。TiDB是一套开源分布式HTAP(Hybrid Transactional/Analytical Processing)数据库，同时提供MySQL与Spark SQL接口。黄东旭在演讲中介绍，TiDB作为一款HTAP数据库，在高性能的实现 OLTP 特性基础之上，也同时提供基于实时交易数据的实时业务分析需求，他分享了TiDB的设计思路、现实应用场景，以及TiDB集群在部署和运营方面的***实践。

PingCAP CTO黄东旭

如今硬件的性价比越来越高，网络传输速度越来越快，数据库分层的趋势逐渐显现，人们已经不再强求用一个解决方案来解决所有的存储问题，而是通过分层，让缓存与数据库负责各自擅长的业务场景。

黄东旭提到，当前数据库领域面临各种问题，如在缩放、一致性、大数据分析、与云基础架构集成等方面均存在诸多问题，现有的数据库解决方案和大数据分析引擎解决方案基本处于割裂的状态，由于***、MySQL数据库并不是面向分布式环境而设计，因此即使勉强通过分库、分表或中间件的方式，在数据库层面做了分片，从本质上看也只是复制了相同的堆栈，而非针对分布式系统进行存储和计算优化，这正是进行跨业务查询或跨物理机查询和写入十分繁琐的本质原因。NoSQL虽然解决了数据库弹性扩展的难题，但是却放弃了数据的强一致性以及对ACID事务的支持，带来了新的问题。

为了解决这一问题，TiDB在架构上将计算和存储层进行高度的抽象和分离，对混合负载的场景通过IO优先级队列，智能副本调度，行列混合存储等技术使其变为可能。TiDB 作为开源的分布式关系数据库，其特点是几乎可以100% 兼容MySQL接口，也兼容 MySQL 的语法和协议，在保证不丧失 ACID 事务的前提下，能够弹性伸缩，高可用，可以同时处理OLTP和OLAP工作负载，不再需要ETL。

TiDB整体架构图

TiDB产品的整体架构是高度分层的，由分布式SQL层(TiDB)、分布式KV存储引擎(TiKV)以及管理整个集群的PD模块组成。***水平扩展是TiDB的一大特点，这里所说的水平扩展包括两方面：计算能力和存储能力。

HTAP给开发者提供了一个实时数据分析方面的新思路，不需要再去维护另一个离线的数据仓库，既减轻了ETL的工作，又能节省很大一部分建立数据仓库所用到的存储和计算成本，HTAP将是未来的重要趋势。黄东旭介绍了TiDB的四个主要应用场景，一是MySQL分片与合并;二是直接替换MySQL;三是用做数据仓库;四是作为其他系统的一个模块。

用例1：MySQL分片与合并

Syncer

TiDB应用的***类场景是MySQL的分片与合并。对于已经在用MySQL的业务，分库、分表、分片、中间件是常用手段，随着分片的增多，跨分片查询是一大难题。TiDB在业务层兼容MySQL的访问协议，PingCAP做了一个数据同步的工具——Syncer，它可以把TiDB作为一个MySQL Slave，将TiDB作为现有数据库的从库接在主MySQL库的后方，在这一层将数据打通，可以直接进行复杂的跨库、跨表、跨业务的实时SQL查询。黄东旭提到，“过去的数据库都是一主多从，有了TiDB以后，可以反过来做到多主一从。”

用例2：直接替换MySQL

第二类场景是用TiDB直接去替换MySQL。如果你的IT架构在搭建之初并未考虑分库分表的问题，全部用了MySQL，随着业务的快速增长，海量高并发的OLTP场景越来越多，如何解决架构上的弊端呢?

在一个TiDB的数据库上，所有业务场景不需要做分库分表，所有的分布式工作都由数据库层完成。TiDB兼容MySQL协议，所以可以直接替换MySQL，而且基本做到了开箱即用，完全不用担心传统分库分表方案带来繁重的工作负担和复杂的维护成本，友好的用户界面让常规的技术人员可以高效地进行维护和管理。另外，TiDB具有NoSQL类似的扩容能力，在数据量和访问流量持续增长的情况下能够通过水平扩容提高系统的业务支撑能力，并且响应延迟稳定。

黄东旭在演讲中提到了摩拜单车的案例，摩拜早期的数据库全部用MySQL，随着业务的快速增长，MySQL的弊端逐渐显现，摩拜单车于2017年初开始使用TiDB替换MySQL。如今，摩拜的IT系统中已部署了数套TiDB集群，近百个节点，承载着数十TB 的各类数据。

用例3：数据仓库

TiDB本身是一个分布式系统，第三种使用场景是将TiDB当作数据仓库使用。TPC-H是数据分析领域的一个测试集，TiDB 2.0在OLAP场景下的性能有了大幅提升，原来只能在数据仓库里面跑的一些复杂的Query，在TiDB 2.0里面跑，时间基本都能控制在10秒以内。当然，因为OLAP的范畴非常大，TiDB的SQL也有搞不定的情况，为此PingCAP 开源了 TiSpark，TiSpark是一个Spark插件，用户可以直接用Spark SQL实时地在TiKV上做大数据分析。

用例4：作为其他系统的模块

TiDB是一个传统的存储跟计算分离的项目，其底层的Key-Value层，可以单独作为一个***的Replacement来用，它同时支持跨行事务。TiDB对外提供两个API接口，一个是ACID Transaction的API，用于支持跨行事务;另一个是Raw API，它可以做单行的事务，换来的是整个性能的提升，但不提供跨行事务的ACID支持。用户可以根据自身的需求在两个API之间自行选择。例如有一些用户直接在 TiKV 之上实现了 Redis 协议，将 TiKV 替换一些大容量，对延迟要求不高的 Redis 场景。

尚待解决的问题

***，黄东旭提到了数据库领域尚待解决的三大问题：

1、 多租户：例如，整个集群云化之后，IO隔离还存在很大的问题，数据层如何做到更有效的资源隔离和复用是一个问题。

2、真正的自治：数据库能否拥有真正的智能，如能够自我维护，自我修复以及自我性能调优等。

3、如何利用新的硬件：如何利用Nvme ***、Persistent Memory、GPU、FPGA等，软硬结合的利用新时代的硬件提升数据库的稳定性。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。