Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
B+木入門:PHPで理解する データベースインデックスの仕組み/b-plus-tree-101
Search
Ryo Tomidokoro
March 10, 2024
Technology
5
5.8k
B+木入門:PHPで理解する データベースインデックスの仕組み/b-plus-tree-101
PHPerKaigi 2024 の登壇資料です
Ryo Tomidokoro
March 10, 2024
Tweet
Share
More Decks by Ryo Tomidokoro
See All by Ryo Tomidokoro
開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from
hanhan1978
7
3.1k
Spec Driven Development入門/spec_driven_development_for_learners
hanhan1978
2
1.3k
フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない/php-is-not-bad
hanhan1978
8
13k
どうすると生き残れないのか/how-not-to-survive
hanhan1978
17
14k
100分で本番デプロイ!Laravelで作るWebアプリケーション作成/100min_web_app_cicd
hanhan1978
1
220
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
8
3.3k
集中して作業する技術/how_to_work_deeply
hanhan1978
65
53k
PHPでデータベースを作ってみた/create-data-with-php
hanhan1978
11
11k
ADRを一年運用してみた/adr_after_a_year
hanhan1978
8
4.6k
Other Decks in Technology
See All in Technology
MySQLとPostgreSQLのコレーション / Collation of MySQL and PostgreSQL
tmtms
1
1.2k
事業の財務責任に向き合うリクルートデータプラットフォームのFinOps
recruitengineers
PRO
2
190
20251218_AIを活用した開発生産性向上の全社的な取り組みの進め方について / How to proceed with company-wide initiatives to improve development productivity using AI
yayoi_dd
0
650
なぜ あなたはそんなに re:Invent に行くのか?
miu_crescent
PRO
0
200
ExpoのインダストリーブースでみたAWSが見せる製造業の未来
hamadakoji
0
190
株式会社ビザスク_AI__Engineering_Summit_Tokyo_2025_登壇資料.pdf
eikohashiba
1
110
モダンデータスタックの理想と現実の間で~1.3億人Vポイントデータ基盤の現在地とこれから~
taromatsui_cccmkhd
2
260
ソフトウェアエンジニアとAIエンジニアの役割分担についてのある事例
kworkdev
PRO
0
210
AI との良い付き合い方を僕らは誰も知らない
asei
0
240
AI時代のワークフロー設計〜Durable Functions / Step Functions / Strands Agents を添えて〜
yakumo
3
2.1k
たまに起きる外部サービスの障害に備えたり備えなかったりする話
egmc
0
400
「図面」から「法則」へ 〜メタ視点で読み解く現代のソフトウェアアーキテクチャ〜
scova0731
0
490
Featured
See All Featured
Git: the NoSQL Database
bkeepers
PRO
432
66k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
400
Google's AI Overviews - The New Search
badams
0
870
The Cost Of JavaScript in 2023
addyosmani
55
9.4k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
340
New Earth Scene 8
popppiees
0
1.2k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
508
140k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
47
7.9k
Designing Powerful Visuals for Engaging Learning
tmiket
0
190
Transcript
@hanhan1978 B+木入門:PHPで理解する データベースインデックスの仕組み PHPerKaigi 2024/03/09
@hanhan1978 • 富所 亮 • 所属 株式会社カオナビ CTO室 BackEnd Re-architecturing
Team (BERT) • 職業 バックエンドエンジニア • ブログ https://blog.hanhans.net • Yokohama North AM https://anchor.fm/yokohama-north-am 2
まず基礎的な知識から
B木の木って何?
コンピューターサイエンスにおける 基本的なデータ構造のひとつ https://en.wikipedia.org/wiki/Tree_(data_structure) 由来がわからない程度には基本
データ構造って? 言語によってはありえない質問かも
アルゴリズム + データ構造 プログラム
アルゴリズム + データ構造
アルゴリズム https://ja.wikipedia.org/wiki/アルゴリズム > アルゴリズムとは、解が定まっている「計算可能」問題 に対して、その解を正しく求める手続きをさす。あるいは それを形式的に表現したもの。
ようするにプログラム
アルゴリズム + データ構造
たとえば、PHPの配列 https://www.php.net/manual/ja/language.types.array.php
たとえば、PHPの配列 https://www.php.net/manual/ja/language.types.array.php
たとえば、PHPの配列 https://www.php.net/manual/ja/language.types.array.php 便利すぎる?
私達はもう自然に データ構造を使いこなしていた (過言)
余談 https://www.php.net/manual/ja/function.array-is-list.php 配列がリストかどうかをチェックする(錯乱)
PHPの配列は便利すぎるデータ構造 https://fortee.jp/phperkaigi-2023/proposal/e00788a4-ef25-49ee-b254-9d2b53e19633
PHPの配列は便利すぎるデータ構造2 https://tek.phparch.com/schedule
配列は便利すぎる データ構造としての用途ならSPL推奨
Standard PHP Library https://www.php.net/manual/ja/spl.datastructures.php
データ構造を意識するのはいつ?
• 低レイヤー • 競技プログラミング • 就活(leetcode) • パフォーマンス改善 PHPの仕事ではあんまりデータ構造を意識しないかも
LeetCode https://leetcode.com/
• 低レイヤー • 競技プログラミング • 就活(leetcode) • パフォーマンス改善 PHPの仕事ではあんまりデータ構造を意識しないかも
アルゴリズムだけだと どうしても改善できないことがある
そのため、やりたいことに合わせて データ構造とアルゴリズムを変える
例えば • [データ構造] リスト • [アルゴリズム] ループ PHPの文字列リストから、特定の文字を探す場合
例えば • [データ構造] リスト • [アルゴリズム] ループ PHPの文字列リストから、特定の文字を探す場合 O(N)
例えば • [データ構造] リスト • [アルゴリズム] Binary Search 整列されたデータであった場合
例えば • [データ構造] リスト • [アルゴリズム] Binary Search 整列されたデータであった場合 O(LogN)
計算量のおさらい https://www.techscore.com/blog/2016/08/08/開発新卒に捧ぐ、基本のアルゴリズムと計算量/
計算量 整列されてないデータ 整列されているデータ O(N) 単純ループ O(logN) Binary Search
アルゴリズム単体での限界 この先はデータ構造の助けがいる
例えば PHPでのよくある解決策としては 配列の値をhashのキーに置き換える
例えば • [データ構造] HashMap • [アルゴリズム] キーの存在チェック
例えば • [データ構造] HashMap • [アルゴリズム] キーの存在チェック O(1)
計算量のおさらい https://www.techscore.com/blog/2016/08/08/開発新卒に捧ぐ、基本のアルゴリズムと計算量/
ここまでのまとめ
アルゴリズムだけでは、限界があるの でデータ構造を工夫する必要がある
つまり、データ構造は向いているアル ゴリズムがある
C言語とか書いてた人は そりゃデータ構造いるだろ? 何いってんだ?となる
ここからB木の話
B木 1972年にBayerとMcCreightが発表した 論文 ORGANIZATION AND MAINTENANCE OF LARGE ORDERED INDICES
Boeing Research Labs に所属していた
B木の特徴 データアクセスを最小限にしつつ、データを効率的に保 存するためのデータ構造として生み出された。
B木の特徴 平衡木という特徴がある 二分木の場合 -> 偏った木になる可能性がある
偏った木
偏った木 ルートから3回の値比較が必要
平衡木
平衡木 全体の深さが同じになる
B木は挿入、削除で木の調整を行う
全体として バランスの取れた状態になる
ここでピンと来るかもしれない
B木は挿入、削除で木の調整を行う
データベースのインデックス追加時のコスト 平衡木はデータ追加時に木に調整が必要
5を加えたらどうなる?
これは平衡でない
高さが一定になるように調整される この”調整”がいわゆるコスト
このコストはどれくらいなのか?
5を加えることを考える
1. 挿入箇所を探す ルートからキーを比較して挿入箇所のノードを探す
2. 挿入処理を行う 探した挿入箇所にノードを追加する
3. ノード数が次数に達したら上にマージ 3,4,5で分裂した木をルートに向けてマージする
3. ノード数が次数に達したら上にマージ もし、ここも満杯になったら同じ処理を上に向かって繰り返す
O(logN) で探す + O(logN) でマージ
2 x O(logN) の計算量で インデックスの再構築が行われる
基本的にはデータを挿入するノードに 至るまでの経路上のノードに対して再 帰的に処理を行えば平衡が保たれる
経路外のノードは調整しない そこまで仕様は複雑じゃない
B木の特徴 また、もう一つの大きな特徴として 外部メモリ使用時の有用性
最近はインメモリデータベースなども ありますが、一般的にはデータベース はストレージ(HDD, SSD) にデータを 保存
OSのシステムコールはブロック単位で データの読み書きを行う 通常は4096バイト
必要なデータが1バイトだったとして も4096バイトの読み込み
昔のHDD ぐるぐる回るシリンダー から、データを読み取る ため、ブロック効率が良 くないともったいない! SSDで読み取りが早く なったとはいえ、無駄の ないデータIOはデータ ベースの鍵
B木はノードのサイズを設計可能 例えば 4バイト整数のキーで、ノード のインデックスも4バイトの場合
(4+4) x 2B = 8 x 512 = 4096 バイト
このように外部メモリに対してあらか じめデータ量を計算できる
なんでB木はデータベースインデック スで使われるの?
因果関係が逆
Randomに配置された大量の書類のイ ンデックスを効率的に管理するために 作られたのがB木
実際のB木の動き(デモ)
B+木 B木の特徴を保持しつつ、実用的な機能性を付加 論文 The Ubiquitous B-Tree
データ構造のイメージ
B+木 平衡を保つ基本的な仕組みはB木と同じ ただし、リーフノードにすべてのデータを保持
データ構造のイメージ リーフにすべてのデータが並ぶ
木の高さが変わってもリーフにすべてのデータが並ぶ
B+木の検索 3を探す場合は近傍のノードから到達
リーフがポインターを数珠つなぎにもつため 範囲検索も可能
検索 始点・終点でリーフだけで範囲を取得できる
カバリングインデックス(おまけ) インデックスのデータのみを取得する場合
カバリングインデックス(おまけ) インデックス検索以後の処理が必要ない
本当は実装が完了したリポジトリリンクを バシッと貼りたかったが 未完...orz 口でいうほど全然簡単じゃなかった
まとめ
データベースのインデックスが速いのは インデックスのデータ構造が専用につくら れているから
古典 インデックスサイズの正確な計算を実感するにはやはりC
安定のラムダノート この本には何度も命を救われている