データ操作言語（DML）でデータを変換する

BigQuery のデータ操作言語（DML）を使用して、BigQuery テーブルのデータを更新、挿入、削除できます。

DML ステートメントは、次の条件が満たされている場合、SELECT ステートメントと同じように実行できます。

  • GoogleSQL を使用する必要があります。GoogleSQL を有効にするには、SQL 言語の切り替えをご覧ください。
  • クエリの宛先テーブルを指定することはできません。

BigQuery DML ステートメントの一覧と使用例については、GoogleSQL のデータ操作言語ステートメントをご覧ください。

制限事項

  • 各 DML ステートメントは、暗黙のトランザクションを開始します。つまり、成功した各 DML ステートメントの終了時に、ステートメントによる変更が自動的にコミットされます。

  • tabledata.insertall ストリーミング メソッドを使用して最近書き込まれた行は、UPDATE、DELETE、MERGE ステートメントなどのデータ操作言語（DML）を使用して変更することはできません。最近の書き込みとは、30 分以内に行われたものを指します。テーブル内の他のすべての行は引き続き、UPDATE、DELETE、MERGE ステートメントを使用して変更できます。ストリーミング データがコピー オペレーションで使用可能になるまでに最大 90 分かかることがあります。

    また、Storage Write API を使用して最近書き込まれた行は、UPDATE、DELETE、MERGE ステートメントを使用して変更できます（プレビュー）。詳細については、最近のストリーミング データでデータ操作言語（DML）を使用するをご覧ください。

  • MERGE ステートメントにおける when_clause、search_condition、merge_update_clause、merge_insert_clause 内の相関サブクエリはサポートされていません。

  • DML ステートメントを含むクエリでは、クエリ対象としてワイルドカード テーブルを使用できません。たとえば、UPDATE クエリの FROM 句ではワイルドカード テーブルを使用できますが、ワイルドカード テーブルを UPDATE オペレーションの対象として使用することはできません。

同時実行ジョブ

BigQuery は、テーブル内の行を追加、変更、削除する DML ステートメントの同時実行を管理します。

INSERT DML の同時実行

24 時間の間、最初の 1,500 件の INSERT ステートメントは送信された直後に実行されます。この上限に達すると、テーブルに書き込む INSERT ステートメントの同時実行数は 10 件に制限されます。それ以上の INSERT ステートメントは PENDING キューに追加されます。一度に最大で 100 件の INSERT ステートメントをテーブルに対してキューに入れることができます。ある INSERT ステートメントが完了すると、次の INSERT ステートメントがキューから除かれて実行されます。

UPDATE、DELETE、MERGE DML の同時実行

UPDATE、DELETE、MERGE DML ステートメントは、変更 DML ステートメントと呼ばれます。あるテーブルに対して 1 つ以上の変更 DML ステートメントを送信したときに、他の変更 DML ジョブが実行中（または保留中）である場合、BigQuery はそれらのうち最大 2 個を同時に実行し、最大 20 個が PENDING としてキューに入れられます。実行中のジョブが終了すると、次の保留中のジョブがキューから出され、実行されます。キューに入れられる変更 DML ステートメントはテーブルごとのキューを共有し、キューの最大長は 20 です。各テーブルの最大キュー長を超える追加のステートメントは失敗し、次のエラー メッセージが表示されます。Resources exceeded during query execution: Too many DML statements outstanding against table PROJECT_ID:TABLE, limit is 20.

インタラクティブ優先の DML ジョブが 6 時間以上キューに入ったままになると失敗し、次のエラー メッセージが表示されます。

DML statement has been queued for too long

DML ステートメントの競合

1 つのテーブルで同時に実行される DML ステートメントを変更するときに、そのステートメントで同じパーティションを変更しようとすると、DML ステートメントの競合が発生します。同じパーティションを変更しない限り、ステートメントは成功します。BigQuery は、失敗したステートメントの再実行を最大 3 回試行します。

  • 行をテーブルに挿入する INSERT DML ステートメントは、同時に実行される他の DML ステートメントと競合しません。

  • MERGE DML ステートメントは、行の挿入のみを行い、既存の行の削除または更新を行わない限り、同時に実行されている他の DML ステートメントと競合しません。UPDATE 句または DELETE 句がクエリの実行時に呼び出される場合を除き、これらの句を含む MERGE ステートメントも同様です。

料金

DML の料金については、料金ページのデータ操作言語の料金をご覧ください。

ベスト プラクティス

最適なパフォーマンスを得るために、次のパターンをおすすめします。

  • 個別の行の更新や挿入を大量に送信しないでください。可能であれば、DML オペレーションをグループ化します。詳細については、単一行を更新または挿入する DML ステートメントをご覧ください。

  • 古いデータ、または特定の期間内に更新または削除が行われる場合は、テーブルのパーティショニングを検討してください。パーティショニングにより、変更をテーブル内の特定のパーティションのみに限定できます。

  • 各パーティションのデータ量が小さく、各更新の際にテーブル内の大部分のパーティションを変更している場合は、テーブルのパーティショニングを行わないようにします。

  • 1 つ以上の列が、値の狭い範囲内に収まる行を更新する場合は、クラスタ化テーブルの使用を検討してください。クラスタリングを行うことで、変更が特定の一連ブロックに制限されるため、読み取りと書き込みが必要なデータの量が削減されます。以下は、列の値の範囲をフィルタする UPDATE ステートメントの例です。

    UPDATE mydataset.mytable
SET string_col = 'some string'
WHERE id BETWEEN 54 AND 75;

    次に、列の値の小さなリストをフィルタする類似の例を示します。

    UPDATE mydataset.mytable
SET string_col = 'some string'
WHERE id IN (54, 57, 60);

    このような場合には、id 列のクラスタリングを検討してください。

  • OLTP 機能が必要な場合は、Cloud SQL 連携クエリの使用を検討してください。これにより、BigQuery は Cloud SQL に存在するデータをクエリできるようになります。

クエリのパフォーマンスを最適化するためのベスト プラクティスについては、クエリ パフォーマンスの最適化の概要をご覧ください。

次のステップ

  • DML 構文の情報とサンプルについては、DML 構文をご覧ください。
  • スケジュールされたクエリで DML ステートメントを使用する方法については、クエリのスケジューリングをご覧ください。