AWS ElastiCache / SimpleQueueとDynamoDB

ElastiCache / SimpleQueueを使用することと、DynamoDB内にそれぞれ「キャッシュ」テーブルと「キュー」テーブルをそれぞれ持つ理由について、私は疑問に思っています。

キャッシュ/キューサービスへのネットワークレイテンシは、パフォーマンスの向上に大きく勝ると思われ、キャッシュ/キューサービスとしてEC2がDynamoを処理すると、同じレイテンシとスループットが提供されるようです（Dynamoでは、負荷）。

主に負荷のかかったダイナモ対他のサービスの価格についてですか？

DynamoとElastiCache / SQSを比較した大まかなレイテンシー値はありますか？

追加の複雑さを正当化する他のより重要な考慮事項がありませんか？

ありがとう。

さまざまな理由でDynamoDBとElastiCache Redisを使用しています。

DynamoDB：

• より複雑なこと（より大きい、間など）を実行できるクエリ言語を持っている
• 外部のインターネットに接続されたAPIを介して到達可能です（変更や独自のインフラストラクチャなしで異なる地域に到達可能です）
• テーブルまたは行に基づくアクセス許可が可能です
• データサイズの観点から無限にスケーリング
• リクエストごとに支払う->リクエスト数が少ないと請求額が少なくなり、リクエスト数が多いと請求額が増える
• 読み取りと書き込みはコストが異なります
• データは複数の施設でAWSによって冗長に保存されます
• DynamoDBはすぐに使用できる高可用性
• 自動スケーリングはサービス自体で利用可能です

ElastiCache Redis：

• シンプルなクエリ言語-複雑な機能はありません
• 他の地域からは（すぐに）到達できません。
• メモリの量（またはクラスター内のすべてのプライマリインスタンスの合計）に常に制限されます。
• 複数のインスタンスでのシャーディングはアプリケーション内でのみ可能です-Redisはここでは何もしません（Redisクラスターはここで役立ちますが、シャーディングロジックはアプリケーションで使用しているドライバー/ sdkの内部にあります）-スケールインとスケール-現時点では、ダウンタイムなしではアウトできません
• 負荷やリクエストの数に関係なく、インスタンスごとに支払います。
• データの冗長性が必要な場合は、レプリケーションをセットアップする必要があります（異なるリージョン間では不可能です）
• 高可用性のためにレプリカを使用する必要があります
• 自動スケーリングは使用できません（上記のスケーリングなしに関する部分を参照）

そのため、ほとんどの場合、セットアップは次のようになります。DynamoDBによって永続的かつ長期的なストレージとしてバックアップされるRedisの大量のリクエストを含むシンプルなキャッシュ。これにより、Redisのインスタンスごとの支払いモデルによる読み取りの暗黙的な割引が得られるため、コストが制限されますが、DynamoDBの冗長性の利点も得られ、DynamoDBクエリ言語をさらに複雑なものに使用することもできます（必要な場合）。

お役に立てば幸いです！

更新：Amazon DynamoDB Accelerator（https://aws.amazon.com/de/dynamodb/dax/）の発表により、DAXをそのまま（最終的に）使用するように切り替えています。 DynamoDBとRedisの組み合わせ。DAXはAWSによって完全に管理されておらず、アプリケーションで常にDynamoDB言語を使用する機会を与えてくれるだけでなく、Redisのようなライトスルーキャッシュからも利益を得ることができます。

DynamoDBではなくElasticacheを使用する主な理由は速度です。小さなオブジェクトの場合、1ミリ秒未満の往復遅延が発生します。ボックスはEC2マシンに本当に近く、メモリはディスク、SSDよりもはるかに高速です。

さまざまな価格設定モデルを考えると、コスト面でも有利になる可能性がありますが、ここでは詳しく説明していません。

Redis / memcachedはメモリ内ストアであり、一般的にキャッシュ/キュータイプのデータについてはDynamoDBよりも高速である必要があります。また、期限切れキー、RedisのPub / Subなど、Dynamoにはない便利な追加アイテムもあります。