Slow SQL ガバナンスの実践と実装結果の共有 | JD Logistics 技術チーム

1. ガバナンスの背景

データベース システムのパフォーマンスの問題は、アプリケーションのパフォーマンスやユーザー エクスペリエンスに悪影響を与える可能性があります。クエリが遅いと、アプリケーションの応答の遅さ、リクエストの蓄積、システム負荷の増加などの問題が発生し、さらにはシステムのクラッシュや使用不能を引き起こす可能性があります。遅い SQL の管理は、データベース システムで実行が遅い SQL クエリを最適化および改善する上で重要なタスクです。

しかし、当初のガバナンスリズムは、大規模な昇進の準備期間に緊急ガバナンスに人員を投入することが一般的であり、日常的に遅いSQLにはあまり注目せず、R&Dチームがガバナンスを始めたくても、詳細な審査が必要でした。インスタンス下の SQL は煩雑で、傾向が不明確で、システムやデジタル ガバナンス ソリューションが不足していました。

そこで、システムの安定性を確保し、潜在的な遅い SQL に起因する緊急事故を防止するために、特別な遅い SQL 正規化準備プロジェクトが立ち上げられ、以下では主に特別プロジェクトの実践と実装について説明します。

2. ステージ企画

1.0段階

目標: [正規化されたガバナンス メカニズムを形成し、遅い SQL を解決する効率に重点を置く]

遅い SQL 管理の習慣を、大規模なプロモーションの準備中の元の管理から変更し、日次ディメンションで生成される遅い SQL を毎日フォローアップし、隔週ディメンション管理の有効性に注意を払います。

注目すべき指標:

期限超過率= 期限超過の作業指示書の数 (現在の四半期に作成されたタスク) / 合計金額 (現在の四半期に作成されたタスク) 注: 作業指示書が 14 日を超えて完了しない場合、作業指示書は期限超過とみなされます。期限を過ぎたかどうかは、最初の完了時刻に基づいて判断され、期限までに完了しなかった場合は期限を過ぎたものとみなされ、期限までに完了したが、再開後に期限を過ぎて完了した場合は、期限超過とは見なされず、再オープンされたものとしてカウントされます。14 日を超えて保留されている場合は、期限超過としてカウントされます。

再開率= 作業指示書が再開された数 (現在の四半期に作成されたタスク。タスクが 5 回再開された場合、5 として記録される) / 合計金額 (現在の四半期に作成されたタスク)

2.0ステージ

目標: [遅い SQL による過去の負債を完全に撲滅し、0.9 秒を超える定期クリアランスを達成する]

1.0 フェーズの研究開発チームが遅い SQL を秩序正しく段階的に管理した後、一部の遅い SQL データは初期段階で効果的に解決されましたが、システムの安定性に影響を与える過去の負債がまだ残っています。フェーズ 2.0 では、隔週の段階的なクリアリングが必要です。

注目すべき指標:

P0 プッシュされた作業指示の数= 今週のプッシュ時間が 0.9 秒を超えるタスクの総数 注: 宣言レベルの区分、

P0 の実行時間が 0.9 秒を超え、しきい値に 10 回到達しました

P1 の実行時間が 0.9 秒を超えていますが、しきい値に 10 回到達していません

P2 の実行時間はインデックスなしで 0.9 秒未満で、しきい値に 10 回到達します

P3 の実行時間はインデックス作成なしで 0.9 秒未満ですが、しきい値に 10 回到達しません

P0 作業指示書の在庫数= プッシュ時間が 0.9 秒を超え、ステータスが「はい」または「いいえ」で今週中に解決されたタスクの総数

解決率= 0.9 秒より大きく、プッシュ時間のタスク ステータスが解決されている / 週のプッシュ時間のタスクの総数

3.0段階

目標: [システムのパフォーマンス指標を改善し、低速 SQL のしきい値を段階的に削減する]

主要な隠れた危険を 0.9 秒かけて段階的に除去した後、遅い SQL の作業指示は徐々に調整され、遅い SQL 定義のしきい値はラダー ディメンションに従って徐々に引き下げられ、新しい遅い SQL は隔週のディメンションに従ってクリアされます。

注目すべき指標:

P0 プッシュされた作業指示の数= 今週のプッシュ時間が 0.9 秒を超えるタスクの総数 注: 宣言レベルの区分、

P0 の実行時間が 0.9 秒を超えています

P1 の実行時間は 0.9 秒以下、0.7 秒以上です

P2 実行時間は 0.7 秒以下、0.5 秒以上です

P3 の実行時間はインデックスなしで 0.5 秒以下

P1 作業指示のプッシュ数= 今週のプッシュ時間が 0.9 秒以下、0.7 秒を超えるタスクの合計数

P2 作業指示のプッシュ数= 今週のプッシュ時間が 0.7 秒以下、0.5 秒を超えるタスクの総数

ストック数= 今週のプッシュ時間内でステータスが未解決のタスクの総数

解決率= プッシュ時のタスクの解決ステータス / 今週のプッシュ時のタスクの総数

4.0段階

目標:【遅いSQLを事前に防止し、データベースの動作仕様を実装する】

期待される目標は、過去の負債を完全に解決してシステム パフォーマンス指標を改善し、新たな遅い SQL を防ぐためのデータベース操作仕様を実装し、新たな遅い SQL に引き続き注意を払い、新たな追加の数を明確に制御することです。

注目すべき指標:

新しい作業指示の数= 今週プッシュされた、存在しないフィンガープリント ID を持つタスクの総数

ストック数= 今週のプッシュ時間内でステータスが未解決のタスクの総数

解決率= プッシュ時のタスクの解決ステータス / 今週のプッシュ時のタスクの総数

3. 実施計画

①データ準備

しきい値の定義

二次部門の業務と組み合わせると、毎日 SQL を収集するためのクエリ時間は T-1 日になります。実行時間が >0.9 秒または <0.9 秒で、bi_cx および wlcx の小数を除外した後でインデックスが実行計画に含まれていない場合(マスターとスレーブを区別せずに)、同じフィンガープリントを持つ遅い SQL はすべて、既存の危険な遅い SQL として識別されます。

レベルを明確にする

ガバナンスのさまざまな段階で、遅い SQL は P0 ~ P3 の順に優先され、研究開発は高いものから低いものへと促進され、さまざまなソリューションの適時性に従って評価されます。同時に、低速 SQL 管理タスクをトリガーしたデータベース IP/ドメイン名/ライブラリ名/実行時間/実行計画などの補助診断情報が提供されます。

並べ替えとフィルタリング

インスタンス情報、データベース名、属性のあるシステム、属性のある製品ライン、クエリ時間、集計フィンガープリントなどに基づいて分類し、遅い SQL 問題の同じ原因を簡単に分類します。

②作業指示の進行

作業指示の流れ

ビジネスラインに応じて分割し、各ラインの作業指示のインターフェイス担当者を明確にし、遅い SQL 作業指示をインターフェイス担当者に一律に割り当てます。インターフェイス担当者はシステムに従って遅い SQL 作業指示をグループ内の学生に配布し、解決します。一つ。

ソリューション

DBA などから提供されるソリューションのアイデアから学び、同時にチーム内で実装されたソリューションを要約して、遅い SQL の迅速な解決を促進します。

③傾向分析

チャート作成

各ステージの指標データに基づいて、遅い SQL のソリューション傾向グラフが作成され、チームが各インスタンスの遅い SQL の詳細を明確に確認できるようになり、複数のディメンションのフィルタリングがサポートされると同時に、ソリューションの傾向や既存の数量の表示もサポートされます。 、など時間次元に応じて。

通海のレビュー

毎週の特別なミーティングの形式で、研究開発チームの処理リズムと進捗状況が同期され、継続的な進歩が保証されます。

④工程追跡

フェーズ 1.0 は有効性の解決に焦点を当てます

フェーズ 2.0 では、0.9 秒を超えるガバナンスに焦点を当て、過去の負債を一掃します

P0 レベルの SQL 解決策のフォローアップ:

既存の歴史的負債の清算:

月ごとの低速 SQL ボリュームの傾向

4. 実施結果

【システム保証】

遅い SQL を段階的に管理した結果、チームは529 件の閉鎖までに合計831 件の遅い SQL を解決し、今年の 618 件の準備中に過去の負債の定期的な清算を完了しました。**遅い SQL 管理インデックスの追加とコードの最適化を毎日完了し、問題に焦点を当て、大規模なプロモーション中に未使用のインデックスを分析して、準備に漏れがないようにします。

また、システムの安定性も直接保証されており、過去 6 か月間、SQL の遅さに起因するオンラインの問題は発生していません。

【プロジェクト降水量】

低速 SQL ガバナンスが特別なプロジェクトとして研究開発の日常業務に組み込まれているため、チームはまず、新たな低速 SQL の生成を回避するために、データベース開発仕様である JD グループ データベース開発仕様-V1.0-公開を実装しました。 SQL を分析して迅速に見つけて効率的に解決する方法、そしてチームはガバナンス ソリューションも出力します。

5. まとめ

特別プロジェクトの各段階の実装後、チームはガバナンス目標を実装し、解決策を導き出し、その後の遅い SQL ガバナンスを継続的に推進してシステムの安定性を確保します。

著者: JD Logistics Liu Honyan
出典: JD Cloud Developer Community Ziyuanqishuo Tech 転載する場合は出典を明記してください

おすすめ

転載: blog.csdn.net/jdcdev_/article/details/133021071