新一代HTAP数据库崛起，MySQL生态的最佳归宿？

俗话说，天下大势，合久必分、分久必合。

数据库领域同样如此。过去五十余年，数据库经历OLTP和OLAP两种需求漫长的融合-分离-再融合的过程。究其原因，数据库的发展始终与用户场景需求变迁紧密相关。如今，随着云计算和大数据的兴起，业务场景正在经历前所未有的变革，数据库领域也掀起了一股HTAP浪潮。

Gartner在多次报告中强调，HTAP是数据库领域最重要的发展趋势之一，也是用户数字化转型中重要的数据平台。业界甚至认为，HTAP的兴起代表着数据库大融合时代的开启。

那么，为什么数据库大厂和云服务巨头们均纷纷押宝HTAP？开源+多云为何是HTAP普及的助推剂？面对新一代HTAP数据的崛起，多年积累形成的MySQL生态终于找到最佳归宿？

放在几年前，HTAP可能还会被认为是数据库领域的小众产品，是否成气候还有待观察。

而随着数据资源、数据消费习惯和数据驱动型场景发生巨大变化，用户需求与传统数据库之间的供需矛盾日渐突出，使得HTAP这种具备“同时支持OLTP和OLAP、创新计算存储框架、去ETL”等特征的新时代数据库成为不可阻挡的趋势。

如今，几乎所有数据库大厂和云服务巨头都在布局HTAP。例如，OceanBase去年推出的 3.0版本中就正式宣布向HTAP数据库进军；今年5月，Google Cloud发布HTAP云端数据库AlloyDB，为PG用户提供了HTAP数据库服务；再加上Oracle MySQL Heatwave，甚至连SnowFlake也发布Unistore来“蹭”HTAP的热点。

如果细数近一年以来的HTAP新品，会发现几乎全部都建立在云端之上。新一代HTAP+云正在成为数据库市场重要的潮流。例如，PingCAP近日发布的TiDB 6.0，也是与云端紧密联系的新一代HTAP数据库。

事实上，PingCAP是HTAP数据库领域非常重要的一个引领者。早在TiDB 3.0起，PingCAP就正式转向HTAP，从OLTP主引擎+OLAP辅助能力，到OLTP引擎+外接分析引擎，再到OLTP引擎+融合分析引擎，PingCAP在HTAP领域稳打稳扎，一个版本上一个台阶。

如今，随着TiDB 6.0的发布，针对HTAP进行了更多成熟性改进，TPC-C 性能也较 5.0 版本提升达到 76.32%，TiDB 6.0还增强了多个企业级特性，以更好适合云时代用户对于HTAP数据库的需求。

固然，有人质疑当前HTAP是新瓶装旧酒，并无太多新意。但业界普遍形成共识：新一代HTAP与过去完全不同，开源+云孕育而出，很多都有AI加持，而且是为数据敏捷而生，拥有过去前所未有的创新活力与迭代速度，并逐渐形成数据库技术变革的新潮流。

PingCAP CTO 黄东旭也直言：“TiDB近年来的快速进化与迭代，得益于开源和云的助力。”

HTAP之所受到用户青睐，某种程度是因为用户对于数据敏捷性的极度渴求。

“在数字化时代，客户最为在乎的是如何快速走向市场。这需要数据敏捷性，而HTAP恰恰是数据敏捷的核心能力。”黄东旭如是说。

最近几年，“海量、实时、在线”的需求越来越广泛，大量采用 MySQL 和 PostgreSQL 开源数据库的新一代企业需要提升对于热数据的实时在线分析能力，这类需求遍布几乎所有的互联网企业以及从事线上业务的数字化转型企业。对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡，传统的 OLTP+OLAP+ETL 的数据架构已经严重阻碍了消费者体验，这种诉求催生了 HTAP 的技术变革。

而真正帮助HTAP与用户需求完成对接的则是开源+云。众所周知，开源近年来在数据库领域的流行和影响力与日俱增，DB-Engines数据显示，全球383款数据库中开源数据库占据51.7%，六款开源数据库进入到前十，开源正在成为像HTAP这种新时代数据库的创新源泉。

以PingCAP的TiDB为例，其产品研发体系建立在开源体系和开源社区的基础上，实现了一年一个大版本、一个月一个小版本的迭代速度。黄东旭透露道：“开源是TiDB的第一个增长引擎，通过开源体系，开发者、贡献者、布道者和用户能够很好串联起来，形成飞轮效应，让产品能够走向加速迭代和创新的正向循环。”

据悉，TiDB每年会有超过 40% 的代码更新，而这些代码有很大一部分由外部贡献者所共享。TiDB开源项目一直在全球和中国开源项目活跃度中名列前茅。

如果说开源改变了HTAP产品的开发模式和迭代速度，那么云则能够为HTAP产品提供用户最为直接的需求反馈。众所周知，云数据库一改以往传统数据库部署、运维、扩展等难题，以云服务的方式让数据库使用更加简单；更加关键的是，随着云计算的普及，云上用户群体持续增加，来自云上用户群体的需求反馈无时无刻都在发生，对于数据库产品的进化与迭代至关重要。

“真正的产品迭代是如何缩短用户问题/需求的反馈时间。云无疑为数据库等基础软件提供了这样的价值，让产品可以更好地迭代。”黄东旭如是说。以TiDB为例，自去年五月全托管的数据库即服务（DBaaS）产品 TiDB Cloud 公测版发布以来，已经陆续登陆亚马逊云 科技 、谷歌云等全球知名云服务商的Marketplace，并在今年5月份正式全球商用；今年 6 月与阿里云合作上线阿里云云市场，成为为数不多的跨全球三朵云的数据库服务。

在众多数据库产品之中，MySQL凭借着开源、免费、适合互联网场景等优势，常年位居全球最受欢迎数据库的前三。根据Slintel网站的统计数据，在全球关系型数据库市场中，MySQL市场份额最高，达到43.04%。

过去二十年里，开源MySQL数据库对于各行各业影响至深，捕获了来自互联网、金融、零售、交通等多个行业用户的心，堪称“万人迷”。例如，在中国就有超过9成的金融机构都应用了MySQL数据库。

但任何数据库潮流都是“需求变化+技术变革+架构创新”融合的产物，MySQL是如此，HTAP亦不例外。如今，场景的数据规模、业务并发量、处理速度要求跟以往相比早已不是一个数量级。此时，MySQL数据库的局限性愈发突出，扩展性很难满足用户需求，想继续获得增长的企业不得不使用分库分表方案，但这又会造成数据架构的复杂性。

新一代HTAP数据库无需分库分表，且具备实时海量规模的OLTP和实时数据分析能力，还拥有极为出色的扩展性，与很多业务场景的海量交易实时数据展现、平稳运行的需求高度契合，HTAP凭借技术架构优势崛起已成必然。

“用户需求侧最大的变化就是很多用户需要借助热数据实现运营级别的实时分析，获得实时洞察以支持决策，这极大推动了新一代HTAP数据库的需求。”PingCAP副总裁刘松补充道。

虽然MySQL已经增加列存引擎Heatwave来获得HTAP能力，但主要解决规模化查询的问题，系统本身架构并未产生革命性变化，扩展能力、OLTP吞吐量依然有着很大局限。“智能新能源 汽车 跟传统燃油车在外表看几乎没区别。数据库也类似，像TiDB这种新一代HTAP数据库，从架构设计、应对场景和使用体验等角度，都与传统数据库有着极大的区别。”刘松形象比喻道。

事实上，与过去SAP HANA这种小众、昂贵的HTAP不同，新一代HTAP拥有极强的兼容性，像Google Cloud、PingCAP这些数据库厂商都借助新一代HTAP架构为采用 MySQL或者PG开源数据库的企业拓展 OLTP和OLAP的能力范围。

例如，Google Cloud发布的HTAP云端数据库AlloyDB，为单机版PG生态用户提供了最好选择，TiDB则成为MySQL生态的最佳归宿。PingCAP大量用户中有很多TiDB与MySQL混合部署的成功案例；得益于 TiDB 的开放性，TiDB 也可通过和其他数据服务产品“混搭”形成新的数据服务解决方案， 如通过同样是开源的大数据计算引擎 Flink 混搭形成实时数仓解决方案，扩展 HTAP 数据库的能力边界。

黄东旭则直言，HTAP数据库除了产品、技术之外，尤为需要关心用户体验，“HTAP应该让用户觉得好用，屏蔽掉数据库的复杂性。”据悉，PingCAP是2022 Gartner Peer Insights“Voice of the Customer” 云数据库领域唯一入选的中国数据库公司，客户总体评分达到 4.7 分（满分 5 分），在所有入选企业中位列第一。在参与Gartner Peer Insights评分的PingCAP用户中，像互联网、金融等重点行业用户均高度认可HTAP现代数据库理念。

总体来看，今年是HTAP的大年，各大厂商纷纷在市场中上新。随着新一代HTAP数据库产品的增多，整个市场对于HTAP数据库理念和产品的接受与采用将会提速。而随着新一代HTAP数据库持续完善，让广大MySQL生态用户群真正看到了大数据时代一条绝佳的迁移路径。

1、测试环境推荐配置

2、生产环境推荐配置

3、 如果 tikv 服务器的 CPU及磁盘配置较高，可以考虑多实例部署，按照每个 tikv 实例16~20core + 64G 内存 + 800G 磁盘的比例分配硬件资源。

同时需要注意 inventory.ini 及 ansible/conf/tikv.yml 的相关配置。

4、tidb 服务器视业务类型，如果业务逻辑有偏 AP 类的 SQL，需要考虑配置大内存，防止出现 OOM。

如果是纯 TP 类业务，tidb 服务器 CPU 配置较高的话，也可以考虑多实例部署，每个 tidb-server 分配20~32core，可以避免无谓的CPU上下文切换， 减少 system cpu 消耗。

5、pd 服务器的磁盘可以配置200~500G 的SSD 盘，主要用来保存源数据信息。在集群规模较大，源数据信息较多的时候，SSD 磁盘能够避免源数据信息存取成为集群的瓶颈点。

1、操作系统版本要求

建议 centos 7.3及以上，支持 redhat 7.3版本及以上，不推荐其他版本的系统。

2、ansible、jinja 等软件依赖包版本，只需要验证中控机（运行ansible 机器）上软件版本满足条件即可

中控机：

监控机（grafana）：

3、测试环境磁盘 IO 不满足需求

ansible-playbook bootstrap.yml --extra-vars "dev_mode=True"

加上 dev_mode=True 可以在部署时，绕过系统磁盘相关的 benchmark

4、关闭防火墙、开启时钟同步

systemctl status firewalld

systemctl status chronyd/ntpd

5、集群下所有服务器要配置不同的 hostname

如果否，可以编辑 inventory.ini 的配置项 set_hostname=True 来自动修改 hostname

6、调整参数

参数在 ansible/conf/目录下，tidb.yml，tikv.yml，常见的可能需要调整的参数

tidb.yml：

grpc-connection-count: 如果服务器 CPU 配置较高，tikv 实例个数较多，该参数可以调整至20~32之间

slow-threshold：slow-query 记录的阈值，默认300ms

level：日志级别，默认 info，可以视情况调整为 debug 或 error

tikv.yml：

sync-log：raft-log sync配置，默认值true，对于磁盘 io 消耗较高，测试/非金融生产环境建议设置为 false

region-split-check-diff：检测 region 分裂的阈值，非 SSD 磁盘建议调大至32MB

rocksdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 30%（多实例部署下配置，单实例部署不需要修改）

rocksdb writecf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 45%（多实例部署下配置，单实例部署不需要修改）

rocksdb lockcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 2.5% (最小 128 MB)（多实例部署下配置，单实例部署不需要修改）

raftdb defaultcf block-cache-size(GB) = MEM * 80% / TiKV 实例数量 * 2.5% (最小 128 MB)（多实例部署下配置，单实例部署不需要修改）

多实例情况下，需要修改 

readpool:

  coprocessor:

  high-concurrency

  normal-concurrency

  low-concurrency

三个参数，推荐为实例数*参数值 = CPU 核数 * 0.8。

 raftstore:

   capacity

 磁盘总容量 / TiKV 实例数量，例如 “100GB”

修改完后，可以使用下面命令验证

cat tidb-ansible/conf/tikv.yml |grep -Ev "^$|#"

无误后执行 

ansible-playbook rolling_update.yml --tags=tidb/tikv

滚动升级，tags 可选

7、官网有比较完善的在线+离线部署方案、在线升级指导、在线扩容缩容文档，具体参考：

https://pingcap.com/docs-cn/op-guide/ansible-deployment/

https://pingcap.com/docs-cn/op-guide/offline-ansible-deployment/

https://pingcap.com/docs-cn/op-guide/ansible-deployment-scale/

1、从 MySQL 迁移

TiDB 兼容 MySQL 语法，小数据量建议直接使用 mysqldump、mydumper 来全量导出数据，再通过 source、myloader 的方式导入 TiDB。

./bin/mydumper -h 127.0.0.1 -P 3306 -u root -t 16 -F 64 -B test -T t1,t2 --skip-tz-utc -o ./var/test

./bin/loader -h 127.0.0.1 -u root -P 4000 -t 32 -d ./var/test

详情请参考： https://pingcap.com/docs-cn/op-guide/migration/#使用-mydumper-loader-全量导入数据

如果数据量较大，超过几百 G，可以联系原厂申请试用 lightning 工具，loader 导入数据平均速度是20G/小时，lightning 约为100~150G/小时

2、从 Oracle 迁移

目前有几种方式可以参考

使用 OGG 做全量+增量同步

使用 Navicat Premium 版的 data transfer 功能，支持从 Oracle/SqlServer 迁移全量数据至 TiDB

通过 kafka 等消息队列工具，解析 OGG 的日志，开发写入 TiDB/MySQL 的工具

目前我们也在积极跟专业的数据异构平台合作，争取能够尽快在更多的数据迁移工具中兼容 TiDB 数据源。

1、启动集群

ansible-playbook start.yml --tags=tidb/tikv/pd

在正确的 ansible 目录下，确保 inventory.ini 里的配置正确，tags 可选

2、停止集群

ansible-playbook stop.yml --tags=tidb/tikv/pd

在正确的 ansible 目录下，确保 inventory.ini 里的配置正确，tags 可选

3、停止单个 tidb-server / tikv-server

ansible-playbook stop.yml --tags=tidb/tikv/pd -l IP

-l 后面接 inventory.ini 配置的IP 或别名

4、访问 tidb

TiDB 兼容 MySQL 协议，所有连接 MySQL 的方式都适用于TiDB

mysql -uroot -h127.0.0.1 -P4000 -p

常见的图形化界面工具，navicat 等都可以直接访问 tidb

同时也支持jdbc、odbc 等，需要注意的是 mysql 8.0版本的客户端，及 mariadb 客户端可能存在兼容性问题，不建议使用

SQL 语法基本兼容 MySQL，某些不兼容的场景见： https://pingcap.com/docs-cn/sql/mysql-compatibility/#与-mysql-兼容性对比

5、修改参数

可以通过修改 tidb-ansible/conf/tidb.yml 配置文件，然后执行

ansible-playbook rolling_update.yml --tags=tidb/tikv

也可以直接登录服务器，找到deploy_dir/conf/tidb.toml，直接编辑文件，然后 pkill tidb-server 来重启服务

6、查看 tidb 版本信息

select tidb_version()

Release Version: v2.1.0-rc.3-24-g23f90a6

Git Commit Hash: 23f90a68be321e724280da6033a2b63ebf6cc7dd

Git Branch: HEAD

UTC Build Time: 2018-10-10 09:18:39

GoVersion: go version go1.11 linux/amd64

Race Enabled: false

TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e

Check Table Before Drop: false

7、备份 tidb 数据

全量备份可以采用 mydumper，增量备份需要开启 binlog，实时恢复采用商业版工具 reparo。

8、查看监控数据

在 ansible 的配置文件 inventory.ini 里，有一个监控服务器的配置

[monitoring_servers]

10.1.163.87

deploy 的时候会默认在这个配置服务器上部署 grafana 组件，通过

http://10.1.163.87:3000 admin/admin  访问

具体一些常见的监控指标，请参考： https://pingcap.com/docs-cn/op-guide/dashboard-overview-info/

9、收集统计信息

set @@tidb_build_stats_concurrency=20

set @@tidb_distsql_scan_concurrency=100

set @@tidb_index_serial_scan_concurrency=20

analyze table xxx index xxx

修改上面三个参数可以提升 scan 效率。

具体统计信息相关，请参考： https://pingcap.com/docs-cn/sql/statistics/#统计信息简介

1、Transaction too large

TiDB 对于事务有限制，简单来说以下几点：

单个事务的SQL 语句数量不能超过5000，（ 在 tidb.yml 可配 stmt-count-limit ）

单条 KV entry 不超过 6MB

KV entry 的总条数不超过 30w

KV entry 的总大小不超过 100MB

备注：假设某张表有4个索引，那么一条数据对应的 kv entry 为数据+索引，一共5个kv 记录。

如果是批量 insert 或delete，建议先修改

set tidb_batch_insert = 1 

set tidb_batch_delete = 1

update mysql.tidb set variable_value='24h' where variable_name='tikv_gc_life_time'

再执行 SQL。

如果是批量 update，建议采用 limit 循环的方式执行。

2、GC life time is shorter than transaction duration

GC Life Time 间隔时间过短，长事务本应读到的数据可能被清理了，可使用如下命令增加 GC Life Time ：

update mysql.tidb set variable_value='30m' where variable_name='tikv_gc_life_time'

3、Lost connection to MySQL server during query

log 中是否有 panic

dmesg 中是否有 oom，命令： dmesg -T | grep -i oom

长时间没有访问，也会收到这个报错，一般是 tcp 超时导致的，tcp 长时间不用, 会被操作系统 kill。

相比于 Intel 的 x86-64 架构，ARM 架构虽然作为后来者，但在服务器领域也开始在不停地攻城拔寨，很多企业也开始将自己的服务迁移到 ARM 架构上面，自然，对于 TiDB 来说，大家也想将 TiDB 运行到 ARM 上面。因为 AWS 上面直接提供了 ARM 机型，所以我们决定先尝试在 AWS 的 ARM 上面编译运行 TiDB。

TiDB 主要包含三个组件 - PD，TiKV 和 TiDB，对于 PD 和 TiDB 来说，使用的是 Go 进行编译的，所以我们只需要在 ARM 机器上面装好 Go 的版本就可以了。这里，我使用的是 go1.12.6.linux-arm64 这个版本。

用 Go 编译 TiDB 和 PD 比较容易，中途遇到了一个 TiDB 的编译问题，只需要升级下 vendor 就解决了。

编译 TiKV 就比较麻烦了，因为我们使用的是 CentOS 系统，系统用 yum 就能安装相关的依赖，除了 cmake3 ，装 cmake 需要做如下处理：

当然，编译 RocksDB 还有 Titan 的时候还遇到了一些错误，不过多数就是传递编译参数的时候需要处理下 ARM64 相关的选项，并不是特别的困难。

总的来说，编译并没有花太多的时间，这里有一个 脚本 ，大家可以自行去看如何在 ARM64 上面编译 TiDB。对于运行集群需要的 Grafana 和 Prometheus，官方都提供了 ARM64 版本，大家可以直接去 Google。

编译好了 ARM64 的版本，自然就是测试了，这里我使用了 go-ycsb 进行了简单的测试，这里我使用的是 16c32g 的 ARM64 机器，顺带也开了一台同配置的 x86 作为对比。

在每台测试机器上面，启动一个 PD，一个 TiKV，使用的是默认配置，然后 go-ycsb 使用 100 并发，导入 1 百万数据，操作次数 1 百万，batch size 为 0。

结果如下：

可以看到，ARM 的机器性能比 x86 的差了很多，需要来优化了。在网上找了这篇 文章 ，使用了上面的脚本，但发现没有什么变化。在这个脚本里面，主要的优化就是将网卡中断的处理绑定到某一个 CPU 上面，然后将 RPS 分散到不同的 CPU。对于 16c32g 的机器来说，这个脚本将网卡中断的处理绑定到 CPU core 0 和 8 上面，然后把 RPS 分散到所有的 CPU 上面，但是我通过 mpstat 发现，core 0 和 8 几乎被打满：

于是我重新调了下，将 RPS 分散到除开 core 0 和 8 的地方：

然后 OPS 稍微提升了一点，但 CPU core 0 和 8 仍然是瓶颈。而这个瓶颈明显是网络处理造成的，直观的优化就是减少网络消息的处理，于是将 batch size 设为 128，可以发现在 ARM 上面性能提升很多，譬如对于 workload C，OPS 能提升到 118270。但即使这样，CPU core 0 和 8 还是会成为瓶颈。

对比 ARM，x86 下面 CPU 的分配明显的均匀很多：

所以后面我们要考虑的事情就是如何让 ARM 能更好的处理网络消息。

上面简单的说了一下如何在 ARM 上面编译运行 TiDB，以及一些调优策略。个人认为，虽然 ARM 在性能上面还赶不上相同配置的 x86，但低功耗，成本这些是一个非常大的优势，加上很多不可说的原因，个人认为会有越来越多的企业使用 ARM，所以这块也会是趋势。

---