開発者向けの青信号-スタートアップからスターまで。 バレンティン・ゴギチャシビリ

PGデイが開催されるのはこれで4回目です。 この間に、私たちはスピーカーから有用な資料の大規模なデータベースを蓄積しました。 業界のレポートのレベルは年々高くなっていますが、良いワインのように、その関連性を失わないトピックがあります。



Zalandoのデータエンジニアリング責任者であるValentin Gogichashviliは 、 最近の PG Dayで、開発者、非常に動的なプロセスの大規模なスタッフがいる会社でPostgreSQLがどのように使用され、どのようにこの選択をしたかを説明しました。



ZalandoがPG Dayの常連客であることは秘密ではありません。 PG Day'17 Russiaでは、ドイツの同僚からの3つの素晴らしいレポートを紹介します。 Murat KabilovとAlexey Klyukinは、 アクセスしやすいPostgreSQLクラスターを展開するためのZalandoの内部開発について話します 。 Alexander Kukushkinが 、AWSでPostgreSQLを使用する方法について説明します 。 Dmitry Dolgovは、ドキュメント指向のストレージとしてP​​ostgreSQLを使用する場合のJSONBデータ型の内部とパフォーマンスを理解するのに役立ちます。





私の人生で初めて、私はロシア語で発表します。 いくつかの翻訳や用語があなたにとって非常に面白い場合、私を責めないでください。 私は自分から始めます。 Zalandoのデータエンジニアリング責任者であるバレンタインです。











Zalandoはヨーロッパで非常に有名なオンライン靴屋であり、衣類に関連するすべてのものです。 それはそれがどのように見えるかです。 ドイツでの約98％のブランド認知度は、当社のマーケティング担当者が非常に良い仕事をしました。 残念ながら、マーケティング担当者がうまく機能すると、技術部門は非常に悪くなります。 私が4年前にザランドに来たとき、私たちの部署は50人で構成され、月に100％成長しました。 そしてそれは非常に長い間続いた。 現在、私たちは最大のオンラインストアの1つです。 3つの倉庫センター、数百万のユーザー、8,000人の従業員がいます。







画面の背後で、そのような倉庫を含むひどいことが起こっていることを想像できます。これらのうち3つがあります。 そして、これは並べ替えが行われている1つの小さな部屋です。 技術的な観点から見ると、すべてがより美しく、図を描くのはとても良いことです。 絵を描くことができる素晴らしい人がいます。







Postgresはユーザーデータに関連するすべてを記録するため、構造の中で最も重要なニッチの1つを占めています。 実際、Postgresは検索データ以外のすべてを記録します。 Solar'ahで探しています。 現在、当社のテクノロジーオフィスでは700人を雇用しています。 私たちは急速に成長しており、常に人を探しています。 ベルリンに大きなオフィスがあります。 ドルトムント、ダブリン、ヘルシンキの小規模オフィス。 ヘルシンキは先月オープンしましたが、現在採用中です。









テクノロジー企業として何をしますか？



以前はJavaとPostgresの会社でした。すべてがJavaで書かれ、Postgresで書かれていました。 2015年3月に、私たちはチームに無限の自律性と技術の選択肢を提供する、 根本的な俊敏性の概念を発表しました。 したがって、私たちにとって、Postgresが開発者のために彼らが自分で選択する技術を維持することは非常に重要であり、「さあ、Postgresに書きましょう」とは言いません。 「トランザクション」データのベースは6テラバイトです。 そこに含まれていない最大のデータベースは、時系列、ビジネスイベント（約7テラバイト）を記録するために使用するイベントログです。 このデータを扱うのは興味深いです。 あなたはすべてについて多くの新しいことを学びます。







どのような問題がありますか？



継続的な成長、高速、毎週の開発サイクル：新しい機能は毎週展開されます。 また、ダウンタイムは推奨されません。 最近、問題が発生しました-自律開発チームはデータベースをAmazon AWSアカウントにドラッグしており、DBAユーザーはこれらのデータベースにアクセスできません。







プロダクションがアイドル状態にならないようにデータスキームを変更する方法について説明します。 データの操作方法（Zalandoのデータベースへのアクセスは、ストアドプロシージャのレイヤーを介して行われます）。 これが重要だと考える理由を簡単に説明します。 そして、私たちがどのようにシャードし、どのようにデータベースを破壊するかについてもお話します。







したがって、Postgresで最も重要な機能の1つは、 実質的にロックなしでデータスキームを変更する機能です。 Oracle、MySQL、および他の多くのシステムに存在し、NoSQLデータベースが親しみのあるデータベースファミリーの完全なメンバーとして本質的に増加したという事実につながった問題は、他のデータベースがそれほど速く、うまくできないことです。データスキーマを変更します。 PostgreSQLでは、列の追加や名前の変更、デフォルト値の削除や追加、ディレクトリの展開のためにロックを必要としません。



必要なのは、他の誰もこのテーブルに触れないことを確認し、ディレクトリを変更するバリアロックだけです。 ほとんどすべての操作で、ギガバイトのデータを書き換える必要はありません。 これが最も重要です。 特に、CONCURRENTLYインデックスを作成および削除できます（テーブルをブロックせずにインデックスが作成されます）。



制約にはまだ問題があります 。 巨大な巨大テーブルにNOT NULL制約を追加する方法はまだありません。テーブルの列に実際にNULL値がないことを確認する必要はありません。 制約を信頼するため、これは正しいです。 しかし、残念なことに、これらすべてがうまく機能するために適用しなければならないいくつかの例外があり、システム全体を停止する恐ろしいロックはありませんでした。







これをどのように整理しましたか？ 私が始めたとき、Zalandoでは私が唯一のDBAでした。 データベースの構造を変更するすべてのスクリプトを作成しました。 その後、すべてのステージング環境でこれを行う必要があるため、それが恐ろしいことであることに気付きました。 さまざまな環境でディレクトリをダンプし、それらを差分と比較し始めました。 dbdiffの作成を自動化するというアイデアがありました。 そのようなツールに時間を費やすことができないことに気付きました。また、あるバージョンから別のバージョンにスクリプトを書くほうが簡単です。 ただし、dbdiffという名前は残ります。



私たちの成長に伴い、dbdiffを自分で書くことは不可能になりました。 したがって、データベースの仕組み、ロックが発生する理由、リグレッションが発生する場所などを理解できるように、開発者にSQLの作成、トレーニング、PostgreSQLの基本の認定を行う必要がありました。 そのため、「リリース」の認証を導入しました。 私たちのチームからこのような証明書を持っている人だけがデータベースの管理者権限を受け取り、システムを停止できます。 もちろん、私たちは救助に来て、みんなが問題を起こさないようにあらゆることを助け、助言し、助けます。









以下に、非常に単純なdbdiffの例を示します。order_addressテーブルと外部キーテーブルが追加されます。 問題は、開発中にテーブルが変更された場合、このテーブルのソースを毎回変更する必要があることです。 各オブジェクト、各テーブルはgitの個別のファイルにあるため、毎回dbdiffを変更する必要があります。pl/ pgsqlの素晴らしい機会を利用して、ディレクトリからファイルをアップロードできます。







興味深いことに、テーブル全体をロックする必要があるため、外部キー制約を追加する操作には問題があります。これには多くの時間がかかる可能性があります。 自分自身を保護するために、statement_timeout（システムがロックを保持するのに許容される秒数）を設定することをお勧めします。 テーブルがメモリに保存されている場合、通常は3秒で十分です。 適合しない場合、3秒でスキャンできません。









他に何が私たちを助けますか？ 私たちが書いたツールは私たちを助けてくれます。 pg_viewは、ロック、xlogでのパーティションの占有など、必要なすべてのデータベース情報を収集します。 ほぼトップのように見えます。 このツールは、何か問題が発生した場合に時間内に移行を停止できるように、残りのディスク容量に関する情報を収集し、データベースに表示されるロックを表示します。



nice_updaterは、データベースを監視し、その負荷、xlog-partitionsの負荷、ゆっくりと、それぞれ10〜100,000レコードを調べ 、更新ステートメントを実行し、定期的にバキュームを開始するプログラムです。 したがって、大規模な移行を実行します。 テーブルを追加したり、追加の列に新しい値を書き込んだりする必要がある場合、nice_updaterの使用は非常に簡単です。 彼らはいくつかの操作を展開しました。そのため、数ギガバイトの不正なデータが形成されたため、書き換える必要があります-nice_updaterは非常に役立ちます。 私の意見では、すでにオープンソースになっています。 私たちはすべてのツールを「オープンソース」にしようとしています。コードの品質は非常に向上しており、ドキュメントが登場しています。



私ができる最大のアドバイスは、データベースがあるかないかを気にしないコードをプログラマーに書かせることです。 私たちの最大の間違いは、Postgresがうまく機能しすぎていたことで、開発者はデータベースは常に重力のようなものだと考えていました。 したがって、2秒間データベースがシャットダウンされると、開発者は恐怖と完全な災害とみなします。 ROLLBACKを記述せず、このタイプのエラーを処理せず、テストも行いません。



データベースをアップグレードしたり、データベースを使用して何か他のことをしたりするために、30秒間データベースを無効にする機能を持つことが、最初にすべきことです。 今日、アンドレスと私[おおよそ。 Ed。：Andres Freund ]は、開発者が通常のコードを書くことを学ぶために、ランダムな接続を切断するモードを一般的に作成する必要があると述べました。 5分以上かかるすべてを強制終了するスクリプトがあります。 ステートメントのタイムアウトはデフォルトで30秒に設定されています。 誰かが30秒以上かかる手順を書く場合、正当な理由を与える必要があります。











ストアドプロシージャから得られるもの



最大の利点は、外出先でデータを交換できることです。古い列からデータを読み取って新しい空の列を追加します。 次に、両方の列のレコードをオンにして、新しい列から読み取り、合体を使用して古い列へのフォールバックを実行します。 次に、データを新しい列に移行します。 そして、あなたはすでに古いものを捨てることができます。 アプリケーションコードがテーブルをまったく認識しないように、テーブルの正規化を数回行いました。 この機能は、システムを健全な状態に維持するために重要です。



優れたトレーニングと優れたツールを使用して、原則として、データ構造の移行または変更に起因するダウンタイムを回避することができました。 変更数の規模を理解するために、データベースで週に約100 dbdiffsが展開されています。 そして、基本的にテーブルを変更します。 リレーショナルデータベースには、データ構造を変更する柔軟性が欠けていると定期的に言われています。 これは真実ではありません。



dbdiffトランザクションを実行しようとしますが、残念ながら、enumの変更など、トランザクションではないコマンドがあります。











データは通常どのようにアクセスされますか？



ここには、古典的な構造があります-オブジェクトの階層：顧客、彼は銀行口座を持っています。 多くの異なる注文があり、アイテムは注文にリストされます。 この階層は何が良いですか？ 顧客に関連付けられているオブジェクトは、顧客のみに関連付けられています。 ほとんどの場合、この階層を超える必要はありません。 顧客Aに注文するとき、顧客Bでどのような注文が利用できるか、またその逆については、まったく関心がありません。 誰もが多くの利点があることを知っています。快適な領域に留まり、ビジネスロジックを記述するのと同じ言語を使用します。



しかし、ハイバネートには大きな問題があり、開発者にトランザクションでうまく機能するコードを書くように教えました。 開発者は、テーブル全体をメモリにロードしてから、それを使っていくつかの部分を数分でコミットしようとします。 長いトランザクションがあり、それが長くなるほど、スキームでの移行が難しくなります。 テーブルは常にコードで表示する必要があります。 私たちには、アプリケーションとは別のベースとしての概念はありません。 これをデータロジックと呼びます。 実際、これらはデータに重畳される制約であり、ストアドプロシージャに保持すると便利です。 これは、移行では実行できません。 実際、これは別のデータ層です。



ストアドプロシージャがない場合は、アプリケーション内に抽象レイヤーを配置することをお勧めします。 たとえば、Netflixもこれを行います。 データレイヤーを介したデータアクセスを完全に抽象化する特別なライブラリがあります。 したがって、OracleからCassandraに移行しました。ロジックをビジネスとデータに分割し、ビジネスロジックを別のデータベースに置き換えます。 しかし、そのような状況でサーキットを変更するのは悪夢です。







NoSQLはすばらしいことです。この階層全体をすべての注文と一緒に使用して、1つのドキュメントを作成できます。 初期化する必要はありません。すべてがJSONに直接書き込まれます。 トランザクションは不要です。書き留められているものは書き留められます。 暗黙的なスキームが発生します。 文書の構造が変化し始めたとき、それをどのように操作し、このすべてのロジックをどこに突き出すか？ これは怖いです。 現時点では、残念ながら、ACIDのデータを失わないPostgreSQL以外のNoSQLデータベースはありません。



したがって、NoSQLにはSQLがありません。 SQLは分析操作に非常に強力な言語であり、データを非常に迅速に変換します。 これをすべて、たとえばJavaで行うことも、なんとなく怖いです。







ORMの代替手段は何ですか？



直接SQLクエリ。 ストアドプロシージャを使用せずに、データベースから集計をプルできます。 明確なトランザクション境界があります-1つのSQLが起動され、トランザクション間でデータを処理する時間が無駄になりません。 非常に良い例：Clojure上のYeSQLは、ほとんどストアドプロシージャのように機能します。 Scala Slick-Scalaに携わっており、Slickをまだ見たことがない場合は、ソースコードを確認する必要があります。これは、これまで見た中で最も印象的なコードの1つです。









ストアドプロシージャ。 トランザクション境界をクリアします。 データ層からの抽象化。 これは、古典的なJavaアプリケーションのレシピです。



ビジネスロジック、JDBCドライバー、およびデータテーブルがあります。 私たちは何をしましたか？ まず、ストアドプロシージャレイヤーを実装しました。 getFullCustomerInformationなどの行を返すとします。この行には配列があり、その順序はPostgresによってシリアル化されます。内部には位置を持つ配列もあり、内部には銀行データを持つ配列もあります。 非常によく型付けされた階層構造になります。 これがすべてJavaで記述されている場合、ある時点でクラスに50のメンバーページがあります。 これにより、ひどい結果が生じたため、独自のライブラリを作成することにしました。 彼らは彼女のSproc Wrapperと呼ばれ、データベースのAPCレイヤーとして機能します。 基本的に、アプリケーションサーバーデータベースを作成します。













どのように見えますか？



ストアドプロシージャが記述された後、注釈付きのこのような小さなインターフェイスが記述されます。 register_customer呼び出しはアプリケーションに対して完全に透過的であり、データベース内のストアドプロシージャが呼び出されます。同様に、すべてのひどいネストされた配列、ハッシュマップなどのシリアル化/逆シリアル化も呼び出されます。 注文のリストとしてマップする注文住所構造を含む。







何の問題？



ストアドプロシージャの問題は、大量のコードを記述する必要があることです。 多くのCRUD操作を行う必要がある場合（新しいExcelを作成している場合）、ストアドプロシージャの使用はお勧めしません。 100列のテーブルがある場合、各列に個別のストアドプロシージャとして変更を入力する必要があります。その後、だますことができます。 これらのストアドプロシージャを生成するブートストラップを作成した人がいました。 しかし、その後、この状況で休止状態を使用し、これらのテーブルを編集する方が良いと言いました。 たとえば、調達チームに製品情報を駆動するツールがあり、それは休止状態で書かれています。 500人がこれらのツールを使用し、1500万人がメインサイトを使用しています。



ポジティブとは？ SQLを学ぶ必要がある。 それは本当に開発者を助けます。 ClosureとScalaを学び始めた開発者は、定期的に私に頼り、「ScalaはほとんどSQLに似ています、すごい!!!」と言っています。 原則として、はい。 機能フィルターを介して下から上に流れるパイプラインデータは、SQLが常に行っていることです。 残念ながら、Scalaにはまだ実行プランナーがありません。







すべてを自動化します。



手作業で行われることはすべて、おそらく不十分に行われます。 PostgreSQLがどのように機能するか、システムがどのように機能するかを知ることが非常に重要です。









バージョン管理方法



最初に、ストアドプロシージャの使用を開始したとき、プロシージャを変更すると、返されるデータのタイプが変更されました。 古い手順を削除し、新しい手順を展開する必要があります。 これらすべてを1つのトランザクションで行います。 ストアドプロシージャ間に依存関係がある場合、ハンドルを使用してそれらを検索する必要がありました。 完全にドロップして、再び展開します。 私が会社で唯一のDBAだったとき、ストアドプロシージャを更新するこれらの恐ろしいdbdiffを書いただけです。 それから、どうにか座って、セッションでオブジェクトを見つけるためのパスを制御する素晴らしいPostgreSQLのsearch_path機能を使用できるというアイデアを思いつきました。 バージョン15.01のアプリケーションが開き、search_pathを設定すると、検出されるオブジェクトはこのスキームに配置されます。



このストアドプロシージャのセットを使用したアプリケーションのロールアウト中の展開ツールは、目的のバージョンのスキーマを作成し、そこにすべてをロードします。 その後、アプリケーションはそれらを使用します。 新しいバージョンをロールアウトするとどうなりますか？ 展開ツールは、所有しているストアドプロシージャのセット全体で新しいスキームを展開し、新しいバージョンのロールアウトが発生している間、両方のバージョンが実際に機能し、それぞれに独自のストアドプロシージャのセットがあります。 データに関連するものは何もありません。 これらは、データアクセスレイヤーを提供する、いわゆるAPIスキームです。 発生するすべての移行は、ここで発生します。 そのため、移行が発生した場合、以前のバージョンと互換性がなければならず、以前のバージョンはまだ機能しています。



聴衆からの質問 ： 開発者にそのようなフローに取り組むことをどのくらい教えましたか？ 誰もがまさにそれを行い、以前のバージョンと互換性のない移行を行わないようにする方法は？ 移行が本当に正しいこと、新しいAPIが古いデータを正しく読み取り、同時にクラッシュしないことを何らかの方法でさらにテストしますか？



バレンタイン：もちろん、これはテストカバレッジがどれだけうまく機能するか、そしてすべてがテストされるかという問題です。開発者はローカルベースで作業し、その後、統合ステージング、テストステージング、リリースステージング、および実稼働を行います。



聴衆からの質問：API、DBA、または開発者は誰が書いていますか？アクセス権はどのように分割されますか？



バレンタイン：開発者が作成します。 DBAがこれを行うオプションはスケーラブルではありません。一般に、DBAがすべてのAPIを作成しているいくつかの小さな会社を知っています。彼らが私に電話したとき、彼らは私がAPIを書くと思った。しかし、それは不可能です。まず、月に5人を雇いましたが、今では月に40人を雇っています。したがって、開発者がデータベースを操作する方法を学ぶのに時間を費やす方が簡単です。実際には、すべてが物理的にどのように格納および配置されているかを説明すると、非常に簡単です。







API層全体がテストされ、移行が必要ないため、テストは非常に便利です。すべてを自動化できます。









1つの大きな拠点を持つことの良い点は何ですか？



すべてを1つの大きな拠点で行うことができるかどうかを尋ねられたら、答えます。余裕がある限り、1つの大きな拠点にとどまります。ビジネスのすべてのデータをデータベースRAMに配置している場合は、何もする必要はありません。1つのデータベースにとどまります。非常にうまくいきます。分析をすばやく行い、オブジェクト間でデータをリンクできます。さまざまなデータにアクセスするための戦略は簡単です。多数の異なるノードではなく、1台のマシンをサポートすれば十分です。











ただし、RAMよりも多くのデータがある場合に問題が発生します。移行、バックアップ、メンテナンス、アップグレードなど、すべてが遅くなります。基部が大きいほど、頭痛が大きくなります。データを共有します。1つの大きな論理ベースを取得し、多くのPostgreSQLインスタンスに配置します。











何がそんなに良いの？



繰り返しますが、私たちの拠点は小さくなっています。あなたはすぐに彼らと仕事をすることができますが、問題はもちろん、参加することはすでに不可能だということです。アナリストにはさらにツールが必要です。データを操作するには、より多くのツールが必要です。プロセスを自動化するインフラストラクチャの開発に投資することなく、大量のデータを扱うことができると考えている場合、あなたは間違っています。これは不可能です。たくさんのツールを書く必要があります。













私たちには利点がありました。データレイヤーを提供するSproc Wrapperが既にありました。異なるデータベースの使用方法を彼に教えました。



どのように見えますか？パラメーターrunOnAllShards = trueでfindOrders関数を呼び出しています。登録したすべてのシャードでストアドプロシージャを呼び出します。または、CustomerNumberがあり、それがシャードキーであると言います。構成では、使用できる検索戦略（ルックアップ戦略）を指定できます。シャード、シャード認識ID、およびハッシュによる並列検索もサポートされています。シャード上のオブジェクトを見つけるために最も広く使用されている戦略は、いわゆる仮想シャードIDです。







アイデアは本当にシンプルです。パーティション化キーがあります-私が示した階層では、CustomerNumberになります。パーティション化キーは、各オブジェクトについて、オブジェクト間のリンクの境界を定義するキーです。













キーの形成。



主なことは、パーティション化キーが何であるかを理解することです。たとえば、ユーザーがいます。ユーザーには注文があり、あらゆる種類のポジションがこれらの注文に関連付けられています。パーティション化キー-同じユーザーに属するオブジェクトのグループを割り当てる共有キー。この顧客番号、一意のユーザー番号があります。顧客がどこにいるのかを理解するために、階層内の基本オブジェクトであるOrderタイプのすべてのオブジェクトとともにドラッグする必要があります。階層のオブジェクトの親がどこにあるかを常に把握できる必要があります。 IDは技術的なキーであるため、カスタマーIDと言うのは怖いです。私たちは技術的なキーについて話していません。論理キーについて話している。技術的なキーは論理フレームワーク内で一意ではないためです。



通常、顧客IDにUUIDを使用します。お客様番号とお客様IDを区別します。 1つの顧客IDは、システム内の8つのデータベースに8回存在します。そして、顧客番号は常に1です。 MD5でハッシュしますが、もっとうまくやることができます。主なことは、ハッシュが均等に分散されることです。これは、シャーディング戦略のレベルで行われます。実際、アプリケーションがオブジェクトの階層の場所をすばやく見つける必要がある場合はいつでも、ハッシュを実装する必要があります。 Sproc Wrapperを使用した状況では、これはCustomerオブジェクトのシャーディング戦略にすぎません。



このキーのハッシュのサイズによって、仮想シャードの数が決まります。ベースを分割したい場合はどうなりますか？ベースを共有し、ハッシュの最初のビットを使用し始めているというだけです。したがって、データベースが分割されると、データベースがマスターであり、スレーブになったことを示すことができ、そのような瞬間に非常に短いシステムシャットダウンが発生します。現時点では、これはそうです。透過的になるように完全に自動化できます。システムの電源を切り、シャーディング戦略を変更し、これからこことここにアクセスできると言いますが、最初のビットが1であるデータを、既にデータが存在する別のデータベースに書き込みます。この後に行う必要があるのは、このベースから一方に属するすべてのオブジェクトを消去し、もう一方からゼロを参照するすべてのデータを消去することだけです。などなど。非対称に分割することもできます。シャーディング戦略は、ハッシュがゼロから始まる場合、いくつかのシャードがあることを知っているかもしれません。あなたは夢中になる可能性があるため、これはしないことをお勧めします。原則として、これをすでに2回共有しています。







現在、素晴らしいPostgreSQLの機能である論理複製を実験しています。これはマルチマスターです。システムを停止することなく、メジャーバージョンにアップグレードし、すべてをゆっくりと苦痛なく実行する機能です。部分レプリケーション-データベースから1つのテーブルまたはテーブルの一部のみをプ​​ルできます。キャッシュの更新を行います。









現在、RDSが提供する優れた機能を使用して、PostgreSQLをAWSに取り込むために一生懸命取り組んでいます。AWSチームは、STUPSと呼ばれるシステムを開発しました。これにより、Spiloでドッカーイメージをロールアウトし、追跡および監視することができます。Spiloは3つのコマンドの助けを借りて、AWSでPostgreSQLクラスターを展開できます。これは高可用性になり、ノードの1つがオフになったときに自動的に切り替わり、ウィザードを選択します。しかし、これは別の議論のトピックです。