Amazon SimpleDBを使用する意味は何ですか？
SimpleDBを使用して、アプリケーションの最も困難な領域（スケーリングに関しては）を処理できると思いました-Twitterのようなコメントですが、場所が一番上にあります-座って実際に実装を開始するまでSDB。
まず、SDBには属性値ごとに1000バイトの制限があり、コメントに対しても十分ではありません（おそらく、より長い値を複数の属性に分割する必要があります）。
その場合、最大ドメインサイズは10GBです。 SDBはデータの負荷が増えても劣化しないため、データベースのシャーディングなどを気にせずにスケールアップできることが約束されていました。しかし、正しく理解していれば、ドメインではシャーディングとまったく同じ問題が発生します。ある時点で、アプリケーションレベルでドメイン間でデータレコードの配布とクエリを実装する必要があります。
アプリケーション全体で私が持っている最も単純なオブジェクトでも、つまり。アトミックユーザー評価、SDBはクエリ内の平均を計算できないため、オプションではありません（すべてが文字列ベースです）。したがって、オブジェクトの平均ユーザー評価を計算するには、すべてのレコード（一度に250）をロードして、アプリケーションレベルで計算する必要があります。
SDBについて何かが足りませんか？ 10GBは、SDBのすべての制限を克服するのに本当に多くのデータベースですか？私はすでにS3とEC2を使用しているので、SDBを利用することに正直に熱心でしたが、今ではユースケースが見当たらないだけです。
私はいくつかの大規模なアプリケーションでSDBを使用しています。ドメインあたり10GBの制限は私を心配させますが、私たちはAmazonでギャンブルをしており、必要に応じてこれを拡張できるようにしています。より多くのスペースが必要な場合は、サイトにリクエストフォームがあります。
クロスドメイン結合に関しては、SDBを従来のデータベースとは考えないでください。データをSDBに移行する際に、クロスドメイン結合を手動で実行できるように、データの一部を非正規化する必要がありました。
属性あたり1000バイトの制限も回避するのが困難でした。私が持っているアプリケーションの1つは、投稿やコメントをデータベースに保存するブログサービスです。 SDBに移植しているときに、この制限に遭遇しました。最終的に投稿とコメントをファイルとしてS3に保存し、それをコードで読み取りました。このサーバーはEC2上にあるため、S3へのトラフィックに余分なコストはかかりません。
おそらく、注意すべき他の問題の1つは、SDBの結果整合性モデルです。データを書き込んでから、新しく書き込んだデータが返されることを保証して、データを読み戻すことはできません。最終的に、データは更新されます。
とはいえ、私はまだSDBが大好きです。切り替えたことを後悔していません。 SQL2005サーバーから移動しました。 SQLの方がはるかに制御できたと思いますが、その制御を放棄すると、柔軟性が高まります。スキーマを事前に定義する必要がないのは素晴らしいことです。コードに強力で堅牢なキャッシングレイヤーがあれば、SDBをより柔軟にするのは簡単です。
SimpleDBには約50GBがあり、30のドメインに分割されています。これを使用して、S3に保存されているオブジェクトに複数のキーを許可し、S3のコストを削減します。 SimpleDBをフルテキスト検索に使用したことはありませんが、試しません。
SimpleDBは機能し、簡単であるなどですが、すべての状況に適した機能のセットではありません。あなたの場合、集約が必要な場合、SimpleDBは適切なソリューションではありません。 DBは単なるキー値ストアであり、集計は結果をキー値ストアに書き戻す集計プロセスによって処理される必要があるという考え方に基づいて構築されています。これはまさに必要なものです一部のアプリケーションでは
ドメイン間で独自のシャーディングロジックを作成することは理想的ではありませんが、パフォーマンスの観点からは理想的ではないことを付け加える価値があります。たとえば、100 GBのデータを検索する必要がある場合は、1台のマシンでタスク全体を実行するのではなく、それぞれ5GBを保持する20台のマシンに担当部分で同じ検索を実行するように依頼することをお勧めします。最終的にソートされたリストを作成することが目標である場合は、20の同時クエリから返された最良の結果を取得し、リクエストを開始するマシンでそれらを照合できます。
そうは言っても、これを通常の使用から抽象化して、低レベルにしたい場合はAPIに「ヒント」のようなものを入れたいと思います。したがって、100 GBのデータを保存する場合は、Amazonに20台のマシンに分割するか10台または40台のマシンに分割するかを決定させ、作業を分散させます。たとえば、GoogleのBigTableデザインでは、テーブルが大きくなるにつれて、400MBのタブレットに継続的に分割されます。テーブルから行を要求するのはそれと同じくらい簡単で、BigTableは1つのタブレットまたは数百万のタブレットのどこにあるかを把握する役割を果たします。
繰り返しになりますが、BigTableではクエリを実行するためにMapReduce呼び出しを作成する必要がありますが、SimpleDBはそれ自体に動的にインデックスを付けるため、勝ち、負けます。
属性ごとのストレージサイズが問題になる場合は、S3を使用してより大きなデータを保存し、s3オブジェクトへのリンクをSDBに保存できます。 S3はファイル専用ではなく、一般的なストレージソリューションです。
Amazonは、単純なオブジェクトデータベースを実装させようとしています。これは主に速度上の理由によるものです。 SimpleDBレコードは、S3の要素へのポインター/キーであると考えてください。このようにして、クエリを実行できます（SimpleDBに対して低速で結果リストを取得するか、レコードを一度に1つずつ取得または変更する必要がある場合は、キー（高速）でS3を直接押してオブジェクトをプルできます。
制限は現在のベータリリースに適用されるようです。経済的に需要に対応する方法を見つけた後、将来的にはより大きなデータベースが可能になると思います。制限がある場合でも、高いスケーラビリティと信頼性をサポートする10GBのデータベースは、有用で費用効果の高いリソースです。
スケーラビリティとは、データの量または要求の量が増加する間、安定した浅いパフォーマンス曲線を維持する機能を指すことに注意してください。これは必ずしも最適なパフォーマンスを意味するわけではなく、非常に大容量のデータストレージを意味するわけでもありません。
Amazon SimpleDBは無料のサービス階層も提供しているため、最大25時間のマシン時間を使用して、最大1GBを保存し、最大1GB /月を転送できます。この制限は非常に低いように聞こえますが、無料であるという事実により、一部の小規模な顧客は、大規模なサーバーファームに投資することなくテクノロジーを使用できます。
SimpleDBをプライマリデータストアとして使用する商用の.NETアプリケーションを構築しています。私はまだ本番環境ではありませんが、SimpleDBとRDBSの使用に関するいくつかの問題に対処するオープンソースライブラリも構築しています。私のロードマップの機能のいくつかは、あなたが言及した問題に関連しています。
- データの透過的なパーティション化
- 疑似トランザクション性
- 1000バイトの制限を超える属性の透過的なスパン
SimpleDBはまだ活発に開発中であり、確かに今日は持っていない多くの機能を備えています（コアシステムに追加されたものとコードライブラリに追加されたものがあります）。
.NETライブラリは Simple Savant です。
SimpleDBに関する誇大広告をすべて購入しているわけではなく、次の制限に基づいて、SimpleDBを使用する理由がわかりません（今ではほとんどすべてのテクノロジーでほぼすべてを構築できることを理解していますが、これが1つを選択する理由ではありません） 。
だから私が見た制限：
- アマゾンAWSでのみ実行できます。また、 スタッフ全員に支払う
- ドメイン（テーブル）の最大サイズは10 GB
- 属性値の長さ（フィールドのサイズ）は1024バイトです
- 選択した応答の最大アイテム-2500
- selectの最大応答サイズ（返されるデータの最大量）-1Mb、実際にはすべてを確認できます ここでの制限
- いくつかの言語 （Java、php、python、Ruby、.net）専用のドライバーがあります
- 大文字と小文字を区別しない検索は許可されません。追加の小文字のフィールド/アプリケーションロジックを導入する必要があります。
- 並べ替えは 1つのフィールドで のみ実行できます
- 5秒の制限時間のため カウントインは奇妙に振る舞う可能性があります 。 5秒が経過してもクエリが終了しない場合は、クエリを続行できるようにする部分的な番号とトークンが表示されます。アプリケーションロジックは、このすべてのデータをまとめて収集する責任があります。
- すべてがUTF-8文字列です これにより、文字列以外の値（数値、日付など）を操作するのが面倒になります。
- 並べ替えは、数値に対して奇妙な動作をします（すべてが文字列であるため）。だから今あなたは パディング付きのシャーマニックダンス をしなければなりません
- どちらにもトランザクションと結合はありません
- 複合、地理静的、複数列インデックス、外部キーなし
これだけでは不十分な場合は、group by、sumaverage、distinctなどの基本的なことやデータ操作についても忘れる必要があります。全体として、クエリ言語はかなり初歩的なものであり、SQLで実行できることの小さなサブセットを思い出させます。
そのため、機能はRedis/Memcachedよりもそれほど豊富ではありませんが、ユースケースでこれら2つのデータベースと同じくらい優れたパフォーマンスを発揮するかどうかは非常に疑わしいです。
SimpleDBは、それ自体をスキーマのないドキュメントベースのnosqlデータベースとして位置付けていますが、MongoDB/CounchDBのクエリ構文ははるかに表現力があり、その制限ははるかに合理的です。
そして最後に-忘れないでください ベンダーロックイン 。数年以内にAzure（または表示される他の何か）がAWSの5倍安いクラウドホスティングを提供する場合、切り替えるのは非常に困難です。