データベースを比べるときは、データをどのような形で表すかをまず確認します。SQLを使うか、速いか、クラウド上か、といった異なる観点を一つの分類に混ぜないことが大切です。
データベースの種類
| モデル | データの表現 | 理解するポイント |
|---|---|---|
| 階層型 | 親子関係の木構造 | 基本モデルでは子が持つ親は一つ。階層をたどる |
| ネットワーク型 | レコード間のつながり | 複数の親との関係を表現でき、経路をたどる操作が中心 |
| リレーショナル（関係）型 | 行と列からなる関係（表） | キーや結合などで表同士を関連付けて扱う |
| NoSQLの各モデル | キー・バリュー、ドキュメント、ワイドカラム、グラフなど | モデルごとに扱い方・適したアクセスが異なる |
階層型なら常に高速、ネットワーク型なら重複が必ずなくなる、という保証はありません。構造だけでなくアクセス方法や業務の要件で評価します。ネットワーク型の「ネットワーク」はレコードのつながりのことで、ネットワーク越しに利用するすべてのDBを指すわけではありません。
RDBMSとNoSQLの違い
RDBとRDBMS
RDBは関係モデルで表すデータベース、RDBMSはそれを管理するソフトウェアです。多くのRDBMSではSQLによって定義・検索・更新などを行います。表計算ソフトに似た見た目でも、制約、複数利用者の同時実行、トランザクションなどの管理を含む点を押さえます。
代表例にはPostgreSQL、MySQL、Oracle Database、SQL Serverなどがあります。機能や制約の詳細は製品・構成によって異なります。
NoSQLは一つのモデルではない
NoSQLは非関係型のさまざまなモデルをまとめて呼ぶ文脈で使われます。「Not Only SQL」と説明されることもありますが、SQLまたはSQLに似た言語の有無だけで厳密に分類するものではありません。NoSQL製品がトランザクションや整合性を扱えない、という断定も誤りです。
| モデル | 考え方 | 例 |
|---|---|---|
| キー・バリュー | キーから対応する値を取り出す | 設定やセッションなどのキーによる参照 |
| ドキュメント | 項目を含む文書単位で扱う | 構造が異なる商品情報など |
| ワイドカラム | 行キーや列群などを用いて扱う | キーを中心とする大規模な読書きなど |
| グラフ | 頂点と辺で関係を表す | 人や物のつながりをたどる処理 |
MongoDBはドキュメント型、HBaseやCassandraはワイドカラム系の例です。NoSQLのワイドカラムと、分析用RDBなどの列指向ストレージは同じ分類ではありません。
使い分けは要件から判断する
- どんなデータを、どのキーや条件で検索・更新するか。
- 複数のデータを一緒に更新する必要があるか。
- 一貫性、同時実行、可用性、分散構成に何を求めるか。
- データ量、応答時間、運用体制、費用はどうか。
RDBMSは複雑な条件検索や結合、制約を使う設計に適する場面があります。NoSQLは各モデルに合うアクセスや拡張方法に強みを持ちますが、どちらも製品・設計次第です。「NoSQLは常に速い」「RDBは必ず遅い」「NoSQLでは整合性を保てない」といった比較は避けます。
併用するときに確認すること
業務の主データをRDB、検索やキャッシュなどを別の仕組みで扱う構成もあります。その場合は、どちらを正本とするか、変更をどう反映するか、反映の遅延や不一致をどう扱うかを決めます。併用するだけで整合性や運用の問題が解消するわけではありません。
確認問題：NoSQLはSQLを一切使わず、トランザクションもない？
どちらも一律には言えません。製品やモデルによって問い合わせ言語、トランザクションの対応範囲、一貫性の設定などが異なります。
noteで関係データベースの操作を学ぶ
モデルの違いを理解したら、関係データベースの操作はSQL教材で練習できます。リンク先はSQLの学習教材で、すべてのNoSQL製品の操作を扱うものではありません。
コメント