这阵子对OLAP数据库产生了兴趣，先是简单测试了ClickHouse，性能的确不错，不过它在稳定&可靠性，整体生态&周边配套方面还有待加强，我会持续保持关注。
3月27日，腾讯云推送的文章 TXSQL(TencentDB for MySQL) 8.0特性介绍中提到即将推出 基于MySQL框架的列存引擎CSTORE，看了下架构图，和以前红极一时的 infobright 有点神似。
不过现在还没上线，还不能开始内测，只能看看了。
转过身看看阿里云，发现有 分析型数据库MySQL版（AnalyticDB，简称ADB） 以及 云数据库ClickHouse可选。
ADB的产品介绍可以看官方文档 什么是分析型数据库MySQL版，我抓取了其中几个关键技术信息：
- 云端PB级高并发实时数据仓库。
- 采用关系模型的行列混存技术。
- 自动索引，智能优化器。
- 高度兼容MySQL和SQL 2003语法。
- 可对RDS直接创建一个分析实例，构建ADB，并利用DTS实现数据同步。
看着很牛逼，有木有，那就测测呗。
1. 新建RDS实例和ADB实例
我选择的RDS实例对标之前用于测试ClickHouse的规则
- 4CPU
- 16G内存
- 500G存储
选择ADB实例时，系统会根据RDS中的数据量，只显示符合条件的规格，我这里选择的是 3.0版本、T16型号、存储空间 600G。
2. 导入测试数据
老样子，用ClickHouse官网提到的dbgen工具生成测试数据，生成数据时选择 -s 100 参数。
然后在RDS实例中分别导入到几个测试表。
MySQL [testabc]> load data local infile '/data/ssb-dbgen/customer.tbl' into table customer fields terminated by '\t';
提醒：ClickHouse官网提供的建表DDL需要自己微调下，改成适用于MySQL的语法和数据类型。
3. 创建数据同步DTS任务
DTS的工作机制类似 pt-table-sync，需要每个表都要指定一个主键，这就让我很不开心了。
生成的测试表中，是在其他表都导完数据后，再用 CREATE...SELECT创建的。
几个测试表的总数据量是604,637,902(6亿)，创建完DTS同步任务后，经过22.5小时候，同步的数据量约为325,174,022条，完成率53.78%，折算下来每秒约3990条记录，这个速度如果是OLTP数据库也还算可以，但放在海量数据的OLAP场景下，可就有点慢了。
对了，我选择的是 medium规则，号称最高同步性能 5000 records/s。
DTS启动、停止
同步进度
由于测试经费预算有限，我只能放弃全量数据同步，有多少算多少吧。
接下来的事情可就有点头疼了。
上面说了，lineorder_flat表是 CREATE...SELECT 创建的，而这个语法在ADB中是不支持的（产品页面上宣称全面支持MySQL语法，产品经理果然很会画大饼啊，哈哈）。
好嘛，我退而求其次，改成 在RDS中先创建一个空表，让DTS把表结构同步过去，再在ADB中用INSERT...SELECT写数据。
由于lineorder_flat原表是没有主键的，我需要新建一个自增INT做主键，否则DTS配置阶段是过不去的，无论我选择分区表还是维度表，都必须指定主键列。
分区表模式下：
维度表模式下：
好了，变通之后表结构是同步过去了，可是在ADB上执行 INSERT...SELECT时，弹出下面的错误提醒：
而上面这条SQL，如果把所有列读取出来，再手动构造成INSERT写入，则不会报错，这就尴尬了，搞不懂具体是错在哪里。
不得已，只能回到RDS实例上，硬着头皮对其他几个表都先加上主键和必要，再生成测试数据了。
在RDS主库上往lineorder_flat表中写入1000万条数据，等到DTS同步完成后，再在ADB上跑测试SQL。
4. 执行测试SQL
下面是几个测试SQL执行耗时、返回数据，和ClickHouse运行结果的对比（提醒：CH的数据量是6亿，ADB的数据量是1000万，相差60倍）。
| SQL | ADB(毫秒)/返回数量 | CH(秒)/返回数量 | CH扫描数量(10万) |
| Q1.1 | 33/0 | 2.141/1 | 91.01 |
| Q1.2 | 33/0 | 0.320/1 | 7.75 |
| Q1.3 | 31/0 | 0.053/1 | 1.81 |
| Q2.1 | 271/100 | 17.979/280 | 600.04 |
| Q2.2 | 385/56 | 3.625/56 | 600.04 |
| Q2.3 | 99/7 | 3.263/7 | 600.04 |
| Q3.1 | 383/100 | 6.906/150 | 546.67 |
| Q3.2 | 130/100 | 5.330/600 | 546.67 |
| Q3.3 | 96/24 | 3.666/24 | 546.67 |
| Q3.4 | 65/2 | 0.058/4 | 7.76 |
| Q4.1 | 304/35 | 10.110/35 | 600.04 |
| Q4.2 | 519/100 | 1.928/100 | 144.42 |
| Q4.3 | 67/772 | 1.373/800 | 144.42 |
在ADB中没办法看到每次扫描了多少条数据，因此少了这项数据。
看起来性能还算可以，就是不知道如果数据量一样的话，结果又会如何。
这次的测试就先到这里吧，以后有机会再继续。
本次测试得到了DTS产品经理的帮助，感谢。
</div>
