经常在社区的用户中有看到这个需求

image1682×746 104 KB

我记得2023年2月份的上海地区活动的时候，也有小伙伴现场提及了这个需求。

image826×420 51.6 KB

image718×116 17.8 KB

随着物化视图的需求越来越强烈，

咱们的 PM 小哥哥也觉得应该响应大家的需求，来看看大家希望实现到什么的程度，

然后一起来实现“物化视图” 的功能！

欢迎大家参与调研！

参与调研回复 4 个问题即可参与抽奖获得双肩包！奖励经验值&积分 100分。

1. 场景描述：您当前业务中的哪些场景需要物化视图功能？单个物化视图的基表（数据源）有几张表？是否有持续数据写入？能够接受物化视图的更新延迟是多少？单个物化视图的数据量有多少？相关表是否存在更新或者删除操作？

2. 痛点描述：您的系统是如何支持这些业务的，有遇到哪些痛点？

3. 功能描述：物化视图你需要哪些功能？（例如：过滤，关联，聚集，分区等）手动更新能力对于您的业务有价值吗？

4. 使用意向：在提供自动更新能力之前，先提供手动更新功能，您会在业务中使用吗？在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图，您会在业务中使用吗？

【调研参与奖励】

100 经验值&积分

【抽奖奖励】

抽 1名小伙伴送双肩包，

image1436×1448 38.6 KB

没有按照要求回复4个问题无法活动抽奖哟！

【后续计划】

调研之后我们会与有强需求场景的小伙伴，随机抽取 3-5个 1v1 深入沟通产品需求，如有迭代计划将在本贴第一时间更新计划。

场景描述
场景很多，比如现金管理、报表生成
痛点描述
目前 TiDB 的大数据量下多表 join 的性能还不能 100% 满足业务需求，10表+ 的关联比较常见
功能描述
对我们来说，稳定与性能有限，功能点其次。手动更新有意义，但需要看具体操作和使用要求，运维和开发的界限还比较严格
使用意向
“先提供手动更新功能，您会在业务中使用吗”，要依赖使用要求
“动修改 SQL 以访问物化视图，您会在业务中使用吗”，应该可行，但也要看改动的成本有多少，透明肯定是最希望的

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

场景描述：
物化视图可以说是目前某一类业务强需求，之前业务明确提过，当前的主要用在获量业务，涉及营销数据、各类游戏分析大盘等；
物化视图的基表5~10张左右，单个表的数据量大概在3000万左右，宽表，基表的数据有实时或定时的写入、更新和删除操作；针对当前TiDB不支持无法视图，业务采取其他的方案替代，按照目前的情况，延迟在10min以内应该是可以接收，具体可能还需要和业务确认

痛点描述：
您的系统是如何支持这些业务的，有遇到哪些痛点？
1、当前业务采用中间表的方式，预先将多表复杂查询的结果存储在中间表中，并且该表数据会更加业务时效性的要求，定时的进行更新；
2、子查询通过CTE表达式复用子查询结果,但是在查询结果大的情况下，内存占用非常大导致OOM等问题
维表、指标表多表关联join以及子查询的性能在数据量大的情况下需要不定期进行优化，一个SQL语句几百行简直是噩梦

功能描述：
物化视图你需要哪些功能？（例如：过滤，关联，聚集，分区等）手动更新能力对于您的业务有价值吗？
1、分析需求覆盖明细数据查询以及固定维度查询两方面；
2、查询过滤涉及表中的很小一部分列
3、一些查询时间很久的关联聚合操作
4、物化视图数据更新最大能提供手动触发更新、定时触发更新和自动触发更新

使用意向：
1、在提供自动更新能力之前，先提供手动更新功能，您会在业务中使用吗？
手动更新功能应该在某些情况下会用的

2、在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图，您会在业务中使用吗？
按照目前情况，可能不会用，因为调整代价太大了

如果物化视图可以支持流式数据(类比Starrocks这类分析型数据库) 那就可以简化架构 在特定场景下效率提升巨大 意义非凡很值得开发 当然如Tidb这种分布式强一致性数据库来说 可能会有些许繁琐 但P社从未让人失望过

1、场景描述

• 在未做tidb改造之前，Oracle数据库内存在很多物化视图。总结来说这些物化视图通过dblink指向了人员权限等基础库，业务上对这些物化视图访问十分频繁（每秒上千次）。Oracle内使用物化视图定期刷新替换同义词+dblink的方式，大幅减少了高频dblink对基础库造成的压力。单个物化视图的基表（数据源）有1~5张表。基础数据库有持续数据写入但是更新不频繁，单表每日变化千行以下。原Oracle数据库物化视图更新时间为5~10分钟。单个物化视图数据量保持在几万行以内。基表存在数据更新和删除操作。

2、痛点描述

• 业务系统从Oracle转为TiDB后，为了确保依然可以访问基础库的数据。在基础库没有完成TiDB改造前需要额外搭建ogg链路，以实现相关基表向tidb的同步。在基础库改造为TiDB后，也需要额外搭建TiCDC链路、drainer链路，分别推给TiDB和Oracle库。这种方式相比过去，大幅增加了后期的运维成本。
• 对于多表关联的物化视图改造的场景，由于直接创建视图后，SQL查询无法利用到基表的索引。为了保证业务查询效率，我们是在业务用户下创建了实体表，然后通过外挂脚本的方式，取基表内时间字段，每小时插入一次新增数据，每晚全量更新一次。这种方式相比过去，降低了数据同步时效。

3、功能描述

• 建议优先满足索引创建、简单的多表关联，其他功能可以后续逐步迭代。日常运维过程中对于手动更新的使用也比较频繁。

4、使用意向

• 提供自动更新之前，可以接受手动更新，开发团队也可以接受修改SQL以访问物化视图。

1. 场景描述：
   本身就有报表快照的需求
2. 痛点描述：
   目前只能从源表取数，速度慢还耗资源
3. 功能描述：
   需要过滤，关联，聚集，分区等
   手动更新能力不需要
4. 使用意向：
   会，其实和现在差不多，现在是实体表加定时任务更新

1. 场景描述：
   有些情况下，join比较耗时，可以用这个提前join好放那里。每次查询不需要临时join，相当于join结果的缓存，这是能节省很多计算资源的。
2. 痛点描述：
   就是写少读多的业务需要频繁的计算，浪费不少资源
3. 功能描述：
   join、复杂查询
4. 使用意向：
   自动更新，如果需要手动更新，那业务还得改，不符合tidb的风格。如果这个是个临时1年内的方案，那完全可以忍一忍，忍到自动更新出来。因为业务上线就得跑很久。

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

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

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

使用意向

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

1. 场景描述：
   部分报表功能未单独拆分库，使用物化视图将3-12张表数据进行联合查询，获得大宽表分析数据。大的基表在2-4张左右，单表10个亿数据，需要定时刷新
2. 痛点描述：
   无物化视图，通过中间表实现，就要不断的对表进行手动的增删改，或者通过临时表与生产表定时切换的方式去实现。实现极其复杂
3. 功能描述：物化视图视图需要定时刷新，存储数据便于前端快捷查询
4. 使用意向：在提供自动更新能力之前，先提供手动更新功能，也是可以的，那结合触发器去做，也能达到自动的目的。在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图也是可以的

还真有
在mysql上遇到优化难点

1. 复杂列表页查询，关联表过多过，where条件过多，排序，都会造成某张表不走索引，全表扫描非常慢又浪费IO

2. 在mysql上使用了很多json字段，很多时候是虚拟列引出来做查询使用，虚拟列用虚拟模式查询的时候会非常慢，用存储模式更新表又很慢，导致只要用到json字段表的视图就非常慢，如果有物化视图应该能解决问题

3. 实时宽表汇总的视图，场景跟上面两个相似。

1. 场景描述：您当前业务中的哪些场景需要物化视图功能？单个物化视图的基表（数据源）有几张表？是否有持续数据写入？能够接受物化视图的更新延迟是多少？单个物化视图的数据量有多少？相关表是否存在更新或者删除操作？

• 业务系统中的报表功能需要需进行历史数据汇总或统计分析，大量关联查询和聚合操作需要在短时间内完成，需要通过通过物化视图实现。

• 单个物化视图的基表涉及5-10张表

• 有持续写入，但不频繁

• 能够接收小时级别的更新延迟

• 单个物化视图的数据量在百万级别

• 相关表存在更新或者删除操作，但不频繁

2. 痛点描述：您的系统是如何支持这些业务的，有遇到哪些痛点？

• 目前通过ticdc和datax将数据库抽取到下游异构数据库，再通过存储过程实现导致架构复制，维护成本大。

3. 功能描述：物化视图你需要哪些功能？（例如：过滤，关联，聚集，分区等）手动更新能力对于您的业务有价值吗？

• 手动更新功能对部分业务来说有价值，特别是在不需要频繁刷新或对延迟要求不高的场景。

4. 使用意向：在提供自动更新能力之前，先提供手动更新功能，您会在业务中使用吗？在优化器提供自动改写功能前，需要手动修改 SQL 以访问物化视图，您会在业务中使用吗？

• 在性能提升显著的场景下有使用的可能使用。

1、场景描述

• 在未做tidb改造之前，Oracle数据库内存在很多物化视图。总结来说这些物化视图通过dblink指向了人员权限等基础库，业务上对这些物化视图访问十分频繁（每秒上千次）。Oracle内使用物化视图定期刷新替换同义词+dblink的方式，大幅减少了高频dblink对基础库造成的压力。单个物化视图的基表（数据源）有1~5张表。基础数据库有持续数据写入但是更新不频繁，单表每日变化千行以下。原Oracle数据库物化视图更新时间为5~10分钟。单个物化视图数据量保持在几万行以内。基表存在数据更新和删除操作。

2、痛点描述

• 业务系统从Oracle转为TiDB后，为了确保依然可以访问基础库的数据。在基础库没有完成TiDB改造前需要额外搭建ogg链路，以实现相关基表向tidb的同步。在基础库改造为TiDB后，也需要额外搭建TiCDC链路、drainer链路，分别推给TiDB和Oracle库。这种方式相比过去，大幅增加了后期的运维成本。
• 对于多表关联的物化视图改造的场景，由于直接创建视图后，SQL查询无法利用到基表的索引。为了保证业务查询效率，我们是在业务用户下创建了实体表，然后通过外挂脚本的方式，取基表内时间字段，每小时插入一次新增数据，每晚全量更新一次。这种方式相比过去，降低了数据同步时效。

3、功能描述

• 建议优先满足索引创建、简单的多表关联，其他功能可以后续逐步迭代。日常运维过程中对于手动更新的使用也比较频繁。

4、使用意向

• 提供自动更新之前，可以接受手动更新，开发团队也可以接受修改SQL以访问物化视图。

场景描述:
一些smartbi报表展示，数据分析场景

痛点描述:
存在多表join操作，且数据量较大，性能不好

功能描述:
多表关联，数据分析

使用意向:
会考虑，但是也要看具体的情况

1 场景描述 需要的物化视图场景：单个物化视图的基表（数据源）通常有3-5张表，涉及订单、用户信息、产品属性等多个维度的数据。
2 遇到的痛点 查询性能瓶颈：复杂查询耗时长，影响用户体验。
3 功能描述 过滤：支持对基表数据进行条件过滤，以生成特定条件下的物化视图。
4 手动更新功能 在提供自动更新能力之前，如果先提供手动更新功能，我们会在业务中积极使用。

场景描述：
通常在需要频繁执行复杂查询并且希望提高性能的情况下，会使用物化视图。例如，报表生成、数据汇总、实时分析等场景。

痛点描述：
在没有物化视图的情况下，复杂查询可能会对数据库性能产生较大影响。

功能描述：
过滤、关联、聚集、分区基本都需要；在某些业务需要的情况下，需要手动控制物化视图的更新时机。
使用意向：
手动更新、手动 SQL 修改初步可能会使用。

部分客户有问到是否支持物化视图，一般这种都是重度 Oracle 用户，表关联在 10+ 以上吧，相关表存在更新操作，最好能定期自动更新，加增量更新

需求还挺强的，我们系统用tidb作为从库，又肩负着数据仓库，支持物化视图能减少相当大的开发工作。

场景描述
月度审计、日报、周报等
痛点描述
审计一般都是多表关联，时间范围跨度比较长，数据量比较大，tidb查询比较慢，cpu影响比较大
功能描述
多表关联、过滤，聚合
使用意向
现在会在hive生成，实时性有点差。

1. 场景描述：在业务中，可能需要物化视图的场景包括：

• 复杂查询的优化：当需要频繁执行涉及多表连接、大量数据筛选和排序的复杂查询时，物化视图可以预先计算并存储这些结果，从而提高查询效率。
• 数据汇总：对于需要定期生成的报告或汇总数据，物化视图可以存储这些汇总结果，减少每次生成报告时的计算负担。
• 数据缓存：在高并发的系统中，物化视图可以作为数据的缓存层，减少对基表的直接访问压力。

在这些场景中，单个物化视图的基表可能涉及多张表，具体数量取决于业务逻辑的复杂性。如果业务涉及到实时数据处理，物化视图可能需要较低的更新延迟，例如几秒到几分钟。数据量则取决于业务规模和查询的复杂度，可能从几千到数百万条记录不等。相关表的更新和删除操作会影响物化视图的准确性，因此需要定期或实时更新物化视图以保持数据一致性。

2. 痛点描述： 在没有物化视图的情况下，系统可能面临以下痛点：

• 性能瓶颈：频繁执行复杂查询会导致数据库性能下降，尤其是在高并发环境下。
• 资源消耗：每次执行复杂查询都会消耗大量CPU和IO资源，增加系统负载。
• 数据一致性问题：在多用户环境中，频繁的数据更新可能导致数据不一致，影响业务决策。

3. 功能描述： 可能需要的物化视图功能包括：

• 过滤功能：允许在创建物化视图时对数据进行过滤，只存储符合特定条件的数据。
• 关联功能：支持多表关联，以便在物化视图中存储关联查询的结果。
• 聚集功能：提供对数据进行聚合操作的能力，如求和、平均、最大值等。
• 分区功能：支持物化视图的分区，以便更有效地管理和查询大规模数据集。
• 手动更新能力：在某些情况下，可能需要手动控制物化视图的更新，以适应特定的业务需求或优化性能。

4. 使用意向： 对于那些对数据一致性要求不是特别严格的场景可能是有用的。