はじめに
お世話になっております。ノベルワークスのファービー（@furbydayonn）です。
3日後に控えた健康診断に向けて過酷な減酒中です。
さて今回は、
- DynamoDBを操作するようなコードは普段書かない、DynamoDBのことはよくわかってない、そもそもエンジニアじゃない
- けど、何かしらの目的でDynamoDBに直接アクセスして保管されているデータ(アイテム)を探し出すことがある
そんな方に向けて、テーブル内を検索する時の注意点やケースに応じてどうすべきかをまとめました。
※本記事の内容は2025年1月20日時点の画面構成・仕様に準じます。
本記事では扱わないこと
- DynamoDBの詳細な仕様
- テーブル設計
- 本来スキャンを利用するケースが無いように設計すべきですが、そのあたりには触れません
- コンソール画面の詳細な操作方法
本記事で一番伝えたいこと
スキャンとクエリはケースに応じて適切に使い分けよう！
スキャンとクエリ
DynamoDBのアイテムを検索する際の方法として、 スキャンとクエリ の2つがあります。
マネジメントコンソールでテーブルにアクセスした時、デフォルトではスキャンが選択されています。
クエリの存在を知らない場合、このままなんとなく「あ、フィルターってあるな、これで絞り込めばいいんだな」となり、スキャンを使ってしまう傾向が多いように感じています（少なくとも私の観測範囲では）。
ですが、スキャンは極力使用すべきではありません。
取得したいデータにもよりますが、 基本的にはまずクエリで取得できないかを考えて 、クエリでは取得が難しい場合にやむを得ずスキャンを使用します。
何故スキャンを使用すべきではない？
以下は、テーブルサイズが約1GBあるテーブルに対し、クエリでパーティションキーを指定した場合と、スキャンでフィルタによってパーティションキーを絞り込んだ際の消費キャパシティです。
キャパシティについては「どれぐらい負荷がかかったか」を表しています。
クエリ
スキャン
注目すべきは右端のRCUs consumedです。
得られる結果（アイテム）は同じですが、スキャンを使うかクエリを使うかによって、負荷に約16倍の差が生まれています。
なんならスキャンの方はエラーが出ています。これはテーブルに設定している処理上限を超えてしまったことによるエラーです。
キャパシティの詳細については以下を参照してください。
RCUs consumed (消費キャパシティ) が高いと何がまずい？
テーブルの設定により影響が変わります。
DynamoDBの課金形態として
- 使った分だけ課金（従量課金）
- 予め決めた使用量に対する課金
の2つがあります。
2の方が単価は安くなりますが、予め使用量を計算・予測する必要があります。
要件やコストを鑑みてどちらにするかを選択します。
オンデマンドキャパシティモードの場合 ☞ お金がかかる💸＆ユーザーにも迷惑かけるかも🥹
1の課金形態をオンデマンドキャパシティモードといいます。
この場合、単純に 課金量が増えます。
また、あまりにも消費キャパシティが大きい場合は処理上限超過によるエラー(ProvisionedThroughputExceededException)が発生します。
エラーが発生しているテーブルを参照しているアプリケーションに影響を及ぼす、つまりユーザーに迷惑をかける可能性があります。
オンデマンドキャパシティモードにおける処理上限（最大スループット）については以下を参照してください。
プロビジョンドキャパシティモードの場合 ☞ ユーザーに迷惑かけるかも🥹
2の課金形態をプロビジョンドキャパシティモードといいます。
事前に最大これぐらい使いそう、と予測して設定した閾値に応じて課金されます。
なのでどれだけ負荷をかけようが料金は変わりません。
ただし閾値を超える負荷をかけた場合、先述の処理上限超過によるエラー(ProvisionedThroughputExceededException)が発生します。
いかがでしょうか。
スキャンをやみくもに使うと何か痛い目に合いそう 、というのがなんとなく理解いただけたのではないかと思います。
なおキャパシティモードの確認は、テーブルの詳細情報の「追加の設定」タブから確認できます。
用語の説明
この後、ケースに応じた検索方法（スキャンとクエリの使い分け）を紹介していきますが、その前に用語について簡単に説明します。
なんとなくわかっている方は読み飛ばしてもらって大丈夫です。
パーティションキーとソートキー
パーティションキーとソートキーの組み合わせは、テーブル内のアイテムを一意に特定するために使用されます。
- パーティションキー：データの保存場所を決定する主要な識別子
- ソートキー：同じパーティションキー内でのデータの並び順を決定。指定しないことも可能。
パーティションキーのみ設定している場合: パーティションキーは重複することができません。
パーティションキーとソートキーを設定している場合: パーティションキーは重複することができますが、パーティションキー＋ソートキーの組み合わせは重複することができません。
インデックス
テーブルに対して、パーティションキーとは異なる属性でも効率的に検索できるように、インデックスを作成することができます。
例えば以下のようなテーブルがあるとします。
| パーティションキー: company_code | ソートキー: user_email |
|---|---|
| company_a | 1@a.com |
| company_a | 2@a.com |
| company_b | 1@b.jp |
ソートキーであるuser_emailだけを指定して検索したい場合、このままではスキャン＋フィルタによる高負荷な検索しかできません。
しかしこのユースケースは頻繁に発生するので、負荷はかけたくありません。
こういった場合にuser_emailをパーティションキーとしたインデックスを作成することで、負荷を減らすことができます。
ただしインデックスを作成することで費用は増加します。
フィルター
スキャンやクエリで得た結果から、更に絞り込みを行います。
注意すべき点としては、フィルタによって絞り込みを行っても、 処理にかかる負荷（消費キャパシティ）は変わりません
ケース別💡スキャンとクエリの使い分け
以下、ケースに応じた取得方法を記載します。
なお本記事のサンプルテーブルではインデックスは存在していない想定ですが、
実際のテーブルにおいてインデックスが用意されている場合には適切に利用してください。
サンプルテーブル
パーティションキーとソートキーがどちらも設定されているテーブルまたはインデックスとなります。
以下のような、会社別の担当者を管理するテーブルがあるとします。
※説明のしやすさ優先の設計となっています。予めご了承ください。
| パーティションキー: company_code | ソートキー: user_email | position |
|---|---|---|
| company_a | 1@a.com | Manager |
| company_a | 2@a.com | Staff |
| company_b | 1@b.jp | Staff |
ケース1: 取得したいデータのパーティションキーの値のみわかっている
クエリを使用 してください。
例: 特定の会社compnay_aの担当者を一覧で取得したい
ケース2: 取得したいデータのソートキーの値のみわかっている
ソートキーのみで検索することはできない為、スキャンを使用してください。
例: 特定のメールアドレス（担当者）2@a.comがすでに存在しているか確認したい
ケース3: 取得したいデータのパーティションキーとソートキーの両方の値がわかっている
クエリを使用してください。
例: company_aの2@a.comの情報を取得したい
ケース4: 取得したいデータのパーティションキーとソートキーの両方の値がわからない
スキャンを使用してください。
例: positionがManagerな人の一覧を取得したい
例: とにかくテーブルの全情報が欲しい
Tips
すべてのデータを取得する
スキャンまたはクエリを一度実行した際に取得できるアイテム数は、ページサイズで設定されている件数に準じます。（最大300件）
取得した結果ページサイズ以上のアイテムが存在している場合は、Retrieve next pageというボタンが表示されるので、クリックすることで残りのアイテムを取得することができます。
ソートしたい
テーブルの属性名をクリックすることで、任意の属性値でソートすることが可能です。
ソートの対象は、 取得済みのアイテム になります。
なので、一部データのみ取得した状態でソートした場合、期待した結果とならない可能性があります。
すべてのデータを取得した上でソートする ようにしましょう。
参考）取得した時点でのソート順は？
デフォルトでは、項目は保存されている順序 (つまり、ソートキーによって昇順でソート) で返されます
SQLを使いたい
PartiQLを利用することでSQLに似た構文でアイテムを検索することができます。