Database Autonomy Service (DAS) は、データベース内の低速クエリを自動的に検出および分析し、非効率的なSQLステートメントを特定するために使用できるSQL最適化テクノロジを提供します。 SQL最適化テクノロジは、これらの問題のあるSQL文の実行計画を徹底的に分析し、最適化の提案を提供するか、問題のあるSQL文を直接最適化します。 提案には、SQL文の書き換えやインデックスの使用の調整が含まれます。 このようにして、クエリ時間が短縮され、リソース消費が低減される。
背景情報
ほとんどのデータベース管理者 (DBA) とアプリケーション開発者には、SQL最適化の要件があります。 データベース上で実行されるSQL文は多様化している。 さらに、SQLステートメントは、ビジネスの迅速な反復、データ分散特性の変更、ホットスポットの変更、データベースバージョンの更新などのシナリオで動的に継続的に変更されます。 したがって、SQLの最適化には多大な労力と重要なリソースが必要です。
課題
精度: 最適化時間を正確に特定し、問題のあるSQLステートメントを正確に特定するために、例外検出メカニズムを構築する必要があります。
プロフェッショナル診断: 目標をサポートするには、強力なプロフェッショナル診断と最適化が必要です。 有効なプロフェッショナル診断が利用できない場合、SQL最適化は実装できません。
セキュリティ: オンラインのすべてが重要です。 オンラインの変更は安全で制御可能でなければなりません。
包括的な多次元追跡と最適化パフォーマンスの包括的なリアルタイム評価もセキュリティを確保するために必要です。
リンケージ: 突然発生する悪意のある低速クエリなど、複雑なオンライン問題を包括的に解決する必要がある場合があります。 したがって、DASの自動SQLスロットリングおよび自動SQL最適化機能をリンクして、これらの問題の症状と根本原因の両方に対処する必要があります。
スケール: 数十万、さらには数百万のサーバーの自動SQL最適化をサポートするには、十分なスケーラビリティを提供するサービスアーキテクチャを構築する必要があります。
発行リスク
2つの重要な時点が考慮される。 次の図は、低速クエリの単純な傾向を示しています。 T1は、データベースインスタンスのパフォーマンス例外が検出され、低速クエリの最適化が開始される時点を表します。 T2は、最適化プロセスが完了し、インスタンスが通常状態に回復する時点を表す。 従来の最適化では、このプロセスは完全に手動操作に依存します。 これには次の重大な弱点があります。
T1は、予想時間よりもはるかに遅い。 これは、例外が最も早い機会に検出または応答されないことを示す。 例外が検出されたとしても、それは長期間存在し、障害の端にあった可能性があります。
T2とT1との間の時間差は、最適化プロセスの持続時間を表す。 長い処理期間は、ユーザ経験に深刻な影響を及ぼし、失敗のリスクを大きく増大させる。
上記の2つの問題に加えて、次のより大きな課題に直面しています。
継続的な最適化を実現するには? 問題を検出し、できるだけ早い機会にSQL文を最適化して、問題の蓄積を防ぎます。 これにより、データベースインスタンスの安定性と継続的な最適なステータスの両方が保証されます。
処理時間を短縮し、影響を最小限に抑え、包括的な方法を使用してデータベースインスタンスの安定性を確保し、症状と根本原因の両方を解決するにはどうすればよいですか?
手動操作に依存する従来の最適化プロセスは、故障駆動型であり、多数の問題に対処することができない。 ビジネスが発展し、データベースインスタンスのデータ量が増加するにつれて、すべての問題が拡大します。 人員が増えても問題は解決できません。 これは悪循環を形成する。
解決策
自動SQL最適化は、Alibaba Cloud DASのコア機能です。 これは、SQL最適化の閉ループを実現するための自律的な機能である自己最適化を提供します。 次の図は、自動SQL最適化によって提供される閉ループ機能を示しています。
自動SQL最適化は、ワークロード例外を検出し、データベースビジネスの変更を識別し、低速クエリを引き起こす新しいSQL文、パフォーマンスが低下するSQL文、非効率的なSQL文などの問題のあるSQL文を識別します。
問題のあるSQL文の場合、自動SQL最適化はDASのSQL診断および最適化機能を自動的に使用して、最適なインデックスの作成、SQL文の書き換え、エンジンの推奨などの最適化の提案を生成します。
自動SQL最適化は、最適化提案のリスクを自動的に評価する。 カナリアリリース計画を自動的に生成し、データベースインスタンスのワークロードとプロファイルに基づいて最適化タスクを自動的に調整します。
自動SQL最適化は、O&Mタイムウィンドウを自動的に選択し、生成されたカナリアリリースプランを使用して関連するオンライン変更を完了します。 この場合、インデックスは自動的に変更およびリリースできます。
自動SQL最適化は、リリースされた複数のディメンションからの変更の最適化パフォーマンスを追跡し、パフォーマンス回帰リスクをリアルタイムで継続的かつ包括的に評価します。 評価結果が予想通りであれば、最適化効果は自動的に計算される。 評価結果が予想どおりでない場合、変更は自動的にロールバックされます。
人手を必要とするパッシブ最適化は、自動SQL最適化の閉ループに基づいて、インテリジェンスベースのアクティブで継続的な最適化に変換されます。 これは最終的に無人SQL最適化を達成する。 自動SQL最適化の閉ループは、データベースを管理するための24/7保護サービスを提供するデータベースエキスパートのグループのように機能します。 さらに、データベースシステムを最適な最適化状態で実行し続けます。
アーキテクチャ
DASの自動SQL最適化は、データ駆動型の閉ループです。 上の図は、プロセス全体を簡単に示しています。
例外イベント: 例外イベントは、自動SQL最適化をトリガーするためのヒューズです。 DASイベントセンターでは、例外イベントに対して集中管理を実行できます。 例外イベントは、アラートシステムまたはリアルタイム例外検出、オフライン分析、ワークロード検出などのシナリオで生成されます。
診断: イベントセンターから例外イベントを受信すると、自動SQL最適化はデータベースインスタンスの予備診断を実行し、診断エンジンに診断要求を送信します。 次に、自動SQL最適化は、1つ以上の提案を含む診断結果を処理する。 結果が処理された後、自動SQL最適化は有効性評価を完了し、新しい最適化イベントを生成し、その後イベントをイベントセンターに送信して、後続の最適化プロセスを推進します。
提案プッシュ: DAS自律センターで自律サービスを有効にすると、最適化の提案を受け入れるかどうかを選択できます。 その後の自動最適化プロセスは、設定に基づいてトリガーできます。
変更リリース: DASは、O&Mタイムウィンドウで変更コマンドを発行し、コマンドのステータスを確認します。
パフォーマンスの追跡と測定: 最適化提案が有効になると、意思決定エンジンは追跡タスクを開始して、最適化されたSQL文と関連するSQL文のパフォーマンスを追跡します。 パフォーマンスが低下すると、SQL文は自動的にロールバックされます。 一般に、パフォーマンスが24時間追跡された後にロールバックが発生しない場合、最適化のメリットが計算されます。
問題の検出
SQL最適化では、次のシナリオでSQL例外を検出できます。
SQL最適化は定期的にトリガーされます。 通常のO&Mタイムウィンドウでは、データベースインスタンスで実行される低速クエリが定期的にオフラインで分析され、SQL最適化がトリガーされます。
SQL最適化は、一部のSQL文のパフォーマンスが低下するとトリガーされます。 ワークロード例外検出アルゴリズムがリアルタイムでパフォーマンスが低下するSQL文を検出すると、自動SQL最適化がトリガーされます。 複雑なオンライン問題の場合、DASの自動SQL最適化および自動SQLスロットリング機能をリンクして、自動SQL最適化をトリガーする必要があります。
SQLの最適化は、データベースのワークロードが変更されるとトリガーされます。 ビジネスSQL文が公開または未公開の場合、データベースインスタンスのワークロードとデータ量が変化し、既存のインデックスがビジネスのパフォーマンス要件を満たすことができなくなります。 この場合、診断と最適化がトリガーされます。
診断機能
DASのSQL診断および最適化機能は、自動SQL最適化の強力なサポートを提供します。 この機能は、データベースオプティマイザと同じ方法でコストベースのモデルを使用して最適化の問題を処理します。 最後に、この機能は、実行コストに基づいてすべての可能な推奨オプションの定量的評価を実装し、信頼できる推奨を作成します。
SQL診断および最適化機能は、Alibaba Groupで長年安定して実行されています。 この機能は、1日あたり約50,000のSQL文を診断でき、グループ全体のビジネスアプリケーションのSQL最適化をサポートします。 SQL診断の成功率は98% 以上のままであり、低速クエリの推奨率は75% 以上のままです。
セキュリティの変更
セキュリティ変更には、変更前のセキュリティチェック、カナリアリリースポリシー、変更後のパフォーマンス追跡が含まれます。
セキュリティチェック: リスクを軽減するために、変更はO&Mタイムウィンドウでのみ行われます。 さらに、変更は、プライマリデータベースとセカンダリデータベース、データベースワークロード、およびテーブルスペース間のレプリケーション遅延の各メトリック値が安全な範囲内にある場合にのみ発生します。
カナリアリリースポリシー: たとえば、シャーディングに大量のデータが含まれる場合、カナリアリリース計画が自動的に生成され、変更がバッチで実装されます。 これによりリスクが軽減されます。 変更プロセス中、システムはプライマリデータベースとセカンダリデータベース間のレプリケーション遅延を監視します。 レイテンシが指定されたしきい値を超えると、システムは各データベースのインデックス変更タスクを直ちに中断し、各データベースに対して1つの変更タスクのみが実行されるようにします。
パフォーマンス評価: パフォーマンス評価アルゴリズムは、最適化されたSQL文および関連するSQLテンプレートのパフォーマンスを追跡して、パフォーマンスの低下による障害を防ぎます。 性能評価アルゴリズムは、決定木モデルを用いて、最適化前のSQLテンプレートの性能メトリックと最適化後の性能メトリックとを比較する。 このアルゴリズムは、特定の時点でSQLテンプレートのパフォーマンスが低下するかどうかを包括的に判断します。 このアルゴリズムは、完全なSQL文と低速クエリの原因となるSQL文を追跡します。 ビジネスの変化は毎日発生します。 デフォルトの追跡サイクルは24時間です。 ロールバックが発生しない場合、最適化は成功し、実際の最適化の利点が計算されます。
サポートされるデータベースエンジン
自動SQL最適化は、ApsaraDB RDS for MySQL、PolarDB for MySQL、ApsaraDB RDS for PostgreSQLのデータベースエンジンをサポートしています。