Relational Database Architecture
Overview
リレーショナルデータベースでのアーキテクチャー情報をまとめたセクション。
DBMSの構造
データベースの中のテーブルは、ベタッと1つの階層に並べられているわけではなく、いくつかのグループに分けて管理されています。
言ってみれば、PCでファイルを分類するために使う「フォルダ（ディレクトリ）」に相当するものが、データベースの中にもある。
時々、すべてのファイルをPCのデスクトップ上に並べている人がいますが、データベースの世界ではそういう乱雑なことをやると、すぐにデータを管理できなくなる。
スキーマ(フォルダに相当する)
フォルダに相当するのが「スキーマ（Schema）」
「枠組み」という意味。
テーブルは、実際には「いくつかのスキーマの中に格納される」という形をとっている。
スキーマも、フォルダのようにユーザが自由に作れるので、用途別に分けたり、見られたくないユーザからはアクセスできないようにセキュリティを制限したスキーマを作ったりといった権限管理も可能。
スキーマの上位にはもう1つの階層として「データベース(Database)」がある。
インスタンス(最上位)
データベースのさらに上位に「インスタンス（Instance）」という概念がある。
これは物理的な概念で、DBMSが動くときの単位。
したがって、OSからは「プロセス」として見えます（Windowsであれば「タスクマネージャ」から確認できます）
実際、DBMSによってはこれを「サーバプロセス」とか単に「サーバ」と呼ぶ場合もある。
OS上では mysqld と見える
インスタンスはメモリやCPUを消費することでOS上に存在する「実態」という意味。
階層構造はDBMSによって違う
3層派と4層派で「どちらが正しいのか」というとこれは4層派。
なぜなら、ANSI（アンシー*6）が定める標準SQLで決められているため。
- 階層の原則を守っているもの
- Postgres
- SQL Server
- DB2
- スキーマとデータベースのどちらかの階層を省略している
- MySQL
- Oracle
MySQLはデータベースとスキーマを「同一」とみなして階層の差を設けていない。
データベースとスキーマはMySQLにおいては同義語。
マルチインスタンスと仮想化
データベースの階層構造において、インスタンスは最上位に位置する概念。
1つのOS内に複数存在させることは原理的には可能で、そのような構成を「マルチインスタンス」と呼ぶ。
インスタンスは、OSから見ればメモリやCPUなどの物理資源を消費するプロセスであるため、複数のインスタンスを存在させられるだけの余力がリソースになければ、マルチインスタンスをやりたくてもできない。
特に、CPUパワーが不足するだけなら処理が遅くなる程度だがメモリが不足した場合は、インスタンスの起動すらできない場合も
※これは、DBMSは一般的に起動時に最低限のメモリ空間を確保しようとするのでメモリ不足で失敗することがある。
マルチインスタンスの構成を採用するケースというのはどのような場合か
最近はこのマルチインスタンスを使うケースはそれほど多くない。
せいぜい、「テスト環境を複数用意したいけど、物理サーバの台数が足りない」という場合ぐらい。
ただ、そうした用途であれば、1つのインスタンス内にデータベースを複数作るか、最近では仮想化環境を使うケースが増えている。