6

モバイル iOS アプリを作成しています。ユーザーはアカウントを作成し、文字列をアップロードできます。ツイッターのようなもので、人々をフォローしたり、プロフィール写真を撮ったりすることができます。ユーザーベースを見積もることはできませんが、アプリがうまくいけば、データセット全体はかなり大きくなる可能性があります。

Amazon S3 に実際のオブジェクトを保存し、DataBase にキーを保存しています。Amazon S3 キーのリストは遅いです。では、鍵の保管にはどちらが適しているでしょうか?

これは、SimpleDB と DynamoDB に関する私の知識です。

シンプルDB:

  • 安いです
  • うまく機能します
  • 小規模/中規模のデータセット向けに設計
  • 選択式を使用してクエリを実行できます

ダイナモDB:

  • 高価な
  • 非常にスケーラブル
  • 優れたパフォーマンスを発揮します。ミリ秒応答
  • クエリできません

これらの点は私の理解では正しいです。DynamoDB はキラーに関するものです。速度とスケーラビリティよりも、SimpleDB はクエリと価格に重点を置いています (それでも優れたパフォーマンスを提供します)。しかし、このように見ると、DynamoDB からすべてのキーをダウンロードするのと、SimpleDB で選択クエリを実行するのとでは、どちらが速いでしょうか? 1 つは非常に高速なデータベースを使用して大量のダウンロードを行う(そしてそれらを一致させる必要がある) ことであり、もう 1 つは適度にパフォーマンスの高いデータベースを使用して少数の正しいオブジェクトをクエリおよびダウンロードすることです。だから、どちらが速いですか：

DynamoDB がすべてをダウンロードしてマッチングする OR SimpleDB がクエリを実行してダウンロードする

（注：マッチングとは-rangeOfString、文字列比較を使用することを意味するだけであり、電力を消費したり、時間効率が悪い、またはサーバー側のものは何もありません）

私の S3 キーは、すべてのタイプのオブジェクトにこの形式を使用します

accountUsername:typeOfObject:randomGeneratedKey

例: アカウント オブジェクトを参照している場合

ローハン: アカウント: shd83SHD93028rF

またはプロフィール写真:

Rohan:ProfilePic:Nck83S348DD93028rF37849SNDh

一意性のためにランダムに生成されたキーがあります。それは何も参照しません。キーが繰り返されないように、2 つのオブジェクトが重複しているだけです。

私のアプリでは、SimpleDB または DynamoDB のいずれかを選択できるため、次の 2 つのオプションがあります。

  • SimpleDB を使用し、その形式でキーを格納しますが、参照には形式を使用しません。代わりに、SimpleDB に格納された属性を使用します。そのため、ユーザー名、タイプなどの属性とともにキーを保存し、キー形式に含める必要があるその他の属性も使用します。したがって、ユーザー 'Rohan' からアカウント オブジェクトを取得したい場合。SimpleDB Select を使用して、属性「username」と属性「type」を照会するだけです。（「アカウント」に一致する場所）

  • DynamoDB、ストア キー、および各キーは図に示す形式になります。データベース全体をスキャンして、すべてのキーを返します。次に、キーを取得し、キー形式を利用-rangeOfStringして、必要なものを一致させ、S3 からダウンロードできます。

また、SimpleDB は地理的に分散しているようですが、どうすれば有効にできますか?

では、どちらがより迅速で信頼性が高いでしょうか? SimpleDB を使用して、属性を持つキーをクエリします。または、DynamoDB を使用してすべてのキーを保存し、スキャン (すべてのキーをダウンロード) して、たとえば-rangeOfString? これらは、S3 オブジェクトへのポインターである短いキーに過ぎないことに注意してください。

これが私の最後の質問です。データベース内のオブジェクトの量は、決定された答えによって異なります。

  • ユーザーが持つオブジェクトごとに個別のキー/オブジェクトを作成する
  • アカウントキー/オブジェクトを作成し、そこにすべての情報を保存します

明らかに、これら 2 つのオプションにはさまざまな長所と短所があります。たとえば、すべてが分離されていると取得が速くなりますが、1 つのユーザー アカウントに格納するためのデータセットはより整理され、サイズも小さくなります。

それで、あなたはどう思いますか？

助けてくれてありがとう！私はこれに賞金をかけました。本当に早急に回答が必要です。

4

1 に答える 1

7

わお！何の質問 ：）

さて、いくつかの側面について話し合いましょう。

S3

キーを一覧表示するためのプレフィックスを追加していないため、S3のパフォーマンスは低い可能性があります。

次のようなオブジェクトを保存してシャーディングする場合type/owner/id、特定の所有者（type / owner /のプレフィックス）のすべてのIDをすばやく一覧表示できます。または、少なくとも、すべてを一度にリストするよりも高速です。

DynamoとSimpleDB

一般的に、それは私のアドバイスです：

  • SimpleDBは次の場合に使用します。

    • エンティティストレージが10GBを超えることはありません
    • 複数のフィールドを含む複雑なクエリを適用する必要があります
    • クエリが明確に定義されていません
    • 複数値のデータ型から活用できます

  • 次の場合にDynamoDBを使用します。

    • エンティティストレージは10GBを通過します
    • 需要/スループットを段階的にスケーリングしたい
    • クエリとモデルは明確に定義されており、変更される可能性はほとんどありません。
    • モデルは動的であり、緩いスキーマが含まれます
    • クライアント側でクエリをキャッシュできます（Dynamoの前にキャッシュをクエリすることでスループットを節約できます）
    • Atomic Updatesを使用して、集計/ロールアップの要約を実行したい

現在の説明を考えると、SimpleDBの方が実際には優れているようです。-モデルが完全に定義されていない-（10GiB）の制限に達するまでに時間がかかるため、いくつかの決定の側面を延期することができます

地理的なSimpleDB

サポートしていません。それは私たちからのみ機能します-east-1afaik。

キーネーミング

これはDynamoに最も当てはまります。可能な場合は常に、ハッシュ+範囲キーを使用してください。ただし、ハッシュを使用してキーを作成し、次のようなクエリを適用することもできます。

  • で始まるテーブルTにすべてのレコードを一覧表示しますaccountid:
  • で始まるテーブルTにすべてのレコードを一覧表示しますaccountid:image

ただし、これらはまったくスキャンです。それを覚えておいてください。

（概要については、こちらをご覧ください：http: //docs.amazonwebservices.com/amazondynamodb/latest/developerguide/API_Scan.html）

ボーナストラック

Javaを使用している場合、Maven Centralのcloudy-dataには、BlobフィールドをS3にマップするためのいくつかの拡張機能を備えたSimpleJPAが含まれています。だからそれを見てください：

http://bitbucket.org/ingenieux/cloudy

ありがとうございました

于 2013-01-11T20:10:06.780 に答える