禹鼎侯的博客

我之前在ClickHouse vs Doris 读写性能比较一文中，初步做了一下ClickHouse和Doris的读写性能比较，但由于数据样本比较小，且未发挥出所有硬件资源的性能，因此进行了第二轮压测。新加入了Elasticsearch搜索引擎ClickHouse和Doris均采用多并发写入，发挥最大性能本轮测试得到了飞轮科技多位技术专家的指导，对Doris进行了一定的参数调优环境准备（硬件机器配置同上一篇文章）clickhouse集群节点IP分片编号副本编号ck9311ck941。

所谓的runtime filter，因为一般左表join右表，右表需要加载到内存，通常会比较小，所以当扫描左表和加载右表同时进行时，右表一般会率先完成，此时根据 join on cause动态生成一些过滤条件，并广播给正在各个节点扫描的左表，使得左表扫描的数据量减少，从而加速整个查询，避免不必要的网络开销。Doris物化视图比较牛逼的地方在于，它可以在查询时自动匹配，也就是说，在查询时，我们依然可以查底表，Doris会根据查询语句自动选择一个最优的物化视图进行查询，而不需要显示地指定查询物化视图。

点击主页的，就会进入创建集群的界面：： 集群的名字，注意不要和ckman已有的名字重合: 安装包类型，用来区分平台和架构，不需要自己填写，上传安装包后可通过下拉框选择。如果选择的平台和架构不正确，如在arm的机器上部署x86的安装包，则不会成功。ck的版本，不需要自己填写，通过下拉列表选择，下拉列表中会列出ckman服务器中所有的安装包版本。此处版本信息只会列出当前ckman服务下的安装包版本，如果配置了多中心，其他ckman的安装包是无法看见的在部署集群之前，需要先上传安装包。

clickhouse的容器化部署，已经有非常成熟的生态了。在一些互联网大厂也已经得到了大规模的应用。clickhouse作为一款数据库，其容器化的主要难点在于它是有状态的服务，因此，我们需要配置PVC。kubectl 原生部署这种方式部署流程复杂，需要管理的资源非常多，稍不留神就容易出错维护繁琐，涉及到集群的扩缩容、rebalance等操作会很复杂非常不推荐这种部署方式kubectl + operator部署资源集中管理，部署方便维护方便业界已经有成熟的方案，如等。

从技术实现上来说，肯定是可行的。上面有三个part，现在我的诉求是查询出其中>=3且<=5的所有数据，虽然在各个part内部，数据本身是有序的，但是这三个part很不凑巧地都包含了3~5的范围，因此必须每个part都扫描一遍，而实际上，part3是没有任何符合条件的数据的，所以这个扫描其实是无用的操作。热数据，经常会被查询的数据（比如近两三天的数据），存储到固态磁盘，这样不论是写入，还是查询都非常快，超过一定时间的数据，可以通过存储策略转移到机械磁盘上，因为查询频率并不怎么高，那么受到的影响就会有限。

模糊查询在日志存储的场景中非常普遍。ClickHouse作为大数据分布式引擎，理所当然地会被作为日志存储的备选方案。事实上使用ClickHouse作为日志存储方案，业界目前也已经在多家企业落地，比如Uber、石墨文档、映客、快手、携程、唯品会等。日志查询的一个最大的特点是，几乎极少涉猎点查询，而模糊查询则占据了绝大部分使用场景。这也是为什么ES凭借其逆天的分词能力在日志存储领域杀疯了的原因。但ES存储的瓶颈近些年也逐渐显现， 如压缩率低，需要较大的存储成本，当数据量过大时，查询性能也比较差。

无论是备份还是恢复，执行效率都非常高同压缩比备份，支持不同的备份目的地支持增量备份需要开放配置，操作性上不太友好集群备份到本地时，必须要选共享目录，如果每个分片单独备份，则无法进行数据汇总，存留于节点自身，与没有备份没什么区别，还不如多加副本数据恢复功能尚不太完备推荐一个零声学院免费教程，个人觉得老师讲得不错，分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，