「PingCAP」会成为数据库的未来吗？，HTAP 本文转载自InfoQ官网

本文转载自InfoQ官网，作者：王晓青
在访问量和数据量急剧膨胀的今天，关系型数据库已经难以支撑庞大复杂的系统规模。在此背景下，备受关注的数据库新理念HTAP ，会是一条“正确”的路吗？
为什么是HTAP？在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构，所有的线上请求(OLTP,OnlineTransactionalProcessing)和后台分析(OLAP,OnlineAnalyticalProcessing)都跑在同一个数据库实例上。
随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量限制制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求， OLTP、OLAP在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：
OLAP和OLTP系统间通常会有几分钟甚至几小时的时延， OLAP数据库和OLTP数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。在此背景下，由Gartner提出的HTAP（混合事务/分析处理， HybridTransactional/AnalyticalProcessing）成为希望。基于创新的计算存储框架， HTAP数据库能够在一份数据上同时支撑业务系统运行和OLAP场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外， HTAP基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
目前，实现HTAP的数据库不多，主要有PingCAP的TiDB、阿里云的HybridDBforMySQL、百度的BaikalDB等。其中， TiDB是国内首家开源的HTAP分布式数据库，接下来，本文将以此例进行深入分析。
一、TiDB基本架构解析TiDB的理论基础来源于2013年Google发布的Spanner/F1论文，以及2014年Stanford工业级分布式一致性协议算法Raft论文。在架构上， TiDB将计算和存储层进行高度的抽象和分离，对混合负载的场景通过IO优先级队列、智能副本调度、行列混合存储等技术，使HTAP变为可能。
参考GoogleSpanner/F1的设计， TiDB整体架构分为上下两层：负责计算的TiDBServer和负责存储的TiKVServer ，二者由集群管理模块PDServer调度和管理。

文章图片
根据PingCAP高级技术总监、CMC成员、华南区总经理姚维最近的《TiDB性能设计及鲲鹏平台优化实践》演讲， TiDBServer对应于GoogleF1 ，是一层无状态的SQLLayer ，其本身并不存储数据，只负责计算。在接收到SQL请求后，该计算层会通过PDServer找到存储计算所需数据的TiKV地址，然后与TiKVServer交互获取数据，最终返回结果。在水平扩展方面，随着业务的增长，用户可以简单地添加TiDBServer节点，提高数据库整体的处理能力和吞吐。
作为整个集群的管理模块， PD（PlacementDriver)主要工作有三类：一是存储集群的元信息；二是对TiKV集群进行调度和负载均衡，如数据的迁移、Raftgroupleader的迁移等；三是分配全局唯一且递增的事务ID 。
TiKVServer是一个分布式KeyValue数据库，对应于GoogleSpanner ，支持弹性水平扩展。不同于HBase或者BigTable那样依赖底层的分布式文件系统， TiKVServer在性能和灵活性上更好，这对于在线业务来说非常重要。随着数据量的增长，用户可以部署更多的TiKVServer节点解决数据Scale的问题。 PD模块则会在TiKV节点之间以Region为单位做调度，将部分数据迁移到新加的节点上。