Druid架构设计 元数据存储


本教程介绍了如何通过MYsql、PostgreSQL数据库来进行元数据存储操作,并为执行过程中的数据库连接池进行了讲解。

1 元数据存储

元数据存储是Druid的一个外部依赖。Druid利用它来存储系统中的各种元数据,但不存储实际的数据。

Derby是Druid的默认元数据存储,但是它不适合实际开发环境。相反,MySQL和PostgreSQL是更适合实际开发环境的元数据存储。

注意:元数据存储包含了Druid集群工作所必需的整个元数据。对于实际开发集群,我们建议使用MySQL或PostgreSQL,而不是Derby。此外,我们强烈建议对数据库的高可用性进行规定,因为元数据一旦丢失将无法恢复。

2 使用Derby

将以下内容添加到您的Druid配置中:

druid.metadata.storage.type=derby
druid.metadata.storage.connector.connectURI=jdbc:derby://localhost:1527//opt/var/druid_state/derby;create=t

3 MySQL

参见mysql-metadata-storage扩展文档

4 PostgreSQL

参见postgresql-metadata-storage扩展文档

5 添加自定义的数据库连接池属性

注意:在数据库连接池属性的配置中,usernamepasswordconnectURIvalidationQuerytestOnBorrow这些属性不能通过druid.metadata.storage.connector.dbcp设置,而是必须通过druid.metadata.storage.connector属性进行设置。

支持的属性示例:

druid.metadata.storage.connector.dbcp.maxConnLifetimeMillis=1200000
druid.metadata.storage.connector.dbcp.defaultQueryTimeout=30000

6 元数据存储表

完成数据库连接池属性配置之后,我们来对元数据中的表进行介绍:
1)段表

段表是由druid.metadata.storage.tables.segments的属性决定的。该表存储了系统中可用的段的元数据。该表有两个主功能列,其他列用于索引。

  • Coordinator对表进行遍历,以确定可用于在系统中查询的段集。
  • used列是布尔型标识。1表示集群应“使用”该段(即,应加载该段并可用于请求),0表示不应将段主动加载到集群中。这样设置的目的是为了从集群中删除段,而非实际删除它们的元数据(这允许我们在开发中进行必要的回滚操作)。
  • payload 列存储一个JSON blob,该blob包含该段的所有元数据(存储在该payload中的某些数据与表中的某些列是冗余的,这是有意的),信息如下:
{
 "dataSource":"wikipedia",
 "interval":"2012-05-23T00:00:00.000Z/2012-05-24T00:00:00.000Z",
 "version":"2012-05-24T00:10:00.046Z",
 "loadSpec":{
    "type":"s3_zip",
    "bucket":"bucket_for_segment",
    "key":"path/to/segment/on/s3"
 },
 "dimensions":"comma-delimited-list-of-dimension-names",
 "metrics":"comma-delimited-list-of-metric-names",
 "shardSpec":{"type":"none"},
 "binaryVersion":9,
 "size":size_of_segment,
 "identifier":"wikipedia_2012-05-23T00:00:00.000Z_2012-05-24T00:00:00.000Z_2012-05-23T00:10:00.046Z"
}

请注意,此blob的格式可以而且将不时地更改。

2)规则表

规则表用于存储有关段应在何处着陆的各种规则。

Coordinator在对集群进行段(重)分配决策时使用这些规则。

3)配置表

配置表用于存储运行时的配置对象。我们还没有很多这样的机制,我们也不确定是否会继续使用这种机制,但这是一种在运行时跨集群更改一些配置参数的方法的开始。

4)任务相关的表

在管理任务时,Overlord和MiddleManager还创建和使用了许多表。

5)审计表

审核表用于存储配置更改的历史记录,例如Coordinator所做的规则更改和其他配置更改。

只有以下角色才能访问元数据存储:

  • 索引服务进程(如果有)
  • 实时进程(如果有)
  • 协调程序

因此,您只需要为这些计算机授予访问元数据存储的权限(例如,在AWS安全组中)。