clickhouse使用感受，优点&缺点

传统的MPP数据库由于所有的节点都要参与运算，所以一个集群的并发能力与一个节点的并发能力相差无几。如果一定要提高并发量，可以考虑增加副本数的方式，但同时也增加了RPC的交互，对性能和物理成本的影响巨大。

单表很快，官方建议用宽表；比mysql快30倍是可信的；多表关联很不好，复杂的sql往往造成oom；更新操作不擅长，使用alter table ，且是异步执行；物化视图只在第一个表有新增的时候聚合数据，源表数据变动不会同步到物化视图普通视图仅仅是sql语句的缓存，并不能提升性能；sql使用上还是有一些小区别的，很多的小区别，有一定的学习成本；并发低，官方数据100qps，即使一个查询，也会用服务器一半的CPU去查询；存储空间小

StarRocks(DorisDB) 网上资料暂时没有实际使用

一个东西，StarRocks是因为版权问题修改后的名字

一般与clickhouse比较的较多；

单表查询性能基本相同（略略好于ck）；多表关联更好；更新操作支持更好，且实时；并发更高，可以支撑数千用户同时进行分析查询，在部分场景下，高并发能力能够达到万级；提供了多种模型适配了更新操作，明细召回操作，聚合操作等业务需求。更新模型可以按照主键进行UPDATE/DELETE操作，通过存储和索引的优化可以在并发更新的同时高效的查询。在某些电商场景中，订单的状态需要频繁的更新，每天更新的订单量可能上亿。

两者有着很多的相似之处，对于分析类查询都提供了极致的性能，都不依赖于Hadoop生态圈。 StarRocks相较于ClickHouse有更好的表现。一般来说，ClickHouse适合于维度变化较少的拼宽表的场景，StarRocks不仅在单表的测试中有着更出色的表现，在多表关联的场景具有更大的优势。

elasticsearch 使用感受，优点&缺点

我使用dsl进行查询，还是需要一定的学习成本网上说查询性能弱于ck3-5倍，不过在我的实际使用中50亿数据量，机器性能够用的话，速度并不慢；（我们的集群是16个节点，每节点8Tssd，内存每台256G（要保留一半左右的缓存区），cpu也是顶级）针对上面这一条得出：es是比其他两个更耗费资源（但是大家并不能定论它存储更耗空间，es进行字段索引的话确实占用空间大，但是如果只是存储基本数据，空间还是可控的；）

下图实测了一张对比图

mysql & clickhouse & startRocks 的空间存储，查询耗时； 都采用单机部署； startRocks：1FE 1BE（硬盘为HDD） clickhouse: 单机部署 （公司服务器应为ssd） mysql：（公司服务器应为ssd）

这里进行单表扫描188万行，SUM聚合（无索引）&分组（均有索引）;10次耗时如图；（次数间隔时间为我手动记录一次耗时所需要的时间）三个db存储空间在标头栏；这里可以看到单表 ck 和 start差不多（start使用HDD，可能会慢一些）；多表关联耗时后期补充

好文链接

评论可见，请评论后查看内容，谢谢！！！
 您阅读本篇文章共花了：