第3章：データ構造の話、地味だけどめっちゃ大事
第3章：データ構造の話、地味だけどめっちゃ大事
『データ指向アプリケーションデザイン（DDIA）』第3章を読んだメモです
地味に見えて、実は設計の基礎体力に直結する「データ構造」の話を、自分の言葉で整理してみました
データ構造がわからないとDBの話がわからない
DBまわりの話をするときは、データ構造が根底にないと話についていけない
この辺を抑えておくと、業務や案件に適したデータベースを選べるようになってくるはず
WAL（Write Ahead Log）
ログファイルに書き込むのはPostgresみたいなRDBも同じで、WAL（Write Ahead Log）って言われてる
復元するときもWALから、だいたい何かしらWAL使ってるので超重要
WALの“A”は ahead、忘れがちなので2回言う🙄
メモリに収まるかどうか？
「メモリに収まるか？」はめちゃくちゃ重要
キャッシュ設計でもインデックス設計でも、常に意識しておきたい観点
再起動したら消えるとか、そもそも永続化の設計にも関わってくる
SSTableとバイナリサーチの話
SSTable化でソートされると、バイナリサーチのような検索が可能になるので効率的
単純だけど強い構造
全文検索への応用？
請求書検索とかを考えると、全文検索も活用できそう
- 検索対象を単語で分解してキーにする
- UUIDをバリューにしたKVストアを構築するイメージ
実際のキーワード傾向を分析すれば、何をキーにすべきかのヒントが得られそう
ブルームフィルタ
「存在しないことを効率よく判定する」＝ブルームフィルタの出番
設計系の本や様々な記事でもよく紹介されている
検索が増えてくると導入余地が出てくる気がする
Bツリー
- 固定長でページに分ける構造
- カラムが多すぎると1レコードが肥大化して効率が落ちる
- サイズが大きくなりすぎるとテーブルスペースを圧迫してパフォーマンスが落ちる
ほどほどが大事
最適化方法はいろいろあるけど、「早く見つけられるように住所を整理しておく」みたいな話が多い
LSMツリーとの比較
- LSMは書き込み処理が軽い（後でまとめて整理）
- Bツリーは書き込み時に構造を調整するのでコストがかかる
読み込み最適化 vs 書き込み最適化の違いがわかると、用途で選びやすくなる
図3: B‑tree と LSM‑tree の書き込みパス比較
データは適した場所に
「ログでもなんでもDBに突っ込むのはNG」という話
この章の内容と紐づいた話で、適材適所のデータ配置の意識が大事だと感じた
クラスタ化インデックスとヒープファイル
- ヒープファイルは便利だけど、更新のたびにインデックス再計算が発生しがち
- クラスタ化インデックスは高速だけどテーブルサイズがでかくなる
折衷案として、「頻繁にアクセスされるものはクラスタ化」の選択肢もあり
空間充填曲線？
複数の値を1つのインデックスに変換する構造っぽい
まだちゃんと理解してないけど、地理情報系とかで使われるイメージ
インメモリDBとプロトコル変換コスト
インメモリDBはデータ変換オーバーヘッドが少なくて高速
媒体間のプロトコル変換って思ってるより重たい
あと、ネットワークレイテンシは光速が遅いのが悪い(^^)
ETLって何？
よく聞くけど正直よくわかってない単語代表🙄
分析用にデータを整えるプロセスらしい。GCP使ってるならBigQuery前提で設計することもあるかも？
スタースキーマ
小売系の開発で見たことある
外部キーばかりのテーブルから複数のリレーションを組み立ててデータを出してた
この章の話とつながるところがあったな
列ストレージと圧縮
- 列ストレージは更新に弱そう
- select * よりちゃんとカラムを絞ったほうが高速化する
- 圧縮手法もイメージついてると、バグの原因切り分けに役立つことがある
マテリアライズド・ビューは、PostgreSQLの with materialize と似てる
使い方次第でかなり便利
✍️ まとめ
この章は、ちょっと泥臭いけど「なんでそれを使ってるのか」っていう技術の裏を覗けるパートだった
バズワード的に覚えてた用語も、「意味があるから存在してる」ことがわかってくると、設計の選択肢に深みが出る
💡 設計Tips
- 構造を選ぶということは、読み書きのトレードオフを設計するということ
- パフォーマンス問題の裏には、ほぼ確実に“データ構造選びのミスマッチ”がある
- インデックスやログ設計は、アーキテクチャの“足回り”そのもの
Discussion