【openGauss/MogDB列存表的delta表测试】

已于 2023-12-21 18:22:03 修改
阅读量1k 收藏 15
点赞数 17
分类专栏： openGauss 文章标签： 数据库
于 2023-12-19 14:25:34 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_47308871/article/details/135083954
版权

列存储格式是OLAP类数据库系统最常用的数据格式，适合复杂查询、范围统计类查询的在线分析型处理系统。cstore列存储的主体数据文件以CU为I/O单元，只支持追加写操作，因此cstore只有读共享缓冲区。CU间和CU内的可见性由对应的CUDESE表（astore表）决定，因此其可见性和并发控制原理与行存储astore基本相同。

对于cstore表的单条插入以及更新操作，提供与每个cstore表对应的delta表（astore行存储表），来接收单条插入或单条更新的元组，以降低CU文件的碎片化，如下针对列存表的delta表进行部分测试。

1.1参数配置

数据库里开启enable_delta_store参数。

opengauss=# select * from pg_settings where name like '%delta%';
-[ RECORD 1 ]-------------------------------
name       | enable_delta_store
setting    | on
unit       |
category   | Query Tuning
short_desc | Enable delta for column store.
extra_desc |
context    | postmaster
vartype    | bool
source     | configuration file
min_val    |
max_val    |
enumvals   |
boot_val   | off
reset_val  | on
sourcefile | /opt/mogdb/data/postgresql.conf
sourceline | 803

1.2 创建测试表

创建一张列存表test_cstore和一张行存表test_astore, 列存表test_cstore的deltarow_threshold指定为1000，压缩级别为默认的low。

opengauss=# create table test_cstore(id int,name varchar(20),insert_time timestamptz not null default now()) with (orientation=column,deltarow_threshold=1000);
CREATE TABLE
opengauss=# create table test_astore(id int,name varchar(20),insert_time timestamptz not null default now()) with (orientation=row);
CREATE TABLE

未知.png

根据系统表查询到两张表对应的oid如下,列存表在创建的时候，会对应在cstore这个schema下自动生成两张表，分别为pg_cudesc_${oid} 和pg_delta_${oid}两张表，${oid}对应列存表原始表的oid。

opengauss=# select oid,relname from pg_class where relname like '%test_%';
  oid  |   relname
-------+-------------
 25150 | test_cstore
 25315 | test_astore
(2 rows)

image.png

根据函数可以查询到表在数据目录下的位置，对应的在系统上的表的物理文件的名字和表的oid同名，列存表有几个列，除了原始表，就会多生成几个${oid}_c$的文件。

opengauss=#select pg_relation_filepath('test_cstore');
 pg_relation_filepath
----------------------
 base/25149/25150
(1 row)

opengauss=#  select pg_relation_filepath('cstore.pg_cudesc_25150');
 pg_relation_filepath
----------------------
 base/25149/25157
(1 row)
 
opengauss=#  select pg_relation_filepath('cstore.pg_delta_25150');
 pg_relation_filepath
----------------------
 base/25149/25154
(1 row)

omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ ll base/25149/25150*
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25150
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25150_C1.0
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25150_C2.0
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25150_C3.0
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ ll base/25149/25157*
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25157
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ ll base/25149/25154*
-rw------- 1 omm dbgrp 0 Dec  7 21:45 base/25149/25154

如下是行存表的文件情况。

 pg_relation_filepath
----------------------
 base/25149/25315
(1 row)
 
opengauss=# \q
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ ll base/25149/25178*
-rw------- 1 omm dbgrp 0 Dec  7 21:46 base/25149/25315

1.3    插入数据测试

1.3.1   插入单条数据

1.3.1.1        列存表

从数据库中看，在原始列存表test_cstore和pg_delta表里分别有一条记录。

opengauss=# insert into test_cstore values(1,'test1');
INSERT 0 1
opengauss=# select * from test_cstore;
 id | name  |          insert_time
----+-------+-------------------------------
  1 | test1 | 2023-12-07 22:17:53.571677+08
(1 row)
 
opengauss=# select * from cstore.pg_cudesc_25150;
 col_id | cu_id | min | max | row_count | cu_mode | size | cu_pointer | magic | extra
--------+-------+-----+-----+-----------+---------+------+------------+-------+-------
(0 rows)
 
opengauss=# select * from cstore.pg_delta_25150;
 id | name  |          insert_time
----+-------+-------------------------------
  1 | test1 | 2023-12-07 22:17:53.571677+08
(1 row)

从操作系统上查看，数据情况如下，数据仅写入了pg_delta表中。原始列存表中没有数据。数据库中读取的表的数据来自于pg_delta表。

#原始列存表
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh  base/25149/25150*
0       base/25149/25150
0       base/25149/25150_C1.0
0       base/25149/25150_C2.0
0         base/25149/25150_C3.0
 
#pg_cudesc表
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh base/25149/25157*
0         base/25149/25157
 
#pg_delta表
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh  base/25149/25154*
8.0K    base/25149/25154

pg_delta表中的数据按行存方式存储。

opengauss=# select * from test_cstore;
 id | name  |          insert_time
----+-------+-------------------------------
  1 | test1 | 2023-12-07 22:17:53.571677+08
(1 row) 
opengauss=# select * from cstore.pg_delta_25150;
 id | name  |          insert_time
----+-------+-------------------------------
  1 | test1 | 2023-12-07 22:17:53.571677+08
(1 row)
opengauss=#  select pg_relation_filepath('cstore.pg_delta_25150');
 pg_relation_filepath
----------------------
 base/25149/25154
(1 row)

使用hexdump分析表数据文件中的内容。

omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ hexdump -C base/25149/25184
00000000  00 00 00 00 e0 4d 22 1e  c6 ca 40 00 2c 00 d0 1f  |.....M"...@.,...|
00000010  00 20 06 20 00 00 00 00  67 3a 00 00 00 00 00 00  |. . ....g:......|
00000020  00 00 00 00 00 00 00 00  d0 9f 60 00 00 00 00 00  |..........`.....|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001fd0  03 00 00 00 00 00 00 00  0c 00 00 00 00 00 00 00  |................|
00001fe0  01 00 03 00 02 0b 18 00  01 00 00 00 0d 74 65 73  |.............tes|
00001ff0  74 31 00 00 00 00 00 00  5d 3f f1 e6 ea ae 02 00  |t1......]?......|
00002000

image.png

16进制的01对应的10进制的1
 
16进制的74对应的10进制的116,ascii 码对应为t
16进制的65对应的10进制的101,ascii 码对应为e
16进制的73对应的10进制的115,ascii 码对应为s
16进制的74对应的10进制的115,ascii 码对应为t
16进制的31对应的10进制的49,ascii 码对应为1
 
5d 3f f1 e6 ea ae 02 00部分应该存储的是表中的timestamp类型数据，具体转化方式未深究，待后续分析。

1.3.1.2 行存表

行存表直接按照上述列存表的数据进行一个

opengauss=# insert into test_astore  select * from test_cstore ;                                                                      
INSERT 0 1
opengauss=# select * from test_astore;
 id | name  |          insert_time
----+-------+-------------------------------
  1 | test1 | 2023-12-07 22:17:53.571677+08
(1 row)
 
opengauss=# select pg_relation_filepath('test_astore');
 pg_relation_filepath
----------------------
 base/25149/25315
(1 row)
opengauss=# \q
 
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh base/25149/25315*
8.0K    base/25149/25315
 
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh base/25149/25315*
8.0K    base/25149/25315
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ hexdump -C base/25149/25315
00000000  00 00 00 00 28 ed 2e 1e  18 eb 40 00 2c 00 d0 1f  |....(.....@.,...|
00000010  00 20 06 20 00 00 00 00  7d 3a 00 00 00 00 00 00  |. . ....}:......|
00000020  00 00 00 00 00 00 00 00  d0 9f 60 00 00 00 00 00  |..........`.....|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001fd0  06 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001fe0  01 00 03 00 02 09 18 00  01 00 00 00 0d 74 65 73  |.............tes|
00001ff0  74 31 00 00 00 00 00 00  5d 3f f1 e6 ea ae 02 00  |t1......]?......|
00002000

1.3.1.3测试结果

1.经过测试，列存表test_cstore的deltarow_threshold指定为1000，压缩级别为默认的low。后当插入单条数据，数据条数未达到deltarow_threshold指定值的情况下，系统上查看物理文件，可以看出数据仅存储到了pg_delta表中。
 
2．原始列存表中没有数据。数据库中读取的表的数据来自于pg_delta表。相当于在数据库层面做了一个映射。pg_delta表和原列存表的数据均取自pg_delta对应的物理文件。
 
3.产生的pg_delta表的数据存储方式是行存，它的结构以及物理文件存储形式和单纯以行存表保存的数据完全一致。同样数据的情况下，列存的pg_delta表和普通行存表数据文件对比如下,数据块的排布也是完全一致。

image.png

1.3.1.4 其他现象分析

测试过程，做过delete from并做了vacuum full的操作，列存表的原始表的物理文件位置发生了变化。底层在vacuum full的时候，创建了新的物理文件，整理完数据后，修改了表对应指向的物理文件映射。虽然依旧原始表对应的物理文件中没有数据，但是由于列存表原表的物理文件的名字和oid不一致，直接通过名字无法知道对应的cstore下的两张表是哪两张。

omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ ll base/25149/25181
-rw------- 1 omm dbgrp 0 Dec  8 00:21 base/25149/25181
omm@ubuntu-linux-22-04-desktop:/opt/mogdb/data$ du -sh  base/25149/25181
0       base/25149/25181

image.png

但是可以通过pg_class里的oid和relfilenode关联。找到列存表原始表的新物理文件对应的oid以及其对应的两张cstore的相关的表。

opengauss=# select pg_relation_filepath('test_cstore');
 pg_relation_filepath
----------------------
 base/25149/25181
(1 row)

opengauss=# select oid,relfilenode from pg_class where relfilenode='25181';
  oid  | relfilenode
-------+-------------
 25150 |       25181
(1 row)
 
opengauss=# \dt cstore.*25150*
                        List of relations
 Schema |      Name       | Type  | Owner |        Storage
--------+-----------------+-------+-------+-----------------------
 cstore | pg_cudesc_25150 | table | omm   | {internal_mask=33031}
 cstore | pg_delta_25150  | table | omm   | {internal_mask=32768}
(2 rows)

image.png

1.3.2   继续插入999条

1.3.2.1  列存表

在上述的基础上插入999条数据，凑够列存表test_cstore的deltarow_threshold的 1000阈值。

insert into test_cstore select generate_series(1,999),left(md5(random()::text),10);

image.png


可以发现1000条数据，达到了deltarow_threshold阈值的情况下，数据依然在数据库里原始表和pg_delta表里能查到条数。
而去系统上看物理文件，可以看到100条数据依旧存在pg_delta表中。


image.png

1.3.2.2 行存表

依旧和列存插入一样的数据。

image.png

1.3.2.3测试结果

列存表pg_delta里的数据在正好达到了deltarow_threshold阈值的时候，并没有任何反应，pg_delta里的数据并没有如预期的转换成列存形式存储在cu里。

1.3.3   继续插入1条单条数据

在原始列存表test_cstore和pg_delta表里分别再插入一条记录。

1.3.3.1 列存表

列存表里再插入一条，满足1001条，超过deltarow_threshold阈值，看是否有反应。发现也没有触发行转列。数据依旧存储在pg_delta表里。

insert into test_cstore values(1001,'test1001');
select count(*) from test_cstore;
select count(*) from cstore.pg_cudesc_25150;
select count(*) from cstore.pg_delta_25150;

image.png


如下是列存的三张表物理文件的大小。以及cu文件的大小
 

image.png

image.png

1.3.3.2 行存表

行存表预期正常，此处无需做对比。

image.png

1.3.3.3 测试结果

列存表里再插入一条，满足1001条，超过deltarow_threshold阈值，看是否有反应。发现也没有触发行转列。数据依旧存储在pg_delta表里。

1.3.3.4 手动做一下vacuum deltamerge操作

手动对原始列存表做一次vacuum merge操作之后。
发现pg_delta表里的数据已经清空了，而pg_cudesc表里有了四条记录，但是原始列存表的条数是不变的，此外原始列存表对应的物理文件也是自始至终不会存储数据的，数据只存在pg_detla表或者cu对应的列存表里。
 

image.png


这个时候查询

image.png

相当于col_id的1，2，3分别对应三个列。-10这个id对应的的暂时未知。三列分别在对原始列存表做了vacuum DELTAMERGE后，从pg_delta中把数据按列分别放到不同的cu文件里。此外，原始的pg_delta表会在做完vacuum DELTAMERGE后，抛弃原来的物理文件，直接使用新的物理文件，pg_delta表的relfilenode会发生变化。
 
更换relfilenode，使用新的物理文件的原因猜想可能是为了并发操作，尽可能减少行列转换过程，pg_delta表对更新或者插入的影响。可以一边用旧的文件进行行转列，一边用新的物理文件继续追加新的数据到pg_delta表里，vacuum DELTAMERGE过程申请AccessExclusiveLock。（待验证）
 

image.png


 

image.png


 

image.png



 
其中，生成的C2文件内容如下，转成规范十六进制+ASCII显示便于观察，这一个文件预期应该存储第二列name列的数据。
 

image.png


 
查找到之前插入的test1001。可以看到它相邻的都是这一列上对应的数据。列上的数据是堆积在一起的。
 

image.png


可参照cu文件的结构进行后续分析。

image.png

1.3.4   单点查询，数据分别在pg_delta和cu里区别

870f6110e6的数据在cu里，test1002的数据在pg_delta表里，可以看到，没有索引，仅做单点查询的情况下，无论数据是在cu表里还是在pg_delta里，执行计划是一样的，都显示cstore scan 访问原始列存表。
 

image.png


数据库重启不会影响数据在cu文件和pg_delta里的分布，也不会进行行列转换。

image.png

1.3.5 行转列的最大记录数限制测试（MAX_BATCHROW）

因为创建表的时候没有指定MAX_BATCHROW选项，默认为60000，所以在数据加载过程中一个存储单元可以容纳记录的最大数目是60000。

1.3.5.1 列存表一次性插入60000条数据

一次性插入60000条数据，发现会产生一个行数为60000的cu_id。

image.png

image.png

1.3.5.2 列存表一次性插入61000条数据

而插入61000，则会把61000分成两个cu_id。一个包含60000行，一个包含1000行。

image.png

image.png

1.3.5.3 测试结果

1.一次性插入数条数在进行行转列的时候，有最大值限制，60000是最大值，超出的会拆分成另一个cu_id，然后把记录写入到pg_cudesc里。
2.这次因为单次的插入值大于deltarow_threshold，直接触发了行转列，而不需要手动vacuum deltamerge操作。deltarow_threshol是指定列存表导入时小于多少行的数据进入delta表，而并不是一个delta中数据累积触发的，是单次插入的行数阈值。跟单次写入的行数有关。

小怪兽ysl
关注
  • 17
    点赞
  • 踩
  • 15
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
openGauss行存与列存
weixin_53596073的博客
03-17 2831
列存表限制 列存表不支持数组。 列存表的数量建议不超过1000个。 列存表的表级约束只支持PARTIAL CLUSTER KEY，不支持主外键等表级约束。 列存表的字段约束只支持NULL、NOT NULL和DEFAULT常量值。 列存表不支持alter命令修改字段约束。 列存表支持delta表，受参数enable_delta_store 控制是否开启，受参数deltarow_threshold控制进入delta表的阀值。 列存相关参数 cstore_buffers 列存所使用的共享缓冲
java双向循环链表的实现代码
09-05
据传入的增量修改长度，可以加减）* @param delta 长度增量，正数表示增加，负数表示减少*/private void changeSize(int delta){if (linkedId == null) throw new RuntimeException("该节点未绑定到任何链表");...
列存Delta表是个什么东东
华为云官方博客
03-07 1338
本文从delta表的概念、来历、用法、开启后的影响，delta表数据转移到主表几个方面做了详细的介绍。
openGauss数据库源码解析 | 存储引擎源码解析（19）
weixin_53596073的博客
03-19 766
图4-27 cstore表插入流程示意图cstore表的删除流程主要分为两步。
openGauss数据库源码解析系列文章——存储引擎源码解析（五）
Gauss松鼠会
07-30 7272
上一篇我们详细讲述“4.2.4 ustore”相关内容。本篇我们将继续为小伙伴们带来“4.2.5 行存储索引机制”、“4.2.6 行存储缓存机制”及“4.2.7 cstore”等精彩内容的详细介绍。 4.2.5 行存储索引机制 本节以B-Tree索引为例，介绍openGauss中行存储（格式）表的索引机制。索引本质上是对数据的一种物理有序聚簇。有序聚簇参考的排序字段被称为索引键。为了节省存储空间，一般索引表中只存储有序聚簇的索引键键值以及对应元组在主表中的物理位置。在查询指定的索引键键值元组时，得益
转生异世界的数据库学习之旅（1）初识MongoDB
Momocone的博客
09-20 284
主要讲述有关NoSQL的基础知识，初步认识MongoDB的特点，以及安装部署MongoDB。
openGauss/MogDB列存表vacuum DELTAMERGE过程申请的锁
小怪兽的博客
12-19 444
vacuum DELTAMERGE过程，列存表原表，delta表均获取了8级锁，AccessExclusive Lock，除此之外，还有一个relfilenode对应的表，其实是delta表的原表，在vacuum DELTAMERGE过程中，delta表发生了重建，对应的表文件发生了变化。所以我想到了直接从锁入手，AccessExclusiveLock是8级锁，主库申请8级锁时，会将其记录到WAL日志里。
循序渐进丨openGauss / MogDB 列存表vacuum DELTAMERGE过程申请的锁
weixin_54551388的博客
03-19 700
之前测试 openGauss 列存表vacuum DELTAMERGE的时候，发现pg_delta表会在做完vacuum DELTAMERGE后，使用新的物理文件，pg_delta表的relfilenode会发生变化，相当于表重建了。同时为了测试vacuum DELTAMERGE过程申请了什么锁，通过走读源码可以发现，vacuum DELTAMERGE过程申请了AccessExclusiveLoc...
xscs20131217.rar_plc Delta_产品测试
07-15
标题中的"xscs20131217.rar_plc Delta_产品测试"表明这是一个与PLC（可编程逻辑控制器）相关的程序，具体来说是台达（Delta）品牌的PLC，用于产品测试。日期“20131217”可能表示该程序或项目是在2013年12月17日创建...
实验八顺序表的排序实验报告.docx
07-05
实验八的目的是让学生掌握顺序表的排序方法，特别是希尔排序（Shell Sort）的实现。希尔排序是一种改进的插入排序，通过设置不同的增量序列逐步减少排序的复杂性，从而提高效率。以下是实验报告中的主要知识点： 1....
数字电压表Ptrtues仿真
07-26
数字电压表（Digital Voltmeter, DVM）是电子测量领域中的重要工具，它能精确地显示被测电压的数值。在本项目中，我们聚焦于使用Ptrtues软件进行数字电压表的仿真，该仿真基于TLC2543集成运放芯片，以实现较高的测量...
台达DELTA触摸屏软件
10-29
台达DELTA触摸屏软件是专为台达自动化产品中的HMI（Human Machine Interface）设计的一款强大编程工具，主要用于设计、配置和监控人机交互界面。这款软件支持台达100系列的触摸屏，提供了丰富的图形元素和功能，使得...
OAuth2.0 or Spring Session or 单点登录流程
qq_53374893的博客
07-20 337
一句话精辟解释： 在过滤器放行的时候，偷偷的把原生的 request 和 response 对象换成了它的实现，也就是 调用getSession 的时候拿到的 其实是对redis 操作的Session。但其他的操作还是使用原生的，只不过重写的方法，调用的是子类的，也就是往 redis 里放入 Session，把原生的操作给替换了！分布式Session原理，使用子域名，的时候放入父域名的 JsessionId 然后将这个ID 的所存的内容放入Redis ，这样实现不同域名共享同一sessionID.
基于JSP的高校信息资源共享平台
heye0910032的博客
07-22 522
高校信息资源共享平台的开发和实现，为高校信息资源的管理和共享提供了一个有效的解决方案。通过使用JSP技术和MySQL数据库，本系统实现了一个稳定、安全、易用的高校信息资源管理平台。虽然在开发过程中遇到了一些技术挑战，但通过不断学习和实践，最终完成了一个能够满足用户需求的系统。未来，我们将继续优化系统功能，提升用户体验，以期达到更高的应用价值和社会效益。高校信息资源共享平台的开发和实现，为高校信息资源的管理和共享提供了一个有效的解决方案。
秒杀业务: 简单梳理
最新发布
m0_59925573的博客
07-23 811
（1）在一人一单优惠券秒杀中，先是解决了因线程安全导致的超卖问题，为了满足一人一单的业务需求需要给查询订单表查询库存表上锁，但是synchronized只能满足单机环境下线程安全，在分布式环境对多个JVM需要使用分布式锁，于是手写分布式锁,但是在极端情况下，例如业务超时，会出现“误删”问题，手写锁无法解决，于是引入redisson,借助看门狗机制可以有效解决这个问题。
MySQL（事务、索引）&&MyBatis
hycccccch的博客
07-19 715
事务指的是一组操作的集合，是一个不可分割的工作单位。事务会将所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败默认MySQL的事务是自动提交，即当执行一条DML语句时，MySQL会立即隐式的提交事务开启事务后运行事务不会对数据改变，commit后才会改变数据如果有命令发生错误，需要进行rollback进行回滚、
docker容器
2401_83945639的博客
07-20 879
root@lvs-server ~]# docker start 8a1e7f458daf --手动start启动。-v 目录映射【宿主机的目录映射给容器的某个目录，将容器中的目录挂载到宿主机的目录中】docker rm -f $(docker ps -aq) 删除所有的容器。docker rm -f cname 强制删除，可以删除正在运行的容器。-p 端口映射【宿主机的端口映射给容器的某个端口】创建容器并运行 --这个是mysql的容器。docker ps -q 查看所有容器id。
怎样在 PostgreSQL 中实现数据的异地备份？
技术笔记
07-19 1171
总而言之，在 PostgreSQL 中实现数据的异地备份不是一件难事，但也需要我们认真对待，精心规划。选择合适的备份方法和异地存储方式，制定合理的备份策略，定期进行测试和恢复演练，才能确保我们的数据在任何情况下都能“安然无恙”。🎉相关推荐🍅关注博主🎗️带你畅游技术世界，不错过每一次成长机会！📚领书：PostgreSQL 入门到精通.pdf📙PostgreSQL 中文手册📘PostgreSQL 技术专栏🍅CSDN社区-墨松科技。
const char* fileName = "/pps/fileMgr/client?wait,delta";
06-09
wait,delta"。它的含义可能是访问一个名为client的PPS对象，并在此处等待新的数据到达，同时只会返回新数据的增量变化。PPS是QNX操作系统中的一种持久性内存映射对象，用于进行进程间通信和共享数据。在该程序中，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小怪兽ysl

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值