51

SimpleDB を使用して、アプリケーションの最も困難な領域 (スケーリングに関する限り) を処理できると考えていました。これは、Twitter のようなコメントですが、一番上に位置があります。実際に実装を開始するまでは、 SDB。

まず、SDB には属性値ごとに 1000 バイトの制限があり、これはコメントに対してさえ十分ではありません (おそらく、より長い値を複数の属性に分割する必要があります)。

そして、最大ドメインサイズは 10GB です。SDB はデータの負荷が増加しても劣化しないため、データベースのシャーディングなどを気にせずにスケールアップできるという約束でした。しかし、私が正しく理解していれば、ドメインではシャーディングとまったく同じ問題が発生します。ある時点で、アプリケーション レベルでドメイン全体にデータ レコードの分散とクエリを実装する必要があります。

アプリケーション全体で私が持っている最も単純なオブジェクトでも、つまり. アトミック ユーザー評価、SDB はオプションではありません。クエリ内で平均を計算できないためです (すべてが文字列ベースです)。したがって、オブジェクトの平均ユーザー評価を計算するには、すべてのレコード (一度に 250 件) をロードし、アプリケーション レベルで計算する必要があります。

SDB について何か不足していますか? 10GB は、SDB のすべての制限を克服するのに十分な量のデータベースですか? 私はすでに S3 と EC2 を使用しているので、SDB を利用することに正直に熱中していましたが、今ではユースケースが見当たりません。

4

9 に答える 9

35

いくつかの大規模なアプリケーションで SDB を使用しています。ドメインごとに 10 GB の制限があるのは気になりますが、Amazon でギャンブルをしているので、必要に応じてこれを延長できます。さらにスペースが必要な場合は、サイトにリクエストフォームがあります。

クロスドメイン結合に関しては、SDB を従来のデータベースと考えないでください。データを SDB に移行する際に、クロス ドメイン結合を手動で実行できるように、データの一部を非正規化する必要がありました。

属性ごとに 1000 バイトという制限も回避するのが困難でした。私が持っているアプリケーションの 1 つは、投稿とコメントをデータベースに保存するブログ サービスです。それを SDB に移植しているときに、この制限に遭遇しました。投稿とコメントをファイルとして S3 に保存し、それをコードで読み取りました。このサーバーは EC2 上にあるため、S3 へのトラフィックに追加料金はかかりません。

おそらく、注意すべきその他の問題の 1 つは、SDB の結果整合性モデルです。新しく書き込まれたデータが返されることを保証して、データを書き込んで読み戻すことはできません。いよいよデータ更新です。

以上のことから、私は今でも SDB が大好きです。乗り換えたことに後悔はありません。SQL 2005 サーバーから移行しました。私は SQL を使ってより多くのことを制御できたと思いますが、その制御を放棄すると、より柔軟になります。スキーマを事前に定義する必要がないのはすばらしいことです。コードに強力で堅牢なキャッシング レイヤーを使用すると、SDB をより柔軟にすることが容易になります。

于 2009-05-05T16:04:46.517 に答える
12

SimpleDB には約 50GB があり、30 のドメインに分割されています。これを使用して、S3 に格納されているオブジェクトに複数のキーを許可し、S3 のコストを削減しています。全文検索に SimpleDB を使用したことはありませんが、試すつもりはありません。

SimpleDB は機能し、簡単ですが、すべての状況に適した機能セットではありません。あなたの場合、集計が必要な場合、SimpleDB は適切なソリューションではありません。これは、DB は単なるキー バリュー ストアであり、結果をキー バリュー ストアに書き戻す集計プロセスによって集計を処理する必要があるという考え方に基づいて構築されています。これは、一部のアプリケーションで必要とされるものです。

これは、SimpleDB を使用してペニーをつまむ方法の説明です。

于 2009-06-27T08:08:50.360 に答える
7

ドメイン間で独自のシャーディング ロジックを記述しなければならないことは理想的ではありませんが、パフォーマンスの観点から言えば、追加する価値があります。たとえば、100 GB のデータ全体を検索する必要がある場合、1 台のマシンがタスク全体を実行するよりも、それぞれ 5 GB を保持する 20 台のマシンに、それぞれが担当する部分で同じ検索を実行するように依頼する方が適切です。最終的にソートされたリストを作成することが目標である場合は、20 の同時クエリから返された最良の結果を取得し、要求を開始したマシンでそれらを照合できます。

そうは言っても、これを通常の使用から抽象化して、より低レベルになりたい場合は、API に「ヒント」のようなものを入れたいと思います。したがって、たまたま 100 GB のデータを保存する場合、20 台のマシンまたは 10 台または 40 台のマシンにパーティション分割するかどうかを Amazon に決定させ、作業を分散させます。たとえば、Google の BigTable 設計では、テーブルが大きくなると、継続的に 400 MB のタブレットに分割されます。テーブルから行を要求するのはそれと同じくらい簡単です。BigTable は、1 台または数百万台のタブレットのどこに行が存在するかを把握する仕事をします。

繰り返しになりますが、BigTable ではクエリを実行するために MapReduce 呼び出しを記述する必要がありますが、SimpleDB 自体は動的にインデックスを作成するため、得られるものもあれば失うものもあります。

于 2011-01-07T00:08:51.120 に答える
5

属性ごとのストレージ サイズが問題である場合は、S3 を使用してより大きなデータを保存し、s3 オブジェクトへのリンクを SDB に保存できます。S3 は単なるファイルではなく、一般的なストレージ ソリューションです。

于 2009-03-15T18:26:53.417 に答える
5

Amazon は、単純なオブジェクト データベースを実装するように求めています。これは主に速度上の理由によるものです。SimpleDB レコードは、S3 の要素へのポインタ/キーであると考えてください。このようにして、クエリを実行できます (SimpleDB に対して低速で結果リストを取得するか、S3 をキーで直接ヒットして (高速)、レコードを 1 つずつ取得または変更する必要がある場合にオブジェクトをプルできます)。

于 2009-03-15T18:30:28.913 に答える
1

SimpleDB をプライマリ データ ストアとして使用する商用 .NET アプリケーションを構築しています。私はまだ実稼働していませんが、SimpleDB と RDBS を使用する際の問題のいくつかに対処するオープンソース ライブラリも構築しています。私のロードマップの機能のいくつかは、あなたが言及した問題に関連しています:

  • データの透過的な分割
  • 疑似トランザクション性
  • 1000 バイトの制限を超える属性の透過的なスパン

SimpleDB は現在も開発が活発に行われており、最終的には現在存在しない多くの機能 (コア システムに追加された機能やコード ライブラリに追加された機能) が確実に追加されることになります。

.NET ライブラリはSimple Savantです。

于 2009-05-30T18:38:32.707 に答える
1

私は SimpleDB に関するすべての誇大広告を購入しているわけではありません。次の制限に基づいて、SimpleDB を使用する理由がわかりません (現在、ほぼすべてのテクノロジを使用してほぼすべてのものを構築できることは理解していますが、これが 1 つを選択する理由ではありません)。 .

だから私が見た制限：

これで十分でない場合はgroup by、sum average、 、distinctデータ操作などの基本的なことも忘れる必要があります。全体として、クエリ言語はかなり初歩的であり、SQL で実行できることの小さなサブセットを思い起こさせます。

そのため、機能は Redis/Memcached よりも実際にはそれほど豊富ではありませんが、ユース ケースでこれら 2 つのデータベースと同じくらい優れたパフォーマンスを発揮するかどうかは非常に疑わしいです。

SimpleDB は、スキーマのないドキュメント ベースの nosql データベースとしての地位を確立していますが、MongoDB/CouchDB のクエリ構文はより表現力豊かであり、その制限はより合理的です。

そして最後に、ベンダーロックについて忘れないでください。数年以内に Azure (または今後登場する何か) が AWS の 5 分の 1 のコストでクラウド ホスティングを提供するようになるとしたら、切り替えるのは本当に難しいでしょう。

于 2015-09-23T09:27:16.090 に答える