Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、Google Cloud のデータベースのパフォーマンスを最適化するための推奨事項について説明します。
Cloud SQL
次の推奨事項は、SQL Server、MySQL、PostgreSQL の各データベースを実行する Cloud SQL インスタンスのパフォーマンスを最適化する際に役立ちます。
- SQL Server データベースの場合は、特定のパラメータを変更し、一部のパラメータのデフォルト値を保持することをおすすめします。
- MySQL データベースまたは PostgreSQL データベースのストレージ タイプを選択する場合は、SSD ストレージと HDD ストレージのコスト パフォーマンスのトレードオフを考慮してください。
- PostgreSQL データベースのパフォーマンスの問題を特定して分析するには、Cloud SQL Insights ダッシュボードを使用します。
- SQL クエリを実行する際のパフォーマンスの低下を診断するには、
EXPLAINステートメントを使用します。
詳細については、以下のドキュメントをご覧ください。
Bigtable
このセクションでは、Bigtable インスタンスのパフォーマンスを最適化するための推奨事項について説明します。
パフォーマンス要件に基づいて容量を計画する
Bigtable は幅広いアプリケーションで使用できますが、アプリケーションごとに最適化の目標が異なります。たとえば、バッチデータ処理ジョブでは、レイテンシよりもスループットが重要になることがあります。ユーザー リクエストを処理するオンライン サービスの場合、スループットよりも低レイテンシを優先しなければならない場合もあります。Bigtable クラスタの容量を計画する場合は、スループットとレイテンシの間のトレードオフを考慮してください。詳細については、Bigtable の容量を計画するをご覧ください。
スキーマ設計のベスト プラクティスに従う
テーブルは数十億行、数千列にまでスケールできるため、ペタバイト規模のデータを保存できます。Bigtable テーブルのスキーマを設計する場合は、スキーマ設計のベスト プラクティスを検討してください。
パフォーマンスをモニタリングして調整する
インスタンスの CPU とディスクの使用状況をモニタリングし、各クラスタのパフォーマンスを分析して、モニタリング グラフに示されている適正サイズを確認します。
Spanner
このセクションでは、Spanner インスタンスのパフォーマンスを最適化するための推奨事項について説明します。
ホットスポットを防ぐ主キーを選択する
ホットスポットとは、多数のリクエストの処理を強いられる単一サーバーです。データベースの主キーを選択する場合は、スキーマ設計のベスト プラクティスに従って、ホットスポットの発生を回避してください。
SQL コーディングのベスト プラクティスに従う
Spanner の SQL コンパイラは、宣言型の SQL ステートメントを命令型のクエリ実行プランに変換します。Spanner は、実行プランを使用して SQL ステートメントを実行します。SQL ステートメントを作成するときは、SQL のベスト プラクティスに従い、最適なパフォーマンスを発揮するような実行プランを Spanner が使用するようにします。
クエリ オプションを使用して SQL クエリ オプティマイザーを管理する
Spanner は、SQL クエリ オプティマイザーを使用して、SQL ステートメントを効率的なクエリ実行プランに変換します。オプティマイザーによって生成されるクエリ実行プランは、クエリ オプティマイザー自体が進化したとき、またはデータベース統計情報が更新されたときに、わずかに変更される可能性があります。クエリ オプションを使用すると、クエリ オプティマイザーまたはデータベースの統計情報が変更されたときのパフォーマンスの低下を最小限に抑えることができます。
クエリ実行プランの構造を可視化して調整する
クエリのパフォーマンスの問題を分析するには、クエリプランの可視化ツールを使用して、クエリ実行プランの構造を可視化してチューニングします。
オペレーション API を使用して長時間実行オペレーションを管理する
特定のメソッド呼び出しでは、Spanner によって長時間実行オペレーションが作成され、完了までにかなりの時間がかかることがあります。たとえば、データベースを復元する場合、Spanner は復元の進行状況を追跡するために長時間実行オペレーションを作成します。Spanner には、長時間実行オペレーションのモニタリングと管理に役立つオペレーション API が用意されています。詳細については、長時間実行オペレーションの管理をご覧ください。
一括読み込みに関するベスト プラクティスを実施する
Spanner は、大量のデータを一括で読み込むためのオプションをいくつかサポートしています。一括読み込みオペレーションのパフォーマンスは、パーティショニング、書き込みリクエスト数、各リクエストのサイズなどの要因によって異なります。大量のデータを効率的に読み込むには、一括読み込みのベスト プラクティスに従ってください。
CPU 使用率をモニタリングして制御する
Spanner インスタンスの CPU 使用率は、リクエストのレイテンシに影響する可能性があります。バックエンド サーバーが過負荷状態になると、リクエストのレイテンシが増加する可能性があります。Spanner は、高い CPU 使用率の調査に役立つ CPU 使用率の指標を提供します。パフォーマンス重視のアプリケーションでは、コンピューティング容量を増やして CPU 使用率を低減することが必要になる場合があります。
レイテンシの問題を分析して解決する
クライアントが Spanner に対してリモート プロシージャ コールを行うと、まず、クライアント ライブラリによって API リクエストが準備されます。リクエストは Spanner データベースに到達する前に、Google Front End と Cloud Spanner API Front End を通過します。レイテンシの問題を分析して解決するには、API リクエストが通過するパスの各セグメントでレイテンシを測定して分析する必要があります。詳細については、Spanner エンドツーエンドのレイテンシ ガイドをご覧ください。
データベースがウォーム状態に達した後にアプリケーションを起動する
Spanner データベースが大きくなると、データのキースペースがスプリットに分割されます。各スプリットは、テーブルのサブセットを含む行の範囲です。データベース全体の負荷を分散するために、Spanner は動的に個々のスプリットを個別に移動させ、異なるサーバーに割り当てます。スプリットが複数のサーバーに分散している場合、データベースはウォーム状態とみなされます。データベースがウォーム状態になると、並列処理が最大化され、パフォーマンスが向上します。アプリケーションをリリースする前に、テストデータを読み込んでデータベースをウォームアップすることをおすすめします。
次のステップ
コンピューティング リソース、ストレージ リソース、ネットワーキング リソース、分析リソースのパフォーマンスを最適化するためのベスト プラクティスを確認します。