clickhouse 删除操作

OLAP 数据库设计的宗旨在于分析适合一次插入多次查询的业务场景,市面上成熟的 AP 数据库在更新和删除操作上支持的均不是很好,当然 clickhouse 也不例外。但是不友好不代表不支持,本文主要介绍在 clickhouse 中如何实现数据的删除,以及最新版本中 clickhouse 所做的一些技术突破

Click_House_Delete_Statement_6fd661d851

一、mutation

刚接触 clickhouse 的小伙伴或许对 mutation 就很熟悉了,mutation 查询可以看成 alter 语句的变种。虽然 mutation 能够最终实现修改和删除的需求,但不能完全用通常意义的 delete 和 update 来理解,我们需要清醒的认识到它的不同:

  1. mutation 是一个很重的操作,适合批量数据操作
  2. 不支持事务、一旦操作立刻生效无法回滚
  3. mutation 为异步操作

1.1 实操

创建一张表用于测试 mutation 操作

create table mutations_operate
(UserId     UInt64,Score      UInt64,CreateTime DateTime
) engine = MergeTree()partition by toYYYYMMDD(CreateTime)order by UserId;

接下来分别插入两批不同分区的数据

insert into mutations_operate
select number,abs(number - 100),'2023-08-08 00:00:00'
from system.numbers
limit 1000000;insert into mutations_operate
select number,abs(number - 100),'2023-08-09 00:00:00'
from system.numbers
limit 1000000;

尝试删除 20230808 分区中 1000-10000 之间的所有数据,sql 如下

alter table mutations_operate delete where toYYYYMMDD(CreateTime) = 20230808 and UserId between 1000 and 10000;

可以统计一下该分区的数据条数来确认是否成功删除,从体验来说目前的数据规模感受不到 mutation 的“重”,感觉像是瞬间完成的。

当然我们也可以查看system.mutations表来监控 mutation 操作的进度

select table, mutation_id, `block_numbers.number` as num, is_done
from system.mutations;Query id: 0878a0f1-a5ff-474c-8f84-518ce5dc5e1d┌─table─────────────┬─mutation_id────┬─num─┬─is_done─┐
│ mutations_operate │ mutation_3.txt │ [3]1 │
└───────────────────┴────────────────┴─────┴─────────┘1 row in set. Elapsed: 0.002 sec.

mutation_id 是一个日志文件,可以在表存储目录中查看,完整记录了本次操作的语句和时间,例如

format version: 1
create time: 2023-08-09 18:54:06
commands: DELETE WHERE (toYYYYMMDD(CreateTime) = 20230808) AND ((UserId >= 1000) AND (UserId <= 10000))

而其中的 3 以及block_numbers.number是 mutation 号,每执行一条 delete 或 update 语句都会对应一个唯一的编号

id_done 表示本次 mutation 操作是否执行完成,1 表示已经完成

1.2 原理

为了探寻 mutation 操作的原理和执行流程重置一下表数据(删除重建即可),在插入两批数据后查看磁盘目录

» du -h0B	./detached
7.7M	./20230809_2_2_0
7.7M	./20230808_1_1_015M	.

可以看到两个分区目录均是 7.7M

尝试执行删除操作后,可以在日志中看到下面的查询信息

<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Key condition: unknown, (column 0 in [1000, +Inf)), (column 0 in (-Inf, 10000]), and, and
<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Key condition: unknown, (column 0 in [1000, +Inf)), (column 0 in (-Inf, 10000]), and, and
<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): MinMax index condition: (toYYYYMMDD(column 0) in [20230808, 20230808]), unknown, unknown, and, and
<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): MinMax index condition: (toYYYYMMDD(column 0) in [20230808, 20230808]), unknown, unknown, and, and
<Trace> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Running binary search on index range for part 20230808_1_1_0 (124 marks)
<Trace> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Found (LEFT) boundary mark: 0
<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Selected 0/1 parts by partition key, 0 parts by primary key, 0/0 marks by primary key, 0 marks to read from 0 ranges
<Trace> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Found (RIGHT) boundary mark: 2
<Trace> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Found continuous range in 13 steps
<Debug> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 2/123 marks by primary key, 2 marks to read from 1 ranges
<Trace> delete_operate.mutations_operate (7f120927-b71e-4f85-a06c-21a94b7f89e3) (SelectExecutor): Spreading mark ranges among streams (default reading)
<Trace> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part 20230808_1_1_0, approx. 16384 rows starting from 0
<Trace> Aggregator: Aggregation method: without_key
<Trace> AggregatingTransform: Aggregated. 0 to 1 rows (from 0.00 B) in 0.000570041 sec. (0.000 rows/sec., 0.00 B/sec.)
<Trace> Aggregator: Merging aggregated data
<Trace> MutateTask: Part 20230809_2_2_0 doesn't change up to mutation version 3

首先,clickhouse 会使用我们执行的删除语句中附带的 where 条件在每个分区中执行 count 查询,为了判断哪些分区有需要被删除的数据,从日志可以看出Reading 1 ranges in order from part 20230808_1_1_0, approx. 16384 rows starting from 0以及Part 20230809_2_2_0 doesn't change up to mutation version 3。注意日志中所说 20230808 的范围是 0~16384 并不是实际删除的范围,而是索引的范围。我们知道 mergeTree 引擎默认的跳数索引的间隔是 8192 而我们删除的数据范围是 1000-10000,显然作为一个整周期自然是 0-16384(2x8192)

当我们再次查看磁盘目录

» du -h0B	./detached
7.7M	./20230809_2_2_0
7.7M	./20230808_1_1_00B	./20230809_2_2_0_3
7.6M	./20230808_1_1_0_323M	.

总目录从 15M 变成了 23M,而两个分区也都各自生成了一个以 mutation version 为后缀的新分区

因此接下来的逻辑如下:

clickhouse 会创建一个 tmp_mut_ 为前缀、mutation version 为后缀的临时分区目录,例如这里的就是 tmp_mut_20230808_1_1_0_3

对于需要删除的分区,会在 tmp_mut 目录中生成全新的 .bin 和 .mrk 文件

对于无需删除的分区,clickhouse 会创建一个 tmp_clone_ 为前缀、mutation version 为后缀的临时分区目录并将原分区里面的数据以硬链接的方式拷贝过去,并修改目录名称为正确的格式

下面是执行的日志情况

<Debug> delete_operate.mutations_operate (4351d317-2cd6-4328-85fe-49d5beeff5c3): Clone part /opt/homebrew/var/lib/clickhouse/store/435/4351d317-2cd6-4328-85fe-49d5beeff5c3/20230809_2_2_0/ to /opt/homebrew/var/lib/clickhouse/store/435/4351d317-2cd6-4328-85fe-49d5beeff5c3/tmp_clone_20230809_2_2_0_3
<Trace> delete_operate.mutations_operate (4351d317-2cd6-4328-85fe-49d5beeff5c3): Renaming temporary part tmp_clone_20230809_2_2_0_3 to 20230809_2_2_0_3 with tid (1, 1, 00000000-0000-0000-0000-000000000000).
<Trace> MergedBlockOutputStream: filled checksums 20230808_1_1_0_3 (state Temporary)
<Trace> delete_operate.mutations_operate (4351d317-2cd6-4328-85fe-49d5beeff5c3): Renaming temporary part tmp_mut_20230808_1_1_0_3 to 20230808_1_1_0_3 with tid (1, 1, 00000000-0000-0000-0000-000000000000)

从磁盘目录也可以佐证这一点,首先上面的 20230809_2_2_0_3 占用空间为 0B,当然这是 mac 独有的现实方式,在其它 linux 系统不一定是这么显示,进入各个分区查看一下

wjun :: data/delete_operate/mutations_operate ‹stable› » ll 20230808_1_1_0_3
total 15632
-rw-r-----@ 1 wjun  admin    17863 Aug  9 19:36 CreateTime.bin
-rw-r-----@ 1 wjun  admin      369 Aug  9 19:36 CreateTime.cmrk2
-rw-r-----@ 1 wjun  admin  3968891 Aug  9 19:36 Score.bin
-rw-r-----@ 1 wjun  admin      409 Aug  9 19:36 Score.cmrk2
-rw-r-----@ 1 wjun  admin  3969011 Aug  9 19:36 UserId.bin
-rw-r-----@ 1 wjun  admin      409 Aug  9 19:36 UserId.cmrk2
-rw-r-----@ 1 wjun  admin      490 Aug  9 19:36 checksums.txt
-rw-r-----@ 1 wjun  admin       90 Aug  9 19:36 columns.txt
-rw-r-----@ 1 wjun  admin        6 Aug  9 19:36 count.txt
-rw-r-----@ 1 wjun  admin       10 Aug  9 19:36 default_compression_codec.txt
-rw-r-----@ 1 wjun  admin        1 Aug  9 19:36 metadata_version.txt
-rw-r-----@ 1 wjun  admin        8 Aug  9 19:36 minmax_CreateTime.idx
-rw-r-----@ 1 wjun  admin        4 Aug  9 19:36 partition.dat
-rw-r-----@ 1 wjun  admin      188 Aug  9 19:36 primary.cidx
wjun :: data/delete_operate/mutations_operate ‹stable› » ll 20230809_2_2_0_3
total 15768
-rw-r-----@ 2 wjun  admin    18042 Aug  9 19:35 CreateTime.bin
-rw-r-----@ 2 wjun  admin      375 Aug  9 19:35 CreateTime.cmrk2
-rw-r-----@ 2 wjun  admin  4004938 Aug  9 19:35 Score.bin
-rw-r-----@ 2 wjun  admin      415 Aug  9 19:35 Score.cmrk2
-rw-r-----@ 2 wjun  admin  4004915 Aug  9 19:35 UserId.bin
-rw-r-----@ 2 wjun  admin      415 Aug  9 19:35 UserId.cmrk2
-rw-r-----@ 2 wjun  admin      490 Aug  9 19:35 checksums.txt
-rw-r-----@ 2 wjun  admin       90 Aug  9 19:35 columns.txt
-rw-r-----@ 2 wjun  admin        7 Aug  9 19:35 count.txt
-rw-r-----@ 2 wjun  admin       10 Aug  9 19:35 default_compression_codec.txt
-rw-r-----@ 2 wjun  admin        8 Aug  9 19:35 minmax_CreateTime.idx
-rw-r-----@ 2 wjun  admin        4 Aug  9 19:35 partition.dat
-rw-r-----@ 2 wjun  admin      173 Aug  9 19:35 primary.cidx

20230809_2_2_0_3 分区 inode 被连接次数为 2 表示建立了硬链接。

因此 mutation 的删除逻辑如下:

  1. 每个分区执行附带删除操作的 where 条件的 count 查询,获取需要执行删除操作的分区
  2. 对于需要执行删除操作的分区会创建一个临时目录并生成全新(删除需要删除的行)的文件,随后 rename 分区
  3. 对于无需执行删除操作的分区会创建一个临时目录并以硬链接的方式拷贝文件,随后 rename 分区
  4. 原分区在system.parts中会被置为 inactive 状态
  5. 在下一次 merge 是删除原分区

而对于更新操作基本逻辑一致,需要注意的是需要执行更新操作的分区会有如下两种情况:

  1. 分区类型为 wide:只会重新生成受影响行的 bin 和 mrk 文件,不受影响的文件以硬链接的方式拷贝
  2. 分区类型为 compact:因为所有列都是一个文件,因此会重新生成 bin 和 mrk 文件

更新和删除操作流程不一致的原因是:删除影响全部列而更新只影响部分列

mergeTree 表的分区类型分为 wide 和 compact 两种受min_bytes_for_wide_partmin_rows_for_wide_part参数影响。wide 类型的分区一个列一个文件,compact 类型的分区所有列公用一个文件,当分区数据的行数和字节较小时为 compact 类型,不管是查询所有字段或某个字段相对较快;当数据量很大时就会以列式存储来追求 AP 查询性能

1.3 不足

当我们走一遍 mutation 时发现在删除任务完成后表 merge 前的这一段时间磁盘空间不减反增,这个就让用户很难接受了。因此就可能会出现因为磁盘空间不足想要删除数据,结果删除操作导致空间进一步不足的窘境。同时 mutation 会重写受影响的分区,这也是 mutation 操作重的原因所在。

二、mergeTree

对于 clickhouse 这类高性能分析型数据库而言,修改源文件是一件非常奢侈且代价昂贵的操作,相对于直接修改源文件,我们将修改和新增操作都转换为新增操作,即以增代删将是一个非常不错的选择。是不是和 Hbase 的思路十分接近。在 mergeTree 家族中有一个特殊的表引擎叫 CollapsingMergeTree,翻译过来叫折叠合并树引擎就是提供了这样的功能。它通过定义一个 sign 标记字段来记录数据行的状态。如果 sign 为 1 表示这是一行有效的数据,如果 sign 为 -1 表示这行数据被删除。当 CollapsingMergeTree 分区合并时同一分区的 +1、-1 将会被抵消,犹如一张纸折叠一般。

2.1 实操

创建 CollapsingMergeTree 表

create table collapsing_table
(Id         String,Code       Int32,CreateTime DateTime,Sign       Int8
) engine = CollapsingMergeTree(Sign)partition by toYYYYMMDD(CreateTime)order by Id;

注:和其它 mergeTree 引擎一样 CollapsingMergeTree 依然是以 order by 字段作为后续数据唯一性的依据

插入一批原始数据

insert into collapsing_table values ('A000', 100, '2023-08-09 00:00:00', 1);
insert into collapsing_table values ('A001', 100, '2023-08-09 00:00:00', 1);
insert into collapsing_table values ('A002', 100, '2023-08-09 00:00:00', 1);

修改 A000 的 Code 为 200 并删除 A002 的数据

# 修改 A000 的 Code 为 200
insert into collapsing_table values ('A000', 100, '2023-08-09 00:00:00', -1);
insert into collapsing_table values ('A000', 200, '2023-08-09 00:00:00', 1);
# 删除 A002 的数据
insert into collapsing_table values ('A002', 100, '2023-08-09 00:00:00', -1);
# 手动执行一下分区合并操作
optimize table collapsing_table final;

可以观察到数据已经被删除和修改。

CollapsingMergeTree 在分区合并折叠数据的时候,遵循下面规则

  1. 如果 sign = 1 比 sign = -1 多一行,最后保留 sign = 1 的数据
  2. 如果 sign = 1 比 sign = -1 少一行,最后保留 sign = -1 的数据
  3. 如果 sign = 1 和 sign = -1 一样多,且最后一行时 sign = 1,则保留第一行的 sign = -1 和最后一行 sign = 1
  4. 如果 sign = 1 和 sign = -1 一样多,且最后一行时 sign = -1,则什么也不保留
  5. 其余情况 clickhouse 会打印告警日志,但不会报错且查询情况不可预知

2.2 不足

当前表的数据如下

select *
from collapsing_table;Query id: 4b1da757-d02a-4b88-92e5-1fe659ca462c┌─Id───┬─Code─┬──────────CreateTime─┬─Sign─┐
│ A002 │  3002023-08-09 00:00:00-1 │
└──────┴──────┴─────────────────────┴──────┘
┌─Id───┬─Code─┬──────────CreateTime─┬─Sign─┐
│ A002 │  3002023-08-09 00:00:001 │
└──────┴──────┴─────────────────────┴──────┘
┌─Id───┬─Code─┬──────────CreateTime─┬─Sign─┐
│ A000 │  2002023-08-09 00:00:001 │
│ A001 │  1002023-08-09 00:00:001 │
└──────┴──────┴─────────────────────┴──────┘4 rows in set. Elapsed: 0.003 sec.

从操作来看 A002 是要被删除的

但是如果查询sql如下

select Id, sum(Code), count(Code), avg(Code)
from collapsing_table
group by Id;Query id: 610f6503-1344-4ba0-9564-6327277ffe95┌─Id───┬─sum(Code)─┬─count(Code)─┬─avg(Code)─┐
│ A001 │       1001100 │
│ A000 │       2001200 │
│ A002 │       6002300 │
└──────┴───────────┴─────────────┴───────────┘3 rows in set. Elapsed: 0.005 sec.

此时的结果是不对的,因此需要改写 sql

select Id, sum(Code * Sign), count(Code * Sign), avg(Code * Sign)
from collapsing_table
group by Id
having sum(Sign) > 0;Query id: a3fe84d0-33a5-4287-bd02-49ab03df1852┌─Id───┬─sum(multiply(Code, Sign))─┬─count(multiply(Code, Sign))─┬─avg(multiply(Code, Sign))─┐
│ A001 │                       1001100 │
│ A000 │                       2001200 │
└──────┴───────────────────────────┴─────────────────────────────┴───────────────────────────┘2 rows in set. Elapsed: 0.005 sec.

当然还有一种方式就是在查询数据前执行分区合并操作optimize table collapsing_table final;,但这种方式效率极低在生产中慎用

同时 CollapsingMergeTree 还存在一些问题,例如在分区合并前用户是可以看到所有数据的。当然上面所说的问题都不是最致命的,CollapsingMergeTree 最致命点在于对于 sign 的写入顺序有严格的要求,对于一个删除操作正常的顺序应该是先写入 1 再写入 -1

insert into collapsing_table values ('A002', 300, '2023-08-09 00:00:00', 1);
insert into collapsing_table values ('A002', 300, '2023-08-09 00:00:00', -1);

但如果颠倒顺序

insert into collapsing_table values ('A002', 300, '2023-08-09 00:00:00', -1);
insert into collapsing_table values ('A002', 300, '2023-08-09 00:00:00', 1);

则不会被删除。而在生产环境一旦 CollapsingMergeTree 在多线程中处理就无法保证写入顺序了。

当然幸运的是 clickhouse 也注意到 CollapsingMergeTree 的缺点并推出了新的表引擎 VersionedCollapsingMergeTree,在 CollapsingMergeTree 的基础上将按照写入顺序折叠修改为按照版本号顺序进行折叠,而版本号交由用户来管理。VersionedCollapsingMergeTree 引擎的操作就交给读者来体验,毕竟下面还有一种更贴合 TP 数据库操作的删除操作

三、lightweight

上面介绍了通过 mutation 和 mergeTree 来实现删除操作,但是 mutation 操作太重,mergeTree 则需要修改 sql 且删除操作受分区合并时机影响。从 clickhouse v22.8 开始提供了一个轻量级删除功能且语法为标准 sql 🎉🎉🎉

3.1 实操

准备表和数据

create table lightweight_operate
(UserId     UInt64,Score      UInt64,CreateTime DateTime
) engine = MergeTree()partition by toYYYYMMDD(CreateTime)order by UserId;insert into lightweight_operate
select number,abs(number - 100),'2023-08-08 00:00:00'
from system.numbers
limit 1000000;insert into lightweight_operate
select number,abs(number - 100),'2023-08-09 00:00:00'
from system.numbers
limit 1000000;

同样删除 20230808 分区中 1000-10000 之间的所有数据,sql 如下

delete from lightweight_operate where toYYYYMMDD(CreateTime) = 20230808 and UserId between 1000 and 10000;

验证一下

select count() from lightweight_operate where toYYYYMMDD(CreateTime) = 20230808;Query id: 0344da3b-5ea5-436d-ba29-cfb1a8e3420e┌─count()─┐
│  990999 │
└─────────┘1 row in set. Elapsed: 0.008 sec. Processed 1.00 million rows, 5.00 MB (128.59 million rows/s., 642.93 MB/s.)

成功删除

3.2 原理

查看磁盘目录

» ll
total 16
drwxr-x---@ 16 wjun  admin  512 Aug  9 21:09 20230808_1_1_0
drwxr-x---@ 18 wjun  admin  576 Aug  9 21:10 20230808_1_1_0_3
drwxr-x---@ 16 wjun  admin  512 Aug  9 21:09 20230809_2_2_0
drwxr-x---@ 15 wjun  admin  480 Aug  9 21:10 20230809_2_2_0_3
drwxr-x---@  2 wjun  admin   64 Aug  9 21:09 detached
-rw-r-----@  1 wjun  admin    1 Aug  9 21:09 format_version.txt
-rw-r-----@  1 wjun  admin  171 Aug  9 21:10 mutation_3.txt» du -h0B	./detached
7.7M	./20230809_2_2_0
7.7M	./20230808_1_1_00B	./20230809_2_2_0_328K	./20230808_1_1_0_315M	.

可以看出轻量删除依然是一个 mutation 操作,从system.mutations表也可以验证,但轻量删除生成的新的分区 20230808_1_1_0_3 仅 28K,那么轻量删除和 mutation 删除的区别在哪

查看 20230808_1_1_0_3 磁盘目录

wjun :: data/delete_operate/lightweight_operate ‹stable› » ll 20230808_1_1_0_3
total 15800
-rw-r-----@ 2 wjun  admin    18042 Aug  9 21:09 CreateTime.bin
-rw-r-----@ 2 wjun  admin      375 Aug  9 21:09 CreateTime.cmrk2
-rw-r-----@ 2 wjun  admin  4004938 Aug  9 21:09 Score.bin
-rw-r-----@ 2 wjun  admin      415 Aug  9 21:09 Score.cmrk2
-rw-r-----@ 2 wjun  admin  4004915 Aug  9 21:09 UserId.bin
-rw-r-----@ 2 wjun  admin      415 Aug  9 21:09 UserId.cmrk2
-rw-r-----@ 1 wjun  admin     4493 Aug  9 21:10 _row_exists.bin
-rw-r-----@ 1 wjun  admin      236 Aug  9 21:10 _row_exists.cmrk2
-rw-r-----@ 1 wjun  admin      589 Aug  9 21:10 checksums.txt
-rw-r-----@ 1 wjun  admin      110 Aug  9 21:10 columns.txt
-rw-r-----@ 2 wjun  admin        7 Aug  9 21:09 count.txt
-rw-r-----@ 1 wjun  admin       10 Aug  9 21:10 default_compression_codec.txt
-rw-r-----@ 1 wjun  admin        1 Aug  9 21:10 metadata_version.txt
-rw-r-----@ 2 wjun  admin        8 Aug  9 21:09 minmax_CreateTime.idx
-rw-r-----@ 2 wjun  admin        4 Aug  9 21:09 partition.dat
-rw-r-----@ 2 wjun  admin      173 Aug  9 21:09 primary.cidx

发现多了一组 _row_exists 文件而其余文件的 inode 连接数均为 2,也就是说轻量删除是真正的给字段添加了一个标记。

在查询的时候过滤

lightweight_deletes_v2_b891b54446

在分区合并的时候删除

lightweight_delete_merge_1_a2519ab507

比 mutation 轻的点在于轻量删除不会重构整个分区目录而是重写 _row_exists 文件这样涉及到的修改会少很多,至于分区的拷贝和不涉及删除操作的分区操作逻辑则和上面介绍的 mutation 流程一致

3.3 不足

轻量删除的设计思路相比之前的会好上很多,但 clickhouse 毕竟不是 TP 数据库,目前轻量删除依然存在一些问题和限制,如:

  1. 轻量删除是异步的,只有在分区合并的时候才会被真正删除(轻量删除执行完是逻辑上删除)
  2. 对 wide 类型分区友好,对于 compact 类型分区会产生较大的磁盘 IO
  3. 会修改分区在磁盘中的名称,可能会影响备份

对于 mutation 是否为异步操作可以通过参数进行配置,只需将mutations_sync置为 true 即可

set mutations_sync = true;

至于其它的不足需要用户结合实际场景进行取舍

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

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

相关文章

单链表相关操作(插入,删除,查找)

通过上一节我们知道顺序表的优点&#xff1a; 可随机存储&#xff08;O(1)&#xff09;&#xff1a;查找速度快 存储密度高&#xff1a;每个结点只存放数据元素&#xff0c;而单链表除了存放数据元素之外&#xff0c;还需存储指向下一个节点的指针 http://t.csdn.cn/p7OQf …

【2023年11月第四版教材】《第4章-信息系统管理(合集篇)》

第4章-信息系统管理之管理方法&#xff08;第四版新增章节&#xff09;&#xff08;第一部分&#xff09; 章节说明1 管理方法1.1 信息系统四个要素1.2 信息系统四大领域1.3 信息系统战略三角1.4 信息系统架构转换1.5 信息系统体系架构1.6 信息系统运行1.7 运行和监控1.8 管理和…

kafka基本概念及操作

kafka介绍 Kafka是最初由Linkedin公司开发&#xff0c;是一个分布式、支持分区的&#xff08;partition&#xff09;、多副本的 &#xff08;replica&#xff09;&#xff0c;基于zookeeper协调的分布式消息系统&#xff0c;它的最大的特性就是可以实时的处理大量数据以满足各…

【LeetCode】242 . 有效的字母异位词

242 . 有效的字母异位词&#xff08;简单&#xff09; 方法&#xff1a;哈希表 思路 首先判断两个字符串长度是否相等&#xff0c;不相等直接返回 false&#xff1b;接下来设置一个长度为26 的哈希表&#xff0c;分别对应26个小写字母&#xff1b;遍历两个字符串&#xff0c;…

Go语言工程实践之测试与Gin项目实践

Go 语言并发编程 及 进阶与依赖管理_软工菜鸡的博客-CSDN博客 03 测试 回归测试一般是QA(质量保证)同学手动通过终端回归一些固定的主流程场景 集成测试是对系统功能维度做测试验证,通过服务暴露的某个接口,进行自动化测试 而单元测试开发阶段&#xff0c;开发者对单独的函数…

KAFKA第二课之生产者(面试重点)

生产者学习 1.1 生产者消息发送流程 在消息发送的过程中&#xff0c;涉及到了两个线程——main线程和Sender线程。在main线程中创建了一个双端队列RecordAccumulator。main线程将消息发送给RecordAccumulator&#xff0c;Sender线程不断从RecordAccumulator中拉取消息发送到K…

03-基础入门-搭建安全拓展

基础入门-搭建安全拓展 1、涉及的知识点2、常见的问题3、web权限的设置4、演示案例-环境搭建&#xff08;1&#xff09;PHPinfo&#xff08;2&#xff09;wordpress&#xff08;3&#xff09;win7虚拟机上使用iis搭建网站&#xff08;4&#xff09;Windows Server 2003配置WEB站…

C#应用处理传入参数 - 开源研究系列文章

今天介绍关于C#的程序传入参数的处理例子。 程序的传入参数应用比较普遍&#xff0c;特别是一个随操作系统启动的程序&#xff0c;需要设置程序启动的时候不显示主窗体&#xff0c;而是在后台运行&#xff0c;于是就有了传入参数问题&#xff0c;比如传入/h或者/min等等。所以此…

YOLO v8目标跟踪详细解读(二)

上一篇&#xff0c;结合代码&#xff0c;我们详细的介绍了YOLOV8目标跟踪的Pipeline。大家应该对跟踪的流程有了大致的了解&#xff0c;下面我们将对跟踪中出现的卡尔曼滤波进行解读。 1.卡尔曼滤波器介绍 卡尔曼滤波&#xff08;kalman Filtering&#xff09;是一种利用线性…

欧拉OS 使用 CentOS 7 yum repo

一、下载CentOS的repo的yum文件 任何基于CentOS的yum的repo 的url是这样的&#xff1a; 但欧拉OS输出这个变量为&#xff1a;openEuler 20.03 (LTS-SP3) 那明显欧拉想要使用这个yum的url找不到这个版本&#xff0c; 所以直接讲这个变量替换为 7, Centos 7的7 然后执行&…

从零实战SLAM-第七课(多视角几何)

在七月算法报的班&#xff0c;老师讲的蛮好。好记性不如烂笔头&#xff0c;关键内容还是记录一下吧&#xff0c;课程入口&#xff0c;感兴趣的同学可以学习一下。 --------------------------------------------------------------------------------------------------------…

设计模式--策略模式

目录 一.场景 1.1场景 2.2 何时使用 2.3个人理解 二. 业务场景练习 2.1业务: 2.2具体实现 2.3思路 三.总结 3.1策略模式的特点&#xff1a; 3.2策略模式优点 3.3策略模式缺点 一.场景 1.1场景 许多相关的类仅仅是行为有异&#xff0c;也就是说业务代码需要根据场景不…

归并排序 与 计数排序

目录 1.归并排序 1.1 递归实现归并排序&#xff1a; 1.2 非递归实现归并排序 1.3 归并排序的特性总结: 1.4 外部排序 2.计数排序 2.1 操作步骤: 2.2 计数排序的特性总结: 3. 7种常见比较排序比较 1.归并排序 基本思想: 归并排序(MERGE-SORT)是建立在归并操作上的一种…

redis分布式集群-redis+keepalived+ haproxy

redis分布式集群架构&#xff08;RedisKeepalivedHaproxy&#xff09;至少需要3台服务器、6个节点&#xff0c;一台服务器2个节点。 redis分布式集群架构中的每台服务器都使用六个端口来实现多路复用&#xff0c;最终实现主从热备、负载均衡、秒级切换的目标。 redis分布式集…

使用Edge和chrom扩展工具(GoFullPage)实现整页面截图或生成PDF文件

插件GoFullPage下载&#xff1a;点击免费下载 如果在浏览网页时&#xff0c;有需要整个页面截图或导出PDF文件的需求&#xff0c;这里分享一个Edge浏览器的扩展插件&#xff1a;GoFullPage。 这个工具可以一键实现页面从上到下滚动并截取。 一、打开“管理扩展”&#xff08;…

网络设备(防火墙、路由器、交换机)日志分析监控

外围网络设备&#xff08;如防火墙、路由器、交换机等&#xff09;是关键组件&#xff0c;因为它们控制进出公司网络的流量。因此&#xff0c;监视这些设备的活动有助于 IT 管理员解决操作问题&#xff0c;并保护网络免受攻击者的攻击。通过收集和分析这些设备的日志来监控这些…

Python 3 使用Hadoop 3之MapReduce总结

MapReduce 运行原理 MapReduce简介 MapReduce是一种分布式计算模型&#xff0c;由Google提出&#xff0c;主要用于搜索领域&#xff0c;解决海量数据的计算问题。 MapReduce分成两个部分&#xff1a;Map&#xff08;映射&#xff09;和Reduce&#xff08;归纳&#xff09;。…

tauri-react:快速开发跨平台软件的架子,支持自定义头部和窗口阴影效果

tauri-react 一个使用 taurireacttsantd 开发跨平台软件的模板&#xff0c;支持窗口头部自定义和窗口阴影&#xff0c;不用再自己做适配了&#xff0c;拿来即用&#xff0c;非常 nice。 开原地址&#xff1a;GitHub - Sjj1024/tauri-react: 一个最基础的使用tauri和react开发…

生成式 AI 在泛娱乐行业的应用场景实践 – 助力风格化视频内容创作

感谢大家阅读《生成式 AI 行业解决方案指南》系列博客&#xff0c;全系列分为 4 篇&#xff0c;将为大家系统地介绍生成式 AI 解决方案指南及其在电商、游戏、泛娱乐行业中的典型场景及应用实践。目录如下&#xff1a; 《生成式 AI 行业解决方案指南与部署指南》《生成式 AI 在…

一个概率论例题引发的思考

浙江大学版《概率论与数理统计》一书&#xff0c;第13章第1节例2&#xff1a; 这个解释和模型比较简单易懂。 接下来&#xff0c;第13章第2节的例2也跟此模型相关&#xff1a; 在我自己的理解中&#xff0c;此题的解法跟上一个题目一样&#xff0c;其概率如下面的二维矩阵&a…