オープンソース データベースで何を行うのか、そしてなぜ行うのか。 アンドレイ・ボロディン (Yandex.Cloud)

以下のデータベースに対する Yandex の貢献がレビューされます。

• クリックハウス
• Odyssey
• ある時点へのリカバリ (WAL-G)
• PostgreSQL (logerrors、Amcheck、heapcheck を含む)
• グリーンプラム

ビデオ：

こんにちは世界！ 私の名前はアンドレイ・ボロディンです。 そして、私が Yandex.Cloud で行っていることは、Yandex.Cloud と Yandex.Cloud クライアントの利益のためにオープン リレーショナル データベースを開発することです。

この講演では、大規模なオープン データベースが直面する課題について話します。 どうしてそれが重要ですか？ なぜなら、小さな、小さな問題が、蚊のように、やがて象になるからです。 クラスターが多数ある場合、それらは大きくなります。

しかし、それが重要なことではありません。 信じられないようなことが起こります。 XNUMX万件にXNUMX件の確率で起こること。 そして、クラウド環境では、何かが大規模に存在すると、信じられないようなことが起こる可能性が非常に高くなるため、そのことに備える必要があります。

しかし！ オープンデータベースの利点は何ですか? 事実は、どんな問題にも理論的に対処する機会があるということです。 あなたはソースコードを持っており、プログラミングの知識も持っています。 それを組み合わせるとうまくいきます。

オープンソース ソフトウェアに取り組むにはどのようなアプローチがありますか?

• 最も簡単なアプローチはソフトウェアを使用することです。 プロトコルを使用している場合、標準を使用している場合、フォーマットを使用している場合、オープン ソース ソフトウェアでクエリを作成している場合は、すでにそれをサポートしていることになります。
• エコシステムを拡大しているのです。 バグの早期発見の可能性が高まります。 このシステムの信頼性が高まります。 市場における開発者の可用性が高まります。 あなたはこのソフトウェアを改良します。 スタイルを整えて何かをいじくり回しただけなら、あなたはすでに貢献者です。
• もう XNUMX つのわかりやすいアプローチは、オープンソース ソフトウェアのスポンサーになることです。 たとえば、有名な Google Summer of Code プログラムでは、Google は世界中から集まった多数の学生に、特定のライセンス要件を満たすオープン ソフトウェア プロジェクトを開発してもらうために、理解できる金額を支払います。
• これは、焦点をコミュニティから移すことなくソフトウェアを進化させることができるため、非常に興味深いアプローチです。 テクノロジーの巨人である Google は、この機能が欲しい、このバグを修正したい、ここを掘り下げる必要があるとは言っていません。 グーグルはこう言います。 これまでと同じように仕事を続ければ、すべてうまくいくでしょう。」
• オープンソースに参加するための次のアプローチは参加です。 オープンソース ソフトウェアに問題があり、開発者がいる場合、開発者は問題の解決を開始します。 これらにより、インフラストラクチャの効率が向上し、プログラムの速度と信頼性が向上します。

オープンソース ソフトウェアの分野で最も有名な Yandex プロジェクトの XNUMX つは ClickHouse です。 これは、Yandex.Metrica が直面する課題への対応として誕生したデータベースです。

また、データベースとしては、エコシステムを構築し、他の開発者 (Yandex 内だけでなく) と一緒に開発するために、オープンソースで作成されました。 そして今、これは多くの企業が関与する大きなプロジェクトです。

Yandex.Cloud では、Yandex Object Storage の上、つまりクラウド ストレージの上に ClickHouse を作成しました。

これがクラウドにおいてなぜ重要なのでしょうか? なぜなら、どのデータベースもこの三角形、ピラミッド、メモリ タイプの階層内で機能するからです。 高速だが小さいレジスタと、安価で大きいが遅い SSD、ハード ドライブ、およびその他のブロック デバイスがあります。 そして、ピラミッドの頂点で効率的であれば、高速なデータベースを手に入れることができます。 このピラミッドの最下位で効率的であれば、スケールされたデータベースを手に入れることができます。 この点で、下から別のレイヤーを追加することは、データベースのスケーラビリティを高めるための論理的なアプローチです。

どうすればそれができるでしょうか？ これはこのレポートの重要なポイントです。

• MDS 上に ClickHouse を実装することもできます。 MDS は、Yandex の内部クラウド ストレージ インターフェイスです。 一般的な S3 プロトコルよりも複雑ですが、ブロック デバイスにより適しています。 データの記録に適しています。 より多くのプログラミングが必要になります。 プログラマーがプログラミングするのは良いことですし、面白いこともあります。
• S3 は、特定の種類のワークロードへの適応性が低下する代わりにインターフェイスを簡素化する、より一般的なアプローチです。

当然のことながら、ClickHouse エコシステム全体に機能を提供し、Yandex.Cloud 内で必要なタスクを実行したいと考え、ClickHouse コミュニティ全体がその恩恵を受けられるようにすることにしました。 MDS を介した ClickHouse ではなく、S3 を介して ClickHouse を実装しました。 そして、これは大変な作業です。

リンク：

https://github.com/ClickHouse/ClickHouse/pull/7946 「ファイルシステム抽象化レイヤー」
https://github.com/ClickHouse/ClickHouse/pull/8011 「AWS SDK S3統合」
https://github.com/ClickHouse/ClickHouse/pull/8649 「S3 用 IDisk インターフェイスの基本実装」
https://github.com/ClickHouse/ClickHouse/pull/8356 「ログ ストレージ エンジンと IDisk インターフェイスの統合」
https://github.com/ClickHouse/ClickHouse/pull/8862 「S3 および SeekableReadBuffer のログ エンジンのサポート」
https://github.com/ClickHouse/ClickHouse/pull/9128 「ストレージストライプログS3のサポート」
https://github.com/ClickHouse/ClickHouse/pull/9415 「Storage MergeTree の S3 の初期サポート」
https://github.com/ClickHouse/ClickHouse/pull/9646 「MergeTree による S3 の完全サポート」
https://github.com/ClickHouse/ClickHouse/pull/10126 「S3 経由で ReplicatedMergeTree をサポート」
https://github.com/ClickHouse/ClickHouse/pull/11134 「s3 ストレージのデフォルトの認証情報とカスタムヘッダーを追加」
https://github.com/ClickHouse/ClickHouse/pull/10576 「動的プロキシ構成を備えた S3」
https://github.com/ClickHouse/ClickHouse/pull/10744 「プロキシリゾルバーを備えた S3」

ClickHouseに仮想ファイルシステムを実装するためのプルリクエストリストです。 これは大量のプル リクエストです。

リンク：

https://github.com/ClickHouse/ClickHouse/pull/9760 「DiskS3 ハードリンクの最適な実装」
https://github.com/ClickHouse/ClickHouse/pull/11522 「S3 HTTP クライアント — 応答ストリームをメモリにコピーしないようにする」
https://github.com/ClickHouse/ClickHouse/pull/11561 「応答ストリーム全体を S3 HTTP のメモリにコピーすることは避けてください。
クライアント"
https://github.com/ClickHouse/ClickHouse/pull/13076 「S3 ディスクのマーク ファイルとインデックス ファイルをキャッシュする機能」
https://github.com/ClickHouse/ClickHouse/pull/13459 「パーツを DiskLocal から DiskS3 に並行して移動します」

しかし、仕事はそこで終わりではありませんでした。 この機能が作成された後、この機能を最適化するためにさらに作業が必要になりました。

リンク：

https://github.com/ClickHouse/ClickHouse/pull/12638 「SelectedRows および SelectedBytes イベントを追加する」
https://github.com/ClickHouse/ClickHouse/pull/12464 「S3 リクエストからのプロファイリング イベントを system.events に追加」
https://github.com/ClickHouse/ClickHouse/pull/13028 「クエリタイムマイクロ秒、選択クエリタイムマイクロ秒、および挿入クエリタイムマイクロ秒を追加」

そして、それを診断可能にし、監視を設定し、管理可能にする必要がありました。

そして、これはすべて、コミュニティ全体、ClickHouse エコシステム全体がこの作業の結果を受け取るために行われました。

次に、私にとって個人的に近いトランザクション データベース、OLTP データベースに移りましょう。

オープンソースDBMS開発部門です。 彼らは、トランザクションのオープン データベースを改善するためにストリート マジックを行っています。

プロジェクトの XNUMX つは、Postgres の接続プーラーです。その例を使用して、私たちがどのように、何を行っているかについて説明します。

Postgres はプロセス データベースです。 これは、データベースでトランザクションを処理するネットワーク接続をできるだけ少なくする必要があることを意味します。

一方、クラウド環境では、一度に XNUMX の接続が XNUMX つのクラスターに到達することが一般的な状況です。 そして、接続プーラーのタスクは、XNUMX の接続を少数のサーバー接続に詰め込むことです。

接続プーラーは、データベースに効率的に到達できるようにバイトを再配置する電話交換手であると言えます。

残念ながら、ロシア語で接続プーラーを表す適切な単語はありません。 マルチプレクサ接続と呼ばれることもあります。 接続プーラーを何と呼ぶべきかご存知の場合は、ぜひ教えてください。正しいロシア語の専門用語を喜んで話します。

https://pgconf.ru/2017/92899

マネージド postgres クラスターに適した接続プーラーを調査しました。 そして、PgBouncer が私たちにとって最良の選択でした。 しかし、PgBouncer では多くの問題が発生しました。 何年も前に、Volodya Borodin は、私たちが PgBouncer を使用しており、すべてが気に入っているが、ニュアンスがあり、取り組むべき点があると報告しました。

https://pgconf.ru/media/2017/04/03/20170316H1_V.Borodin.pdf

そして私たちは働きました。 私たちは発生した問題を修正し、Bouncer にパッチを適用し、プル リクエストをアップストリームにプッシュしようとしました。 しかし、基本的なシングルスレッドは扱いが困難でした。

パッチを適用した用心棒からカスケードを収集する必要がありました。 多数のシングルスレッド バウンサーがある場合、最上層の接続はバウンサーの内部層に転送されます。 これは管理が不十分なシステムであり、構築や拡張が困難です。

私たちは、Odyssey という独自の接続プーラーを作成するという結論に達しました。 私たちはそれを一から書きました。

https://www.pgcon.org/2019/schedule/events/1312.en.html

2019 年の PgCon カンファレンスで、私はこのプーラーを開発者コミュニティに発表しました。 現在、GitHub には 2 個弱のスターが付いています。つまり、プロジェクトは生きており、プロジェクトは人気があります。

Yandex.Cloud で Postgres クラスターを作成すると、それは Odyssey が組み込まれたクラスターになり、クラスターを前後にスケーリングするときに再構成されます。

このプロジェクトから何を学んだでしょうか? 競合するプロジェクトを立ち上げることは常に積極的なステップであり、十分な速さで解決されない問題や、私たちに適した期間内に解決されない問題があると言う場合、それは極端な手段です。 しかし、これは効果的な対策です。

PgBouncer はより迅速に開発を開始しました。

そして今、他のプロジェクトも登場しています。 たとえば、Red Hat 開発者によって開発された pgagroal などです。 彼らは同様の目標を追求し、同様のアイデアを実装していますが、もちろん、独自の詳細があり、pgagroal 開発者に近いものとなっています。

postgres コミュニティと連携するもう XNUMX つのケースは、ある時点への復元です。 これは障害後の回復であり、これはバックアップからの回復です。

バックアップはたくさんありますが、それらはすべて異なります。 ほぼすべての Postgres ベンダーは独自のバックアップ ソリューションを持っています。

すべてのバックアップ システムを取得し、特徴マトリックスを作成し、冗談めかしてこのマトリックスの行列式を計算すると、それはゼロになります。 これはどういう意味ですか？ 特定のバックアップ ファイルを取得した場合、そのバックアップ ファイルを他のすべてのファイルの断片から組み立てることはできません。 実装も目的も、そこに組み込まれたアイデアも独自です。 そしてそれらはすべて具体的です。

https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-faster-restores-for-postgres/

私たちがこの問題に取り組んでいる間に、CitusData は WAL-G プロジェクトを立ち上げました。 クラウド環境を意識したバックアップシステムです。 現在、CitusData はすでに Microsoft の一部となっています。 そしてその瞬間、私たちは WAL-G の初期リリースに盛り込まれたアイデアをとても気に入っていました。 そして私たちはこのプロジェクトに貢献し始めました。

https://github.com/wal-g/wal-g/graphs/contributors

現在、このプロジェクトには数十人の開発者が参加していますが、WAL-G への貢献者のトップ 10 には 6 人の Yandexoid が含まれています。 そこで私たちはたくさんのアイデアを持ち寄りました。 そしてもちろん、私たちはそれらを自分たちで実装し、自分たちでテストし、自分たちで運用環境に展開し、自分たちで使用し、大規模な WAL-G コミュニティと対話しながら、次にどこに進むべきかを自分たちで考えました。

そして、私たちの観点からすると、このバックアップシステムは、私たちの努力も含めて、クラウド環境に最適なものになったと言えます。 これは、クラウドで Postgres をバックアップする場合の最良のコストです。

それはどういう意味ですか？ 私たちはかなり大きなアイデアを推進していました。それは、バックアップは安全で、運用コストが低く、できるだけ早く復元できる必要があるということです。

なぜ運用コストが安くなければならないのでしょうか？ 何も壊れていないときは、バックアップがあることに気づかないはずです。 すべてが正常に動作し、CPU の無駄を最小限に抑え、ディスク リソースの使用を最小限に抑え、貴重なサービスのペイロードに干渉しないようにネットワークに送信するバイト数を最小限に抑えます。

そして、たとえば、管理者がデータを落としたり、何か問題が発生したりして、すべてが壊れた場合、緊急に過去に戻る必要がある場合、データを迅速かつ無傷で戻したいため、全額を負担して回復します。

そして私たちはこのシンプルなアイデアを推進しました。 そして、私たちはそれをなんとか実装できたようです。

しかし、それだけではありません。 もう一つ小さなことが欲しかった。 さまざまなデータベースが必要でした。 すべてのクライアントが Postgres を使用しているわけではありません。 MySQL や MongoDB を使用する人もいます。 コミュニティでは、他の開発者が FoundationDB をサポートしています。 そして、このリストは常に拡大しています。

コミュニティは、データベースがクラウドの管理された環境で実行されるというアイデアを気に入っています。 また、開発者はデータベースを保守しており、当社のバックアップ システムを使用して Postgres とともに均一にバックアップできます。

この話から私たちは何を学んだでしょうか? 開発部門としての私たちの製品は、コード行でも、ステートメントでも、ファイルでもありません。 当社の製品はプルリクエストではありません。 これらは私たちがコミュニティに伝えるアイデアです。 これは技術的な専門知識とクラウド環境へのテクノロジーの移行です。

Postgres などのデータベースがあります。 私は Postgres コアが最も好きです。 私はコミュニティとともに Postgres コアの開発に多くの時間を費やしています。

しかし、ここでYandex.Cloudには管理されたデータベースの内部インストールがあると言わなければなりません。 そしてそれはずっと前に Yandex.Mail で始まりました。 現在マネージド Postgres につながっている専門知識は、メールを Postgres に移行しようとしたときに蓄積されました。

メールにはクラウドと非常によく似た要件があります。 データのどの時点でも予期せぬ指数関数的な増加に対応できるようにする必要があります。 そして、メールには、常に多くのリクエストを行う膨大な数のユーザーの数億のメールボックスが含まれており、すでに負荷がかかっていました。

そして、これは Postgres を開発していたチームにとって非常に深刻な課題でした。 当時、私たちが遭遇した問題はすべてコミュニティに報告されました。 そして、これらの問題は修正され、いくつかの場所では、他のデータベースの有償サポートのレベル、さらにはそれ以上のレベルでもコミュニティによって修正されました。 つまり、PgSQL ハッカーにレターを送信すると、40 分以内に応答を受け取ることができます。 一部のデータベースの有料サポートは、バグよりも優先すべき事項があると考えている場合があります。

現在、Postgres の内部インストールには数ペタバイトのデータがあります。 これらは XNUMX 秒あたり数百万件のリクエストに相当します。 これらは何千ものクラスターです。 とても大規模なものです。

しかし、ニュアンスがあります。 それは派手なネットワークドライブ上ではなく、かなり単純なハードウェア上に存在します。 そして、興味深い新しいものに特化したテスト環境もあります。

そして、テスト環境のある時点で、データベース インデックスの内部不変条件が違反されたことを示すメッセージを受け取りました。

不変式とは、常に保持されると期待されるある種の関係です。

私たちにとって非常に危機的な状況です。 これは、一部のデータが失われた可能性があることを示しています。 そして、データの損失はまさに壊滅的なものです。

管理されたデータベースで私たちが従う一般的な考え方は、努力してもデータを失うのは難しいということです。 たとえ意図的に削除したとしても、長期間その不在を無視する必要があります。 データ セキュリティは、私たちが非常に熱心に従う宗教です。

そしてここで、私たちが備えられていない状況が存在する可能性を示唆する状況が生じます。 そして私たちはこの状況に備え始めました。

https://commitfest.postgresql.org/23/2171/

私たちが最初に行ったのは、これらの数千のクラスターからのログを埋めることでした。 データ ページの更新が失われてしまう問題のあるファームウェアが搭載されたディスク上にクラスタが配置されていることがわかりました。 すべての Postgres データ コードをマークアップしました。 そして、内部不変条件の違反を示すメッセージを、データ破損を検出するように設計されたコードでマークしました。

このパッチは、実際にはあまり議論されることなくコミュニティに受け入れられました。なぜなら、それぞれの特定のケースにおいて、何か悪いことが起こったことが明らかであり、ログに報告する必要があったからです。

この後、ログをスキャンする監視を行うようになりました。 そして、不審なメッセージがあった場合には、当直担当者を起こし、当直担当者がメッセージを修復します。

しかし！ ログのスキャンは、XNUMX つのクラスターでは低コストの操作ですが、XNUMX 個のクラスターでは壊滅的なコストがかかります。

という拡張機能を書きました ログエラー。 過去のエラーに関する統計を安価かつ迅速に選択できるデータベースのビューを作成します。 そして、当番職員を起こす必要がある場合は、ギガバイトのファイルをスキャンすることなく、ハッシュテーブルから数バイトを抽出することでこれを知ることができます。

この拡張機能は、たとえば、次のリポジトリで採用されています。 CentOSの。 使用したい場合は、自分でインストールできます。 もちろんオープンソースです。

https://www.postgresql.org/message-id/flat/[メール保護]

しかし、それだけではありません。 私たちは、インデックスの不変違反を見つけるために、コミュニティが構築した拡張機能である Amcheck の使用を開始しました。

そして、それを大規模に運用するとバグが存在することが分かりました。 私たちはそれらを修正し始めました。 私たちの修正は受け入れられました。

https://www.postgresql.org/message-id/flat/[メール保護]

この拡張機能では GiST および GIT インデックスを分析できないことがわかりました。 私たちは彼らをサポートさせました。 ただし、これは比較的新しい機能であり、詳細がたくさんあるため、このサポートについてはまだコミュニティで議論されています。

https://commitfest.postgresql.org/29/2667/

また、レプリケーション リーダーやマスターではインデックスの違反をチェックする場合、すべて正常に機能しますが、レプリカやフォロワーでは破損の検索がそれほど効果的ではないこともわかりました。 すべての不変条件がチェックされるわけではありません。 そして、XNUMX つの不変条件が私たちを非常に悩ませました。 そして、レプリカでのこのチェックを可能にするために、私たちは XNUMX 年半をかけてコミュニティとコミュニケーションを図りました。

私たちは、すべてのプロトコルに従う必要があるコードを作成しました。 私たちはこのパッチについて Crunchy Data の Peter Gaghan とかなり長い間議論しました。 このパッチを受け入れるために、Postgres の既存の B ツリーをわずかに変更する必要がありました。 彼は受け入れられました。 そして今では、レプリカのインデックスをチェックすることも、遭遇した違反を検出するのに十分な効果を発揮するようになりました。 つまり、これらは、ディスク ファームウェアのエラー、Postgres のバグ、Linux カーネルのバグ、およびハードウェアの問題によって引き起こされる可能性のある違反です。 私たちが準備していた問題の原因の非常に広範なリスト。

https://www.postgresql.org/message-id/flat/38AF687F-8F6B-48B4-AB9E-A60CFD6CC261%40enterprisedb.com#0e86a12c01d967bac04a9bf83cd337cb

ただし、インデックスの他に、ヒープ、つまりデータが保存される場所のような部分があります。 そして、チェックできる不変条件はそれほど多くありません。

Heapcheck という拡張機能があります。 私たちはそれを開発し始めました。 そして並行して、EnterpriseDB 社も私たちと協力して、同じように Heapcheck と呼ばれるモジュールの作成を開始しました。 私たちがそれを PgHeapcheck と呼んだだけで、彼らも単に Heapcheck と呼んだだけです。 彼らは同様の機能、わずかに異なるシグネチャを備えたものを持っていますが、同じアイデアを持っています。 いくつかの場所ではもう少し改良して実装されました。 そして彼らは以前にそれをオープンソースで公開しました。

そして今、私たちは彼らの拡大を進めています。それはもはや彼らの拡大ではなく、コミュニティの拡大だからです。 そして将来的には、これはすべての人に提供されるカーネルの一部となり、将来の問題を事前に知ることができるようになります。

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

場所によっては、監視システムに誤検知があるという結論に達したことさえあります。 たとえば、1C システム。 データベースを使用する場合、Postgres は読み取り可能なデータをデータベースに書き込むことがありますが、pg_dump は読み取ることができません。

この状況は、問題検出システムにとって破損のように見えました。 当直の警官は目が覚めた。 当直の警察官は何が起こっているのかを見ました。 しばらくして、クライアントが来て、私に問題があると言いました。 係員は何が問題なのか説明してくれました。 しかし、問題は Postgres コアにあります。

この機能に関するディスカッションを見つけました。 そして彼は、私たちはこの機能に遭遇しましたが、それは不快であり、人はそれが何であるかを理解するために夜に目が覚めたと書きました。

https://www.postgresql.org/message-id/flat/fe9b3722df94f7bdb08768f50ee8fe59%40postgrespro.ru

コミュニティは「ああ、本当に修正する必要がある」と答えました。

簡単な例えがあります。 砂粒が入った靴を履いて歩いている場合は、原則として、先に進んでも問題ありません。 何千人もの人にブーツを売るなら、砂を一切使わずにブーツを作りましょう。 そして、あなたのシューズのユーザーの XNUMX 人がマラソンを走る予定であれば、非常に優れたシューズを作り、それをすべてのユーザーに提供したいと考えます。 そして、そのような予期せぬユーザーは常にクラウド環境に存在します。 独自の方法でクラスターを悪用するユーザーが常に存在します。 常にこれに備えなければなりません。

ここで私たちは何を学んだのでしょうか？ 私たちは単純なことを学びました。最も重要なことは、問題があることをコミュニティに説明することです。 コミュニティが問題を認識していれば、問題を解決するために自然な競争が起こります。 誰もが重要な問題を解決したいと考えているからです。 すべてのベンダー、すべてのハッカーは、自分たちもこの熊手を踏む可能性があることを理解しているため、それらを排除したいと考えています。

あなたが問題に取り組んでいて、それがあなた以外の誰も気にしていなくても、体系的に取り組んでおり、最終的には問題とみなされている場合、あなたのプルリクエストは間違いなく受け入れられます。 あなたのパッチは受け入れられ、あなたの改善、あるいは改善の要求さえもコミュニティによって検討されます。 結局のところ、私たちはデータベースをお互いにとってより良いものにするのです。

興味深いデータベースは Greenplum です。 これは、私がよく知っている Postgres コードベースに基づいた高度な並列データベースです。

https://greenplum.org/greenplum-database-tables-compression/

Greenplum には、最適化されたテーブルを追加するという興味深い機能があります。 これらのテーブルはすぐに追加できます。 列状または行状のいずれかにすることができます。

しかし、クラスタリングはありませんでした。つまり、インデックスの XNUMX つにある順序に従ってテーブル内のデータを配置する機能はありませんでした。

タクシーの男たちが私のところに来てこう言いました。「アンドレイ、あなたは Postgres を知っていますね。 そしてここでもほぼ同じです。 20分に切り替えます。 あなたはそれを受け取って、それを実行してください。」 私は、そうだ、Postgres を知っている、20 分間切り替える、これを行う必要がある、と思いました。

https://github.com/greenplum-db/gpdb/commit/179feb77a034c2547021d675082aae0911be40f7

でも、いえ、20分ではなく、何か月もかけて書きました。 PgConf.Russia カンファレンスで、私は Pivotal の Heikki Linakangas 氏にこう尋ねました。 追加に最適化されたテーブル クラスタリングがないのはなぜですか?」 彼はこう言います。「あなたはデータを受け取ります。 並べ替えたり、並べ替えたりします。 それはただの仕事だよ。」 私：「ああ、そうだね、それを受け入れてやればいいんだ。」 彼はこう言います。「はい、これを行うには自由な手が必要です。」 これは絶対にやらなければいけないと思いました。

そして数か月後、私はこの機能を実装するプルリクエストを送信しました。 このプル リクエストは、Pivo​​tal によってコミュニティとともにレビューされました。 もちろん、バグもありました。

https://github.com/greenplum-db/gpdb/issues/10150

しかし、最も興味深いのは、このプル リクエストがマージされたときに、Greenplum 自体にバグが見つかったことです。 ヒープ テーブルはクラスタ化するとトランザクション性を損なうことがあることがわかりました。 そして、これは修正する必要があることです。 そして彼女は私が今触れた場所にいます。 そして私の自然な反応は、「分かった、私もやらせてください」というものでした。

https://github.com/greenplum-db/gpdb/pull/10290

このバグを修正しました。 修正者にプルリクエストを送信しました。 彼は殺された。

https://github.com/greenplum-db/gpdb-postgres-merge/pull/53

その後、この機能は PostgreSQL 12 用の Greenplum バージョンで取得する必要があることが判明しました。つまり、20 分間の冒険は新しい興味深い冒険で続きます。 コミュニティが新しい最も重要な機能をカットしている現在の開発に触れることは興味深いものでした。 凍ってます。

https://github.com/greenplum-db/gpdb/pull/10565

しかし、それで終わりではありませんでした。 結局、これらすべてについてドキュメントを作成する必要があることが判明しました。

ドキュメントを書き始めました。 幸運なことに、Pivo​​tal のドキュメンタリー制作者たちが来てくれました。 英語は彼らの母国語です。 彼らは書類作成を手伝ってくれました。 実際、私が提案した内容を彼ら自身が本物の英語に書き直してくれました。

そしてここで、冒険は終わったようです。 そして、その時何が起こったか知っていますか？ タクシーの男たちが私のところに来て、「まだ冒険が 10 つあります。それぞれ XNUMX 分です。」と言いました。 そして、彼らに何を伝えればいいでしょうか？ これは興味深い仕事なので、これから大規模なレポートを提出してから、あなたの冒険を見てみましょう、と言いました。

この事例から何を学んだでしょうか? オープンソースでの作業は常に特定の人物との作業であるため、常にコミュニティとの作業になります。 なぜなら、あらゆる段階で、私は開発者、テスター、ハッカー、ドキュメンタリー作家、アーキテクトと仕事をしてきたからです。 私はGreenplumと一緒に仕事をしたのではなく、Greenplumの周りの人々と一緒に仕事をしました。

しかし！ もう一つ重要な点があります。それは単なる仕事です。 つまり、来て、コーヒーを飲みながら、コードを書きます。 あらゆる種類の単純な不変式が機能します。 普通にやれば大丈夫ですよ！ そしてそれはとても興味深い仕事です。 Yandex.Cloud クライアント、つまり Yandex 内外のクラスターのユーザーから、この作業に対するリクエストがあります。 そして参加するプロジェクトも増え、関わりの深さも増していくと思います。

それだけです。 質問に移ります。

質疑応答

こんにちは！ 再度質疑応答を行います。 そしてスタジオではアンドレイ・ボロディン。 これは、Yandex.Cloud と Yandex のオープンソースへの貢献について先ほど話した人物です。 私たちの今回のレポートは完全にクラウドに関するものではありませんが、同時にそのようなテクノロジーに基づいています。 Yandex 内での取り組みがなければ、Yandex.Cloud のサービスは存在しませんでした。私から個人的に感謝いたします。 そして放送の最初の質問は「あなたが言及したそれぞれのプロジェクトには何について書かれていますか?」

WAL-G のバックアップ システムは Go で書かれています。 これは私たちが取り組んできた新しいプロジェクトの 3 つです。 彼は文字通りわずか30歳です。 そして、データベースは多くの場合、信頼性を重視します。 これは、データベースがかなり古く、通常は C で書かれていることを意味します。Postgres プロジェクトは約 89 年前に始まりました。 それならば、CXNUMXは正しい選択でした。 そしてPostgresが書かれています。 ClickHouse などの最新のデータベースは、通常 C++ で書かれています。 すべてのシステム開発は C および C++ に基づいています。

クラウドの経費を担当する財務マネージャーからの質問: 「なぜクラウドはオープンソースのサポートにお金を使うのですか?」

財務マネージャーにとっての簡単な答えがここにあります。 これはサービスを向上させるために行われます。 どのような方法で改善できるでしょうか? 物事をより効率的かつ迅速に実行し、よりスケーラブルにすることができます。 しかし、私たちにとって、この話は主に信頼性に関するものです。 たとえば、バックアップ システムでは、適用されるパッチを 100% レビューします。 私たちはコードが何であるかを知っています。 そして、新しいバージョンを実稼働環境にロールアウトすることにさらに慣れてきました。 つまり、まず第一に、自信、開発の準備、そして信頼性についてです。

もう XNUMX つの質問: 「Yandex.Cloud に住む外部ユーザーの要件は、内部クラウドに住む内部ユーザーと異なりますか?」

もちろん、負荷プロファイルは異なります。 しかし、私の部門の観点から見ると、特殊で興味深いケースはすべて非標準の負荷で作成されています。 想像力のある開発者、予期せぬことを行う開発者は、社内でも社外でも同様に見つかります。 この点に関しては、私たちは皆ほぼ同じです。 そしておそらく、Yandex のデータベース操作における唯一の重要な機能は、Yandex 内に教えがあるということです。 ある時点で、一部のアベイラビリティ ゾーンが完全にシャドウ状態になり、これにもかかわらず、すべての Yandex サービスが何らかの形で機能し続けなければなりません。 これは小さな違いです。 しかし、データベースとネットワーク スタックのインターフェイスで多くの研究開発が行われます。 それ以外の場合、外部および内部のインストールでは、機能に対する同じ要求と、信頼性とパフォーマンスを向上させるための同様の要求が生成されます。

次の質問: 「自分の行動の多くが他のクラウドによって使用されているという事実について、個人的にはどう思いますか?」 具体的な名前は挙げませんが、Yandex.Cloud で行われた多くのプロジェクトは他の人のクラウドでも使用されています。

これはカッコいい。 まず、それは私たちが何か正しいことをしたというしるしです。 そしてそれはエゴを傷つけます。 そして、私たちは正しい決断をしたと確信しています。 一方で、これは将来、サードパーティのユーザーから新しいアイデアや新しい要求がもたらされることを期待しています。 GitHub 上のほとんどの問題は、個々のシステム管理者、個々の DBA、個々のアーキテクト、個々のエンジニアによって作成されますが、体系的な経験を持つ人が来て、特定のケースの 30% でこの問題が発生しているので、それを解決する方法を考えましょうと言うことがあります。 これが私たちが最も楽しみにしていることです。 他のクラウド プラットフォームとエクスペリエンスを共有できることを楽しみにしています。

マラソンについてたくさん話しました。 あなたがモスクワでマラソンを走ったということは知っています。 結果として？ PostgreSQLの人たちを追い抜いた？

いいえ、オレグ・バルトゥノフはとても速く走ります。 彼は私よりXNUMX時間早く終わった。 全体として、ここまで到達できたことに満足しています。 私にとっては、完走するだけでも達成感がありました。 全体的に見て、postgres コミュニティに非常に多くのランナーが存在することは驚くべきことです。 有酸素スポーツとシステムプログラミングへの欲求の間には何らかの関係があるように思えます。

ClickHouse にはランナーがいないということですか?

彼らがそこにいるのは確かです。 ClickHouse はデータベースでもあります。 ところで、オレグは今私に「レポートの後でランニングに行きましょうか？」と手紙を書いています。 これは素晴らしいアイデアです。

ニキータからの放送での別の質問: 「なぜグリーンプラムのバグを自分で修正し、後輩に渡さなかったのですか?」 確かに、どのサービスのバグなのかはあまり明確ではありませんが、おそらくあなたが話したバグのことを意味していると思われます。

はい、原則として、それは誰かに与えられた可能性があります。 変更したのはコードだけです。 そしてそれをすぐに続けるのは自然なことだった。 基本的に、チームで専門知識を共有するという考えは良い考えです。 Greenplum のタスクを部門のメンバー全員で確実に共有します。

ジュニアの話なので、ここで質問です。 その人は、Postgres で最初のコミットを作成することにしました。 最初のコミットを行うには何をする必要がありますか?

これは興味深い質問です。「どこから始めればよいですか?」 通常、カーネル内で何かを始めるのは非常に困難です。 たとえば、Postgres には To Do リストがあります。 しかし実際には、これは彼らがやろうとしたが成功しなかったことを記録したものです。 これらは複雑なことです。 そして通常、エコシステム内には、カーネル開発者からあまり注目されていない、改善可能ないくつかのユーティリティや拡張機能が見つかります。 そして、それに応じて、そこにはさらに成長するためのポイントがあります。 Google Summer of Code プログラムでは、postgres コミュニティが毎年、取り上げられる可能性のあるさまざまなトピックを提案します。 今年の生徒さんは確かXNUMX名でした。 Yandex にとって重要なトピックについて WAL-G で書いた人もいます。 Greenplum では、Postgres コミュニティよりもすべてが簡単です。Greenplum ハッカーはプル リクエストを非常にうまく扱い、すぐにレビューを開始するためです。 Postgres にパッチを送信するには数か月かかりますが、Greenplum は XNUMX 日以内に来て、あなたの成果を確認します。 もう XNUMX つは、Greenplum が現在の問題を解決する必要があるということです。 Greenplum は広く使用されていないため、問題を見つけるのは非常に困難です。 そしてもちろん、まずは問題を解決する必要があります。

出所： habr.com