文档

实时物化视图

更新时间:

AnalyticDB PostgreSQL版提供了实时物化视图功能,相较于普通(非实时)物化视图,实时物化视图无需手动调用刷新命令,即可实现数据更新时自动同步刷新物化视图。

当基表发生变化时,构建在基表上的实时物化视图将会自动更新。您还可以在实时物化视图上再创建实时物化视图,当基表发生变化时,相关级联的实时物化视图也会自动更新。基于此特性可以方便地构建分析数据的实时ETL处理链路。

目前AnalyticDB PostgreSQL版的实时物化视图仅支持STATEMENT(语句)级别的自动更新,即当基表的更新语句(INSERT、COPY、UPDATE、DELETE)执行成功时,构建于基表之上的物化视图都会实时更新,保证数据强一致。

普通物化视图的详细信息,请参见物化视图管理

STATEMENT级别的刷新

STATEMENT(语句)级别一致性表示当基表的某一条语句执行成功时,实时物化视图中的数据将会同步变更。STATEMENT级别的实时物化视图可以实现当对基表的更新语句返回成功时,对应的物化视图的数据已经完成更新。更新逻辑如下:

  • 在数据库内核中,会先对基表执行更新,然后再执行对物化视图的更新。当基表更新失败时,物化视图中的数据不会发生变化。

  • 如果对物化视图更新失败,则基表的更新也将失败,基表将不会有任何变化,同时对基表执行的语句将返回失败。

如果使用显式事务(例如BEGIN+COMMIT),当基表的更新语句成功更新后,物化视图中的数据变更也同样在这个事务中:

  • 如果AnalyticDB PostgreSQL版为READ COMMITTED隔离级别(默认),当事务未提交时,物化视图中的更新对其他事务也不可见。

  • 如果事务回滚,基表和物化视图都会进行相应的回滚。

使用限制

AnalyticDB PostgreSQL版对构建实时物化视图所使用的查询语句有所限制,您只能创建如下类型查询语句的实时物化视图:

  • 如果查询语句包含JOIN,支持使用INNER JOIN语句和OUTER JOIN语句。

  • 查询语句可以包含大部分的过滤和投影操作。

  • 如果查询语句包含OUTER JOIN,JOIN条件仅支持AND连接,不支持OR或NOT等,不支持非等值条件,不支持等值条件的左右列来自同一张表。

  • 当查询语句包含聚合操作时,只支持COUNT、SUM、AVG、MAX、MIN,不支持HAVING子句。

  • 仅支持简单查询、FROM子查询及UNION ALL查询语句,不支持CTE和其它类型子查询等复杂查询语句。

当您在基表上创建了实时物化视图,对基表执行的DDL将受到限制,限制如下:

  • 对基表执行TRUNCATE命令时,实时物化视图不会同步变化,需要手动刷新物化视图或重建物化视图。

  • 只有指定了CASCADE选项,才能成功对基表执行DROP TABLE命令。

  • 基表上执行ALTER TABLE命令无法删除或修改物化视图引用的字段。

使用场景

建议您在具有如下特征的场景使用实时物化视图:

  • 基于实时物化视图及其嵌套级联能力,可以方便地构建实时ETL处理链路。既可在上游原始基表上创建实时物化视图,还可以基于实时物化视图再创建下游级联的实时物化视图产出实时ETL的处理结果,用于加速查询分析。

  • 基于实时物化视图可以大幅加速查询结果的速度。尤其针对查询结果相对于对基表仅包含少量的行或列,或者获取查询结果需要经过大量的计算处理的场景,包括:

    • 具有很高过滤性的过滤条件。

    • 高度集中的聚合函数等场景。

    • 半结构化数据分析。

    • 需要很长时间才能计算完成的聚合操作。

  • 视图的基表中包含很大的全量数据,增量数据的更新量远小于全量数据。

实时物化视图适用于所有适合使用物化视图的场景。与普通物化视图相比,实时物化视图具有高度的数据一致性,当基表发生改变时,实时物化视图将以较低的性能消耗(增量的)同步发生改变,而普通物化视图如果每次基表发生改变,都执行全量刷新操作,大部分时候将消耗较大。所以当基表具有一定程度的更改,甚至需要流式导入更新时,实时物化视图相比于普通物化视图将具有很大优势。

实时物化视图代价

实时物化视图类似实时维护的索引,在对查询性能进行大幅度优化的同时,对高性能写入有一定影响。影响实时物化视图写入性能的几个关键因素:

  • 构建实时物化视图的查询语句的复杂度和级联的层数。单表和简单JOIN的单层实时物化视图可以在不同配置的实例上支持每秒数万到数十万行的写入。复杂JOIN及多层嵌套场景的写入会占用更多的实例计算资源,同时写入能力相应成比例降低。

  • 包含JOIN的实时物化视图有可能存在写入放大的情况。例如,当某张10亿数据量的事实表JOIN一张1万数据量的维度表的实时物化视图中,10亿级的事实大表通常可以获得很高的写入性能,而1万数据量的较小维度表的数据变化由于增量计算时对结果集的影响存在放大,写入性能会成比例(写入放大的比例)降低。

  • 写入的BATCH模式。批量写入数据有利于降低实时物化视图带来的维护开销,在使用COPY或INSERT时,适当在单条语句内增加BATCH的数据行数,可以有效降低实时物化视图的开销维护。

  • AnalyticDB PostgreSQL版实例的规模和资源。实时物化视图进行增量计算和写入过程中会使用实例资源,实例的规模和资源对实时物化视图写入效率会产生影响。当实时写入的性能不满足业务需求时,可以考虑增加计算资源以获取更好的写入性能。

创建或删除实时物化视图

  • 使用CREATE INCREMENTAL MATERIALIZED VIEW命令创建一个名为mv实时物化视图,示例如下:

    CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM base WHERE id > 40;
  • 使用DROP MATERIALIZED VIEW命令删除物化视图mv,示例如下:

    DROP MATERIALIZED VIEW mv;

使用示例

  1. 创建基表。示例如下:

    CREATE TABLE test (a int, b int) DISTRIBUTED BY (a);
  2. 创建实时物化视图。示例如下:

    CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM TEST WHERE b > 40 DISTRIBUTED BY (a);
  3. 向基表插入数据。示例如下:

    INSERT INTO test VALUES (1, 30), (2, 40), (3, 50), (4, 60);
  4. 查看基表,示例如下:

    SELECT * FROM test;

    查询结果如下:

     a | b
    ---+----
     1 | 30
     2 | 40
     3 | 50
     4 | 60
    (4 rows)
  5. 查看物化视图,示例如下:

    SELECT * FROM mv;

    物化视图已经修改成功,查询结果如下:

     a | b
    ---+----
     3 | 50
     4 | 60
    (2 rows)

  • 本页导读 (1)
文档反馈