Druid和Pinot中的“Segment”数据管理方法与ClickHouse中的简单数据管理相比，定义了更多的架构层次。重要的是，这种差异对潜在的压缩效率（尽管目前所有三个系统中的压缩故事都很令人遗憾）或查询处理速度几乎没有影响。
ClickHouse
类似于传统的RDMBS，例如PostgreSQL。特别是ClickHouse可以只部署在一台服务器上。如果部署的体量很小，例如不大于100个CPU核心用于查询处理和1 TB数据，我会说ClickHouse比Druid/Pinot具有显着的优势，因为它简单且不需要其他类型的节点，例如“Master”，“实时摄取节点”，“代理”。在这个领域，ClickHouse与InfluxDB竞争，而不是与Druid或Pinot竞争。
Druid/Pinot
更适用于大规模的数据，场景上与HBase类似。这不是因为它们的性能特征，而是说它们更加的强调分布式能力。它们依赖于ZooKeeper，依赖于持久性复制存储（例如HDFS），关注单个节点故障的恢复能力，以及不需要经常人工关注的自主工作和数据管理。
总结
对于应用案例的广泛性比较，ClickHouse，Druid或Pinot没有明显的赢家。首先，我建议：首先考虑理解系统源代码，修复错误，添加功能的难度。以及性能比较和系统选择。
其次，你可以看下面的表格。此表中的每行都描述了某个应用属性，这使得ClickHouse或Druid / Pinot可能是更好的选择。行不按重要性排序，因为对于不同的应用程序，每行的相对重要性是不同的，您需求根据应用场景作出选择。
| ClickHouse | Druid/Pinot |
|---|---|
| 具备C++经验的组织 | 具备Java经验的组织 |
| 小型集群 | 大型集群 |
| 少量表 | 大量表 |
| 单一数据集 | 多个不相关的数据集（多租户） |
| 表和数据集永久驻留在集群中 | 表和数据集定期出现并从群集中退出 |
| 表格大小（以及它们的查询强度）在时间上是稳定的 | 表格随时间热度降低 |
| 查询的同质性（其类型，大小，按时间分布等） | 异质性 |
| 存在可以用于分区的维度，且经过该维度分区后，几乎不会触发跨分区的数据查询 | 没有这样的维度，查询经常触及整个集群中的数据 |
| 不使用云，集群部署在特定的物理服务器上 | 群集部署在云中 |
| 无需依赖现有的Hadoop或Spark集群 | Hadoop或Spark的集群已经存在并且可以使用 |