when should i use druid
This commit is contained in:
parent
fd544ebcb9
commit
a84128fc35
|
@ -26,3 +26,22 @@ Druid的核心架构吸收和结合了[数据仓库](https://en.wikipedia.org/wi
|
||||||
10. **摄取时自动汇总聚合**,Druid支持在数据摄取阶段可选地进行数据汇总,这种汇总会部分预先聚合您的数据,并可以节省大量成本并提高性能。
|
10. **摄取时自动汇总聚合**,Druid支持在数据摄取阶段可选地进行数据汇总,这种汇总会部分预先聚合您的数据,并可以节省大量成本并提高性能。
|
||||||
|
|
||||||
### 什么场景下应该使用Druid
|
### 什么场景下应该使用Druid
|
||||||
|
|
||||||
|
许多公司都已经将Druid应用于多种不同的应用场景,详情可查看[Powered by Apache Druid](https://druid.apache.org/druid-powered)页面。
|
||||||
|
|
||||||
|
如果您的使用场景符合以下的几个特征,那么Druid是一个非常不错的选择:
|
||||||
|
|
||||||
|
* 数据插入频率比较高,但较少更新数据
|
||||||
|
* 大多数查询场景为聚合查询和分组查询(GroupBy),同时还有一定得检索与扫描查询
|
||||||
|
* 将数据查询延迟目标定位100毫秒到几秒钟之间
|
||||||
|
* 数据具有时间属性(Druid针对时间做了优化和设计)
|
||||||
|
* 在多表场景下,每次查询仅命中一个大的分布式表,查询又可能命中多个较小的lookup表
|
||||||
|
* 场景中包含高基维度数据列(例如URL,用户ID等),并且需要对其进行快速计数和排序
|
||||||
|
* 需要从Kafka、HDFS、对象存储(如Amazon S3)中加载数据
|
||||||
|
|
||||||
|
如果您的使用场景符合以下特征,那么使用Druid可能是一个不好的选择:
|
||||||
|
|
||||||
|
* 根据主键对现有数据进行低延迟更新操作。Druid支持流式插入,但不支持流式更新(更新操作是通过后台批处理作业完成)
|
||||||
|
* 延迟不重要的离线数据系统
|
||||||
|
* 场景中包括大连接(将一个大事实表连接到另一个大事实表),并且可以接受花费很长时间来完成这些查询
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue