导读：
前文介绍了Databend对ceph的支持，也带着大家简单部署了一下。
下面就来讲讲Databend的实际应用吧。
一、数据归档选型
线上的大量的历史数据，比如日志数据，交易流水。
如果继续存在MySQL中，会占有很大的存储空间，会对线上业务性能造成抖动。但是业务还有读取的需求，不能彻底删除，甚至还有一定的分析需求。
例如：业务想计算一下 2000年 某个月某个条件的总数等等。
就要考虑对数据进行定期归档，现在归档数据库类型的选择也有很多，可以使用pt-archiver工具进行归档，或者DBA自己写的小程序进行归档。
那么归档数据的选择，首先要满足以下条件：
兼容MySQL协议，这样业务的改动最小。如果选择其他的协议，业务改动较大。
高性能的压缩比，可以节省存储成本。
有一定的计算分析能力。
那么在归档库的选型中就有几种可以参考：MySQL(单独归档集群)、TiDB、Databend等。
二、数据压缩对比
产生2亿的数据分别导入到TiDB、MySQL、databend、TiFlash看一下数据的压缩情况。
物理大小 | |
sql文本 | 88G |
csv文件 | 84G |
databend | 8G |
MySQL | 47G |
Tikv | 13G |
TiFlash | 6.7G |
其中tiflash的压缩比看起来压缩比最好，但tiflash无法单独使用。
databend和Tikv，压缩效果都不错，但databend相对而言要更好一些。
这取决压缩算法和二者不同的数据库架构。
databend 采用 lz4 压缩算法。
Tikv采用rocksdb存储引擎，rocksdb采用多层的设计架构。
compression-per-level = ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]
Tikv设计的方式，是处于OLTP的性能考虑。适合高并发读写等场景。
但数据库归档场景，是批量写，偶尔读，或大范围读取，场景不同。
三、数据分析类型查询测试
主要测一下MySQL、Databend、TiDB、Tiflash 对于一些计算类型的SQL查询响应时间。
环境描述：
服务器硬件配置：40C 256G SSD硬盘。
MySQL：Innodb buffer pool设置 100G，SSD硬盘。
TiDB：tikv readpool.unified.max-thread-count: 16 \ storage.block-cache.capacity: "32GB" ，SSD硬盘。
Databend：默认配置，但S3是机械硬盘。
| select count(*) from ontime; | |
| 执行时间 | |
Databend | 0.02 sec |
| MySQL | 4 min 9.05 sec |
| TiDB | 10.11 sec |
| Tiflash | 0.82sec |
select count(*),Year from ontime group by Year; (没索引) | |
| 执行时间 | |
| Databend | 1.89 sec |
| MySQL | 5 min 19.20 sec |
| TiDB | 38.90 sec |
| Tiflash | 0.44sec |
| select count(*),Year from ontime group by Year; (year索引) | |
| 执行时间 | |
| Databend | 1.89 sec |
| MySQL | 2 min 46.72 sec |
| TiDB | 10.43 sec |
| Tiflash | 0.44sec |
测试结论：Databend 和MySQL和TiDB进行分析类型的SQL响应时间对比还是有一些优势的。
跟Tiflash相比，虽然Databend略逊一筹，但如果给Databend换成SSD硬盘，应该会缩短差距。
四、MySQL协议兼容性
Databend支持MySQL协议、clickhouse协议、HTTP协议。
使用MySQL程序基本上可以无缝兼容Databend。
五、总结
在数据库归档上Databend相对MySQL、TiDB-TiKV还是很有优势的，比如数据压缩方面，数据分析类型SQL查询方面。
目前来说Tiflash，不支持单独使用，需要配合TiKV使用。
而且TiDB、Tiflash都推荐使用SSD，而Databend可以使用机械硬盘，并不需要太好的硬件就能跑出很好的效果。
如果大家有归档分析场景的场景，也推荐大家尝试一下Databend。
单纯归档的化，成本可以降很多。如果后面需要计算了，还可以利用Databend 优秀的特性：比如可以轻松的扩展。
