正文
畅想TiDB应用场景和HTAP演进之路
作者: 康凯森
日期: 2018-04-30
分类:
数据库
前一阵阅读了TiDB官方的文档和使用案例，对TiDB的架构原理，使用场景有了一定了解，本文深度畅想(胡思乱想)下TiDB未来可能的应用场景和HTAP的演进之路。在畅想TiDB的应用场景之前，我们先了解下TiDB诞生的背景和TiDB是什么，要解决什么问题。
1 Why TiDB
![db.png-83.1kB]()
如上图，从1970s年代开始，出现了以Mysql,PostgreSQL为代表的RDBMS， 并在相当长的时间内占据主导地位，但是随着21世纪互联网的快速发展和业务数据的飞速增长，传统数据库
缺乏Scalability
的缺陷暴露出来，于是出现了以HBase,Redis,MongoDB为代表的NoSQL数据库，NoSQL数据库拥有很好的
Scalability和Availability
，但是
缺乏SQL和ACID Transaction
。因此，我们需要一个新一代数据库，能够同时拥有RDBMS和NoSQL数据库的优点。
2 What TiDB
![What TiDB]()
TiDB是一款HTAP数据库（同时支持OLTP和OLAP查询），同时具备了RDBMS和NoSQL数据库的优点，具有以下特点：
-
优秀的横向扩展能力
-
高可用
-
强一致性
-
支持ACID事务
-
支持SQL，兼容Mysql协议和绝大多数Mysql语法
-
Cloud-Native
-
支持多数据中心
![TiDB Architecture]()
TiDB的架构图如上图所示，TiDB的组件共有3个：
TiKV Server，TiDB Server，Placement Driver
。 每个组件的主要职责如下：
1 TiKV Server
如下图，TiKV Server 负责存储数据，TiKV 是一个支持事务的分布式Key-Value存储引擎，
如果不考虑Region复制，一致性，和事务的话，TiKV其实和HBase很像，底层数据结构都是LSM-Tree, Region都是Range分区, Region都是计算和负载均衡的基本单位。
![TiKV.png-345.6kB]()
2 TiDB Server
如下图，TiDB Server 负责接收 SQL 请求，生成SQL的逻辑计划和物理计划，并通过 PD 找到存储计算所需数据的 TiKV 地址，将SQL转换为TiKV的KV操作，与 TiKV 交互获取数据，最终返回结果。
TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展。 TiDB Server 类似Kylin中的QueryServer。
![TiDB.png-353kB]()
3 Placement Driver
Placement Driver 主要有以下职责：
-
集群的元信息 （某个 Key 存储在哪个 TiKV 节点）
-
TiKV 集群进行调度和负载均衡
-
分配全局唯一且递增的事务 ID
3 TiDB的理论背书
-
Google Spanner
: 最主要的特性就是支持跨行事务和在分布式场景上实现 Serializable 的事务隔离级别. TIKV主要参考此篇论文实现。
-
F1: A Distributed SQL Database That Scales
: 基于Google Spanner实现的NewSQL数据库， F1论述了Spanner上层的分布式SQL层怎么实现，分布式的Plan怎么生成和优化，TIDB主要参考此篇论文实现。
-
Raft
: TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。
-
Online, Asynchronous Schema Change in F1
：TiDB的在线Schema变更主要参考此篇论文实现。
-
Google Percolator
: 经过优化的 2PC 实现，依赖一个单点的授时服务 TSO 来实现单调递增的事务编号生成，提供 SI 的隔离级别. TIKV的事务主要参考此篇论文实现。
4 TiDB的应用场景
4.1 Replace Mysql
![TiDB replace Mysql]()
相比Mysql，TiDB 可以做到横向扩展，高可用。 此外，由于TiDB兼容Mysql协议和绝大多数Mysql语法，在大多数情况下，用户无需修改一行代码就可以从Mysql无缝迁移到TiDB。这也是目前TiDB在业界最广泛的应用场景。 下图是几个业界的典型应用：
![TiDB replace Mysql]()
4.2 Replace HBase
![TiDB replace HBase]()
相比HBase, TiDB 可以很好地支持SQL， 支持事务，支持二级索引，没有Java GC的痛点（TiKV是由Rust开发，Rust可以完全手动控制内存，无GC）。所以我认为TiDB可以代替掉HBase。 下图是几个业界的典型应用：
![TiDB replace HBase]()
4.3 TiDB for OLAP
TiDB的设计目标是同时很好的支持OLTP和OLAP，但是从公开的测试结果来看，
TiDB的OLAP性能一般，不如现在专门的OLAP系统
（Kylin， Druid，Palo，ClickHouse等），在业界实践中，大多数公司都会引入TiSpark来解决OLAP问题。
从OLAP视角来看，TiDB的优点如下：
-
兼容Mysql协议和语法
-
实时和离线数据导入
-
支持聚合，明细，点更新
-
在线Schema变更
-
易运维
-
Both OLAP And OLTP
从OLAP视角来看，TiDB的缺点如下：
4.4 TiDB for 实时数仓
![TiDB realtime data warehouse]()
上图是易果集团实时数仓的架构图，上游OLTP的数据和其他的实时数据可以实时写入TiDB，下游OLAP的业务可以通过 TiDB或者TiSpark实时进行分析， 并且可以通过TiSpark将实时和离线整合起来。
