Q: Amazon DynamoDB とは何ですか?

Amazon DynamoDB は、完全マネージド型の NoSQL データベースサービスであり、高速で予測可能なパフォーマンスとシームレスな拡張性が特長です。Amazon DynamoDB を使用すると、分散データベースの運用と AWS にスケーリングするための管理負荷を軽減できます。顧客はハードウェアのプロビジョニング、設定と構成、レプリケーション、ソフトウェア修正プログラムの適用、クラスターのスケーリングなどについて心配する必要がありません。

Q: Amazon DynamoDB は私に代わって何を管理してくれますか?

Amazon DynamoDB により、データベースの拡張、データベースソフトウェアの管理、およびハードウェアの実行に必要なプロビジョニングに伴う主な障害の 1 つが取り除かれます。顧客は非リレーショナルデータベースをほんの数分で展開できます。テーブルサイズを拡大したりプロビジョニングされたスループットを増やすと、データのパーティション化や再パーティション化、追加サーバー容量のプロビジョニングが DynamoDB により自動的に行われます。さらに、Amazon DynamoDB では、同じ AWS リージョン内の 3 つの施設間でデータが同期的にレプリケートされるので、可用性とデータ耐久性が高まります。

Q: 読み込み整合性とは何ですか? なぜ気にかける必要があるのですか?

Amazon DynamoDB では、地理的に分散した 3 つの場所に各テーブルのレプリカが保存されるので、可用性とデータ耐久性が高まります。読み込みの整合性とは、書き込みの成功またはデータ項目の更新が、その同一項目に対するその後の読み込み処理において反映される、方法とタイミングを表します。Amazon DynamoDB ではロジックを公開しており、お客様のアプリケーション内の各読み込みリクエストに、希望する整合性特性を指定できるようにしています。

Q: Amazon DynamoDB の整合性モデルとは何ですか?

Amazon DynamoDB からデータを読み込むとき、ユーザーはその読み込みに対して結果的に整合性のある読み込みを設定するか強い整合性を設定するかを指定できます。

結果的に整合性のある読み込み (デフォルト) – 結果整合性のあるオプションを選択すると、読み込みスループットが最大限に向上します。ただし、結果的に整合性のある読み込みには、最新の書き込み結果が反映されない可能性があります。データの全コピーの整合は通常 1 秒以内に行われます。短時間後に読み込みを繰り返すことによって、更新されたデータが返されます。

強い整合性の読み込み – Amazon DynamoDB には結果整合性のある読み込みに加えて、お客様のアプリケーションまたはアプリケーションの要素が必要とする場合に、強い整合性のある読み込みをリクエストするための、柔軟性と制御が用意されています。強い整合性のある読み込みの結果には、読み込みの前に適切な応答を受け取ったすべての書き込みが反映されています。

Q: DynamoDB では、インプレースアトミック更新がサポートされていますか?

Amazon DynamoDB では、高速なインプレース更新がサポートされています。1 回の API 呼び出しを使用して、1 行の数値属性をインクリメントまたはデクリメントできます。同様に、セット、リスト、マップの追加や削除もアトミックに実行できます。アトミック更新の詳細については、Amazon のドキュメントを参照してください。

Q: Amazon DynamoDB が SSD (Solid State Drive) を使用しているのはなぜですか?

Amazon DynamoDB は SSD(Solid State Drive)でのみ実行されます。SSD は、あらゆる規模のデータの格納およびアクセスに対して、予測可能で低遅延な応答時間を実現するのに役立ちます。また、I/O パフォーマンスが高いので、大容量のリクエスト負荷に対して効率的にサービスを提供でき、リクエストのコストを低く抑えられます。

Q: DynamoDB の保存コストは高いようです。今のユースケースでコスト効果の高いサービスを実現することはできますか?

すべての製品についてそうですが、Amazon DynamoDB の採用をお考えのお客様には、1 つの角度からみた価格だけではなく、ソリューション全体のコストを考慮していただくようお願いしています。データベース負荷に対するサービスを提供する総コストは、リクエストトラフィック要件と保存されているデータ量に基づきます。データベース負荷の多くは、GB あたり高い I/O(高い読み込み/秒および書き込み/秒)を格納する必要があります。Amazon DynamoDB は SSD ドライブに基づいているため、スピニングメディアに比べると GB あたりの格納コストが高くなっていますが、リクエストのコストは大幅に削減できます。標準のデータベース負荷から判断すると、SSD ベースの DynamoDB サービスの総使用コストは、通常、標準のスピニングメディアベースのリレーショナルデータベースまたは非リレーショナルデータベースの使用コストよりも低く抑えられるはずです。ただし、ほとんどアクセスしないデータを大量に格納する必要がある事例では、この DynamoDB は適さない可能性があります。このような場合は、S3 をご利用になることをお勧めします。

保存コストには、AWS リージョン内の複数の施設に各データ項目のコピーを複数格納するコストが含まれることにも注意が必要です。

Q: DynamoDB は大規模アプリケーションのみを対象としていますか?

いいえ。DynamoDB は、小規模なアプリケーションから開始し、ニーズに応じて拡大/縮小できるようにシームレスな拡張機能をサポートしています。DynamoDB は、規模を問わず予測可能な優れたパフォーマンスが必要な場合に適しています。

Q: どのように Amazon DynamoDB の利用を開始できますか?

[今すぐ申し込む] をクリックして、Amazon DynamoDB を今日から使い始めましょう。そのページから、AWS Management Console または Amazon DynamoDB API のいずれかを使用して Amazon DynamoDB の操作を開始できます。AWS Management Console を使用する場合は、数回クリックするだけで、Amazon DynamoDB でテーブルを作成して使用できるようになります。

Q: DynamoDB ではどのようなクエリ機能がサポートされていますか?

Amazon DynamoDB では、ユーザー定義プライマリキーを使用した GET/PUT オペレーションがサポートされています。プライマリキーはテーブル内の項目の唯一の必須属性で、各項目を一意に識別します。このプライマリキーは、テーブルを作成するときに指定します。それに加え、DynamoDB は、グローバルセカンダリインデックスとローカルセカンダリインデックスを使用してプライマリキー以外の属性をクエリすることができる、柔軟なクエリ機能を提供しています。

プライマリキーは、単一属性パーティションキーまたは複合パーティションソートキーのいずれかになります。例えば、“UserID” は単一属性パーティションのプライマリキーです。これにより、指定されたユーザー ID に関連付けられた項目のデータをすばやく読み込んだり書き込んだりできます。

複合パーティションソートキーは、パーティションキー要素およびソートキー要素としてインデックス化されます。このマルチパートキーにより、1 番目の要素値と 2 番目の要素値の間の階層が維持されます。例えば、複合パーティションソートキーは、“UserID” (パーティション) と “Timestamp” (ソート) の組み合わせにすることができます。パーティションキー要素を一定に保つことで、ソートキー要素を検索して項目を取得することができます。これにより、クエリ API を使用して、例えば、単一の UserID のすべての項目をタイムスタンプの範囲にわたって取得できます。

グローバルセカンダリインデックスとそのクエリ機能の詳細については、よくある質問の「セカンダリインデックス」セクションをご覧ください。

 

Q: Amazon DynamoDB ではデータ項目に対する更新およびクエリをどのように実行しますか?

AWS Management Console または CreateTable API を使用してテーブルを作成したら、PutItem API または BatchWriteItem API を使用して項目を挿入できます。テーブルに追加した項目は、GetItem や BatchGetItems を使用して、または Query API を使用して (テーブルで複合プライマリキーが有効化されており使用されている場合) 取得できます。

Q: Amazon DynamoDB では条件付き演算がサポートされていますか?

はい。対象の項目で実行する挿入、更新、または削除オペレーションに対して条件を指定できます。条件付きオペレーションを実行するには、次から構成される ConditionExpression を定義できます。

  • ブール関数の ATTRIBUTE_EXIST、CONTAINS、BEGINS_WITH
  • 比較演算子の =、<>、=、BETWEEN、IN
  • 論理演算子の NOT、AND、OR 

ネストされた句を含む複数の条件句を組み合わせた、自由形式の条件式を構成できます。条件付き演算を使用すると、DynamoDB でオプティミスティック同時実行制御システムを実装できます。条件付きオペレーションの詳細については、 Amazon のドキュメントを参照してください

Q: キー条件で式はサポートされていますか?

はい。式をクエリ API 呼び出しの一部として指定し、KeyConditionExpression パラメータを使用してテーブルのプライマリキーの値に基づいて結果をフィルタリングすることができます。

Q: パーティションおよびパーティションソートキーで式はサポートされていますか?

はい。パーティションおよびパーティションソートキーの両方で式を使用できます。パーティションおよびパーティションソートキーで機能する式に関する詳細については、ドキュメントページを参照してください。

Q: Amazon DynamoDB ではインクリメント演算またはデクリメント演算がサポートされていますか?

はい。Amazon DynamoDB では、スカラー値でアトミックなインクリメント演算とデクリメント演算を行うことができます。

Q: Amazon DynamoDB、もしくは Amazon RDS または Amazon EC2 でのリレーショナルデータベースエンジンは、どのような場合に使用しますか?

今日のウェブベースのアプリケーションでは、大量のデータが生成および使用されます。例えば、開始当初はわずか数千人のユーザーしかいなかったオンラインゲームがあるとします。データベースの負荷も1秒あたりの書き込み数が10、読み込み数が 50 で取るに足りませんでした。しかし、ゲームが多くの人に受け入れられると、ユーザー数はあっという間に数百万に膨れ上がり、1秒あたりの書き込みおよび読み込み数は何万(場合によっては何十万)に増えることがあります。また、1 日に作成されるデータ量は数テラバイトを超えるかもしれません。Amazon DynamoDB のアプリケーションを開発すると、小さな規模から始めて、要件に応じてダウンタイムなしでテーブルのリクエスト容量を調整できます。プロビジョニングしたリクエスト容量に対してコスト効果の高い料金をお支払いいただくと、Amazon DynamoDB が、お客様のニーズ応じてデータとトラフィックをパーティション化して十分なサーバー容量に分散します。データベースの管理は Amazon DynamoDB が行うので、お客様はデータを格納しリクエストするだけです。また、自動レプリケーションとフェイルオーバーにより、フォールトトレランス、高い可用性、そしてデータ堅牢性を備えています。Amazon DynamoDB によって、データベースが完全に管理され、アプリケーションの要件に応じて拡大できるという安心感を得られます。

Amazon DynamoDB はデータベースの拡張性、管理、パフォーマンス、および信頼性に関する主な問題に対処しますが、リレーショナルデータベースのすべての機能が用意されているわけではありません。複雑なリレーショナルクエリ(結合など)やトランザクションはサポートされていません。この機能が必要な場合、または既存のリレーショナルエンジンと対応させたい場合は、Amazon RDS または Amazon EC2 でリレーショナルエンジンを実行することができます。リレーショナルデータベースエンジンには堅牢な機能が用意されていますが、1 つのリレーショナルデータベースインスタンスを越えて負荷を拡張する作業は複雑で、かなりの時間がかかります。また専門知識も必要です。したがって、新しいアプリケーションで拡張が必要な場合、リレーショナル機能が不要であれば、Amazon DynamoDB を使用することをお勧めします。

Q: Amazon DynamoDB と Amazon SimpleDB の違いは何ですか?

どちらを使用するべきですか?どちらのサービスも非リレーショナルデータベースで、データベース管理作業が不要です。Amazon DynamoDB は、シームレスな拡張性と迅速で予測可能なパフォーマンスを提供することに焦点を当てています。遅延の少ない応答時間を実現するために SSD(Solid State Disk)で実行され、1 つのテーブルのリクエスト容量と保存容量に制限はありません。これは、拡張の要件に合わせて、ご利用のデータと負荷が十分な数のサーバーに分散されるよう Amazon DynamoDB によって自動的にパーティション化されるからです。一方、Amazon SimpleDB テーブルには保存容量に厳格な制限があり 10GB までしか保存できません。また、リクエスト容量も制限されています(通常は 25 書き込み/秒)。追加拡張の必要が出てきた場合、追加の SimpleDB テーブルでのデータのパーティションまたは再パーティションの管理はお客様が行います。SimpleDB は拡張制限がありますが、クエリに柔軟性が必要で、負荷が少ない場合は適しているかもしれません。Amazon SimpleDB では、すべての項目属性が自動的にインデックス化されるので、クエリの柔軟性はサポートされますが、代わりにパフォーマンスと拡張性が低下します。

Amazon における非リレーショナルデータベーステクノロジー革新の詳細については、Amazon CTO である Werner Vogels 氏の DynamoDB ブログの投稿を参照してください。

Q: Amazon DynamoDB と Amazon S3 はどのように使い分けますか?

Amazon DynamoDB には、プライマリキーによってインデックス化された構造化データが格納され、1 バイト~ 400 KB の項目に対して低レイテンシーでの読み込みおよび書き込みアクセスが可能です。Amazon S3 には非構造化 Blob が格納されます。これは最大 5TB の大きなオブジェクトを格納するのに適しています。AWS サービスのコストを最適化するには、大きなオブジェクトまたはアクセス頻度の少ないデータは Amazon S3 に格納します。一方、比較的小さなデータ要素またはファイルポインタ(Amazon S3 オブジェクトへのポインタなど)は Amazon DynamoDB に格納することをお勧めします。

Q: DynamoDB は、どのオペレーティングシステムで実行するアプリケーションでも使用できますか?

はい。DynamoDB は、API を介してアクセスする完全マネージド型のクラウドサービスです。DynamoDB は、どのオペレーティングシステム(例: Linux、Windows、iOS、Android、Solaris、AIX、HP-UX など)で実行するアプリケーションでも使用できます。DynamoDB の使用を開始するには、AWS SDK の使用をお勧めします。AWS SDK の一覧は、開発者用リソースのページにあります。SDK のインストールや使用に問題がある場合は、該当する AWS フォーラムに投稿してお知らせください。


Q: データモデルとは何ですか?

Amazon DynamoDB のデータモデルは次のとおりです。

テーブル: データ項目のコレクションです。リレーショナルデータベースのテーブルが行のコレクションであるのと同様です。各テーブルのデータ項目の数に制限はありません。Amazon DynamoDB はスキーマレスです。テーブルのデータ項目の属性および属性数は同じである必要はありません。各テーブルにはプライマリキーが必要です。プライマリキーは、単一属性キー、または 2 つの属性が組み合わされた「複合」属性キーです。プライマリキーはテーブル内の各項目を一意に識別するので、プライマリキーに指定する属性はすべての項目で存在していなければなりません。

項目: プライマリキーまたは複合キー、および任意の数の属性で構成されます。個別の項目に関連付けられる属性の数に明示的な制限はありませんが、1 つの項目の合計サイズ (すべての属性名と属性値を含む) は 400 KB を超えることはできません。

属性: データ項目に関連付けられる各属性は属性名(「Color」など)と 1 つの値(「Red」など)または値セット(「Red、Yellow、Green」など)で構成されます。各属性のサイズに明示的な制限はありませんが、1 つの項目の合計サイズ(すべての属性名と値を含む)が 400 KB を超えることはできません。

Q: 項目のサイズに制限はありますか?

1 つの項目の合計サイズ(すべての属性名と属性値を含む)は 400 KB を超えることはできません。

Q: 項目に設定できる属性の数に制限はありますか?

項目に設定できる属性の数に制限はありません。ただし、1 つの項目の合計サイズ(すべての属性名と属性値を含む)は 400 KB を超えることはできません。

Q: API とは何ですか?

  • CreateTable – テーブルを作成し、データアクセスに使用するプライマリインデックスを指定します。
  • UpdateTable – 指定されたテーブルのプロビジョニングされたスループット値を更新します。
  • DeleteTable – テーブルを削除します。
  • DescribeTables – テーブルサイズ、ステータス、およびインデックス情報を返します。
  • ListTables – 現在のアカウントおよびエンドポイントに関連付けられたすべてのテーブルのリストを返します。
  • PutItem – 新しい項目を作成するか、古い項目を (すべての属性を含め) 新しい項目で置き換えます。指定したテーブルに同じプライマリキーを持つ項目が存在する場合、既存の項目は新しい項目に完全に置き換えられます。条件付き演算子を使用して、所定の条件に一致する属性値を持つ項目のみを置き換えたり、その項目が存在しない場合にのみ新しい項目を挿入したりすることもできます。
  • BatchWriteItem – 1 回のトランザクションとしてではなく、1 回のリクエストにより複数のテーブル間で複数の項目を挿入、置換、削除します。Put または Delete で最大 25 項目のバッチをサポートし、合計リクエストサイズは最大 16 MB です。
  • UpdateItem – 既存の項目の属性を編集します。条件付き演算子を使用して、項目の属性値が所定の条件に一致する場合にのみ更新を実行することもできます。
  • DeleteItem – プライマリキーを使用してテーブルから 1 つの項目を削除します。条件付き演算子を使用して、項目の属性値が所定の条件に一致する場合にのみ項目を削除することもできます。
  • GetItem – GetItem 演算は、プライマリキーに一致する項目の属性セットを返します。GetItem 演算は、デフォルトでは、結果的に整合性のある読み込みを提供します。ご利用のアプリケーションで結果的に整合性のある読み込みを使用できない場合は、ConsistentRead を使用します。
  • BatchGetItems – BatchGetItems 演算は、複数の項目の属性を複数のテーブルから、それぞれのプライマリキーを使用して返します。16 件の応答のサイズ制限は 1 MB で、最大 100 個の項目を返します。強い整合性と結果整合性の両方をサポートします。
  • Query – テーブルのプライマリキーを使用して、または、セカンダリインデックスからインデックスキーを使用して、1 つ以上の項目を取得します。比較演算子や式を使用すると、テーブルのクエリの範囲を絞りこむことができます。また、非キー属性に対してフィルタを使用することで、クエリ結果をフィルタリングすることもできます。強い整合性と結果整合性の両方をサポートします。応答 1 件あたりのサイズ上限は 1 MB です。
  • スキャン – テーブルまたはセカンダリインデックスの全体をフルスキャンして、すべての項目および属性を取得します。リターンセットを制限するには、1 つまたは複数の属性と照合するフィルタを指定します。

Q: スキャンオペレーションの整合性モデルとは?

スキャンオペレーションでは、結果整合性および整合性のある読み込みがサポートされています。デフォルトでは、スキャンオペレーションは結果整合性です。ただし、整合性モデルはスキャン API 呼び出しのオプションの ConsistentRead パラメータを使用して変更できます。ConsistentRead パラメータを true に設定すると、スキャンオペレーションを整合性のある読み込み操作にすることができます。詳細については、スキャンオペレーションのドキュメントを参照してください。

Q: スキャンオペレーションはどのように作動しますか?

スキャンオペレーションはイテレータと考えることができます。指定したスキャン API リクエストに対してスキャンされた項目の合計サイズが 1 MB の制限を超えると、指定されたリクエストは終了し、取得された結果は(以降のオペレーションでスキャンを続行できるように)LastEvaluatedKey と共に返されます。

Q: スキャンオペレーションに制限はありますか?

テーブルまたはセカンダリインデックスへのスキャンオペレーションあたり、1 MB のデータ制限があります。1 MB の制限を超えると、スキャンオペレーションは終了し、その時点までに一致した値と、以降のオペレーションに適用される LastEvaluatedKey が返され、中止した場所がわかります。

Q: スキャンオペレーションではいくつの読み込み容量ユニットが使用されますか?

必要な読み込みユニットは、スキャンオペレーションで取得されたバイト数を直近の 4 KB 単位に切り上げて 4 KB で除算したものです。整合性のある読み込みでテーブルをスキャンすると、結果的に整合性のある読み込みでスキャンしたときの 2 倍の読み込み容量が消費されます。

Q: DynamoDB ではどのようなデータ型がサポートされていますか?

DynamoDB は、数値、文字列、バイナリ、ブールの 4 種類のスカラーデータ型をサポートします。また DynamoDB は、数値セット、文字列セット、バイナリセット、異種データ型リスト、異種データ型マップの各コレクションデータ型をサポートします。DynamoDB は NULL 値もサポートします。

Q: DynamoDB はどのような型のデータ構造をサポートしますか?

DynamoDB はキー値および文書データ構造をサポートします。

Q: キー値ストアとは何ですか?

キー値ストアはデータベースサービスの 1 つで、格納される実内容を含むキーと値を使用して、特定対象となるオブジェクトのコレクションの保存、クエリ、更新をサポートします。

Q: 文書ストアとは何ですか?

文書ストアは、JSON、XML、HTML などの文書形式の項目の保存、クエリ、更新をサポートします。

Q: DynamoDB には JSON データ型は含まれますか?

いいえ。ただし、文書 SDK を使用して JSON データを直接 DynamoDB に渡すことができます。DynamoDB のデータ型は、JSON によってサポートされるデータ型の上位集合です。文書 SDK は JSON 文書をネイティブの DynamoDB データ型に自動的にマッピングします。

Q: AWS マネジメントコンソールを使用して JSON 文書を表示、編集できますか?

はい。AWS マネジメントコンソールのシンプルな UI を使って、DynamoDB テーブルに保存されている JSON 文書などのデータを解析、編集できます。テーブルのデータを表示、編集するには、AWS マネジメントコンソールにログインし、DynamoDB を選び、表示するテーブルを選択して、[Explore Table] ボタンをクリックします。

Q: DynamoDB での JSON データのクエリに何か違いはありますか?

いいえ。最上位の JSON 要素で、グローバルセカンダリインデックスまたはローカルセカンダリインデックスを作成できます。たとえば、ある個人についての姓、名、郵便番号、友人全員のリストの情報を含む JSON 文書を保存したとします。姓、名および郵便番号は最上位の JSON 要素です。インデックスを作成することで、姓、名または郵便番号に基づいてクエリを実行できます。友人のリストは最上位の要素ではないので、友人リストにインデックスを作成することはできません。グローバルセカンダリインデックスとそのクエリ機能の詳細については、よくある質問の「セカンダリインデックス」セクションをご覧ください。

Q: ネストされた JSON データが DynamoDB に含まれる場合、そのデータの特定要素のみを検索できますか?

はい。GetItem、BatchGetItem、Query、または Scan API を使用するとき、ProjectionExpression を定義してテーブルからどの属性を検索するかを指定できます。これらの属性には、JSON 文書のスカラー、セット、または要素が含まれます。

Q: ネストされた JSON データが DynamoDB に含まれる場合、そのデータの特定要素のみを更新できますか?

はい。DynamoDB の項目を更新するとき、更新対象となる JSON 文書の下位要素を指定できます。

Q: 文書 SDK とは何ですか?

文書 SDK は、JS データ型と DynamoDB データ型間の相互運用性を高める JavaScript のデータ型ラッパーです。この SDK により、リクエストが自動的にラップされます。同様にレスポンスについても、データ型がアンラップされます。詳細および SDK のダウンロードについては、こちらの GitHub リポジトリを参照してください。

 


Q: Amazon DynamoDB に保存できるデータ量に制限はありますか?

いいえ。Amazon DynamoDB テーブルで保存できるデータ量の制限はありません。データセットのサイズが増えると、Amazon DynamoDB では、保存要件に対応するために十分な数のマシンリソースにデータが自動的に分散されます。

Q: 1 つのテーブルから取得できるスループットの量に制限はありますか?

いいえ。テーブルのプロビジョニングしたスループットは、UpdateTable API または AWS Management Console を使用して増やすことができます。DynamoDB は大規模な動作が可能であり、実現できる最大スループットに理論的な制限はありません。DynamoDB ではテーブルが複数のパーティションに自動的に分割されます。各パーティションは、独立した並列計算ユニットです。DynamoDB でスループットを増やすには、パーティションを追加します。

スループットレートが 10,000 書き込み/秒または 10,000 読み込み/秒を超える場合は、こちらのオンラインフォームを使用して事前に Amazon までご連絡ください。

Q: DynamoDB のスケールアップまたはスケールダウン (プロビジョニングされたスループットの変更) 時に、Amazon DynamoDB は引き続き利用できますか?

はい。Amazon DynamoDB は、利用できるようにしたままで、プロビジョニングされたスループットを拡大または縮小できるように設計されています。

Q: Amazon DynamoDB でクライアント側のパーティションを管理する必要がありますか?

いいえ。Amazon DynamoDB では、スループット拡張の目的でデータベーステーブルをパーティション化する必要はありません。

Q: Amazon DynamoDB の高い可用性はどのように実現されていますか?

このサービスは、高い可用性を備えた実績のある Amazon のデータセンターで実行されます。このサービスでは、データが同じ AWS リージョン内の 3 つの施設間でレプリケートされるので、サーバー障害の発生やアベイラビリティーゾーンの停止に対する耐障害性が高まります。

Q: Amazon DynamoDB の高い稼働率と耐久性はどのように実現されていますか?

高い稼働率と耐久性を実現するために、Amazon DynamoDB では、同じ AWS リージョン内の 3 つの施設間でデータが同期的にレプリケートされます。


Q: グローバルセカンダリインデックスとは何ですか?

グローバルセカンダリインデックスとは、パーティション、またはパーティション/ソートキーを含んでいるインデックスで、テーブルのプライマリキーとは異なります。

テーブル内のデータに効率的にアクセスするため、Amazon DynamoDB はプライマリキー属性用にインデックスを作成して維持します。このため、アプリケーションはプライマリキーの値を指定することで、迅速にデータを取得することができます。しかし多くのアプリケーションでは、プライマリキー以外の属性を使って、データに効率的にアクセスできるようにするセカンダリ(または代替)キーを 1 つ以上設定することで、メリットが得られることがあります。これに対応するために、1 つのテーブルで 1 つ以上のセカンダリインデックスを作成して、それらのインデックスに対してクエリリクエストを実行することができます。

Amazon DynamoDB は、次の 2 種類のセカンダリインデックスをサポートしています。

  • ローカルセカンダリインデックス – テーブルとパーティションキーは同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が、同じパーティションキーを持つテーブルパーティションに限定されるという意味で "ローカル" です。
  • グローバルセカンダリインデックス – テーブルとはパーティションキーまたはパーティション/ソートキーが異なるインデックスです。グローバルセカンダリインデックスは、インデックスに関するクエリが、すべてのパーティションにまたがり、表内のすべての項目を対象とする可能性があるため、「グローバル」と見なされます。 

セカンダリインデックスは、スパース型オブジェクトとして、Amazon DynamoDB が自動的に保持します。項目は、インデックスの定義元のテーブル内に存在する場合のみ、表示されます。このため、インデックスに対するクエリは非常に効率的に実行されます。これは、インデックス内の項目数が、大抵の場合、テーブル内の項目数と比べて非常に少ないためです。

グローバルセカンダリインデックスは、一意でない属性をサポートしているため、テーブル内の非キー属性に対するクエリを有効にすることで、クエリの柔軟性が向上します。

プライマリキーが UserId (パーティション) と GameTitle (ソート) で構成されている DynamoDB テーブルに、プレーヤーの情報を保存するゲームアプリケーションを検討してみましょう。項目には、TopScoreTimestampZipCode などの属性名が付けられています。テーブルの作成時、プライマリキーに関する暗黙的なインデックス(プライマリインデックス)を提供します。このプライマリキーにより、DynamoDB は効率的なクエリをサポートし、特定ユーザーのすべてのゲームに関するハイスコアを返すことができます。

ただし、アプリケーションが特定のゲームに関するユーザーのハイスコアを必要とする場合にプライマリインデックスを使用すると、テーブル全体のスキャンが必要になり、効率が悪くなります。その代わり、パーティションキー要素として GameTitle を、ソートキー要素として TopScore を指定してグローバルセカンダリインデックスを使用することにより、アプリケーションは、ゲームのハイスコアを短時間で取得できます。

GSI はソートキー要素を必要としません。例えば、パーティション要素である GameTitle のみのキーを持つ GSI を設定できます。次の例では、GSI には射影された属性がないため、クエリ対象の GameTitle と一致する属性を持つすべての(プライマリキーによって識別された)項目だけが返されます。

Q: グローバルセカンダリインデックスはいつ使うのですか?

グローバルセカンダリインデックスは、多数の異なる値が存在する属性間の関係を追跡する場合に特に便利です。例えば、テーブルのプライマリパーティションキーとして CustomerID を、グローバルセカンダリインデックスのパーティションキーとして ZipCode を持つ DynamoDB テーブルを作成できます。郵便番号は多数存在し、お客様の数も多数存在するためです。プライマリキーを使用して、任意のお客様に対するレコードをすばやく取得することができます。グローバルセカンダリインデックスを使用すると、特定の郵便番号の地域内に住んでいるすべてのお客様に対して、効率的なクエリを実行することができます。

グローバルセカンダリインデックスの能力を最大限に活用できるように、均一なワークロードに関するベストプラクティスのドキュメントを参照してください。

Q: DynamoDB テーブル用にグローバルセカンダリインデックスを作成するにはどうすればいいですか?

テーブルに関連付ける GSI はいつでも指定できます。テーブルとそのインデックスの作成に関する詳細な手順は、こちらを参照してください。1 テーブルにつき、最大 5 つのグローバルセカンダリインデックスを作成できます。

Q: DynamoDB のローカルバージョンはグローバルセカンダリインデックスをサポートしますか?

はい。DynamoDB のローカルバージョンは DynamoDB をベースとするアプリケーションの開発とテストに役立ちます。DynamoDB のローカルバージョンは、こちらからダウンロードできます。

Q: 射影された属性とは何ですか?

セカンダリインデックスのデータは、テーブルからインデックスへ射影(つまりコピー)された属性から構成されています。セカンダリインデックスを作成する場合、インデックスの代替キーと、インデックスに射影されたその他の属性を定義します。Amazon DynamoDB は、これらの属性とプライマリキー属性をテーブルからインデックスにコピーします。次に、テーブルに対してクエリを実行する場合と同様に、インデックスに対してクエリを実行します。

Q: グローバルセカンダリインデックスキーを、一意でない属性に対して定義できますか?

はい。テーブルに関するプライマリキーとは異なり、GSI インデックスはインデックス対象の属性が一意である必要はありません。例えば GameTitle に関する GSI では、すべてのゲームでユーザーのスコアを追跡するすべての項目に対して、インデックスを作成できます。この例では、GSI に対してクエリを実行すると、ゲーム「TicTacToe」をプレイしたことがあるすべてのユーザーが返されます。

Q: グローバルセカンダリインデックスは、ローカルセカンダリインデックスとどのような点が異なりますか?

グローバルとローカルのセカンダリインデックスはどちらも、クエリの柔軟性を向上させます。LSI が特定のパーティションキーの値に関連付けられるのに対して、GSI はすべてのパーティションキーの値が対象となります。パーティションキーの値が同じ項目は、DynamoDB の同じパーティションを共有しているため、"ローカル" セカンダリインデックスは (同じパーティションに) 一緒に保存される項目のみを対象とします。つまり LSI の目的は、パーティションキーの値が同じで、ソートキーの値が異なる項目に対してクエリを実行することです。例えば、お客様の注文を追跡する DynamoDB テーブルを検討してみましょう。この場合、CustomerId がパーティションキーです。

OrderTime に関する LSI では、効率的なクエリを実行して、特定のお客様が最後に注文した項目を取得することができます。

これとは対照的に、GSI は共通するパーティションキーの値を持つ項目のみに限定されません。その代わり、GSI はプライマリキーと同様、テーブルのすべての項目が対象となります。上記のテーブルの場合、ProductId に関する GSI を使って、特定の製品に関するすべての注文を効率的に検索できます。この場合、GSI のソートキーが指定されないこと、および同じ ProductId を持つ注文が複数存在する場合でも、GSI では個別の項目として保存されるという点に注意してください。

テーブル内のデータとインデックスが同じパーティションに一緒に配置されるようにするため、LSI はすべての要素 (テーブルとインデックス) の合計サイズを、パーティションキー値ごとに 10 GB に制限します。GSI はデータの Co-Location を実行しないため、このような制限はありません。

テーブルへの書き込みを行うと、DynamoDB は影響を受けるすべての LSI を自動的に更新します。これとは対照的に、テーブルに関して定義されているすべての GSI に対する更新は、結果的に整合されます。

LSI では、Query API を使って、射影リストに含まれていない属性を取得することができます。これは、GSI ではサポート対象外の動作になります。

Q: グローバルセカンダリインデックスはどのように動作しますか?

GSI の動作はさまざまな点で、DynamoDB テーブルの動作に似ています。GSI ソートキー要素に関する条件付きフィルターを指定し、パーティションキー要素を使用して、GSI に対するクエリを実行することができます。ただし、一意でなければならない DynamoDB テーブルのプライマリキーと異なる点は、GSI キーは複数の項目で同じ値を取ることができることです。GSI キーが同じ項目が複数存在する場合、これらの項目は個別の GSI 項目として追跡され、GSI クエリを実行すると、そのすべての個別の項目として取得されます。項目の追加、削除、または更新時、DynamoDB は内部的に、GSI の内容が適切に更新されたことを確認します。

DynamoDB は、GSI の射影された属性を、GSI キーおよび一致する項目のプライマリキーと一緒に、GSI データ構造内に保存します。GSI は、ソーステーブル内に存在する、射影された項目に対してストレージを使用します。このため、クエリはテーブルではなく、GSI に対して実行されることになり、クエリの柔軟性とワークロード分散が向上します。したがって、GSI インデックスへのクエリを実行した場合、テーブル内の項目に含まれていて、GSI キー、テーブルのプライマリキー、または射影された属性に含まれていない属性は返されません。GSI へのクエリ実行後、テーブルから追加データを必要とするアプリケーションは、GSI からプライマリキーを取得し、GetItem または BatchGetItem のいずれかの API で使用して、テーブルから目的の属性を取得することができます。GSI は最終的に整合されるため、このパターンを使用するアプリケーションは、GSI への呼び出しと GetItem/BatchItem への呼び出し間でテーブルから削除された項目を格納する必要があります。

DynamoDB は、テーブルに対して対応する変更が実行されると、GSI に対する項目の追加、更新、および削除を自動的に処理します。(GSI キー属性を持つ)項目をテーブルに追加すると、DynamoDB は GSI を非同期的に更新し、新しい項目を追加します。同様に、テーブルから項目を削除すると、DynamoDB は影響を受ける GSI から項目を削除します。

Q: パーティションベースのテーブルとパーティション/ソートスキーマのテーブルに対して、グローバルセカンダリインデックスを作成できますか?

はい、DynamoDB テーブルのプライマリキーの種類にかかわらず、グローバルセカンダリインデックスを作成できます。テーブルにはパーティションキーのみを格納することも、パーティションキーとソートキーの両方を格納することもできます。

Q: グローバルセカンダリインデックスの整合性モデルとは何ですか?

GSI は、結果整合性をサポートしています。テーブルに項目を挿入または更新すると、GSI の同期更新は実行されません。通常の動作条件では、グローバルセカンダリインデックスへの書き込みにかかる時間は 1 秒の数分の 1 です。可能性は低いものの、さらに長い遅延が発生する場合があります。このため、アプリケーションのロジックは、潜在的に期限切れとなる可能性がある GSI クエリ結果を処理できなければなりません。これは、結果整合性のある読み込みをサポートする他の DynamoDB API が示す動作と同じである点に注意してください。

属性 UserIdGameTitle、および TopScore で構成される各項目のハイスコアを追跡するテーブルを検討してみましょう。パーティションキーは UserId で、プライマリソートキーは GameTitle です。アプリケーションがGameTitle「TicTacToe」と UserId「GAMER123」の新しいトップスコアを示す項目を追加し、その後 GSI に関するクエリを実行した場合、新しいスコアがクエリの結果に表示されなくなる可能性があります。ただし GSI の伝搬が終了すると、新しい項目が GSI に関するクエリで表示されるようになります。

Q: テーブルと各グローバルセカンダリインデックスに対して、個別にスループットをプロビジョニングすることはできますか?

はい。GSI はベースとなるテーブルのスループットを個別に管理します。作成時に、テーブルと関連する各 GSI に対して、プロビジョニングするスループットを明示的に指定する必要があります。テーブルやインデックス間でスループット総計の分配を支援する DynamoDB コンソールテーブル作成ウィザードを使用できます。

アプリケーションによっては、GSI に関する要求ワークロードは、テーブルや他の GSI に関する要求ワークロードと大幅に異なることがあります。これを示すいくつかのシナリオを以下に示します。

  • 少数のテーブルの項目を含んでいる GSI の場合、テーブルと比べて、必要な書き込みスループットは大幅に小さくなります。
  • 項目のルックアップを頻繁に実行しない GSI の場合、テーブルと比べて、必要な読み込みスループットは大幅に小さくなります。
  • 読み込みが頻繁に実行されるバックグラウンドタスクが使用する GSI の場合、1 日数時間、高い読み込みスループットが必要となることがあります。

必要性が増大するにつれて、テーブルのプロビジョニングされたスループットにかかわらず、GSI のプロビジョニングされたスループットを変更できます。

すべての属性が射影された、全項目の 50% に GSI キーが存在する GSI を持つ DynamoDB テーブルを検討してみましょう。この場合、GSI の書き込みプロビジョニング容量ユニットを、テーブルの書き込みプロビジョニング容量ユニットの 50% に設定する必要があります。同様の方法を使って、GSI の読み込みスループットを見積もることができます。詳細については、DynamoDB GSI のドキュメントを参照してください。

Q: グローバルセカンダリインデックスを追加すると、テーブルのプロビジョニングされたスループットとストレージはどのような影響を受けますか?

DynamoDB テーブルと同じように、GSI は GSI への読み込みまたは書き込みが実行されると、プロビジョニングされたスループットを消費します。GSI 項目を追加または更新する書き込みは、更新サイズに基づいて、書き込み容量ユニットを消費します。GSI 書き込みが消費する容量は、テーブルの項目の更新に必要な容量に追加されます。

DynamoDB テーブルに対して項目の追加、削除、または更新を実行した際に、GSI への変更が発生しなかった場合、GSI は書き込み容量ユニットを消費しません。これは、GSI キー属性を持たない項目を DynamoDB に追加するか、GSI キーまたは射影された属性を変更せずに項目を更新した場合に発生します。

GSI へのクエリは、クエリの調査対象の項目サイズに基づいて、読み込み容量ユニットを消費します。

GSI のストレージコストは、対象の GSI に保存される総バイト数をベースにしています。これには、GSI キー、射影された属性とその値、およびインデックス作成用の 100 バイトのオーバーヘッドが含まれます。

Q: DynamoDB を使用した場合、GSI のプロビジョニングされたスループットが原因で、アプリケーションからテーブルへの書き込み速度が抑制されることはありますか?

DynamoDB テーブルへの一部またはすべての書き込みでは、関連する GSI への書き込みも行われるため、GSI のプロビジョニングされたスループットを使い果たしてしまう可能性があります。このようなシナリオでは、テーブルへの以降の書き込みは抑制されます。テーブルに使用可能な書き込み容量ユニットがある場合でも、このような事態が発生する可能性があります。

Q: インデックスレベルで、プロビジョニングされたスループットを変更できる頻度はどれ位ですか?

GSI が存在するテーブルには、スループット変更操作に関して、通常のテーブルと同じ日次制限があります。

Q: DynamoDB グローバルセカンダリインデックスの料金はどのように課金されますか?

テーブルとテーブルの GSI に対する集約プロビジョニングされたスループットが 1 時間単位で課金されます。さらに、GSI が占有するデータストレージと、標準のデータ転送(外部)料金が課金されます。GSI のプロビジョニングされたスループット容量を変更するには、DynamoDB コンソールまたは UpdateTable API を使用します。

Q: クエリに対して、どのグローバルセカンダリインデックスを使用するか指定することはできますか?

はい。一般的なクエリパラメータに加え、GSI Query コマンドは、操作対象の GSI 名を明示的に含みます。クエリは 1 つの GSI しか使用できないことに注意してください。

Q: グローバルセカンダリインデックスでは、どの API 呼び出しがサポートされていますか?

GSI がサポートする API 呼び出しは、QueryScan です。Query 操作はインデックスキー属性値だけを検索し、比較演算子のサブセットをサポートします。GSI は非同期で更新されるため、クエリでConsistentRead パラメータを使用することはできません。クエリとスキャンで GSI を使用する詳細については、こちらを参照してください。

Q: グローバルセカンダリインデックスへのスキャン結果は、どのような順序になりますか?

パーティションのみのキースキーマを持つグローバルセカンダリインデックスの場合、順序付けは行われません。パーティションソートキースキーマを持つグローバルセカンダリインデックスの場合、同じパーティションキーの結果は、ソートキー属性に基づいて順序付けされます。

Q: テーブル作成後、グローバルセカンダリインデックスを変更できますか?

はい。グローバルセカンダリインデックスは、テーブルの作成後でもいつでも変更できます。

Q: 既存のテーブルにグローバルセカンダリインデックスを追加するにはどうすればよいですか?

コンソールまたは API 呼び出しを使って、グローバルセカンダリインデックスを追加できます。DynamoDB コンソールで、まずグローバルセカンダリインデックスの追加先のテーブルを選択し、[Create Index] ボタンをクリックして新しいインデックスを追加します。インデックス作成ウィザードの手順に従い、完了したら [Create] を選択します。UpdateTable API 呼び出しと GlobalSecondaryIndexes パラメータを組み合わせて使って、グローバルセカンダリインデックスを追加/削除することもできます。詳細については、ドキュメントページを参照してください。

Q: グローバルセカンダリインデックスを削除するにはどうすればよいですか?

コンソールまたは API 呼び出しを使って、グローバルセカンダリインデックスを削除できます。DynamoDB コンソールで、グローバルセカンダリインデックスを削除するテーブルを選択します。次に、[Table Items] で [Indexes] タブを選択し、横にある [Delete] ボタンを使ってインデックスを削除します。UpdateTable API 呼び出しを使ってグローバルセカンダリインデックスを削除することもできます。詳細については、ドキュメントページを参照してください。

Q: 1 回の API 呼び出しで、同じテーブルの 1 つ以上のインデックスを追加/削除できますか?

1 回の API 呼び出しでは追加/削除できるのは、1 つのインデックスだけです。

Q: 同じインデックスを追加するための複数のリクエストを送信するとどうなりますか?

最初の追加リクエストだけが受け付けられ、最初の追加リクエストが完了するまで、その後の追加リクエストは失敗します。

Q: 同じテーブル上の数個のインデックスを同時に追加/削除できますか?

いいえ。1 つのテーブルで一度に行えるのは 1 つのインデックスの追加/削除操作だけです。

Q: グローバルセカンダリインデックスを追加するために、追加のスループットをプロビジョニングする必要がありますか?

必ずしも必要ではありません。ただし、インデックス用のスループットとは別に追加の書き込みスループットをプロビジョニングすることを強くお勧めします。追加の書き込みスループットをプロビジョニングしないと場合、新しいインデックスの追加には、インデックスの書き込みスループットが使用されます。これにより、インデックス作成中のインデックスの書き込みパフォーマンスに影響を及ぼし、新しいインデックスの作成にさらに時間がかかります。

Q: インデックスの作成後、グローバルセカンダリインデックスの追加スループットを減らす必要がありますか?

はい。インデックスの作成が完了したら、インデックス追加のためにプロビジョニングした追加の書き込みスループットを元に戻す必要があります。

Q: グローバルセカンダリインデックス追加のためにプロビジョニングした書き込みスループットを変更できますか?

はい。インデックス作成のためにプロビジョニングしたスループットは、作成中にいつでも調整できます。

Q: グローバルセカンダリインデックスの追加/削除中、テーブルを使用できますか?

はい。グローバルセカンダリインデックスの更新中もテーブルを使用できます。

Q: グローバルセカンダリインデックスの追加/削除中、既存のインデックスを使用できますか?

はい。グローバルセカンダリインデックスの更新中も既存のインデックスを使用できます。

Q: グローバルセカンダリインデックスの作成中、新しいインデックスを使用できますか?

いいえ。新しいインデックスは、インデックスの作成が完了すると使用可能になります。

Q: グローバルセカンダリインデックスの追加にかかる時間はどれくらいですか?

追加にかかる時間は、テーブルサイズと、グローバルセカンダリインデックスの作成にプロビジョニングされた追加の書き込みスループットの量によって異なります。インデックスの追加/削除にかかる時間は、数分から数時間まで大きく異なります。例えば、500 の書き込みキャパシティーユニットがプロビジョニングされた 1 GB のテーブルがあり、インデックスと新しいインデックス作成のために追加の書き込みキャパシティーを 1000 プロビジョニングしたとします。新しいインデックスにテーブルのすべての属性が含まれ、テーブルがすべての書き込みキャパシティーユニットを使用している場合、インデックスの作成にかかる時間は約 30 分です。

Q: グローバルセカンダリインデックスの削除にかかる時間はどれくらいですか?

インデックスの削除は通常、数分で完了します。例えば、1 GB のデータを持つインデックスの削除は通常 1 分未満で完了します。

Q: グローバルセカンダリインデックスの追加/削除操作の進行状況を追跡するにはどうすればよいですか?

テーブルに関連付けられているすべてのインデックスの状況を確認するには、DynamoDB コンソールまたは DescribeTable API を使用します。インデックスの追加操作の場合、インデックスの作成中、インデックスの状況は [CREATING] となります。インデックスの作成が完了すると、インデックスの状況は [CREATING] から [ACTIVE] に変わります。インデックスの削除操作の場合、リクエストが完了すると、削除されたインデックスは表示されなくなります。

Q: グローバルセカンダリインデックス追加のためのインデックス作成が完了したら通知を受け取ることはできますか?

インデックスの追加が完了したことを確認する通知を自分のメールアドレス宛てに送信するようリクエストすることができます。コンソールを使ってインデックスを追加する場合は、インデックス作成前の最後のステップで通知をリクエストできます。インデックス作成が完了すると、DynamoDB は指定されたメールアドレスに SNS 通知を送信します。

Q: すでに 5 つのローバルセカンダリインデックスがある場合に、もう 1 つ追加しようとするとどうなりますか?

GSI は現在 5 つまでに制限されています。[Add] 操作が失敗し、エラーが表示されます。

Q: 削除したインデックスの名前を、グローバルセカンダリインデックスで再使用できますか?

はい。グローバルセカンダリインデックスの削除後、新しいインデックスを追加する際にそのインデックス名を再使用できます。

Q: インデックスの作成中にインデックスの追加をキャンセルできますか?

いいえ。インデックスの作成プロセスが開始したら、作成プロセスをキャンセルすることはできません。

Q: DynamoDB のすべての項目で、GSI キー属性は必要ですか?

いいえ。GSI はスパース型インデックスです。プライマリキーの所有要件とは異なり、DynamoDB テーブル内の項目は GSI キーを含む必要がありません。GSI キーにパーティション要素とソート要素の両方が存在し、テーブルの項目でこの 2 つのいずれかが省略されている場合、対応する GSI によってその項目のインデックスが作成されることはありません。このような場合、一般的でない属性を持つ項目を効率的に特定するには、GSI が非常に有効です。

Q: グローバルセカンダリインデックスから DynamoDB テーブルの属性をすべて取得することはできますか?

GSI に関するクエリでは、作成時に GSI に含めるように指定された属性だけが返されます。GSI に含まれる属性は、GSI のキー属性やテーブルのプライマリキー属性、射影するようにユーザーが指定した属性など、デフォルトで射影される属性です。このため GSI クエリでは、テーブルに含まれていて、GSI に含まれていない項目の属性は返されません。すべての属性を射影された属性として指定する GSI を使って、任意のテーブル属性を取得できます。クエリで GSI を使用する詳細については、こちらを参照してください。

Q: テーブルに関連付けられている GSI を一覧表示するにはどうすればいいですか?

DescribeTable API は、テーブルのグローバルセカンダリインデックスに関する詳細情報を返します。

Q: どのデータ型をインデックス化できますか?

ローカルセカンダリインデックスキーのソートキー要素に、すべてのスカラーデータ型 (数値、文字列、バイナリ、ブール) を使用できます。セット型、リスト型、マップ型にインデックスは作成できません。

Q: 複合属性のインデックスは可能ですか?

いいえ。ただし、属性を文字列に連結して、キーとして使用することはできます。

Q: GSI の射影された属性に含まれるのはどのデータ型ですか?

任意のデータ型を GSI に射影するように属性を指定できます。

Q: GSI のスケーラビリティに関する考慮事項は何ですか?

DynamoDB テーブルのプライマリキーに関するパフォーマンスの考慮事項が、GSI キーにも適用されます。GSI では、すべてのキーで比較的ランダムなアクセスパターンが使用されていると見なされます。セカンダリインデックス用にプロビジョンされるスループットを最大限活用するには、独自の大きな値を持つ GSI パーティションキー属性と、できるだけランダムとなるように均一に要求される GSI ソートキー属性を選択する必要がありあす。

Q: グローバルセカンダリインデックスに対して、CloudWatch を介して使用できる新しいメトリックスは何ですか?

GSI を設定したテーブルは、テーブルと GSI の集計メトリックス、およびテーブルと各 GSI の分割メトリックスを提供します。

個々の GSI のレポートでは、テーブルがサポートする CloudWatch メトリックスのサブセットがサポートされます。具体的には次のとおりです。

  • 読み込み容量(プロビジョンされた読み込み容量、消費された読み込み容量)
  • 書き込み容量(プロビジョニングされた書き込み容量、消費された書き込み容量)
  • 調整された読み込みイベント
  • 調整された書き込みイベント

DynamoDB テーブルとインデックスがサポートするメトリックスの詳細については、こちらを参照してください。

Q: DynamoDB のテーブルとインデックスを自動スケーリングすることはできますか?

これはネイティブな機能ではありません。推奨するサードパーティ製ライブラリは、DynamoDB ウェブページの開発者用リソースセクションに記載されています。

Q: グローバルセカンダリインデックスをスキャンするにはどうすればよいですか?

グローバルセカンダリインデックスをスキャンするには、コンソールまたはスキャン API を使用します。

グローバルセカンダリインデックスをスキャンするには、スキャン対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

Q: グローバルセカンダリインデックスのスキャンでは、射影されていない属性を結果セットに入れて返すように指定できますか?

グローバルセカンダリインデックスのスキャンでは、射影されていない属性は取得できません。

Q: インデックスは並列スキャンできますか?

はい、インデックスは並列スキャンできます。構文はメインテーブルの構文と同じです。


Q: ローカルセカンダリインデックスとは何ですか?

ローカルセカンダリインデックスを使用すると、一般的なクエリを簡単にコスト効率のよい方法で実行できます。ローカルセカンダリインデックスを使用しない場合は、多数の項目を取得し、結果をフィルタリングする必要があります。つまり、アプリケーションには、より幅広い属性をベースにした、より柔軟なクエリを使用できます。

パーティション内の特定の項目 (同一のパーティションキーを共有する項目) を検索する場合は、ローカルセカンダリインデックスを呼び出す前に、DynamoDB は単一のパーティションキーを共有するすべてのオブジェクトを取得し、結果をフィルタリングします。例えば、顧客 ID 注文のタイムスタンプのパーティションソートスキーマを使用して、DynamoDB テーブルに顧客注文データを保存する e コマースアプリケーションがあるとします。LSI がない場合、“顧客 X によって行われた、出荷日が過去 30 日間のすべての注文を出荷日別に並べ替えて表示する” という質問の答えを見つけるには、Query API を使用してパーティションキー “X” を持つすべてのオブジェクトを取得し、結果を出荷日で並べ替え、古いレコードを除外することが必要でした。

ローカルセカンダリインデックスにより、この処理が簡略化されます。「出荷日」属性でインデックスを作成し、このクエリを効率よく実行して、必要な項目だけを取得します。これにより、特定の基準を満たす項目だけが取得されるため、クエリのレイテンシーとコストが大幅に減少します。さらに、結果をフィルタリングするためのカスタマーロジックを作成する必要がないため、アプリケーションのプログラミングモデルが簡略化されます。この新しいセカンダリインデックスを ‘ローカル’ セカンダリインデックスと呼びます。理由は、このインデックスがパーティションキーとともに使用され、パーティションキーバケット内をローカルに検索できるためです。そのため、以前はパーティションキーとソートキーを使用して検索することしかできなかったのに対し、現在ではソートキーの代わりにセカンダリインデックスを使用して検索することもできます。これにより、効率的に実行できるクエリに使用可能な属性の数が増加します。

データ属性の冗長コピーが、定義したローカルセカンダリインデックスにコピーされます。これらの属性には、テーブルのパーティションおよびソートキーと、ユーザーが定義する代替のソートキーが含まれています。他のデータ属性をローカルセカンダリインデックスに冗長的に格納することもでき、テーブル自体にアクセスせずに、それらの他の属性にアクセスできます。

ローカルセカンダリインデックスはすべてのアプリケーションに適しているわけではありません。ローカルセカンダリインデックスでは、単一のパーティションキー値に保存できるデータ量に一定の制約があります。詳しくは、項目コレクションに関する以下の「よくある質問」の項目を参照してください。

Q: 射影とは何ですか?

ローカルセカンダリインデックスにコピーされる一連の属性を射影と呼びます。射影により、最も効率よく取得できる属性が決定します。ローカルセカンダリインデックスにクエリを行う場合、Amazon DynamoDB から任意の射影された属性にアクセスできますが、その際のパフォーマンス特性は、それらの属性が独自のテーブルにある場合と同じです。射影されていない属性を取得する必要がある場合、Amazon DynamoDB は自動的にそれらの属性をテーブルから取得します。

ローカルセカンダリインデックスを定義する場合は、インデックスに射影される属性を指定する必要があります。少なくとも、各インデックスエントリは、(1) テーブルのパーティションキー値、(2) インデックスソートキーとして機能する属性、(3) テーブルソートキー値で構成されている必要があります。

この最小限の構成に限定されず、他の非キー属性のユーザー指定リストを選択してインデックスに射影することもできます。すべての属性をインデックスに投影することもできます。その場合、インデックスはテーブル自体と同じデータを複製しますが、データはユーザーが指定する別のソートキーによって編成されます。

Q: LSI を作成するにはどうすればよいですか?

LSI は、テーブル作成時に作成する必要があります。現時点では、後から追加することはできません。LSI を作成するには、次の 2 つのパラメータを指定します。

Indexed Sort key – インデックス化されてクエリの対象となる属性です。

Projected Attributes – テーブルにある属性のうち、ローカルセカンダリインデックスに直接コピーされる属性のリストです。ローカルセカンダリインデックスにコピーされた属性は、テーブルの全項目を含むプライマリインデックスからデータを取得することなく迅速に取得できます。射影された属性を使用しない場合、ローカルセカンダリインデックスにはプライマリインデックスキーとセカンダリインデックスキーのみが含まれます。

Q: LSI の整合性モデルとは何ですか?

プライマリインデックスが更新されると、ローカルセカンダリインデックスが自動的に更新されます。プライマリインデックスからの読み込みと同様に、LSI は厳密な整合性のある読み込みオプションまたは最終的な整合性のある読み込みオプションの両方をサポートしています。

Q: ローカルセカンダリインデックスにはテーブル内のすべての項目への参照が含まれているのですか?

いいえ、必ずしもそうではありません。ローカルセカンダリインデックスは、その LSI 用に指定された、インデックス化されたソートキーを含む項目のみを参照します。DynamoDB の柔軟なスキーマは、必ずしもすべての項目がすべての属性を含むとは限らないことを意味します。

つまり、ローカルセカンダリインデックスは、プライマリインデックスに比べて、含まれる属性が少ない場合があります。ローカルセカンダリインデックスは、スパース型であるため、共通でない属性に対するクエリをサポートするために効率的です。

例えば、前に説明した Orders の例では、お客様は項目の中に、注文を取り消した場合(CanceledDateTime や CanceledReason など)にのみ含まれる追加の属性を持っている場合があります。取り消された項目に関連したクエリでは、どちらの属性についても、ローカルセカンダリインデックスが効率的です。インデックスで参照される唯一の項目は、これらの属性が設定されていた項目であるためです。

Q: ローカルセカンダリインデックスへのクエリを行うには、どうすればよいですか?

ローカルセカンダリインデックスへのクエリは、Query API を介してのみ実行できます。

ローカルセカンダリインデックスへのクエリを行うには、クエリ対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

クエリで、プライマリに格納された射影されていない属性を取得できます。そのためには、追加の読み取り容量ユニットのコストはかかりますが、テーブル取得オペレーションを実行します。

厳密な整合性のある読み込みと最終的な整合性のある読み込みの両方が、ローカルセカンダリインデックスを使用したクエリでサポートされています。

Q: ローカルセカンダリインデックスを作成するには、どうすればよいですか?

ローカルセカンダリインデックスは、テーブル作成時に定義する必要があります。また、テーブルのプライマリインデックスで複合パーティションソートキーを使用する必要があります。

Q: 既存のテーブルにローカルセカンダリインデックスを追加できますか?

いいえ、現時点では既存のテーブルにローカルセカンダリインデックスを追加することはできません。Amazon では、この機能を追加するように作業を進めており、将来この機能をリリースする予定です。ローカルセカンダリインデックスを使用してテーブルを作成する場合、現在使用されていないソートキー要素を定義して、将来使用するためのローカルセカンダリインデックスを作成することもできます。ローカルセカンダリインデックスはスパース型なので、使用時までコストは発生しません。

Q: 1 つのテーブルに何個のローカルセカンダリインデックスを作成できますか?

各テーブルに最大 5 個のローカルセカンダリインデックスを作成できます。

Q: 射影された非キー属性は、1 つのテーブルにつき何個作成できますか?

各テーブルに最大 20 個の射影された非キー属性を作成できます。この数は、テーブル内のすべてのローカルセカンダリインデックスの合計です。また、各インデックスで、プライマリインデックスからすべての非キー属性が射影されるように指定することもできます。

Q: インデックスを作成後に変更できますか?

いいえ、インデックスを作成後に変更することはできません。Amazon では、この機能を追加するように作業中です。

Q: ローカルセカンダリインデックスは削除できますか?

いいえ、現時点では、ローカルセカンダリインデックスを作成後にテーブルから削除することはできません。テーブル全体を削除した場合は、ローカルセカンダリインデックスも削除されます。Amazon では、この機能を追加するように作業を進めており、将来この機能をリリースする予定です。

Q: ローカルセカンダリインデックスではプロビジョニングされた容量はどのように使用されますか?

ローカルセカンダリインデックス用の容量を明示的にプロビジョニングする必要はありません。プロビジョニングされた容量は、ローカルセカンダリインデックスが関連付けられているテーブルの一部として使用されます。

LSI からの読み込みおよび LSI を含むテーブルへの書き込みでは、データ 1 KB ごとに 1 ユニットという標準式に基づいて容量が使用されますが、次の違いがあります。

書き込みに含まれるデータが 1 つ以上のローカルセカンダリインデックスに関連している場合、書き込みは適切なローカルセカンダリインデックスにミラーリングされます。その場合、書き込み容量はテーブル自体のために使用され、追加の書き込み容量が関連する各 LSI のために使用されます。

更新によって既存の項目が上書きされる場合、2 つのオペレーション(削除と挿入)が実行され、データ 1 KB ごとに書き込み容量の追加ユニットが使用されます。

LSI に射影されていない属性が読み込みクエリで要求された場合、DynamoDB はそれらの属性をプライマリインデックスから取得します。この暗黙的な GetItem 要求では、取得する項目データ 4 KB あたり 1 ユニットの読み込み容量が使用されます。

Q: ローカルセカンダリインデックスはどれくらいのストレージを使用しますか?

ローカルセカンダリインデックスでは、すべての射影された非キー属性について、各 LSI のプライマリキーおよびインデックスキーの属性名と値のためにストレージが使用されます。それに加えて、LSI に射影された項目ごとに 100 バイトが使用されます。

Q: どのデータ型をインデックス化できますか?

ローカルセカンダリインデックスキーのソートキー要素として、すべてのスカラーデータ型 (数値、文字列、バイナリ) を使用できます。セット型は使用できません。

Q: どのデータ型をローカルセカンダリインデックスに射影できますか?

すべてのデータ型 (セット型を含む) をローカルセカンダリインデックスに射影できます。

Q: 項目コレクションとは何ですか? また、LSI とどのように関係していますか?

Amazon DynamoDB では、項目コレクションとは、テーブルおよびテーブルのすべてのローカルセカンダリインデックス全体で同じパーティションキーを持つ任意の項目グループです。従来のパーティション化 (またはシャーディング) されたリレーショナルデータベースシステムでは、シャードまたはパーティションと呼ばれており、1 つのパーティションキーに含まれるすべてのデータベース項目または行を指していました。

項目コレクションは、ローカルセカンダリインデックスを含むすべてのテーブルに対して自動的に作成され、維持されます。DynamoDB では、各項目コレクションが単一のディスクパーティションに格納されます。

Q: 項目コレクションのサイズに制限はありますか?

Amazon DynamoDB のすべての項目コレクションには、10 ギガバイトの最大サイズ制限が適用されます。任意の個別パーティションキー値の場合、テーブルの項目サイズの合計と、そのテーブルのすべてのローカルセカンダリインデックス全体の項目サイズの合計を足したサイズが、10 GB を超えてはなりません。

項目コレクションに対する 10 GB 制限は、ローカルセカンダリインデックスを含まないテーブルには適用されません。1 つ以上のローカルセカンダリインデックスを含むテーブルのみに影響します。

個々の項目コレクションはサイズが制限されていますが、ローカルセカンダリインデックスを含むテーブル全体のストレージサイズは制限されません。Amazon DynamoDB のインデックス化されたテーブルの合計サイズは、実質的に無制限です。ただし、任意の 1 つのパーティションキーの合計ストレージサイズ (テーブルとインデックス) が 10 GB のしきい値を超えない場合に限ります。

Q: 項目コレクションのサイズを追跡するには、どうすればよいですか?

DynamoDB の書き込み API(PutItem、UpdateItem、DeleteItem、および BatchWriteItem)に含まれているオプションを使用すると、関連する項目コレクションのサイズ予測を API 応答に含めることができます。この予測には、特定の項目コレクション内のデータの下限および上限サイズ予測(ギガバイト単位)が含まれます。

項目コレクションのサイズを監視するようにアプリケーションを設定することをおすすめします。アプリケーションは項目コレクションのサイズに関して API 応答を検査し、項目コレクションがユーザー定義の制限(例えば 8 GB)を超えた場合はエラーメッセージをログに記録する必要があります。これが早期警告システムとなり、項目コレクションが大きくなりすぎていることが通知され、対処するための十分な時間が与えられます。

Q: 項目コレクションの 10 GB の制限を超えた場合は、どうすればよいですか?

特定の項目コレクションが 10 GB の制限を超過した場合は、新しい項目を書き込めなくなります。また、その特定のパーティションキーについて既存の項目のサイズを大きくすることもできません。項目コレクションのサイズを縮小させる読み込みおよび書き込みオペレーションは、引き続き実行できます。テーブル内の他の項目コレクションは影響されません。

この問題に対処するには、項目を削除したり、10 GB を超過したコレクションの項目サイズを減らしたりします。または、この問題を回避するために、新しいパーティションキー値で新しい項目を作成できます。頻繁にはアクセスされない履歴データがテーブルに含まれている場合は、Amazon S3、Amazon Glacier または他のデータストアにアーカイブすることを検討してください。

Q: ローカルセカンダリインデックスをスキャンするにはどうすればよいですか?

ローカルセカンダリインデックスをスキャンするには、スキャン対象テーブルの名前に加えて、インデックスを明示的に参照します。インデックスパーティション属性の名前と値を指定する必要があります。インデックスキーソート属性に対してオプションで条件を指定できます。

スキャンで、プライマリインデックスに格納された射影されていない属性を取得できます。そのためには、テーブル取得オペレーションを実行します。ただし、追加の読み込み容量ユニットのコストがかかります。

Q: ローカルセカンダリインデックスのスキャンでは、射影されていない属性を結果セットに入れて返すように指定できますか?

ローカルセカンダリインデックスのスキャンでは、射影されていない属性は取得できません。

Q: ローカルセカンダリインデックスへのスキャン結果は、どのような順序になりますか?

ローカルセカンダリインデックスの場合、コレクション内での順序は、インデックスが作成された属性に基づいて決まります。


Q: DynamoDB の FGAC(Fine-Grained Access Control)とは何ですか?

FGAC(Fine Grained Access Control)とは、DynamoDB テーブルの所有者がテーブル内のデータに対して詳細なコントロールを行うための機能です。具体的には、テーブル所有者は(呼び出し元)がテーブルのどの項目や属性にアクセスでき、どのようなアクション(読み込み/書き込み)を実行できるかを指定できます。FGAC は、AWS Identity and Access Management(IAM)と組み合わせて使用されます。セキュリティ認証情報および対応するアクセス権限の管理は、IAM で行います。

Q: DynamoDB FGAC の一般的なユースケースを教えてください。

FGAC が効果を発揮するのは、DynamoDB テーブルを使用して情報をトラッキングするアプリケーションにおいて、エンドユーザー(またはエンドユーザーの代理となるアプリケーションクライアント)がテーブルの読み取りや変更を、中間層サービスなしで直接行う必要がある場合です。たとえば、「Acme」という名前のモバイルアプリで FGAC を使用し、Acme ユーザーそれぞれのトップスコアを DynamoDB テーブル内でトラッキングします。FGAC を利用すると、アプリケーションクライアントが変更するのはアプリを実行しているユーザーのトップスコアだけとなるように制限できます。

Q: JSON 文書では Fine Grain Access Control を使用できますか?

はい。Fine Grain Access Control(FGAC)を使用して、文書の最上位の属性に基づいてデータへのアクセスを制限できます。FGAC を使用して、ネストされた属性に基づいてアクセスを制限することはできません。たとえば、ある個人についての ID、姓、名、友人全員のリストの情報を含む JSON 文書を保存したとします。FGAC を使用して、ID、姓、名に基づいてアクセスを制限できますが、友人リストに基づいて制限することはできません。

Q: FGAC を使用しない場合は、どのようにすれば項目レベルでアクセスをコントロールできるのですか?

このレベルのコントロールを FGAC なしで達成する方法はいくつかありますが、いずれも手間がかかる可能性があります。たとえば、次のようなものです。

  1. プロキシ: アプリケーションクライアントはリクエストを仲介プロキシに送信し、このプロキシが認証と認可を実行します。このような方法では、システムアーキテクチャが複雑になり、総所有コスト(TCO)が上昇する可能性があります。
  2. クライアント別テーブル: アプリケーションクライアントそれぞれに専用のテーブルを割り当てます。アプリケーションクライアントはそれぞれ別のテーブルにアクセスするので、互いに干渉することはありません。この方法では、作成するテーブルの数が膨大になる可能性があり、したがってデータベース管理がきわめて煩雑になります。
  3. クライアント別埋め込みトークン: 秘密のトークンをアプリケーションクライアントに埋め込みます。この方法の欠点は、トークンの変更や、保存されているデータへの影響の扱いが難しいことです。この方法では、クライアントからアクセスできる項目のキーに秘密のトークンを格納します。

Q: DynamoDB FGAC のしくみを教えてください。

FGAC を使用する場合は、アプリケーションはセキュリティトークンをリクエストします。このトークンは、特定の DynamoDB テーブル内の特定の項目のみへのアクセスをアプリケーションに認可するものです。このトークンを使用して、エンドユーザーアプリケーションエージェントは DynamoDB に対して直接リクエストを発行します。このリクエストが受信されると、リクエストの認証情報が DynamoDB によって検証されます。リクエストの認証には IAM が使用され、そのユーザーにどの操作を許可するかが決定します。ユーザーのリクエストが許可されない場合は、データへのアクセスが FGAC によって阻止されます。

Q: DynamoDB FGAC の料金はどれくらいですか?

FGAC は追加料金なしで使用できます。通常どおり、お支払いいただくのは DynamoDB テーブルに関連してプロビジョニングされたスループットとストレージの料金のみです。

Q: 使用を開始する方法を教えてください。

DynamoDB 開発者ガイドの「Fine-Grained Access Control」のセクションをご覧ください。ここでは、アクセスポリシーを作成し、アプリ用の IAM ロールを作成して(例: AcmeFacebookUsers というロールを Facebook アプリ ID 34567 用に作成)、ロールにアクセスポリシーを割り当てる方法を説明しています。どの認証プロバイダが受け入れられるか(例: Login with Amazon、Facebook、または Google)はロールの信頼ポリシーによって決まり、どの AWS リソースにアクセスできるか(例: DynamoDB テーブル)はアクセスポリシーで規定されます。これで、アプリがロールを使用して DynamoDB に対する一時的認証情報を取得できるようになります。取得するには、AWS Security Token Service(STS)の AssumeRoleWithIdentityRequest API を呼び出します。

Q: ユーザーにローカルセカンダリインデックスへのクエリを許可するが、射影されない属性を取り出すテーブルフェッチを禁止するには、どうすればよいでしょうか。

ローカルセカンダリインデックスに対するクエリ操作の中には、他の操作と比較して高コストになるものがあります。それは、インデックスとして射影されていない属性を要求している場合です。このような高コストの可能性がある「フェッチ」操作を制限するには、射影された属性のみにアクセスできるように権限を設定します。このようにするには、「dynamodb:Attributes」コンテキストキーを使用します。

Q: 特定の属性に対するユーザーアクセスを禁止するには、どうすればよいでしょうか?

特定の属性へのアクセスを禁止するには、最小権限の原則に従い、特定の属性へのアクセスのみを許可することをお勧めします。

別の方法としては、アクセスを許可しない属性を Deny ポリシーで指定するというものがあります。ただし、この方法は次のような理由からお勧めできません。

  1. Deny ポリシーによる方法では、隠された属性名をユーザーが発見することも可能です。リクエストを繰り返し発行して、考えられる属性名を 1 つずつ指定していくと、最終的にそのユーザーはアクセスを拒否されます。
  2. Deny ポリシーは脆弱です。将来 DynamoDB に新しい API 機能が導入されたときに、開発者がそれまでブロックしていたアクセスパターンが許可されるようになることも考えられるからです。

Q: ユーザーによってテーブルに無効なデータが追加されるのを防ぐには、どうすればよいでしょうか?

FGAC によるコントロールには、どの項目の変更や読み取りが可能で、どの属性の変更や読み取りが可能かを特定する機能があります。ユーザーは、ブロックされた属性を除いて新しい項目を追加でき、変更可能と指定されている属性の値を自由に変更できます。

Q: 複数の属性へのアクセスを許可する場合に、その属性をすべて列記しないで済む方法はありますか?

IAM ポリシー言語では、StringLike や StringNotLike など、多数の比較演算がサポートされています。 詳細については、IAM ポリシーリファレンスを参照してください。

Q: 適切なポリシーを作成するには、どうすればよいでしょうか?

DynamoDB コンソールにある DynamoDB Policy Generator の使用をお勧めします。また、作成したポリシーと Amazon DynamoDB 開発者ガイドに記載されているポリシーとを比較して、推奨パターンに従っているかどうかを確認することもお勧めします。ポリシーを AWS フォーラムに投稿すると、DynamoDB のコミュニティから意見をもらうことができます。

Q: ユーザーがログインに使用した認証プロバイダごとのユーザー ID ではなく、1 つの標準ユーザー ID に基づいてアクセスを許可することはできますか?

実現するには、「トークン自動交付機能」のようなものが必要です。ユーザーが IAM ロールに対するフェデレーテッドアクセス権を、Facebook 認証情報と STS を使用して直接取得した場合は、その一時的認証情報に含まれているのはそのユーザーの Facebook ログインに関する情報のみであり、そのユーザーの Amazon ログインや Google ログインの情報はありません。開発者が、これらのログインから独自の永続的な識別子へのマッピングを内部的に保存する必要がある場合は、ユーザーがログインするときの接続先となるサービスを実行してください。このサービスで STS を呼び出して、ユーザーに認証情報 (そのユーザーの正規ユーザー ID となるパーティションキー値をスコープとする) を付与します。

Q: FGAC を使用しても隠せない情報には、どのようなものがありますか?

現時点で、テーブル内の項目に関する情報のうち、呼び出し元からのアクセスをブロックできないものは次のとおりです。

  • 項目コレクションのメトリックス。呼び出し元は、項目コレクションの項目数やバイト単位のサイズの推計値を問い合わせることができます。
  • 使用されたスループット。呼び出し元は、プロビジョニングされたスループットのうち操作で使用された分の詳細な内訳や集計値を問い合わせることができます。
  • 検証ケース。場合によっては、開発者がアクセスを許可する意図がなくても、あるテーブルが存在することと、そのプライマリキースキーマを呼び出し元が知ってしまうこともあります。このことを防ぐには、最小権限の原則に従い、意図的にアクセスを許可するテーブルとアクションのみについてアクセスを許可することをお勧めします。
  • アクセスを許可する特定の属性のホワイトリストを作成するのではなく、特定の属性へのアクセスを拒否するようになっていると、隠されている属性の名前を呼び出し元が特定することは理論的には可能です。これが可能になるのは、「~を除くすべてを許可」ロジックが使用されている場合です。代わりに、特定の属性名をホワイトリスト化するほうが安全です。

Q: Amazon DynamoDB では IAM 権限がサポートされていますか?

はい。DynamoDB では、AWS Identity and Access Management(IAM)サービス統合によって API レベルの権限がサポートされます。

IAM の詳細については、以下のサイトをご覧ください:

Q: DynamoDB テーブルに関するセキュリティ分析またはオペレーションのトラブルシューティングを実行したいと考えています。自分のアカウントで実行した、すべての DynamoDB API 呼び出し履歴を取得することはできますか?

はい。AWS CloudTrail はアカウントに対する AWS API 呼び出しを記録し、ログファイルを配信するウェブサービスです。AWS CloudTrail で生成される AWS API の呼び出し履歴を利用して、セキュリティの分析、リソース変更の追跡、およびコンプライアンスの監査を行うことができます。CloudTrail 向けの DynamoDB サポートの詳細については、こちらを参照してください。CloudTrail の詳細については、AWS CloudTrail の詳細ページを参照してください。CloudTrail を有効にするには、CloudTrail の AWS マネジメントコンソールのホームページにアクセスしてください。


Q: Amazon DynamoDB を使用すると、どのように課金されますか?

各 DynamoDB テーブルには、プロビジョニングされた読み込みスループットと書き込みスループットがあり、テーブルに関連付けられています。無料利用枠を超える場合は、そのスループット容量に対して 1 時間ごとに課金されます。

テーブルにリクエストを送信するかどうかにかかわらず、テーブルにプロビジョニングしたスループット容量に対して 1 時間ごとに課金されることに注意してください。テーブルのプロビジョニングされたスループット容量を変更するには、AWS Management Console または UpdateTable API を使用します。

さらに、DynamoDB では、インデックス化されたデータの保存料金として標準的なインターネットデータ転送料金が別途かかります。

DynamoDB の料金計算の詳細については、DynamoDB 料金表のページをご覧ください。

Q: 価格設定例を教えてください。

米国東部 (バージニア北部) リージョンの料金表を使用してスループットコストを計算する方法の例を次に示します。他のリージョンの料金については、料金表のページをご覧ください

テーブルを 1 つ作成し、10 ユニットの書き込み容量と 200 ユニットの読み込み容量のプロビジョニングされたスループットをリクエストした場合は、以下のように課金されます:

$0.01 + (4 x $0.01) = 1 時間あたり $0.05

スループットを変更し、予約されたスループット要件を 10,000 ユニットの書き込み容量と 50,000 ユニットの読み込み容量に増やすと、以下のように変更されます:

(1,000 x $0.01) + (1,000 x $0.01) = 1 時間あたり $20

DynamoDB の料金計算の詳細については、DynamoDB 料金表のページをご覧ください。

Q: 料金は税込み価格ですか?

税金の詳細については、Amazon Web Services Tax Help を参照してください。

Q: プロビジョニングされたスループットとは何ですか?

Amazon DynamoDB を使用すると、テーブルの目標とするリクエストスループットを指定できます。指定されたスループットレートを達成するために、リソースのプロビジョニングが見えないところで処理されます。当社では、スループットレートに影響するインスタンス、ハードウェア、メモリなどの要因についてお客様に尋ねるのではなく、目標とするスループットレベルをプロビジョニングしていただくようお願いしています。これが、サービスのプロビジョニングされたスループットモデルです。

Amazon DynamoDB を使用すると、テーブルの読み込み容量と書き込み容量のユニットの観点からスループットのニーズを指定できます。テーブルの作成時に、必要な読み込み容量と書き込み容量のニーズを指定すると、スループット要件に応じて適切な量のリソースが自動的にパーティション化および予約されます。必要な読み込みおよび書き込みスループット値を決めるには、読み込みおよび書き込みデータのシンプルな API 呼び出しを 1 秒あたり何回行うかを考慮してください。トラフィックが増加し、プロビジョニングされたスループットをどこかの時点で超える可能性がある場合は、プロビジョニングされたスループット値を AWS Management Console または Amazon DynamoDB API を使用して増やします。需要の減少に応じて、プロビジョニングされたスループットを減らすこともできます。Amazon DynamoDB は、スループットレベルを拡大または縮小しているときも使用できます。

Q: プライマリキーの選択は達成できる拡張性にどのように影響しますか?

Amazon DynamoDB は、データを保存するときに、テーブルを複数のパーティションに分けて、プライマリキーのパーティションキー要素に基づいてデータを分散します。容量リソースを割り当てる際、Amazon DynamoDB はすべてのプライマリキーで比較的ランダムなアクセスパターンが使用されると仮定します。データモデルを設定するときは、リクエストによるトラフィックがプライマリキー全体に均等に分散するようにします。1 つのテーブルに頻繁にアクセスされるパーティションキー要素がごく少数含まれる場合 (場合によっては、非常に頻繁に使用されるパーティションキー要素が 1 つのみの場合)、少数のパーティション (場合によっては 1 つのパーティションのみ) にトラフィックが集中します。1 つまたは一部のパーティションに偏ってしまうなど、負荷のバランスが極端に悪いと、プロビジョニングされたスループットレベルが達成されません。Amazon DynamoDB のスループットを最大限に活用するには、テーブルを作成するときに、パーティションキー要素に個別の値が多数含まれ、できるだけランダムに、かつ均一に値がリクエストされるようにします。たとえば、アプリケーションの利用顧客が多く、様々な顧客レコードへのリクエストがほぼ均一な場合は、CustomerID をプライマリキーとして使用するとよいでしょう。大きな偏りが生じるプライマリキーの例としては、製品カテゴリによって人気にばらつきがある場合の「製品カテゴリ名」が挙げられます。

Q: 読み込み/書き込み容量のユニットとは何ですか?

使用しているアプリケーションに必要な読み込み/書き込み容量のユニットはどのように見積もりますか? 1 ユニットの書き込み容量で、最大 1 KB のサイズの項目について 1 秒に 1 書き込みを実行できます。同様に、1 ユニットの読み込み容量で、最大 4 KB の項目に対して強い整合性のある読み込みを 1 秒あたり 1 回(結果的に整合性のある読み込みについては 1 秒あたり 2 回)行うことができます。項目のサイズが大きくなるほど、多くの容量が必要になります。必要な読み込みおよび書き込み容量のユニット数を計算するには、必要な 1 秒あたりの読み込みまたは書き込み回数を見積もり、項目のサイズ(KB に切り上げ)を掛け合わせます。

書き込みに必要な容量のユニット数 = 1 秒あたりの項目書き込み回数 x 項目のサイズ (1 KB ブロック)

読み込みに必要な容量のユニット数* = 1 秒あたりの読み込み回数 x 項目のサイズ (4 KB ブロック)

* 結果整合性のある読み込みを使用する場合は、1 秒あたりの読み込み回数によってスループットが 2 倍になります。

項目のサイズが 1 KB を下回る場合は、読み込み容量のユニットごとに 1 秒あたり強力な整合性のある 1 読み込み、書き込み容量のユニットごとに 1 秒あたり 1 書き込みの容量が割り当てられます。例えば、項目のサイズが 512 バイトで、1 秒あたり 100 個の項目をテーブルから読み込む必要がある場合は、100 ユニットの読み込み容量をプロビジョニングする必要があります。

項目のサイズが 4 KB を上回る場合は、必要な読み込み容量と書き込み容量のユニット数を計算する必要があります。例えば、項目のサイズが 4.5 KB で、1 秒あたり 100 個の強力な整合性のある読み込みを行う必要がある場合は、「100(秒あたりの読み込み)x 2(4.5 KB の保存に必要な 4 KB ブロックの数)= 200(読み込み容量のユニット数)」をプロビジョニングする必要があります。

必要な読み込み容量のユニット数は、API 呼び出し数ではなく、1 秒あたりに読み込まれる項目数によって決まります。例えば、1 秒あたり 500 個の項目をテーブルから読み込む必要があり、項目のサイズが 4 KB 以下の場合は、500 ユニットの読み込み容量が必要です。個別の GetItem 呼び出しを 500 回行う場合でも、10 個の項目を返す BatchGetItems 呼び出しを 50 回を行う場合でも同じです。

Q: プロビジョニングされたスループットのレベルは必ず達成することができますか?

Amazon DynamoDB では、すべてのプライマリキーで比較的ランダムなアクセスパターンが使用されていると見なされます。データモデルを設定するときは、リクエストによるトラフィックがプライマリキー全体に均等に分散するようにします。アクセスパターンが極端にばらついている場合、または偏りがある場合は、プロビジョニングされたスループットレベルを達成できない可能性があります。

Amazon DynamoDB は、データを保存するときに、テーブルを複数のパーティションに分けて、プライマリキーのパーティションキー要素に基づいてデータを分散します。また、テーブルに関連付けられているプロビジョニングされたスループットもパーティションに分けられます。各パーティションのスループットは、パーティションに指定された割り当て量に基づいて個別に管理されます。プロビジョニングされたスループットがパーティションをまたいで共有されることはありません。つまり、負荷がパーティションキー値に均等に分散されている場合、Amazon DynamoDB のテーブルはプロビジョニングされたスループットレベルに最適に対応できます。リクエストを複数のパーティションキー値に分散させると、リクエストが複数のパーティションに分散されます。これは、完全にプロビジョニングされたスループットレベルを達成するのに役立ちます。

プライマリキーの負荷パターンが不均等で、プロビジョニングされたスループットレベルを達成できない場合、プロビジョニングされたスループットレベルを上げ、各パーティションに割り当てるスループットを増やすと、スループットのニーズに対応できることがあります。しかし、プライマリキーで比較的ランダムなアクセスパターンを実現するには、リクエストパターンまたはデータモデルの変更を検討することをお勧めします。

Q: JSON 文書の 1 つの要素に限り検索する場合、項目全体の読み込み料金がかかりますか?

はい。DynamoDB からデータを読み込むと、項目全体の読み込みに必要なスループットを消費します。

Q: 1 つの DynamoDB テーブルにプロビジョニングできる最大スループットはどのくらいですか?

DynamoDB にスケールの制限はありません。ただし、各テーブルのスループットレートが 10,000 書き込み容量ユニットまたは 10,000 読み込み容量ユニットを超える場合は、こちらのオンラインフォームを使用して事前に Amazon までご連絡ください。また、1 つの登録アカウントから 20,000 を超える書き込み容量ユニットまたは読み込み容量ユニットをプロビジョンする場合も、上記のフォームを使用して事前にご連絡ください

Q: 1 つの DynamoDB テーブルにプロビジョンできる最小スループットはどのくらいですか?

プロビジョニングされる最小スループットとして、書き込み容量と読み込み容量をそれぞれ 1 ユニットずつリクエストできます。

これは無料利用枠(書き込み容量 25 ユニットと読み込み容量 25 ユニットまで)の範囲内です。無料利用枠は、テーブルレベルではなくアカウントレベルに適用されます。つまり、お客様の全テーブルのプロビジョニングされた容量の合計が、書き込み容量 25 ユニットと読み込み容量 25 ユニットを超えていなければ、このプロビジョニングされた容量は無料利用枠の範囲内になります。

Q: プロビジョニングされたスループットを 1 回のリクエストで変更できる量に制限はありますか?

テーブルのプロビジョニングされるスループット容量は、UpdateTable API を使用して必要量を増加できます。たとえば、テーブルのプロビジョニングされる書き込み容量を、1 回の API 呼び出しで 1 書き込み容量ユニットから 10,000 書き込み容量ユニットに増加できます。ただし、お客様のアカウントにはテーブルレベルとアカウントレベルでの容量制限が課せられます。詳しくはドキュメントページを参照してください。プロビジョニングされる容量の制限を引き上げる必要がある場合は、サポートセンターを表示し、[Open a new case] をクリックして、サービス制限引き上げリクエストを申請します。

Q: プロビジョニングされたスループットにはどのように課金されますか?

Amazon DynamoDB テーブルでは、お客様が指定したスループットレートを達成するのに必要なリソースが事前にプロビジョニングされています。テーブルのリソースがこの量で十分である限り、1 時間ごとに課金されます。課金例が記載された詳しい価格リストについては、DynamoDB 料金表ページを参照してください。

Q: 既存の DynamoDB テーブルのプロビジョニングされたスループットはどのように変更しますか?

Amazon DynamoDB テーブルのプロビジョニングされたスループットは 2 通りの方法で更新できます。管理コンソールで変更を行う方法、または UpdateTable API 呼び出しを使用する方法です。どちらの場合でも、Amazon DynamoDB は、プロビジョニングされたスループットレベルを拡大または縮小している時も使用できます。

Q: プロビジョニングされたスループットはどのくらいの頻度で変更できますか?

プロビジョニングされたスループットは好きな頻度で増やすことができます。ただし、スループットを減らす作業は 1 日 4 回しか行うことができません。日付は GMT (グリニッジ標準時) に基づいて定義されます。例えば、12 月 12 日にテーブルのプロビジョニングされたスループットを 4 回減らすと、12 月 13 日午前 12 時 1 分まではそのテーブルのプロビジョニングされたスループットを減らすことができません。

お客様が最後に行ったプロビジョニングされたスループットに対する変更リクエストが Amazon DynamoDB テーブルで処理中の場合、スループットは変更できないことにご注意ください。テーブルのステータスは、管理コンソールまたは DescribeTables API を使用して確認します。ステータスが「CREATING」、「DELETING」、または「UPDATING」の場合、テーブルのスループットは調整できません。テーブルが「ACTIVE」ステータスになってから、再度お試しください。

Q: 整合性レベルはスループットレートに影響しますか?

はい。特定のリソース割り当てでは、DynamoDB テーブルで達成できる読み込みレートは、強い整合性のある読み込みと結果的に整合性のある読み込みで異なります。「1,000 読み込み容量ユニット」をリクエストすると、最大 4KB の項目について、強い整合性のある読み込みを 1 秒あたり 1,000 回達成できるようにリソースが割り当てられます。最大 4 KB の項目について結果整合性のある読み込みを 1,000 回達成するには、その容量の半分、つまり 500 読み込み容量ユニットが必要です。テーブルの適切なスループットレートを選択するための詳細なガイダンスについては、プロビジョニングされたスループットに関するガイドを参照してください。

Q: 項目のサイズはスループットレートに影響しますか?

はい。特定のリソース割り当てでは、DynamoDB テーブルで達成できる読み込み速度は項目のサイズよって異なります。目標とするプロビジョニングされた読み込みスループットを指定するとき、DynamoDB では、項目のサイズが 4 KB 未満になるという前提でリソースがプロビジョニングされます。項目が最大で 4 KB 増加するたびに、同じスループットレートを達成するのに必要なリソースが直線的に増加します。例えば、100 ユニットの読み込み容量で DynamoDB テーブルをプロビジョニングした場合、このテーブルは、1 秒あたり 100 回の 4 KB の読み込み、1 秒あたり 50 回の 8 KB の読み込み、または 1 秒あたり 25 回の 16 KB の読み込みを処理できることを意味します。

同様に、DynamoDB テーブルが達成できる書き込み速度は項目のサイズによって異なります。目標とするプロビジョニングされた書き込みスループットを指定するとき、DynamoDB では、項目のサイズが 1 KB 未満になるという前提でリソースがプロビジョニングされます。最大 1 KB の増加があるたびに、同じスループットレートを達成するのに必要なリソースが正比例的に増えます。例えば、100 単位の書き込み容量で DynamoDB テーブルをプロビジョニングした場合、このテーブルは、100 回の 1 KB の書き込み/秒、50 回の 2 KB の書き込み/秒、または 25 回の 4 KB の書き込み/秒を処理できることを意味します。

テーブルの適切なスループットレートを選択するための詳細なガイダンスについては、プロビジョニングされたスループットに関するガイドを参照してください。

Q: プロビジョニングされた容量を超える読み込みまたは書き込みがアプリケーションで行われるとどうなりますか?

1 秒あたりに、テーブルでプロビジョニングされたスループット容量を超える読み込みまたは書き込みがアプリケーションで行われると、プロビジョニングされた容量を超えた分のリクエストは調整され、エラーコード 400 が返されます。たとえば、1,000 ユニットの書き込み容量を要求した場合、1KB の項目に対して 1,500 書き込み/秒を行おうとしても、1,000 書き込み/秒しか処理できず、処理できなかった分のリクエストに対してエラーコード 400 が返されます。必要なリクエストレートを達成できるだけのプロビジョニングされたスループットを常に確保するためには、CloudWatch を使用してリクエストレートを監視する必要があります。

Q: プロビジョニングされたスループットを超えたことを確認するにはどうすればよいですか?

使用したスループット容量は CloudWatch 基準として公開されています。プロビジョニングされた容量に近づいたら通知されるように、この基準に基づいてアラームを設定することができます。

Q: テーブルのプロビジョニングされたスループットレベルを変更するにはどのくらい時間がかかりますか?

通常、スループットを減らす場合は数秒から数分、増やす場合は数分から数時間かかります。

追加スループットが必要になった時点でスループットを増加したり増加のスケジュールを立てたりすることはお勧めできません。スループット容量のプロビジョニングは、必要なときに確実に容量を確保できるようかなり前から行っておくことをお勧めします。

Q: リザーブドキャパシティーとは何ですか?

リザーブドキャパシティは課金の機能で、以下の料金をお支払いただくことで、プロビジョニングされたスループット容量に割引を受けることができます。

  • 一括前払いのお支払い
  • 契約期間中の最小月額使用料を規定します。

リザーブドキャパシティは単一の AWS リージョン内で適用され、1 年または 3 年の期間で購入できます。すべての DynamoDB テーブルには、関連するプロビジョンドスループット性能があります。テーブルの作成や更新を行う際に、そのテーブルに必要な読み書き容量を指定します。この容量は、DynamoDB テーブルが実現できる読み書きのスループットを決定するものです。リザーブドキャパシティは請求の仕組みで、DynamoDB テーブルのパフォーマンスや容量に直接の影響は与えません。例えば、書き込み容量 100 ユニットのリザーブドキャパシティを購入すると、割引価格を支払う代わりに、契約期間(1 年または 3 年)の容量に対して支払いをする契約となります。

Q: リザーブドキャパシティはどのように購入するのですか?

AWS マネジメントコンソールにログインして、DynamoDB コンソールのページに移動し、[Reserved Capacity] をクリックします。[Reserved Capacity Usage] ページが表示されます。[Purchase Reserved Capacity] をクリックします。そこで表示されるフォームに必要事項を記入して、リザーブドキャパシティの購入手続きを行います。リザーブドキャパシティが使用される予定の AWS リージョンが選択されていることを確認してください。リザーブドキャパシティを購入すると、[Reserved Capacity Usage] ページに、購入内容が示されます。

Q: リザーブドキャパシティーの購入をキャンセルできますか?

いいえ。リザーブドキャパシティはキャンセルできず、前払い料金は返金不可能です。使用されたかどうかにかかわらず、リザーブドキャパシティの期間が終了するまで毎時間の料金をお支払いただきます。

Q: 購入できるリザーブドキャパシティーの最小数量はどのくらいですか?

リザーブドキャパシティとして提供される最小容量は、100 ユニット(読み取りまたは書き込み)です。

Q: リザーブドキャパシティーの購入に使用できる API はありますか?

まだありません。将来的に、API および追加のリザーブドキャパシティのオプションを用意する予定です。

Q: リザーブドキャパシティーを別のリージョンに移動させることはできますか?

いいえ。リザーブドキャパシティは 1 つのリージョンに関連付けられています。

Q: リザーブドキャパシティーよりも多くのスループットをプロビジョンできますか?

はい。リザーブドキャパシティを購入すると、最小使用量を契約し、その使用量に対して割引料金を支払うことになります。最小量よりも多くの容量をプロビジョニングする場合、追加の容量に対しては標準料金をお支払いただきます。

Q: リザーブドキャパシティーはどのように使用するのですか?

リザーブドキャパシティは自動的に請求に適用されます。例えば、書き込み容量 100 ユニットのリザーブドキャパシティを購入し、300 ユニットの容量をプロビジョニングした場合、書き込み容量 100 ユニットのコストについては自動的にリザーブドキャパシティが充てられ、残りの書き込み容量 200 ユニットについては標準料金でお支払いただきます。

Q: リザーブドキャパシティーよりも少ないスループットの容量をプロビジョンした場合はどうなりますか?

リザーブドキャパシティの購入は、割引価格の代わりに、契約期間中、プロビジョニングするスループット容量の最小量に対してお支払いいただく契約です。使用する容量がリザーブドキャパシティより少ない場合も、プロビジョニングするスループット容量の最小量に対して毎月課金されます。

Q: リザーブドキャパシティーを複数の DynamoDB テーブルに使用できますか?

はい。リザーブドキャパシティは、リザーブドキャパシティを購入したリージョン内でプロビジョニングされた総容量に適用されます。例えば、書き込み容量 5,000 ユニットのリザーブドキャパシティを購入すると、1 つのテーブルに書き込み容量 5,000 ユニットを適用するか、または 100 のテーブルに書き込み容量 50 ユニットを適用する、あるいは 1,000 のテーブルに書き込み容量 5 ユニットを適用することなどが可能になります。

Q: リザーブドキャパシティーは、一括請求 (コンソリデーティッドビリング) アカウントの DynamoDB の使用に適用されますか?

はい。一括請求 (コンソリデーティッドビリング) に関連付けられた複数のアカウントを所有している場合、支払いアカウントレベルまたは連結アカウントレベルで購入されたリザーブドキャパシティーのユニットは、支払いアカウントに関連付けられたすべてのアカウントの間で共有されます。リザーブドキャパシティーは、まずそれを購入したアカウントに適用され、その後未使用のキャパシティーが他の連結アカウントに適用されます。

 

Q: DynamoDB クロスリージョンレプリケーションとは何ですか?

DynamoDB クロスリージョンレプリケーションを使用すると、DynamoDB テーブル(マスターテーブル)の同一コピー(レプリカ)を複数の AWS リージョンに保持できます。テーブルのクロスリージョンレプリケーションを有効にすると、そのテーブルの同一コピーが別の AWS リージョンに作成されます。そのテーブルに対する書き込みは、すべてのレプリカに自動的に反映されます。

 

Q: クロスリージョンレプリケーションはどのような場合に使用しますか?

クロスリージョンレプリケーションは、次のような場合に使用できます。

  • 効率的な災害対策: 複数のデータセンターにテーブルをレプリケートすることで、あるデータセンターで障害が発生した場合に、別のリージョンの DynamoDB テーブルを使用するように切り替えることができます。
  • 読み込みの高速化: お客様が複数のリージョンに分散している場合に、最寄りの AWS データセンターの DynamoDB テーブルを読み込むことでデータ配信を高速化できます。
  • トラフィック管理の簡単化: レプリカを使用すると読み取りワークロードを複数のテーブルに分散できるので、マスターテーブルの読み込み容量の消費を抑えられます。
  • リージョン間移行の簡単化: 別のリージョンにリードレプリカを作成し、そのレプリカをマスターに格上げすることで、そのリージョンにアプリケーションを簡単に移行できます。
  • ライブデータの移行: リージョン間で DynamoDB テーブルを移行するには、移行元リージョンのテーブルのレプリカを移行先リージョンに作成します。移行元と移行先のテーブルが同期されたら、移行先リージョンに書き込むようにアプリケーションを切り替えます。

Q: クロスリージョンレプリケーションでサポートされているのはどのモードですか?

クロスリージョンレプリケーションでは現在、単一マスターモードがサポートされています。このモードでは、1 つのマスターが、マスターテーブルと 1 つ以上のレプリカテーブルを持ちます。

Q: テーブルに単一マスタークロスリージョンレプリケーションを設定するにはどうすればよいですか?

DynamoDB クロスリージョンレプリケーションライブラリを使用してクロスリージョンレプリカを作成できます。

Q: ブートストラップが完了したことはどのようにしてわかりますか?

レプリケーション管理アプリケーションで、レプリケーションの状態が「ブートストラップ」から「アクティブ」に変わります。

Q: 1 つのマスターテーブルに対して複数のレプリカを作成できますか?

はい。1 つのマスターテーブルから作成できるレプリカテーブルの数に制限はありません。レプリカテーブルごとに DynamoDB ストリームリーダーが作成され、マスターテーブルからデータをコピーして各レプリカを同期状態に維持します。

Q: 1 つのテーブルにクロスリージョンレプリケーションを設定するために必要な料金を教えてください。

DynamoDB クロスリージョンレプリケーションDynamoDB クロスリージョンレプリケーションライブラリを使用して有効化されます。クロスリージョンレプリケーションライブラリに対する特別の課金はありませんが、プロセスで使用される以下のリソースについて、通常の料金をお支払いいただきます。以下が課金対象となります。

  • プロビジョニングされたスループット(書き込みと読み込み)およびレプリカテーブルのストレージ。
  • リージョン間データ転送。
  • テーブル間の同期を維持するための DynamoDB ストリームからのデータの読み込み。
  • レプリケーションプロセスをホストするためにプロビジョニングされた EC2 インスタンス。インスタンスの費用は、選択したインスタンスタイプとインスタンスをホストしているリージョンによって異なります。

Q: クロスリージョンレプリケーションをホストする Amazon EC2 インスタンスは、どのリージョンで動作しますか?

クロスリージョンレプリケーションアプリケーションは、クロスリージョンレプリケーションアプリケーションが最初に起動されたのと同じリージョンにある Amazon EC2 インスタンスによってホストされます。このリージョンのインスタンス価格が請求されます。

Q: マスターテーブルとレプリカテーブルのサイズとスループットの変動に応じて、Amazon EC2 インスタンスは Auto Scale によって自動スケールされますか?

現時点では、EC2 インスタンスは自動スケールされません。DynamoDB クロスリージョンレプリケーションを設定するときは、お客様にインスタンスサイズを選択していただく必要があります。

Q: レプリケーションを管理する Amazon EC2 インスタンスでエラーが発生するとどうなりますか?

Amazon EC2 インスタンスは Auto Scaling Group の配下で動作しているため、アプリケーションは別のインスタンスに自動的にフェイルオーバーされます。アプリケーションは下層で Kinesis クライアントライブラリ (KCL) を使用しており、これによりコピーのチェックポイントが作成されます。インスタンスでエラーが発生した場合、アプリケーションは、チェックポイントを検索してそこから再開すればよいことを認識しています。

Q: リードレプリカの作成中も DynamoDB テーブルを使い続けることができますか?

はい。レプリカの作成はオンライン操作です。リードレプリカの作成中も読み取りおよび書き込み可能な状態に維持されます。ブートストラップでは、スキャンオペレーションを使用してソーステーブルからコピーを実行します。スキャンオペレーションをサポートするために十分な読み込み容量ユニットでテーブルをプロビジョニングすることをお勧めします。

 

Q: レプリカの作成にはどのぐらい時間がかかりますか?

マスターテーブルからレプリカテーブルへの初回コピーに要する時間はマスターテーブルのサイズ、マスターテーブルとレプリカテーブルのプロビジョニングされた容量によって異なります。項目レベルの変更がマスターテーブルからレプリカテーブルに反映されるまでに要する時間は、マスターテーブルとレプリカテーブルのプロビジョニング容量とレプリケーションアプリケーションを実行している Amazon EC2 インスタンスのサイズによって異なります。

Q: マスターテーブルのプロビジョニング済み容量を変更すると、レプリカテーブルのプロビジョニング済み容量も更新されますか?

レプリケーションが作成された後、マスターテーブルのプロビジョニング済み容量を変更しても、レプリカテーブルのスループット容量は更新されません。

 

Q: レプリカテーブルのインデックスはマスターテーブルと同じですか?

レプリケーションアプリケーションからレプリカテーブルを作成するよう選択した場合、マスターテーブルのセカンダリインデックスがレプリカテーブルに自動的に作成されることはありません。レプリケーションアプリケーションは、マスターテーブルのセカンダリインデックスに対する変更をレプリカテーブルに反映しません。通常の DynamoDB テーブルで行うのと同じ要領で、AWS マネジメントコンソール経由で各レプリカテーブルのインデックスを追加/更新/削除する必要があります。

 

Q: レプリカのプロビジョニングされたスループット容量はマスターテーブルと同じですか?

レプリカテーブルを作成する際には、最低でもマスターテーブルと同じ書き込み容量をプロビジョニングして、すべての受信書き込みを処理できるだけの容量を確保することをお勧めします。レプリカテーブルのプロビジョニングされる読み込み容量は、アプリケーションに合った任意のレベルに設定できます。

 

Q: レプリケートされたテーブルの整合性モデルとは何ですか?

各レプリカは非同期に更新されます。DynamoDB では、マスターテーブルに受け入れられた時点で書き込みオペレーションを成功と認識します。その後、その書き込み内容が各レプリカに反映されます。つまり、すべてのレプリカテーブルに書き込みが反映されるまでには若干の遅延が発生することになります。

Q: クロスリージョンレプリケーションの CloudWatch メトリックスはありますか?

CloudWatch メトリックスはすべてのレプリケーション設定で使用可能です。メトリックスを確認するには、レプリケーショングループを選択し、[モニタリング] タブに移動します。スループットのメトリックスと処理されたレコード数が確認でき、マスターテーブルとレプリカテーブルのスループットの差異を監視できます。

Q: マスターテーブルと同じリージョンにレプリカを配置できますか?

はい。レプリカテーブルとマスターテーブルの名前が異なっていれば、両テーブルを同じリージョンに配置できます。

Q: レプリケーショングループを作成した後、レプリカを追加または削除できますか?

はい。レプリケーショングループに対してはいつでもレプリカの追加または削除を実行できます。

Q: レプリカグループを作成後に削除できますか?

はい。レプリケーショングループの削除により、グループのためのEC2 インスタンスを削除します。ただし、DynamoDB メタデータテーブルを削除する必要があります。

Q: DynamoDB トリガーとは何ですか?

DynamoDB トリガーとは、DynamoDB テーブルの項目レベルの更新に基づいてカスタムアクションを実行できるようにする機能です。コード内でカスタムアクションを指定できます。

Q: DynamoDB トリガーでできることは何ですか?

DynamoDB トリガーを使用すると便利なアプリケーションシナリオはいくつかあります。例えば、通知の送信、集計テーブルの更新、DynamoDB テーブルの別のデータソースへの接続などのユースケースがあります。

Q: DynamoDB トリガーのしくみを教えてください。

DynamoDB トリガーのカスタムロジックは、AWS Lambda 関数にコードとして格納されます。特定のテーブルのトリガーを作成するには、AWS Lambda 関数を(DynamoDB ストリームを使用して)DynamoDB テーブルのストリームに関連付けます。テーブルが更新されると、更新内容が DynamoDB ストリームに発行されます。そして、AWS Lambda が自分に関連付けられたストリームからこの更新内容を読み込み、関数内のコードを実行します。

Q: DynamoDB トリガーの使用料を教えてください。

DynamoDB トリガーを使用する場合は、AWS Lambda 関数をリクエストした回数および AWS Lambda 関数の実行所要時間分のみのお支払いとなります。AWS Lambda の料金の詳細については、こちらをご覧ください。お客様の AWS Lambda 関数が、テーブルに関連付けられたストリームに対して(DynamoDB ストリームを介して)行う読み込みについては課金されません。

Q: テーブルのトリガー数に制限はありますか?

テーブルのトリガー数に制限はありません。

Q: DynamoDB トリガーでサポートされている言語を教えてください。

DynamoDB トリガーでは現在、トリガー関数の言語として JavaScript、Java、および Python をサポートしています。

Q: DynamoDB トリガーを作成、編集、削除するための API はサポートされていますか?

いいえ。現時点では、DynamoDB トリガーを作成、編集、削除するためのネイティブ API は用意されていません。AWS Lambda コンソールを使用して AWS Lambda 関数を作成し、DynamoDB ストリームのストリームに関連付ける必要があります。詳細については、AWS Lambda FAQ ページを参照してください。

Q: DynamoDB トリガーを作成するには、どうすればよいですか?

トリガーを作成するには、AWS Lambda 関数を作成し、その関数のイベントソースを DynamoDB ストリームのストリームに関連付けます。詳細については、AWS Lambda FAQ ページを参照してください。

Q: DynamoDB トリガーを削除するにはどうすればよいですか?

トリガーを削除するには、関連付けられた AWS Lambda 関数を削除します。AWS Lambda 関数は、AWS Lambda コンソールから、または AWS Lambda API 呼び出しを使用して削除できます。詳細については、AWS Lambda FAQ ページおよびドキュメントページを参照してください。

Q: 既存の AWS Lambda 関数を使用して DynamoDB トリガーを作成するにはどうすればよいですか?

AWS Lambda 関数のイベントソースは、DynamoDB ストリームのストリームを指すように変更できます。この変更は DynamoDB コンソールから実行できます。ストリームが有効になっているテーブルで、そのストリームを選択し、[Associate Lambda Function] ボタンを選択して、Lambda 関数の一覧から DynamoDB トリガーに使用する関数を選択します。

Q: どのリージョンで DynamoDB トリガーを利用できますか?

DynamoDB トリガーは、AWS Lambda と DynamoDB が利用できるすべての AWS リージョンで利用できます。

Q: DynamoDB ストリームとは何ですか?

DynamoDB ストリームは、過去 24 時間以内にテーブルのデータに対して行われた項目レベルの変更を時系列ストリームとして提供したものです。簡単な API 呼び出しでストリームにアクセスできます。ストリームを使用すると、変更された直近の DynamoDB で他のデータストアを最新の状態に維持したり、テーブルに対する変更内容に基づいてアクションを実行したりできます。

Q: DynamoDB ストリームを使用する利点は何ですか?

DynamoDB Streams API を使用すると、開発者は、更新を使用して変更する前後の項目レベルのデータを受け取ることができます。それを使用して、DynamoDB を基礎として構築されたアプリケーションにお好みの拡張機能を作成できます。例えば、DynamoDB を使用してグローバルなマルチプレーヤーゲームを開発する場合、DynamoDB Streams API を使用してマルチマスタートポロジを構築し、各マスターに対して DynamoDB Streams を使用して、リモートマスターで更新を再生することで、各マスターの同期を維持できます。別の例として、ユーザーが新しい自分の写真をアップロードするとすぐにサークル内のすべての友人のモバイルデバイスに自動的に通知するモバイルアプリケーションを DynamoDB Streams API を使用して作成できます。また、DynamoDB ストリームを使用して、DynamoDB テーブルに対するすべての変更を Amazon Redshift などのデータウェアハウスツールに同期させて、リアルタイム分析を行うことも可能です。DynamoDB は Amazon DynamoDB Logstash Plugin によって Elasticsearch と統合されるため、開発者が DynamoDB コンテンツにフリーテキスト検索を追加することも可能です。

DynamoDB ストリームの詳細については、当社のドキュメントをご覧ください。

Q: DynamoDB テーブルに対する変更を DynamoDB Streams で利用できる期間はどれくらいですか?

DynamoDB Streams はテーブルに対するすべての変更のレコードを 24 時間保持します。その後、レコードは消去されます。

Q: DynamoDB Streams はどうすれば有効にできますか?

DynamoDB ストリームはテーブルごとに有効にする必要があります。既存の DynamoDB テーブルで DynamoDB ストリームを有効にするには、AWS マネジメントコンソールからテーブルを選択し、[Overview] タブを選択し、[Manage Stream] ボタンをクリックし、表示のタイプを選択し、それから [Enable] をクリックします。

詳細については、当社のドキュメントを参照してください。

Q: DynamoDB ストリームが有効になったかどうかを確認するにはどうすればよいですか?

DynamoDB ストリームを有効にすると、AWS マネジメントコンソールにそのストリームが表示されます。テーブルを選択し、[Overview] タブを選択します。ストリームの詳細で、ストリームの有効化が [Yes] に設定されているか確認してください。

Q: DynamoDB ストリームにアクセスするにはどうすればよいですか?

DynamoDB ストリームを介して利用可能なストリームにアクセスするには、DynamoDB SDK または Kinesis クライアントライブラリ (KCL) を使用した簡単な API 呼び出しを使用します。KCL を使用すると、ストリームのデータを使用および処理したり、複数のリーダーへの負荷分散、インスタンス障害への対応、処理されたレコードのチェックポイントなどのタスクを管理したりできます。

DynamoDB ストリームへのアクセスに関する詳細については、当社のドキュメントを参照してください。

Q: DynamoDB Streams では DynamoDB のテーブルに対して行われたすべての変更が順番に表示されますか?

特定の項目に対して行われた変更は、正しい順序で表示されます。異なる項目に対して行われた変更は、受信した順序とは異なる順序で DynamoDB ストリームに表示されることがあります。

例えば、ゲームのハイスコアを追跡している DynamoDB テーブルがあり、テーブルの各項目が個別のプレーヤーを表している場合について考えます。次の 3 つの更新をこの順序で行うものとします。

  • 更新 1: プレーヤー 1 のハイスコアを 100 ポイントに変更します
  • 更新 2: プレーヤー 2 のハイスコアを 50 ポイントに変更します
  • 更新 3: プレーヤー 1 のハイスコアを 125 ポイントに変更します

更新 1 と更新 3 は同じ項目(プレーヤー 1)に対する変更なので、DynamoDB ストリームでは、更新 1 より後に更新 3 が表示されます。これにより、各プレーヤーの最新のハイスコアを取得できます。3 つの更新すべてが正しい順序で(つまり、更新 2 が更新 1 より後、かつ更新 3 より前に)表示されるとは限りませんが、プレーヤーごとのレコードに対する更新は正しい順序になります。

Q: DynamoDB Stream のストリームの容量を管理する必要がありますか?

いいえ。ストリームの容量は、DynamoDB ストリームによって自動的に管理されます。テーブルに対するトラフィックが大幅に増加した場合、DynamoDB はストリームの容量を自動的に調節して、すべての更新を引き続き受け入れられるようにします。

Q: DynamoDB ストリームからの読み取り速度はどれくらいですか?

DynamoDB テーブルのプロビジョニングされている書き込み容量の最大 2 倍の速度で、DynamoDB ストリームから更新を読み取ることができます。例えば、1 秒間に 1,000 項目を更新するのに十分な容量をテーブルにプロビジョニングしている場合、1 秒間に最大 2,000 件の更新をストリームから読み取ることができます。

Q: DynamoDB テーブルを削除した場合、DynamoDB ストリームのストリームも削除されますか?

いいえ、すぐには削除されません。テーブルに対して最後に行われた更新を読み取ることができるように、ストリームは DynamoDB ストリーム内に 24 時間保持されます。24 時間経過すると、ストリームは DynamoDB ストリームから自動的に削除されます。

Q: テーブルの DynamoDB ストリームを無効にするとどうなりますか?

DynamoDB ストリームを無効にした場合、ストリームは 24 時間保持されますが、DynamoDB テーブルに対して行われた追加変更で更新されなくなります。

Q: DynamoDB Streams を無効にした後で有効に戻すとどうなりますか?

DynamoDB Streams を無効にすると、ストリームは 24 時間保持されますが、DynamoDB テーブルに対して行われた追加変更で更新されることはありません。DynamoDB ストリームを有効に戻すと、DynamoDB ストリームに新しいストリームが作成され、作成時点以降に DynamoDB テーブルに対して行われた変更が格納されます。

Q: DynamoDB ストリームに重複またはギャップはありますか?

DynamoDB ストリームは、テーブルに対して行われた更新はすべて 1 度だけストリームに出力されるように設計されています。

Q: DynamoDB ストリームにはどのような情報が含まれていますか?

DynamoDB ストリームには、項目の変更前の値と変更後の値に関する情報が含まれます。また、変更タイプ(INSERT、REMOVE、または MODIFY)と変更された項目のプライマリキーも含まれます。

Q: DynamoDB ストリームに含める情報はどのようにして選択すればよいですか?

新しいテーブルの場合は、CreateTable API 呼び出しを使用し、ViewType パラメータを指定して、ストリームに含める情報を選択します。
既存のテーブルの場合は、UpdateTable API 呼び出しを使用し、ViewType パラメータを指定して、ストリームに含める情報を選択します。

ViewType パラメータは、次の値を持つことができます。

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

値には次のような意味があります。KEYS_ONLY: 変更のあった項目のキーの名前のみストリームに含められます。

  • NEW_IMAGE: キーの名前と更新後の項目(新しい項目)がストリームに含められます。
  • OLD_IMAGE: キーの名前と更新前の項目(古い項目)がストリームに含められます。
  • NEW_AND_OLD_IMAGES: キーの名前、更新前の項目(古い項目)と更新後の項目(新しい項目)がストリームに含められます。

Q: Kinesis クライアントライブラリを使用して DynamoDB ストリームにアクセスできますか?

Kinesis API を使い慣れている開発者は、DynamoDB ストリームを簡単に使用できるようになります。Amazon Kinesis インターフェイスを実装する DynamoDB Streams Adapter を使用すると、アプリケーションで Amazon Kinesis クライアントライブラリ(KCL)を使用して DynamoDB Streams にアクセスできます。KCL を使用して DynamoDB Streams にアクセスする詳細については、ドキュメントを参照してください。

Q: DynamoDB ストリームに含める情報の種類を変更できますか?

ストリームを作成した後でそこに格納する情報の種類を変更する場合は、そのストリームを無効にし、UpdateTable API を使用して新しいストリームを作成する必要があります。

Q: DynamoDB テーブルを変更したとき、どれくらいの時間でその変更が DynamoDB ストリームに表示されますか?

通常、変更は DynamoDB ストリームに 1 秒未満で反映されます。

Q: 項目を削除した場合、その変更は DynamoDB ストリームに含まれますか?

DynamoDB ストリーム内の各更新には、更新が削除されたのか、新しい項目が挿入されたのか、あるいは既存の項目が変更されたのかを指定するパラメーターが含まれます。更新の種類の詳細については、ドキュメントを参照してください。

Q: テーブルで DynamoDB ストリームを有効にした後、ストリームからの読み取りを開始できるのはいつですか?

DescribeStream API を使用してストリームの現在のステータスを取得できます。ステータスが [ENABLED] に変わったら、テーブルのすべての更新がストリームに含まれます。

ストリームの作成を開始するとすぐにストリームからの読み取りが始まりますが、ステータスが [ENABLED] に変わるまでは、テーブルの一部の更新がストリームに含まれない可能性があります。

Q: Amazon DynamoDB Logstash Plugin for Elasticsearch とは何ですか?

Elasticsearch は人気のあるオープンソースの検索、分析エンジンで、リアルタイム検索とビッグデータ分析を簡単に実現するよう設計されています。Logstash はオープンソースのデータパイプラインで、Elasticsearch と連携させることでログやその他のイベントデータの処理に役立ちます。Amazon DynamoDB Logstash Plugin によって、簡単に DynamoDB のテーブルを Elasticsearch クラスターに統合できます。

Q: Amazon DynamoDB Logstash Plugin の料金はいくらですか?

Amazon DynamoDB Logstash Plugin のダウンロードと使用は無料です。

Q: Amazon DynamoDB Logstash Plugin をダウンロードおよびインストールするにはどうすればよいですか?

Amazon DynamoDB Logstash Plugin は GitHub でダウンロードできます。プラグインのインストールと実行の詳細については、ドキュメントページを参照してください。


Q: DynamoDB Storage Backend for Titan とは何ですか?

DynamoDB Storage Backend for Titan は、お客様が DynamoDB を Titan のグラフデータベースの基盤となるストレージレイヤーとして使用することを可能にするプラグインです。これは、DynamoDB ですばやいグラフ探索を可能にする、インデックスフリーの隣接関係を実装するためのクライアント側のソリューションです。

Q: グラフデータベースとは何ですか?

グラフデータベースとは、頂点と、これらの頂点をつなぐ有向辺を保存したものです。頂点と辺はいずれも、キーと値のペアとして保存されたプロパティを持ちます。

グラフデータベースは隣接関係のリストを使用して辺を保存し、探索を容易にします。グラフデータベースのグラフは特定の辺のタイプによって、またはグラフ全体にかけて探索できます。グラフデータベースはアクション、所有権、親子関係などによって、エンティティ同士の関係性を表すことができます。

Q: グラフデータベースにはどのようなアプリケーションが適していますか?

モデル化するデータの核となるのがエンティティ同士のつながりまたは関係性である場合は、グラフデータベースが適しています。したがって、グラフデータベースはソーシャルネットワーク、ビジネス関係、依存関係、船舶移動などをモデル化およびクエリするのに便利です。

Q: DynamoDB Storage Backend for Titan の使用を開始するにはどうすればよいですか?

使用を開始する最も簡単な方法は、このドキュメントページに記載されている CloudFormation テンプレートを使用して、Gremlin サーバーを実行する EC2 インスタンスと DynamoDB Storage Backend for Titan を合わせて起動することです。また、GitHub レポジトリからプロジェクトを複製し、このドキュメントの指示に従って独自のコンピュータで Marvel および Graph-Of-The-Gods のチュートリアルを使用して開始することもできます。テストを拡大する、または本稼働環境で実行する準備ができたら、バックエンドを変更して DynamoDB サービスを使用できます。詳細は、この AWS ドキュメントをご覧ください。

Q: DynamoDB Storage Backend と他の Titan ストレージバックエンドの違いは何ですか?

DynamoDB はマネージドサービスです。そのため、DynamoDB を Titan のストレージバックエンドとして使用することで、グラフストレージのための独自のクラスターを管理することなくグラフワークロードを実行できます。

Q: DynamoDB Storage Backend for Titan は完全マネージドサービスですか?

いいえ。DynamoDB Storage Backend for Titan は、Titan ワークロードのストレージレイヤーを管理します。ただし、このプラグインではクライアント側のプロビジョンおよび管理は実行されません。Titan のプロビジョンを簡素化するため、AWS では DynamoDB Storage Backend for Titan を Gremlin で設定するための CloudFormation テンプレートを開発しました。こちらから手順をご覧ください。

Q: DynamoDB Storage Backend for Titan の使用料金はいくらですか?

お客様は、通常の DynamoDB スループットおよびストレージの費用を課金されます。Titan グラフのワークロード向けのストレージバックエンドとして DynamoDB を使用する場合、追加料金は発生しません。

Q: DynamoDB のバックエンドは、他のバックエンドに設定された Titan 機能と完全な互換性がありますか?

さまざまな Titan ストレージバックエンドの機能を比較した表がこちらのドキュメントでご覧いただけます。

Q: このプラグインはどのバージョンの Titan をサポートしていますか?

AWS は、バージョン 0.5.4 および 1.0.0 の Titan 向けの DynamoDB ストレージバックエンドプラグインをリリースしています。

Q: 現在、異なるバックエンドで Titan を使用しています。DynamoDB に移行できますか?

もちろんできます。DynamoDB Storage Backend for Titan は Titan KCV ストアインターフェイスを実装しているため、アプリケーションに最低限の変更を加えるだけで異なるストレージバックエンドから DynamoDB に移行できます。Titan のストレージバックエンドの完全な比較は、こちらのドキュメントをご覧ください。

Q: 現在、異なるバックエンドで Titan を使用しています。どうすれば DynamoDB に移行できますか?

バルクロードを使用して一方のストレージバックエンドから DynamoDB Storage Backend for Titan にグラフをコピーできます。

Q: Titan インスタンスをプラグイン経由で DynamoDB に接続するにはどうすればよいですか?

DynamoDB Storage Backend for Titan がインストールされた状態でグラフおよび Gremlin サーバーインスタンスを作成した場合、DynamoDB に接続するために必要なのは、デフォルトの AWS 認証情報プロバイダーチェーンにプリンシパルおよび認証情報のセットを提示することのみです。これは、EC2 インスタンスのプロファイル、環境変数、またはホームフォルダの認証情報ファイルによって実行可能です。最後に、接続する DynamoDB エンドポイントを選択する必要があります。

Q: DynamoDB Storage Backend for Titan を使用した場合、データの堅牢性はどの程度になりますか?

DynamoDB Storage Backend for Titan を使用した場合、Amazon の実証済みの、可用性の高いデータセンターにかけて実行される DynamoDB の強力な保護がデータに対して適用されます。このサービスでは、データが同じ AWS リージョン内の 3 つの施設間でレプリケートされるので、サーバー障害の発生やアベイラビリティーゾーンの停止に対する耐障害性が高まります。

Q: DynamoDB Storage Backend for Titan の安全性はどの程度ですか?

DynamoDB Storage Backend for Titan はグラフデータを複数の DynamoDB テーブルに保存するため、他のすべての DynamoDB ワークロードと同じく高いセキュリティが適用されます。Fine-Grained Access Control、IAM の役割、AWS プリンシパルおよび認証情報のセットが、DynamoDB テーブルおよび DynamoDB テーブルの項目へのアクセスを制御します。

Q: DynamoDB Storage Backend for Titan はどのようにスケールしますか?

DynamoDB Storage Backend for Titan は、DynamoDB の他のワークロードと同様にスケールできます。必要なスループットを随時増加または減少できます。

Q: グラフにはいくつの頂点および辺を含めることができますか?

辺の保管に複数項目モデルを使用している場合、Titan の制限である (2^60) で最大の辺の数が制限され、その半分の数の頂点をグラフに含めることができます。単一項目モデルを使用している場合、特定の 1 つの外頂点キーに保存できる辺の数は、DynamoDB の最大項目サイズ(現在は 400 KB)によって制限されます。

Q: 頂点および辺のプロパティはどのくらい大きくできますか?

複数項目モデルにおける辺のプロパティの合計は、最大の項目サイズである 400 KB を超えることはできません。複数項目モデルでは、各頂点のプロパティは最大で 400 KB までです。単一項目モデルでは、合計項目サイズ(頂点のプロパティ、辺および辺のプロパティを含む)が 400 KB を超えることはできません。

Q: いくつのデータモデルがあり、どのような違いがありますか?

DynamoDB Storage Backend for Titan には、単一項目モデルと複数項目モデルという 2 種類のストレージモデルがあります。単一項目のストレージモデルでは、頂点、頂点のプロパティ、辺が 1 つの項目に保存されます。複数項目のデータモデルでは、頂点、頂点のプロパティ、辺が異なる項目に保存されます。どちらの場合でも、辺のプロパティは対応する辺と同じ項目に保存されます。

Q: どちらのデータモデルを使用すればよいでしょうか?

通常、テーブルに対する辺の保管およびグラフのインデックス化には複数項目のデータモデルを推奨しています。そうでなければ、1 つの外頂点に対して保存できる辺および頂点のプロパティの数が制限される、もしくはグラフインデックス内の特定のプロパティの名前と値のペアに対してインデックス化できるエンティティの数が制限されることになります。通常、単一項目のデータモデルは Titan バージョン 0.5.4 および 1.0.0 の他の 4 KCV ストアに対して使用できます。これらに保存される各項目は通常 400 KB より小さくなるためです。Titan プラグインが DynamoDB に作成するテーブルの完全なリストは、こちらをご覧ください。

Q: Titan グラフデータベースのスキーマを作成する必要がありますか?

Titan は自動のタイプ作成をサポートしているため、新規の辺および頂点のプロパティとラベルは最初の使用時に迅速に登録されます (詳細についてはこちらをご覧ください)。Gremlin 構成 (Edge labels=MULTI、Vertex properties=SINGLE) がデフォルトで使用されています。

Q: Titan グラフデータベースのスキーマを変更できますか?

はい。ただし、既存の頂点および辺のプロパティとラベルのスキーマは変更できません。詳細については、こちらをご覧ください。

Q: DynamoDB Storage Backend for Titan はどのようにスーパーノードに対応しますか?

DynamoDB は頂点ラベルのパーティショニングによってスーパーノードに対応します。作成時に、頂点ラベルを管理システム内でパーティショニング済みと定義した場合、辺保管テーブル内のパーティションソートキースペースの複数のパーティションキーで、1 つの頂点から発生する辺および頂点のプロパティの複数のサブセットにキー付けをすることができます。通常、辺保管場所に 1 つよりも多いパーティションがある場合、これによって仮想の頂点ラベルのパーティションが異なる物理的 DynamoDB パーティションに保管されることになります。辺保管テーブルをバックアップする物理的パーティションの数を推測するには、こちらのドキュメントをご覧ください。

Q: DynamoDB Storage Backend for Titan はバッチグラフ操作をサポートしていますか?

はい。DynamoDB Storage Backend for Titan は Blueprints BatchGraph の実装によって、また Titan のバルクロード設定オプションの使用によってバッチグラフ操作をサポートしています。

Q: DynamoDB Storage Backend for Titan はトランザクションをサポートしていますか?

DynamoDB Storage Backend for Titan はオプティミスティックロックをサポートしています。つまり、DynamoDB Storage Backend for Titan では、キーと列のペアまたはキーの既存の値に対する個々のキーと列のペア(複数項目モデルの場合)または個々のキー(単一項目モデルの場合)の書き込みに条件をつけることができます。

Q: Titan インスタンスを 1 つのリージョンで所有し、他のリージョンで DynamoDB にアクセスできますか?

EC2 Titan インスタンスと異なるリージョンで DynamoDB エンドポイントにアクセスすることは可能ですが、推奨されません。Gremlin サーバーを EC2 で実行する場合、クロスリージョンのリクエストによるレイテンシーの影響を緩和するために、EC2 インスタンスと同じリージョンの DynamoDB エンドポイントに接続することを推奨します。また、ネットワークパフォーマンスを向上するため、EC2 インスタンスを VPC で実行することを推奨します。CloudFormation テンプレートが、この設定全体をお客様に代わって実行します。

Q: このプラグインと、ストリームの更新およびクロスリージョンレプリケーションなどの他の DynamoDB 機能を併用できますか?

クロスリージョンレプリケーションと DynamoDB ストリームの機能を使用して、グラフテーブルの読み取り専用レプリカを異なるリージョンに作成できます。


Q: Amazon DynamoDB は CloudWatch メトリックスをレポートしますか?

はい、Amazon DynamoDB は CloudWatch のいくつかのテーブルレベルのメトリックスをレポートします。Amazon DynamoDB テーブルについて運用上の決定を下し、それらメトリックスに基づいてアラームを設定するなどの具体的なアクションを起こすことができます。レポートされるすべてのメトリックスのリストについては、ドキュメンテーションの「CloudWatch による DynamoDB のモニタリング」セクションを参照してください。

Q: Amazon DynamoDB テーブルの CloudWatch メトリックスはどのようにして見ることができますか?

Amazon DynamoDB コンソールで、CloudWatch メトリックスを見るテーブルを選択し、[Metrics] タブを選択します。

Q: メトリックスはどれほどの頻度でレポートされますか?

Amazon DynamoDB の CloudWatch メトリックスのほとんどは 1 分間隔でレポートされます。一部のメトリックスは 5 分間隔でレポートされます。詳細については、ドキュメンテーションの「CloudWatch による DynamoDB のモニタリング」セクションを参照してください。