$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DB Tree Algorithms
Search
Yunosuke Yamada
October 16, 2022
Programming
0
120
DB Tree Algorithms
Yunosuke Yamada
October 16, 2022
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
Gemini CLIでもセキュアで堅牢な開発をしたい!
yunosukey
1
310
DevOps/MLOpsに学ぶエージェントの可観測性
yunosukey
1
850
Agent Development Kitで作るマルチエージェントアプリケーション(AIAgent勉強会)
yunosukey
4
1.4k
Agent Development Kitで作るマルチエージェントアプリケーション(GCNT2025)
yunosukey
0
41
AIエージェントのオブザーバビリティについて
yunosukey
1
800
OpenTelemetry + LLM = OpenLLMetry!?
yunosukey
2
810
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
370
フロントエンドオブザーバビリティ on Google Cloud
yunosukey
1
310
ChatGPTのアルゴリズム
yunosukey
0
400
Other Decks in Programming
See All in Programming
AIエージェントを活かすPM術 AI駆動開発の現場から
gyuta
0
360
SwiftUIで本格音ゲー実装してみた
hypebeans
0
110
TUIライブラリつくってみた / i-just-make-TUI-library
kazto
1
360
ViewファーストなRailsアプリ開発のたのしさ
sugiwe
0
430
Building AI Agents with TypeScript #TSKaigiHokuriku
izumin5210
6
1.2k
【Streamlit x Snowflake】データ基盤からアプリ開発・AI活用まで、すべてをSnowflake内で実現
ayumu_yamaguchi
1
120
Why Kotlin? 電子カルテを Kotlin で開発する理由 / Why Kotlin? at Henry
agatan
2
6.9k
チームをチームにするEM
hitode909
0
290
リリース時」テストから「デイリー実行」へ!開発マネージャが取り組んだ、レガシー自動テストのモダン化戦略
goataka
0
120
sbt 2
xuwei_k
0
260
AWS CDKの推しポイントN選
akihisaikeda
1
240
Microservices Platforms: When Team Topologies Meets Microservices Patterns
cer
PRO
1
1k
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
40
2.2k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
GitHub's CSS Performance
jonrohan
1032
470k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.6k
A better future with KSS
kneath
240
18k
We Have a Design System, Now What?
morganepeng
54
7.9k
Learning to Love Humans: Emotional Interface Design
aarron
274
41k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
196
69k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
Writing Fast Ruby
sferik
630
62k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Context Engineering - Making Every Token Count
addyosmani
9
490
Transcript
DBとアルゴリズム 2021/09/09 山田悠之介
Web の技術とアルゴリズム アルゴリズムの理論には純粋なパズル的な楽しさがある Web の技術ではプラクティカルな話が中心で理論の話は多くない (そんな事ないよって方の LT をお待ちしています) DB は理論の話が多く面白い
今回は DB にまつわるアルゴリズムのうち、木に関するものを紹介 2
流れ データ構造をいくつか紹介 BST B-tree LSM tree(主題) 時間があれば LSM tree における最適化をいくつか紹介
3
BST(二分探索木) 右部分木のノードは親より大きく、左部分木のノードは親より小さい 多くの言語で Map, Set の実装に使われる 4
BST(二分探索木) バランスしている時、読み込み・書き込み (INSERT, UPDATE, DELETE)がO(log N) 5
BST はディスクと相性が悪い バランシングが頻発する → ディスクの読み書きが増える ノードサイズとページサイズと合っていない 6
B-tree (B+ tree) ディスクに最適化された探索木 多くの RDBMS (MySQL, PostgreSQL など) のストレージエンジン
でインデックスとして用いられている 7
B-tree (B+ tree) ディスク最適化 各ノードの大きさをページサイズに合わせる バランシングも兄弟への分割・兄弟とのマージなので局所的 8
B-tree の向き・不向き 読み込み・書き込みともに だが、 書き込みが多いユースケースではボトルネックになる ミュータブルなので排他制御が必要 O(log N) 9
LSM tree 書き込みに最適化されたデータ構造 Cassandra などの NoSQL, Spanner などの分散 DB で用いられる
書き込みが 、読み込みが 書き込み時はメモリとログに書くだけにして、 重複を読み込み時に解決する ディスク上のコンポーネントはイミュータブルで、 ロックなしで読み書きできる O(1) O(N) 10
LSM tree 小さなメモリ上のコンポーネント (memtable) 大きなディスク上のコンポーネント(複数) からなる 11
LSM tree 全ての書き込みは memtable に適用される 耐久性を保証するためにログファイルが必要となる memtable はサイズが閾値になると,ディスク上に永続化される ディスク上のデータ構造は B-tree
が一般的 12
LSM tree フラッシュ後のテーブルの数を抑えるために定期的にマージする (コンパクション) コンパクションではマージされた結果を新しいファイルに書き出す (イミュータブル) 13
LSM tree の書き込みと読み込み 追加・更新は memtable に新たに key と value を追加するだけ
削除では memtable からデータレコードを削除するだけでは不十分 (ディスク上のコンポーネントが同じキーのデータレコードを 保持している可能性がある) value に特別な削除エントリ(墓石)を割り当てることで対応 読み込みでは複数のコンポーネントにアクセスし、 タイムスタンプを比較して最新の結果を返すようにする → どのコンポーネントにレコードがあるか知りたい 14
Leveled compaction レベル 0 はフラッシュされたテーブルがそのまま入る レベル 1 以降は上のレベルからマージされ、 key の範囲が各レベルで被らないようにすることで探索を最適化する
15
Bloom Filter 各レベルである key がどのテーブルの範囲にあるかはわかるが、 本当にそのテーブルにあるかは分からない Bloom filter という確率的データ構造がよく使われる 16
Bloom Filter 構築時: 要素の key に対して hash 値のビットを全て立てる (ビット配列は共有) 探索時:
hash 値のビットが全て立っていれば要素かもしれない、 そうでなければ要素ではない 17
まとめ B-tree は読み込み・書き込みともに優れたデータ構造 特殊なケースでは書き込みに特化した LSM tree が使われる LSM tree の読み取りを改善する最適化がいろいろある
18
参考資料 Database Internals 19