GraphQL API のレートリミット

ポイントベースのレート制限

GraphQL は、REST API が対処するように設計されていなかった欠点を克服するために作成されました。GraphQL には多くの利点がありますが、その1つはREST API で利用可能なデータをすべて取得するために必要なHTTP コール数を減らすことができることです。

ただし、GraphQL Admin API の呼び出しは推定クエリコストに基づいて制限されるため、リクエストの量よりも、時間の経過に伴うクエリのコストを考慮する必要があります。

ポイントは非常に単純な方法で機能します。アプリとストアの組み合わせごとに1000コストポイントのバケットが与えられ、1秒あたり50コストポイントのリークレートが設定されています。つまり、クエリの総コストは常に1,000ポイントを超えることはできず、アプリのバケットのスペースは毎秒50ポイントのレートで作成されます。平たく言えば、一般的なプランでは1秒ごとに50ポイントが与えられます。データの編集、作成、削除を必要とするミューテーションは10ポイント消費します。一方、単一のオブジェクトを取得するコストは1ポイントにすぎません。 たとえば、1つの注文データが必要で、その注文の各ラインアイテムも必要だとしましょう。これは1ポイントでは済みません。注文に10のラインアイテムが含まれている場合、それぞれの項目に1ポイント、注文自体に1ポイント、合計11ポイントがかかります。

要求されたコストと実際のクエリコストが組み合わされて制限が設定されます。クエリを実行する前に、アプリのバケットには、要求されたコストに対して十分な容量が必要です。クエリが完了すると、要求されたクエリコストと実際のクエリコストの差額がバケットに返済されます。

要求コストとスロットルの状態は応答に含まれます。extensions キーの下には次の情報が返されます：

"extensions": {
    "cost": {
      "requestedQueryCost": 101,
      "actualQueryCost": 46,
      "throttleStatus": {
        "maximumAvailable": 1000,
        "currentlyAvailable": 954,
        "restoreRate": 50
      }
    }
  }
  

これらを考慮して、ドライバーは、スロットリングを避けるために要求ごとに取得できる適切なデータ量を計算する必要があります。テーブルのページサイズは、GraphQL API の制限に適合するように、テーブル内のフィールド数とデータ数に基づいて自動的に計算されます。計算されるページサイズが小さいために、GraphQL の大きなテーブルに対するパフォーマンスが不足する可能性があります。別の方法として、MaxPointsPerCall を増やし、ページサイズを強制的に増加させることもできますが、 スロットリングが起こる可能性が高いため、お勧めしません。

GraphQL Bulk API

大量のデータをクエリして取得するには、単一のクエリではなく、一括操作を使用することをお勧めします。

一括操作は大量のデータを扱うことを目的としており、単一のクエリと同じコストやレートの制約はありません。バルククエリを利用しない場合は、データセットをページ分割する必要があります。たとえばREST の場合、応答に含めることができる要素は250までです。GraphQL はコストベースですが、それでも要求ごとに特定の数に制限されます。

Bulk Operation API では、これは該当しません。そのため、GraphQL スキーマを使用する場合は、接続文字列でUseBulkAPI をTRUE に設定し、ページネーションやスロットリングを心配することなく大量のデータを取得することをお勧めします。