💡
達人に学ぶDB設計６章要約
達人に学ぶDB設計6章を要約してみました
この記事を書いた人
データベースとパフォーマンス
- インデックスは単にデータベースに作成しておくだけでよい
- インデックスを使うかどうかはリレーショナルデータベースが勝手に判断するため、アプリケーション側で制御する必要がなく、透過性が高い
- インデックスの作成、変更がデータの中身に影響を及ぼすことはない
- 頻繁に利用するインデックスはB-treeインデックス。パフォーマンスの平均値が高く、無難に使っても優秀
- B-treeはどのノードに対しても、探索距離が一定である平衡木と言える。それでも長いこと、データの変更を行えば、徐々にバランスは崩れ、非平衡木となっていく
- しかし、性能劣化は長期的に見ても、緩やかであるので持続性が非常に高い
- B-treeは否定条件の検索では全く役に立たない
- リレーショナルデータベースは内部で暗黙的にソートが行う。大量のデータのソートが必要な場合、一時的にディスクデータへ書き出しを行う。B-treeは構築時にキー値をソートして保持する。そのため、I/Oコストが高いソート処理をスキップすることが出来る。
- B-treeインデックスはむやみに使えば良いわけではなく、使い所がある
- データベースのレコード量が少なければ、B-treeを使うよりもフルスキャンの方が処理時間は早い。そのため、B-treeを使うかどうかの閾値が存在する（環境によってケースバイケース）。大雑把にレコード数１万件まではB-treeの効果はない
- B-treeインデックスを作る時は、カーディナリティが高い列を選ぶのが基本
- 目安は特定のキー値を指定したときに、全体のレコード数の5%程度に絞り込めるカーディアンリティがあること。複合列の組み合わせでも良い。値が平均的に分散しているレコードを選ぶ必要がある
- インデックスを使う際には、明示的に条件に使用する値のデータ型を列のデータ型にあわせてやる必要がある
- 主キーおよび一意制約の列には作成不要。DBMSは主キー制約や一意制約を作成する際、内部的にはB-treeインデックスを作成してくれる
- インデックスはデータベースの内部にオブジェクトとして保持される。そのため、作成すればするほど更新性能がさがっていく
- インデックスは性能維持のため定期的に再構築をする
- リレーショナルデータベースが内部的にデータにアクセスしているか解説する
- まず、パーサとよばれるモジュールでSQLの構文が正しい記法かがチェックされる
- 次に、オプティマイザというモジュールにSQL文が送られる。オプティマイザはSQLの頭脳と呼ぶべき役割を担っている。
- さらに、オプティマイザは実行計画を立てる際に、統計情報を必要とするため、統計情報を管理するカタログマネージャに紹介する。
- カタログマネージャから統計情報を受け取ると、オプティマイザはあSQLのデータの中から最適にデータをアクセスする経路を組み立てる。（なので、英語の意味でoptimize=最適が使われている）
- 最後にテーブルのデータにアクセスされる
- 上の何段階もの工程に分けてデータアクセスが行われるのは一見非効率に見えるが、コストの面では一番最適化された方法である
- 統計情報を収集するべきタイミングは、データが大きく更新されたときにおこない、重い処理になるため、システム利用者が少ない夜間の時間に実施するのが原則である
- 統計情報を収集する範囲は大きな更新のあったテーブルが対象である。負荷の高い処理であるため、収集範囲は絞る必要がある。また一時テーブルも考慮する必要がある。
- 例外的なケースで統計情報の収集を全く行わない方が良い場合がある（統計情報を凍結する）。それはサービスの寿命が設計段階でわかる場合で、サービス開始時と終了時のデータ量が変わらない特性を持つサービスのみに適用可能である。
Discussion