TiDB升级、TiFlash测试及对比ClickHouse

TiDB升级、TiFlash测试及对比ClickHouse

                                              --2020-05-13 刘春雷

1、汇总

1.1、需求

测试3.0.7 升级至4.0.0-rc

测试部署TiFlash

测试TiFlash性能等

对比ClickHouse

1.2、结果

【结论】:

[1]、TiFlash可以提升OLAP的分析速度

[2]、TiFlash与ClickHouse对比,存在一定性能差距。

【差异原因】:

1、tiflash 因为需要支持 update,所以需要额外读取三列:handle (int64), version(uint64), del_mark(uint8); 2、clickHouse的更新存在几点问题:

  • 无法保证一定更新成功,也无法确定啥时候更新成功,因为是后台慢慢做的,两条相同的 key 不一定会merge
  • 正确性无法保证,即有可能同时读到几个数据版本,至于数据库的事务隔离性就更没法做了

3、clickHouse 只需要 scan,但是 tiflash 需要把数据做一次全局排序 + mvcc 过滤,这一步是最耗时的。

2、流程及部署

2.1、流程

1、升级至4.0.0-rc

2、部署TiFlash

3、添加表至tiflash

4、会话级别设置使用tikv及tiflash

5、测试查询

2.2、机器信息 编辑

集群:xxx集群

TiDB&PD 混合部署

TiKV*3

TiFlash *1

image

ClickHouse:为单机部署

2.3、部署集群3.0.7版本

TiDB3.0.7集群部署完成

2.4、升级至4.0.0-rc

【1】、打包4.0.0-rc版本 完成

【2】、执行升级 完成

注:自己开发的工具

tidb_manage --options=upgrade -c xxx -o 3.0.7 -n 4.0.0-rc

2.5、已有集群部署TiFlash

2.5.1、设置

  1. 在 pd-ctl,开启 PD 的 Placement Rules 功能。

     cd  tidb-ansible-4.0.0-rc-xxx/resources/bin
    
     ./pd-ctl -u "http:10.xxx.x.x:xxx" -i 
    
     config set enable-placement-rules true 
    

2.5.2、部署

ssh tidb中控

su - tidb

cd tidb-4.0.0-rc-xxx

【1、配置】

配置 scale-out.yaml

【2、执行扩容】

tiup cluster scale-out TiflashTest scale-out.yaml Scaled cluster TiflashTest out successfully

3、测试

3.2、测试SQL信息

4、对比ClickHouse

结果:

ClickHouse比TiFlash减少: 74.9%

SQL:

create database test;

CREATE TABLE test ENGINE = MergeTree order by id AS SELECT * FROM mysql(‘IP:port’, ‘db’, ‘test’, ‘user’, ‘password’);

【差异原因】:

1、tiflash 因为需要支持 update,所以需要额外读取三列:handle (int64), version(uint64), del_mark(uint8); 2、clickHouse的更新存在几点问题:

  • 无法保证一定更新成功,也无法确定啥时候更新成功,因为是后台慢慢做的,两条相同的 key 不一定会merge

  • 正确性无法保证,即有可能同时读到几个数据版本,至于数据库的事务隔离性就更没法做了

3、clickHouse 只需要 scan,但是 tiflash 需要把数据做一次全局排序 + mvcc 过滤,这一步是最耗时的。

5、TiFlash使用

45.1、使用步骤

【1、添加表至TiFlash】

alter table xxx SET TIFLASH REPLICA 1;

【2、查看进度,需要available=1 后才可能使用到tiflash】

SELECT * FROM information_schema.tiflash_replica ;

  • AVAILABLE 字段表示该表的 TiFlash 副本是否可用。1 代表可用,0 代表不可用。副本状态为可用之后就不再改变,如果通过 DDL 命令修改副本数则会重新计算同步进度。
  • PROGRESS 字段代表同步进度,在 0.0~1.0 之间,1 代表至少 1 个副本已经完成同步。

【3、设置引擎,会话级别】

set SESSION tidb_isolation_read_engines = “tikv”;

set SESSION tidb_isolation_read_engines = “tikv,tiflash”;

set SESSION tidb_isolation_read_engines = “tiflash”;

【4、执行具体SQL或执行计划】

查看执行计划,如果有cop[tiflash],则说明使用到了tiflash

【5、其他优化参数,会话级,待确认优化程度】

set @@tidb_opt_agg_push_down=1;

set @@tidb_opt_distinct_agg_push_down=1;

5赞

:+1:

多谢刘老师, RC1 的话可以加一个

set @@session.tidb_allow_batch_cop = 1;
set @@session.tidb_distsql_scan_concurrency=80;

和 Clickhouse 对比另一个差异是,multi-raft和动态扩容体系让每一段数据都属于一个 Region(sharding)。ClickHouse 对数据是平扫的,而 TiFlash 则是一个 Region 一个 Region 发起读取,每个读取还包含 Region 的上下边界(为了 Sharding 自由分裂和迁移所以必须规定上下边界),这部分还有一个性能损失。上面的开关是一个新的优化特型,这个特性让 TiFlash 的性能不会受限于 TiDB 发起 Region 读取速度的限制,而是一次性将所有需要读取的 Region 请求都下发,由 TiFlash 自主决定并发读取,并流式返回。在数据大 Region 多的情况下,可能会有数倍提速,中小数据量下也会有百分比提速。 另外由于支持更新,因此粗糙索引过滤暂时关闭了,这个也是对比 ClickHouse 的一个性能损失,这个会在 6 月测试完善之后打开,类似时间维度过滤会快不少。 另外如果计算非常简单非常轻,那么就会显得 MVCC 和 Mutable 这些损失比例变大,差距最大的可能是单纯的 count (*)。但是如果是类似 TPC-H Q1 这样复杂的聚合,差距就会比较小。

2赞

“由 TiFlash 自主决定并发读取,并流式返回。” 请问这里说的“流式返回” 会保证返回结果有序吗?(因为查询是并发的)