長いロックなしでPostgreSQLテーブルのスキーマを変更します。 ヤンデックス講義

データベーススキーマを変更するために多くの操作が同時に実行されると、サービスは録音時に正しく機能しません。 開発者のVladimir Kolyasinskyは、PostgreSQLでの操作に長期ロックが必要なことと、Yandex.Connectチームがそのような操作中にサービスがほぼ完全に書き込み可能であることを保証する方法について説明しました。 さらに、記述されたプロセスの一部を自動化するように設計されたDjangoのライブラリについても学習します。

負荷が大きく、数千のRPSがあり、数分でのダウンタイムはもちろんのこと、許容範囲を超えています。 ユーザーが気付かないうちに移行を行う必要があります。 そして、そのような荷物があると、朝の4時に起きて、荷物がないときに何かを転がし、再び寝るのは不可能です-荷物は24時間休みます。

-こんばんは！ 私の名前はウラジミールです。Yandexで5年間働いています。 過去2年間、社内サービスと組織向けサービスを開発してきました。

これらのサービスが組織にとって何であるかについて少し。 私たちは長い間、多数の内部サービスを使用してきました：データの保存と交換のためのウィキ、同僚との迅速なコミュニケーションのためのメッセンジャー、作業プロセスを整理するためのトラッカー、内外の調査を実行するためのフォーム、および他の多くのサービス。

しばらく前に、私たちのサービスはクールであり、Yandex内だけでなく、外部の人々にも役立つと判断しました。 ドメインのメールなどの既存の外部サービスを追加して、統合Yandex.Connectプラットフォームにそれらを導入し始めました。



現在、フォームデザイナとWikiを開発しています。 使用されるスタックは、主に2番目と3番目のバージョンでPythonで記述されたサービスです。 Django 1.9-1.11。 データベースとしては、ほとんどがPostgreSQLです。 また、ブローカーとしてMongoDBとSQSを使用したCeleryです。 これはすべてDockerで機能します。

私たちが直面している問題に移りましょう。 サービスは人気があり、毎日数十万人が使用し、データが蓄積され、テーブルがますます増えており、時間の経過とともに、昨日ユーザーに気付かれずに実行されていたデータベーススキーマを変更する多くの操作が、サービスの通常の操作を妨げ始めています。

今日は、そのような状況に対処する方法と、読み取りおよび書き込みサービスの高可用性を実現する方法について説明します。

最初に、PostgreSQLでの操作にテーブルの長いロックが必要なものを考えてみましょう。 ロックとは、テーブルの通常の操作を妨げるあらゆるタイプのロックを意味します-書き込みと読み取りの両方を防ぐ排他的アクセス、または書き込みのみを防ぐ弱いロックレベルです。

次に、このような操作中にロックを回避する方法について説明します。 次に、PostgreSQLの操作が最初に高速で、長いロックを必要としないことについて説明します。 最後に、zero_downtime_migrationsライブラリについて説明します。これは、長いロックを回避するために前述の手法の一部を自動化するために使用します。

長いロックが必要な操作：



インデックスを作成します。 デフォルトでは、テーブル内の読み取り操作はブロックされませんが、すべての書き込み操作はインデックスが作成される間ブロックされます;したがって、サービスは読み取り専用になります。

また、このような操作には、PostgreSQLがテーブル全体を上書きし、この間は読み取りと書き込みの両方でブロックされるため、デフォルト値で新しい列を追加することが含まれます。 さらに、すべてのインデックスが上書きされます。

列のタイプの変更について-同様のことが起こり、プレートも再び上書きされます。 これは、大きなテーブルで長時間かかるだけでなく、短時間でテーブルが占有する空きメモリの最大2倍の量を必要とすることに注意してください。

また、VACUUM FULL操作には、以前の操作と同じレベルのロックが必要です-これはアクセス専用です。 VACUUM FULLは、テーブルに対するすべての読み取りおよび書き込み操作もブロックします。

最後の2つの操作では、一意のプロパティを列に追加し、一般にCONSTRAINTを追加します。 また、データ検証中はロックを必要としますが、内部でテーブルを上書きしないため、以前に検討したものよりもはるかに短い時間で済みます。





インデックスを作成します。 ここでは非常に簡単です。CONCURRENTLYキーワードを使用して作成できます。 違いは何ですか？ この操作は1回ではなくテーブルを数回実行するため、時間がかかります。また、インデックスを変更する可能性のある現在のすべての操作が完了するまで待機します。 また、失敗する場合もあります-たとえば、一意のインデックスを作成するときに一意性の条件の違反が見つかった場合。 その後、インデックスは無効としてマークされ、削除して再作成する必要があります。 REINDEXコマンドは、通常のCREATE INDEXと同じように機能するため、つまり、書き込みのためにテーブルをロックするため、お勧めしません。

インデックスの削除について-バージョン9.3以降では、インデックスの削除中にロ​​ックを回避するためにインデックスを並行して削除することもできますが、一般的には簡単な操作です。



デフォルト値で新しい列を追加してみましょう。 Djangoがこのような操作を実行するなど、このようなコマンドを実行するときに実行される標準操作を次に示します。

テーブルを上書きしないように書き換えるにはどうすればよいですか？ 最初に、1つのトランザクションで、デフォルト値なしで新しい列を追加し、別のリクエストでデフォルト値を追加します。 ここの違いは何ですか？ 既存の列にデフォルト値を追加しても、テーブル内の既存のデータは変更されません。 メタデータのみが変更されます。 つまり、すべての新しい行について、このデフォルト値はすでに保証されています。 このコマンドが実行された時点でテーブルにあったすべての既存の行を更新することは残ります。 大量のデータを長期間ブロックしないように、数千コピーのバッチで行うこと。

すべてのデータを更新した後、NOT NULL列を作成する場合にのみSET NOT NULLを実行します。 作成しない場合は作成しません。 この方法により、この種の変更を行うときにテーブルを上書きすることを回避できます。

このようなコマンドのシーケンスは、テーブルのサイズとインデックスの数に依存するため、通常のコマンドの実行よりも時間がかかります。通常のコマンドは、すべての操作をブロックし、負荷に関係なくテーブルを上書きします。 ただし、操作中はテーブルを読み書きできるため、これはそれほど重要ではありません。 それには長い時間がかかります、あなたはこれに従うだけでいいのです。



列のタイプの変更について。 このアプローチは、デフォルト値を持つ列を追加するのに似ています。 まず、必要な型の別の列を追加してから、元の列のデータを変更して両方の列に一度に書き込むトリガーを追加し、必要なデータ型の新しい列に追加します。 すべての新規エントリについて、これらの列の両方にすぐに移動します。 既存のものをすべて更新する必要があります。 前のスライドのように、私たちが少しずつ行うことは似ていました。

その後、1つのトランザクションに残り、トリガーを削除し、古い列を削除し、古い列の名前を新しいものに変更します。 したがって、同じ結果が得られました。列のタイプを変更しましたが、テーブルのロックは長くありませんでした。



一意の列の追加について。 ロックは作成時に取得されます。 一意のインデックスを作成することでPostgreSQLの一意性が保証されていることがわかっている場合は、回避できます。 CONCURRENTLYを使用して、必要な一意のインデックスを作成できます。 そして、このインデックスを構築した後、このインデックスを使用してCONSTRAINTを作成します。 この後、テーブルの初期インデックスの定義は消え、テーブルの定義が示す結果は、これら2つの操作を実行した後も変わりません。



そして一般的に、CONSTRAINTを追加するとき。 この手法を使用して、データのチェック中のブロックを回避できます。 最初に、キーワードNOT VALIDを指定してCONSTRAINTを追加します。 これは、このCONSTRAINTがテーブル内のすべての行に対して実行されることが保証されていないことを意味します。 しかし同時に、すべての新しい行に対して、このCONSTRAINTはすでに適用されており、実行されない場合は対応する例外がスローされます。

既存のすべての値のみを検証できます。これは、個別のVALIDATE CONSTRAINTコマンドで実行でき、同時にこのコマンドがテーブルの読み取りまたは書き込みのいずれにも干渉しなくなります。 この時間のテーブルが利用可能になります。

最初にPostgreSQLで迅速に動作し、長いロックを必要としない操作：



これらの操作の1つは、デフォルト値と制限なしで列を追加することです。 テーブル自体は変更されないため、メタデータのみが変更されます。 また、SELECTの結果として表示されるすべてのNULL値は、出力で単純に混合されます。

また、メタデータのみが変更されるため、既存のラベルにデフォルト値を追加するのは簡単な操作です。 この情報を入力するのに必要な数ミリ秒の間、テーブルとロックは文字通り取得されます。

また、クイックセットアップ操作はSET NOT NULLです。ここでは、以前に説明したよりも少し時間がかかり、3000万レコードのテーブルにつき約数秒かかります。 重要な場合は、この時間も回避できます。

列の名前を変更し、列の長さを変更しても、列は上書きされません。 PostgreSQLの列、および一般的に多くのエンティティを削除することも簡単な操作です。



NOT NULL列の追加について。 検証中のブロックを回避するには、前述のメソッドを実行します-CHECK（列IS NOT NULL）NOT VALIDに対応するCONSTRAINTを追加し、別のコマンドで検証します。

一般的な違いは、この制限はテーブル定義の列レベルではなくテーブルレベルに存在することです。 もう1つの違いは、パフォーマンスに影響を与える可能性があることです（約1％）。 この場合、サービスの負荷が高い場合、ブロッキングは発生しません。数秒のブロッキングでも、トランザクションの巨大なキューが蓄積され、サービスに問題が発生する可能性があります。



PostgreSQLでのデータの削除は通常、迅速な操作です。データはすぐには削除されず、テーブルの属性で列のみが古くなっているとマークされ、実際にデータは次のバキュームの開始後にのみ削除されます。



ライブラリについて話しましょう。 Django、移行について話している。 一般に、DjangoはWebフレームワークであるPythonのライブラリであり、元々はニュースのようなWebサイトをすばやく作成するために作成されました。それ以来、大幅にアップグレードされています。 Pythonオブジェクトまたはクラスであるかのように、データベース内のレコードやテーブルと通信できるORMシステムがあります。 つまり、各テーブルにはPythonの独自のクラスがあります。 そして、Pythonコードに変更を加える、つまり、テーブルに列などの新しい属性を追加すると、移行の作成プロセス中にDjangoはこれらの変更を認識し、データベース自体にミラー変更を加える移行ファイルを作成して、それらが分岐しないようにします。

ライブラリは、このような移行中にテーブルの長いロックを回避するための前述の手法の一部を自動化するために作成されました。 バージョン1.8から2.1までのDjango、および2.7から3.7までのPythonで動作します。

ライブラリの現在の機能に関して、これはロックなしのデフォルト値、null可能または無効の列を追加しています。これは、CONCURRENTLYインデックスを作成し、クラッシュしたときに再起動する機能です。 標準のDjango実装では、デフォルト値で列を追加すると、テーブルがロックされ、サイズが大きい場合、私の経験では40分のロックになる可能性があります。 テーブルはロックされています。変更がコピーされて行われるまで待ちます。 30分が経過しました-データベースへの接続エラーをキャッチし、移行が失敗し、変更がコミットされず、再度開始する必要があります。再び40分待機し、再びこの時間テーブルをブロックします。

^{_{GitHubリンク}}

ライブラリにより、中断された場所から移行を再開することもできます。 クラッシュして再起動すると、アクションのさまざまなオプションがあるダイアログボックスが表示されます。つまり、データの更新を続行するように指示できます。 これは最長のプロセスであるため、通常はデータの更新です。 移行は、中断したところから続行されます。 このような操作は、テーブルロックを使用する標準の操作よりも時間がかかりますが、同時に、この時点でサービスは操作可能なままです。



接続全体について。 ドキュメントがあります。 つまり、Djangoデータベース設定のエンジンをライブラリのエンジンに置き換える必要があります。 エンジンを使用して接続する場合は、さまざまなミックスインもあります。



作業の例は、デフォルト値を持つ列を追加することです。 ここでは、ブール値（デフォルトではTrue）の列を追加します。 標準のSchemaEditorによって実行される操作は何ですか？ SQLを実行した場合に確認できる操作は移行されます。 これは非常に便利です。まさに移行のタイプによって、Djangoが実際にそこで変更できることは必ずしも明確ではありません。 そして、私たちが期待する操作が完了したかどうか、そして不必要なものや不必要なものがそこに届いているかどうかを確認することは有用です。

SchemaEditorはどのコマンドを実行しますか？ 最初に、1つのトランザクションに新しい列が追加され、デフォルト値が追加されます。 次に、そのような更新がゼロを更新したことを返すまで、データは更新されます。

次に、列にSET NOT NULLが設定され、デフォルト値が削除され、Djangoの動作が繰り返されます。Djangoは、データベースではなくコードの独自のロジックレベルでデフォルト値を保存します。

ここでは、一般的に、成長する余地もあります。 たとえば、補助索引を作成して、表全体の更新に近づくと、NULL値を持つそのような行をすばやく見つけることができます。



また、移行を開始したときの更新時間の最大IDを修正して、IDによってまだ更新されていない値をすばやく見つけることができます。

一般的に、ライブラリは開発中であり、プールリクエストを受け付けています。 誰も気にしない-参加。

DBの成長に伴い、移行には速度低下の避けられない特性があることに注意する価値があります。 テーブルがどのロックを取得するかを追跡し、SQL移行を実行して、適用されている操作を確認する必要があります。 私たちの側では、Yandex.Connectで、機能が許す限りこのライブラリを使用します。 そして、彼らがそれを許可していない場合、私たちは自分自身で、Djangoの偽の移行を行い、SQLクエリを実行します。

したがって、読み取りおよび書き込みサービスの高可用性を実現します。 負荷が大きく、数千のRPSがあり、数分でのダウンタイムはもちろんのこと、許容範囲を超えています。 ユーザーが気付かないうちに移行を行う必要があります。 そして、そのような荷物があると、朝の4時に起きて、荷物がないときに何かを転がして、再び寝るのは不可能です-荷物は24時間動きます。

PostgreSQLでの高速操作でも、PostgreSQLでのロックキューの動作により、サービスの速度低下やエラーが発生する可能性があることに注意してください。

数ミリ秒であっても、排他的アクセスが必要な操作が開始されたと想像してください。 このような操作の例は、デフォルト値なしで列を追加することです。 別のトランザクションでの起動時に、他のいくつかの長い操作（たとえば、集計付きのSELECT）があると想像してください。 この場合、操作は彼女のためにキューに入れられます。 これは、アクセス排他が他のすべてのタイプのロックと競合するために発生します。

列を追加する操作がロックを待機している間、他のすべての列はその列に並ぶことになり、完了するまで実行されません。 同時に、実行中の操作-集約を伴うSELECT-は他の操作と競合しない可能性があり、列の作成用でない場合は、キュー内に立つことはありませんが、並行して実行されます。

この状況は、サービスに大きな問題を引き起こす可能性があります。 したがって、ALTER TABLEまたはアクセス排他ロックを必要とするその他の操作を開始する前に、長いクエリが現時点でデータベースに送信されないように注意する必要があります。 または、非常に小さなログタイムアウトを挿入することもできます。 その後、すぐにロックを取得できない場合、操作は失敗します。 ただテーブルを再起動するだけで、テーブルを長時間ロックすることはできませんが、操作はロック許可の付与を待機します。 それだけです、ありがとう。