PostgreSQL
PrevNext

Chapter 29. アーキテクチャ

Postgresアーキテクチャの概念

話を続ける前に,まず基本的なPostgres システム・アーキテクチャを理解していた方がよいでしょう. Postgresの各部分が,いかにして相互に 作用しているかを理解しておくと,次の章がかなり読みやすくなる でしょう.データベースの用語集によると,Postgres は「ユーザごとに処理を行う」クライアント・サーバ・ モデルを用いているということになっています.ある Postgresセッションは,以下に示すような,互いに 協調する UNIX プロセス群(プログラム)から構成されています.

単一のpostmasterは,単一のホスト上 において,与えられたデータベースの一群を管理します.そのような データベースの一群のことをインストレーション(installation) とかサイト(site)と呼びます.1つのインストレーション内部において, 与えられたデータベースにアクセスしたいと思うフロントエンド・ アプリケーションは,ライブラリを呼び出します.ライブラリは,ユーザ の要求を,ネットワークを介して,新しいバックエンド・サーバ・プロセス (どのように接続が確立されるか(b)) を開始させるpostmaster (どのように接続が確立されるか(a)) に送ります.

Figure 29-1. どのように接続が確立されるか

そしてフロントエンドのプロセスを新しいサーバ (どのように接続が確立されるか(c)) に接続します.その時点から,フロントエンドのプロセスとバックエンド サーバは,postmasterの介在なしに通信を します。ですから、フロントエンドとバックエンドのプロセスが行ったり 来たりしている間にも,postmasterは常に 走っていて要求を待っています. libpqライブラリは,ひとつのフロントエンドが バックエンドプロセスに対して複数の接続を行うのを可能にしています. しかし、フロントエンドアプリケーションは相変わらずシングルスレッド のプロセスです.マルチスレッドのフロントエンド/バックエンドの接続 は,現在のところlibpqではサポートされていません. このアーキテクチャの1つの実装系では,postmaster とバックエンドは常に同じマシン(データベースサーバ)で 走っていますが,フロントエンドアプリケーションはどこででも走らせる ことができます.このことは心に留めておいてください.なぜなら, クライアントマシンからアクセスできるファイルは,データベースサーバ マシンではアクセスできない (もしくは違うファイル名を用いてアクセス できるだけ)かもしれないからです。 また、postmasterと Postgres のサーバが, PostgresのスーパーユーザのユーザIDで走る ことにも気を付けてください.Postgresの スーパーユーザは,特別なユーザ(例えば "postgres" という名前のユーザ) である必要はないことに注意しましょう.さらに,Postgres のスーパーユーザは,UNIX のスーパーユーザ("root") で あってはなりません !! どのような場合でも,データベースに関連する すべてのファイルは,このPostgresのスーパー ユーザに属していなければなりません。


PrevHomeNext
著作権と商標UpExtending SQL: An Overview