🅿️ 🧟 🧔🏼 クラスター佐賀。 Postgresの水平スケーリングについて知りたいことすべて 💆🏿 ⛴️ ⛽️

Oleg Bartunov（@zen）、Alexander Korotkov（@smagen）、Fedor Sigaev

Ilya Kosmodemyansky：これから、PostgreSQLで最も燃えているトピックがあります。私たちがコンサルティングを行ってきた何年もの間、人々が最初に尋ねるのは、「マルチマスターレプリケーションを作成する方法、魔法を実現する方法」です。多くのプロのウィザードが、PostgreSQLでどのようにうまく実装されているかについて話します。PostgresProfessionalの担当者は、このレポートでクラスターに関するすべてを説明します。対応する名前-「佐賀」-は壮大で記念碑的なものです。これで、Postgres Professionalのメンバーがサガを開始し、面白くて良いものになります。

オレグ・バルトゥノフ、アレクサンダー・コロトコフ、ヒョードル・シガエフ。

Oleg Bartunov： Ilya氏は、Postgresがクラスターでどのようにうまく機能しているかについて話しますが、実際には、このトピックでPostgresコミュニティで何が起こっているかについて話します。実際、このトピックはあいまいであり、これを説明しようとしますが、なぜそれほど難しくないのか、どのような見通しが待ち受けていますか。

最初に、自己紹介をしたいと思います-私たち3人は、ロシアのPostgresコミュニティの主要な開発者です。

Postgresで行ったことはすべて、この小さなプレート（スライド上）にリストしようとしました。おそらく私たちの仕事を知っているでしょう。

最初に小さなスケッチを作成し、分散されたものを扱うのがどれほど難しいか、どれほど苦痛かを示すことにしました。最初のスライドは、Distributed Misfortuneと呼ばれます。

Fedor Sigaev：続けます。

原則として、人々がクラスターについて話すとき、これらはこれが何であるかをよく理解している人々であり、それから詳細に深く入ります：「どのようにこれとそれを実装したか、しかし単一のコミットとして、そしてノード間の相互作用がある方法、」または、彼らが来て、クラスターが「複数の手押し車を上下に配置し、すべてが機能し、私たちは幸せになる」と言う人々ですか？

これはそれほど単純ではなく、どのクラスターにもいくつかのソリューションが必要であることをスケッチで示したかったのです。最初に、Ivan PanchenkoとKolya Shaplovに退社をお願いします。それらをサーバーとして指定します。サーバーAとサーバーB。正直なサーバー、つまり正直なデータベース。サーシャにクライアントになるようお願いします。クライアントは、誰が銀行に来てお金を分けたという意味ではなく、銀行の外部のクライアントにサービスを提供する何らかの種類のアプリケーションであるという意味です。これらのお客様を直接心に留めることはありません。実際、クライアントはアプリケーションです。

ここで、アプリケーションはトランザクションを開始し、beginコマンドでそれを配布します。その後、仲間のクライアントがデータベースを離れ、握手し、抽象的な方法で何かをする必要があると言います。「ここで何かを変更し、ここに挿入し、ここで削除します。何でも構いません。」

さて、誰もが言いたいように、2フェーズコミットは問題を解決します。クライアントは、準備コマンドを提供します。データベースは実際に何をしますか？すべてのトリガーを実行し、制約などをチェックします。その後、これらのコマンドが成功した場合、データベースはコミットが常に成功することを約束します。何が起こっても、電力が失われても。

ここで、クライアントは1つのコミットを発行し、1つのデータベースに移動します。バニャはコミットしました。しかし、2番目のサーシャが行くと、ライトがオフになり、全員が3つになります。落ちた。彼らは明かりをつけた。彼らは上昇しますが、コミットは来ませんでした。クライアントは一般的に夢でも精神でもありません。すべてがうまくいったからです。 Vania Panchenkoにちなんで名付けられたデータベースは、彼女のWALログを読み、彼女がコミットしたことについて読み、彼女は幸せな状態にあります-私はすべてをしました。サーバーBのKolyaによって提示されたデータベースは、WALログを読み取り、「コミットの準備ができている」と書かれている内容を見つけて、「コミットがありませんでした」という質問でハングします。彼女は何をすべきですか？そして彼女はどこにも行くことができません。クライアントもこれについて何も知りません、Vanya-彼は彼自身のコミットを持っています。質問：この状況から抜け出すにはどうすればいいですか？

1つのデータベースがすべてを正常にコミットし、2番目のデータベースが問題でハングします。多くの出口はありません。 DBAまたは他の誰か、たとえばシステム管理者に電話します。彼はログから何が起こったのか、あるデータベースで何がコミットされたのかを理解しようとしますが、別のデータベースではそうではありません。現時点では、お金を失うことを恐れていない場合、クラスターは一貫性のないデータで動作するか、サービスを完全に停止します。たとえば、技術的な作業を行っている場合、誰に何を負っているのかがわかります。

または、仲裁人を紹介します。クライアントは、データベースではなくアービターに移動します。タスクを分散し、ログに自分自身に「コミットの準備ができている」状態、または「完了」したことを書き込むのはアービターです。その後、コミットを配布し、最初のベースがコミットを書き込んだものをログに書き込み、2番目がコミットを書き込みます。次に、私たちは目を覚まし、ログを読んで不幸なコリヤは言う：「あなたが見つけたものをコミットする」。

ここでの問題は、このレフリーをゼロから書くことも非常に難しいタスクだということです。それでも、データベースへのコミットを言った瞬間はありますが、ログに自分で書き込むことができませんでした。これが問題の一つです。信頼性を高めたい、または信頼できるように思われるクラスターソリューションが直面する多くの問題の1つです。

次のシーンでは、2つの口座を持つ銀行を想像してください。各口座に1,000枚のクレジットカードがあります。 Vanyaには1つのアカウントがあり、Kolyaには1つのアカウントがあります。クライアント1（サーシャ）が請求額をインタビューします。彼は何を見ていますか？彼は合計1000枚のクレジットカード、1000枚のクレジットカード、2000枚のクレジットカードを見ています。その後、サーシャはトランザクションを開始します-彼は1つのベースに2つの「+500クレジットカード」、「-500クレジットカード」を与えます。そして、彼は尋ねます：「あなたは全部で何を持っていますか？」。つまり、Vanyaから1500枚、Kolyaから500枚のクレジットカードが引き出されたという結果が出ています。500枚あります。すべてが順調です。クライアント1には再び2000が表示されます。

その後、サーシャはこのビジネスをコミットし始めます。彼はKolyaとのコミットを開始します。この時点で、クライアントNo. 2が目を覚まし（聴衆からの少女）、「しかし、あなたがどれだけのお金を持っているかを見せてください」という質問を思いつきます。 Vanyaのトランザクションはまだコミットされていませんが、最初のクライアントは何を見ますか？彼は1000を見ています。しかし、コリヤはすでにコミットしています-彼はすでに500を持っています。不幸な2番目のクライアントは結果として何を見ますか？そのお金はどこかになくなっています。彼は合計1,500人を見ています！

これらは不整合の問題です。2つの異なるデータベースに同時にコミットすることはできません。つまり何とかしてこれと戦う必要があります。 Lokiは、データベースの外部で公開、またはデータベースへのアクセスを拒否します。ここで、直面している段階的な不幸、あなたが遭遇するかもしれない問題。

Oleg Bartunov：この見解からの結論は、2フェーズコミットでは全体的な読み取りができないということです。読書でさえ全体的ではありません。

Fedor Sigaev：ここでは、2フェーズコミットを実際に引き付けることすらしませんでした。 2フェーズコミットは状況を複雑にしますが、実際には、1つのベースがすでにコミットを受け入れ、もう1つのベースが受け入れていない「ホール」を残します。したがって、2つのベースの状態に一貫性がないときは、常にその瞬間があります。

Oleg Bartunov：すべてがそれほど単純ではないことを示した後、いくつかの政治ゲームに移ります。

なぜ政治ゲームなのか？これは条件付きの名前です。 Postgresはコミュニティによって開発されており、コミュニティには一種の民主主義があります。1つのソリューションを実現するには、あらゆる種類のジェスチャーや会話などを多数適用する必要があります。これらすべてを政治ゲームと呼びます。

最近まで、これについてはまったく考えていませんでした。そして、文字通り約2〜3年前、そのような状況はオープンソースで発生しました。オープンソースが支配的なソフトウェア開発モデルになりつつあります。このグラフでは、グローバルな傾向を見ることができます：

オープンソースデータベースが成長しており、専有データベースが減少していることがわかります。

単なるソリューションモデル。ここでは、GartnerのMagic Quadrantが示しています。左側が昨年、右側が今年です。

EnterpriseDBと富士通に直面したPostgresは、すでにデータベースのリーダーになっていることがわかります。 2014年に初めてオープンソースデータベースがデータベースリーダーのリストに追加されたことは、かなり注目に値するイベントです。つまり市場は過熱しています。

2018年には、データベースの70％がオープンソースになることがわかります。この予測は、あなたはそれを信じることができますが、信じることはできませんが、今では人々はますますデータベースを使いたがっている傾向があります。そして、オープンソースデータベースのリーダーはPostgresです。また、MySQLもあります。これも非常に優れたデータベースですが、Postgresは本格的なデータベースであり、現在非常に優れています。そして、これは私たちのコミュニティで感じられます。なぜなら、私たちが訪れるすべてのクライアントが質問を始め、Postgresからいくつかの機能を求め始めるからです。

このスライドをEnterpriseDBプレゼンテーションから抜粋しました。これはPostgres開発の段階を示しています。彼らは次のように述べました：今はエンタープライズの段階です。そこに書かれている機能、つまりエンタープライズと呼ばれる機能に注意してください。すべては問題ありませんが、「クラスタ」という単語は表示されません。つまり本当にそうです。コミュニティでは、クラスターソリューションが必要であるという意見はまだありません。

Todo（特別にスクリーンショットを作成しました）を見ると、そこにクラスターがありますが、これは同じクラスターではありません。これはクラスタコマンドです。つまり Todoでさえ、水平クラスターなどを行うために必要なことについての言葉はありません。

これは偶然ではありませんでした。一方では、コミュニティは保守的であり、他方では、市場はまだ私たちをサポートしていません。

現在、特にロシアでは、Postgresは非常に大規模なプロジェクトの候補と見なされており、クラスターの概念は必須になっています。

Postgres forkページをご覧ください。フォークの数を確認します。それだけではありません。

赤い丸で、クラスターがフィーチャであるフォークをマークしました。 Postgresから表示されるほとんどすべてのフォークは、クラスターが欠落しているためにのみ表示されていることがわかります。そして最終的に、コミュニティはクラスターが本当にTodoにあるべきだと考え始め、何かをするべきだと考え始めました。

これは初めてのことではありません。古いユーザーであるPostgresの古いユーザーは、レプリケーションについて話したことを覚えています。かつてPostgresにはレプリケーションがなく、カーネルではレプリケーションが不要であると言われていました。レプリケーションはサードパーティ製品でなければなりません。そして、再び、ユーザーは、コミュニティが突然コアにあるべきだと気づきました。そして、私たちはそれを手に入れ、今ではレプリケーションは誰もが使用する良い通常のツールです。また、Windowsのポートに関するストーリーもありました。どのくらいの電力が必要か、どのくらいの電力が必要か、Windowsのポートをキックオフしましたが、最終的にはそれを行いました。

ヒョードル・シガエフ：しかし、私たちはキックオフしました。

オレグ・バルトゥノフ：その結果、今では非常に革命的な状況になりました。下層階級が望んでいますが、上層階級は決定していません。さらに、興味深い状況-私たちは会社を組織し、顧客と話し、「クラスターを作る」と言います。 2ndQuadrantは同じことを言っています：「クラスターを作成します」。 EnterpriseDBは、「私たちもクラスターを作っています」と言います。しかし、すべての慣習は、「ロードマップには興味がなく、ロードマップコミュニティに興味があります」と言います。このクラスターがコミュニティーに必要であり、コミュニティーが機能する必要があります。

スライド上で、私は手短に決定を下したとサーシャは語る。

アレクサンダー・コロトコフ：

おそらく多くの人がPostgres XC XLがあると聞いています。 XL-Postgres XCのフォークでした。 XCはX2に移行しました。これはシャーディングとレプリケートされたテーブルを実装する別個のフォークであり、GTM-Global Transaction Managerと呼ばれる別個のサービスを通じてグローバルな一貫性を実現します。 2ndQuadrant、MTT、Huaweiによって開発されています。さらに、Huaweiには独自のフォークMPPDBがあり、XCのフォークです。

オレグ・バルトゥノフ：私は、これらがすでにライブユーザーを持っているデータベース、つまり中国の多くの銀行がこれらのXCを使用しています。

アレクサンダー・コロトコフ：一貫性のあるバグがあったという事実にもかかわらず、中国は非常に勇敢で、これに関して銀行を立ち上げる準備ができています。

pg_shardがあります-これは、基本的なシャーディング機能を提供するオープンソースのPostgres拡張機能です。繰り返しますが、トランザクションマネージャはなく、分散一貫性はありませんが、一部のWebタスクに使用できます。
Citus DBがあります-これはまだCitus Dataが間もなくオープンすることを約束する独自のデータベースです。より豊富な機能があります。より複雑なクエリ。そこで、ある種のラボを編成できますが、OLTPの場合、分散一貫性は保証されません。
FDWは、EnterpriseDBがPostgresに対して実行しようとしているアプローチです。メインマスターブランチに追加します。アイデアは、既存の外部データラッパーメカニズムを使用することです。シャーディングを行うために、外部データソースにアピールします。 B 9.6。 Postgresの既存の継承を通じてパーティションを作成できるようにするパッチを既にコミットしています。同様に、外部テーブル、外部テーブルの継承を行う場合、かなり単純なシャーディングを実行できます。ただし、オプティマイザーがこのような分散クエリを最適化する方法については、多くの疑問が生じます。

EnterpriseDBは現在、Aggregate Pushdownを実行できるようにパッチに取り組んでいます。シャードからすべてをプルしないようにしてから、集計をカウントし、シャード自体の集計をカウントできるようにします。同様に、プッシュダウンに参加します...そして、このようなかなり長いロードマップは、完全には完成していません。おそらく、本格的な分散オプティマイザーを入手するのは明確ではありません。ただし、このアプローチの利点は、FDWを改善していることです。

Greenplumは、3日前にオープンソースで最近リリースされたPivotalの商用フォークです。

Oleg Bartunov： GitHubでGreenplumをダウンロードし、コンパイル、インストールすれば、eBayが長い間働いていたのと同じ大規模な並列データベースをすでに持っていることになります。つまりここでのオープンソース開発モデルはオープンであり、その利点を示しています。

Fedor Sigaev：覚えておいてください-これらはOLAPデータベースであり、OLTPではありません。 Postgresで何かを大量に分析する必要がある場合は、Greenplumまたはpg_shardでそれを感じることができますが、確実に転送されることを期待してそこにお金を入れない方が良いです。

Alexander Korotkov：そして、私たちが始めたプロジェクトは、Postgresウィザード用の分散トランザクションマネージャーです。彼についてもう少し詳しくお話します。

Oleg Bartunov：これらは活発で活発なプロジェクトであり、独自のカスタムマーがあり、開発中です。そして、我々はリソースがあることがわかりますが、コミュニティの決定はありません。

前回のPGConで、この問題を提起し、この問題を解決するための大きな会議、いわゆるクラスターサミットを開催することに同意しました。

2日前、私たちはこの会議から飛びました。私たちはウィーンで会い、クラスターの燃焼問題、つまりコミュニティがTodoでクラスター化されたソリューションを使用するかどうかという問題を提起しました。

私たちは、状況が非常に成熟しているため、Todoに示す必要があると判断しました。同時に、クラスターソリューションの開発を継続する必要があります。既に示したように、クラスターソリューションは非常に複雑なものであり、明日または2年後にこのソリューションが勝つとは言えないため、ソリューションを開発する必要があります。さらに、たとえば、当社のコミットメントが他のソリューションへの道を妨げないような方法で開発する必要があります-これは非常に重要です。決定-平和と愛。

クラスタソリューションを拡張として開発できるようにPostgresインフラストラクチャを作成するというアイデアがありました。これにより、開発が大幅に促進されます。分散トランザクションマネージャーについて話しましたが、このアイデアは人々にとって興味深いものでした。この問題を9.6にプッシュします。 9.6では、分散トランザクションが既にPostgresにあり、少なくとも誰かが既にクラスターを作成できるようにしますか？アプリケーションレベルで。

2015年10月31日にEnterpriseDBから取得したスライドに追加しました。この期間を水平スケーリング（シャーディング）と呼び、解決する必要のあるタスクのリストを作成しました。つまりこれがコミュニティで推進されているもので、コミュニティがこれを処理します。

アレクサンダー・コロトコフ：目標は明確であり、読み取りと書き込みの両方のスケーラビリティに加えて、高い価値を求めています。これは、たとえば冗長性を使用して実現できます。同じシャードは1つのコピーではなく、2つのコピーに保持されます。

そして、彼らはここでタスクを売り込みました、ここで最大です。実際にはもっと多くあることは明らかです。私たちが扱っているタスクは、分散トランザクションの管理です。現在、多くの異なる関心事が交差しているのは、分散リクエストのプランナーとエグゼキューターです。 FDWは分散リクエストに対する1つのアプローチであり、pg_shardは別のアプローチであり、Postgres XC XLは3番目のアプローチです。そして、おそらく4日、5日など。しかし、遅かれ早かれこの方向で、共通の分母にも到達することを願っています。

Oleg Bartunov： Bruce Momzhanが会議にここにいます。彼はTodoでのクラスタリングに関する条項を書くべき責任者です。そうすれば、なんらかの努力を結集する必要があるので、すべてがうまくいきます。

この写真は、たくさんの材料があり、その中からたくさんのものを調理できることを意味しますが、それが判明するという事実はありません。

アレクサンダー・コロトコフ：表では、このようなマトリックスを作成しようとしました。ここにクラスターソリューションを入力しました。現在存在し、開発中のソリューションと、かつて歴史的でサポートされなくなったソリューションの両方です。

Fedor Sigaev：最も人気のあるものを採用しました。 Olegは最初、このマトリックスがさらに大きく、ピクセルごとのグラフィックを作成できることを示しましたが、それからは何も明確ではありません。

オレグ・バルトゥノフ：この表は長い間検討することができ、議論することができます。理想的な解決策はないことを示しています。たとえば、XC / XL / X2は最も魅力的に見え、最もプラスになります。 FDWとpg_shardにも多くの利点がありますが、特にデータの整合性に欠ける何かが欠けています。

戦い全体が始まったとき、各企業は「私たちは決断を下す、私たちの決断は良い」などと述べました。また、XLを使用して遊んで、独自のクラスターを作成することを決めましたが、XLが実稼働で使用する準備があまり整っていないことに気付き、一般的な戦いには参加せず、その一般的な技術に集中することにしました誰もが必要とする要素。つまりすべてのクラスタソリューションには、分散トランザクションマネージャが必要です。

したがって、この方向を選択して実装しました。次に、それが何であるか、なぜそれが重要であるか、そしてそれがクラスターソリューションに与えるものを説明します。

アレクサンダー・コロトコフ：分散トランザクションマネージャーには一般的に何が必要ですか？分散システムでのコミットがアトミックであることは明らかです。アトミックとは、まず、アトミックにあらゆる場所を通過するか、あらゆる場所に転がることを意味します。第二に、アトミックな可視性、つまりこれは、複数のデータベース（2番目のシーンで示したもの）の読み取り要求を行った場合、すべてのコミットを表示するか、すべてのコミットを表示する必要がないことを意味します。あるサーバーでお金が既に送金されているのを見て、別のサーバーで送金されていないことがわかり、その結果、金額が収束しません。

, . , , pluggable API . つまり Postgres' , — , . , , , - , , , .

API, , . , Postgres , so', , .

: , pluggable. pluggable, executer pluggable, , , , Transaction Manager pluggable.

: , , executer Postgres pluggable, .. executer, .

: , ? : , , Transaction Manager Postgres .

: , , .

, .. , Postgres.

, Transaction Manager.

次。

, , .

— Snapshot sharing — , Postgres XC, XL. , , , . , , , - , . ? , . , , , — , , ..
Timestamp. , , , Timestamp. Timestamp, , , , , , , . MTP , . , , , , , . . , , , , - , , , . , two-phase commit, , , .
— . , . , . , , , ' , , , .. , . , , .