建築宇宙飛行士向けのSQLAlchemyアクセラレーション

Habr、これはモスクワで開催されたMoscow Python Conf ++ 2018カンファレンスでのソフトウェアエンジニアAlexei Starkovによるレポートです。 投稿の最後のビデオ。

みなさんこんにちは！ 私の名前はアレクセイ・スターコフです。これは私です。私の最高の年に、私は工場で働いています。
現在、Qrator Labsで働いています。 基本的に、私は一生、CとC ++を勉強しました-Alexandrescu、The Gang of Four、SOLIDの原則が大好きです-それだけです。 私は建築の宇宙飛行士になります。 私は気に入っているので、ここ数年Pythonを書いています。

実際、「建築の宇宙飛行士」とは誰ですか？ ジョエル・スポルスキーとこの言葉に初めて会ったとき、あなたはおそらくそれを読んだでしょう。 彼は、「宇宙飛行士」を完璧なアーキテクチャを構築したい、抽象化、抽象化、抽象化にかける人々が、ますます一般的になっていると説明しています。 最終的に、これらのレベルはすべての可能なプログラムを説明するほど高くなりますが、実際的な問題は解決しません。 この瞬間、「宇宙飛行士」（この用語が引用符で囲まれるのはこれが最後です）が空中でなくなり、彼は死にます。

また、建築空間の探索に向かう傾向もありますが、このレポートでは、それがどのように私を苦しめ、必要なパフォーマンスを備えたシステムを構築できなかったかについて少しお話しします。 主なものは、私がそれをどのように克服したかです。

私のレポートの要約：だった/だった。



数千および数百万回の増加。 このスライドを作成したとき、私が考えていたのは「方法」だけでした。



どこでそんなに激しく台無しにできますか？ あなたは私のように台無しにしたくない場合-読んでください。



構成システムについてお話します。 構成システムは、Qrator Labsの内部ツールであり、フィルタリングネットワークであるSoftware Defined Network（SDN）の構成を保存します。 コンポーネント間の構成の同期とそのステータスの監視に取り組んでいます。



要するに、何で構成されているのでしょうか？ ネットワーク全体の構成のスナップショットを保存するデータベースがあり、それに来るコマンドを処理し、何らかの形で構成を変更するサーバーがあります。

技術管理者とクライアントがこのサーバーにアクセスし、エンドポイントAPI、REST API、JSON RPCなどを介してコンソールを使用してサーバーにコマンドを発行し、その結果、構成が変更されます。

チームは非常に単純な場合もあれば、より複雑な場合もあります。 次に、SDNを構成するレシーバーの特定のセットがあり、サーバーはこれらのレシーバーに構成をプッシュします。 とても簡単に聞こえます。 基本的に、この部分について説明します。



データベースと錬金術に関係しているのは彼女だからです。



このシステムの特徴は何ですか？ それはかなり小さい-平凡です。 このデータベースには、数十万から数百万ものエンティティが保存されています。 特徴は、エンティティ間の関係のグラフが非常に複雑であることです。 エンティティ間にいくつかの継承階層があり、包含があり、それらの間には単純に依存関係があります。 これらのすべての制限はビジネスロジックによって決定され、それらに従う必要があります。

書き込み要求と読み取り要求の比率は約15：1です。 ここで明らかなように、構成を変更するためのコマンドがたくさんあり、特定の長期間に一度、エンドポイントに構成をプッシュします。

MySQLは社内で使用されます-当社の他の製品でも使用できます。このデータベースには非常に真剣な専門知識があり、データスキームの構築、クエリの設計、その他すべての作業を行うことができます。 そのため、MySQLをユニバーサルリレーショナルデータベースとして採用しました。



このシステムを設計した後、問題は何でしたか？ 1つのコマンドの実行には、チームの複雑さに応じて1〜30秒かかりました。 したがって、実行の遅延は5分に達しました。 1つのチームが到着しました-30秒、2番目など、5分の遅延。

構成の適用の遅延は最大10分です。 これでは十分ではなく、最適化が必要であると判断されました。



まず、最適化を実行する前に、調査を実施し、実際に何が問題なのかを調べる必要があります。



判明したように、調査に最も重要なコンポーネントがありませんでした-テレメトリーがありませんでした。 したがって、何らかのシステムを設計する場合は、最初に設計段階でテレメトリを導入します。 システムが最初は小さくても、それからもう少し、さらにはもっと小さくても、最終的には誰もがトラックを見る必要がある状況になりますが、テレメトリはありません。



テレメトリーがない場合、次に何ができますか？ ログを分析できます。 ここでは、かなり単純なスクリプトがログを調べて、そのようなテーブルに変換し、最速、最低、平均のコマンド実行時間を示します。 ここから始めて、ギャグがある場所、つまり実行するのに時間がかかるチーム、速くなるチームを確認しています。



唯一注意すべきことは、ログを分析するとき、サーバーでのこれらのコマンドの実行時間のみを考慮することです。 これは最初の段階です-t2としてマークされています。 t1は、クライアントがコマンドの実行時間を確認する方法です。つまり、キューに入る、待機する、サーバーでの実行です。 この時間は長くなるため、時間t2を最適化し、時間t1を使用して目標に到達したかどうかを判断します。

t1は、パフォーマンスの品質指標です。



したがって、これがすべてのチームのプロファイリング方法です。つまり、サーバーからログを取得し、スクリプトを介して実行し、最も低速に動作するコンポーネントを探して明らかにしました。 サーバーは非常にモジュール式に構築されており、コマンドごとに個別のコンポーネントが担当します。コンポーネントを個別にプロファイルし、それらのベンチマークを作成できます。 そのため、ここにクラスがありました-作成した問題のあるコンポーネントごとに、code_under_test（）でコンポーネントの戦闘使用を示すアクティビティを行いました。 そして、2つの方法がありました：プロファイル（）とベンチ（）。 最初はcProfileを呼び出し、何回呼び出されたか、ボトルネックはどこにあるかを示します。

bench（）が数回実行され、異なるメトリックが考慮されました-これがパフォーマンスの評価方法です。

しかし、これは問題ではないことが判明しました！



主な問題は、データベースへのクエリの数でした。 たくさんのリクエストがありましたが、なぜそんなにたくさんあったのかを理解するために、すべてがどのように構成されているかを見てみましょう。



受信者を表す簡単な回路の一部が、Recieverクラスの形式で表示されます。 彼らはいくつかのグループに統合されています-受信者グループ。 また、それに応じて、いくつかの構成プレーンがあります。構成のスライスは、このレシーバーの1つの「役割」を担当する構成のサブセットです。 たとえば、ルーティングの場合-ルーティングプレーン。 レシーバーのあるプレーンは任意の順序で接続できます-つまり、これは多対多の関係です。

これは、例をさらに説明するためにここで提示する大きな概要の一部です。

すべての建築の宇宙飛行士は、他の誰かのAPIを見たときに何をしたいのでしょうか？ 彼は、このAPIを削除できるようにするために、それを非表示にし、抽象化し、インターフェースを作成するか、むしろ非表示にしたいと考えています。



したがって、錬金術の「ダーティな」APIがあります。実際には、マッパーと「純粋な」クラスがあります。レシーバには、いくつかの設定が保存され、メソッドがあります：load（）、save（）、delete（） そして、それに関連する他のすべてのクラス。 何らかの方法で相互に接続されたPythonオブジェクトのグラフを取得します-それぞれにload（）、save（）、delete（）メソッドがあり、錬金マッパーを参照し、APIを呼び出します。



ここでの実装は非常に簡単です。 loadメソッドがあり、データベースへのクエリを作成し、受け取ったオブジェクトごとに独自のPythonオブジェクトを作成します。 反対の操作を行うsaveメソッドがあります-主キーを使用してデータベースにオブジェクトがあるかどうかを調べ、ない場合は作成し、追加してから、このオブジェクトの状態を保存します。 主キーの削除は、データベースからオブジェクトを受信して​​削除します。



主な問題はすぐに明らかになります-これはマッピングです。 最初にPythonオブジェクトからマッパーまで一度実行し、次にマッパーからベースまで実行します。 追加のマッピングは1つまたは2つの課題であり、まだそれほど怖くないかもしれません。 主な問題は手動同期でした。 「クリーンな」インターフェースの2つのオブジェクトがあり、そのうちの1つが属性を変更します。もう1つの属性が変更されたことを確認するにはどうすればよいですか？ まさか。 変更をデータベースにマージし、別のオブジェクトの属性を取得する必要があります。 もちろん、オブジェクトが同じコンテキストに存在することがわかっている場合は、何らかの方法でこれを追跡できます。 しかし、異なる場所に2つのセッションがある場合-ベースのみを使用するか、メモリ内のベースをブロックしますが、これは行いませんでした。

このロード/保存/削除は、錬金術の内部を完全に複製する別のマッパーであり、よく記述され、テストされています。 このツールは何年も前のものであり、インターネット上で多くの助けがあり、それを複製することもあまり良くありません。

右上隅のアイコンを参照してください？ それで、「純度」のために何かが行われるスライドに印を付け、建築の天文学のために、抽象化のレベルを上げます。 つまり、このアイコンのないスライドは実用的で退屈で面白く、読むことができません。

多くのクエリが遅い場合の対処方法。 いくつ？ 実はたくさん。 継承チェーンを想像してください。1つのオブジェクト、1つの親、もう1つの親があります。 子オブジェクトを同期します-これを行うには、まず親を同期する必要があります。 親を同期するには、その親を同期する必要があります。 さて、全員が同期されました。 実際、グラフの作成方法にもよりますが、これらすべてのオブジェクトを100回同期して、つまり多数のリクエストを同期させることができました。



私たちは何をしましたか？ すべてのビジネスロジックを取得し、マッパーに貼り付けました。 ここの他のすべてのオブジェクトもマッパーとマージされ、API全体（データ抽象化レイヤー全体）がダーティであることが判明しました。



Pythonでの表示は次のとおりです。マッパーには何らかのビジネスロジックがあり、このプレートの宣言的な説明がすぐにあります。 列がリストされます、関係。 ここにそのようなクラスがあります。



もちろん、宇宙飛行士の観点から見ると、汚れたAPIは欠点です。 ベースの宣言的記述におけるビジネスロジック。 スキームはビジネスロジックと混在しています。 ふう。 glyい。

回路の説明は乱雑です。 これは実際には問題です。ビジネスロジックに2行がなく、ボリュームが大きい場合、このクラスでは、特定の説明に到達するために非常に長い時間スクロールまたは検索する必要があります。 それ以前は、すべてが美しいものでした。ある場所では、ベースの説明、宣言、スキームの説明、別の場所ではビジネスロジックです。 そして、回路が乱雑になります。

しかし、一方で、錬金術のメカニズムはすぐに得られます。作業単位。どのオブジェクトが汚れているか、どのリレーを更新する必要があるかを追跡できます。 関連するコレクションが満たされていることを確認せずに、データベース内の追加の質問を取り除くことができる関係を取得します。 そして、私たちを最も助けてくれたアイデンティティマップ。 アイデンティティマップは、2つのPythonオブジェクトが同じ主キーを持つ場合、同じPythonオブジェクトになるようにします。

したがって、すぐに複雑さを線形に減らしました。



これらは中間結果です。 パフォーマンスはすぐに10倍になり、データベースへのクエリの数は約40〜80倍に減少し、RPSは1〜5に増加しました。 いいですね しかし、APIは汚れています。 どうする



ミックスイン。 ビジネスロジックを使用し、再びマッパーから削除しますが、再度マッピングが行われないように、錬金術内部のマッパーをmixinから継承します。 なぜ逆にしないのですか？ これは錬金術では機能しません、彼女は誓うと言います：「1つのタブレットを参照する2つの異なるクラスがあり、多形性はありません-ここから行きます。」 そして-それは可能です。

したがって、Mixinから継承され、すべてのビジネスロジックを受け取る宣言的な記述がマッパーにあります。 とても快適です。 そして、残りのクラスはまったく同じです。 それは思えます-クール、すべてがきれいです。 ただし、注意点が1つあります。接続とリレーは錬金術の中に残り、たとえば、中間プレートのセカンダリテーブルを介して結合すると、このプレートのマッパーがクライアントコードに何らかの形で存在することになります。

錬金術は、私にこれと戦う機会を与えなかったら、それほど良い、有名なフレームワークではなかったでしょう。



ミックスインはどのように見えますか。 彼は、ビジネスロジック、マッパーを個別に、プレートの宣言的な説明を持っています。 接続は錬金術内に残りますが、ビジネスロジックは別です。

一般的なアウトラインはどのように見えますか？



すべての宣言クラスが収集されるスキームを持つファイルがあります-schema.pyと呼びましょう。 また、ビジネスロジックには個別にエンティティがあります。 また、これらのエンティティはスキーマファイル内で継承されます。各エンティティに個別のクラスを作成し、スキーマで継承します。 したがって、ビジネスロジックは1つのヒープにあり、スキームは別のヒープにあり、独立して変更できます。



改善の例として、レシーバー（Receiverテーブル）と構成のスライス（ReceiverPlanesテーブル）の2つのラベルの単純なスキームを検討します。 構成の多対1スライスは、レシーバラベルに関連付けられています。 特に複雑なことはありません。

錬金術の「汚い」インターフェース内に関係を隠すために、関係とコレクションを使用します。



これにより、マッパーをクライアントコードから隠すことができます。



特に、非常に便利な2つのコレクションはassociation_proxyとattribute_mapped_collectionです。 それらを一緒に使用します。 錬金術における古典的な関係の仕組み：関係があります-これは特定のコレクション、リスト、マッパーです。 マッパーは遠端の関係オブジェクトです。 Attribute_mapped_collectionを使用すると、このリストを辞書、マッパーの属性の一部となるキー、値はマッパー自体に置き換えることができます。

これが最初のステップです。



2番目のステップでは、この関係に対してassociation_proxyを実行します。 マッパーをコレクションに渡すのではなく、後でマッパーのReceiverPlanesを初期化するために使用される値を渡すことができます。

ここにキーと値を渡すラムダがあります。 キーは構成スライスの名前に変わり、値は構成スライスの値に変わります。 その結果、クライアントコードでは、すべてが次のようになります。



ある種のディクテーションをある種の辞書に入れるだけです。 マッパーも錬金術もデータベースもありません。

確かに、落とし穴があります。



同じキーに異なる値または1つの値を2回割り当てると、そのようなセット項目ごとにlambdaが呼び出され、オブジェクトが作成されます-マッパー。 また、スキームの構造に応じて、「定数の単なる違反」から予測不可能な結果まで、さまざまな結果につながる可能性があります。 たとえば、コレクションからオブジェクトを削除しましたが、オブジェクトはまだ残っています。1つだけ削除しました。 私が最初に始めたとき、私はそのようなことで多くの時間を殺しました。

少し暗黙的な同期。 Association_proxyとattribute_mapped_collectionは少し遅れる場合があります。マッパーオブジェクトを作成すると、データベースに追加されますが、コレクション属性にはまだ存在しません。 このセッションで属性の有効期限が切れた場合にのみ表示されます。 有効期限が切れると、データベースとの新しい同期が発生し、そこに到達します。

これを克服するために、私たちは独自の自己記述コレクションを使用しました。 これは錬金術でさえありません-これをすべて克服するためにあなた自身のコレクションを作成することができます。



さらにコードがあり、最も重要な領域が強調表示されています。 ミュート可能なマッピングから継承する特定のコレクションがあります。これはキーで値を変更できる辞書です。 そして、_get_plane_objメソッドがあります-構成スライスオブジェクトを取得します。

ここでは、単純なことを行います。名前、主キーによって取得し、そうでない場合は、このオブジェクトを作成して返します。

次に、2つのメソッド__setitem__と__getitem__のみを再定義します
__setitem__では、これらのオブジェクトをコレクション内の関係に配置します。 唯一のことは、最後に値を割り当てることです。 したがって、association_proxyと同じメカニズムを実装します。値dictを渡し、対応する属性に割り当てます。

__getitem__は逆の操作を行います。 キーによってリレーからオブジェクトを受け取り、その属性を返します。 ここにも小さな落とし穴があります-マッピング内でコレクションをキャッシュすると、少し同期が取れなくなる可能性があります。 コレクションの属性が錬金術で期限切れになると、コレクションは期限切れ後に別のコレクションに置き換えられるためです。 したがって、古いコレクションへの参照を保持し、古いコレクションの有効期限が切れて新しいコレクションがすでに出現していることを知ることはできません。 したがって、最後の部分では、錬金術のインスタンスに直接移動し、再び__getattr__を介してコレクションを取得し、それを使用して__getitem__を実行します。 つまり、ここでPlanesコレクションをキャッシュすることはできません。



このコレクションは、ミックスインでどのように平手打ちされますか？ いつものように-コレクションの属性を開始します。 唯一の興味深い場所は、データベースからインスタンスをロードするときに__init__メソッドが呼び出されないことです。 すべての属性は事後的に置換されます。

Alchemyは標準の再構築デコレータを提供します。このデコレータを使用すると、データベースからオブジェクトをロードした後にメソッドが呼び出されるようにマークできます。 そして、起動時にコレクションを初期化する必要があります。 Selfはまさにそのインスタンスです。 使用方法は、前の例とまったく同じです。



しかし、このスキームでは、データベースの耳はまだ見えています-これが設定です。 どのタイプの構成ですか？ それはvarcharですか、それともblobですか？ 実際、クライアントは興味がありません。 彼は自分のレベルの抽象的なエンティティで作業する必要があります。 このために、錬金術は型の装飾を提供します。



簡単な例。 データベースは、IPAddressをvarcharとして保存します。錬金術の一部であるTypeDecoratorクラスを使用します。これは、まず、このタイプに使用する基になるデータベースタイプを指定し、次に、値をデータベースタイプに変換するprocess_bind_paramと値を指定するときにprocess_result_valueを定義しますデータベースのタイプから、Pythonオブジェクトに変換します。

アドレスからの属性は、PythonタイプIPAddressを取ります。そして、このタイプのメソッドを呼び出すことも、このタイプのオブジェクトをそれに割り当てることもでき、すべてが機能します。そして、それはデータベースに保存されます...何が保存されているのかわかりませんが、varchar（45）ですが、その行を置き換えるとblobが保存されます。または、一部のネイティブタイプがIPアドレスをサポートしている場合は、それを使用できます。

クライアントコードはこれに依存せず、書き換える必要はありません。



もう1つの興味深い点は、バージョンがあることです。オブジェクトを変更するとすぐに、バージョンがすぐに増加するようにします。バージョンカウンターがあり、オブジェクトを変更しました。変更され、バージョンが増加しました。忘れないようにこれを自動的に行います。



このために、イベントを使用しました。イベントは、マッパーの人生のさまざまな段階で発生するイベントであり、属性が変化したときにトリガーできます。たとえば、「作成済み」、「データベースに保存済み」、「データベースからロード済み」、「削除済み」また、セッションレベルのイベントで、SQLコードがデータベースに発行される前、コミット前、コミット後、ロールバック後。

Alchemyでは、これらすべてのイベントにハンドラーを割り当てることができますが、同じイベントに対してハンドラーが実行される順序は保証されません。つまり、それは具体的ですが、どれがわかっているのかはわかりません。したがって、実行順序が重要な場合は、登録メカニズムを実行する必要があります。



以下に例を示します。 ここでは3つのイベントが使用されます。
on_before_flush-SQLコードがデータベースに送信される前に、このセッションで錬金術がダーティとマークしたすべてのオブジェクトを調べ、このオブジェクトが変更されているかどうかを確認します。錬金術がすでにすべてをマークしているのに、なぜこれが必要なのですか？ Alchemyは、何らかの属性が変更されるとすぐにオブジェクトをダーティマークします。この属性に同じ値を割り当てた場合、ダーティとしてマークされます。このためのis_modifiedセッションメソッドがあります-内部で使用されるため、描画しませんでした。さらに、セマンティクスの観点から、ビジネスロジックの観点から、属性が変更された場合でも、オブジェクトは変更されないままです。たとえば、2つの要素が交換された特定のリストがあります。錬金術の観点から、属性が変更されましたが、ビジネスロジックにとっては、たとえばある種。

そして最後に、各オブジェクトに固有の別のメソッドを呼び出して、オブジェクトが変更されているかどうかを理解します。そして、私たちが自分で立ち上げたセッションに関連付けられた特定の変数にそれらを追加します-これは、このオブジェクトを追加するdirty_instances変数です。

次のイベントは、コミットの前に発生します-before_commit。ここにも小さな落とし穴があります：トランザクション全体で単一のフラッシュがない場合、フラッシュはコミットの前に呼び出されます-私の場合、ハンドラはフラッシュの前にコミットの前に呼び出されました。

ご覧のとおり、前の段落で行ったことは役に立たない可能性があり、session.dirty_instancesは空になります。そのため、ハンドラー内で再度フラッシュを実行し、すべてのハンドラーがフラッシュの前に呼び出され、バージョンを1ずつインクリメントするだけです。

after_commit、after_soft_rollback-コミット後、次回の超過が発生しないようにクリーンアップします。

したがって、このinstall_handlerメソッドは3つのイベントのハンドラーを一度にインストールします。これはクラスのイベントであるため、クラスとして、ここでセッションを渡します。



よくここに。私たちが達成したことを思い出してください-複雑で大規模なチームの場合は30〜40秒の速度。すべてではありませんが、RPSで確認できるように、1秒で完了したものもあれば、200ミリ秒で完了したものもあります。データベースクエリは数百にカウントされ始めました。



結果は、かなりバランスの取れたシステムです。ただし、警告が1つありました。私たちのリクエストのいくつかは、バッチで排出されます。つまり、約30のリクエストが到着し、それぞれがそのようなものです！ （話者は親指を示します）

一度に1秒ずつ処理すると、キュー内の最後の要求は30秒間機能します。最初のもの、2番目のもの、など。



したがって、まだ加速する必要があります。どうする？

実際、錬金術には2つの部分があります。 1つ目は、SQLAlchemy Coreと呼ばれるsqlデータベースの抽象化です。 2番目はORMです。これは、リレーショナルデータベースとオブジェクト表現の間の実際のマッピングです。したがって、錬金術のコアはsqlとほぼ1対1で一致します。後者を知っていれば、コアに問題はありません。 SQLがわからない場合は、SQLを学んでください。
さらに、コアは最小のオーバーヘッドを表します。ポンピングは実質的にありません。クエリはクエリジェネレータを使用して生成され、実行されます。 dbapiのオーバーヘッドは最小限です。

どんな複雑なリクエストでも、どんなタイプでも作成でき、タスクに合わせて最適化できます。つまり、一般的な場合、データベーススキーマの構築方法をORMが気にしない場合、テーブルの説明がいくつかある場合、クエリを生成します。この場合、たとえば、ここから、別の場所から、ここから選択するのが最適であることを知りませんフィルターを適用すると、別のフィルターがあり、ここでタスクのリクエストを作成できます。

欠点は、手動での同期に戻ったことです。すべてのイベント、リレー-コア内のすべてが機能しません。私たちは選択を行い、オブジェクトが来て、それらを使って何かをしてから、更新、挿入...あなたは自分の手でバージョンを増やし、定数をチェックする必要があります。コアでは、これらすべてを高レベルで便利に行うことはできません。

まあ、私たちは最初の日は生きていません。



シンプルなユースケース。各マッパーには、コアで使用される__table__オブジェクトが内部的に含まれています。次に、通常の選択を行い、列をリストし、2つのプレートを結合し、左右を示し、どの条件で結合するかを示します。次に、この生成されたリクエストをセッションに送り、反復可能なオブジェクトを返します。タップ可能なオブジェクトには、列名と番号の両方でインデックスが付けられます。番号は、選択にリストされている順序に対応しています。



ずっと良くなりました。最悪の場合のパフォーマンスは2〜4秒に低下し、最も複雑で長い要求には14個のコマンドとRPS 10〜15が含まれていました。しっかりしています。



結論として私が言いたいこと。
必要のない場所ではエンティティを作成しないでください。準備が整っている場所でエンティティを台無しにしないでください。
SQLA ORMを使用する-これは非常に便利なツールで、イベントを高レベルで追跡し、データベースに関連付けられたさまざまなイベントに応答し、錬金術の耳をすべて隠すことができます。
他のすべてが失敗した場合、パフォーマンスは十分ではありません-SQLA Coreを使用してください。これは、データベースに対するリレーショナル抽象化を提供するため、純粋な生SQLを使用するよりも優れています。パラメータを自動的にエスケープし、バインダーを正しく実行します。どのデータベースがその下にあるかは関係ありません。変更することができ、Coreはさまざまな方言をサポートしています。とても便利です。

今日はそれだけを伝えたかったのです。