PartiQL と SQL

SQL の癖を PartiQL に貼り付け、SELECT * FROM orders WHERE status = 'OPEN' を 走らせ、DynamoDB がそれをテーブル Scan にマップして全アイテムを課金する。 PartiQL は SQL 構文を借りる。リレーショナルなプランナは借りない。

PartiQL はサーバー上で一度に 1 テーブルに対する SELECT、INSERT、UPDATE、 DELETE をサポートする。JOIN も GROUP BY もアイテム横断の SUM もない。 DynoTable の SQL Workbench はその隙間をクライアント側で埋める。通常の Query/Scan API 経由で境界づけられた結果セットを取得し、DynamoDB のアクセス パターン規則の中で、あなたのマシン上でリレーショナル演算子を走らせる。

読み終えたらできること

• PartiQL 文が Query になるかフルテーブル Scan になるかを予測できる。
• 既定ではステージされないことを知りつつ PartiQL DML を書ける（テーブルへ直接実行）。
• PartiQL ができないとき Workbench で JOIN、GROUP BY、集約を走らせられる。
• 「DynamoDB 上の SQL」が常に境界づけられた、パターン形の読み取りを意味する理由を チームに説明できる。

読む順番

1. PartiQL 対 SQL — 構文の重なり対エンジンの 限界。クエリを書く前に期待値を合わせる。
2. PartiQL の例 — DynamoDB API にきれいに マップする SELECT/INSERT/UPDATE/DELETE パターン。
3. DynamoDB 向け SQL — クライアント側 SQL が役立つときと、 DynoTable が Workbench をどう位置づけるか。
4. JOIN — キー内の隣接対、取得済み行上のクライアント側 join。
5. GROUP BY — 選択的な読み取りのあとアプリコードまたは Workbench で集約する。
6. COUNT、SUM、集約 — キーが読み取りを 狭めない限り、なぜ PartiQL 上の COUNT(*) がそれでも Scan か。

キー条件なしの SELECT count(*) FROM events はテーブル全体を読み、レスポンスが 1 つの数でも評価した全アイテム分の読み取りキャパシティを課金する。Workbench の 注文と顧客の間の JOIN は、すでに支払って取得した行だけを join する — 下層の Query を広げると、join コストはアイテムサイズと行数とともに増える。

PartiQL のパラメータ束縛と対応関数は DynamoDB の限界を映す。サブクエリなし、 1 文でのクロステーブル参照なし、パーティション横断のサーバー側集約なし。だから Workbench がある — サーバーがプランナを得たふりをせずに SQL の馴染みを保つ。 すべての Workbench クエリを「DynamoDB のアクセスパターン規則の中の SQL」として 位置づける。まず境界づけられた読み取り、次にリレーショナル演算子。

DynoTable で試す

DynoTable をダウンロード。SQL Workbench エディタは無料の読み取り 専用プランでも使え、ローカルに推論されたスキーマによるオートコンプリート付き。 有料プランが Workbench クエリの実行とエクスポートを解放する。

PartiQL SELECT は無料で走らせられる。PartiQL DML（INSERT、UPDATE、DELETE）は 警告付きで直接実行する — 書き込みステージングを迂回する。コミット前に見直せる diff が欲しいときはアイテムエディタのステージングを使う。

Workbench と PartiQL タブのクエリコストステータスバーは、プランが分かるとき ~N items · ~R RCU を示し、Scan に退化する PartiQL 文が実行前に見える。 50 万アイテムのテーブルで、キーなしの PartiQL SELECT が Scan になると、 約 2 KB アイテムの結果整合性フル読み取りでおおよそ 125k RRU を焼きうる — キー付き Query なら一握りの RRU に対して。本番 PartiQL をジョブに貼る前に 料金計算機 でそのトレードオフを見積もろう。 JOIN と集約の限界は SQL Workbench ドキュメント を読み、 API JSON を手書きせず同じアクセスパターンが欲しいときは クエリビルダー を使う。