共计 721 个字符，预计需要花费 2 分钟才能阅读完成。
许多公司都曾经将 Druid 利用于多种不同的利用场景。请拜访 应用 Apache Druid 的公司 页面来理解都有哪些公司应用了 Druid。
如果您的应用场景合乎上面的一些个性，那么 Druid 将会是一个十分不错的抉择：
数据的插入频率十分高，然而更新频率非常低。
大部分的查问为聚合查问（aggregation）和报表查问（reporting queries），例如咱们常应用的“group by”查问。同时还有一些检索和扫描查问。
查问的提早被限度在 100ms 到 几秒钟之间。
你的数据具备工夫组件（属性）。针对工夫相干的属性，Druid 进行非凡的设计和优化。
你可能具备多个数据表，然而查问通常只针对一个大型的散布数据表，然而，查问又可能须要查问多个较小的 lookup 表。
如果你的数据中具备高基数（high cardinality）数据字段，例如 URLs、用户 IDs，然而你须要对这些字段进行疾速计数和排序。
你须要从 Kafka，HDFS，文本文件，或者对象存储（例如，AWS S3）中载入数据。
如果你的应用场景是上面的一些状况的话，Druid 不是一个较好的抉择：
针对一个曾经存在的记录，应用主键（primary key）进行低提早的更新操作。Druid 反对流式插入（streaming inserts）数据，然而并不很好的反对流式更新（streaming updates）数据。Druid 的更新操作是通过后盾批处理实现的。
你的零碎相似的是一个离线的报表零碎，查问的提早不是零碎设计的重要思考。
应用场景中须要对表（Fact Table）进行连贯查问，并且针对这个查问你能够介绍比拟高的提早来期待查问的实现。
https://www.ossez.com/t/apach…
