云服务器内容精选

  • RCR UBTree增删改查 Insert操作:Ubtree的插入逻辑基本不变,只需增加索引插入时直接获取事务信息填写xmin字段。 Delete操作:Ubtree额外增加了索引删除流程。索引删除主要步骤与插入相似,获取事务信息填写xmax字段(B-tree索引不维护版本信息,不需要删除操作),同时更新页面上的active_tuple_count。若active_tuple_count被减为0,则尝试页面回收。 Update操作:对于Ustore而言,数据更新对Ubtree索引列的操作也与Astore有所不同。数据更新包含两种情况:索引列和非索引列更新,下图给出了Ubtree在数据发生更新时的处理。 上图展示Ubtree在索引列和非索引列更新的差异: 在非索引列更新的情况下,索引不发生任何变化。index tuple仍指向第一次插入的data tuple,Uheap不会插入新的data tuple,而是修改当下data tuple并将历史数据存入Undo中。 在索引列更新的情况下,Ubtree也会插入新的index tuple,但是会指向同一个data linepointer和同一个data tuple。扫描旧版本的数据则需要从Undo中读取。 Scan操作:用户在读取数据时,可通过使用索引扫描加速,Ubtree支持索引数据的多版本管理及可见性检查,索引层的可见性检查使得索引扫描(Index Scan)及仅索引扫描(IndexOnly Scan)性能有所提升。 对于索引扫描: 若索引列包含所有扫描列(IndexOnly Scan),则通过扫描条件在索引上进行二分查找,找到符合条件元组即可返回数据。 若索引列不包含所有扫描列(Index Scan),则通过扫描条件在索引上进行二分查找,找到符合条件元组的TID,再通过TID到数据表上查找对应的数据元组。如下图所示。 父主题: RCR UBTree
  • RCR UBTree多版本管理 RCR(Row Consistency Read) UBtree的多版本管理是基于数据行的行级多版本管理,将XID记录在了数据行上,会增加Key的大小,索引会有5-20%左右的膨胀。最新版本和历史版本均在btree上,索引没有记录Undo信息。插入或者删除key时按照key + TID的顺序排列,索引列相同的元组按照对应元组的TID作为第二关键字进行排序。会将xmin、xmax追加到key的后面。索引分裂时,多版本信息随着key的迁移而迁移。 父主题: RCR UBTree