when should i use druid

GettingStarted/chapter-1.md

@@ -25,4 +25,23 @@ Druid的核心架构吸收和结合了[数据仓库](https://en.wikipedia.org/wi
 9. **近似算法**，Druid应用了近似count-distinct，近似排序以及近似直方图和分位数计算的算法。这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid还提供了精确count-distinct和精确排序。
 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支持流式插入，但不支持流式更新（更新操作是通过后台批处理作业完成）
+* 延迟不重要的离线数据系统
+* 场景中包括大连接（将一个大事实表连接到另一个大事实表），并且可以接受花费很长时间来完成这些查询
+