江苏龙网

  1. 首页 > 人文 > >

小镇的夕阳|深度 | X-Engine的In-Memory读性能优化( 三 )


SIMD指令加速长Key比较解决了数据页中记录查找的cache访问问题之后 ， 继续往下perf分析 ， 会发现查找路径中的compare比较函数消耗了较多的CPU cycle数 ， 在查找长key场景时 ， 计算开销的问题会更加明显 。 考虑到我们新的数据页编码结构中 ， 每次读取会将多个需要先后比较的index key同时load进CPU cache ，引入SIMD指令集可以实现在一个CPU cycle内并行检索完在cache中的多个index key 。
为了使用SIMD指令集 ， 我们需要对X-Engine的数据页编码继续进行调整 ， 如下图所示：
小镇的夕阳|深度 | X-Engine的In-Memory读性能优化对key进行lossy compression：由于SIMD寄存器的处理单位segment最长为64bit（AVX-512指令集） ， 简单地分段并行比较长key会因为额外逻辑抹去并行计算带来的性能提升 。 因此这里将key拆分为common prefix+significant Nbits+suffix ， 避免了分段并行比较在prefix上的多余操作 ， 而significant Nbits（N取决于SIMD寄存器的segment大小）逻辑上具有很高的区分度 ， 在大多数情况下都仅需要一次SIMD比较就能得到结果 ， 如果出现相等的情况 ， 也只需要顺序比较一部分的index key的suffix 。
选择固定的fanout并使用padding补齐：SIMD指令的处理带宽（即SIMD寄存器中segment的数量）均为2的指数 ， 如果fanout仍然是N开根号 ， prepare过程会增加很多额外的操作 。 同时考虑对CPU cache友好的node长度和对SIMD指令处理带宽的适配 ， 以及DataBlock中restart key的数量的范围 ， leaf node的fanout固定为8 ， root node的fanout固定为16 ， 实际key的数量不足node的fanout ， 则用node中最大的key padding补齐 ， 这样可以直接在代码中将SIMD指令写死 ， 减少分支预测开销 。
对索引页和数据页进行重新编码再配合SIMD指令加速 ， 在不同行长下测试最大能提升20%左右的点查性能 。 在TP系统中 ， 单个请求读写的数据量非常少 ， 在我们的测试场景一次只操作一条记录 ， 因此数据页编码和SIMD指令优化一起对端到端的性能提升达到20% ， 已经非常可观.
BP的代价及PointSwizzlingBufferPool管理成本面向全内存的数据库和面向磁盘的数据库具有不同的设计原则 。 一个典型的差异是：当访问一个数据页时 ， 全内存数据库倾向于使用指针直接访问 ， 而面向磁盘的数据库一般则通过PageID在一个数据结构中间接地获得该数据页的内存地址（当该数据页没有被缓存时需要先读盘） ，然后才能访问到该数据页 。 这样的间接访问会带来额外的查找开销 ， 已有研究显示在数据集能够完全装载进内存时 ， BufferPool管理结构会消耗超过30%的CPU资源 。
由于OS的虚拟内存地址空间相对于DB的数据集大小来讲是足够的 ， 一个可能的解决办法是对面向磁盘的数据库引擎也使用指针直接访问 ， 当内存空间不足时 ， 则依靠OS的Swap机制来进行内存页的汰换 ， 这样在数据集小于可用内存时 ， 由于消除了PageID映射查找的开销 ， 存储引擎会具有与In-Memory数据库一样的性能 。
但这种方法有一个缺陷 ， 在数据集大于系统可用物理内存时 ， 由于OS的的Swap机制不能准确的感知DB中的数据访问特征 ， 它有可能将一个非常关键的内存对象Swap到到磁盘上 ， 导致性能波动 。
X-Engine是一个通用存储引擎 ， 其装载的数据集大部分时候都超出了可用内存的大小 ， 因此也必须引入一个BufferPool来管理对数据页的访问 。 但是在我们的设计中 ， 冷热分离精准且用户负载存在明显的局部性特征时 ， 大部分访问都是命中内存的 ， 这个时候BP的30%的CPU资源消耗显得非常浪费 ， 需要找到办法消除 。
X-Engine中的Extent信息/索引页/数据页都是通过BufferPool的Cache管理 。 其中的Cache使用哈希表和双向链表管理数据 ， 通过哈希查找获取数据 ， 命中后还要维护LRU链表的顺序信息 。 开销主要来源于三个方面：


推荐阅读


上一篇：传染病|北京两病例隐瞒去过新发地、隔离期超范围活动 警方展开调查

下一篇：强降雨来袭 北京排水集团防汛保障人员全部进入战时状态