Jayendra’s Blog
この記事は自己学習用に「AWS DynamoDB – Certification(Jayendra’s Blogより)」を日本語に訳した記事です。
AWS DynamoDB
- Amazon DynamoDB は、完全に管理された NoSQL データベースサービスであり、
- 任意の量のデータを格納および取得し、任意のレベルの要求トラフィックを処理するために、シンプルでコスト効率の高い機能を提供します。
- シームレスな拡張性により、迅速かつ予測可能でパフォーマンスを提供します。
- DynamoDB では、ハードウェアのプロビジョニング、セットアップと構成、レプリケーション、ソフトウェアの適用、またはクラスタのスケーリングを心配することなく、分散データベースの運用およびスケーリングの管理上の負担を AWS にオフロードできます。
- DynamoDB テーブルには固定スキーマがないため、テーブルは項目で構成され、各項目の属性数が異なる場合があります。
- DynamoDB は、AWS リージョン内の3つの施設間でデータを同期的にレプリケートし、高可用性とデータの耐久性を提供します。
- DynamoDB は、インプレース更新を高速にサポートします。1つの API 呼び出しを使用して、数値属性を行でインクリメントまたはデクリメントすることができます。
- DynamoDB は、実証済みの暗号化方法を使用して、ユーザーを安全に認証し、不正なデータアクセスを防止します。
- 耐久性、パフォーマンス、信頼性、およびセキュリティは、SSD (ソリッドステートドライブ) ストレージと自動3ウェイレプリケーションで構築されています。
- DynamoDB では、次の2種類の主キーがサポートされます。
- パーティションキー (以前はハッシュキーと呼ばれていました)
- 1つの属性で構成される単純な主キー
- DynamoDB は、内部ハッシュ関数への入力としてパーティションキーの値を使用します。ハッシュ関数からの出力は、項目が格納されるパーティションを決定します。
- テーブル内の2つの項目に同じパーティションキー値を設定することはできません。
- パーティションキーとソートキー (以前はハッシュとレンジキーと呼ばれていました)
- 2つの属性で構成される複合主キー。最初の属性はパーティションキーで、2番目の属性は並べ替えキーです。
- DynamoDB は、内部ハッシュ関数への入力としてパーティションキー値を使用します。ハッシュ関数からの出力は、項目が格納されるパーティションを決定します。
- 同じパーティションキーを持つすべてのアイテムは、並べ替えキー値によって並べ替えられた順序でまとめて保存されます。
- 2つの項目が同じパーティションキー値を持つことは可能ですが、これらの2つの項目は異なる並べ替えキー値を持つ必要があります。
- パーティションキー (以前はハッシュキーと呼ばれていました)
- DynamoDB セカンダリインデックス
- パフォーマンスに影響を与えることなく、クエリに柔軟性を追加します。
- セカンダリインデックスは、スパースオブジェクトとして自動的に保持され、インデックスが定義されているテーブルに存在する場合にのみ、インデックスに対して項目が表示され、インデックスに対するクエリが非常に効率的になります。
- DynamoDB のスループットと1桁のミリ秒のレイテンシにより、ゲーム、アドテック、モバイル、その他多くのアプリケーションに最適。
- ElastiCache を DynamoDB の前で使用して、頻繁に変更されないデータに対して大量の読み取りをオフロードすることができます。
DynamoDB パフォーマンス
- 水平方向に自動的にスケーリング
- ソリッドステートドライブ (SSD) 上で排他的に実行されます。
- SSD は、任意の縮尺でデータを格納およびアクセスするための、予測可能な低レイテンシ応答時間の設計目標を達成するのに役立ちます。
- SSD の高い I/O パフォーマンスにより、高スケールの要求作業負荷を効率的に処理し、低要求価格に沿ってこの効率性を渡すことができます。
- プロビジョニングされたテーブルの読み取りと書き込みを許可。
- 必要に応じてスループットをスケールアップします。
- UTC のカレンダーの日あたりの4回のスループットをスケールダウンします。
- データを自動的にパーティション化、再、再パーティション化し、サーバ容量を追加します。
- テーブルサイズが大きくなったり
- プロビジョニングされたスループットが向上
- グローバル・セカンダリ・インデックス (GSI)
- 後で作成することも、後で追加することもできます。
DynamoDB の一貫性
- 各 DynamoDB テーブルは、3つの地理的に分散した場所に自動的に保存され、耐久性が確保されます。
- 読み取りの一貫性は、データ項目の書き込みまたは更新が、その同じ項目の後続の読み取り操作に反映される方法とタイミングを表します。
- DynamoDB では、ユーザーは、要求時に読み取りが最終的に一貫性があるか、厳密に一致するかを指定できます。
- 結果整合性読み込み (default)
- 最終的に整合性オプションは、読み取りスループットを最大化します。
- すべてのコピーにわたる一貫性は、通常、2秒以内に到達します。
- ただし、最終的に一貫性のある読み取りは、最近完了した書き込みの結果を反映していない可能性があります。
- 短時間後に読み取りを繰り返すと、更新されたデータが返されます。
- 強一貫性読み込み
- 厳密に一貫性のある読み取りは、読み取り前に成功した応答を受信したすべての書き込みを反映する結果を返します。
- 結果整合性読み込み (default)
- クエリ、GetItem、および BatchGetItem の各操作は、既定で最終的に一貫した読み取りを実行します。
- クエリおよび GetItem 操作を強制的に厳密に一貫性を持たせることができます。
- クエリ操作は、グローバルセカンダリインデックスに対して厳密に一貫した読み取りを実行できません。
- BatchGetItem 操作は、テーブルごとに厳密に一貫性を持たせることができます。
DynamoDB セカンダリインデックス
- DynamoDB は、ローカルおよびグローバルのセカンダリインデックスをサポートします。AWS DynamoDB セカンダリインデックスに関するブログ記事を参照してください。
DynamoDBクロスリージョンレプリケーション
- DynamoDB クロスリージョンレプリケーションでは、1つ以上の AWS リージョンで管理される DynamoDB テーブル (マスタテーブルと呼ばれる) の同一のコピー (レプリカと呼ばれます) を使用できます。
- テーブルへの書き込みは、すべてのレプリカに自動的に反映されます。
- クロスリージョンレプリケーションは現在、シングルマスターモードをサポートしています。1つのマスターテーブルと1つ以上のレプリカテーブルがあります。
- 読み取りレプリカは、マスターテーブルによって受け入れられると、DynamoDB によって書き込み操作が成功したと認識されるため、非同期的に更新されます。書き込みは、わずかな遅延で各レプリカに伝達されます。
- クロスリージョンレプリケーションは、シナリオで役立ちます。
- データセンターの障害が発生した場合の効率的な災害復旧。
- 最も近い AWS データセンターから DynamoDB テーブルを読み取ることにより、データをより高速に配信し、複数のリージョンのお客様に対して高速読み取りを行います。
- より簡単なトラフィック管理により、読み取りワークロードをテーブル間で分散し、マスタテーブルの読み取りキャパシティーを消費することが少なくなります。
- マスタへのリードレプリカのプロモートによる簡単なリージョン移行
- ライブデータの移行、データのレプリケート、およびテーブルの同期が行われるときに、アプリケーションを変換先リージョンに書き込むように切り替えます。
- クロスリージョンレプリケーションの原価計算は、
- プロビジョニングされたスループット (書き込みと読み取り)
- レプリカテーブルのストレージ
- リージョン間のデータ転送
- テーブルの同期を維持するために、DynamoDB ストリームからデータを読み取ります。
- インスタンスタイプとリージョンに応じて、プロビジョニングされた EC2 インスタンスのコストで、レプリケーションプロセスをホストします。
- 注:DynamoDBのクロスリージョンレプリケーションは、DynamoDBストリームとアウトオブボックスクロスリージョンレプリケーションのサポートの前に、EMR を内部的に使用してデータを転送する AWS データパイプラインジョブを定義して実行されました
DynamoDB ストリーム
- DynamoDB ストリームは、最後の24時間以内にテーブル内のデータに対して行われた項目レベルの変更の時系列順序を提供し、その後、アイテムごとのイベントの順序付けられたシーケンスが保持されていることを消去します。
- DynamoDB ストリームはテーブル単位で有効にする必要があります。
- Dynamodb ストリームをマルチリージョンレプリケーションに使用して、他のデータを最新の Dynamodb に変更したり、テーブルに加えられた変更に基づいてアクションを実行したりすることができます。
- DynamoDB ストリーム API を使用すると、開発者は更新を消費し、アイテムが変更された前後にアイテムレベルのデータを受け取ることができます。
- Dynamodb ストリームは、Dynamodb テーブルのプロビジョニングされた書き込みキャパシティーの最大2倍の速度で読み取ることができます。
- DynamoDB ストリームは、テーブルに対して行われるすべての更新がストリーム内で1回だけ表示されるように設計されています。
DynamoDB トリガ
- Dynamodb トリガは、Dynamodb テーブルのアイテムレベルの更新に基づいてカスタムアクションを実行できる機能です。
- Dynamodb トリガは、通知の送信、集計テーブルの更新、Dynamodb テーブルと他のデータソースへの接続などのシナリオで使用できます。
DynamoDB コスト
- インデックス・ストレージ
- DynamoDB はインデックス付きデータストアです。
- 請求可能データ = 未処理バイトデータサイズ + 100 バイト/アイテムストレージインデックスのオーバーヘッド
- DynamoDB はインデックス付きデータストアです。
- プロビジョニングされたスループット
- テーブルに対してプロビジョニングされたスループットとして予約された容量に基づいて、フラットな時間単価を支払う。
- 1つの書き込みキャパシティーユニットでは、1秒あたりの書き込みが可能です。
- 1つの読み取りキャパシティーユニットは、1秒あたりの読み取り (または2つの最終的に整合性のとれた読み取り) を提供します。
- プロビジョニングされたスループットは、10 単位ごとの書き込みキャパシティー、50 単位ごとの読み取りキャパシティーに課金されます。
- 予約容量
- 通常価格以上の大幅な節約。
- 1回の前払い料金を支払う
DynamoDB のベストプラクティス
- アイテムサイズを小さく保つ。
- Amazon S3 の DynamoDB およびラージ BLOB にメタデータを格納する。
- 時系列データを格納するために、1日、週、月などのテーブルを使用する。
- 条件付きまたはオプティミスティック同時実行制御 (OCC) 更新の使用。
- オプティミスティック同時実行制御は、RDMS のオプティミスティックロックのようなものです。
- 通常、データの競合が少ない環境では、競合がまれであり、ロックやトランザクションの管理を犠牲にすることなくトランザクションを完了できます。
- 複数のトランザクションが互いに干渉することなく、頻繁に完了できることを前提としています。
- トランザクションは、これらのリソースに対してロックを取得せずに、他のトランザクションロックのクリアを待機することなく、データリソースを使用して実行されます。
- トランザクションがコミットされる前に、データが他のトランザクションによって変更されたかどうかが検証されます。その場合は、rollbacked になり、更新されたデータを使用して再起動する必要があります。
- デッドロックを回避しても効果的な並行処理を大幅に制限できるため、OCC はペシミスティック・ロックなどの他の同時実行制御方式と比較してスループットが向上します。
- ホットキーとホットパーティションを避ける。
AWS認定試験の練習問題
- 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます(これはあなたと異なる場合があります)。
- AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
- AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
- さらなるフィードバック、ディスカッション、修正を可能にします。
- Amazon DynamoDB の使用例を次に示します。3つの回答を選択
- BLOB データを格納する。
- web セッションの管理
- JSON ドキュメントの保存
- Amazon S3 オブジェクトのメタデータの保存
- リレーショナル結合と複雑な更新を実行する。
- 大量のアクセス頻度の低いデータを格納する。
- 自動スケーリングを使用するために会社のアプリケーションを設定しており、ユーザーの状態情報を移動する必要があります。耐久性と待ち時間の短い共有データストアを提供する次の AWS サービスはどれですか?
- AWS ElastiCache Memcached (書き込みを許可しません)
- Amazon S3 (低レイテンシを提供していません)
- Amazon EC2 インスタンスストレージ (永続的ではない)
- Amazon DynamoDB
- DynamoDB は、インプレースのアトミック更新をサポートしていますか?
- 定義されていません
- いいえ
- はい
- これは、インプレース非アトミック更新をサポートしています
- 1つの動的 DB テーブルに対してプロビジョニングできる書き込みスループットの最大値を教えてください。
- 1000書き込みキャパシティーユニット
- 10万書き込みキャパシティーユニット
- 動的 DB は制限なくスケーリングするように設計されていますが、1万を超えた場合は、まず AWS に連絡する必要があります
- 1万書き込みキャパシティーユニット
- DynamoDB テーブルの場合、アプリケーションがプロビジョニングされた容量よりも多くの読み取りまたは書き込みを実行した場合はどうなりますか。
- 何もない
- プロビジョニングされた容量を超える要求は実行されますが、400エラーコードが表示されます。
- プロビジョニングされた容量を超える要求は実行されますが、200エラーコードが表示されます。
- プロビジョニングされた容量を超える要求は調整され、400のエラーコードが表示されます。
- DynamoDBを使用することでどのような利点が得られますか?(2 つの回答を選択)
- 非常に複雑なクエリを処理するには、完全に管理されたデータベースが必要です。
- 膨大な量の「ホット」データを処理し、非常に短い待ち時間を必要とします。
- ユーザーの行動に関するデータを収集するためには、迅速なクリックストリームの取り込みが必要です。
- オンプレミスのデータセンターは Oracle データベースを実行し、AWS クラウドでバックアップをホストする必要があります。
- ファイル共有サービスを設計しています。このサービスには何百万ものファイルがあります。サービスの収益は、ユーザーが使用しているストレージの量に基づいて料金から得られます。また、タイトル、説明、オブジェクトがパブリックであるか非公開であるかなど、各ファイルにメタデータを格納します。どのようにあなたは経済的であり、何百万ものユーザーに拡張できる方法で、これらの目標のすべてを達成するのですか?[PROFESSIONAL]
- すべてのファイルを Amazon シンプルストレージサービス (S3) に保存します。ユーザーごとにバケットを作成します。各オブジェクトのファイル名にメタデータを格納し、S3 API に対してリストコマンドを使用してアクセスします。(それは一度に1000アイテムだけを返すように高価で遅い)
- すべてのファイルを Amazon S3 に保存します。オブジェクトがアップロードされるときに、関連するメタデータの対応するキーと値のペアの Amazon DynamoDB テーブルを作成します。
- データを格納するために、4000 IOPS の Elastic 負荷分散ボリュームのストライプセットを作成します。Amazon リレーショナルデータベースサービス (RDS) で実行されているデータベースを使用して、メタデータを格納します。(ボリュームのある経済的ではありません)
- データを格納するために、4000 IOPS の Elastic 負荷分散ボリュームのストライプセットを作成します。オブジェクトがアップロードされるときに、関連するメタデータの対応するキーと値のペアのAmazon DynamoDB テーブルを作成します。(ボリュームのある経済的ではありません)
- ユーティリティ会社は、1万以上のセンサーからのデータを格納するアプリケーションを構築しています。各センサーは、ユニークな ID を持ち、一日中10分ごとに datapoint (約1万) を送信します。各 datapoint は、タイムスタンプだけでなく、センサーから来る情報が含まれています。この会社は非常に急速に過去1週間の特定のセンサーから来る情報を照会し、4週より古いすべてのデータを削除したいと思います。Amazon DynamoDB を使用してスケーラビリティと迅速さを実現するために、最もコスト効率の高い方法でこれを実装するにはどうすればよいでしょうか。[PROFESSIONAL]
- 1つのテーブルで、主キーがセンサー ID で、タイムスタンプであるハッシュキー (シングルテーブルがパフォーマンスに影響します)
- センサー ID とタイムスタンプの連結である主キーを持つ1つのテーブル (単一テーブルと連結によるパフォーマンスへの影響)
- 各週の1つのテーブルに、センサー ID とタイムスタンプを連結した主キーを使用します (連結によってクエリの速度が遅くなります)
- 週ごとに1つのテーブルで、主キーがセンサー ID であり、タイムスタンプであるハッシュキー (センサー ID とタイムスタンプを持つ複合キーを使用すると、クエリの高速化に役立ちます)
- あなたは最近、都市部の街路騒音や空気の質を測定するためにセンサーを構築するスタートアップ会社に参加している。同社は3カ月間、約100のセンサーのパイロット展開を実行している。各センサーは、1分ごとのセンサーデータを AWS でホストされているバックエンドにアップロードします。パイロットの間、データベースで 10 IOPS のピークを測定し、1か月あたり平均 3GB のセンサーデータをデータベースに格納しました。現在のデプロイメントは、EC2 インスタンスと、500GB 標準ストレージを持つ PostgreSQL RDS データベースを使用して、負荷分散された自動スケール取り込みレイヤで構成します。パイロットは、成功と考えられているあなたの CEO は、注目やいくつかの潜在的な投資家を得るために管理しています。ビジネスプランでは、バックエンドでサポートする必要がある少なくとも100K のセンサーを展開する必要があります。また、年間の改善を比較することができるように、少なくとも2年間のセンサーデータを格納する必要があります。資金調達を確保するには、プラットフォームがこれらの要件を満たしていることを確認し、さらにスケーリングする余地を残しておく必要があります。要件を満たすセットアップはどれですか。[PROFESSIONAL]
- 取り込みレイヤーに SQS キューを追加して、RDS インスタンスへの書き込みをバッファリングする (RDS インスタンスは2年間データをサポートしません)
- データを DynamoDB テーブルに取り込み、古いデータを Redshift クラスターに移動する (10K IOPS の取り込みを処理し、分析のためにデータを Redshift に格納する)
- 96TB のストレージを使用して、RDS インスタンスを6ノードの Redshift クラスタに置き換えます (取り込みの問題は処理されません)。
- 現在のアーキテクチャを維持し、RDS ストレージを3TB および10k プロビジョニングされた IOPS にアップグレードします (RDS インスタンスは2年間データをサポートしません)
- Amazon DynamoDB は、増加と減少の両方のアトミック操作をサポートしていますか?
- いいえ、増加も減少操作もありません。
- 減少は DynamoDB のデータモデルでは本質的に不可能であるため、増加のみを行います。
- 増加は DynamoDB のデータモデルでは本質的に不可能であるため、減少のみです。
- はい、増加と減少の両方の操作。
- DynamoDB のデータモデルについて教えてください。
- キーと1つ以上の属性を持つ”アイテム”。 “名前” と “値” の “属性” があります。
- “データベース” は “表” の集合であり、”アイテム” の集合であり、”属性” の集合である。
- “テーブル”、アイテムのコレクション。キーと1つ以上の属性を持つ “アイテム”。 “名前” と “値” の “属性” があります。
- “データベース”、テーブルのコレクション。キーと1つ以上の属性を持つ “テーブル”。 “名前” と “値” の “属性” があります。
- DynamoDB に関しては、次のパラメータのいずれかが Amazon では課金されません。
- プロビジョニングされた書き込み単位あたりのコスト
- プロビジョニングされた読み取り単位あたりのコスト
- ストレージコスト
- 同じリージョン内の I/O 使用量
- DynamoDBに関する正しい記述はどれですか? 2つの答えを選択してください。
- DynamoDB は悲観的ロックモデルを使用します。
- DynamoDB はオプティミスティック同時実行制御を使用します。
- DynamoDB は整合性のために条件付き書き込みを使用します。
- DynamoDB は読み取り中にアイテムへのアクセスを制限します。
- DynamoDB は書き込み中にアイテムのアクセスを制限します。
- プロビジョニングされたスループット効率のための優れた DynamoDB ハッシュキースキーマの例は次のうちどれですか?
- アプリケーションに多くの異なるユーザーがいるユーザー ID。
- ほとんどのステータスコードが同じである状態を表示します。
- デバイス ID は、1つが他のすべてよりもはるかに人気があります。
- ゲームの種類は、3つの可能なゲームの種類があります。
- DynamoDB テーブルの1秒ごとに1000の新しいアイテムを挿入しています。これらの項目は1時間に一度分析され、必要なくなります。プロビジョニングされたスループット、ストレージ、および API 呼び出しを最小限に抑える必要があります。これらの要件を考慮して、分析後にこれらの項目を管理する最も効率的な方法は何ですか?
- 1つのテーブルのアイテムを保持する。
- 24時間以内に個別にアイテムを削除する。
- テーブルを削除し、時間ごとに新しいテーブルを作成する。
- 1時間ごとに新しいテーブルを作成する。
- DynamoDB で大規模なスキャン操作を使用する場合、テーブルのプロビジョニングされたスループットに対するスキャンの影響を最小限に抑えるためにどのような手法を使用できますか?
- スキャンのページサイズを小さく設定する (リンクを参照)
- 並列スキャンを使用する
- テーブルのレンジインデックスを定義する
- すべてのアイテムを更新してテーブルを暖気する
- DynamoDB に関しては、次のステートメントのどれが正しいですか。
- 項目には、少なくとも2つの値セット、主キー、および別の属性が必要です。
- アイテムは複数の属性を持つことができます。
- 主キーは単一値である必要があります。
- 属性は、1つまたは複数の他の属性を持つことができます。
- 次のいずれかのステートメントは、DynamoDB がソリッドステートドライブ(SSD)上に構築されている利点ではありません。
- 高スケールの要求ワークロードを提供
- 低要求価格
- EC2 インスタンス上での WEB の高い I/O パフォーマンス (DynamoDB とは関係ありません)
- 低遅延応答時間
- 次のいずれかの操作は、DynamoDB 操作ではありませんか。
- Batchwriteitem
- DescribeTable
- Batchgetitem
- BatchDeleteItem (DeleteItem は主キーによってテーブル内の1つの項目を削除しますが、BatchDeleteItem は存在しません)
- 1つの API 呼び出しで DynamoDB テーブルから複数のアイテムを取得できるアイテム操作は何ですか。
- Getitem
- Batchgetitem
- GetMultipleItems
- GetItemRange
- アプリケーションは、数百のオフィスにまたがる多数の従業員のために、DynamoDB で毎晩給与情報を保存します。項目の属性は、個々の名前、オフィスの識別子、および累積的な毎日の時間で構成されます。管理者は、オフィスで働いている名前の範囲のレポートを実行します。1つのクエリです。”A から始まる名前については、このオフィス内のすべての項目を返す”.このクエリのプロビジョニングされたスループットに最も影響を与えるテーブル構成はどれですか。[PROFESSIONAL]
- Name 属性にハッシュインデックスを持つようにテーブルを構成し、Office 識別子のレンジインデックス
- Name 属性のレンジインデックスを持つようにテーブルを構成し、Office 識別子のハッシュインデックス
- Name 属性とレンジインデックスなしでハッシュインデックスを構成する
- [Office id] 属性およびレンジインデックスなしでハッシュインデックスを構成する
- 1000万レコードを1時間で DynamoDB に移行する必要があります。すべてのレコードのサイズは 1.5 KB です。データは、パーティションキー全体に均等に分散されます。このバッチロード中にプロビジョニングする必要がある書き込みキャパシティーユニットの数を教えてください。
- 6667
- 4166
- 5556 (2 つの書き込み単位 (各 1 kb) * 10000000/3600 秒、参照リンク)
- 2778
- 気象システムは 600 の温度計を監視し、毎分温度サンプルを取得し、各サンプルを DynamoDB テーブルに保存します。各サンプルには1K のデータが書き込まれ、書き込みは時間の経過と共に均等に分散されます。ターゲット・テーブルに必要な書き込みスループットはどれくらいですか。
- 1書き込みキャパシティーユニット
- 10書き込みキャパシティーユニット (1k * 600 ゲージ用1書き込みユニット/60 秒)
- 60書き込みキャパシティーユニット
- 600書き込みキャパシティーユニット
- 3600書き込みキャパシティーユニット
- DynamoDB でゲームハイスコアテーブルを構築しています。各ゲームの各ユーザーの最高得点を格納します, 多くのゲームと, すべては、比較的類似した使用レベルと選手の数を持っている.あなたはすべてのゲームのための最高のスコアをルックアップすることができる必要があります。最高の DynamoDB キー構造は何ですか?
- ハッシュ/唯一のキーとして HighestScore します。
- GameID をハッシュキーとして、HighestScore を範囲キーとして指定します。(ハッシュ (パーティション) キーは GameID である必要があり、HighestScore を注文するための範囲キーがある必要があります。リンク参照)
- ハッシュ/唯一のキーとして GameID します。
- GameID を範囲/唯一のキーとして指定します。
- DynamoDB テーブルへの書き込み中にパフォーマンスの問題が発生しています。お使いのシステムは、市場でのビデオゲームの高得点を追跡します。あなたの最も人気のあるゲームは、すべてのパフォーマンスの問題を経験する。最も可能性の高い問題は何ですか?
- DynamoDB のベクトルクロックは、最も人気のあるゲームのための要求の急速な成長のために、同期していません。
- テーブルのプライマリパーティションキーとして、ゲーム ID または同等の識別子を選択しました。(リンク参照)
- 最も人気のあるビデオゲームのユーザーは、それぞれ平均よりも多くの読み取りおよび書き込み要求を実行します。
- テーブルに十分な読み取りまたは書き込みスループットを提供しませんでした。
- DynamoDB テーブルに書き込み中で、次の例外が発生しました: “ProvisionedThroughputExceededException”。 表の Cloudwatch メトリックによれば、プロビジョニングされたスループットを超えているわけではありません。 これについての説明は何でしょうか?
- 十分な DynamoDB ストレージインスタンスをプロビジョニングしていません
- 特定の範囲キーの容量を超えている
- 特定のハッシュキーで容量を超えている(ハッシュキーはパーティションとそれに伴うパフォーマンスを決定する)
- 特定の並べ替えキーの容量を超えている
- DynamoDB 自動スケーリングトリガが構成されていません
- あなたの会社は、消費者向けデバイスを販売し、すべての販売されたデバイスの最初の活性化を記録する必要があります。デバイスは、情報が永続的なデータベースに書き込まれるまでアクティブ化されません。アクティベーションデータは、あなたの会社にとって非常に重要であり、MapReduce の仕事で毎日分析する必要があります。データ分析プロセスの実行時間は1日3時間未満でなければなりません。デバイスは、通常、年の間に均等に販売されているが、新しいデバイスモデルが出ているときに、アクティベーションの予測可能なピークがある、つまり、数日のためにある10倍またはさらに100倍以上の活性化の平均日よりも。このワークロードのコストとパフォーマンスを最適化するために、次のデータベースと分析フレームワークを実装しますか。[PROFESSIONAL]
- Amazon RDS および Amazon の Elastic MapReduce にスポットインスタンスを使用します。
- Amazon DynamoDB および Amazon Elastic MapReduce にスポットインスタンスを使用します。
- Amazon RDS および Amazon Elastic MapReduce にリザーブドインスタンスがあります。
- リザーブドインスタンスを持つ Amazon DynamoDB および Amazon Elastic MapReduce
コメントを残す