4.3 数据打包压缩和整理压缩
当部分package达到最大容量后,它会被转换为big package并压缩到磁盘上以减少空间消耗。压缩过程采用写时复制模式以避免访问冲突。也就是说,生成一个新package来保存压缩数据,而不对部分package进行任何更改。PolarDB-IMCI在压缩后更新元数据,将部分打包替换为新的package(即以原子方式更新指向新打包的指针),对于不同的数据类型,列索引采用不同的压缩算法。数值列采用参考帧、delta编码和位压缩的组合,而字符串列使用字典压缩。此外,由于打包是不可变的,当活动事务大于所有VID时,即没有活动事务引用插入VID映射时,该打包的插入VID映射是无用的。在这种情况下,PolarDB-IMCI会删除行组中的插入VID映射以减少内存占用。
整理
删除操作可能在一个打包中设置删除VID,从而在该打包中留下空洞。随着无效行的数量随时间增加,扫描性能和空间利用效率会降低。PolarDB-IMCI定期检测和重新整理不足的打包,以保持列索引无效行的低水位。例如,少于一半有效行的稀疏包被选为不能进行package。然后,后台线程发起一个整理事务,其中包括大量的更新操作,针对每个迁移的有效行,将选定的打包的所有有效行重新追加到部分打包中。请记住,列索引的更新操作是就地进行的,因此旧行在整理期间甚至之后仍然可以进行前台操作,这使得更新操作不受阻塞。整理后选定的打包在没有活动事务访问时将被永久删除。
5 更新传播
在本节中,我们描述了我们在同步异构数据存储方面的努力。对OLTP的最小干扰是PolarDB-IMCI的一个高优先级目标。为了实现这个目标,PolarDB-IMCI中的更新传播是通过REDO日志实现的,消除了将额外逻辑日志持久化的开销。在REDO日志的基础上,PolarDB需要尽可能及时地保持RO节点的更新以保持数据的新鲜度。为此,我们引入了前置提交日志传送(CALS)来减少可见延迟,并引入了两阶段无冲突并行回放(2P-COFFER)机制来提高回放吞吐量。
5.1 提前提交日志传输 为了最小化性能干扰,在PolarDB-IMCI中,对RO节点的更新是完全异步的。鉴于此,为增强数据的新鲜度,PolarDB-IMCI使用了提前提交日志传输(CALS)技术,在提交之前将事务传送到其他节点。如图5所示,一个事务由多个日志项组成:最后一个日志项是提交或中止日志,前面的日志项是DML日志。每个日志项都被分配了一个日志序列号(LSN)。例如,事务TID为101的日志项有LSN 300∼302。日志项300和301是DML操作的日志,而日志项302包含了事务的决定(即中止)。当RW节点将一个日志项写入共享存储(即PolarFS)后,它通过广播其最新的LSN(在我们的例子中为299)通知RO节点。当接收到LSN时,RO节点立即从PolarFS中读取日志。然后,每个DML日志都会被解析为一个DML语句,并基于其TID存储在一个事务缓冲区中(每个事务一个缓冲单元)。整个过程不需要等待RW节点提交事务。例如,在日志项299中的最终提交之前,具有TID 100的事务中的DML操作将被传输。当RO节点读取一个提交日志项时,较早的DML语句已经被解析并作为逻辑操作交付到事务缓冲区中,使得PolarDB-IMCI能够立即重放这些DML操作。当读取一个中止日志项时,RO节点只需释放事务缓冲区,无需回滚数据。
5.2 两阶段无冲突并行回放 如前所述,PolarDB-IMCI不会为了更新传播而生成额外的逻辑日志,而是重用REDO日志。其原因是日志传送会使RW节点写入更多的日志项,从而影响OLTP性能。然而,从长远来看,使用REDO日志同步异构存储被认为几乎是不可能的[34]。这存在三个挑战:(1) REDO日志仅记录行存储中物理页面的变化,缺乏数据库级别或表级别的信息[42](例如,RO节点不知道页面更改对应哪个表)。(2) REDO日志还包括由行存储本身引起的页面更改,而不仅仅是用户的DML操作,例如B+树的分裂/合并和页面整理。列索引不能应用这些日志,否则可能导致不一致。(3) REDO日志仅包含差异而不是完整的更新,以减少日志占用空间。
如图6所示,PolarDB-IMCI通过两个重放阶段解决了这些挑战。第一阶段是将REDO日志重放到RO节点的内存中的行存储的副本。在这个阶段,PolarDB-IMCI获取完整的信息,将REDO日志解析为逻辑DML语句。然后,第二阶段是将DML语句重放到列索引中。重放的性能对我们的系统至关重要。为了实现高性能,文献中提出了几种并行重放机制[6, 45, 46, 54]。这些工作要么以会话粒度进行并行重放,要么以事务粒度进行并行重放,并借助冲突处理辅助工具(例如锁或依赖图)或者乐观控制。与这些工作不同,PolarDB-IMCI提出了一种新的重放方法,即2P-COFFER,使得两个重放阶段都是无冲突的。在2P-COFFER中,第一阶段以页面粒度进行,而第二阶段以行粒度进行,以实现对不同页面/行的并发修改。修改相同页面/行但属于不同事务的日志条目被视为依赖项,应该按顺序重放。使用2P-COFFER,RO节点的重放吞吐量要远高于RW节点的OLTP吞吐量(图13)。
5.3 第一阶段:物理日志解析 如图7所示,PolarDB的REDO日志记录包含多个字段。为简单起见,我们以更新操作为例,其他类型的操作类似。
本文分享自 AustinDatabases 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!