[15-445]Database Storage related1 memo

最先的一部分还是介绍存储介质速度层级

 

总的来说就是 cpu > memory > disk 但是究竟快多少呢？

 我觉得这里只需要记住一个常用的关键论点，内存约比 ssd 快 150 倍 比普通的 HDD 快 20000 倍。单从这里就可以比较清晰的知道，在内存里汇总计算大量数据对数据库效率的重要性。

 

另外我们还需要回答两个问题。

1. dbms 如果组织展示数据库在硬盘文件上面。

2. dbms 如何管理内存和数据从硬盘和内存挪动。

 

FileStorage

不管是硬盘还是系统还是数据库都是用页来管理数据，通常情况下(硬件 page) / (操作系统 page) 约 4kb/page

而数据库 page 包括 512b ~ 16kb 

 

 

PageLayout

当然每个数据库都会有自己的页管理 metadata 来告诉请求者有多少页，有多少空间，你具体要使用的页在哪里等等信息。我们现在到 page 内部去看看是什么结构。

每一个页都会有 Header 来描述一些 metadata 信息，包含 page size | checksum | version | transaction visibility | compression information 等等等，都可以放在头信息里。

 

 

 页内部通常的组织形式是 slotted pages。 

 

针对这个结构值得多理解一下。我刚开始看的时候确实页不太理解这种结构的组织。

我们会有一些 slot array 来记录下面真正的 tuple 数据开始的位置。slot array 记录的是每一个 tuple 开始的 offset。这样我们可以直接通过我们要的是 tuple #x 直接去 slot array 里面对应 slot 拿到该 tuple 的起始地址然后开始读取，直到读取到下一个 slots 开始前的位置前结束。这样做可以让我们支持变长的 tuple，我们将可以不再 fixed tuple 的大小。这里注意 slot array 是从头部开始往后存储占用空间，而我们实际的 tuple 内容是从页的最后往前存储，直到这个页里面已经无法再存储更多的配对的时候，我们就需要开启下一个页。

ok 现在来看如果我们在这个结构里面想要找到对应的页，我们只需要知道 page_id 找到这个对应的页，再找到 offset。读到首地址，我们就可以访问到该页的数据了。

所以我们在找数据的时候变成了 => where_is_data = query_page_dict => page_id + offset/slot

 

Tuple Layout

 

 感觉跟 page 差不多的设计，tuple data 的内部也是有保存元信息的 header 然后是具体的数据。

 

 然后有的数据库现在还支持 pre join(denormalize) 对相关表的页进行重新组织，使得相关的数据在同一页中以加快查询。

 

 

Reference:

2022-[15-445]Database Storage part https://www.youtube.com/watch?v=df-l2PxUidI&t=466s