跑路访谈
前段时间有个群友私信和我说，接手一个急活，需要提升后台各个页面的打开速度，保障后台批量导出可用稳定。但是系统优化了两个多月没有什么进展，如果最后两天还搞不定，就需要跑路了。
沟通了一轮，发现问题很多，但是最严重最棘手的是 sql 查询中慢 sql 太多。看了下慢查询，发现基本上都是BI报表需求，sql 特别复杂，从 sql 脚本去优化是无解了，只能另辟蹊径了。总结下，也就是业务规模发展壮大之后，数据仓库技术方案没更上，而是继续使用 MySQL 在处理。
一般的大数据平台离线处理，虽然很稳定，但是有两个缺点：
- 有延时，一般默认都是 T+1，淡然可以设置调度为分钟级别。
- 第二执行速度慢。
业务需求总结下来
- 需要对海量数据进行即时的多维分析
- 有一定的并发
- 低延时的响应速度
解决思路
我心中大概有两个选择：
- 云原生数据仓库AnalyticDB MySQL版（简称ADB，原分析型数据库MySQL版）
- 开源列式数据库ClickHouse
问了群里 ClickHouse 实践经验丰富的老李，得值要想 ClickHouse 发挥其最大的威力，最好是通过 ETL 工具来同步 mysql 表到 ClickHouse 的各个大宽表中，最好不要执行多表的联查。单表查询的速度嗷嗷快，我也看了网上一些 ClickHouse 和 ADB 的性能对比，ClickHouse 完胜。
考虑用户的数据库是阿里云的 RDS ，所以想在云上直接解决这个问题，阿里云的 DTS 专门为数据同步提供服务
方案1 优点：简单，快捷；缺点：目前仅支持DML中的Insert和Update操作，如果原来的项目里面有 DELETE 操作就会出现数据不一致的问题。所以还得选择方案2。但是方案2 比较复杂，同时业务方目前后端代码都是 php mysql 事务的写法，换成一个 clickhouse 的客户端成本还是有一些，目前最成熟和切换成本最低的应该是 java jdbc 客户端。所以没实践先搁置了。
转头调向 ADB，发现这个切换平滑很多，支持同步的SQL操作包括
- DDL操作：CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE、ADD COLUMN、DROP COLUMN；
- DML操作：INSERT、UPDATE、DELETE
同时数据库的操作方式不用变，只是类似于切换了一个从库。但是需要每个表都有自增主键。尝试了表联查视图也是正常的，语法上有少许严格，略微调整即可，更换成本低，见效快。
经过实际的测试，如下结构的比较复杂的 sql 使用的 8核16g 测试服务器 7s 左右的 sql，到 8核 32G 集群版（ 目前是 9.9元三个月,有兴趣的可以买个玩玩 ）上执行只要400ms~430ms，用了16核64G，速度又快了2到3倍，我测试的时候使用的按量付费，( 16核64G 的是 3.2元/小时 )。
虽然说性能上比 Clickhouse 还是差很多，但是开发改造成本低廉，性脚本要高很多，推荐一试。
结束语
应了一句网络鸡汤，选择大于努力，特别是对于咱们新生代农民工，我们遇到的问题，市面上一般会有一些更新型的成熟的解决方案可以解决我们遇到的一些问题。可以多花一些时间在技术调研上，而不是直接陷入细节。当然我也理解很多时候最开始不知道搜啥，慢慢搜慢慢爬会有一些线索出来，我的一个朋友老李就特别在行突破瓶颈敢于挑战新的技术方案。