我应该在什么时候使用 Apache Druid

许多公司都已经将 Druid 应用于多种不同的应用场景。请访问 使用 Apache Druid 的公司 页面来了解都有哪些公司使用了 Druid。

druid_architecture_diagram

如果您的使用场景符合下面的一些特性,那么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/apache-druid/13604

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

HoneyMoose

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值