一括読み込みのベスト プラクティス

このページでは、大容量データを Cloud Spanner に効率よく一括読み込みするためのガイドラインを説明します。

Cloud Spanner にデータを一括で読み込む方法はいくつかあります。

一括読み込みのパフォーマンス ガイドライン

以下のガイドラインに従うと、一括読み込みのパフォーマンスを最適化できます。

  • 書き込みトランザクションに関連するスプリット数を最小限にする。 トランザクションのスプリット数が少ないほど書き込みスループットが大きくなるため、パフォーマンスが最大化されます。

  • パーティショニングを最大限利用して、ワーカータスク全体にパーティションの書き込みを分散する。

Cloud Spanner は負荷ベースの分割を使用して、ノード間でデータの負荷を均等に振り分けます。負荷の高い状態が数分続くと、Cloud Spanner はインターリーブされていないテーブルの行間に分割境界を設定します。一般に、データの負荷が適切に分散されている場合、スキーマ設計と一括読み込みのベスト プラクティスに従うと、インスタンスで使用可能な CPU リソースが飽和するまで、書き込みスループットは数分ごとに倍増します。

主キーによるデータの分割

一括読み込みの書き込みスループットを最適化するには、次のパターンになるようにデータを主キーで分割します。

  • 各パーティションに、主キー列で決定された連続した行範囲が含まれる。
  • 各 commit に、1 つのパーティションのデータのみが含まれる。

パーティションの数は、Cloud Spanner インスタンスのノード数の 10 倍にすることをおすすめします。以下の方法でパーティションに行を割り当てます。

  • 主キーでデータを並べ替えます。
  • データを 10 ×(ノード数)個の同じサイズのパーティションに分割します。
  • 各パーティションにそれぞれワーカータスクを作成して割り当てます。ワーカータスクはアプリケーション内で作成されます。これは Cloud Spanner の機能ではありません。

このパターンにより、負荷が大きい場合、一括書き込み全体のスループットの最大値がノードごとに 10~20 MB/秒になります。

データを読み込みながら、Cloud Spanner はスプリットを作成して更新し、インスタンスのノード間で負荷を分散します。このプロセスにおいてスループットが一時的に低下する場合があります。

3 つのノードを持つリージョン構成があるとします。この構成の非インターリーブ テーブルには 90,000 行あるため、主キーは 1〜90,000 の範囲になります。

  • 行数: 90,000 行
  • ノード数: 3
  • パーティション数: 10 × 3 = 30
  • パーティションあたりの行数: 90,000 ÷ 30 = 3,000

最初のパーティションには 1 から 3,000 までのキー範囲、2 番目のパーティションには 3,001 から 6,000 までのキー範囲が含まれています。同様の範囲指定を行っていくと、30 番目のパーティションのキー範囲は、87,001 〜 90,000 になります(大規模なテーブルでは連続したキーを使用しないでください。この例はデモ用です)。

各ワーカータスクは単一のパーティションに書き込みを送信します。各パーティション内では、主キーによって行を順番に書き込みます。主キーを基に、行をランダムに書き込む場合でも、比較的高いスループットが得られます。テスト実行を測定することで、データセットに最大のパフォーマンスをもたらすアプローチがわかります。

パーティションを使わない場合

各ミューテーションがそれぞれ 1 行を挿入する 1 回の commit で複数のランダム行を書き込むと、一度に 1 行ずつ書き込んでいくよりもパフォーマンスが低下することがあります。各ランダム行が異なるスプリットに属する可能性があり、複数のスプリットが関係する可能性が高くなるためです。最悪のシナリオでは、各書き込みが Cloud Spanner インスタンスのすべてのスプリットに関係します。前に説明したように、書き込みスループットが低下するのは、1 回の書き込みに関係するスプリットが増加した場合です。

プッシュバックの回避

Cloud Spanner が処理できる以上の書き込みリクエストが送信される場合があります。Cloud Spanner は、トランザクションを中止することにより過負荷に対処します。これをプッシュバックと呼びます。書き込み専用トランザクションの場合、Cloud Spanner は自動的にトランザクションを再試行します。この場合、プッシュバックによりレイテンシが高くなります。高負荷が続くと、プッシュバックは 1 分間続くことがあります。非常に高い負荷の場合、プッシュバックが数分間続くことさえあります。プッシュバックを避けるには、書き込みリクエストを調整して CPU 使用率を相応の範囲内に抑える必要があります。

1 MB~5 MB のミューテーションを一度に commit

書き込みが大きくても小さくても、Cloud Spanner に書き込むたびにオーバーヘッドが生じます。スループットを最大化するには、1 回の書き込みで格納されるデータ容量を最大まで増やします。書き込みが大きいほど、書き込みごとのオーバーヘッドの比率が低くなります。適切な方法は各 commit で数百単位の行を変更することです。比較的大きな行を書き込むときは、commit のサイズを 1 MB~5 MB にすると、通常最適なパフォーマンスが得られます。小さい値やインデックス付きの値を書き込むときは、通常、1 回の commit で数百行まで書き込むことをおすすめします。commit のサイズや行数とは関係なく、1 回の commit あたりのミューテーションは 20,000 までという制限に注意してください。最適なパフォーマンスを見いだすには、スループットをテストして測定する必要があります。

5 MB 超のミューテーションや数百行を超えるミューテーションを commit してもメリットはなく、commit サイズと commit あたりのミューテーション数に関する Cloud Spanner の制限を超えるリスクがあります。

セカンダリ インデックスのガイドライン

データベースにセカンダリ インデックスがある場合は、データベース スキーマへのそのインデックスの追加を、テーブルデータの読み込み前に行うか、後に行うかを選択する必要があります。

  • 数千万以上の行を追加する場合は、テーブルデータを読み込むと同時にインデックスを追加するよりも、テーブルデータの読み込み後にインデックスを追加するほうが通常は高速です。
  • データの後にインデックスを追加する場合は、スキーマ変更のパフォーマンス コストを考慮する必要があります。原則として、1 日あたり 3 個、または 1 週間で 21 個というインデックスの追加制限があります。
  • 負荷をテストして測定してから最終的な決定をするようにしてください。

大量のデータを読み込む場合、通常はデータを読み込む前にインデックスを作成すると、最高のパフォーマンスを得られます。インデックスが週次の制限である 21 個未満の場合、データの読み込み後にインデックスを追加することをおすすめします。

セカンダリ インデックスを作成するため、Cloud Spanner はバックグラウンド プロセスを使用してインデックスを自動的にバックフィル(入力)します。通常、セカンダリ インデックスのスプリットは、テーブルそのものとは別のサーバーにあります。セカンダリ インデックスを含むテーブルにデータを書き込む場合は、複数のサーバーが関係します。その結果、セカンダリ インデックスのあるテーブルへの commit では複数サーバー用の commit プロトコルが使用されるため、オーバーヘッドが増加しレイテンシが長くなります。データを一括読み込みするときにテーブルにセカンダリ インデックスがない場合は、関係するサーバーの数が減り、一括書き込みのスループットが最大になります。

スループットのテストと測定

スループットは予測が困難な場合があります。最終読み込みを実行する前に、一括読み込みの戦略をテストすることをおすすめします。パーティショニングとパフォーマンスのモニタリングを使用した詳細な例については、データ読み込みスループットの最大化をご覧ください。

既存データベースへの一括読み込みを定期的に行う際のベスト プラクティス

データは含むがセカンダリ インデックスがない既存のデータベースを更新する場合にも、このトピックのベスト プラクティスが当てはまります。

セカンダリ インデックスがある場合、同様の手順で一定のパフォーマンスが得られますが、パフォーマンスは、トランザクションに関係するスプリットの平均数に依存します。スループットが低すぎる場合は、次の方法を試してください。

  • 各 commit に含まれるミューテーションの数を減らします。これにより、スループットが向上する場合があります。
  • アップロードの容量が更新対象テーブルの現在の合計サイズよりも大きい場合は、いったんセカンダリ インデックスを削除し、アップロードが完了した後で追加し直してください。この手順は通常は必要ありませんが、スループットが向上する場合があります。

Avro ファイルのインポートのベスト プラクティス

以下のページでは、Avro ファイルのインポート パフォーマンスの向上に関する情報をご覧いただけます。

Cloud Dataflow コネクタを使用するためのベスト プラクティス

Cloud Dataflow コネクタを使用する際のパフォーマンス向上のヒントに関しては、Cloud Spanner への書き込みとデータの変換をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Spanner のドキュメント