WAL転送(メモリ書き込み)まで保証。データ保護とパフォーマンスのバランスが目的。ローカルのWAL書き込みまで保証。パフォーマンス優先が目的。ローカルのWAL書き込みも保証しない。高パフォーマンスだが、非現実的。同期レプリケーションとは、MasterからSlaveへWALファイルを転送した際に、MasterがSlaveへの反映完了を待つレプリケーション方式です。MasterはWALファイルを転送後、Slaveの応答を待ってから次の処理に移ります。処理の流れは以下のようになり、1から順に処理が実行されます。Clientが6OKを受け取るためには、Slaveでの4WAL書き込みの処理が完了し、5応答を受け取る必要があります。このため、Masterでコミットが成功した場合、Slaveにもデータが反映されていることが保証されます。コミットの完了にはSlaveからの応答を待つ必要があるため、単位時間当たりの処理性能は低くなります。非同期レプリケーションは、同期レプリケーションと異なり、MasterがSlaveの反映完了を待たないレプリケーション方式です。MasterはWALファイルをSlaveへ転送した後、すぐに次の処理に移ります。処理の流れは以下のようになり、1から順に処理が実行されます。同期の場合と異なり、Slaveでの5WAL書き込みの処理の前に、Clientには3OKが返されています。このため、MasterとSlaveのデータは必ずしも一致するとは言えません。一方で、コミットの完了にはSlaveからの応答を待つ必要がないため、単位時間の処理性能は高くなります。それぞれの方式の特長をまとめます。本検証を実施するにあたり、各検証サーバには仮想マシン(KVM)を用いました。負荷かけ用のClientマシン1台、レプリケーション元となるMasterマシン1台、レプリケーション先となるSlaveマシン3台、計5台の構成です。ゲストマシンの構成を示します。10.1また、それぞれの仮想マシンは以下の様にネットワークを設定しました。データベース設定¶レプリケーション検証を行うための、PostgreSQLの各種設定を以下に示します。これらはデフォルトから変更した値のみとなります。pg_hba.confの設定¶Master側での認証のために、pg_hba.confの設定を以下の様にします。本検証では、以下の2パターンで性能を比較します。性能影響を同期レプリケーション、非同期レプリケーションそれぞれで明らかにします。検証Bでは、同期・非同期が混在する構成での検証を行います。Slaveの合計台数が3台となるように、以下の4パターンで性能を比較します。データベースの初期設定¶initdbコマンドにてデータベースクラスタを作成します。UTF8先述した通りに、pg_hba.confを編集します。pg_hba.confpostgresql.confを先に述べた設定に編集し、データベースを起動します。検証用のデータベースを作成します。pgbenchの初期化オプションを用いて、スケールファクタ=1000のおおよそ15GBのデータベースを作成します。pgbenchレプリケーション用のユーザを作成します。共通の設定Slaveにて、Masterのデータベースのバックアップ(複製)を取ります。repl_userpostgresql.confを設定し、データベースサーバを起動します。startSlaveのrecovery.confへapplication_nameの記述を追加します。下記ではSlave2を例としています。同期とする場合には、Masterのpostgres.conf内、synchronous_standby_namesを下記のように、適した値に設定する必要があります。下記では一例として、同期台数2台(slave1とslave2)としています。設定後、MasterとSlaveそれぞれのPostgreSQLを再起動します。性能測定には、PostgreSQLに標準で同梱されているpgbenchを使用しました。pgbenchでは、ベンチマーク用のスクリプトをユーザにてカスタマイズすることが可能です。本検証では、以下に示す簡単な更新処理を行うカスタムスクリプトで測定を行いました。:aid;また、キャッシュによる測定値の影響を排除するため、以下の処理の順で測定を行ないました。各マシンのキャッシュクリアpg_prewarmによるデータのロードpgbenchによるTPS値の測定これらを1パターンにつき3回実施し、各パターンの平均値を結果としました。以下にその処理を行ったスクリプトを示します。検証Aでの結果は下記となります。検証Bでの結果は以下となります。同期1台のみは50.4%、非同期2台のみは84.1%のため、単純に掛け合わせると42.4%となるが、上回っている。同期2台のみは43.4%、非同期1台のみは91.8%のため、単純に掛け合わせると39.8%となるが、上回っている。今回の構成では、MasterとSlaveは同じホストマシン上で稼働しており、ネットワークとストレージは物理的には同一のものを使用しています。そのため、Slaveのノード数が多くなるほど、物理的なリソースの競合により性能に影響が出てきたのではないかと考えられます。スケールアウトによるボトルネックが出てきてしまうケースがあると言えます。同期のみの構成の場合は、非同期のみの構成の場合に比べ約1/2の性能値となりました。同期の場合、一つの処理の完了にはMasterとSlave双方の処理の完了を待つ必要があります。一方で非同期の場合は、Masterだけの処理が完了すれば次の処理が開始されます。TPS値が約1/2になったものと考えられます。同期・非同期ともに、サーバ台数を増やすとTPS値が下がっていく傾向が見られました。Slave側の処理を待たない非同期の場合でも、サーバ台数を増やすことでTPS値の低下が見られる結果となりました。複製先が4台以上となっても同じように性能は一定の割合で逓減していくことが考えられます。見たように、同じ台数の構成であっても、同期の台数を増やすほど性能値が低下していく傾向を見ることが出来ました。検証Aと同様、台数を変化させる毎に性能は一定の割合で逓減していくことが考えられます。非同期のみの構成と比較すると、同期を1台でも追加すると性能値が急落するということも確認できました。これは検証Aと同様に、同期ではSlave側の処理を待つ時間が増えるためと考えらえます。同期ではSlave側の処理の完了時にMaster側への応答が返ってくるため、ネットワークの使用量が増加します。そのため、検証Aの場合と同様に、ネットワークのリソース競合により性能が低下することが考えらえます。混在する構成との比較検証を行いました。検証結果から、今回の検証環境下では以下のような傾向を見ることができました。構成では、総台数が同じでも同期の台数を増やすことで性能の低下が見られる。同期・非同期の台数を変化させることで、ある程度一定の割合で性能値も変化している。サイジングの基礎値として利用可能な値が取れたのではないかと考えられます。ネットワークやストレージのリソースを共有していることによるオーバーヘッドが考えられます。考慮する必要があると言えそうです。Wrapper)は近年PostgreSQLが最も力を入れて強化している機能の一つです。この機能を用いることで、点在する様々な外部データをPostgreSQLから一括して管理する事ができるため、企業のデータ活用に非常に有望視されています。性能的なオーバヘッドに対する懸念も存在します。10系のFDW機能に注目して、参照系、更新系における性能オーバヘッドを明らかにします。TABLEによりカスタムに作成したテーブルを組み合わせ使用しています。FDWモジュールにはPostgreSQL9.3より実装されているpostgres_fdwを使用しました。このモジュールを用いることで、外部に存在するPostgreSQLのテーブルを内部に存在するテーブルと同様に扱うことができます。FDWモジュールとしてはPostgreSQLだけでなく、MySQL、OracleDB、CSVファイル、MongoDB等、様々なデータソースへアクセス可能なものが提供されています。詳細は公式wikiに記載されています(https://wiki.postgresql.org/wiki/Foreign_data_wrappers)。本検証では、負荷クライアント(以降「Client」)からデータベースサーバ(以降、「Internal」)のいくつかのテーブルにアクセスします。「Internal」のテーブルに格納されるデータの実体は、「Internal」の中に存在する場合もあるし、FDW機能によって接続された2つの外部データベースサーバ(以降、「External-1」「External-2」)に存在する場合もあります。今回、データベースサーバはすべて仮想環境としています。本検証は、FDW機能を利用する場合と利用しない場合でのオーバヘッドを測定する事が目的であるため、仮想環境である点は性能面で考慮不要と考えました。本検証では、簡単な銀行の口座処理を模擬しています。(pgbench_accounts)、取引履歴(pgbench_history)の3つのテーブルを持っています。KEYであるIDが1対1に紐付く)ことを想定としています。TABLEにより個別なテーブルを作成しました。顧客情報(addrbook)氏名、メールアドレス、性別、年齢などの情報を持つ顧客テーブルを以下の様に作成しました。顧客情報テーブルには、「なんちゃって個人情報(http://kazina.com/dummy/index.html)」を利用して作成した10万件のデータを格納しています。下記にテーブル生成時のコマンドを示します。今回の検証環境においてデフォルトより変更した設定について以下に示します。内部テーブルのみの場合を基準値とした場合において、外部テーブルの変化/増加に伴いどの程度の性能オーバーヘッドが発生するかを検証していきます。以下の方法で測定を行いました。10秒は計測を行わず、10秒経過後に60秒間のスループットを計測します。各パターン3回測定して、中央値を採用します。同時接続数は1、10、20、30、40、50、60、70、80、90、100の11パターン。update」エラーが頻発するため、更新、挿入では、同時接続数1のみ実施しています。検証パターン¶パターン1顧客情報(addrbook)、口座情報(pgbench_accounts)共に内部テーブルである場合。パターン2顧客情報(addrbook)が内部テーブル、口座情報(pgbench_accounts)が外部テーブルである場合。パターン3顧客情報(addrbook)が外部テーブル、口座情報(pgbench_accounts)が内部テーブルである場合。パターン4顧客情報(addrbook)、口座情報(pgbench_accounts)共に外部テーブルである場合。データベースへのアクセス¶ある顧客に対して、顧客情報(addrbook)から氏名(name)、年齢(age)、口座情報(pgbench_account)から残高(abalance)を抽出します。更新対象のテーブル(今回は口座情報である、pgbench_accnounts)が内部データの場合と外部データの場合で測定します。データベースへのアクセス¶ある口座(pgbench_accounts)の残高(abalance)を増加させます。検証パターン¶データの挿入対象のテーブル(今回は取引履歴であるpgbench_history)が内部データの場合と外部データの場合で測定します。取引履歴(pgbench_history)に適当な履歴を挿入します。外部テーブル参照のあり/無しで大きく性能が異なりました。パターン2、3、4にはパターン1を基準とした時の性能(Throughput)劣化率を記載しています。13605.8パターン2296.4▲92.3%2852.0▲81.8%3347.2▲78.5%3379.8▲78.23%3353.4▲78.4%3340.5▲78.2%3350.8▲77.9%3350.1▲77.5%3222.5▲77.8%3269.2▲76.7%3222.8▲76.3%パターン3276.6▲92.9%2916.8▲81.4%3181.6▲79.6%3240.4▲79.2%3253.6▲79.0%3229.8▲79.0%3199.2▲78.9%3222.1▲78.3%3145.7▲78.3%3119.1▲77.7%3108.5▲77.2%パターン4161.7▲95.8%1905.5▲87.8%2204.5▲85.9%2214.0▲85.8%2231.1▲85.6%2184.2▲85.8%2208.6▲85.4%2166.6▲85.4%2125.3▲85.3%2118.9▲84.9%2112.7▲84.5%パターン1:顧客情報(addrbook)、口座情報(pgbench_accounts)共に内部テーブルパターン2:顧客情報(addrbook)が内部テーブル、口座情報(pgbench_accounts)が外部テーブルパターン3:顧客情報(addrbook)が外部テーブル、口座情報(pgbench_accounts)が内部テーブルパターン4:顧客情報(addrbook)、口座情報(pgbench_accounts)共に外部テーブル同時接続数1の場合では、片方が外部テーブルとなるパターン2/パターン3において▲92~93%、両方が外部テーブルとなるパターン4において▲96%の性能(Throughput)劣化となりました。同時接続数10~100において大きく傾向は変わりませんが、パターン2/パターン3において▲76~81%、パターン4において▲84~87%劣化していました。今回の環境で外部テーブルを更新した場合(FDW機能あり)、内部テーブルの更新(FDW機能なし)に比べて、約31%性能(Throughput)が劣化しています。今回の環境で外部テーブルにデータを挿入した場合(FDW機能あり)、内部テーブルへの挿入(FDW機能なし)に比べて、約34%性能(Throughput)が劣化しました。参照においては、測定条件によって異なりますが▲76%~▲91%、更新・挿入においては▲35%前後の性能低下が見られました。個々のアクセスのレスポンス時間を比較すると、同時接続数100の場合、内部テーブルのみで平均14ms、すべて外部テーブルの場合でも平均70msとなっています。今回、非常に単純なアクセスパターンであったため、内部テーブルのみのレスポンス時間が非常に短く、外部テーブルアクセスのオーバヘッドの影響が大きく出る結果となったと想定されます。更新・挿入においてもレスポンス時間は全パターンで10ms前後であり、外部テーブルアクセスによるオーバヘッドの大きさは同様の傾向であると考えられます。来年度以降の測定においては、複数のテーブルの結合など、内部テーブルのみであったとしても時間のかかる処理を対象として測定することで、外部テーブル処理のオーバヘッドをより明らかにできるのではないかと考えます。昨年度にPGEConsのワーキンググループの位置づけを見直してから、性能に加えて新技術の検証も行う「新技術検証ワーキンググループ」として活動しました。つのテーマの検証結果を報告しました。以下では、今年度の検証活動を振り返って、具体的な進め方をご紹介することで、報告書のあとがきとしたいと思います。成果報告会や、オープンソースカンファレンスなどに参加されたお客様に記入いただくアンケートを参考に進めました。例年通りの定点観測を行うことはもちろんのことながら、さらに今年度は定点観測と同様の検証モデルを用いて今までWG1で触れてこなかったWindows版PostgreSQLの性能検証を行うこととなりました。以前から、WindowsでもPostgreSQLサーバを立てるケースが増えるに従い、Windows版PostgreSQLの実際の性能、特にLinux版PostgreSQLと比較した際の性能を知りたいという要望が多くなってきました。今回のWindows版PostgreSQL検証ではLinux版との性能比較に加えてWindows版固有のチューニング要素も検証対象となっており、Windows版PostgreSQL利用者にとって有用な情報を提供できることが期待されます。検証テーマを考慮する上でPostgreSQL最新バージョンの新機能は外せません。バージョンが10となった今回は強化されたパラレルクエリ、ロジカルレプリケーションが検証対象となりました。Wrapperの検証といったテーマは過去に検証しきれなかったテーマを改めて今回選定しています。各テーマごとの検証活動は担当する企業が主体となって進めます。各担当企業が作成した検証計画は、定例の会合で議論しました。提出された検証計画に対して「どのような観点で・何を計測することで、検証の目的が満たされるのか」検討します。その中で不足している観点や冗長な測定パターンが明らかになることもあります。して検証計画が固まると、約2週間から1ヶ月程度、実機上で測定作業をします。得られたデータは整理されて会合に提出されます。「検証の目的に適ったデータが得られているか」確認し、「そのデータの意味するところは何か」考察して、少しでも質の高い結果が得られるように議論を重ねます。した作業を積み重ねることで、単にベンチマークプログラムの測定値に留まらない、有用な結果が得られます。深く係わり、その挙動やソースコードを熟知したメンバが集まって初めて達成できた成果です。会合は、異なる企業に属するメンバが集まって、専門的な意見を交わす貴重な場となっており、メンバの技術力の向上にも寄与しているものと思います。今年度から議論のためにチャットツールを導入したところ、以前よりも圧倒的に意見のやりとりの回数が増えました。これはメンバー間の連帯感向上、ひいては各検証における考察の質向上に寄与しました。活用のご参考になれば幸いです。