DynamoDBテーブルのサイズとアイテム数を取得する方法

DynamoDBテーブルに気軽に向けられるSELECT COUNT(*)はありません。DynamoDBは「このテーブルはどれくらいの大きさか？」に対して、まったく性質の異なる2つの答えを返します:最大6時間古い可能性のある無料の推定値と、テーブル全体の読み取りコストがかかる正確なカウントです。アイテム数が「間違っている」ときは、たいてい正確なカウントを期待しながら推定値を読んでいます。

DynamoDBテーブルのアイテム数とサイズを取得するには？

DescribeTableを呼び出します:ItemCountとTableSizeBytesを無料で返しますが、どちらもおよそ6時間ごとにしか更新されません (AWS APIリファレンス)。

正確な数が必要なら、--select COUNT付きのScanを実行します。カウントだけを返しますが、すべてのアイテムを読み取り(そして課金し)ます。

方法1:DescribeTable(無料、約6時間の遅延)

DescribeTableはメタデータの参照です。アイテムを一切読み取らないので読み取りキャパシティを消費せず、探している2つの数値を返します:

aws dynamodb describe-table --table-name Tickets \
  --query 'Table.[ItemCount, TableSizeBytes]'

どちらにも同じ但し書きが付きます。 APIリファレンスそのままの表現で: "DynamoDB updates this value approximately every six hours. Recent changes might not be reflected in this value." つまり一括ロードしたばかりのテーブルが何時間もItemCount: 0と報告することがあります。その数値は直近の更新時点のスナップショットです。

同じレスポンスにはインデックスごとの数値も含まれます:すべてのGSIとLSIが、同じ6時間サイクルで自身のItemCountとIndexSizeBytesを報告します。スパースインデックスのアイテム数をテーブルのアイテム数と比較するのは、無料でできるヘルスチェックです。実際にインデックスキーを持つアイテムがいくつあるかが分かります。

方法2:Scan + Select COUNTによる正確なカウント

「今朝時点の、おおよその値」では足りないときは、実際に数えます:

aws dynamodb scan --table-name Tickets --select COUNT

実行する前に知っておくべき事実を、すべて Scan APIリファレンスから:

• COUNTは "returns the number of matching items, rather than the matching items themselves": ネットワークトラフィックは減ります。しかし "this uses the same quantity of read capacity units as getting the items"。100 GBのテーブルの正確なカウントは、請求書上は100 GBの読み取りです。
• 単一のリクエストはそれでもスキャンしたデータ1 MBで止まります。レスポンスのCountは "only return[s] the count of items specific to a single scan request"。CLIはLastEvaluatedKeyを辿ってページを合計してくれます。SDKのコードでは自分でループして加算します — ページネーションを参照してください。
• 大きなテーブルでは、並列スキャン(--segment / --total-segments)で作業を分割し、セグメントごとのカウントを合計してください。

サブセットをカウントする

• 1つのパーティションキー配下のアイテム: --select COUNT付きのQueryは、そのキーのアイテムだけを読み取るので、データが小さければそれだけ安価です。アイテムコレクションを数える正しい方法です。
• フィルタに一致するアイテム: FilterExpressionを追加します。ただし、CountだけでなくScannedCountに数えられたすべてのアイテムの読み取りに支払います。DynamoDBは読み取った後にフィルタするので、フィルタ付きスキャンで「クローズ済みのチケットを数える」と、すべてのチケットの分を支払います。
• 小さなCountの隣に大きなScannedCountがあるのは、GSIになりたがっているフィルタの兆候です。フィルタリング戦略を参照してください。

より高度な質問(ステータスごとのカウント、合計、平均)に対しては、DynamoDBにはGROUP BYが一切ありません。回避策はカウント・合計・集計にあります。DynoTableのSQL Workbenchは、DynamoDBでのGROUP BYで示すとおり、GROUP BYと集計をクライアント側で実行します。

DynoTableでのテーブルサイズとアイテム数

DynoTableはすべてのテーブルで推定値を表示し、必要に応じて正確なカウントを計算できます。開いているすべてのテーブルには、タブのツールバーに 設定 ボタンがあり、それが開くダイアログには次が表示されます:

• プライマリキーとセカンダリインデックス: テーブルの形が一目で分かります。
• Item · サイズ · 平均 Item: DynamoDB自身のDescribeTable推定値。推定値であることが明示され、6時間の但し書きはホバー1つで確認できます。
• テーブルをインデックス化: インデックス の下にある、上限付きのサンプリングスキャン(通常の読み取りコストがかかります)で、フィールドのオートコンプリートと推論によるTypeScript / Zod / JSON Schemaエクスポートを支えます。テーブルの概要とインデックス作成を参照してください。

正確な数値については、組み込みのAIエージェントが、リクエストに応じてテーブル全体に対するカウント、合計、グループごとの内訳を計算します。1ページをサンプリングするのではなく、一致するすべてのアイテムを読み取り、その全件読み取りを実行する前に確認を求めます。(テーブルのフィールドを把握するために、確認なしで約100件のアイテムを読み取ることはあります。)

よくある質問

DynamoDBのアイテム数が間違っているのはなぜですか？ ItemCount(とTableSizeBytes)は "approximately every six hours" に更新されるため、最近の書き込みと削除はまだ反映されていません。コンソールのテーブル概要も同じDescribeTableの数値を、同じ遅延付きで表示しています。現在の数値が必要ならaws dynamodb scan --table-name X --select COUNTを実行します。これは全件読み取りです。

DynamoDBの行数を正確に数えるには？ aws dynamodb scan --table-name X --select COUNTです。CLIがテーブル全体をページングし、ページごとのカウントを合計します。正確ですが、すべてのアイテムを取得するのと同じ読み取りキャパシティが課金されます。

DescribeTableは無料ですか？読み取りキャパシティを消費しません。データの読み取りではなくメタデータ呼び出しなので、ポーリングしてもテーブルのスループットには触れません。

1つのアイテムのサイズを知るには？ DynamoDBはアイテムサイズで計測します(書き込みは1 KB単位、読み取りは4 KB単位で切り上げ)。アイテムをアイテムサイズ計算ツールに貼り付ければ課金サイズが分かります。上限については400 KBのアイテムサイズ制限を参照してください。

アイテム数は請求額に影響しますか？はい、少しだけ。課金対象のストレージはデータの生のサイズにアイテムごとのオーバーヘッドを加えたものなので、小さなアイテムが多いとバイト数から想像するより高くなり、各インデックスのストレージも課金されます。リクエストはアイテムサイズ×リクエスト数で課金されます。テーブルの数値を料金計算ツールに入力すれば、オンデマンドとプロビジョンドの両モードでの月額の全体像が見えます。

DynoTableをダウンロードして任意のテーブルでテーブルダイアログを開けば、その形、推定値、インデックス済みフィールドを確認できます。