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，可能会慢一些）；多表关联耗时后期补充