PostgreSQL中vacuum 物理文件truncate发生的条件

与我联系:
微信公众号:数据库杂记   个人微信: iiihero
我是iihero. 也可以叫我Sean.
iihero@CSDN(https://blog.csdn.net/iihero) 
Sean@墨天轮 (https://www.modb.pro/u/16258)
数据库领域的资深爱好者一枚。
水木早期数据库论坛发起人 db2@smth就是俺,早期多年水木论坛数据库版版主。
国内最早一批DB2 DBA。前后对Sybase ASE及SQLAnywhere, PostgreSQL, 
HANA, Oracle, DB2, SQLite均有涉猎。曾长期担任CSDN相关数据库版版主。
SAP数据库技术专家与开发架构师,PostgreSQL ACE.
代表作有:<<Java2网络协议内幕>> <<Oracle Spatial及OCI高级编程>> 
<<Sybase ASE 15.X全程实践>>
兴趣领域:数据库技术及云计算、GenAI业余专长爱好:中国武术六段 陈式太极拳第13代传人(北京陈式太极拳第5代传人)
职业太极拳教练,兼任北京陈式太极拳研究会副秘书长。
如果想通过习练陈式太极拳强身健体,也可以与我联系。

前言

前段时间,有些同学说到vacuum截断的行为时,认为,只要末尾是空页,无论多少,都会被截断,真是这样的吗?

PostgreSQL当中,由于vacuum的操作并不总能将死元组的空间进行”物理截断”,虽然说是回收了(表示空间可重用),但是真正的物理文件的大小依然不会收缩。那么什么时候这个空间会被真正截断呢?

我们不妨看看源代码:

摘自: src/backend/access/heap/vacuumlazy.c/** Space/time tradeoff parameters: do these need to be user-tunable?** To consider truncating the relation, we want there to be at least* REL_TRUNCATE_MINIMUM or (relsize / REL_TRUNCATE_FRACTION) (whichever* is less) potentially-freeable pages.*/
#define REL_TRUNCATE_MINIMUM    1000
#define REL_TRUNCATE_FRACTION    16/** should_attempt_truncation - should we attempt to truncate the heap?** Don't even think about it unless we have a shot at releasing a goodly* number of pages.  Otherwise, the time taken isn't worth it, mainly because* an AccessExclusive lock must be replayed on any hot standby, where it can* be particularly disruptive.** Also don't attempt it if wraparound failsafe is in effect.  The entire* system might be refusing to allocate new XIDs at this point.  The system* definitely won't return to normal unless and until VACUUM actually advances* the oldest relfrozenxid -- which hasn't happened for target rel just yet.* If lazy_truncate_heap attempted to acquire an AccessExclusiveLock to* truncate the table under these circumstances, an XID exhaustion error might* make it impossible for VACUUM to fix the underlying XID exhaustion problem.* There is very little chance of truncation working out when the failsafe is* in effect in any case.  lazy_scan_prune makes the optimistic assumption* that any LP_DEAD items it encounters will always be LP_UNUSED by the time* we're called.*/
static bool
should_attempt_truncation(LVRelState *vacrel)
{BlockNumber possibly_freeable;if (!vacrel->do_rel_truncate || VacuumFailsafeActive)return false;possibly_freeable = vacrel->rel_pages - vacrel->nonempty_pages;if (possibly_freeable > 0 &&(possibly_freeable >= REL_TRUNCATE_MINIMUM ||possibly_freeable >= vacrel->rel_pages / REL_TRUNCATE_FRACTION))return true;return false;
}

从代码里头可以看出,只有不少于1000个空页或者空页比例不低于总页数/16的情况下,才会真正发生truncate。两者必须满足其中之一。

这方面的原理分析,在cc老师的文章里都有谈及 (https://mp.weixin.qq.com/s/ymFYOAGin2kqo96gfNYDnQ),为加深印象,我们可以通过实验来进一步验证。

实验验证

-- 安装几个内置的插件:
create extension pg_buffercache;
create extension pg_freespacemap;
create extension pageinspect;
create extension pg_visibility;
create extension pgstattuple

准备表及数据

CREATE OR REPLACE FUNCTION random_string( int ) RETURNS TEXT as $$
SELECT string_agg(substring('abcdefghijklmnopqrstuvwxyz', round(random() * 25 + 0.5)::integer, 1), '') FROM generate_series(1, $1); 
$$ language sql;postgres=# create table t(id int primary key, col2 varchar(4000));
CREATE TABLE
postgres=# insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
INSERT 0 4000

相当于是建一个表t, 往里边插入4000条数据。里边使用随机串,主要是为了避免字符串压缩。我们看看相关表大小。

select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8331264 | 8224768 |  106496 | 8331264 |  8192000 | 32768
(1 row)

我们看到,上边的空间大小主要集中在表本身。因为实际插入长度2000左右,还不会进入到Toast空间。

postgres=# select min(blkno), max(blkno) from pg_freespace('t');min | max
-----+-----0 | 999
(1 row)postgres=# select pg_relpages('t');pg_relpages
-------------1000
(1 row)postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 4000
tuple_len          | 8128000
tuple_percent      | 99.22
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 20000
free_percent       | 0.24

可以看出,这个表实际占用了1000个页面(每4条记录占用一页,符合预期)。

删除末尾的4条记录

我们就只删除末尾的4条记录,看下情况,相当于是最后一页。

postgres=# delete from t where id >= 3997;
DELETE 4
postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 3996
tuple_len          | 8119872
tuple_percent      | 99.12
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 28128
free_percent       | 0.34postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 1 pages from table (0.10% of total) have 4 dead item identifiers
INFO:  table "t": found 0 removable, 0 nonremovable row versions in 1 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223185
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29708"
INFO:  table "pg_toast_29708": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223186
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select * from pgstattuple('t') \gx
-[ RECORD 1 ]------+--------
table_len          | 8192000
tuple_count        | 3996
tuple_len          | 8119872
tuple_percent      | 99.12
dead_tuple_count   | 0
dead_tuple_len     | 0
dead_tuple_percent | 0
free_space         | 28128
free_percent       | 0.34

上边的信息也可以看到,并没有什么截断发生。统计一下物理空间:

select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8339456 | 8232960 |  106496 | 8339456 |  8192000 | 40960
(1 row)

表的物理大小,仍然为:8192000

postgres=# select pg_relation_filepath('t');pg_relation_filepath
----------------------base/13236/29708\! stat postgres/data/base/13236/29708
16777234 104752459 -rw------- 1 ***** ***** 0 8192000 "Feb  4 06:40:12 2024" "Feb  4 06:44:03 2024" "Feb  4 06:44:03 2024" "Feb  4 06:40:12 2024" 4096 16512 0 postgres/data/base/13236/29708

继续删除12条记录:

postgres=# delete from t where id >= 4000 - 16 + 1;
DELETE 12
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 4 pages from table (0.40% of total) have 16 dead item identifiers
INFO:  table "t": found 16 removable, 3984 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223205
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29729"
INFO:  table "pg_toast_29729": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223205
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------8339456 | 8232960 |  106496 | 8339456 |  8192000 | 40960
(1 row)

累计16个页面:

postgres=# delete from t where id >= 4000 - 64 + 1;
DELETE 32
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 16 pages from table (1.60% of total) have 64 dead item identifiers
INFO:  table "t": found 32 removable, 0 nonremovable row versions in 16 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223209
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29729"
INFO:  table "pg_toast_29729": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223210
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

还是一点动静都没有。

那么要多少个空页,才有效:1000/16 = 62页? 

我们不妨逐步推进这个实验,累计16一直往上,看到底多少次以后,开始有截断?

。。。。。。

发现,删除80条记录(20个页面),结果不变

删除84条记录时,结果仍不变。

删除88条记录的时候(22个页面),这个时候会截断20个页面。(INFO:  table "t": truncated 1000 to 980 pages)

postgres=# delete from t where id >= 4000 - 88 + 1;
DELETE 8
postgres=# vacuum verbose t;
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 2 pages from table (0.20% of total) have 8 dead item identifiers
INFO:  table "t": found 8 removable, 0 nonremovable row versions in 22 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223218
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 980 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29736"
INFO:  table "pg_toast_29736": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223219
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpostgres=# select pg_relpages('t');pg_relpages
-------------980
(1 row)

事实上,我们发现,在删除87条记录的时候,仍然不会发生截断:

postgres=# delete from t where id >= 4000 - 87+1; vacuum verbose t;
DELETE 1
INFO:  vacuuming "public.t"
INFO:  table "t": index scan bypassed: 1 pages from table (0.10% of total) have 3 dead item identifiers
INFO:  table "t": found 1 removable, 1 nonremovable row versions in 22 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223228
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29743"
INFO:  table "pg_toast_29743": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223228
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM

autovacuum禁掉,去除影响

我们禁掉autovacuum, 并进行连续操作

drop table t;create table t(id int, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;postgres=# insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 88+1; vacuum verbose t;
DELETE 88
INFO:  vacuuming "public.t"
INFO:  table "t": removed 88 dead item identifiers in 22 pages
INFO:  table "t": found 88 removable, 3912 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223240
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29756"
INFO:  table "pg_toast_29756": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223240
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# select pg_relpages('t');pg_relpages
-------------1000
(1 row)

如果我们快速进行处理:

postgres=# drop table t;create table t(id int, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
DROP TABLE
CREATE TABLE
ALTER TABLE
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 247+1; vacuum verbose t; select pg_relpages('t');
DELETE 247
INFO:  vacuuming "public.t"
INFO:  table "t": removed 247 dead item identifiers in 62 pages
INFO:  table "t": found 247 removable, 3753 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  vacuuming "pg_toast.pg_toast_29776"
INFO:  table "pg_toast_29776": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------1000
(1 row)-- 再执行一次
postgres=# delete from t where id >= 4000 - 247+1; vacuum verbose t; select pg_relpages('t');
DELETE 0
INFO:  vacuuming "public.t"
INFO:  table "t": found 0 removable, 0 nonremovable row versions in 1 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223267
Skipped 0 pages due to buffer pins, 60 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 939 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29776"
INFO:  table "pg_toast_29776": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223268
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------939
(1 row)

这里会因为:  Skipped 0 pages due to buffer pins, 60 frozen pages.,  最后还是触发truncate. 但是从实验结果来看,在没有到达62个页面之前,第一次插,确实没有被trunate.

删除62个页面对应的记录:

postgres=# drop table t;create table t(id int primary key, col2 varchar(4000)); alter table t SET (autovacuum_enabled = off); insert into t select n, random_string(2000) from generate_series(1, 4000) as n;
DROP TABLE
CREATE TABLE
ALTER TABLE
INSERT 0 4000
postgres=# delete from t where id >= 4000 - 248+1; vacuum verbose t; select pg_relpages('t');
DELETE 248
INFO:  vacuuming "public.t"
INFO:  scanned index "t_pkey" to remove 248 row versions
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  table "t": removed 248 dead item identifiers in 62 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  index "t_pkey" now contains 3752 row versions in 13 pages
DETAIL:  248 index row versions were removed.
0 index pages were newly deleted.
0 index pages are currently deleted, of which 0 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": found 248 removable, 3752 nonremovable row versions in 1000 out of 1000 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223284
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO:  table "t": truncated 1000 to 938 pages
DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
INFO:  vacuuming "pg_toast.pg_toast_29795"
INFO:  table "pg_toast_29795": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 223285
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUMpg_relpages
-------------938postgres=# select pg_total_relation_size('t') total, pg_table_size('t') table, pg_indexes_size('t') indexes, pg_table_size('t')+pg_indexes_size('t') as sum, pg_relation_size('t') relation, pg_table_size('t')-pg_relation_size('t') as toast;total  |  table  | indexes |   sum   | relation | toast
---------+---------+---------+---------+----------+-------7831552 | 7725056 |  106496 | 7831552 |  7684096 | 40960
(1 row)         

小结

vacuum一个表,产生物理截断,默认情况下,需要空页达到一定条件。上边的实验表明,在空页没达到1000个页同时也没达到总页数/16的情况下,第一次尝试截断,并不会真正发生。(autovacuum关闭,是为了屏蔽自动vacuum的影响)因为autovacuum还会触发freeze等其它动作,会间接产生影响。

上边的实验,禁掉auto vacuum, 在删除最后62个页面的情况下,会发生截断。

如果不禁掉auto vacuum, 你会发现在20个页面被删除的情况下,会发生截断,那刚好是autovacuum默认触发的条件(20%)。而它本身又会触发与freeze action相关的操作,最终会引发截断。

一个小实验,结合代码,可以引发很多思考。希望这个实验对vacuum原理感兴趣的人有所帮助。

与我联系:

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/278525.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

基于YOLOv8/YOLOv7/YOLOv6/YOLOv5的障碍物检测系统(深度学习代码+UI界面+训练数据集)

摘要&#xff1a;开发障碍物检测系统对于道路安全性具有关键作用。本篇博客详细介绍了如何运用深度学习构建一个障碍物检测系统&#xff0c;并提供了完整的实现代码。该系统基于强大的YOLOv8算法&#xff0c;并对比了YOLOv7、YOLOv6、YOLOv5&#xff0c;展示了不同模型间的性能…

Flink源码解析(1)TM启动

网络传输模型 首先在看之前,回顾一下akka模型: Flink通讯模型—Akka与Actor模型-CSDN博客 注:ActorRef就是actor的引用,封装好了actor 下面是jm和tm在通讯上的概念图: RpcGateway 不理解网关的作用,可以先移步看这里:网关_百度百科 (baidu.com) 用于定义RPC协议,是…

Centos strema 9 环境部署Glusterfs9

本文档只是创建复制卷&#xff0c;分布式卷&#xff0c;分布式复制卷&#xff0c;纠删卷 操作系统 内核 角色 Ip地址 说明 CentOS Stream 9 x86_64 5.14.0-427.el9.x86_64 客户端 client 192.168.80.119 挂载存储业务机器 CentOS Stream 9 x86_64 5.14.0-427.el9.x8…

YOLOv9改进策略:注意力机制 | 用于微小目标检测的上下文增强和特征细化网络ContextAggregation,助力小目标检测,暴力涨点

&#x1f4a1;&#x1f4a1;&#x1f4a1;本文改进内容&#xff1a;用于微小目标检测的上下文增强和特征细化网络ContextAggregation&#xff0c;助力小目标检测 yolov9-c-ContextAggregation summary: 971 layers, 51002153 parameters, 51002121 gradients, 238.9 GFLOPs 改…

Hive SQL必刷练习题:连续问题 间断连续(*****)

问题描述&#xff1a; 1&#xff09; 连续问题&#xff1a;找出连续三天&#xff08;或者连续几天的啥啥啥&#xff09;。 2&#xff09; 间断连续&#xff1a;统计各用户连续登录最长天数&#xff0c;间断一天也算连续&#xff0c;比如1、3、4、6也算登陆了6天 问题分析&am…

手撕算法-二叉树的镜像

题目描述 操作给定的二叉树&#xff0c;将其变换为源二叉树的镜像。数据范围&#xff1a;二叉树的节点数 0≤_n_≤1000 &#xff0c; 二叉树每个节点的值 0≤_val_≤1000要求&#xff1a; 空间复杂度 O(n) 。本题也有原地操作&#xff0c;即空间复杂度 O(1) 的解法&#xff0c…

要将镜像推送到GitLab的Registry中的步骤

1、通过cli 模式登录gitlab &#xff08;命令行模式&#xff09; docker login git.asc-dede.de Username: haiyang Password: Login Succeeded 2、查看我的本地镜像&#xff1a; 3&#xff0c;推送镜像apollo_core到对应的gitlab项目的Registry 中 docker push registry.gi…

Python aiohttp 使用指南:快速入门教程

aiohttp 就是 Python 中一款优秀的异步 Web 框架&#xff0c;它能够帮助我们构建高效的异步 Web 应用和异步 HTTP 客户端。在本文中&#xff0c;我们将深入探讨 aiohttp 是什么以及如何使用它&#xff0c;通过简单易懂的案例带领你理解异步编程&#xff0c;以及如何处理异步请求…

大数据开发--01.初步认识了解

一.环境准备 1.使用虚拟机构建至少三台linux服务器 2.使用公有云来部署服务器 二.大数据相关概念 大数据是指处理和分析大规模数据集的一系列技术、工具和方法。这些数据集通常涉及海量的数据&#xff0c;包括结构化数据&#xff08;如关系型数据库中的表格&#xff09;以及…

WanAndroid(鸿蒙版)开发的第二篇

前言 DevEco Studio版本&#xff1a;4.0.0.600 WanAndroid的API链接&#xff1a;玩Android 开放API-玩Android - wanandroid.com 1、WanAndroid(鸿蒙版)开发的第一篇 2、WanAndroid(鸿蒙版)开发的第二篇 3、WanAndroid(鸿蒙版)开发的第三篇 4、WanAndroid(鸿蒙版)开发的第…

【研发日记】Matlab/Simulink技能解锁(一)——在Simulink编辑窗口Debug

文章目录 前言 时间阈值断点 信号阈值断点 周期步进 Signal Value Lable Data Inspector 分析和应用 总结 前言 近期在一些研发项目中使用Matlab/Simulink时&#xff0c;遇到了挺多费时费力的事情。所以利用晚上和周末时间&#xff0c;在这些方面深入研究了一下&#x…

深入解析JVM加载机制

一、背景 Java代码被编译器变成生成Class字节码&#xff0c;但字节码仅是一个特殊的二进制文件&#xff0c;无法直接使用。因此&#xff0c;都需要放到JVM系统中执行&#xff0c;将Class字节码文件放入到JVM的过程&#xff0c;简称类加载。 二、整体流程 三、阶段逻辑分析 3…

VS2022 配置QT5.9.9

QT安装 下载地址&#xff1a;https://download.qt.io/archive/qt/ 下载安装后进行配置 无法运行 rc.exe 下载VS2022 官网下载 配置 1.扩展-管理扩展-下载Qt Visual Studio Tools 安装 2.安装完成后&#xff0c;打开vs2022,点击扩展&#xff0c;会发现多出了QT VS Tools,点…

NeRF——基于神经辐射场的三维场景重建和理解

概述 三维重建是一种将物理世界中的实体转换为数字模型的计算机技术。其基本概念是通过对物理世界中的物体或场景进行扫描或拍摄&#xff0c;并使用计算机算法将其转换为三维数字模型。抽象意义上的三维模型指的是&#xff1a;形状和外观的组合&#xff0c;并且可以渲染成不同…

unity3d Animal Controller的Animal组件中Speeds,States和modes基础部分理解

Speeds 速度集是修改你可以做的原始动画,增加或减少运动,旋转,或动画速度。它们与 州 所以,当动物在运动状态下,在飞行或游泳时,你可以有不同的速度 如果你的性格动画是 (已到位), 你一定要调整速度 位置 和 旋转 每一种的价值观 速度装置 …否则,它们不会移动或旋转。 每个速…

使用Docker在windows上安装IBM MQ

第一步、安装wsl 详见我另一篇安装wsl文章。 第二步、安装centos 这里推荐两种方式&#xff0c;一种是从微软商城安装&#xff0c;一种是使用提前准备好的镜像安装&#xff0c;详见我另一篇windos下安装centos教程。 第三步、安装windows下的Docker desktop 详见我另一篇wind…

MATLAB的使用(二)

一&#xff0c;算法需求 算法五特性(1)有穷性。有穷性是指算法需在有穷步骤、有穷时间内结束。 (2)确定性。确定性是指每个步骤都有确切的意义&#xff0c;相同的输入有相同的输出。 (3)有效性。有效性是指可通过已实现的运算在有限次完成&#xff0c;或叫可行性。 (4)输入。…

ttkbootstrap界面美化系列之主窗口(二)

一&#xff1a;创建主窗口 在利用ttkbootstrap构建应用程序时&#xff0c;可以用tkinter传统的tk方法来创建主界面&#xff0c;也可以用ttkbootstrap中的window类来创建&#xff0c;下面我们来看看两者的区别 1&#xff0c;传统方法创建主界面 import tkinter as tk import …

鸿蒙Harmony应用开发—ArkTS声明式开发(基础手势:Span)

作为Text组件的子组件&#xff0c;用于显示行内文本的组件。 说明&#xff1a; 该组件从API Version 7开始支持。后续版本如有新增内容&#xff0c;则采用上角标单独标记该内容的起始版本。 该组件从API Version 10开始支持继承父组件Text的属性&#xff0c;即如果子组件未设置…

2.26OS分类,中断(内,外),系统调用,操作系统结构、引导,虚拟机(两类VMM),进程

外核可以申请分配连续的磁盘块以支持频繁的随机访问&#xff0c;其它的方式是采用虚拟存储 分层结构