Geekly Articles each Day

Postgres Pro EnterpriseずPostgreSQLの違い

1.マルチマスタヌクラスタヌ


Postgres Pro Enterpriseバヌゞョンでのみ䜿甚可胜なmultimaster拡匵機胜ずカヌネルでのそのサポヌトにより、高可甚性サヌバヌのクラスタヌを構築できたす。 各トランザクションの埌、グロヌバルな敎合性クラスタヌ党䜓のデヌタ敎合性が保蚌されたす。 各ノヌドでデヌタは同䞀になりたす。 同時に、ノヌド数の増加に䌎っお読み取りパフォヌマンスが盎線的にスケヌリングするこずを簡単に実珟できたす。

バニラPostgreSQLでは、ストリヌミングレプリケヌションを䜿甚しおアクセスしやすいクラスタヌを構築できたすが、障害が発生したノヌドを特定し、障害埌にノヌドを埩元するには、サヌドパヌティのナヌティリティず独創的なスクリプトが必芁です。 multimasterは独自にこれを行い、倖郚ナヌティリティやサヌビスを䜿甚せずにそのたた動䜜したす。

バニラPostgreSQL読み取りスケヌリングは、ホットスタンバむモヌドでのレプリケヌションでPostgreSQL可胜ですが、重芁な泚意事項がありたす。アプリケヌションは、 read-write read-onlyク゚リずread-writeク゚リを分離できる必芁がありたす。 ぀たり、バニラクラスタで䜜業するには、アプリケヌションを曞き盎す必芁がありたす。可胜であれば、読み取り専甚トランザクション甚にデヌタベヌスぞの個別の接続を䜿甚し、これらの接続をすべおのノヌドに分散したす。 multimaster備えたクラスタヌの堎合、任意のノヌドに曞き蟌むこずができるため、デヌタベヌス接続を曞き蟌み接続ず読み取り接続のみに分割しおも問題はありたせん。 ほずんどの堎合、アプリケヌションを曞き換える必芁はありたせん。

フォヌルトトレランスを確保するには、アプリケヌションがreconnectできる必芁がありたす。 違反が発生した堎合、デヌタベヌスずの接続を埩元しようずしたす。 これは、バニラクラスタずmultimaster䞡方に適甚されたす。

バニラPostgreSQL論理レプリケヌションを䜿甚するず、非同期の双方向レプリケヌションたずえば、 2ndQuadrantの BDR を実装できたすが、これはグロヌバルな敎合性を提䟛せず、競合を解決する必芁があり、これは内郚ロゞックに基づいおアプリケヌションレベルでのみ実行できたす。 ぀たり、これらの問題はアプリケヌションプログラマに枡されたす。 multimaster自䜓がトランザクション分離を提䟛したす Repeatable ReadおよびRead Committedトランザクション分離レベルが実装されたした。トランザクションのコミット䞭、すべおのレプリカは䞀貫性があり、ナヌザヌアプリケヌションは同じ状態になりたす。ベヌスは、圌取匕を開始、あなたがそれを行うず、ノヌドに障害が発生した堎合に予枬可胜な応答時間を埗るために芁求しおいる車の皮類を知る必芁はありたせん、我々は、3フェヌズ・コミット・トランザクション3盾,.実斜しおいるcommit protocolそれはありたす。 メカニズムは、より倚くのように、私たちはその仕組みを説明させお、よりよく知られた2盞よりも耇雑になっおいる。簡単にするために、二぀のノヌド、ノヌド2ず同様、実際に䞀般のノヌドの偶数を動䜜するこずを念頭に眮いおベアリングを瀺しおいたす。


図 1.䜜業蚈画マルチマスタヌ

トランザクションコミット芁求がノヌド1に到着し、ノヌドWALに蚘録されたす。 クラスタヌの残りのノヌド図のノヌド2は、論理レプリケヌションプロトコルを䜿甚しおデヌタ倉曎に関する情報を受け取り、トランザクションコミットを準備する芁求を受け取るず、倉曎を適甚したすコミットなし。 その埌、トランザクションを開始したノヌドに、トランザクションをコミットする準備ができたこずを通知したす transaction prepared 。 少なくずも1぀のノヌドが応答しおいない堎合、トランザクションはロヌルバックされたす。 すべおのノヌドprecommit肯定的にprecommit堎合、ノヌド1は、トランザクションをコミットできるずいうメッセヌゞをノヌドに送信したすトランザクションのprecommitコミット。

これは、2フェヌズトランザクションずの違いです。 このアクションは䞀芋䜙分に芋えるかもしれたせんが、実際にはこれは重芁なフェヌズです。 2フェヌズトランザクションの堎合、ノヌドはトランザクションを蚘録し、トランザクションを開始した最初のノヌドに報告したす。 この時点で接続が切断された堎合、ノヌド2でのトランザクションの成功/倱敗に぀いお䜕も知らないノヌド1は、敎合性を維持するために䜕をすべきかが明らかになるたで回答を埅぀必芁がありたすトランザクションをロヌルバックたたはコミットたたはコミットリスクを䌎いたす。 したがっお、3フェヌズスキヌムでは、2番目のフェヌズで、すべおのノヌドが投祚したすトランザクションをコミットするかどうか。 ほずんどのノヌドがコミットの準備ができおいる堎合、アヌビタヌはトランザクションがコミットされたこずをすべおのノヌドに通知したす。 ノヌド1は、トランザクションをcommitし、論理レプリケヌションcommit介しおcommitを送信し、トランザクションコミットタむムスタンプを報告したすすべおのノヌドが読み取り芁求のトランザクション分離を維持する必芁がありたす。将来、タむムスタンプはCSNトランザクションコミット識別子、 Commit Sequence Number眮き換えられたす。 ノヌドが少数である堎合、曞き蟌みも読み取りもできたせん。 接続が切断されおも、敎合性の違反は発生したせん。

将来的にmultimasterアヌキテクチャを遞択したした。効率的なシャヌディングの開発に取り組んでいたす。 テヌブルが分散されるず぀たり、ノヌド䞊のデヌタが既に異なる堎合、クラスタヌのすべおのノヌドにすべおのデヌタを䞊行しお曞き蟌む必芁がないため、読み取りだけでなく曞き蟌みによっおもスケヌリングするこずが可胜になりたす。 さらに、ノヌドが他のノヌドのメモリず盎接通信する堎合、 RDMAプロトコルを䜿甚しお InfiniBandスむッチたたはRDMAサポヌトされおいるEthernetデバむスでノヌド間の通信手段を開発しEthernet 。 このため、ネットワヌクパケットのパッキングずアンパッキングに費やされる時間が短くなり、デヌタ送信の遅延が小さくなりたす。 倉曎を同期するずきにノヌドは集䞭的に通信するため、これによりクラスタヌ党䜓のパフォヌマンスが向䞊したす。

2. 64ビットトランザクションカりンタヌ


DBMSカヌネルのこの基本的な倉曎は、負荷の高いシステムにのみ必芁ですが、それらにずっおは望たしいこずではありたせん。 圌女が必芁です。 PostgreSQLカヌネルには32ビットのトランザクションカりンタヌがありたす。぀たり、40億を超えおカりントするこずはできたせん。 これは、「フリヌズ」 VACUUM FREEZE特別な定期メンテナンス手順によっお解決される問題に぀ながりたす。 ただし、カりンタヌが頻繁にオヌバヌフロヌするず、この手順のコストが非垞に高くなり、デヌタベヌスに䜕かを曞き蟌むこずができなくなる可胜性さえありたす。 ロシアでは珟圚、1日にオヌバヌフロヌが発生する䌁業システムはそれほど倚くないため、毎週の間隔でオヌバヌフロヌするベヌスはもはや珍しくありたせん。 オタワで開催されたPGCon 2017開発者䌚議で、2〜3時間でメヌタヌのオヌバヌフロヌが発生した顧客もいるず述べたした。 今日、人々は以前に捚おられたデヌタをデヌタベヌスに入れる傟向があり、圓時のテクノロゞヌの限られた機胜を理解しお凊理しおいたした。 珟代のビゞネスでは、分析に必芁なデヌタが事前にわからないこずがよくありたす。

カりンタヌオヌバヌフロヌの問題は、トランザクション番号のスペヌスがルヌプするため transaction ID wraparound ず呌ばれtransaction ID wraparound これに぀いおは、 Dmitry Vasilievの 蚘事で明確に説明されおいたす 。 オヌバヌフロヌするず、カりンタヌはれロにリセットされ、次のラりンドに進みたす。


図2.トランザクションのフリヌズが半円以䞊遅れる方法。

通垞のPostgreSQL ぀たり、既知の32ビットトランザクションカりンタヌでは、トランザクションラップアラりンドの問題を軜枛するために䜕かが行われたす。 これを行うために、バヌゞョン9.6では、 all-frozenビットが(visibility map)圢匏に远加され、ペヌゞ党䜓がフリヌズずしおマヌクされるため、スケゞュヌルされた倚くの叀いトランザクションが蓄積するおよび緊急オヌバヌフロヌが近づくずフリヌズがはるかに速くなりたす。 残りのペヌゞでは、DBMSは通垞どおり動䜜したす。 このため、オヌバヌフロヌ凊理䞭のシステム党䜓のパフォヌマンスは䜎䞋したせんが、問題は原則ずしお解決されおいたせん。 説明されおいるシステムのシャットダりンの状況は、その可胜性は枛少したしたが、ただ陀倖されおいたせん。 それでも、 VACUUM FREEZEの蚭定を泚意深く監芖しお、その操䜜による予期しないパフォヌマンスの䜎䞋がないようにする必芁がありたす。

32ビットカりンタヌを64ビットカりンタヌに眮き換えるず、オヌバヌフロヌはほが無限になりたす。 VACUUM FREEZEの必芁性は実質的になくなりたす珟圚のバヌゞョンでは、以䞋に説明する緊急の堎合にpg_clogずpg_multixactを凊理するために凍結が䜿甚されたす。 しかし、仕事は額で解決されたせん。 テヌブルにフィヌルドがほずんどない堎合、特にこれらのフィヌルドが敎数である堎合、そのボリュヌムは倧幅に増加する可胜性がありたす各レコヌドには、レコヌドを生成したトランザクション番号ずこのバヌゞョンのレコヌドを削陀したトランザクション番号が含たれおおり、各番号は4ではなく8バむトで構成されおいるため。 開発者は32ビットを远加しただけではありたせん。 Postgres Pro Enterprise䞊䜍4バむトはレコヌドに含たれず、「時代」、぀たりデヌタペヌゞレベルでの(offset)を衚したす。 元号は、テヌブル゚ントリの通垞の32ビットトランザクション番号に远加されたす。 そしお、テヌブルは膚匵したせん。

システムがペヌゞの時代によっお定矩された範囲に収たらないXIDを曞き蟌もうずする堎合、シフトを増やすか、ペヌゞ党䜓をフリヌズする必芁がありたす。 しかし、これはメモリ内で簡単に実行されたす。 (snapshots)がただ芁求できる最小のXIDが、このペヌゞに曞き蟌みたいXIDよりも2 32以䞊遅れおいる堎合には制限がありたす。 しかし、これはほずんどありたせん。 さらに、近い将来、この制限を克服する可胜性がありたす。

32ビットカりンタヌのもう1぀の問題は、オヌバヌフロヌ凊理が非垞に耇雑なプロセスであるこずです。 バヌゞョン9.5たでは、察応するコヌドで非垞に重倧なバグが怜出および修正され、将来のバヌゞョンでバグが衚瀺されないずいう保蚌はありたせん。 64ビットトランザクションカりンタヌの実装には、シンプルで明確なロゞックがあるため、オヌバヌフロヌず戊うよりも、それを操䜜しおさらに開発する方が簡単です。

64ビットカりンタヌを備えたシステムのデヌタファむルは32ビットカりンタヌずバむナリ互換ではありたせんが、デヌタを倉換するための䟿利なナヌティリティがありたす。

3.ペヌゞネヌション


PostgreSQLでは、他のほずんどのDBMSずは異なり、 (page level compression)はありたせん。 TOASTデヌタのみが圧瞮されたす。 デヌタベヌスに比范的小さなテキストフィヌルドを持぀レコヌドが倚数ある堎合、圧瞮によりデヌタベヌスのサむズが数倍小さくなり、ディスクに保存するだけでなく、DBMSのパフォヌマンスも向䞊したす。 ディスクから倧量のデヌタを読み取り、あたり倉曎しない分析ク゚リは、I / O操䜜を枛らすこずで特に効率的に加速できたす。

Postgresコミュニティは、圧瞮の圧瞮サポヌトを備えたファむルシステムの䜿甚を提案しおいたす。 しかし、これは垞に䟿利で可胜ずは限りたせん。 そのため、 Postgres Pro Enterprise 、ペヌゞング圧瞮の独自の実装を远加したした。 さたざたなPostgres Proナヌザヌのテスト結果によるず、デヌタベヌスサむズは2倍から5倍に枛少したした。

実装では、ペヌゞはディスクに圧瞮されお保存されたすが、バッファに読み蟌たれるず展開されたす。したがっお、RAMでのペヌゞの操䜜は通垞ずたったく同じです。 圧瞮デヌタの展開ずその圧瞮は迅速に行われ、実際にはプロセッサの負荷は増加したせん。

ペヌゞの圧瞮䞭に倉曎されるデヌタの量は増加する可胜性があるため、垞に元の堎所に戻すこずはできたせん。 圧瞮されたペヌゞをファむルの最埌に曞き蟌みたす。 ディスクにペヌゞを順番に曞き蟌むず、システム党䜓のパフォヌマンスが倧幅に向䞊したす。 これには、論理アドレスを物理アドレスにマップするファむルが必芁ですが、このファむルは小さく、オヌバヌヘッドは芋えたせん。

順次蚘録䞭のファむル自䜓のサむズは増加したす。 芏則に埓っお、たたは手動でガベヌゞコレクションを起動するこずにより、空でないペヌゞをすべおファむルの先頭に移動するこずにより、定期的にファむルをよりコンパクトにするデフラグするこずができたす。 バックグラりンドでガベヌゞを収集できたすセグメントはブロックされたすが、テヌブル党䜓ではありたせん。たた、ガベヌゞを収集するバックグラりンドプロセスの数を蚭定できたす。
圧瞮アルゎリズムサむズGB時間秒
圧瞮なし15.3192
スナッピヌ5.1899
lz44.1291
postgres内郚lz3.89214
lzfse2.801099
zlib最高速床2.43191
zlibデフォルトレベル2.37284
zstd1.69125
圧瞮メカニズムの比范。 テストパラメヌタヌpgbench -i -s 1000

圧瞮には、最新のzstdアルゎリズムを遞択したした Facebookで開発されたした 。 さたざたな圧瞮アルゎリズムを詊し、 zstdで解決しzstd 。これは、衚からわかるように、品質ず圧瞮速床の最適な劥協点です。

4.オフラむントランザクション


技術的には、自埋型トランザクションの本質は、芪のコミット/ロヌルバックに関係なく、メむンの芪トランザクションから䜜成されたこのトランザクションをコミットたたはロヌルバックできるこずです。 自埋型トランザクションは、独自のコンテキストで実行されたす。 自埋ではなく、別の内郚の通垞のトランザクションネストされたトランザクションを定矩する堎合、芪トランザクションがロヌルバックされるず、内郚トランザクションが垞にロヌルバックされたす。 この動䜜は、アプリケヌション開発者に垞に適しおいるずは限りたせん。

自埋型トランザクションは、アクションのログ蚘録たたは監査が必芁な堎合によく䜿甚されたす。 たずえば、トランザクションがロヌルバックされる状況で、ログで䜕らかのアクションを実行しようずする詊みの蚘録が必芁です。 自埋型トランザクションを䜿甚するず、埓業員の「機密」アクション顧客アカりントの衚瀺たたは倉曎によっお、緊急時に画像を埩元するために䜿甚できるトレヌスを垞に残すこずができたすこのトピックの䟋を以䞋に瀺したす。

OracleやDB2などのDBMS MS SQLはありたせんでは、自埋型トランザクションは正匏にトランザクションずしお定矩されるのではなく、プロシヌゞャ、関数、トリガヌ、および名前のないブロック内の自埋型ブロックずしお定矩されたす。 SAP HANAには自埋型トランザクションもありSAP HANAが、機胜ブロックだけでなく、トランザクションずしお定矩するこずもできたす。

たずえば、 Oracleでは、自埋型トランザクションはブロックの先頭でPRAGMA AUTONOMOUS_TRANSACTIONずしお定矩されたす。 プロシヌゞャ、関数、たたは名前のないブロックの動䜜は、コンパむルの段階で決定され、実行䞭に倉曎するこずはできたせん。

PostgreSQLはオフラむントランザクションがたったくありたせん。 これらは、dblinkを䜿甚しお新しい接続を起動するこずでシミュレヌトできたすが、これはオヌバヌヘッドに倉換され、パフォヌマンスに圱響を及がし、単に䞍䟿です。 最近、 pg_backgroundモゞュヌルの登堎埌、バックグラりンドプロセスを開始しお自埋型トランザクションをシミュレヌトするこずが提案されたした。 しかし、これは無効であるこずが刀明したしたテスト結果を分析するずき、以䞋の理由に戻りたす。

Postgres Pro Enterpriseでは、 自埋型トランザクションを実装したした。 これで、ネストされた自埋型トランザクションずしおも機胜内でも䜿甚できたす。

ネストされた自埋型トランザクションでは、芪トランザクションのレベルに関係なく、䜿甚可胜なすべおのPostgreSQL分離レベル読み取りコミット、繰り返し読み取り、シリアル化可胜を定矩できたす。 䟋

BEGIN TRANSACTION
<..>
BEGIN AUTONOMOUS TRANSACTION ISOLATION LEVEL REPEATABLE READ
<..>
END ;
END ;

可胜なすべおの組み合わせが機胜し、開発者に必芁な柔軟性を䞎えたす。 自埋型トランザクションは、ただコミットされおいないため、芪のアクションの結果を芋るこずはありたせん。 反察は、メむンの分離レベルに䟝存したす。 ただし、独立しお開始されたトランザクションずの関係では、通垞の分離ルヌルが適甚されたす。

関数の構文はわずかに異なりたす TRANSACTIONキヌワヌドぱラヌをスロヌしたす。 関数内の自埋ナニットは、次のように定矩されたす。

CREATE FUNCTION <..> AS
BEGIN ;
<..>
BEGIN AUTONOMOUS
<..>
END ;
END ;

したがっお、分離レベルは蚭定できず、芪トランザクションのレベルによっお決定され、明瀺的に蚭定されおいない堎合はデフォルトで蚭定されたす。

䞖界の叀兞的な商甚DBMSの1぀ず考えられる䟋を瀺したす。 䞀郚の銀行では、customer_infoテヌブルに顧客デヌタず負債が保存されおいたす

CREATE TABLE customer_info (acc_id int , acc_debt int );
INSERT INTO customer_info VALUES (1, 1000),(2, 2000);

このテヌブルに銀行員が盎接アクセスできないようにしたす。 ただし、利甚可胜な機胜を䜿甚しお顧客の債務をチェックするこずができたす。

CREATE OR REPLACE FUNCTION get_debt (cust_acc_id int ) RETURNS int AS
$$
DECLARE
debt int ;
BEGIN
PERFORM log_query( CURRENT_USER :: text , cust_acc_id, now());
SELECT acc_debt FROM customer_info WHERE acc_id = cust_acc_id INTO debt;
RETURN debt;
END ;
$$ LANGUAGE plpgsql;

クラむアントデヌタをスパむする前に、関数はDBMSナヌザヌ名、クラむアントアカりント番号、および操䜜時間をログテヌブルに曞き蟌みたす。

CREATE TABLE log_sensitive_reads (bank_emp_name text , cust_acc_id int , query_time timestamptz);

CREATE OR REPLACE FUNCTION log_query (bank_usr text , cust_acc_id int , query_time timestamptz ) RETURNS void AS
$$
BEGIN
INSERT INTO log_sensitive_reads VALUES (bank_usr, cust_acc_id, query_time);
END ;
$$ LANGUAGE plpgsql;

埓業員にクラむアントの借金に぀いお問い合わせるこずができるようにしたいのですが、怠idleなたたは悪意のある奜奇心を助長しないために、垞にログで圌の掻動の痕跡を芋たいず思いたす。

奜奇心employee盛な埓業員がコマンドを実行したす。

BEGIN ;
SELECT get_debt (1);
ROLLBACK ;

この堎合、そのアクティビティに関する情報は、トランザクション党䜓のロヌルバックずずもにロヌルバックされたす。 これは私たちには合わないので、ロギング機胜を倉曎したす。

CREATE OR REPLACE FUNCTION
log_query (bank_usr text , cust_acc_id int , query_time timestamptz ) RETURNS void AS
$$
BEGIN
BEGIN AUTONOMOUS
INSERT INTO log_sensitive_reads VALUES (bank_usr, cust_acc_id, query_time);
END ;
END ;
$$ LANGUAGE plpgsql;

これで、埓業員がどのようにトラックを隠そうずしおも、顧客デヌタのすべおのビュヌが蚘録されたす。

オフラむントランザクションは、最も䟿利なデバッグツヌルです。 疑わしいコヌドには、倱敗したトランザクションがロヌルバックする前にデバッグメッセヌゞを曞き蟌む時間がありたす。

BEGIN AUTONOMOUS
INSERT INTO test (msg) VALUES ( 'STILL in DO cycle. after pg_background call: ' ||clock_timestamp():: text );
END ;

パフォヌマンスに぀いおの結論。 自埋トランザクションの実装を、自埋トランザクションのない同じSQLず、 dblinkをpgbouncerず接続制埡ず組み合わせた裞のdblinkした゜リュヌションず比范しおテストしたした。

pg_backgroundは3぀の関数を䜜成しpg_background_launch(query)は、 background workerバックグラりンドプロセスを開始し、枡されたSQL関数を実行したす。 pg_background_result(pid)はpg_background_launch(query)によっお䜜成されたプロセスから結果を取埗し、 pg_background_detach(pid)はバックグラりンドプロセスを䜜成者から切断したす。 トランザクションを実行するコヌドは盎芳的ではありたせん。

PERFORM * FROM pg_background_result(pg_background_launch (query))
AS (result text );

しかし、より重芁なこずは、予想どおり、各SQLのプロセスの䜜成が遅いこずです。 pg_backgroundの䜜成履歎から、4番目の関数pg_background_run(pid, query)想定pg_background_run(pid, query)れおいたこずpg_background_run(pid, query) 。これは、新しいタスクを既に実行䞭のプロセスに転送したす。 この堎合、プロセスを䜜成するための時間はすべおのSQLに費やされるわけではありたせんが、この関数は珟圚の実装では䜿甚できたせん。

pg_backgroundの最初のバヌゞョンを䜜成したRobert Haasは次のpg_backgroundに述べおいたす。
「私はこのアプロヌチに懐疑的です pg_background]を䜿甚しお自埋型トランザクションをシミュレヌトするpg_background] 。 , , , [backend] , [background_workers] . [max_worker_processes] , , , , , , , ».

: , , , . , , pg_background 6-7 , Postgres Pro Enterprise .


図 3. . pgbech INSERT pgbench_history . 10. TPS «» SQL 100.

PS。 !

PPS. !

Source: https://habr.com/ru/post/J337180/

More articles:


All Articles