本文主要讨论对来自其他类型数据库系统的用户的提示,以及常规提示和通用做法。
维度列
或指标列
。这遵循 OLAP 数据的标准命名约定。维度列
按原样存储,因此可以在查询时对其进行过滤,分组或聚合。它们可以是单个字符串,字符串数组,单个 Long,单个 Doubles 或单个 Float。指标列
是预先聚合
存储的,因此它们只能在查询时聚合(不能过滤或分组)。它们通常存储为数字(整数或浮点数),但也可以存储为复杂对象,例如[HyperLogLog sketches 或近似分位数]。即使禁用 rollup,也可以在摄取时配置指标,但启用 rollup 时最有用。(如 Hive 或 PostgreSQL。)
Druid 数据源通常等效于关系数据库中的表。Druid 的lookups
行为与数仓型数据库
的维表相似,但是正如您将在下面看到的那样,如果可以避免,通常建议使用非规范化。
关系数据建模的常见实践规范:将数据分为多个表,这样可以减少或消除数据冗余。例如,在"sales”表中,关系建模的最佳实践需要一个"product id”列,该列是单独的"products”表中的外键,该表又具有"product id”,"product name",和"product category”列。这样可以避免在"sales”表中引用相同产品的不同行上重复产品名称和类别。
而在 Druid 中,通常使用完全展平的数据源,这些数据源在查询时不需要 join。在" sales”表的示例中,通常在 Druid 中将" product_id”," product_name”和" product_category”作为维度直接存储在 Druid" sales”数据源中,而无需使用单独的" products”表。完全平面的架构大大提高了性能,因为在查询时消除了 join 的需求。作为额外的速度提升,这还允许 Druid 的查询层直接对压缩的字典编码数据进行操作。也许违反直觉,相对于规范化的架构,这并没有实质性增加存储空间,
在 Druid 中建模关系数据的技巧:
(如 OpenTSDB 或 InfluxDB。)
与时间序列数据库类似,Druid 的数据模型需要时间戳。Druid 不是时间序列数据库,但是它是存储时间序列数据的优秀选择。其灵活的数据模型使它既可以存储时间序列数据,也可以存储非时间序列数据,即使在同一数据源中也是如此。
要在 Druid 中获得最佳的时间序列数据压缩和查询性能,像时间序列数据库通常那样,按 dimension 标准名称进行分区和排序非常重要。
在 Druid 中建模时间序列数据的提示:
指标
。通常,这包括"sum”,"max”和"min”(long, float, double 类型)。(例如 Elasticsearch 或 Splunk。)
与日志聚合系统类似,Druid 提供了反向索引以进行快速搜索和过滤。与这些系统相比,Druid 的搜索能力通常较不发达,而其分析能力通常也较发达。Druid 与这些系统之间的主要数据建模差异在于,将数据提取到 Druid 中时,您必须更加明确。Druid 列具有预先特定的类型,而 Druid 暂时不支持嵌套数据。
在 Druid 中建模日志数据的提示:
flattenSpec
展平数据。本文翻译自 Druid 官方文档
欢迎关注公众号,一起学习 Druid 及更多数据存储相关知识。