組み込み型DBMSとクライアント・サーバー型DBMSの違い
前回の記事では、データベース周辺の用語について調べ、Database・DBMS・SQLの関係を整理しました。(データベースとDBMSの理解)
その中で、これまで「データベース」と呼んでいた、
- SQLite
- DuckDB
- PostgreSQL
- MySQL
などは、厳密にはデータベースを管理・操作するためのDatabase Management System (DBMS)であることを確認しました。 しかし、同じDBMSであるにもかかわらず、実際に使ってみると使い方はかなり異なります。
例えばSQLiteは、Pythonからデータベースファイルを指定すれば比較的簡単に使い始めることができます。 一方、PostgreSQLを使おうとすると、
- PostgreSQLをインストールする
- PostgreSQLのサーバーを起動する
- ホスト名やポート番号を指定する
- ユーザー名やパスワードを設定する
- アプリケーションからサーバーへ接続する
といった作業が登場します。
これまで個人開発では、必要に応じてこれらをなんとなく使い分けてきました。 しかし、よく考えると同じDBMSと呼ばれるシステムにもかかわらず、使い方・機能が大きく異なります。 この違いを理解するために重要なのが、組み込み型DBMSとクライアント・サーバー型DBMSという動作方式の違いです。
本記事では、この2つの違いを整理します。
まずは大まかに整理する
先ほど例に挙げた4つのDBMSは、以下のように分類することができます
DBMS
│
├─ 組み込み型
│ ├─ SQLite
│ └─ DuckDB
│
└─ クライアント・サーバー型
├─ PostgreSQL
└─ MySQL
大きな違いは、DBMSがどこで、どのように動いているのかです。 組み込み型DBMSでは、DBMSがライブラリとしてアプリケーションに組み込まれ、基本的にアプリケーションと同じプロセス内で動作します。 一方、クライアント・サーバー型DBMSでは、DBMSのサーバープロセスがアプリケーションとは別に動作します。アプリケーションはクライアントとして、そのDBMSへ接続してデータを操作します。
組み込み型DBMS
組み込み型DBMSとは何か
SQLiteやDuckDBは、組み込み型DBMSとして利用できます。 「組み込み型」という名前の通り、DBMSが独立したサーバーとして動くのではなく、アプリケーションに組み込まれたライブラリとして、アプリケーションと同じプロセス内で動作します。
例えばPythonからSQLiteを利用する場合を考えてみます。
import sqlite3
con = sqlite3.connect("crypto.db")
Pythonにはsqlite3モジュールが標準ライブラリとして用意されており、これを通してSQLiteを利用できます。
概念的には、次のような構成です。
Python Process
│
├─ Python Application
│
└─ SQLite (DBMS)
│
↓
crypto.db
SQLiteを利用するために、PostgreSQLのような別のDBサーバーを起動しておく必要はありません。
DuckDBも同じように、Pythonからライブラリとして利用できます。
import duckdb
con = duckdb.connect("crypto.duckdb")
この場合も、DuckDBを独立したDBサーバーとして起動し、Pythonからネットワーク経由で接続する構成ではありません。 DuckDBのDBMSとしての処理は、Pythonアプリケーションと同じプロセス内で実行されます。
つまり、組み込み型DBMSの場合、データベースという実態(サーバー)を特に意識せず、アプリケーションの一部として使うことができます。
組み込み型DBMSの特徴
組み込み型DBMSには、一般に次のような特徴があります。
- 別途DBサーバーを起動する必要がない
- 導入や設定が比較的シンプル
- アプリケーションから直接利用できる
- データベースを単一のファイルとして管理できる製品もある
- 個人開発やデスクトップアプリなどにも組み込みやすい
サーバーを別途管理する必要がないため、アプリケーション内で完結する構成を作りやすいのが大きな特徴です。 一方、組み込み型DBMSの多くは、ネットワーク越しに多数のクライアントがDBMSへ直接接続するような使い方を主目的にはしていません。
ただし、組み込み型だから低性能、小規模なデータ専用というわけでもありません。 例えばDuckDBは組み込み型DBMSですが、大規模なデータ分析を重要な用途として設計されています。 また、「組み込み型だから1人しか利用できない」と単純に考えることもできません。 組み込み型DBMSにも、製品ごとに異なる同時実行やアクセス制御の仕組みがあります。
そのため、まずはアプリケーションのプロセス内でDBMSが動作する方式と理解するのが分かりやすいです。
クライアント・サーバー型DBMS
クライアント・サーバー型DBMSとは何か
PostgreSQLやMySQLは、代表的なクライアント・サーバー型DBMSです。 組み込み型との大きな違いは、DBMSがアプリケーションとは独立して動作していることです。
例えばPostgreSQLを利用するWebアプリケーションを考えると、概念的には次のような構成になります。
Python Process
│
└─ Python Application
│
│ 接続
↓
PostgreSQL Process
│
└─ PostgreSQL (DBMS)
│
↓
Database
PostgreSQL側では、データベースを管理するためのサーバープロセスが動作しています。 PythonやWebアプリケーションは、そのサーバーへ接続するクライアントです。 そのためPostgreSQLへ接続するときには、
hostportdatabaseuserpassword
といった情報が登場します。
例えばhostは、接続先のPostgreSQLがどこで動いているのか、
portは、そのコンピュータ上のどの通信窓口へ接続するのかを指定します。
さらに、どのデータベースを利用するのか、誰として接続するのか、といった情報も指定します。
これは、アプリケーションの中でDBMSが直接動く組み込み型とは異なり、別に動いているDBMSへ接続して利用するためです。
「サーバー」は別のコンピュータというわけではない
クライアント・サーバー型という言葉を初めて見ると、
自分のPC
↓ インターネット
クラウド上のサーバー
↓
PostgreSQL
のような構成を想像してしまいがちです。 しかし、ここでいう「サーバー」は、必ずしも別の物理的なコンピュータを意味するわけではありません。 アプリケーションとPostgreSQL Serverをどちらも自分のPC上で動かすこともできます。 重要なのは、アプリケーションとデータベースが別のプロセスとしてそれぞれ独立して動いていることです。
誤解を恐れずに言うと、Windows環境であれば、PowerShellを二つ立ち上げて、一つのウィンドウではアプリケーションを、もう一つのウィンドウではDBMSをそれぞれ起動して接続するイメージです。一方、組み込み型であればPowerShellを一つ立ち上げてアプリケーションを起動することで、その中でDBMSも一緒に起動するイメージになります。
クライアント・サーバー型DBMSの特徴
クライアント・サーバー型DBMSは、独立したDBMSへ複数のクライアントが接続する構成を取りやすいため、
- 複数のアプリケーションやユーザーから利用する
- ネットワーク越しにデータベースへアクセスする
- 複数の処理から同時にデータへアクセスする
- ユーザーや権限を管理する
- クライアントからの接続を管理する
- DBサーバーを独立して運用・監視する
といった用途に適した仕組みを備えています。
複数のWebアプリケーションのプロセスから、同じPostgreSQLへ接続するような構成も可能です。 DBMSがアプリケーションとは独立しているため、データ管理をDBMS側へ集約できます。 ただし、これらの機能すべてが「組み込み型では絶対に実現できない」という意味ではありません。 あくまで、クライアント・サーバー型DBMSが特に得意としている利用形態として理解するのがよいです。
SQLite・DuckDB・PostgreSQL・MySQLを整理する
ここまで登場した4つのDBMSを整理すると、次のようになります。
| DBMS | 基本的な方式 | 独立したDBサーバー | 主な利用イメージ |
|---|---|---|---|
| SQLite | 組み込み型 | 不要 | アプリケーション内のデータ管理 |
| DuckDB | 組み込み型 | 不要 | データ分析 |
| PostgreSQL | クライアント・サーバー型 | 必要 | Webサービス・業務システムなど |
| MySQL | クライアント・サーバー型 | 必要 | Webサービス・業務システムなど |
同じ方式に分類されるDBMSでも、それぞれさらに個別に得意な用途があります。 例えばSQLiteとDuckDBはどちらも組み込み型DBMSですが、設計思想や得意な処理は大きく異なります。 SQLiteはアプリケーションのデータ管理などで広く使われる一方、DuckDBはデータ分析を重要な用途として設計されています。
具体的な用途から使い分けを考える
ここまでの違いを、具体的な利用シーンから考えてみます。
個人用のデスクトップアプリ
例えば、自分のPCだけで動くデスクトップアプリのデータを管理したいとします。
デスクトップアプリ
↓
SQLite
↓
DBファイル
SQLiteであれば、アプリケーションから直接DBMSを利用できます。 別途PostgreSQLなどのサーバーをインストール・起動して管理する必要がないため、アプリケーション内で完結する構成を作りやすくなります。
Webサービス
複数のユーザーが利用するWebサービスを考えてみます。
ユーザー
↓
Webアプリ
↓
PostgreSQL
Webサービスでは、複数のアプリケーションプロセスから同じデータへアクセスしたり、多数の処理を同時に扱ったりする必要が生じることがあります。 このような場合は、独立したDBMSとして動作するPostgreSQLなどを利用する構成が適していることが多くあります。
ローカルで大量データを分析する
自分のPC上で大量のデータを分析したいケースを考えます。
Python
↓
DuckDB
↓
分析データ
DuckDBは組み込み型なので、別途DBサーバーを運用しなくてもPythonなどから利用できます。 それでいてデータ分析を重要な用途として設計されているため、ローカルでの分析にも利用できます。
このように、
デスクトップアプリ → SQLite
Webサービス → PostgreSQL
ローカル分析 → DuckDB
という組み合わせが典型例として考えられます。 ただし、これは絶対的なルールではありません。 実際のDBMS選定では、データ量、読み書きのパターン、同時アクセス、運用方法など、さまざまな条件を考慮して選択します。
まとめ
SQLite、DuckDB、PostgreSQL、MySQLはいずれもDBMSですが、その動作方式は同じではありません。
SQLiteやDuckDBは組み込み型DBMSで、DBMSがアプリケーションのプロセス内で動作します。 一方、PostgreSQLやMySQLはクライアント・サーバー型DBMSで、DBMSがアプリケーションとは独立して動作し、アプリケーションはクライアントとしてDBMSへ接続します。
この違いを理解することで、これまでなんとなく選定していたDBMSを、開発したいものの特徴や利用用途に合わせて正しく選択できるようになります。