Database

Database とは

データベース (Database) は、大量のデータを整理して保存し、効率よく検索・追加・更新・削除できるようにした仕組みだ。単なるファイルの集まりと違い、データの整合性を保ち、複数の利用者が同時にアクセスしても矛盾が起きないように管理する。ほぼすべての業務システムや Web サービスの根幹を支えている。

主な種類

種類	特徴
リレーショナル (RDB)	表形式でデータを管理、SQL で操作
ドキュメント型	JSON のような柔軟な構造
キーバリュー型	単純な対応関係を高速に処理
グラフ型	要素間のつながりを表現

長らく主流は RDB だが、用途に応じて使い分ける NoSQL と総称される種類も広く使われている。速さの比較は無条件には成り立たない。キーバリュー型が高速なのは、探し方をキー指定に絞り、データを複数のノードへ分けて置きやすくしているからで、複数の表をまたぐ結合や条件を変えながらの集計になると RDB の方が扱いやすい。どの問い合わせを速くしたいかを先に決めてから種類を選ぶ順序になる。

なぜ専用の仕組みが必要か

データをただファイルに保存するだけなら簡単だが、「同時に複数人が書き込んでも壊れない」「途中で電源が落ちても矛盾しない」「大量データから一瞬で目的の 1 件を探す」といった要件を満たすのは難しい。データベース管理システムは、これらを担保する仕組み (トランザクション、インデックスなど) を提供する。

矛盾を防ぐ仕組み

「途中で電源が落ちても矛盾しない」を成り立たせているのがトランザクションだ。複数の更新をひとまとまりとして扱い、全部反映するか 1 つも反映しないかのどちらかにする。この性質を含む 4 つの要件をまとめて ACID と呼ぶ。原子性 (途中状態で終わらせない)、一貫性 (制約を破る状態にしない)、隔離性 (同時に走る他の処理へ中途の値を見せない)、永続性 (確定した変更は障害後も残る) の 4 つである。永続性は、変更内容を先にログへ書いてからデータ本体へ反映する手順で担保する実装が多い。障害後はそのログを読み直して、確定済みの変更を再現できるという理屈だ。

検索の速さを支えるのはインデックスで、列の値を並べ替えた索引を別に持つことで、全行を読まずに目的の行へ到達する。ただし索引は更新のたびに保守が必要になるため、書き込みが多い表に索引を増やしすぎると全体としては遅くなる。

スキーマと正規化

RDB は列の型と制約を先に決め、書き込むときに検証する。ドキュメント型は構造をデータ側が持つため、この検証がアプリケーション側の責任になる。開発初期は後者が身軽だが、時間が経つと「どの形の文書が混在しているか」を誰も把握できなくなりやすい。柔軟さは、形を管理する手間をどこかへ移しただけだと考えたほうがよい。

正規化は、同じ事実をデータベース内の 1 か所にだけ置くように表を分ける作業だ。目的は容量の節約よりも更新時の矛盾の防止にある。顧客の住所を注文の行ごとに複製していると、住所変更のときに一部だけ古い値が残る。逆に、参照ばかりで更新の少ない集計用途では、あえて重複を持たせて結合を減らす (非正規化する) 判断もある。正規化は原則、非正規化は測定した上での例外という順序で扱う。

設計が将来を左右する

データベースの設計 (テーブル構造やデータの持ち方) は、一度運用が始まると変更が難しい。最初の設計が不適切だと、性能問題やデータの不整合が後々まで尾を引く。また、データは事業の資産であり、バックアップ・権限管理・暗号化といった保護を怠ると、消失や漏洩という致命的な事故につながる。地味だが、システムの信頼性を根底で決める領域だ。

変更が難しいという性質は、運用の備え方にも表れる。バックアップは取っているだけでは意味がなく、実際に別の環境へ戻して目的の時点まで復旧できるかを試しておく必要がある。権限も、アプリケーションが使う接続に必要以上の操作を許さない形で分けておくと、不具合や侵入時の被害範囲を狭められる。