clickhouse和doris，请问选哪个好点?

活跃的开源社区：Doris 拥有一个活跃的开源社区（尤其是对国内用户来说），众多开发者积极参与其中。社区提供了丰富的文档资源，包括详细的安装指南、使用教程、最佳实践案例以及 API 参考文档等，方便用户快速学习和使用。同时，社区论坛和交流群氛围活跃，用户在使用过程中遇到问题时，能及时得到其他开发者和社区成员的帮助。另外还有专门的社区论坛

国内社区规模：虽然 ClickHouse 在全球用户量极大，但相较于 Doris，其国内的社区活跃度稍显不足。问题反馈以及解决的及时性并没有Doris有优势。

极简化运维：Doris只有FE和BE两种进程，架构简单，带来最大的好处就是运维也会很简单，这两种进程又都能通过一致性协议来保证服务的高可用和数据的高可靠。Doris BE单节点故障时候，Doris副本均衡和副本补齐能够自动完成，无需人工操作；
监控与告警：提供全面的监控与告警功能，可实时监测集群的各项性能指标，如 CPU 使用率、内存占用、磁盘 I/O、查询响应时间等。通过配置告警规则，当指标超出正常范围时，系统能及时通过邮件、短信等方式通知运维人员。（Manager更加方便）
版本升级平滑：版本升级过程相对平滑，支持在线滚动升级。在升级过程中，Doris 会逐步将各节点切换到新版本，确保业务不受影响。（使用Manager升级更加顺滑）

手动运维操作多：运维过程中需要较多的手动操作。Clickhouse需要人工维护元数据，好处是数据分布可控。Clickhouse不支持数据的自动均衡，需要用户增加分片或重新建表，大幅增加业务在水平伸缩时的运维压力；重新建表在集群中进行全量数据打散，操作开销过大；
配置参数复杂：拥有大量的配置参数，这些参数相互关联且对集群性能影响较大。例如，在调整 ClickHouse Server 的内存分配参数时，需要同时考虑查询性能、数据写入性能以及操作系统的内存管理等多方面因素，稍有不慎就可能导致集群性能下降甚至出现故障。这要求运维人员对 ClickHouse 的内部机制有深入了解，增加了运维难度。
版本升级风险：版本升级可能存在一定风险，尤其是跨大版本升级时。不同版本之间可能存在兼容性问题，如数据存储格式变化、查询语法变更等，需要在升级前进行充分的测试和数据迁移准备。

SQL 兼容性：高度兼容 MySQL 协议，这使得熟悉 MySQL 的开发人员和数据库管理员能够快速上手 Doris。在使用过程中，可以直接使用 MySQL 客户端工具连接 Doris 集群，执行 SQL 语句。
丰富的数据模型：支持多种数据模型，包括 Unique Key、Duplicate Key 和 Aggregate Key 模型。Unique Key 模型适用于需要保证数据唯一性的场景，如用户表中的用户 ID 字段；Duplicate Key 模型适合日志类数据存储，允许数据重复；Aggregate Key 模型则在聚合查询场景下表现出色，能快速对数据进行预聚合处理。
并发上线无瓶颈：支持高并发，无并发瓶颈限制，100台集群可达10w QPS。

SQL 语法差异：SQL 语法与传统关系型数据库有一定差异，虽然基本的查询、插入等操作类似，但在一些高级特性和函数使用上有所不同。
数据模型相对单一：主要以 MergeTree 系列引擎为核心，数据模型相对单一。虽然 MergeTree 引擎在许多场景下表现良好，但在处理一些特殊业务需求时，灵活性不如 Doris。
不支持高并发：单条查询语句默认使用机器核数一半的CPU，因此不支持高并发的应用场景，官方建议QPS100。单条过大的查询或者过高的并发都会导致集群资源使用率过高，影响集群稳定性。

列存储格式：采用先进的列存储格式，将同一列的数据连续存储，这种存储方式在查询时能显著减少 I/O 开销。当执行一个仅涉及某几列的查询时，Doris 只需读取相关列的数据，而无需像行存储那样读取整行数据。而且针对点查场景 IOPS ，Doris还支持了行列混存，适用性更加强了。
数据压缩：支持多种高效的数据压缩算法，如 Snappy、LZ4 等。这些压缩算法能在不影响查询性能的前提下，大幅减少数据存储所需的空间。
存储分层：具备存储分层功能，可根据数据的访问频率和重要性，将数据存储在不同类型的存储介质上。例如，将近期频繁访问的热数据存储在高速 SSD 上，而将历史冷数据存储在成本较低的机械硬盘上。

独特的存储结构：ClickHouse 有其独特的存储结构，如 MergeTree 系列引擎。这种结构针对列式存储进行了优化，在数据写入时，会将数据按一定规则合并成数据块存储。例如，在写入大量用户注册数据时，ClickHouse 会将新数据与已有数据块进行合并操作，以提高数据存储的紧凑性和查询性能。但这种合并操作在高并发写入场景下可能会带来一定的性能影响。
压缩与编码：同样采用数据压缩和编码技术，如 Delta 编码、Run-Length 编码等。这些技术在减少数据存储量方面效果显著，但在某些复杂数据类型和查询场景下，编码和解码过程可能会增加查询处理时间。

查询优化器：拥有强大的查询优化器，采用基于成本的优化（CBO）和基于规则的优化（RBO）相结合的方式。CBO 能根据数据的统计信息，如数据量、数据分布等，估算不同查询执行计划的成本，从而选择最优方案。
向量化执行：支持向量化执行引擎，能充分利用现代 CPU 的 SIMD（单指令多数据）指令集。传统数据库按行处理数据，而向量化执行以列向量为单位处理数据，减少了函数调用开销和数据缓存命中率低的问题。
实时查询：对实时查询的支持十分出色，能在秒级甚至亚秒级响应查询请求。这得益于其高效的存储结构和查询执行机制。

单表查询优势：在单表查询场景下，尤其是针对大表的聚合查询，ClickHouse 表现出卓越的性能。它通过高效的列存储结构和数据压缩算法，减少了数据读取量。
复杂查询挑战：但在处理复杂的多表关联查询时，ClickHouse 面临一定挑战。由于其查询优化器在多表连接场景下的局限性，往往需要对 SQL 进行复杂的改写才能获得较好的性能。

1、FE/BE 分离架构：Doris 采用前端（FE）与后端（BE）分离的架构模式。FE 承担 SQL 解析、查询计划生成以及元数据管理的重任。其设计使得 SQL 语句能高效地被解析为可执行的查询计划，并且元数据管理模块保障了数据定义、权限等信息的有序存储与快速检索。
2、分布式存储与计算：在分布式存储方面，Doris 支持多副本机制，确保数据的高可用性。当某个 BE 节点出现故障时，其他副本节点能立即顶上，保证数据不丢失且查询不受影响。在计算层面，BE 节点间能够协同工作，并行处理查询任务。
3、弹性伸缩：具备出色的弹性伸缩能力，可通过简单的 SQL 命令轻松实现节点的动态增加或减少。（现在直接可以用Manager集群管理工具，更加方便快捷）

1、ClickHouse 架构：LSMTree聚合模型+两层汇聚查询引擎+列式存储，只有一个组件，每个组件都可以进行查询分发和执行 分布式采用Multi-Master多主架构，天然避免单点故障问题
2、依赖 ZooKeeper：ClickHouse 依赖 ZooKeeper 进行分布式协调。ZooKeeper 负责管理 ClickHouse 集群中各节点的状态信息、数据分片信息以及协调分布式事务等。虽然 ZooKeeper 是成熟的分布式协调工具，但这增加了架构的复杂性。