B-Treeのアーキテクチャ解説 (第49回PostgreSQLアンカンファレンス@東京 発表資料)

More Related Content

1.© 2024 NTT DATA Group Corporation© 2024 NTT DATA Group Corporation第49回 PostgreSQLアンカンファレンス@東京B-Treeのアーキテクチャ解説2024年10月12日(土)NTTデータグループ 藤井雅雄
2.© 2024 NTT DATA Group Corporation 2自己紹介藤井 雅雄Database Technical Lead @ NTTデータグループデータベース研究開発PostgreSQL 技術支援PostgreSQLコミッタレプリケーションWAL圧縮バックアップ進捗確認pg_bigm(全文検索モジュール) コミッタfujii_masaoMasaoFujii
3.© 2024 NTT DATA Group Corporation 3謝辞本発表資料は、中村航規さん(*1)がNTTデータグループの業務の一環として作成したものをベースに少し手を入れたものですPostgreSQLのB-Treeのアーキテクチャを調査し、本発表資料を作成していただいた中村航規さんに深く感謝いたします！！(*1)名古屋大学大学院 情報学研究科 知能システム学専攻 修士1年 中村 航規
4.© 2024 NTT DATA Group Corporation 4本講演について講演資料は、後日、NTTデータグループのSlideShareアカウント上で公開予定です。https://www.slideshare.net/nttdata-tech
5.© 2024 NTT DATA Group Corporation 5B-Treeのアーキテクチャについて• データ構造• 検索• 挿入• 削除
6.© 2024 NTT DATA Group Corporation 6B-Treeとは• インデックスのうちの一つ• 最も一般的なインデックス、 CREATE INDEX時USING句での指定がない場合B-Treeが使用される• 一意インデックスとしても使われるCREATE TABLE時にカラムのUNIQUEを宣言CREATE UNIQUE INDEX name ON table (column [, ...]);宣言するとそのカラムについて重複を許さない制約（一意性制約）が追加デフォルトではNULLの重複は許される(はじきたい場合はNULLS NOT DISTINCTを宣言時に追加)• 主キーとなるカラム(or カラムの組)、一意性制約を持つカラムには自動的にB-Treeが生成されて、制約を維持• 対応する演算子は＜、＜＝、＝、＞、＞＝とそれに準じるもの• ある程度データ数が大きくないと性能改善効果なし• インデックス管理のコストやHOT(後述)が使用できないデメリットが上回るためインデックスの使用頻度が低い場合も逆効果• 地理情報であったり、全文検索をよく使用したりする場合や非スカラデータについては他インデックスのが優れる(逆にそれ以外は基本的にB-Treeでよい)
7.© 2024 NTT DATA Group Corporation 7B-Treeのデータ構造メタページルートページインターナルページ インターナルページリーフページ リーフページ リーフページ リーフページヒープ (テーブルデータ領域)• インデックスのページもテーブル(ヒープ)同様にデフォルト8KBのサイズ• 親ページから子ページにリンク。子から親へのリンクはない• 左右ページへ双方向リンク• ヒープ(テーブルデータ領域)にはリーフからのみリンク• メタページという制御用のページが存在し、そこからルートページにリンク• インターナルページは複数階層になる可能性がある階層0階層1階層2B-Treeの階層
8.© 2024 NTT DATA Group Corporation 8B-Treeのデータ構造 – ファイル上の構造メタページインターナルページリーフページルートページリーフページインターナルページリーフページリーフページ・・・先頭末尾インデックスファイル上のイメージ• メタページが常にインデックスファイルの先頭• ルートページの位置は不定
9.© 2024 NTT DATA Group Corporation 9B-Treeのデータ構造 - Fast Rootレコードの挿入や削除を繰り返した結果メタページから１階層ずつ降下するのが非効率になる場合がある(その階層にページが１つしかない場合、そのページは削除されないため階層の数が減ることはない)メタページは子を2つ以上持つページのうち最上層にあるものをFast Rootとしてリンクを持つ探索や挿入操作などでメタページから降下する場合はそのリンクを用いてメタページからFast Rootへ降下するこのリンクを用いて下の階層へ降りるこのページがFast Rootとなるこれらのリンクも保持はされるが使われないページの分割や削除でFast Rootが変更となる場合はFast Rootへのリンクを変更する
10.© 2024 NTT DATA Group Corporation 10B-Treeのデータ構造 – ページ内の構造30 1 10 2030 20 25 2710 1 5 7 20 10 13 17• 親ページにはリンクする子ページの最小キー値が入る• 右端以外の各ページには、1番目のアイテムとして high key が入る• high keyには、右隣ページの最小キー値が入る• high keyにより、そのページのキー値の範囲を知ることができ、検索を高速化できる• ページ内で各キー値は常にソート済。ページ内の探索にはバイナリサーチを使用※実際には１つのページにもっと大量の値が格納される デフォルト8KBインターナルページリーフページ リーフページ リーフページxx high key凡例
11.© 2024 NTT DATA Group Corporation 11検索 メタページインターナルページインターナルページ インターナルページリーフページ リーフページ リーフページ リーフページヒープ (テーブルデータ領域)① メタページから検索開始ルートページ ② Fast Rootへ移動③ インターナルページ内で検索条件のキーを見つけて、そのリンクから子ページに移動※リーフに辿り着くまで繰り返す④ リーフページを右に移動しながら、検索条件のキーを見つけて、そのリンクからヒープにアクセスして、テーブルデータを取得⑤ テーブルデータが削除済の(全Txが見えない)場合は、リーフのそのキーに削除フラグを立てる(以降、削除フラグのあるキーは検索からスキップできる)
12.© 2024 NTT DATA Group Corporation 12検索1 30 8030 1 10 20 80 30 50 70 80 90 9910 1 5 6 20 10 13 15 25 20 21 22id name・・・13 東京15 新潟20 長野・・・リーフページインターナルページルートページB-TreeのIndex Scanでの検索例SELECT * FROM tbl WHERE id = 13ヒープ(テーブルデータ領域)Index Scan：リーフページからヒープへアクセスして該当するテーブルデータを取得
13.© 2024 NTT DATA Group Corporation 13検索1 30 8030 1 10 20 80 30 50 70 80 90 9910 1 5 6 20 10 13 15 25 20 21 22id name・・・6 山形10 群馬13 東京・・・リーフページインターナルページルートページB-TreeのIndexScanでの検索例SELECT * FROM tbl WHERE id >= 6 AND id <= 13ヒープ(テーブルデータ領域)Index Scan：リーフページからヒープへアクセスして該当するテーブルデータを取得
14.© 2024 NTT DATA Group Corporation 14検索Index Only Scan：リーフページにある情報だけで検索を完結して、ヒープへのアクセスなしリーフページにある情報だけで問い合わせに対応できるときはIndex Only Scanが使われる可能性がある1 30 8030 1 10 20 80 30 50 70 80 90 9910 1 5 6 20 10 13 15 25 20 21 22id name・・・・・・インターナルページルートページB-TreeのIndex Only Scanでの検索例SELECT id FROM tbl WHERE id = 13ヒープ(テーブルデータ領域)リーフページ
15.© 2024 NTT DATA Group Corporation 15挿入• 検索と同様に、挿入するキー値でリーフまで辿り、右に移動しながら挿入先のリーフページを見つける• 挿入先のリーフページに空き領域があれば、そこに挿入。その際、ページ内のキー値がソート済になるように適宜キー値を移動• リーフページ内に十分な空き領域がない場合は、不要なキー値を削除して空き領域を確保できないか試し、それでも無理な場合はページをスプリットする1 30 8030 1 10 20 80 30 50 70 80 90 9910 1 5 20 10 15 25 20 2120 10 13 15インターナルページルートページリーフページ• 空き領域に13を挿入• ソート済になるように移動B-Treeの挿入例INSERT INTO tbl VALUES (13, '..');※キー値13の挿入
16.© 2024 NTT DATA Group Corporation 16挿入 – スプリットリーフページに空きがないとき：後述する分割を避ける操作を行う、それでも無理なら分割へ（実際はdeleteされたものが残っているため空きがないことが多い、その場合についてはできるだけ分割を避ける操作で空き領域を作り分割回避）例：13を挿入１ １０10 1 5 10 15 17 19挿入したいが空きのないページを分割
17.© 2024 NTT DATA Group Corporation 17挿入 – スプリット１ １０ １７• 上の階層にも空きがない場合は上の階層についても同様の分割を行っていく• ルートページも空きがなければルートページを分割してインターナルページとし、上の階層に新たなルートページを追加• 同じインデックス値のものはできるだけ同じページに入るように分割親から新しいページへのリンクを追加１ １０１ １０ １７13を挿入
18.© 2024 NTT DATA Group Corporation 18挿入 – スプリット前ページの図では を分割して としている実際の分割後の配分は分割対象ページがその階層の一番右のページかどうかで異なる• 一番右のページでないとき 100％分割後50パーセントずつ埋まっているように分割50% 50%• 一番右のページのとき分割後の左ページがFILLFACTORパーセント埋まるように分割残りは右ページに 100％一番右のページが分割されるとき、timestampなど単純増加する FILLFACTER％ (100-FILLFACTER)%カラムのことが多い分割後右ページに多くのタプルが入ることを想定しているためこのような実装となっている※FILLFACTOR：初期インデックス構築時と一番右ページの分割の時にリーフページにどの割合まで埋めるかを決めるパラメータ デフォルト9010 15 17 19 17 10 15 17 19
19.© 2024 NTT DATA Group Corporation 19スプリットを避ける操作挿入時にページが埋まっていて挿入できないとき、できるだけSplitを操作を避けるため３つの操作が行われる単純削除(Simple deletion)、ボトムアップ削除(Bottom-Up deletion)、重複削除(deduplication)単純削除：削除フラグがついたキー値をすべて削除それに加えて削除フラグがついたものの近くのタプルで削除できるものが見つかれば削除(削除フラグがついたものの近くのタプルを調べる操作は非常に安価)ページの占有ロックを取り、該当のタプルを削除ボトムアップ削除：更新されたものについて古いバージョンのものの削除を目指す（バージョン14以降で実装）重複削除：重複したインデックスタプルを効率の良い表現に変換しサイズを縮小（バージョン13以降で実装）上から順に行い、挿入可能な領域が空けば終了し挿入へこれらの操作後にクイックソートを行い空き領域は詰めて、ソート済みのものが並ぶ
20.© 2024 NTT DATA Group Corporation 20単純削除 (Simple Deletion)20 10 11 13 15 1818 13 43 47 11 10 32 37 15 5福井 東京 熊本 沖縄 埼玉 群馬 島根 香川 新潟 秋田削除済削除済削除済削除済ヒープ(テーブルデータ領域)リーフページページ1 ページ2削除フラグ20 10 11 15単純削除• 削除フラグのあるキー「13」をリーフから削除• 削除フラグのあるキー「13」と同じヒープのページをリンクしているキー「11」「18」について、ヒープ側で削除済のキー「18」をリーフから削除
21.© 2024 NTT DATA Group Corporation 21ボトムアップ削除 (Bottom-up Index Deletion)Tableに対してインデックスが2個以上あり、あるインデックス対象の要素が更新されたものとするそれ以外のインデックスについてボトムアップ削除で削除を目指すインデックスがないカラムの要素が更新されたとき → HOT(Heap Only Tuple)が適用される、インデックスに対する処理なしインデックスがあるカラムの要素が更新されたとき → 削除＋挿入操作として処理(削除処理は前述のように何も行わないので実質は挿入操作のみ行われる)※更新は削除＋挿入として考えることができる・更新されたカラムのインデックス → 単純削除で削除・更新されていないカラムのインデックス → 単純削除で削除されなかった場合、ボトムアップ削除で削除を目指す※単純削除はスキャンなどで該当タプルを参照して“known dead”を示すフラグがつけられるか、“known dead”とされたタプルの近傍タプルで調べられて削除可能と分かった場合しか削除されないつまり、削除可能なタプルがすべて削除されるわけではない
22.© 2024 NTT DATA Group Corporation 22HOT (Heap Only Tuple)インデックスがないカラムの更新の際に更新前レコードから更新後レコードへのポインタを保存しておくことでインデックスの更新なしで更新操作が可能→高速な更新を実現idへのインデックス赤線のポインタを保持しておくことでTableが更新されてもインデックスに対して処理を行わずにレコードへたどることができるHOTの処理がない場合はインデックスについても削除＋挿入の操作が必要Table・・・・・・id = 10, key = 1・・・id = 10, key = 2更新10
23.© 2024 NTT DATA Group Corporation 23ボトムアップ削除 (Bottom-up Index Deletion)かなり複雑な処理をしているかつ資料が少なく、調べきれていないため要点のみをまとめる• キー値が重複しているものについて削除可能かどうかを調べるボトムアップ削除で削除を目指しているのは更新されたが、別インデックスのカラムのみ更新されたものそのため、更新前と更新後はキー値が重複している• すべての削除可能なタプルが削除されるわけではない必要なコストとボトムアップ削除のメリットのバランスがとられており、見合わないと判断されれば途中で打ち切られる• ヒューリスティックな手法“most objects die young”という経験的な観察に基づいている1つ以上削除されるとも限らないそれでもうまく動き、病的なほど大量な更新が起こらない限り不必要なページ分割は起こらない
24.© 2024 NTT DATA Group Corporation 24ボトムアップ削除 (Bottom-up Index Deletion)UPDATE tbl SET id2 = 99 WHERE id1 = 1;UPDATE tbl SET id2 = 44 WHERE id1 = 1;UPDATE tbl SET id2 = 66 WHERE id1 = 1;id1 id21 111 991 441 661 1 1 1 11 44 66 99id1カラムへのB-Treeインデックスのリーフ id2カラムへのB-Treeインデックスのリーフボトムアップ削除では重複して削除済の可能性の高いキーを削除する
25.© 2024 NTT DATA Group Corporation 25重複削除リーフページについて同じキー値をもつエントリをまとめることで効率の良い表現へ例：インデックスの対象カラム:a重複削除なし重複削除ありTablea = 50, b = 15a = 40, b = 50a = 40, b = 1a = 10, b = 40a = 30, b = 20a = 40, b = 5a = 20, b = 6040 40 4040
26.© 2024 NTT DATA Group Corporation 26削除論理的にはB-Treeをたどり値を見つけ、その値を削除すればよいが・・・ 上の層については更新しなくてもよい？例：１０を削除１ ３０ ８０３０ １ １０ ２０ ８０ ３０ ５０ ７０ ８０ ９０ ９９１０ １ ５ ２０ １０ １５ ２５ ２０ ２１２０ １５B-Treeとしては上の層を更新するほうが正確だが、探索能力としては別に変わらない実際も更新していないと思われる
27.© 2024 NTT DATA Group Corporation 27削除実際のPostgreSQL内ではDELETEやUPDATEが起きてもB-Treeに対して即座に変更操作はしないその後のScanなどでヒープを参照して、すべてのトランザクションに対してデッドであるタプルを見つけた場合にそのアイテム“known dead”を示すにフラグを立てる“known dead”のものについてはヒープへの参照をスキップこのタプルについて処理を行うのは挿入時にページが分割されそうになったタイミング単純削除で空き領域を作る（後述）メリット• まとめて削除できるので効率が良い• 空き領域を作る操作が起こるまで占有ロックがいらないため高速に
28.記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。
29.© 2024 NTT DATA Group Corporation 29ページレイアウトインターナルページとリーフページは標準のページフォーマットに準じるソートされた順番で格納されるVACUUMされた場合はその領域が詰められる色付きの部分はhigh keyが入る（階層で一番右のページを除く、この場合は詰める）出典：PostgreSQL 16.4文書
30.© 2024 NTT DATA Group Corporation 30Index Only ScanとIndex Scanの違いリーフページからヒープへのアクセスがあるかどうかが違いIndex Only Scan：リーフページにある情報だけで完結するのでヒープへのアクセスなし(例：インデックス対象のカラムのみSELECTする場合など)Index Scan：リーフページからヒープへアクセスして該当するタプルの情報を取得リーフページにある情報だけで問い合わせに応答できるときはIndex Only Scanが用いられるこの部分のアクセスが必要かどうかの違い
31.© 2024 NTT DATA Group Corporation 31検索Bitmap Index Scan：インデックスから得られた候補行をメモリー上にビットマップ化ビットマップを用いてスキップしながらSeq Scanを行う → I/O操作が少ない※ディスク上のデータはIndexで並んでいるわけではないので、対象行が多いとリーフページからポインタが伸びたレコードをヒープ上で見つけるためのI/O操作が多くなりこちらのが速くなる例：WHERE a >10Tablea = 20a = 1a = 100a = 5a = 40BitMap10101赤の矢印部分でヒープ内のI/O操作発生
32.© 2024 NTT DATA Group Corporation 32よりBitmap Index Scanが強力になるときAND や OR を条件に含む場合、bit演算を組み合わせてより高速に例：WHERE a > 10 AND b > 10 (a, bそれぞれのインデックスを持っている前提)Tablea = 50, b = 15a = 5, b = 50a = 15, b = 1a = 1, b = 40a = 30, b = 20a = 40, b = 5a = 20, b = 60a > 101010111b > 101101101BitmapAnd1000101
33.© 2024 NTT DATA Group Corporation 33検索中のロック検索しているページを読んでいる間に変更されないようにする以外のロックを保持しない(共有ロックのみ保持)下の階層でsplitが起きていてもhigh keyを見ることで分割を検知できる例：WHERE a = 15(インデックスの対象カラム：a)２５ １ １０ ２０１０ １ ５ ６ １４ １０ １１ ２０ １４ １５High keyが20でないので分割されたと判定、右ページを見るというページが分割されてこのようになったとする２０ １０ any any
34.© 2024 NTT DATA Group Corporation 34挿入操作の物理構造ページをたどっていき挿入するページを見つけるそして挿入するページを探索し、挿入位置を決定 （挿入後にソートするわけではない）例：３を挿入• この時_bt_binsrch()の結果をそのまま利用するため、通常は既存の同じキー値の前に挿入される• 分割を避ける操作を行った場合は操作後にクイックソートを行うソート済みのものについて挿入位置を決定する操作が行われる• できるだけ同じインデックスのものは同じページに収まるようにする(分割操作のときも）PageHeaderData ItemID1 ItemID5 ・・・・・・ 5 1 SpecialPageHeaderData ItemID1 ItemID3 ItemID5 ・・・5 3 1 Special・・・
35.© 2024 NTT DATA Group Corporation 35リーフページの要素が空になったらリーフページ内のアイテムが完全に空になったときにページの削除の可能性ただし、一番右のリーフページは削除されない（high keyの処理など探索アルゴリズムの単純化のため)また親ページの一番右のページもそれが唯一の子ページでない限りは削除されない（削除される場合は親ページとともに）１ ３０ ８０３０ １ １０ ２０ ８０ ３０ ５０ ７０ ８０ ９０ ９９１０ １ ５ ２０ ２５ ２０ ２１
36.© 2024 NTT DATA Group Corporation 36リーフページの削除ステップ1：親ページと対象ページをロックし、親ページから対象ページへのリンクを右ページへのリンクに変更３０ １ １０ ２０１０ １ ５ ２０ ２５ ２０ ２１３０ １ １０１０ １ ５ ２０ ２５ ２０ ２１※20からのリンクは使われなくなるため図上では消している
37.© 2024 NTT DATA Group Corporation 37リーフページの削除ステップ２：左兄弟ページ、対象ページ、右兄弟ページの順でロックをとり、左右リンクを更新３０ １ １０１０ １ ５ ２０ ２５ ２０ ２１３０ １ １０１０ １ ５ ２５ ２０ ２１
38.© 2024 NTT DATA Group Corporation 38リーフページの削除親ページの唯一の子ページの場合：親ページごと削除（親ページが祖父母ページの唯一の子ページである場合は祖父母ページもという形で複数子ページをもつページの子ページまで削除）ステップ１：リーフページのみロック、削除しない階層まで再帰的にリンクを切っていくステップ２：「左兄弟ページ、対象ページ、右兄弟ページの順でロックをとり、左右リンクを更新」の操作を上の階層から順にする緑のリーフページを削除するとき赤枠のページが削除されるステップ１の終了 ステップ２の終了