DorisDB,ClickHouse,TiDB的对比与选型分析

• 系统对比
• 实时人群圈选场景需求说明
• 功能选型
  • TIDB
  • DorisDB
  • ClickHouse
  • 功能选型
• 性能测试

系统对比

实时人群圈选场景需求说明

1. 画像本身是一张以user_id为主键，标签为列名的大宽表；
2. 画像标签数据有大量的Array,MAP,Array<Map>等复合类型；
3. 画像标签需要实时增/删，对存储要求是：支持实时的增/删/改列的DDL语句；
4. 标签数据需实时增量的更新，对存储要求是：支持大数据量的实时UPDATE语句；
5. 人群圈选需要实时对任意标签列实施高效的组合过滤操作；

功能选型

TIDB

• 优点：

  1. 支持实时高频的UPDATE操作；

• 缺点：

  1. 复合数据类型只支持Set/JSON，对JSON来说，其内部结构不可见，Schema定义不够明确；
     JSON这种半结构化数据格式是以Binary形式进行序列化存储的（JSON本身不能创建索引，需要反序列化解析后才能做过滤操作？），用于圈选性能较差，为JSON定义的函数不够丰富，且无法通过自定义函数来补充；

  2. 数据写入当前好想只能通过 Insert Into 语句，性能一般，不支持直接导入JSON数据；TiDB 有DM工具，但只能实时同步 Mysql Binlog，缺少与多种其他存储介质的数据交换功能；Spark/Flink的Sink Connector好像没有，可能需要自己手动实现；

  3. 缺少和Hadoop生态圈的交互以及数据同步组件，可能需要通过Jdbc或TiKV API接口实现；

• 其他：

  1. 读数据有TiKV Client Java Api，Flink Source Connector是通过这个包自己定制直接读取 TiKV数据的，可以做一些Filter Push Down；

DorisDB

• 优点：

  1. 集群易维护；
  2. 支持Array这种复合结构（当前只明细模型可用）；
  3. 多表关联查询性能良好；

• 缺点：

  1. 不开源，DorisDB源码全都看不到，社区活跃度较ClickHouse差；

  2. 支持复合数据类型不够，遇到Array,Map或Array<Map>类型的标签需要打成宽表或拆表（多表Join性能良好）；

  3. 当前不支持UPDATE操作， 需要通过INSERT OVERWRITE模拟更新操作（官方说是 7 月版本会支持UPDATE）；

  4. 当前只能在Duplicate Table中定义Array类型，而圈选功能需要选择更新/聚合模型，这使得Array类型标签必须拆分到新表中，不太能满足圈人的功能需求；

• 其他：

  1. 发现一个比较怪的问题，Apache Doris和DorisDB感觉上有分歧？按道理Apache Doris和DorisDB标准版应该是同一个产品定位吧，两者间的的Flink Connector实现代码差异较大，内置的UDF函数也各不相同，源码层面二者还是有一定差别的；

  2. Apache Doris暂时不支持符合结构数据，如：Array,Map等；

ClickHouse

• 优点：

  1. 支持UPDATE操作（但性能一般，不如TiDB，可以用INSERT OVERWRITE模拟）；

  2. 有多样的表引擎和SQL函数；

  3. 支持多样的复合数据类型 Array, Map, Nested Type（但尝试写JSON数据到类型为Array<Nested>列时失败，可能是写入方法问题？）；

  4. OLAP系统，查询性能较好；

• 缺点：

  1. 集群维护成本高；
  2. 多表Join性能不稳定；
  3. 非标准SQL，有学习成本；
  4. 每个表都需要手动分区分片，在维护的表较多时，日常维护成本昂贵；

• 其他：

  1. 当前工程用的开源协议是Apache License Version 2.0；
  2. 源码没贡献到Apache社区，项目规划走向被俄罗斯团队把控；

功能选型

• 结论： 从功能角度出发更倾向于选择ClickHouse；
• 原因：
  1. ClickHouse和DorisDB在做OLAP的性能和功能上高于TiDB；
  2. DorisDB的主要问题是对复合数据类型的支持不够（比如Array），这使得很多是Array类型的列必须进行拆表操作，业务成本高，增加了标签数据写入和查询等业务实现的复杂度；Update这个必须的Feature功能尚未看到；函数支持没ClickHouse丰富，在做查询时有些过滤规则没办法实现（比如：Array hasAny/hasAll）；
  3. TiDB对复合数据类型的支持不够，只有Set，JSON这种复合结构，与Hadoop生态或其他外部存储结合度不高，数据的导入导出不够方便，支持导入的数据类型也不够丰富，使用上不太方便；函数支持上没ClickHouse丰富，没办法做Array hasAny/hasAll等操作；另外TiDB的查询性能不保证满足需求，需做测试；
  4. ClickHouse从功能角度来讲是最能满足用户圈选需求的系统，唯一的问题是维护成本较高，当前国内已有公司将Clickhouse应用到了画像场景；

性能测试

• 机器配置

• SQL 语句

-- 表`user_profile_a`数据量：4528641条
-- 表`user_profile_b`数据量：12836360条

-- SQL-1: 基本数据类型的组合过滤
select count(*) from  user_profile_b where channel_type = 'nature' and user_type = 2 and lang = 'zh_CN' and region = 'CHN' and country = 'CHN' and gender = 0;

-- SQL-2 过滤double类型数值，通过Math.random() 为每条测试数据随机生成一个score
select count(*) from user_profile_ where score > 0.2;

-- SQL-3: 数组类型的过滤
select count() from user_profile_b where hasAny(user_watch_list, ['TSLA']); -- Clickhouse
select count(*) from  user_profile_b where JSON_CONTAINS(user_watch_list, '"TSLA"', '$'); -- TIDB

-- SQL-4: 组合SQL-1, SQL-3的所有条件过滤
select count() from  user_profile_b where channel_type = 'nature' and user_type = 2 and lang = 'zh_CN' and region = 'CHN' and country = 'CHN' and gender = 0 and hasAny(user_watch_list, ['TSLA']); -- ClickHouse
select count(*) from  user_profile_b where channel_type = 'nature' and user_type = 2 and lang = 'zh_CN' and region = 'CHN' and country = 'CHN' and gender = 0 and JSON_CONTAINS(user_watch_list, '"TSLA"', '$'); -- TiDB

-- SQL-5: Join两张表，基本数据类型过滤条件
select count(*) from user_profile_b b, user_profile_a a where a.uuid = b.uuid and a.channel_type = 'nature' and a.user_type = 2 and b.lang = 'zh_CN' and b.region = 'CHN' and b.country = 'CHN' and b.gender = 0;

-- SQL-6: Join两张表，带有Array类型的过滤条件
select count() from user_profile_b b, user_profile_a a where a.uuid = b.uuid and a.channel_type = 'nature' and a.user_type = 2 and b.lang = 'zh_CN' and b.region = 'CHN' and b.country = 'CHN' and b.gender = 0 and hasAny(a.user_watch_list, ['TSLA']);  -- ClickHouse
select count(*) from user_profile_b b, user_profile_a a where a.uuid = b.uuid and a.channel_type = 'nature' and a.user_type = 2 and b.lang = 'zh_CN' and b.region = 'CHN' and b.country = 'CHN' and b.gender = 0 and JSON_CONTAINS(a.user_watch_list, '"TSLA"', '$');  -- TiDB

• 查询性能对比测试

• 性能测试使用的都是单节点的机器，因某些原因未能在同样的软硬件基础上做性能测试；
• 此处没有将DorisDB纳入对比，一方面是因为DorisDB满足不了画像场景的业务需求，比如对Array等复合类型支持不够，另一方面和DorisDB的工作人员沟通得到了一些性能方面的测试结论，自己假设了DorisDB的单表性能与ClickHouse相当，多表Join性能高于ClickHouse；
• 本次性能测试场景并不完整，单从具体得到的结果来看，ClickHouse在多表Join方面表现一般，若有多表做复杂Join或大表间做Join操作的需求，建议做更多具体的性能测试；
• 从Array查询优化来讲，在ClickHouse中可以考虑将Array转Bitmap来优化查询；TiDB有TiFlash，但不太清楚如何处理Array这类复合类型，是否能满足性能需求；
• Insert into select语句的性能大都取决于Select，非特别大数据量需写入的情况下Insert耗时相对较少；
• ClickHouse的Delete，Update语句性能不高，这个需要再做测试，或用Insert语句替换；
• ClickHouse的 optimize table $table final性能不高，1200W数据测试需要8s～14s时间，生产上使用该操作时最好单独周期执行，比如5min执行一次；