在存算分离模式下，GaussDB(DWS)支持搭建跨VW集群，各VW间共享数据但不共享缓存。新的VW创建时，其缓存为空，可能影响查询性能。为此，GaussDB(DWS) 提供缓存预热功能，允许用户从远端存储主动拉取数据至本地缓存。该功能支持以下两种模式：表数据预热：预热指定表 A 的数据。warmup信息解读：Read Cache Size : 从磁盘缓存中读取的数据sizeWrite Cache Size : 从OBS读到本地缓存的数据sizeAvg Write Cache time : OBS请求的平均执行时间对于3.0表，由于数据的实际存储位置位于OBS，增强了sql语句级别的对OBS读写请求统计信息的监控，辅助定位特定sql慢。可以通过topsql以及explain performance 查看特定语句的obs读写统计信息。当前云上的集群的磁盘缓存默认是打开的，即对所有v3表的访问都会使用到磁盘缓存。可以通过以下方式检查当前集群的磁盘缓存是否打开：DN上执行"show enable_aio_scheduler; show obs_worker_pool_size"；确保enable_aio_scheduler=on, obs_worker_pool_size >=4;CN上执行"show enable_disk_cache"，确保enable_disk_cache=on上述两点必须同时满足。

对于云上环境，对不同云盘的访问会走不同的网卡，因此不同云盘的带宽是可以叠加的。在有多块云盘（EVS）的情况下，GaussDB(DWS)支持设置多块盘作为缓存的路径，尽可能将 cache 文件分散在不同云盘上以提升缓存访问的性能。为了提升集群正常时主DN的性能并充分利用节点上的磁盘空间，目前会默认使用主备两块硬盘作为当前节点上主DN缓存介质，通过查询以下参数查看相关信息：通过 disk_cache_base_paths 参数查看和增减缓存硬盘路径，举例某个节点上的目录配置，实例名为h10dn1：主DN多盘缓存路径默认如下：路径1：/DWS/data1/h10dn1/primary0/disk_cache路径2：/DWS/data2/h9dn1/primary0_disk_cache备DN多盘缓存路径默认如下：路径：/DWS/data2/h9dn1/secondry/disk_cache备机的多盘缓存路径与当前节点上主DN的缓存路径2在同一块盘上，因此限制备机升主后的磁盘缓存空间最大为1GB，性能对比切换前会有较大劣化，需要尽快修复集群至均衡状态。

A0队列可使用的缓存空间固定为1GB， TTL 队列和LRU - 2Q队列共同使用由GUC参数 disk_cache_max_size 设置的缓存空间，初始状态时缓存空间都给LRU - 2Q使用，在后续访问到设置TTL属性的数据或者TTL中有大量数据过期时，会动态调整TTL队列与LRU - 2Q队列的比例关系，以充分利用缓存空间，TTL所使用缓存空间的最大比例不超过 disk_cache_ttl_max_ratio。TTL过期淘汰当有新的数据进入TTL队列时，会将部分已经过期的数据淘汰至LRU - 2Q队列。后台线程会定期清理TTL中已过期的数据，并淘汰至LRU - 2Q队列。TTL自身LRU淘汰当TTL空间使用达到上限，且没有过期的数据时，会触发自身的LRU淘汰策略，被淘汰出去的数据会进入LRU - 2Q队列。TTL主动淘汰当用户删除设置了过期时间的表数据时，后台线程会定期清理TTL中无效的数据。当有新的数据插入且当前LRU空间使用达到上限，会触发自身的LRU淘汰策略，被淘汰出去的数据会被清除缓存。当TTL队列空间不足，但未到达上限，会抢占LRU - 2Q队列的空间。如果LRU - 2Q的空间已满，也会触发自身的LRU淘汰。LRU - 2Q主动淘汰当用户删除设置了过期时间的表数据时，后台线程会定期清理LRU - 2Q中无效的数据。

TTL 策略确保新导入的数据在缓存中保留一段时间不被淘汰。在这段时间内，数据具有最高优先级，且所有 TTL 数据之间地位平等，不会因为某些数据即将过期而被提前淘汰。当TTL缓存空间不足时，会尝试抢占LRU队列的空间，以确保 TTL 数据能够被写入，TTL队列最大可使用的空间由guc参数disk_cache_ttl_max_ratio 控制，默认值是0.5，即整个缓存空间的一半。当TTL队列的缓存空间到达上限后，如果仍然有新的数据要进入TTL队列，此时会触发TTL队列自身的LRU淘汰，被淘汰的数据将进入到LRU空间中。应用场景：TTL 策略特别适用于希望在本地持久化的小规模数据表。对于常驻表，可以设置较长的 TTL 值来保护其数据；对于实时表，可以根据热数据的活跃时间设定相应的 TTL 值。GaussDB(DWS) 采用基于 LRU 的多队列策略，根据 TTL 属性及冷热属性将数据分为三类，分别置于 TTL 队列、LRU - 2Q队列、A0 队列中。设置了 TTL 属性的热数据被放置到 TTL 队列，没有设置 TTL 属性的热数据被放置到 LRU - 2Q队列，冷数据都放置到A0队列中。在数据读取和写入过程中，GaussDB(DWS) 会地选择填充和读取的队列，以最大化缓存利用率。 

云计算时代下的存算分离架构将计算和存储解耦，存、算、元数据分离成为趋势，将大量用户数据存放在云端存储。在此背景下，需要频繁地同OBS云端存储进行读写交互，为了尽可能的提升云上数据的处理速度，GaussDB(DWS)通过利用本地硬盘上的缓存来加速数据访问，并采用了一种先进的多队列 LRU（Least Recently Used）策略来高效管理缓存空间。针对跨VW的应用场景，DWS 还提供了缓存预热功能，以便在弹性VW建立时，能够迅速加载特定数据（如表或分区）到缓存中，从而提升查询性能。LRU 通过维护一个数据访问队列来管理缓存。当数据被访问时，该数据会被移动到队列的前端。新加入缓存的数据同样会被置于队列前端，以防止其过早被淘汰。当缓存空间达到上限时，队列尾部的数据将优先被移除。GaussDB(DWS) 通过引入LRU-2Q算法，优化了LRU的缓存污染问题，确保了核心业务的热数据不会因为访问大量历史数据而被冲刷出缓存。

dws怎么获取分布式表结构呢

我们来看下字段随意定义导致的严重资源消耗问题。   一、存储空间差异实际存储：varchar仅存储实际字符长度+1/2字节长度标识，存储相同内容时两者占用空间相同。如存储10字符数据时，两者均占用11-12字节。潜在扩展影响‌：当数据接近定义长度上限时，varchar(2000)可能比varchar(50)多消耗约40倍存储空间（按最大长度计算）。 二、性能影响索引效率‌： 过长的varchar定义（如2000）会导致索引键值变大，降低B-tree索引的节点密度，增加IO操作次数。内存消耗‌：  排序操作（如ORDER BY）时会按定义长度分配内存，而非实际数据长度，varchar(2000)比varchar(50)实际多消耗40倍内存。查询优化器‌：优化器可能因字段长度定义过大而错误估算内存需求，影响执行计划选择。 我们有时候不清楚资源消耗在哪里，为什么这么小的表，消耗内存会这么大，分析系统中  ORDER BY ,  GROUP BY 是家常便饭，定义region_name 为100 和 定义它为 2000,  内存消耗就相差 20 倍， 也许是为了后续不用更改长度，一劳永逸，也许就是全字段皆 2000 ，懒得设计，敏捷的不能再敏捷   。 但上线后， 运行态并发一来，各种排队或资源不足  。 不止ORDER BY , GROUP BY存在这种问题，其他算子有些也存在类似问题。    三、设计规范问题数据完整性‌： 随意使用varchar(5000)会丧失字段长度的约束作用，可能导致存储非预期数据  。资源浪费‌：  定义远大于实际需求的长度会浪费内存池资源，尤其在MPP架构下会影响并行计算效率。      四、不建议随意定义varchar长度的原因行存储限制‌：DWS中单行数据总长度受页大小限制（默认8KB），多个varchar(5000)字段易触发行溢出。维护困难‌：    过大的长度定义会掩盖真实业务需求，增加后续schema优化的复杂度。 建议根据实际业务需求精确设定长度，通常预留20%-50%的扩展余量即可。对于不确定长度的字段，可先采用适中的长度（如varchar(255)），后续通过ALTER TABLE调整。记得Oracle时代，各种评审单位都会对生产上线的表定义，长度，合理性进行评审。   现在是敏捷了， 但是问题却从设计，开发逐步转移到了后端运维  。成本不会消失，只是转移 。  目前只能靠更多的机器堆砌扩容和持续的整改优化来弥补设计上的缺失  。稳定性左移貌似落地太慢 。转载--原作者王琦

一个字符串长度为30，给这个字段设置varchar(50) 和varchar(5000) 有区别吗？插入的时候，占用的空间一样吗？查询的时候，效率一样吗？

TopSQL注意事项cid:link_3记录函数入口语句cid:link_4JDBC执行的带占位符语句cid:link_5operator_realtime级别TopSQL运行监控cid:link_6query_plan原理cid:link_0算子级TopSQL监控cid:link_7TopSQL与其他视图交互cid:link_8TopSQL原理介绍cid:link_9sql_hsah信息cid:link_1数据库弹性扩缩容降本增效cid:link_10弹性资源池cid:link_11手动弹性cid:link_12手动弹性VW的使用方式cid:link_2DDL设置cid:link_13路由策略https://bbs.huaweicloud.com/forum/thread-0208194605946543211-1-1.html

我们支持的路由策略有三种：路由策略none：主VW作业不会卸载到弹性VW上；路由策略dedicated：主VW作业可以卸载专用弹性VW；路由策略elastic：主VW作业可以卸载到专用和公用弹性VW。我们仍然以数据中台团队为例，介绍比例路由方式的案例。数据中台业务用户user1绑定主VW matedata_group1，user2绑定主VW matedata_group2。两个用户提交的作业既包含ETL负载，也包括一些DML业务处理负载。在每日的凌晨12点到6点，ETL负载变高。团队通过在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定主逻辑集群选项卡设置为matedata_group1，集群名称设置为compute_group1。matedata_group1的60%作业卸载到专用弹性VW compute_group1执行。后续团队发现，由于user1提交的作业负载太高，一个弹性VW仍然不能满足需求，而且，user2提交的作业负载也需要卸载一部分到弹性VW执行。但是出于经济成本考量，在额外新建2个弹性VW成本很高。最好的方式是新建一个弹性VW，新建的弹性VW能够处理user1和user2的作业。此时，团队可以选择elastic路由策略。

在凌晨12点到6点，这两个用户将会提交大量的数据导入负载，如果完全在主VW执行，将会花费大量时间，影响其他业务执行。数据中台团队可以在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定用户选项卡设置user1，集群名称设置为compute_group1，设置完成后，在每日的凌晨12点到6点，user1提交的所有作业将会到新建立的弹性逻辑集群 compute_group1执行。而user2提交的作业仍然在原有的metadata_group执行。如果避免ETL业务影响其他业务执行，团队想将user2提交的作业也到弹性VW执行（即增加用户与已经创建出来的弹性VW的绑定关系），可以手动执行DDL，将多个用户绑定到同一个弹性VW上。无需绑定用户，手动弹性VW创建完成后，用户通过DDL设置主VW的作业路由策略和路由比例，内核自动会将作业按照比例分配到主VW和弹性VW上。

客户提交的作业具体到哪个VW执行，依赖于创建时的配置。具体来说：如果在创建时勾选了绑定具体的用户，则作业将会以用户绑定方式路由。如果在创建时勾选了绑定主逻辑集群，我们将这种配置创建出来的弹性VW称之为专用弹性VW。内核以比例路由方式将所绑定的主VW的作业路由到专用弹性VW，即专用弹性VW只会接受来自绑定的主VW的作业。如果在创建时绑定用户和绑定主逻辑集群均没有选择，我们将这种配置创建出来的弹性VW称之为公用弹性VW。内核以比例路由方式将主VW的作业路由到公用弹性VW，即公用弹性VW可以接受来自集群内所有主VW的作业。总结来说，手动弹性VW的作业路由方式主要分为两种：用户绑定方式和比例路由方式。公司的数据中台团队在每天的凌晨12点到6点执行ETL，完成大数据量的离线导入。团队使用不同的用户账户执行ETL，由于凌晨12点到6点的ETL负载变高，我们可以创建新的弹性VW消费突发的负载，并以用户绑定方式实现不同用户间的ETL负载隔离。具体来说，用户user1和user2，他们分别负载导入不同业务模块的数据。

手动弹性，顾名思义，客户需要手动设置弹性资源的扩容和缩容。具体来说，公司的数据中台团队在每天的凌晨12点到6点执行ETL，完成大数据量的离线导入，ETL负载存在两个阶跃式的增长。在手动弹性的帮助下，DWS在12点时会定时准备好弹性VW 1以消费第一阶段的负载增长，而在凌晨4点又由于负载再次增加，仍会定时准备弹性VW 2来满足第二阶段的负载突发。数据导入大约持续到6点，DWS会定时回收2个手动弹性VW。在此过程中，客户只需要额外为零点到6点这段时间额外付费，无需要对主VW进行资源超配，降低成本。手动弹性不仅可以应对周期性负载突发情况，而且也可以扩展计算资源以实现计算加速。例如，在周期性跑批作业的场景下，固定资源池也可以胜任，但是作业整体完成时间会变长。手动弹性提供额外的计算资源，近线性地加速作业完成时间。在集群列表中，单击集群名称，进入“集群详情”页面，点击“添加增删计划”并设置合理的弹性计划。如图6所示，我们需要设置计划类型和集群名称。我们提供一次性增删计划和周期性增删计划两种方式，其中一次性增删计划，创建完成时间和开始删除时间不是必选项（如果未设置，则立刻创建，删除需要手动删除）。在周期性增删计划中，创建完成时间和删除时间必须设置，支持设置每周或者每月的弹性计划，也支持多个时间段的弹性计划。设置完成后，DWS管理面会按照预期设置的时间进行弹性VW的创建和删除。 

DWS存算分离版本（DWS 3.0）存在两个核心逻辑概念：固定资源池和弹性资源池。固定资源池：根据业务需要，部署多个固定VW（Virtual Warehouse），又称主VW。不同业务绑定不同的VW，并提供业务间的负载隔离。主VW的大小在MPP架构下决定了单SQL的上限以及所能处理的QPS的极限。主VW适合承接负载稳定以及低时延的作业。DWS提供分VW的水平扩展能力，通过扩展更多节点资源来满足业务扩张的需要。管理员需要根据长期的负载推演变化趋势来提前规划主VW的规格大小。弹性资源池：适用于细粒度时间范围的负载波动场景，存在一个或多个弹性VW。弹性VW在存储上实现了以OBS为基础储存的shared storage架构，而在计算上则是shared nothing架构。这就决定了计算和存储充分解耦，计算和存储可以实现分层扩展。计算节点扩容无需数据重分布，存储资源按需扩容，实现无限容量存储。弹性VW与主VW之间实时数据共享以解决元数据实时同步问题，避免元数据的滞后刷新，使得弹性VW能够实时利用最新的元数据进行作业执行。本篇文章主要介绍DWS手动弹性VW方案。

随着公司业务的蓬勃发展，为了满足公司业务的扩张，数据库扩容是业界通用的解决方案。业务负载在长时间维度上推演，定量扩容是一个很好的解决方案，能够支撑更多的业务并发。但是在细粒度的时间维度上，例如具体到每周甚至每日，传统的扩容模式仍然以资源超配的方式对抗业务负载波动。考虑图2中的场景，公司的数据中台团队，在每天的凌晨12点到凌晨6点执行ETL，完成大数据量的数据离线导入；业务团队每天作业负载呈现出无规律的负载波动。传统扩容的资源超配将会浪费大量资源，使用成本高。理想情况下，如果数据库能够根据负载波动主动地实现扩容和缩容，按需实现资源的调整能够极大地降低成本，减少资源浪费。为了更灵活、更低成本地实现数据库的扩缩容，数据库系统提供较小资源规格，以满足基础作业负载，又能在业务负载高峰期间快速扩容，保障业务的稳定性。DWS的存算分离版本中，实现了上诉的按需弹性，解决细粒度时间维度上的负载波动，主动地按需扩容弹性资源，以保障负载短期爆发的业务稳定性。