【StoneDB技术解析】验证相关数据包是否需要解压缩
本篇文章给大家分享《【StoneDB技术解析】验证相关数据包是否需要解压缩》,覆盖了数据库的常见基础知识,其实一个语言的全部知识点一篇文章是不可能说完的,但希望通过这些问题,让读者对自己的掌握程度有一定的认识(B 数),从而弥补自己的不足,更好的掌握它。
在StoneDB中,数据包分为以下几类:
- 不相关的数据包:不满足查询条件的数据包。
- 相关的数据包:满足查询条件的数据包。
- 可疑的数据包:数据包中的数据部分满足查询条件,需要进一步解压缩数据包才能得到满足条件的数据行。
通过对数据包的划分,知识网格技术过滤掉不相关的数据包,读取相关的数据包和可疑的数据包。其中相关的数据包不需要解压缩,只读取元数据,不会发生IO,可疑的数据包需要解压缩,会发生IO。
1)创建表t_user CREATE TABLE t_user( id INT NOT NULL AUTO_INCREMENT, first_name VARCHAR(10) NOT NULL, last_name VARCHAR(10) NOT NULL, sex VARCHAR(5) NOT NULL, score INT NOT NULL, copy_id INT NOT NULL, PRIMARY KEY (`id`), key idx_lastname(last_name) ) engine=STONEDB; 2)创建存储过程 DELIMITER // create PROCEDURE add_user(in num INT) BEGIN DECLARE rowid INT DEFAULT 0; DECLARE firstname CHAR(1); DECLARE name1 CHAR(1); DECLARE name2 CHAR(1); DECLARE lastname VARCHAR(3) DEFAULT ''; DECLARE sex CHAR(1); DECLARE score CHAR(2); WHILE rowid
1)验证读取相关数据包
SQL的语义逻辑是对字段 first_name 进行分组统计,在StoneDB中,元数据信息记录在元数据节点,如果能通过元数据节点读取到元数据,就不需要解压缩数据包,不发生IO。
在InnoDB中,表的统计信息记录在mysql.innodb_table_stats,优化器根据表和索引的统计信息,生成一个最优的执行计划,然后执行SQL。分别在InnoDB与StoneDB执行,通过SQL profile观察读取IO的情况。
注:为规避缓存的影响,每组测试前重启数据库实例。
InnoDB
mysql> set profiling=on; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> select first_name,count(*) from t_user_innodb group by first_name; +------------+----------+ | first_name | count(*) | +------------+----------+ | 侯 | 476424 | | 刘 | 475764 | | 吴 | 475979 | | 周 | 475891 | | 孙 | 950444 | | 彭 | 476632 | | 徐 | 476219 | | 李 | 475521 | | 杨 | 476026 | | 林 | 477289 | | 柳 | 476250 | | 江 | 476623 | | 王 | 475119 | | 赵 | 476529 | | 邹 | 476852 | | 郑 | 476379 | | 钱 | 476829 | | 阮 | 476336 | | 陈 | 476746 | | 高 | 476148 | +------------+----------+ 20 rows in set (8.62 sec) mysql> show profiles; +----------+------------+-------------------------------------------------------------------+ | Query_ID | Duration | Query | +----------+------------+-------------------------------------------------------------------+ | 1 | 8.61591075 | select first_name,count(*) from t_user_innodb group by first_name | +----------+------------+-------------------------------------------------------------------+ 1 row in set, 1 warning (0.00 sec) mysql> show profile cpu,block io for query 1; +----------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +----------------------+----------+----------+------------+--------------+---------------+ | starting | 0.000149 | 0.000059 | 0.000083 | 0 | 0 | | checking permissions | 0.000027 | 0.000011 | 0.000015 | 0 | 0 | | Opening tables | 0.048181 | 0.003919 | 0.007952 | 608 | 0 | | init | 0.000036 | 0.000014 | 0.000021 | 0 | 0 | | System lock | 0.000022 | 0.000009 | 0.000013 | 0 | 0 | | optimizing | 0.000017 | 0.000007 | 0.000010 | 0 | 0 | | statistics | 0.000029 | 0.000012 | 0.000016 | 0 | 0 | | preparing | 0.000022 | 0.000009 | 0.000013 | 0 | 0 | | Creating tmp table | 0.000045 | 0.000019 | 0.000027 | 0 | 0 | | Sorting result | 0.000016 | 0.000007 | 0.000009 | 0 | 0 | | executing | 0.000014 | 0.000005 | 0.000008 | 0 | 0 | | Sending data | 8.566974 | 6.905969 | 0.772964 | 873888 | 0 | | Creating sort index | 0.000144 | 0.000164 | 0.000037 | 64 | 0 | | end | 0.000014 | 0.000012 | 0.000003 | 32 | 0 | | query end | 0.000028 | 0.000038 | 0.000009 | 0 | 0 | | removing tmp table | 0.000019 | 0.000015 | 0.000003 | 0 | 0 | | query end | 0.000012 | 0.000010 | 0.000002 | 0 | 0 | | closing tables | 0.000031 | 0.000025 | 0.000006 | 0 | 0 | | freeing items | 0.000032 | 0.000027 | 0.000006 | 0 | 0 | | logging slow query | 0.000067 | 0.000054 | 0.000012 | 0 | 8 | | cleaning up | 0.000035 | 0.000028 | 0.000006 | 0 | 0 | +----------------------+----------+----------+------------+--------------+---------------+ 21 rows in set, 1 warning (0.00 sec)
从SQL profile可知,SQL在InnoDB执行的过程中,发生IO的阶段有Opening tables、Sending data、Creating sort index、end,其中Opening tables是每张表第一次加载都会经历的,可排除讨论。重点关注Sending data部分,它表示在执行器的任意阶段,通常是存储引擎层与Server层的IO交互过程。
StoneDB
mysql> set profiling=on; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> select first_name,count(*) from t_user group by first_name; +------------+----------+ | first_name | count(*) | +------------+----------+ | 赵 | 476529 | | 徐 | 476219 | | 王 | 475119 | | 阮 | 476336 | | 柳 | 476250 | | 侯 | 476424 | | 孙 | 950444 | | 郑 | 476379 | | 高 | 476148 | | 林 | 477289 | | 邹 | 476852 | | 彭 | 476632 | | 李 | 475521 | | 吴 | 475979 | | 刘 | 475764 | | 钱 | 476829 | | 周 | 475891 | | 杨 | 476026 | | 陈 | 476746 | | 江 | 476623 | +------------+----------+ 20 rows in set (0.59 sec) mysql> show profiles; +----------+------------+------------------------------------------------------------+ | Query_ID | Duration | Query | +----------+------------+------------------------------------------------------------+ | 1 | 0.59069975 | select first_name,count(*) from t_user group by first_name | +----------+------------+------------------------------------------------------------+ 1 row in set, 1 warning (0.00 sec) mysql> show profile cpu,block io for query 1; +----------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +----------------------+----------+----------+------------+--------------+---------------+ | starting | 0.000160 | 0.000066 | 0.000089 | 0 | 0 | | checking permissions | 0.000027 | 0.000011 | 0.000015 | 0 | 0 | | Opening tables | 0.011405 | 0.003718 | 0.007688 | 0 | 240 | | System lock | 0.000385 | 0.000163 | 0.000222 | 0 | 0 | | init | 0.000050 | 0.000021 | 0.000028 | 0 | 0 | | optimizing | 0.000143 | 0.000061 | 0.000082 | 0 | 0 | | update multi-index | 0.000052 | 0.000022 | 0.000030 | 0 | 0 | | aggregation | 0.578315 | 2.639504 | 0.981471 | 0 | 8 | | query end | 0.000069 | 0.000043 | 0.000026 | 0 | 0 | | closing tables | 0.000035 | 0.000021 | 0.000013 | 0 | 0 | | freeing items | 0.000034 | 0.000021 | 0.000013 | 0 | 0 | | cleaning up | 0.000027 | 0.000017 | 0.000010 | 0 | 0 | +----------------------+----------+----------+------------+--------------+---------------+ 12 rows in set, 1 warning (0.00 sec)
从SQL profile可知,SQL在StoneDB执行的过程中,只在Opening tables阶段发生IO。其它阶段没有发生IO,说明相关数据包是不需要解压缩的,通过元数据得到。
2)验证读取可疑数据包
SQL的语义逻辑是查询一行数据,StoneDB可以通过知识网格技术过滤掉不相关的数据包,由于只返回一行数据,最终只能找到可疑的数据包,然后解压缩可疑的数据包,最终得到这一行数据。InnoDB还是根据统计信息生成一个最优的执行计划去执行SQL。
InnoDB
mysql> set profiling=on; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> select count(*) from t_user_innodb where first_name='柳' and copy_id=9968888; +----------+ | count(*) | +----------+ | 1 | +----------+ 1 row in set (3.20 sec) mysql> show profile cpu,block io for query 1; +----------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +----------------------+----------+----------+------------+--------------+---------------+ | starting | 0.000170 | 0.000072 | 0.000092 | 0 | 0 | | checking permissions | 0.000030 | 0.000013 | 0.000016 | 0 | 0 | | Opening tables | 0.024121 | 0.004351 | 0.008638 | 800 | 0 | | init | 0.000049 | 0.000021 | 0.000027 | 0 | 0 | | System lock | 0.000019 | 0.000008 | 0.000011 | 0 | 0 | | optimizing | 0.000022 | 0.000010 | 0.000012 | 0 | 0 | | statistics | 0.000030 | 0.000013 | 0.000016 | 0 | 0 | | preparing | 0.000026 | 0.000012 | 0.000015 | 0 | 0 | | executing | 0.000013 | 0.000005 | 0.000007 | 0 | 0 | | Sending data | 3.169882 | 2.755171 | 0.389367 | 534176 | 0 | | end | 0.000069 | 0.000050 | 0.000018 | 0 | 0 | | query end | 0.000029 | 0.000022 | 0.000008 | 0 | 0 | | closing tables | 0.000031 | 0.000023 | 0.000009 | 0 | 0 | | freeing items | 0.000035 | 0.000025 | 0.000009 | 0 | 0 | | cleaning up | 0.000038 | 0.000028 | 0.000010 | 0 | 0 | +----------------------+----------+----------+------------+--------------+---------------+ 15 rows in set, 1 warning (0.00 sec)
StoneDB
mysql> set profiling=on; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> select count(*) from t_user where first_name='柳' and copy_id=9968888; +----------+ | count(*) | +----------+ | 1 | +----------+ 1 row in set (0.01 sec) mysql> show profile cpu,block io for query 1; +----------------------+----------+----------+------------+--------------+---------------+ | Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | +----------------------+----------+----------+------------+--------------+---------------+ | starting | 0.000173 | 0.000081 | 0.000086 | 0 | 0 | | checking permissions | 0.000026 | 0.000013 | 0.000013 | 0 | 0 | | Opening tables | 0.010228 | 0.009385 | 0.000843 | 0 | 240 | | System lock | 0.000232 | 0.000113 | 0.000119 | 0 | 0 | | init | 0.000045 | 0.000021 | 0.000022 | 0 | 0 | | optimizing | 0.000144 | 0.000071 | 0.000074 | 0 | 0 | | update multi-index | 0.003694 | 0.002027 | 0.006428 | 0 | 0 | | aggregation | 0.000191 | 0.000093 | 0.000098 | 0 | 16 | | query end | 0.000020 | 0.000010 | 0.000010 | 0 | 0 | | closing tables | 0.000029 | 0.000014 | 0.000015 | 0 | 0 | | freeing items | 0.000033 | 0.000016 | 0.000017 | 0 | 0 | | cleaning up | 0.000027 | 0.000013 | 0.000013 | 0 | 0 | +----------------------+----------+----------+------------+--------------+---------------+ 12 rows in set, 1 warning (0.00 sec)
从SQL profile可知,SQL在StoneDB执行的过程中,在aggregation阶段发生IO。
综上所述:
- 知识网格技术过滤出相关的数据包后,只需要读取元数据,不再解压缩数据包;
- 知识网格技术过滤出可疑的数据包后,需要解压缩数据包。
好了,本文到此结束,带大家了解了《【StoneDB技术解析】验证相关数据包是否需要解压缩》,希望本文对你有所帮助!关注golang学习网公众号,给大家分享更多数据库知识!

- 上一篇
- Apache Doris 助力网易严选打造精细化运营 DMP 标签系统

- 下一篇
- StoneDB 读、写操作的执行过程
-
- 曾经的项链
- 太详细了,码住,感谢老哥的这篇技术文章,我会继续支持!
- 2023-03-24 00:23:17
-
- 狂野的寒风
- 这篇技术文章太及时了,很详细,真优秀,收藏了,关注大佬了!希望大佬能多写数据库相关的文章。
- 2023-03-08 05:28:15
-
- 香蕉红酒
- 很棒,一直没懂这个问题,但其实工作中常常有遇到...不过今天到这,帮助很大,总算是懂了,感谢博主分享文章!
- 2023-02-28 13:49:36
-
- 数据库 · MySQL | 18小时前 | 索引 数据类型 字符集 存储引擎 CREATETABLE
- MySQL新建表操作指南与建表技巧
- 462浏览 收藏
-
- 数据库 · MySQL | 1个月前 | 条件判断
- CASEWHEN条件判断的嵌套使用详解与实战场景分析
- 469浏览 收藏
-
- 数据库 · MySQL | 1个月前 | java php
- CSV文件批量导入MySQL的性能优化秘籍大揭秘
- 289浏览 收藏
-
- 数据库 · MySQL | 1个月前 |
- GaleraCluster多主集群配置与冲突解决攻略
- 239浏览 收藏
-
- 数据库 · MySQL | 1个月前 | 窗口函数实战
- MySQL窗口函数实战案例深度剖析
- 315浏览 收藏
-
- 数据库 · MySQL | 1个月前 | 自定义函数
- MySQL插件开发入门:自定义函数(UDF)编写指南
- 184浏览 收藏
-
- 数据库 · MySQL | 1个月前 |
- Windows系统MySQL8.0免安装版配置攻略
- 227浏览 收藏
-
- 数据库 · MySQL | 1个月前 | MySQL错误 数据库诊断
- 深度解析错误代码1045/1217/1205的根本原因及解决方案
- 202浏览 收藏
-
- 数据库 · MySQL | 1个月前 | sql注入 编码规范
- 防范SQL注入必备:编码规范与工具推荐指南
- 140浏览 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 542次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 508次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 497次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 484次学习
-
- 笔灵AI生成答辩PPT
- 探索笔灵AI生成答辩PPT的强大功能,快速制作高质量答辩PPT。精准内容提取、多样模板匹配、数据可视化、配套自述稿生成,让您的学术和职场展示更加专业与高效。
- 15次使用
-
- 知网AIGC检测服务系统
- 知网AIGC检测服务系统,专注于检测学术文本中的疑似AI生成内容。依托知网海量高质量文献资源,结合先进的“知识增强AIGC检测技术”,系统能够从语言模式和语义逻辑两方面精准识别AI生成内容,适用于学术研究、教育和企业领域,确保文本的真实性和原创性。
- 24次使用
-
- AIGC检测-Aibiye
- AIbiye官网推出的AIGC检测服务,专注于检测ChatGPT、Gemini、Claude等AIGC工具生成的文本,帮助用户确保论文的原创性和学术规范。支持txt和doc(x)格式,检测范围为论文正文,提供高准确性和便捷的用户体验。
- 30次使用
-
- 易笔AI论文
- 易笔AI论文平台提供自动写作、格式校对、查重检测等功能,支持多种学术领域的论文生成。价格优惠,界面友好,操作简便,适用于学术研究者、学生及论文辅导机构。
- 42次使用
-
- 笔启AI论文写作平台
- 笔启AI论文写作平台提供多类型论文生成服务,支持多语言写作,满足学术研究者、学生和职场人士的需求。平台采用AI 4.0版本,确保论文质量和原创性,并提供查重保障和隐私保护。
- 35次使用
-
- golang MySQL实现对数据库表存储获取操作示例
- 2022-12-22 499浏览
-
- golang 基于 mysql 简单实现分布式读写锁
- 2023-01-07 384浏览
-
- 详解如何利用GORM实现MySQL事务
- 2023-01-07 184浏览
-
- Go语言实现操作MySQL的基础知识总结
- 2023-01-23 265浏览
-
- Go结合Gin导出Mysql数据到Excel表格
- 2023-01-01 352浏览