PartiQL と SQL

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

PartiQL は 1 文につき 1 テーブルに対して SELECT、INSERT、UPDATE、DELETE を実行する。JOIN も GROUP BY もなく、集約関数は一切ない。

それらにはネイティブな選択肢がある。事前計算した集約アイテム、S3 へエクスポートして Athena でクエリする方法、または Athena DynamoDB コネクタだ。DynoTable の SQL Workbench はそれらをデスクトップ上で実行する。FROM テーブルを Scan し、キー付き JOIN の相手側はキーで読む。

このセクションで身につくこと

PartiQL 文が Query になるかフルテーブル Scan になるかを予測できる。
DynamoDB が PartiQL DML を即座に適用することを理解し、先に diff を見たいときは DynoTable でステージできる。
JOIN、GROUP BY、集約の答えをネイティブな方法か Workbench で得られる。
「DynamoDB 上の SQL」がそれでもキーかスキャンで読むこと、そしてそれぞれのコストをチームに説明できる。

読む順番

DynamoDB 向け SQL: DynamoDB で使える SQL と、 JOIN と GROUP BY をどこで実行するか。Athena、Redshift、EMR 上の Hive、Workbench。
PartiQL 対 SQL: 構文の重なり、エンジンの限界、そして何が壊れるか。
PartiQL の例: DynamoDB API にきれいにマップする SELECT/INSERT/UPDATE/DELETE パターン。
JOIN: 非正規化、シングルテーブル設計、BatchGetItem によるアプリ側 join、そしてアドホックな join のための SQL エンジン。
GROUP BY: アトミックカウンター、Streams + Lambda によるロールアップ、S3 へのエクスポート + Athena、そしてアプリ側でのグループ化。
COUNT、SUM、集約: Select=COUNT のコスト、ItemCount が古い理由、そして SUM/AVG をどこから得るか。

7 件中 0 件読了クイズ

DynamoDB のための SQL と PartiQL の限界

DynamoDB を SQL でクエリできる？ PartiQL はキーによる SELECT・INSERT・UPDATE・DELETE を扱いますが、JOIN、GROUP BY、COUNT(*) は扱えません。何が動くのかを解説します。

初級読了 8 分

DynamoDB PartiQL vs SQL: 何が壊れるのか

DynamoDB の PartiQL は SQL に似ていますが、JOIN・GROUP BY・サブクエリ・集計はありません。各ステートメントはネイティブのアイテム操作に対応します。何が壊れるのかを解説。

初級読了 8 分

例で学ぶ DynamoDB の PartiQL

例で学ぶ DynamoDB の PartiQL。SQL に似た構文での SELECT、INSERT、UPDATE、DELETE と、パーティションキーやテーブル全体のスキャンにまつわる落とし穴を解説します。

初級読了 6 分

DynamoDB の JOIN: テーブルを結合する方法

DynamoDB に JOIN はなく、PartiQL もそれを追加しません。その理由、開発者が使う4つの回避策、そして DynoTable の SQL Workbench が本物の JOIN を実行する仕組み。

中級読了 10 分

DynamoDB GROUP BY：代わりに集計する方法

DynamoDB に GROUP BY・SUM・AVG はなく、PartiQL も追加しません。アトミックカウンター、Streams + Lambda のロールアップ、S3 へのエクスポート + Athena、アプリ側グルーピング。

中級読了 11 分

DynamoDB で COUNT、SUM、集計を行う方法

DynamoDB で COUNT、SUM、集計を行う方法。Select=COUNT のコスト、ネイティブの SUM や AVG がない理由、そして本当の合計を得るためのパターン。

初級読了 6 分

理解度チェッククイズに挑戦

このセクションで学んだ内容を確認しましょう。

SELECT count(*) FROM events はそもそも実行されない。PartiQL は ValidationException: Unexpected path component at 1:8:5 で拒否する。ネイティブなカウントは Scan または Query の Select=COUNT で、これも評価した全アイテムを課金する。

Workbench の JOIN は FROM テーブルを読み、次に一致ごとに結合先テーブルをキーで引く。まずキー条件で FROM の読み取りを絞ろう。Workbench が join とグループ化を行うのは、取得したものだけだ。

DynoTable で試す

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

PartiQL SELECT は無料で実行できる。PartiQL DML（INSERT、UPDATE、DELETE）はほかの編集と同じくステージされる。変更を Commit なら 1 ステップで書き込み、変更をステージ なら見直せる diff が残る。どちらの場合も書き込みはジャーナルに記録される。

Workbench と PartiQL タブのコストステータスバーは、プランが分かるとき ~N items · ~R RCU を示すので、Scan になる文は実行前に分かる。JOIN の場合は FROM の読み取りを対象とし、結合先のルックアップはフラグが立つだけで価格は出ない。

Workbench の Execute は 1 ページを読む。最後まで実行 は全ページを読み、アイテム数の上限はない。約 2 KB のアイテムが 50 万件あると、キーなしのフル読み取りは約 125,000 読み取りリクエストユニット（us-east-1 の定価で $0.016）になる。キー付きの Query ならほんの数ユニットで済む。

PartiQL の例でそのコストを詳しく見られ、料金計算機で自分のテーブルの価格を出せる。

JOIN と集約の限界は SQL Workbench ドキュメントを読み、 API JSON を手書きせずに同じアクセスパターンを使いたいときはクエリビルダーを使おう。