摘要：

构筑BLock：

指针移动

高效的页面替换：

线程同步的扩展能力：

LEANSTORE

数据结构概述

Swizzling的详细设计

Cooling Stage

输入输出

缓冲区管理的数据结构

乐观锁

Epoch-Based Reclamation

内存分配和NUMA友好的

实现细节和优化方案

汇总：

摘要：

论文认为，传统的采用BufferPool的数据库系统，在锁处理（hash锁、链表锁、Page锁等等）方面做的比较差，导致跑纯内存场景性能上不去。

LeanStore的方案之一是：访问内存页面仅涉及到if判断，不涉及高成本的Hash查找。

LeanStore的方案之二是：在热点路径实现无锁，满足多核场景。

一点关于BLoom过滤器的指标：

Bloom过滤器（每个密钥大约需要10bit）和自适应范围过滤器保留在主存储器中，以避免在每次元组查找时都必须访问冷存储器。

误判率小于1%，开销约为2-3%

在分析行业竞品时，论文提出：

使用Linux操作系统的内存管理带来的问题：数据库失去了对页面换入换出的管理，并且针对大表扫描的场景也不友好。

Bw-tree / LLAMA，针对多核效果会好一些，但是创建和遍历增量的开销会比较大。

构筑BLock：

LeanStore的硬件背景：多核、SSD、大内存。

指针移动

使用虚拟内存地址（即指针）直接引用位于主内存中的页面-访问此类页面不需要哈希表查找。

另一方面，当前在后台存储中的页面仍由其页面标识符引用。这在图2b中进行了说明，该图将页面引用显示为包含指针或页面标识符的圆圈。我们使用指针标记（8字节引用的一位）来区分这两种状态。因此，访问热页的缓冲区管理开销仅包含一个检查该位的条件语句。

即：

记录地址，不是SpaceID + PageNo。而是下面页面的地址（物理地址或者内存地址）
这样的话，淘汰一个页需要修改父页。---论文没有提到这块，但是从上图看，应该是P1\P2\P3都放到Mapping_Table中了
如果加一个MappingTable就不需要修改父页。

论文把在内存中的Page定义为swizzled，在磁盘上的Page定义为unswizzled。在内存中的Page也有逻辑PageID，记录在页面中，而不是引用中。

高效的页面替换：

采用Second Chance的FIFO机制

参考链接：https://www.cnblogs.com/duhuo/p/6210922.html。有意思的是在这个链接中提到Clock算法比SC算法更优。

不知道论文作者为什么没有采用CLOCK算法，这点放到以后分析。

线程同步的扩展能力：

论文首先提到在传统数据库场景下，线程间同步的开销，比如淘汰一个page要保证没有线程访问它，这个在MySQL的情况可以参考链接：https://blog.csdn.net/duxingxia356/article/details/101195054

确实存在通过锁的方式实现互斥。

LeanStore的解决方案：

虚拟指针替代HashTable
Sc的淘汰算法取代LRU
无锁的页面操作，读不加锁，写加页面锁（SMO成本会高些）（后面详细介绍）

LEANSTORE

数据结构概述

在传统的缓冲区管理器中，缓冲池的状态由哈希表管理，该哈希表将PageID映射到buffer frame。frame包含各种“相关整理”信息：

（1）指向页面内容的内存指针，
（2）替换策略所需的状态（例如LRU列表或Second Chance位），
（3）有关磁盘上页面状态的信息（例如，脏标志，是否正在从磁盘加载页面）。

这些点对应于任何缓冲区管理器都必须实现的3种不同功能，即

（1）确定页面是否在缓冲池中（必要时进行页面转换），
（2）确定哪些页面应位于主内存中，
（3）进行中的I / O操作管理。

LeanStore需要类似的信息，使用3个独立的自定义数据结构。

图4的上半部分显示不需要传统的页面转换表，因为它的状态嵌入在缓冲区管理的数据结构本身中。用于实施替换策略的信息被移到一个单独的结构中，该结构称为冷却阶段，如图4的左下角所示。最后，运行中的I / O操作以图4右下角所示的另一种结构进行管理。

Swizzling的详细设计

Swip定义：一个8字节长度的页面引用称之为swip。一个swip可能处于swizzled状态或者unswizzled状态。在上图，swip可能是虚线的圈或者是箭头。

Root Page没有存储在buffer pool，而是一个单独的内存空间。

在传统的缓冲区管理机制中，常见的方案是通过mapping_table将PageID映射到一个指针。通过这个mapping_table进行访问。但是在LeanStore场景下，映射信息被打散，并存储到缓冲区管理的数据中。

例如：Page x 被Page y 和 Page z同时引用，可能被一个Hot page 和 cooling page(cold page)同时引用，这样如果不使用锁来维护一致性的话，成本很高，实现很难。

所以在LeanStore，每个Page有一个单独的swip，来避免一致性问题。因此buffer管理是一个树状结构。一个Page的状态也可以取决于引用它的状态，见上图。

另外一个设计点是：从来不会淘汰一个有活跃下层节点的Page。

论文在后续描述了特殊的swip机制，它可以保证如果一个中间节点被随机淘汰到cooling状态，且至少有一个下层节点是hot。用其中一个下层节点来代替它进入cooling状态。

Cooling Stage

仅当缓冲池中的可用页用完时才使用冷却阶段。从那一刻起，缓冲管理器开始将页面的随机子集（例如，总池大小的10％）保持在冷却状态。大多数内存中页面将保持热态。

Cooling Page按照加入的顺序通过队列管理，最近的在队列头，最老的在队列尾。如果需要为新页面存储内存，则使用最近最少混乱的页面（如果脏了，先进行持久化）。

通过HashTable对FIFO建立索引，当从页面中访问一个unswizzled状态的页面时，先从hash_table中检查，如果有，就把这个cooling页面捞出来，同时修改它的状态。

论文采用用户线程同步的方式把hot page移动到cooling page，原因是担心后台线程慢。笔者不赞同。论文具体实现是：当线程请求新的空白页或者Hot页时，去检查cooling_page的比例，如果小于门限就移动一个page到cooling page。

写到这里，一开始说hash表的锁粒度问题而采用swizzled pointer，这里又用hashtable来管理fifo。现在又要牺牲同步线程的开销，即SQL时延来把一个page放到cooling。

论文用单个latch来保护cooling stage。论文认为这个和IO有关，加点锁没关系。

输入输出

为了避免多个线程同时加载同一个page，论文设计了一个HashTable（笔者不禁要问，HashTable性能这么差，为啥还要用？）用来存储IO过程中的PAGE。具体存储的是Page和mutex。其他线程如果也需要加载会阻塞在这个mutex上，直到加载成功。

缓冲区管理的数据结构

缓冲区管理器的主要功能是支持任意数据结构，同时在整个缓冲区池中维护单个替换策略。另一个优点是无需了解页面的物理组织（例如，B树叶子的布局）即可实现此目的，从而无需修改缓冲区管理器代码本身即可实现缓冲区管理的数据结构。

在前述介绍的，如果淘汰一个内节点，需要确认其所有下一层节点都被淘汰了。因此需要一个遍历机制。这个遍历机制仅对非叶子节点有效。具体流程可以参考上图。

因为淘汰过程中还要修改父节点的中的swip，因此每个节点在frame中存储父节点的指针。由于父节点一定在子节点之后淘汰，因此维护父节点的内存指针成本不高。

A more general approach would be to keep storing only one parent per page, but have two classes of swips. There would be normal swips that, as in our current design, are linked through parent pointers. In addition, one would have “fat” swips that contain both the page identifier and a pointer.

乐观锁

论文提出，在前述内容中，每个Page都有一个latch，这样对多核系统的扩展性不好。因此想采用乐观锁。

主要的方法类似阿里一篇介绍B_LINK树文章提到的计数器或者叫版本号。但是没有给出详细的解决方案。

Epoch-Based Reclamation

基本同LLAMA论文介绍，将待释放的资源加入到Term中，然后把线程也加入到Term中，当所有对应Term的线程都退出了，这个Term内的资源就可以释放了。

但是有一点没明白，这个是MVCC还是普通的读请求，如果是普通的读请求，当后续线程继续读这个资源的话，是不是要把资源从Term1删除，加入到Term2中？如果是MVCC就没问题了。后续不会有新开始的线程读到这个资源。

论文提到为了避免一个大型操作长期没有执行完，导致资源释放不了，会把大型操作拆成小的操作。这里有两个问题，实际线上业务有的时候是Session没有断开，并不是任务是大型的。第二，如何搞定MVCC多版本？比如之前的子操作读到了某条数据的事务T1版本。之后的子操作读到了某条数据的事务T2版本。这样违反了原子性和一致性吧

From LLAMA Paper:

The epoch mechanism invariant is: No operation in epoch E+1 or later epochs can have seen and be using resources freed in epoch E.

内存分配和NUMA友好的

缓冲区管理除了解决大于内存的数据场景以外，还提供了内存管理。是大小固定的内存Page分配。可以防止内存碎片。

LeanStore为所需的缓冲池大小执行一种内存分配。该分配可以由操作系统按需物理地提供（即首次访问），也可以在启动时进行预故障处理。

LeanStore还支持按照NUMA架构进行内存分配。即将内存池和空闲列表在逻辑上划分的和NUMA NODE一样多来实现。但是Cooling等结构是全局的，NUMA awareness是一个尽力的设计方案。

实现细节和优化方案

读不加通过版本号读取（行锁要加吧，否则如何保证一行修改的原子性？），写加Page锁。SMO要从根节点加锁。SMO这块实现效果类似SX锁。

论文提到把Frame和Page放到一起可以提升CPU缓存命中率。确实连续的内存访问会快一些。

在page空间重用的点上，采用线程缓存部分被删除的Page空间，加快效率。

汇总：

整体看是一个类似B+Tree的结构
文章提到读不加锁（读是不是要加行锁呢？），写加Page锁，SMO加Tree锁。
在内存访问过程中，通过Pointer替代hash表，来减少互斥和CPU缓存的开销，一共有两类指针，分别是指向内存和指向页面标识符（类似SpaceID + PageNo）,应该就是逻辑地址。如果页面在内存中，其逻辑地址会存储在Frame。
文章提到其采用swizzled pointer\sc的淘汰算法\io的算法来实现数据库的基本操作
文章提到采用SC的淘汰算法来替代LRU算法，但是相关论文提到CLOCK算法比SC算法更优。
比如在淘汰节点的同时避免请求访问，论文提到是通过epoch-based来解决，但是在LLAMA论文看到貌似是对老版本的删除。这里如果是普通的没有变更的Page，如何处理呢？
页面淘汰的机制，优先淘汰叶子节点。 --- MySQL应该不会
论文提到把Frame和Page放到一起可以提升CPU缓存命中率。确实连续的内存访问会快一些。
在page空间重复利用的点上，采用线程缓存部分被删除的Page空间，加快效率。
论文提到采用后台线程从Cooling stage中持久化脏页，清楚dirty flag。非脏的呢？从论文上看，刷脏和从Cooling Stage取Page是互斥的。

LeanStore 应该是一个原地写的Btree结构，通过版本号来减少加锁成本，但是对SMO没有提到。在其他方面，比如LRU算法、淘汰Page算法等方面做了一定优化。

LeanStore论文分析相关推荐

三维点云去噪无监督学习：ICCV2019论文分析
三维点云去噪无监督学习:ICCV2019论文分析 Total Denoising: Unsupervised Learning of 3D Point Cloud Cleaning 论文链接: htt ...
最新最全的视觉Transformer教程！论文分析 + 逐行Coding，带你轻松玩转ViT
Transformer自2017年被提出后,从横扫NLP领域的风光无二,到陷入一片对其在CV任务有效性的质疑声中,再到不久前在多项图像任务中显示出直逼CNN的优异性能以及 ICCV2021 best ...
Densenet论文解读深度学习领域论文分析博主
深度学习领域论文分析博主博客链接: https://my.csdn.net/u014380165 其中一篇文章: DenseNet算法详解: https://blog.csdn.net/u01438 ...
基于论文分析Google的张量处理器TPU
本文转载自微信公众号CPUinNUDT,由<基于论文分析Google的张量处理器TPU>及<基于论文分析Google的张量处理器TPU(补充)>两篇文章合并而成,如有相关问题, ...
Accurate, Dense, and Robust Multi-View Stereopsis论文分析与代码实现（一）
Accurate, Dense, and Robust Multi-View Stereopsis论文分析与代码实现(一) 本文版权属于重庆大学计算机学院刘骥,禁止转载前言本文依据论文Accura ...
《Unsupervised Salience Learning for Person Re-identification》论文分析
<Unsupervised Salience Learning for Person Re-identification>论文分析 1.基础知识颜色直方图(用于颜色特征的提取):它描述的 ...
APP流量识别与分类论文分析
论文分析---APP流量分类亮点 1.1APP分类 1.2模糊数据处理 1.3提高可靠性(训练集和测试集数据来自一次提取还是不同时间提取) 1.4对比时间,版本,设备改变,操作系统版本改变的影响 1 ...
TTiki-Taka: Attacking and Defending Deep Learning-based Intrusion Detection Systems 论文分析
TTiki-Taka: Attacking and Defending Deep Learning-based Intrusion Detection Systems 论文分析摘要神经网络在网络入 ...
社会网络——信管考研方向之管科图情论文分析
(一)项目介绍项目目标是什么? 使用Python的词云库和pyecharts库以及UCINET6对论文数据进行可视化网络关系分析 (二)结果评估目标是否完成? 完成目标完成情况? 论文关键词词云 ...

LeanStore论文分析

摘要：

构筑BLock：

指针移动

高效的页面替换：

线程同步的扩展能力：

LEANSTORE

数据结构概述

Swizzling的详细设计

Cooling Stage

输入输出

缓冲区管理的数据结构

乐观锁

Epoch-Based Reclamation

内存分配和NUMA友好的

实现细节和优化方案

汇总：

LeanStore论文分析相关推荐

最新文章

热门文章