miniob01
基本模块网络模块:客户端交互 应答等 src/observer/net下 主要是server.h与cpp
sql解析:将用户输入的语句解析成语法书 observer/sql/parser里lex负责词法解析 yacc负责语法解析
计划执行模块: 根据用户输入的sql命令 执行对应语句 将生成结果返回给客户端 execute_stage.cpp
会话管理模块: 用户链接 调整参数 session下
元数据管理: 当前数据库 表的元数据 在observer/storage/common下
客户端:测试端 接收 发送请求ob client
接下来的执行计划缓存 sql/plan_cache里 将第一次生成的执行计划缓存 避免重复查询
语义解析:将生成的语法树转化为数据库内部结构sql/parser (非必须)
查询缓存:将执行的查询结构缓存在内存中 下次直接返回quert_cache
查询优化:通过一定规则与统计数据 调整 重写语法书observer/sqlSEDA 结合时间驱动与多线程的优点
oceanbase缓存池
研究问题:搜索引擎如何管理磁盘上数据与内存上数据的流动1.内存池缓冲磁盘上文件的一部分2.用户修改或插入数据时(未保存) 数据时存在缓存池的 这样避免了频繁读写硬盘
3.缓存池两大控制的目标a.空间上 把经常一起用的数据集中在缓存池储存 便于直接读b.时间上(什么时候把数据存到缓冲池 什么时候存到硬盘) 最小化时间
4.如果执行器要读page2：先从缓存池里面找 如果没有 就把磁盘上目录加载到缓存池 再找出page2读到缓存池里 执行器再解析 后续排序 筛选都是执行器
5.缓存池也分页(frame)如何知道缓存池存了哪些数据:有pagetable 类似于索引的机制 也可以在其中加锁
6.locks vs latches锁(locks)一般指代逻辑上的 一个表锁(latches 有时候也叫mutex)底层的 给表的底层的数据加上锁
7.page directory 磁盘上的目录 记的是几号页在什么位置上page table 内存池里的索引
8.文件页储存在哪有全局策略和本地策略
9.缓存池不止一个 降低锁的冲突
ip地址 主机名
ifconfig 查看ip地址
oceanbase存储引擎2
假如一个数据很长很大 会新开一个overflow page(溢出页) 一页不够再开一页一般如果存一个文件或者什么大的东西 可以记个地址进去 效率高如果有外部文件 可以链接到字段 但数据库无法保证其会不会被别的软件修改系统目录/元数据 如表 列结构 索引 用户 权限等 存在里面 每个数据库的定义不一样
工作负载(workloads)
OLTP在线交易处理OLTP 场景包含简单的读写语句，且每个语句都只操作数据库中的一小部分数据例：a给了b 5块钱 a-5 b+5
OLAP在线分析处理主要处理复杂的，需要检索大量数据并聚合的操作例： 支付宝今日交易数据
Hybrid OLTP + OLAP混合态 均可以处理
数据在底层并不一定是一行一行存的 这是用户不用考虑的
1.n-ary storage model(NSM) 一个数据一行 这个就很适合OLTP优势:如果要SELECT一行 直接走索引就能取到tuple劣势：如果是复杂的分析 列查找等 要扫描所有数据 里面有很多无用数据 但是因为是行存 必须一个个解析 所以性能低下
2.decomposition storage model( ...
软链接 日期时区
系统中创建软链接 将文件 文件夹链接到其它位置 类似于快捷方式ln -s 参数1 参数2-s 创建软连接参数一:被连接的文件或文件夹参数二:要链接去的目的地
日期时区date [-d] [+ 格式化字符串]如按照2022-01-01的格式date +%Y-%m-%ddate +%Y-%m-%d “%H:%M:%S” 因为有空格 后面要变字符串-d是显示日期计算date -d “+1 day” +%Y%m%d 显示后一天date -d “+1 monrh” +%Y%m%ddate -d “-1 year” +%Y%m%d修改时区先删除自带的localtime文件 再软链接一个rm -f /etc/localtimesudo ln -s /user/share/zoneinfo/Asia/Sichuan /etc/localtime