【产品调研】你有需要 TiDB 支持物化视图吗?参与调研可获得 100分,双肩包抽奖送!

  1. 场景描述:您当前业务中的哪些场景需要物化视图功能?
    AP 场景中,是有物化视图的,如果 tidb 能支持物化视图,也可以解决一部分问题,就不用 AP 资源了
    单个物化视图的基表(数据源)有几张表?是否有持续数据写入?
    物化视图是有不同场景的,有单表的,有多张表连接的,类似于星座模型,数据会有持续的写入,所以物化视图需要支持数据改写
    能够接受物化视图的更新延迟是多少?
    希望更新延迟,能支持自动同步,和调度式异步,能控制调度策略,满足更多的场景。基本上延迟时间是按小时来计算的。
    单个物化视图的数据量有多少?
    单个物化视图在 AP 的场景中,数据量会有亿级别
    相关表是否存在更新或者删除操作?
    维度表和基础表会存在更新和删除的场景

  2. 痛点描述:您的系统是如何支持这些业务的,有遇到哪些痛点?
    目前采用的方式有两种,依靠应用层的数据拆解实现服务链路,来满足数据重建。
    另外一种是依靠大数据的组件,传递到数仓中进行处理。
    痛点到没有,就是组件和应用过程比较复杂,运维上的要求也会比较高

  3. 功能描述:物化视图你需要哪些功能?(例如:过滤,关联,聚集,分区等)手动更新能力对于您的业务有价值吗?
    物化视图需要考虑成本问题,构建时资源占用是否会影响运行的业务,持续构建的成本核算会是一个需要规划的方向,手动更新能力肯定是有价值的,但是操作难度会比较大,产研成本也不会低

  4. 使用意向:在提供自动更新能力之前,先提供手动更新功能,您会在业务中使用吗?在优化器提供自动改写功能前,需要手动修改 SQL 以访问物化视图,您会在业务中使用吗?
    如果能够控制到 SQL 改写,以物化视图会基准,是可以优化 SQL 的结果的,能用更少的资源达到要求,为啥不用?

  1. 场景描述
    复杂查询,数据汇总,出报表。基表1-10张,有数据写入更新删除,接受延迟更新1小时,最好半小时,10分钟
  2. 痛点描述
    目前是通过实体表,外挂脚本定时更新,资源消耗非常不稳定
  3. 功能描述
    主要是过滤关联聚合,分区用的很少,手动更新有价值
  4. 使用意向
    手动数据刷新功能会使用,最好提供定时job能力,手动修改sql访问物化视图只会在新业务中使用

需要,不然查数据感觉繁琐

1 个赞

1.场景描述:
所有功能用数据库存储过程、视图实现,大量物化视图要求
2.痛点描述:
历史数据量大、全数据库实现功能,每天大量物化视图涮新
3.功能描述:
定时生成各类报告结果数据
4.使用意向:
会,不然应用改动太大

  1. 场景描述:多表关联的复杂查询需要物化视图,基表数据太大,且数据持续写入,需要立即刷新,延时不低于10秒。单个视图数据在2000万以上,存在大量更新操作。
  2. 痛点描述:基表数据大,普通视图查询不动。
  3. 功能描述:希望能支持复杂查询,即时提交的话不影响更新和插入新能。
  4. 使用意向:提供手动更新也是可以的,但是需要配合作业定时操作。

场景描述
大量的历史数据统计
痛点描述
多表关联查询复杂,基表大,统计非常耗费资源。
功能描述
多表关联,复杂查询,动态刷新。
使用意向
支持动态更新无论立即提交还是手动刷新都可以。

1.当前业务中每月汇总,出账结算数据需要物化视图,单个物化视图基表可能有5-8张,持续有数据写入,更新延迟接受1小时内,单个物化视图数据量2000w,相关表存在更新删除操作
2.写汇总的计划任务,每小时生成汇总数据。每次汇总需要几分钟,这个时间段是查不到数据的。
3.过滤 关联,有价值
4.会

1 个赞

场景描述
数据主题场景,目前还是采用传统调度到主题表中,根据修改日期定时调度,有一天一次的,有一天N次的,在业务量较小的时候执行。
痛点描述
1、数据时效性较差;
2、数据调度时查询速度慢,只能在业务较为空闲时执行;
功能描述
多表关联,复杂查询,动态刷新。
使用意向
支持动态刷新,通过物化视图内部机制实现数据自动更新。

用到物化视图的都是报表类查询,我担心上了这个功能研发产品会滥用,数据库性能会变差。

场景描述:
通常在需要频繁执行复杂查询并且希望提高性能的情况下,需要使用物化视图。
如:多表join、大量数据需要实时汇总等场景。

痛点描述:
在没有物化视图的情况下,复杂查询可能很慢或查不出来,对数据库性能产生较大影响。

功能描述:
1)普通视图的基本功能;
2)手动和自动控制物化视图的更新。

使用意向:
手动或配置自动刷新。

场景描述
数据仓库实时生成报告都会消耗大量的计算资源,并可能导致延迟
痛点描述
查询性能低, 资源消耗大。
功能描述
支持复杂查询,数据刷新。
使用意向
暂时还没有具体生产需求

  1. 场景描述:您当前业务中的哪些场景需要物化视图功能?单个物化视图的基表(数据源)有几张表?是否有持续数据写入?能够接受物化视图的更新延迟是多少?单个物化视图的数据量有多少?相关表是否存在更新或者删除操作?
    报表类需求,例如月度报表,年度报表之类的,一般源头有10张表左右,有些表是持续数据写入,更新延迟一般不会高于30分钟,数据量大概不到十万,存在更新或者删除操作
  2. 痛点描述:您的系统是如何支持这些业务的,有遇到哪些痛点?
    现在基本都是用定时脚本去刷的。
  3. 功能描述:物化视图你需要哪些功能?(例如:过滤,关联,聚集,分区等)手动更新能力对于您的业务有价值吗?
    一般用到过滤,关联,手动更新有价值。
  4. 使用意向:在提供自动更新能力之前,先提供手动更新功能,您会在业务中使用吗?在优化器提供自动改写功能前,需要手动修改 SQL 以访问物化视图,您会在业务中使用吗?
    会使用,可以手动修改sql。

场景描述
场景很多,比如:报表生成
痛点描述
目前大数据、多表关联等在业务高峰时段发起操作,而且应用主要访问的是昨天、前天或者几天、一月前的一些实时性要求不高的数据,这种访问由于资源消耗较大,由应用直接SQL查询担心影响在线其他响应级别更高的应用效率,因此一般我们会推荐用户在同城库上进行,但若没有同城库,则存在风险。另外对于这种涉及聚合统计或关联查询等SQL,并且会随着时间的推移,需要叠加变化结果,每次都进叠加10%的变化,却要访问100%的数据来重新计算,这个感觉是比较笨的。因此有些系统会在晚间或业务低峰期通过应用侧的定时任务来产生一些中间表来处理。但这种应用的复杂度会提升。
功能描述
利用资源或者业务相对空闲的时段,来产出一些目前仅能通过view来实现的物化结果,对于后续的view或sql等,有提升性能,降低应用复杂性的有点。但如何识别物化视图的刷新进展、刷新正确性是关键点。另外通常物化视图都涉及的是比较大量的数据,因此丰富的刷新模式,例如全量与增量,增量不仅针对时间递增性的改变刷新,还包含存量的变化(delete、update)的刷新。
使用意向
对我们来说,稳定与性能是最重要的,在保证稳定性能的前提下,提升易用性、更丰富的功能,可简化开发的工作,推动产品适用范围的扩展。自动化定时刷新、手动刷新等多种模式都是我们所需要的。

  1. 场景描述:
  • 业务场景: 数据分析和报表生成,其中需要高性能的查询响应。
  1. 痛点描述:
  • 痛点: 查询性能仍然无法满足高并发需求,数据更新延迟影响数据实时性。
  1. 功能描述:
  • 所需功能: 需要支持过滤、关联、聚集和分区功能。
  • 手动更新: 对业务有价值,特别是在需要确保数据一致性和准确性的情况下。
  1. 使用意向:
  • 手动更新功能: 如果提供手动更新功能,会在业务中使用,以便在需要时控制数据更新的时机。
  • 手动修改 SQL: 在优化器提供自动改写功能之前,手动修改 SQL 以访问物化视图也是可接受的,尤其是在过渡期。

太有必要了,我要严重呼吁增加物化视图

  1. 场景描述
    目前做实时数据开发,基于tidb+flink 如果有物化视图,基本不需要搭建ticdc ,kafka,flink , 还有flink ck 存储的hadoop 。
    目前基表很多,但是一般join 需要2-6张表这样子
    ,这些表全部是持续写入。
    更新延迟秒级别。
    单个物化数据量不足TB级别,到几兆(维度表)到几百G(多事实聚合) 都有。
    表均存在更新,删除比较少,我们这里目前将删除进行打flag 软删除。

  2. 痛点描述

系统目前通过基于ticdc+kafka+flink+tidb 实时 开发处理,由于flink sql 需要占用内存比较大,目前都是stream api 实现,代码维护量比较大,另外,数据血缘比较难追踪,开发周期时间长。

  1. 功能描述
    需要功能,实时更新肯定是必要的,过滤关联聚合也是需要的,还有就是能够手动updae 视图是最好的,可以根据业务调整对应调整视图逻辑。

  2. 使用意向
    手动更改SQL,手动更新均可接收

1、场景描述
复杂查询,大量数据筛选,出报表,join比较多
2、痛点描述:
通过实体表,频繁执行复杂查询会导致数据库性能下降,资源消耗非常不稳定
3、功能描述:
允许在创建物化视图时对数据进行过滤,只存储符合特定条件的数据
4、使用意向:
最好提供定时job能力,定时刷新,手动修改可后续增加

  1. 场景描述
    复制需要的数据,BI项目需要的视图,增量的物化视图,都需要,有的涉及几张表,有的涉及十几张表。
  2. 痛点描述:复杂查询时间长,BI平台反应慢。财务方面表数据量大、仓库方面数据量更大,多表查询实在是慢。
  3. 功能描述:基本的条件过滤、关联等。
  4. 使用意向:手动的可以使用。

聚合查询了,可以提升相关查询速度

场景:
某个分公司的某一个自然月月累产品的销售额分类汇总,甚至是个频繁执行的汇总语句

痛点:
数据量太大,表数量超过3个以上,内存,cpu高

功能
能够提供灵活的条件过滤,可以保证线路

使用意向

使用需求强,可以接受写延迟,满足写可以稍微延迟,满足多表关联汇总的实时快速提取需求

场景描述:数据表准实时打宽,多张表,实时持续,频繁更新。
痛点描述:离线批任务调度,数据时效性和可靠性不够。
功能描述:物化视图的过滤,关联,聚集,分区等均需要,手动更新能力有一定的价值。
使用意向:手动可做为过渡期的临时方案。

1 个赞