devkuma – RDBMS

Database Index (インデックス)

kc@example.com (kc kim) — Sun, 19 Dec 2021 01:05:00 +0900

インデックス(index)とは

テーブルに対する動作速度を高めるデータ構造を指す。
インデックスは、テーブル内の 1 つのカラム、または複数のカラムを使って作成できる。
高速な検索動作だけでなく、レコードアクセスに関連する効率的な並び順付けの基盤も提供する。
インデックスとは、追加の書き込み処理と保存領域を利用して、データベーステーブルの検索速度を向上させるためのデータ構造である。
もし本の中で目的の内容を探すとしたら、本のすべてのページを探すには長い時間がかかる。そのため本の著者は本の先頭または末尾に索引を追加するが、データベースの index は本の索引と同じである。
データベースでも、テーブルのすべてのデータを検索すると時間がかかるため、データとデータの位置を含むデータ構造を作成し、高速に照会できるようにしている。
index を適用していないカラムを照会すると、全体を探索する Full Scan が実行される。Full Scan は全体を比較しながら探索するため速度が低下する。

データベースでデータを検索する 2 つの方法

FTS(Full Table Scan)
- テーブルを最初から最後まで検索する方法である。
Index Scan
- インデックスを検索し、該当データのテーブルへアクセスする方法である。

インデックスのデータ構造

ハッシュテーブル
- カラム値から生成されたハッシュを基にインデックスを実装する。
- 時間計算量が O(1) であるため検索が非常に速い。
- 不等号（<, >）のような連続データに対する順次検索はできない。
B+Tree
- 子ノードが 2 つ以上ある B-Tree を改善したデータ構造である。
- BTree のリーフノードを LinkedList で接続し、順次検索を容易にした。
- ハッシュテーブルより悪い O(log2n) の時間計算量を持つが、ハッシュテーブルより一般的に使用される。

Database Transaction (トランザクション)

kc@example.com (kc kim) — Sun, 19 Dec 2021 01:05:00 +0900

Database Transaction(トランザクション)とは

データベースの状態を変化させるために実行する論理的な作業単位である。
データベースのデータを操作する作業単位（Unit of work）である。
トランザクションでは複数の演算が実行されることがある。
トランザクションは、実行中に 1 つでも作業が失敗するとすべてロールバックされ、すべて成功すると commit を実行する。

Transaction ACID とは

原子性(Atomicity)
- 1 つのトランザクションの作業が、その一部だけ実行されたり中断されたりしないことを保証することをいう。
一貫性(Consistency)
- トランザクションの作業が正常に完了しても、作業前と同じ有効な状態を維持することをいう。
分離性(Isolation)
- Transaction 作業が実行されているとき、他の作業が割り込めないように保証することをいう。
永続性(Durability)
- 正常に実行されたトランザクションについては、永続的（Persistent）に反映されなければならないことをいう。

Transaction を使用する際の注意点

トランザクションの範囲は最小化する。
- トランザクションの範囲を最小化することが重要である。
- データベースのコネクション数は限定的であるため、コネクションを保持する時間を最小化する必要がある。
- そうしないと、他のサービスがそのコネクションを使用するために待機しなければならない状況が発生する。

Transaction isolation level の種類と特徴

READ UNCOMMITTED
- SELECT クエリ実行時に、他のトランザクションで COMMIT されていないデータを読み取ることができる。
- COMMIT されていないデータを読む現象を Dirty read という。
- INSERT だけが行われ、ROLLBACK される可能性のある、つまり COMMIT されていないデータを読むことができるため注意が必要である。
READ COMMITTED
- Read Committed は、COMMIT が完了したデータだけが SELECT 時に見えるレベルを保証するものであり、多くの DBMS では Read Committed がデフォルトに設定される。
- Read Committed では、Read Uncommitted で発生する Dirty read が発生しないことを保証する。
- トランザクションで COMMIT を実行していなくても、DB にはすでに値が反映されている状態であり、COMMIT 前のデータを保証するには、COMMIT されていないクエリを復旧する過程が必要になる。つまり、この時点では Consistent Read を実行する必要があることを意味する。
- Read Committed の問題は、1 つのトランザクション内で SELECT を実行するたびにデータが同一であることを保証しない点である。その理由は、他のトランザクションで該当データが COMMIT された場合、COMMIT されたデータを返すのが Read Committed の特徴だからである。
- このような理由から、Read Committed は Non-repeatable Read とも呼ばれる。
REPEATABLE READ
- Read Committed とは異なり、Repeatable Read は 1 つのトランザクション内で繰り返し SELECT を実行しても、読み取る値が変わらないことを保証する。
- Repeatable Read トランザクションは、最初に SELECT を実行した時刻を記録し、その後はすべての SELECT でその時点を基準に Consistent Read を実行する。
- したがって、トランザクション中に他のトランザクションが COMMIT されても、新しく COMMIT されたデータは見えない。
- その理由は、最初の SELECT 時に生成された SNAPSHOT を読むためである。
SERIALIZABLE
- Serializable は、すべての作業を 1 つのトランザクションで処理するのと同じ、最も高い分離レベルを提供する。
- Read Committed、Repeatable Read の 2 つに共通する問題は、Phantom Read が発生する点である。
  - Phantom Read とは
    - 1 つのトランザクションで UPDATE 命令が失われたり上書きされたりする、つまり UPDATE 後に COMMIT して再度照会したとき、予想とは異なる値が見えたりデータが失われたりした場合を Phantom Read という。
- それとは異なり、SERIALIZABLE では SELECT クエリがすべて SELECT … FOR SHARE に自動で変更され、Repeatable Read では防げないいくつかの状況を防止できる。

Commit と Rollback

Commit
- 1 つのトランザクションが終わったとき、完了したことをトランザクション管理者に知らせる。
Rollback
- 1 つのトランザクション処理が異常終了して DB の一貫性を崩したとき、すべての演算を取り消すことをいう。

Database Normalization (正規化)

kc@example.com (kc kim) — Sun, 19 Dec 2021 01:05:00 +0900

DB 正規化

データ損失や不要な情報の導入なしに、データの一貫性とデータ重複を最小化し、最大限のデータ安定性を確保する安定したデータ構造へ変換するため、1 つのテーブルを 2 つ以上に分離する作業である。

DB 正規化の目的

データ整合性の維持
- データ保存に必要な保存領域を最小化し、データの挿入、更新、削除に伴う異常を除去する。
データ構造の安定性を最大化するためである。

正規化過程

第1正規化
- すべての属性値が原子値を持つように分解する。
第2正規化
- 第1正規形を満たし、主キーではない属性が主キーに完全関数従属するように分解する。
  - ここで完全関数従属とは、主キーの部分集合が他の値を決定しないことを意味する。
第3正規化
- 第2正規形を満たし、主キーではない属性が主キーに直接従属（非推移的従属）するように分解する。
  - ここで推移的従属とは A->B->C が成立することであり、これを A,B と B,C に分解することが第3正規形である。
BCNF 正規化
- 第3正規形を満たし、関数従属性 X->Y が成立するとき、すべての決定子 X が候補キーになるように分解する。

Database Tuning (チューニング)

kc@example.com (kc kim) — Sun, 19 Dec 2021 01:05:00 +0900

DB Optimizer(オプティマイザ)

SQL を最も速く効率的に実行する最適な処理経路を生成する、DBMS 内部の中核エンジンである。

種類
- ルールベースオプティマイザ、コストベースオプティマイザ
過程
- ユーザーが投げたクエリを実行するため、候補となる実行計画を探す。
- オブジェクト統計およびシステム統計情報を通じて、各実行計画の予想コストを算定する。
- 各実行計画を比較し、最も低いコストを持つものを選択する。

ヒント(Hint)

ヒントとは、SQL をチューニングするための指示構文である。
オプティマイザが最適な計画で SQL 文を処理できない場合に、開発者が直接最適な実行計画を提供するものである。
ヒントは SELECT の後に記述でき、INDEX、PARALLEL などさまざまなヒント句がある。

データベースチューニングと方法

DB チューニングは、データベース構造やデータベース自体、オペレーティングシステムなどを調整し、データベースシステムの性能を向上させる作業を意味する。
チューニングは DB 設計チューニング > DBMS チューニング > SQL チューニングの段階で進められる。

1段階: DB 設計チューニング(モデリング観点)

チューニング方法
- データベース設計段階で性能を考慮して設計
- データモデリング、インデックス設計
- データファイル、テーブルスペース設計
- データベース容量算定
チューニング事例
- 非正規化、分散ファイル配置

2段階: DBMS チューニング(環境観点)

チューニング方法
- 性能を考慮してメモリやブロックサイズを指定
- CPU、メモリ I/O に関する観点
チューニング事例
- Buffer サイズ
- Cache サイズ

3段階: SQL チューニング(APP 観点)

チューニング方法
- SQL 作成時に性能を考慮
- Join, Indexing, SQL Execution Plan
チューニング事例
- Hash / Join

Database Lock

kc@example.com (kc kim) — Mon, 11 Jul 2022 09:26:00 +0900

Lock とは

Lock とは、トランザクション間の順序性を保証するための方法である。
ここでトランザクションとは、独立して処理できる最小単位を意味する。
Lock は DBMS ごとに実装方式や方法が異なるため、DBMS ごとの Lock の概念を理解しておく必要がある。

DB ロックとは

DB ロックは、複数のトランザクションが 1 つのデータに同時にアクセスしようとするとき、それを制御するものである。

DB ロックの種類

Lock の種類には共有ロック（Shared Lock）、排他ロック（Exclusive Lock）があり、それぞれ Read Lock、Write Lock とも呼ばれる。

共有ロック(LS, Shared Lock)
- トランザクションが読み取りを行うときに使用するロックであり、データを読むことはできるが書き込むことはできない。
排他ロック(LX, Exclusive Lock)
- トランザクションが読み書きを行うときに使用するロックであり、データを読み書きできる。

排他制御

楽観的ロック

複数の人がほぼ同時にリソースを変更することは少ない、という楽観的な観点から行う排他制御である。

悲観的ロック

複数の人が同じリソースを頻繁に変更するという前提の、悲観的な観点から行う排他制御である。