PostgreSQLのデータベース管理
第II章アーキテクチャ
アウトライン
PostgreSQLは、クライアント/サーバーリレーショナルデータベース管理システム（RDBMS）のための非常に強力な、オープンソースコードです。（そのようなJSONとJSONB型、配列型など）のデータ型は、豊かでカスタムタイプをサポートしています。デフォルトのページ・サイズPostgreSQLのメモリは、8kBのです。
PostgreSQLは、次の主要な機能を備えています。
1つのグッドSQL言語のサポート、サポート ACID 、準整合性、データベーストランザクション、Unicodeの多言語を。
2高同時読み取りと書き込みを設計し、詰まらないでください
3つのサポートするデータベースモデルの種類の数（例えばJSONとJSONB型、配列型など）リレーショナル、文書タイプ、キー/値のタイプ。
2.1 PostgreSQLのプロセス構造
PostgreSQLは、クライアント・ユーザー・プロセス/アプリケーションサーバです。いくつかのプロセスが開始するときにポストマスター（デーモン）、Postgresの（サービスプロセス）のsyslogger、checkpointer、バックグラウンドライタ、walwriterやその他の補助プロセスを含むデータベース開始します。
2.1.1ポストマスター（デーモン）
ポストマスター（デーモン）主な責務は以下のとおりです。
スタート・ストップデータベース1.
2.クライアント接続をリッスン
別々のサーバプロセスのpostgresフォーク各クライアント接続3.
4. Postgresの修理サービス・プロセスのエラー
5.データファイルの管理
ワーカープロセスに関連するデータベースの6管理・運営
2.1.2 Postgresのサービスプロセス
Postgresのサーバプロセス（例えば、JDBCインターフェースを介しPSQL、またはユーザ・アプリケーションのような）クライアントを受け入れ、実行コマンド（対話型SQLクエリ）を送信。これは、基礎となるモジュール各メイン機能モジュール（例えば、保管、管理、トランザクション、インデックス、等）（例えば、コンパイラ、オプティマイザ、アクチュエータなど）、各種のデータベース操作クライアント、および戻り結果を達成するために呼び出します。
2.1.3のsyslogger（システムログ処理）
唯一の上に配置された設定ファイルpostgresql.conf内のログ・パラメータに関連する多くのがありますが、メインプロセスはのsysloggerワーカープロセスパラメータ設定をlogging_collect開始します。
- PostgreSQLのの買収は、状態を実行し、ログファイルに書き込まれたログを実行しています
- 起動パラメータのlogging_collectorは近くに推奨されていません
- LOG_DIRECTORYログディレクトリを設定しました
- LOG_DESTINATIONは、ログ出力、でも書式を設定します
- LOG_FILENAMEは、ログファイル名を設定します
- サイクルの使用を繰り返して、ログを削除するかどうかをlog_truncate_on_rotationをセット
- log_rotation_ageセットサイクルタイム
- log_rotation_sizeログサイクルセットの寸法線
2.1.6補助プロセスチェックポイント：
- データベースの整合性を確保するために、
- それは、アクション、バックグラウンドライタとWALライターをトリガー
- その開始の間隔を制御するために、より多くのパラメータを持っています
2.1.7補助プロセスBackgroupライター（バックグラウンドの書き込み処理）：
PostgreSQLでは、のbgwriterワーカープロセスは、ディスク上のプロセスは、メモリがダーティページを書き込み共有です。場合は、データベースまたは更新データに挿入され、データはすぐにデータファイルに永続化しません。データブロックがある場合、これはデータの汚れをブラシでもない速すぎたり遅すぎ、2つのbgwriterワーカープロセスデータは、定期的にディスクにメモリ内のダーティデータをリフレッシュすることができ、挿入、更新、削除のパフォーマンスを向上させるために主です彼は何度か変更しましたが、あまりにも高速リフレッシュするには、この時間は、その後、これらは1/0倍の増加につながることができ、それをディスクに保存されるたびに、変更されます。新しいクエリまたはストアデータブロックに使用メモリへの更新の必要性は、ディスクから読み取る場合は遅いリフレッシュの場合には、これらのデータ・ブロックを格納するための空き領域がないため、メモリを明け渡すことをする必要がある最初の数クエリや更新を待つ長い必要性につながるディスクに書き込まれたダーティページのメモリでは、自然に制御する設定パラメータの先頭に「_」、バックグラウンドライタを」L-の順でこれらのメカニズムのパフォーマンスが低下
- 共有バッファ内のタスクダーティデータページがディスク・ファイルに書き込まれます
- 利用LRUアルゴリズムダーティ・ページをクリーンアップします
- 仕事を活性化されると、睡眠中に多くの時間を費やします
2.1.8補助プロセスWALライター（ログ先行書き込み）：
WALはWriteAheadLogの頭字語、中国と呼ばれる先行書き込みログです。WALlogもxlogのと呼ばれます。
WalWriterプロセスは、WALログを書き込む処理です。コンセプトは、データを変更する前にログインすると、あなたがディスクに記録されたこれらの変更を加える必要があり、先行書き込みなので、次の更新、実際のデータには、リアルタイムのデータをファイルに永続化する必要はありません。メモリ内のデータの汚い部分が生じ、突然マシンのデータベースのダウンタイムや異常終了が、ファイルにタイムリーに更新されない場合でも、データベースはWALログを読むことによって再開され、WALは、再びそれを再実行の最後の部分のログを記録しますこれは、ダウンタイムの状態に復元することができます。
WALログは、PG_ xlogの中に保管されています。各xlogのデフォルトのファイルは、ディレクトリxlogのWALの複数で発生満たすリカバリ要件、するためには、この性を保証が後にダウンタイムログに記録し、16メガバイトで、非永続データは、WALログによって回収することができ、必要としませんWALログは自動的に上書きされます。
- ディスクファイルへのログ先行書き込み
- トリガーのタイミング：
•WALバッファがいっぱいです
•トランザクションがコミット。
•WAL・ライター・プロセスは、インターバル時間に達します。
とき•チェックポイントが発生します。
2.1.9補助プロセスアーカイバ（アーカイブ）：
- プロセスが唯一のアーカイブモードで有効になっている、アーカイブディレクトリに転送WALログファイル用に入力されます
WALログはWALは時間がカバーされることになる以前のログ、と言うことですつまり、リサイクルされています。アーカイブプロセスはWALによってカバーされるPgArch前にバックアップアウトを記録。WALは8.Xバージョンから開始PostgreSQLは言って人気PITR（ポイントインタイム-Recoery）技術を提供した後、ログインするデータベースにフルバックアップを持っている、技術がアーカイブによってバックアップされる時に、バックアップ時点WALは、ログ、フルバックアップデータベースを生成し、プラスの背後にある、フルバックアップのいずれかにデータベースに推し進め - 時点。
2.1.10ワーカープロセス統計情報コレクタ（統計情報収集プロセス）：
- 収集プロセスの統計情報。タプルスペース情報と情報収集テーブルとインデックス、さらにはアクセス情報テーブル。収集された情報に加えて、外部を使用して最適化することができ、そこautovaccumは、データベース管理者データベース管理にも参考情報として、使用することができ
2.1.11ワーカープロセス自動バキュームランチャ/労働者（自動システム洗浄プロセス）：
- 自動的にクリーンアップガベージコレクションプロセス
- パラメータが時に自動バキュームに設定されている場合、自動クリーンアップ機能を有効にします
- ランチャーを使用すると、1つまたは複数のワーカーを呼び出します時間を起動するたびにクリーンアップするデーモンです
- 労働者は、パラメータautovacuum_max_workersの数によって設定された実際のクリーンアッププロセス、責任があります
PostgreSQLデータベース、テーブルの後にDELETE操作では、古いデータがすぐに削除されません。データの行 - データを更新する場合と、それは古いデータが、新世代の更新を行いません。これは、マルチバージョンと呼ばれる関連するセクションで、「ロック」、目の前に導入されています。この場合、古いデータは、他のトランザクションは、彼らがクリアされ、これらの古いデータを読まない同時場合にのみ、のみ削除状態として識別されます。クリーンアッププロセスは、自動バキュームによって完成されます。
2.2 PostgreSQLのメモリ構造
PostgreSQLのは、発生開始後 - 共有メモリのブロック、共有バッファメモリは、主に読み取りおよび書き込みパフォーマンスを高めるために、データブロックとして使用されます。WALログバッファとCLOGは、（ログをコミット）、共有バッファメモリ内に存在します。加えて、いくつかのグローバル情報は、プロセス情報、ロック情報、グローバル統計情報として、共有メモリに格納されている、というようにされています。
2.2.1共有メモリ
OracleのSGAに相当共有メモリー構造のグループは、すべてのサービスとバックグラウンドプロセスで共有されています。データベース・インスタンスが起動されると、システムメモリは、自動的にグローバル領域が割り当てられています。データベース・インスタンスが、SGAメモリが回復したときには閉じました。SGAは、最大面積の1メモリによって占有するだけでなく、データベースのパフォーマンスに影響を与える重要な要因です。
共有バッファ：
- キャッシュテーブルとインデックス|データブロック
Aは、キャッシュ・ブロックが不要になっている場合は、データは、直接バッファ動作している読んで、それをディスクから読み取ることが必要です
- バッファに変更はなく、汚れたブロックと呼ばれているディスク・ファイル・ブロックに書き込まれていません
- 共有バッファパラメータの大きさを制御します
WAL（ログ先行書き込み）バッファ：
- 先行書き込みトランザクションログのログバッファなど、生成されたキャッシュの追加および削除を書き込み
- WALバッファパラメータのサイズによって制御されます
クロッグバッファ：
-commitログバッファは、事務の状態を記録するログキャッシュです
2.2.2ローカルメモリ
PGAのオラクルと同等
A PGAは、Oracleがデータ及び制御情報を格納するためにそれを使用する独自の方法で処理し、メモリの排他的な領域です。Oracleプロセスが開始すると、PGAは、Oracleデータベースによって作成されました。ユーザー・プロセスがデータベースに接続し、対応するセッションを作成する場合は、Oracleサーバー・プロセスは、このユーザーセッションの内容を保存するためにPGAのユーザーのための特別な領域を設定します。ユーザーセッションが終了すると、システムが自動的にメモリによって占めPGAエリアを解放します。
接続セッションが増加するにつれて、それは例の一部ではない、それぞれの小さなメモリ、 - ローカルメモリは、排他的サーバープロセスメモリ構造であり、各サブプロセスは、postgreが割り当てられています
work_ MEM：ソートするためのメモリ
保守作業のMEM：メモリは、例えば真空ガベージコレクションとして、内部動作や保守作業に使用作成し、インデックスを再構築、などされます
temp_バッファ：データを格納するための一時テーブル
2.3 PostgreSQLのメモリのディレクトリ構造
PostgreSQLの階層
1.論理階層の
データベースクラスタ（インスタンス） - 「データベース- 」スキーマ- 「オブジェクト（表） - >タプルはある
2.物理階層の
表領域- 「ファイル-データベースクラスタ」 - 「ブロック
2.3.1インストールディレクトリ構造
PGHOME =は/ opt / pgsql11.4 PostgreSQLのソフトウェアをインストールするディレクトリです。
2.3.1データのディレクトリ構造
PGDATA一般的な使用環境変数は、データディレクトリのルートを指します。このディレクトリは、インストール時に指定され、インストール時にデータディレクトリのルートとして適切なディレクトリを指定する必要があり、各データベース・インスタンスは、このようなAのディレクトリを持っている必要があります。ディレクトリは完全にinitdbを使用した初期化されます。完了後、このデータのルートが生成されます
3つの構成ファイル。
PostgreSQLのCONF :.メイン設定ファイルデータベースインスタンス、実質的にすべてのファイルの構成パラメータ。
PG_ hba.conf：認証設定ファイル、IPホストがデータベースにアクセスすることができます設定、認証方法は、他にどのような情報です。
PG_ ident.conf：ユーザーマッピングファイル「IDENT」の認証方法。
1つの全体のディレクトリ構造
ベース、グローバル、ログファイル、pg_clog、pg_multixact、pg_notify
、pg_serial、pg_snapshots、pg_stat_tmp、pg_subtrans
、pg_tblspc、pg_twophase、PG_VERSION、pg_xlog内
、postgresql.confの、pg_hba.confの、なpg_ident.conf
2ベースディレクトリ実体ファイルディレクトリ
- すべてのエンティティのデータベースに格納するファイルに使用されるベースディレクトリ。
- サブディレクトリは、OIDデータベースの下に名前が付けられます。
- データベースサブディレクトリの下にファイルという名前のオブジェクトのOIDです。
- バージョン番号の現在のデータ形式に対応するPG VERSIONデータベース。
FSMファイル名FSMを対応するデータファイルの末尾に（フリー
空間マップ）ファイル、ブロックが空のビットマップ同定
レジャー。
- ファイルを終了VmがVM（可視性を、対応するデータファイルであります
）マッピング、マルチバージョン並行処理制御でタプル識別子のヘッドによって行われます
VACUUMによって最終的に削除または更新、および達成するために、「もはや、有効な」
無効なデータをクリーンアップする機能は、空きスペースを取り戻します。
3グローバル共有グローバルディレクトリ
PG_コントロールを■
グローバル制御情報に使用
■PG_ filenode.map
特定のファイル名で、現在のディレクトリシステム・テーブルのOID
各ユーザが作成したためにハードコーディングされたマップ（データベースディレクトリ
）同じファイル名でもあります。
■PG_ internal.init
システム・テーブル・キャッシュ、システムテーブルまでの速度（それぞれを読みます
ユーザーが作成したデータベース・ディレクトリー・ファイル）は、同じ名前を持ちます。
■グローバルファイルシステムテーブル
デジタルファイルコンテンツストレージシステムテーブルの名前が付きました。また、
彼らはに応じて、ゼロにPG_クラスにされているrelfilenode
OIDハードコーディングされたマップとPG_ filenode.mapファイル。
4その他の一般的なディレクトリ
- PG_ WAL、WALログディレクトリは非常に重要です
- PG_ XACT、ログディレクトリをコミットは非常に重要です。ディレクトリのV9バージョン以前PG_詰まり
- PG_ hba.confクライアント認証の設定ファイルは、クライアントの接続プロトコル、暗号化、ACLなどを設定することができます
- テキスト形式のデータベースクラスタpostgresql.conf設定ファイル
- postgresql.auto.conf、また、パラメータ設定ファイルは、ALTERコマンドによって変更されたすべてのコマンドは、バイナリに同じパラメータpostgresql.confファイルの値、ファイルのパラメータを上書きすることを、このファイルに保存されます
- データベース・インスタンスが正常に起動した後postmaster.pid、メインオペレーティングシステムpostmasterプロセスのPID、ファイルが生成されます。
2.3.4表スペース・ディレクトリー
表スペースを作成した後、ルートディレクトリテーブルスペース内の小見出し「カタログ・バージョン」で生成されます
次のような録音、
TABLESPACEのtbs01のLOCATION '/ホーム/ OSDBA / tbs01" を作成します。
また、生成されます - サブディレクトリ名「PG、9.3_ 201306121」を：
osdbatosdba-ノートパソコン：〜秒1秒-1 /ホーム/ OSDBA / tbs01
合計4
drw------ 3 osdba osdba 4096 10月19 14:29 PG_ 9.3_ 201306121
サブディレクトリ名は「* 201 306 121」の「PG 93 201306121」は、「カタログ・バージョン、」カタログ・バージョン」
あなたはPG_制御データのコマンドをチェックアウトすることができます：
osdbadosdba-ラップトップ： - / pgsqlの/ bin5 PG_制御データ
P9_コントロールのバージョン番号：937
カタログのバージョン番号：201306121
データベースのシステム識別子：5925271200006401779
データベースクラスタの状態：生産中
データベース名であるいくつかのサブディレクトリ - 「PG 9.3 _201306121」サブディレクトリでは、とがあるでしょう
OIDは、次の通り：
OSDBA @ OSDBA-ラップトップ： - $ 1秒-1 /ホーム/ OSDBA / tbs01 / PG_ 9.3_ 201306121 /
合計4
drw------ 2 osdba osdba 4096 10月19 14:29 16384
例えば以下のように、上記「16384」サブディレクトリは、「OSDBA」データベースのOIDです。
OIDを選択osdbaf、P9_データベースからdatname。
OID datname
1にtemplate1
12065 template1では
12070件のpostgres
16384 oadba
