私はモバイル アプリケーション (iPhone/Android) を構築中で、アプリケーション データを Amazon の SimpleDB に保存したいと考えています。これらのサービスを提供するために独自のサーバーをホストしたくないからです。すべてのドキュメントを確認しましたが、要素値の最大ストレージ サイズは 1024 バイトです。
私の場合、1024 から 10K までのテキスト データを保存する必要があります。
私たちのプロジェクトのように大きなストレージが必要な場合に、他のプロジェクトが SimpleDB をどのように使用しているかを知りたいと思っていました。S3（ファイルシステム）に保存されるファイルへのポインターを保存できることを読みました。それが良い解決策かどうかはわかりません。
私の考えでは、SimpleDB が正しい解決策であるかどうかはわかりません。それが何をしたか、またはこの問題について考える別の方法を提供することについて誰かコメントできますか?
10kのテキストデータを保存する方法はいくつかありますが、それが受け入れられるかどうかは、他に何を保存する必要があるか、およびそれをどのように使用するかによって異なります。
任意の大きなデータ（特にバイナリデータ）を保存する必要がある場合は、S3ファイルポインターが魅力的です。SimpleDBがこのシナリオで追加する価値は、SimpleDBに保存しているファイルメタデータに対してクエリを実行する機能です。
10kに制限されたテキストデータの場合、SimpleDBに直接保存することをお勧めします。1つのアイテムに簡単に収まりますが、複数の属性に分散させる必要があります。これを行うには、基本的に2つの方法があり、それぞれにいくつかの欠点があります。
1つの方法は、より柔軟で検索しやすい方法ですが、データに触れる必要があります。データを約1000バイトのチャンクに分割し、各チャンクを属性値として複数値属性に格納します。複数値の属性には順序付けが課されていないため、順序付けのために各チャンクの前に番号を付ける必要があります（例：01）
すべてのテキストが1つの属性に格納されているという事実により、述語内の1つの属性名でクエリを簡単に実行できます。1kから200+kまでの任意の場所で各アイテムに異なるサイズのテキストを追加でき、適切に処理されます。ただし、先頭に追加された行番号がクエリに対して正の値になる可能性があることに注意する必要があります（たとえば、01すべてのアイテムを検索している場合は、そのクエリに一致します）。
SimpleDB内にテキストを保存する2番目の方法では、テキストチャンク内に任意の順序データを配置する必要はありません。各テキストチャンクを異なる名前の属性に配置することにより、順序付けを行います。たとえば、属性名を使用できます：desc01 desc02...。desc10次に、各チャンクを適切な属性に配置します。両方の方法で全文検索を実行することはできますが、多くの述語を指定する必要があり、SimpleDBが属性ごとに個別のインデックスを検索することになるため、この方法では検索が遅くなります。
このタイプの回避策は、データベース内でこのタイプの低レベルの詳細を処理することに慣れているため、ハックと考えるのは簡単かもしれません。SimpleDBは、ファーストクラスの機能として可用性を提供する手段として、この種のものをデータベースからクライアントにプッシュするように特別に設計されています。
リレーショナルデータベースがテキストを1,000個のチャンクに分割して、実装の詳細としてディスクに保存していることがわかった場合、それはハックのようには見えません。問題は、SimpleDBクライアントの現在の状態では、このタイプのデータフォーマットを自分で多く実装する必要があるということです。これは、スマートクライアントで理想的に処理されるタイプのものです。まだ無料で利用できるスマートクライアントはありません。
10kのテキストをS3に配置してから、10kのテキストのすべての一意の単語を複数の値として持つ属性を作成できます。そうすれば、検索は高速になります。ただし、フレーズ検索はありません。
1つの「行」（名前）の1つの属性にいくつの値を格納できますか？ドキュメントを調べましたが、答えが返ってきませんでした。
-トム
コストが心配な場合は、S3にテキストを配置し、SimpleDBにポインターを使用してメタデータを配置する方が安価であることがわかる場合があります。
SimpleDb は、まあ、単純です。その中のすべてが文字列です。ドキュメントは非常に簡単です。そして利用制限が多い。そのような：
SELECT * FROM ___ WHERE ItemName() IN (...)で実行できるのは 20ItemName秒のみですIN。PUT(更新) できません。SELECTなもの(または何も返さないこともある) が返される可能性があります。これは、次が実際に制限カウントを返す可能性があることを意味するため、2 つの から返される行の合計は、元の制限よりも大きくなる可能性があります。たくさん選んでいる場合、これは懸念事項です。また、 aを行うと、同様の問題が発生します。とともに、カウントが返されます。そして、これらの s を繰り返し処理し、返されたカウントを合計して、真の (合計) カウントを取得する必要があります。LIMIT1000800nextTokennextTokenSELECTSELECTSELECT COUNT(*)nextTokennextTokenしたがって、大量の文字列データを使用する予定がある場合、または大量のレコードを使用する予定がある場合は、他の場所を探すことをお勧めします。SimpleDb は非常に信頼性が高く、ドキュメントどおりに動作しますが、多くの頭痛の種になる可能性があります。
あなたの場合、MongoDbのようなものをお勧めします。独自の問題もありますが、この場合はより良いかもしれません。ただし、多数のレコード (数百万以上) があり、あまりにも多くのレコードにインデックスを追加しようとすると、それが SSD ではなくスピンデル上にある場合、それが壊れる可能性があります。
Simple Savant (私が作成した SimpleDB 用の C# 永続化ライブラリ)の今後のリリースでは、Mocky によって記述された属性スパンと、Lucene.NET を使用した SimpleDB データの全文検索の両方がサポートされます。
おそらく C# でアプリを構築していないことは承知していますが、SimpleDB とフルテキスト インデックスを検索すると、あなたの質問が上位に表示されるので、言及する価値があると思われます。
更新: 上記の Simple Savant リリースが利用可能になりました。