DynoTable

用語集

これらのドキュメント全体で使われる DynamoDB と DynoTable の用語の定義です。 多くの用語はドキュメント内で点線の下線付きで表示されます — クリックすると その場で定義を確認できます。

AWS Bedrock
基盤モデル向けの AWS のマネージドサービス。DynoTable の AI アシスタントは、あなた自身の AWS 認証情報を使って Bedrock 上で動作でき、プロンプトをアカウント内に留めます。 DynoTable で見る →
DynamoDB Stream
テーブル上のアイテムレベルの変更（挿入、更新、削除）を時系列順に記録したログ。Lambda 関数などの後続処理をトリガーするのに使われます。 コンセプトを学ぶ →
Expression Builder
ビジュアルなフォームから、対応する属性名マップと値マップを備えた有効な DynamoDB のキー / フィルタ / 更新式を生成する DynoTable の無料 Web ツール。 DynoTable で見る →
IAM Identity Center (SSO)
AWS のシングルサインオン認証情報のソース（旧 AWS SSO）。DynoTable はこれを通じてサインインし、作業中に短命なロール認証情報を更新します。 DynoTable で見る →
MFA
多要素認証。ロールやプロファイルが要求する場合、DynoTable はワンタイムコードの入力を求め、得られたセッションをその有効期間中キャッシュします。 DynoTable で見る →
NDJSON
改行区切りの JSON — 1行に1つの JSON オブジェクト。DynoTable が CSV や JSON 配列と並んで提供する、ストリーミングに適したエクスポート形式です。 DynoTable で見る →
OLAP (Online Analytical Processing)
分析系のクエリワークロード — 大規模な集計、GROUP BY、データセット全体にわたるアドホックなスライシング。OLTP の対極にあります。DynamoDB は OLTP 指向のため、重い分析処理はエクスポートで供給される列指向ストアに任せるべきです。 コンセプトを学ぶ → DynoTable で見る →
OLTP (Online Transaction Processing)
運用系のクエリワークロード — 個々のレコードに対する、小規模で既知のポイント読み取り・範囲読み取りと書き込み。OLAP の対極にあります。DynamoDB は OLTP のために設計されています。 コンセプトを学ぶ → DynoTable で見る →
PartiQL
AWS が DynamoDB 向けに提供する SQL 互換のクエリ言語。DynoTable では INSERT/UPDATE/DELETE を含む PartiQL を直接書け、結果がストリーミングで返ってきます。 コンセプトを学ぶ → DynoTable で見る →
Query
1つのパーティションキー値に対する対象を絞った読み取り（必要に応じてソートキー条件で絞り込み）。一致するアイテムのみを読み取るため、高速かつ安価です。DynoTable はハッシュキーフィルタを設定した瞬間に Query を発行します。 コンセプトを学ぶ → DynoTable で見る →
Quick View
グリッドを離れずに1つのアイテムの全内容をキーボードで素早く確認する機能 — 選択した行で開くと、すべての属性を確認できます。 DynoTable で見る →
Scan
テーブルまたはインデックス内のすべてのアイテムを読み取り、後からフィルタする操作。大きなテーブルでは高コストです — DynoTable はリクエストが Scan にフォールバックする際に警告します。 コンセプトを学ぶ → DynoTable で見る →
Smart Table
1つ以上の DynamoDB テーブルにまたがる関連アイテムを1つのグリッドに結合する DynoTable のビュー。エンティティ関係キャンバス上でビジュアルに定義します。 DynoTable で見る →
TTL（Time to Live）
アイテムごとの有効期限タイムスタンプ属性。DynamoDB は TTL を過ぎた直後にアイテムを無料で自動削除します — セッション、キャッシュ、一時的なデータに便利です。 コンセプトを学ぶ →
Workbench
DynoTable の SQL で記述するタブ。テーブルに対して本物の SQL（JOIN、GROUP BY、集計）を — PartiQL 単体では表現できない操作を — DynamoDB のアクセスパターンの制約の中で書けます。 コンセプトを学ぶ → DynoTable で見る →
アイテム
DynamoDB テーブル内の1件のレコード — おおよそ行に相当します。アイテムはプライマリキーで識別される属性の集まりです。
アイテムコレクション
同じパーティションキーの値を共有するすべてのアイテム。単一の Query がまとめて読み取る単位であり、キースキーマから生まれる創発的な性質であって、有効化する機能ではありません。 コンセプトを学ぶ →
エンタイトルメント
ユーザーが現在アクティブなサブスクリプションでカバーされているか — そしてチームの場合は、どの組織がカバーしているか。DynoTable はこれを解決して、ライセンストークンが何を付与するかを決定します。 DynoTable で見る →
オンデマンドキャパシティ
リクエストごとに課金される課金モード。DynamoDB がスループットを自動的にスケールし、読み取り / 書き込みごとに支払います。キャパシティ計画が不要でシンプル — 急増する、または予測できないトラフィックに適しています。 コンセプトを学ぶ →
キーのオーバーロード
パーティションキーとソートキーに汎用的な名前（pk/sk）を付け、各エンティティタイプを値にエンコードすることで、1 つのテーブルで多数のエンティティを扱えるようにする手法。シングルテーブル設計を成立させる技術です。 コンセプトを学ぶ →
キャパシティユニット
DynamoDB の I/O に対する課金 / スループットの単位。読み取りは 4 KB ごと（RCU）、書き込みは 1 KB ごと（WCU）に切り上げて計測されます。query や scan のコストを決定します。 コンセプトを学ぶ →
クエリパターン
DynoTable において、タブを読み取るのに使うインデックス — テーブルの PRIMARY キーまたは名前付きの GSI/LSI です。どのキーでフィルタできるかを決めます。 DynoTable で見る →
グローバルセカンダリインデックス (GSI)
同じテーブルデータに対する代替のキースキーマで、独自のパーティション / ソートキーを持ちます。テーブルのプライマリキー以外の属性でクエリできます。GSI は結果整合性で、独自のキャパシティを持ちます。 コンセプトを学ぶ → DynoTable で見る →
シート
チームサブスクリプションにおける1つのライセンス済みユーザー枠。メンバーを追加するとシートを1つ消費します。シート数がチームプランの課金対象です。 DynoTable で見る →
シングルトンアイテム
固定でハードコードされたキーを持ち、アプリケーション全体の状態（フィーチャーフラグ、設定 blob、グローバルカウンター）を保持する単一のアイテム。Scan ではなく、必ず GetItem で読み取ります。 コンセプトを学ぶ →
ステージングエリア
保留中の編集を保持する DynoTable のテーブルごとのバッファ。変更は確認可能な差分としてローカルに蓄積され（そのテーブルの開いている任意のビューから見えます）、トランザクションバッチとして DynamoDB にコミットされるため、中途半端な編集が書き込まれることはありません。 DynoTable で見る →
スパースインデックス
そのキー属性を持つアイテムだけを含むセカンダリインデックス。巨大なテーブルの小さなホットな部分集合が、事前にフィルタされてクエリ可能な独自のコレクションになります。 コンセプトを学ぶ →
ゼロパディング
数値のソートキーに先頭ゼロを付けて固定幅に埋め、文字列としての辞書順が数値順と一致するようにすること。これがないと "10" が "2" より前に並びます。 コンセプトを学ぶ →
ソートキー
複合プライマリキーの任意の後半部分。同じパーティションキーを共有するアイテムはソートキー順に格納されるため、範囲クエリ（begins_with、between、>）が安価になります。 コンセプトを学ぶ → DynoTable で見る →
タイプ属性
各アイテムに刻まれる単純な文字列で、そのアイテムが表すエンティティを示します（例: EntityType: "Document"）。混在パーティション内の行を識別し、オーバーロードされたインデックスを 1 つのエンティティに絞り込み、将来のマイグレーションを容易にします。 コンセプトを学ぶ →
タブ
DynoTable 内のブラウザ風に開いたワークスペース。各タブは独自のテーブル、クエリパターン、フィルタ、結果を保持します — 多数開いてキーボードで切り替えられます。 DynoTable で見る →
トライアル
全機能を使える期間限定の評価期間。終了すると、サブスクリプションを開始するまで DynoTable は読み取り専用に切り替わります。 DynoTable で見る →
トランザクション
1つ以上のテーブルにまたがる、オールオアナッシングの書き込み（または読み取り）のグループ — TransactWriteItems / TransactGetItems。すべての操作が成功するか、まったく成功しないかのいずれかです。 コンセプトを学ぶ → DynoTable で見る →
パーティションキー
テーブルのプライマリハッシュキー。DynamoDB はこれをハッシュ化してアイテムを格納する物理パーティションを選ぶため、効率的な読み取りはすべて1つのパーティションキー値を固定することから始まります。 コンセプトを学ぶ → DynoTable で見る →
バッチ操作
BatchWriteItem / BatchGetItem — 効率化のため、多数のアイテムを1回のラウンドトリップで処理します。トランザクションと違い、個々のアイテムは独立して成功または失敗できます。 コンセプトを学ぶ → DynoTable で見る →
フィルタ式
query または scan がアイテムを読み取った後に適用される条件。結果セットを絞り込みますが、読み取りコストは減らしません — それができるのはキー条件だけです。 コンセプトを学ぶ → DynoTable で見る →
プライマリキー
アイテムを一意に識別する属性。単純（パーティションキーのみ）または複合（パーティションキーとソートキーの組み合わせ）のいずれかです。 コンセプトを学ぶ → DynoTable で見る →
プロジェクション
インデックスにコピーされる属性の集合 — KEYS_ONLY、INCLUDE（選択した一部）、または ALL。プロジェクションに含まれない属性を読むと、ベーステーブルからの追加取得が発生します。 コンセプトを学ぶ →
プロジェクション式
読み取りから返す属性のリスト。これにより DynamoDB はアイテム全体ではなく、必要なフィールドだけを返します。 コンセプトを学ぶ →
プロビジョンドキャパシティ
固定の読み取り / 書き込みキャパシティユニットを設定する課金モード（必要に応じて自動スケール）。安定して予測可能な負荷では、オンデマンドより安価です。 コンセプトを学ぶ →
プロファイル
DynoTable に保存された AWS 認証情報の接続（アクセスキー、SSO、またはリージョンに対する引き受けロール）。プロファイルを切り替えると、アプリを別のアカウントや環境に向けられます。 DynoTable で見る →
ホットパーティション
あるパーティションキーが、その取り分のスループットでは処理しきれないほど多くの読み取りや書き込みを引き寄せ、テーブルの他の部分が空いているのにそのキーへのリクエストがスロットリングされる状態。サイズではなく、キー設計の問題です。 コンセプトを学ぶ →
マーシャリング
素の JSON を DynamoDB の型付きワイヤ形式（{"S":"…"}、{"N":"…"}）に変換し、また元に戻す（アンマーシャリング）こと。DynoTable はアイテムの編集や式の構築時に値を自動的にマーシャリングします。 コンセプトを学ぶ →
マシンハッシュ
ライセンスの2台までのマシン制限に対して、有効化されたデバイスを数えるために使われる、安定した匿名のコンピュータの指紋。個人データは一切含みません。 DynoTable で見る →
ローカルセカンダリインデックス (LSI)
テーブルのパーティションキーを共有しつつ、異なるソートキーを使うインデックス。テーブル作成時にのみ定義でき、強い整合性の読み取りをサポートします。 コンセプトを学ぶ → DynoTable で見る →
並列 Scan
単一の Scan を N 個の独立した Segment 読み取りに分割し、複数のワーカーが同時に 1 つのテーブルを読み取れるようにすること。単一パーティションのスループットが許す以上の速さでテーブル全体を読み取る唯一の方法です。 コンセプトを学ぶ →
再インデックス
自動補完と統計を支えるために、テーブルの実際のフィールドと値のサンプルをカタログ化する DynoTable のバックグラウンドスキャン。ローカルで実行され、データを一切変更しません。 DynoTable で見る →
参照カウント
親アイテムに保存される非正規化されたカウント（投稿への「いいね」、ワークスペースのメンバー数など）で、子が書き込まれるたびに更新されるため、読み取り側が数える必要がありません。トランザクションを使い、二重カウントを防ぎます。 コンセプトを学ぶ →
属性
アイテム上の1つの型付きフィールド（文字列、数値、バイナリ、ブール、リスト、マップ、セット、または null）。同じテーブル内のアイテムが同じ属性を持つ必要はありません。 コンセプトを学ぶ → DynoTable で見る →
強い整合性の読み取り
最新のコミット済み書き込みを返すことが保証された読み取り。テーブルと LSI で利用でき（GSI では不可）、結果整合性の読み取りの2倍のコストがかかります。 コンセプトを学ぶ →
更新式
アイテム全体を上書きするのではなく、書き込みがアイテムをどう変更するかを指定する句 — 特定の属性に対する SET、REMOVE、ADD、または DELETE です。 コンセプトを学ぶ → DynoTable で見る →
条件式
書き込みが成功するために満たされなければならない述語（条件付き書き込み） — 例えば「このアイテムがまだ存在しない場合のみ」。DynoTable はこれを使ってステージした編集を安全にコミットします。 コンセプトを学ぶ → DynoTable で見る →
結果整合性の読み取り
デフォルトの読み取りモード。書き込み直後に一時的に古いデータを返すことがありますが、強い整合性の読み取りの半分のコストです。レプリカは1秒以内に収束します。 コンセプトを学ぶ →
複合キー
パーティションキーとソートキーで構成されるプライマリキー。1つのパーティションキーの下に多数のアイテムを持たせ、ソートされたコレクションとしてアクセスできるようにします。 コンセプトを学ぶ → DynoTable で見る →
読み取り専用モード
DynoTable で閲覧とクエリはできるが、書き込み（アイテムの保存、ステージのコミット、削除）はブロックされる状態。トライアル / ライセンスの期限切れ、または明示的に読み取り専用にしたビューによってトリガーされます。 DynoTable で見る →
隣接リスト
グラフを通常のアイテムとして保存する方法で、各エッジはその始点をパーティションキーに、終点をソートキーにキー付けします。単一の Query でノードの隣接ノードを列挙でき、結合テーブルを join する代わりとなる DynamoDB 流のやり方です。 コンセプトを学ぶ →
非正規化
読み取りで join を不要にするために、データを意図的に複製する、または複雑な属性に埋め込むこと。書き込み時に事前結合し、より慎重な書き込みと引き換えに、1 リクエストで済む安価な読み取りを得ます。 コンセプトを学ぶ →

更新日