翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

書き込みワークロードの調整

ロードバランシングを実装し、ライターインスタンスを解放すると、書き込みワークロードが急増したときのパフォーマンスを改善することができます。高い同時実行性での書き込みパフォーマンスをさらに改善するには、次の追加手順に従います。

参照整合性をアプリケーション層に移行する

参照整合性チェックは重要なチェックですが、ハイパースケール時には負荷にマイナスの影響を及ぼす可能性があります。書き込みのたびに、追加のスキャンを行ってから書き込み自体を実行する必要があるため、パフォーマンスの低下につながります。アプリケーションに厳密な整合性チェックが必要な場合は、書き込みのスロットリングを回避するためチェックをアプリケーション層に組み込みます。

重いプライマリキーの使用は避ける

プライマリキーは軽い状態に保つようにします。InnoDB のストレージエンジンは、テーブルに作成される他のすべてのインデックスにプライマリキーを追加します。プライマリキーが大きいと、インデックスのサイズに影響します。プライマリキーが非常に大きいと、データページの保存および取得のスピードが遅くなります。一般的な例として、汎用一意識別子をプライマリキーとして使用する例が挙げられます。この方法は、ハイパースケール後の環境でのパフォーマンスを対象としている場合は適していません。

パーティション交換を使用してパーティションテーブルにデータを読み込む

大量のデータセットをパーティションテーブルに書き込む場合は、LOAD DATA FROM S3 とパーティション交換を組み合わせるとパフォーマンスが向上します。挿入の際にメインテーブルにアクセスしないためです。パーティション交換にはデータ定義言語 (DDL) を使用し、テーブルにメタデータロックを適用します。この処理は、パーティション交換 DDL が待機することなくメタデータロックを取得できるよう、テーブルで実行されているクエリが最小限かまたはまったくないときに実行します。パーティション交換それ自体は数ミリ秒で完了します。

未使用インデックスの削除

InnoDB はデータの増加に応じてクエリプランを最適化するため、データベース内で未使用のインデックスがないかチェックし、あれば削除することが推奨されます。未使用のインデックスは、アプリケーションがテーブルにデータを書き込む際に IO を使用します。未使用のインデックスのリストをチェックし、それらが四半期レポートなどまれな状況で使われるインデックスではないことを確認します。また、インデックスの中には一意性や順番を強化するために使用され、考慮する必要があるものもあるため、注意します。

古い行バージョンは効率的に削除する

多版型同時実行制御 (MVCC) の InnoDB 実装では、レコードが変更されると、変更されたデータの現行 (古い) バージョンが undo ログに undo record として記録されます。履歴リストの長さ (HLL) の値が増えた場合、InnoDB ガベージコレクションスレッド (パージスレッド) が書き込みワークロードに追いついていないか、パージが長時間のクエリまたはトランザクションによってブロックされていることを意味します。ガベージコレクションがブロックされたり遅延したりすると、データベースで大幅なパージの遅延が発生し、クエリのパフォーマンスにマイナスの影響を及ぼす可能性があります。次の推奨事項を参考にすると、パージのプロセスを最適化できます。

ログ記録のせいで競合がさらに発生しないようにする

一般的なクエリログには、サーバーが受信したすべてのステートメントが受信順に記録されているほか、クライアントの接続と切断も記録されます。ログ記録は有効にすると同期的に実行されるため、負荷の高いシステムではパフォーマンスが大幅に低下する可能性があります。必要なければ、一般ログは非アクティブにすることが推奨されます。

スロークエリログには、実行に要する秒数 long_query_time より長く時間がかかったステートメントが記録されます。デフォルトの設定は 10 秒です。0 に設定するとすべてのステートメントが同期的にログ記録されるため、負荷の高いデータベースではパフォーマンスが低下する可能性があります。