起源与背景
ClickHouse
- 开发者：Yandex公司
- 特点：专为OLAP场景设计，适合处理大宽表和数据聚合查询
Doris
- 开发者：最初由百度大数据部研发，后贡献给Apache社区
- 特点：设计目标满足大数据场景下的实时分析需求，适合即席查询和BI分析场景
运维与监控
ClickHouse
- 运维复杂性：
- 集群模式依赖第三方的组件Zookeeper，当集群规模或者数据过大之后，集群的瓶颈也会受限于Zookeeper，这便又会涉及Zookeeper集群的扩容升级等；
- 集群扩缩容不仅需要手动部署实例，还要创建新表并导数据、在配置文件中维护更新全部的节点信息；分片与副本也需要在配置文件中手动维护
- 监控：可通过系统表进行监控，也有官方的exporter程序用以通过prometheus平台进行监控，但是这需要手动部署和配置exporter程序
Doris
- 运维简便性：
- 由SelectDB开发的Manager可视化管理工具，进行doris集群部署、升级、扩缩容和配置修改等日常运维操作的一键式管理，大大的降低了运维人员的操作复杂度以及误操作的概率
- 监控：FE和BE组件均自带了适配Prometheus的metrics接口，监控接入非常的方便快捷
数据迁移
ClickHouse
- 导入性能：单表导入性能优异，但在分布式表和高并发查询方面比较的劣势
- 导入方法：常规的导出导入、clickhouse-client和引擎表等，但是面对大数据的时候都显得有一些力不从心
Doris
- 导入性能：支持多种方式，优化存储和查询引擎，实现高并发写入和查询
- 导入方法：X2Doris、Connectors、SQL Convertor等多种多样的工具，可以帮助用户将各种数据源如Presto、Trino、Hive包括ClickHouse在内的数据高效稳定的迁移到Doris集群中
易用性与技术支持
ClickHouse
- SQL语法：相对独特，需要一定的学习成本
- 技术支持：没有及时和靠谱技术支持
Doris
- SQL语法：与MySQL高度相似，学习成本大大降低
- 技术支持：社区活跃，还有官方创建的微信群，线上遇到问题能够及时的得到官方的反馈与支持
真实使用过程
- 运维人员花费一个月中的碎片时间从0到1学习，基本掌握了Doris的架构、原理以及日常操作，且具备了手动维护集群的能力，期间还花费极少的时间掌握了Manager工具的部署和使用；研发人员也仅仅花费了少量的时间完成了业务及数据从clickhouse迁移到Doris
- 浏览器中使用Manager工具操作两分钟，等待10分钟完成了一个集群的部署；操作数十秒，等待10分钟完成一个集群的升级；操作数十秒即可完成数个节点的水平扩缩容
- 在实际使用过程中遇到了多次问题，均在官方微信群中反馈后及时得到了解决办法
总结
ClickHouse有他固有的优势特点不可否认，但是Doris的众多优势下，若非特定的使用场景，那就显得不那么重要了，所以为何不选择一个让开发者和运维人都轻松的呢。
延展阅读：
中小团队怎么基于PG快速迭代创新？PostgreSQL is all you need！
如何有效利用PostgreSQL的PITR技术保护客户数据完整性？
咨询方案 预约演示
