GaussDB for MySQL パフォーマンス最適化の詳細な説明

背景

まず、MySQL 8.0でのトランザクション送信の一般的なプロセスを見てみましょう。

上記のプロセスは、MySQL 8.0 の WAL 原則の実装です。このプロセスは、トランザクションの送信時に、書き込みバッファとディスクへのフラッシュのプロセスを完了する必要があることを意味します。

しかし、このプロセスには問題があります。各サーバーの CPU には制限があり、サーバーが処理できるスレッドの数にも制限があります。そのため、業務における同時トランザクションの数がサーバーが並行して処理できる数よりはるかに多い場合、後続のトランザクションは前のトランザクションが送信された後にしか処理できません。それまでは、彼らは何もできなかった。したがって、高同時実行シナリオでは、スレッドの使用率をさらに向上させる方法が、高同時実行トランザクションを作成するための鍵となります。

インスピレーションは人生から生まれる

最適化は、何もないところから想像できるものではなく、現実から生まれるものであることもよくあります。次に、取引送信プロセスに非常によく似た、身近な例である速達配送について見てみましょう。

今日の速達便では、一般的に1人の配達員が1つのエリアを担当します。速達便が普及し始めた頃は、荷物の量も少なかったため、基本的に1人の配達員が指定時間内に配達を完了することができました。

しかし、速達便の件数が増加すると、宅配業者は1つのコミュニティで配達してから次のコミュニティに到着するまでに長い時間を費やす必要があり、その結果、宅配業者が時間通りに配達できなくなることがよくあります。この問題に駆り立てられて、速達ステーションという新しい産業が生まれ始めました。

速達配送の最適化原則

次に、宅配ステーションが実際にどのような問題を解決するのかを見てみましょう。

速達の過程で、最も時間がかかるのは荷物の積み下ろしではなく、電話と待ち時間です。コミュニティへの配達にかかる時間は、最後の人が荷物を取りに来る時間によって決まります。最後の人が代金を受け取った後は、配達員は電話をかける以外何もできません (最後の人が荷物を取りに来る時間が不確かなため、隣のコミュニティの人々に通知する方法はありません)。そうなると、この待ち時間は宅配業者にとって無駄になります。

宅配ステーションはこの問題を大幅に解決できます。宅配便業者は到着後、宅配便を降ろして次のコミュニティに行くだけで済みます。残りの作業はステーションのスタッフが行うことができるため、宅配便業者の配達効率が大幅に向上します。

分析する

データベースに戻って、トランザクションスレッドを宅配便業者、ストレージ上のファイルを宅配便を受け取る人と考えると、この 2 つは非常によく似ていることがわかります。では、速達配送を最適化するのと同じように、トランザクション処理プロセスを最適化することはできるのでしょうか?答えはイエスです。

速達ステーションの最適化原則によれば、速達ステーションは顧客が商品を受け取るのを待つ時間を配達員に節約することが分かっています。では、取引処理プロセスには待機プロセスがありますか?答えは「はい」です。ストレージ IO の待機時間は長くなります。データベースの使用経験が豊富な開発者は、REDO ログがストレージに書き込まれるのを待つディスク IO パフォーマンスが、データベースの書き込みパフォーマンスを大きく左右することを知っています。最新のデータベース、特にコンピューティングとストレージを分離している GaussDB (MySQL 用) などのデータベースでは、ストレージ IO 時間がトランザクション処理時間全体の大部分を占めます。ログバッファーのマージ書き込みにより、同時実行状況での全体的なスループットを向上させることができますが、IO の待機時間中にこれらのスレッドが他の処理 (待機中の他のトランザクションの処理など) を実行できる場合は、この限りではありません。その後、パフォーマンスがさらに向上します。

GaussDB の最適化 (MySQL 用)

待機ポイントが見つかったので、速達の最適化方法と同様に、データベースに「速達ステーション」を作成し、「速達ステーション」に待機を任せ、トランザクションスレッドが他の待機中のトランザクションを処理できるようにすることで、CPU が「アイドル」にならないようにします。

図 5 に示すように、GaussDB (for MySQL) は、REDO ログのディスクへのフラッシュアクションが完了した後にトランザクションをコミットできます。ただし、この時点ではクライアントに応答せず、次のトランザクションを直接処理します。同時に、少数の「コミット後のワーカースレッド」を使用して、ログ書き込みの完了をバッチで待機し（待機プロセスは実際には CPU を占有しません）、クライアントに応答します。これにより、「待機」と「次のトランザクションの処理」が並列化され、CPU が「ビジー」な状態を維持できます。