Azureストレージ入門：Blobs対Tables対SQL Azure
これはかなりのトピックですブロブvsテーブルvs SQL、そしてこれまで読んだすべてのことにもかかわらず、何をいつ使うべきかについての適切な推論がまだ見つかりません。
マルチテナントSaaS WebアプリケーションをAzureに移行しようとしています。SQLServer 2008データベースを使用しています。ドキュメントを保存し、ドキュメントに属する情報をログに記録しています。ドロップボックスはありません。
フォーラムでは、「大きな」オブジェクトを検討する場合は、Azure Tablesをより適切に使用すると述べています。通常、ユーザーごとに数百のドキュメントを保存します。ドキュメントのサイズは5kbから30mbまでさまざまで、大部分は約1MBです。
Blob、Table、Sqlを使用する際の基本的なルールはありますか？文書は高すぎるため、SQLに保存しないでください。しかし、ドキュメントをBLOBに格納することが「有益」になるのはいつですか。いつテーブルを使用するとよいでしょうか。次のような式はありますか？
if (objects * MB/object * objectrequested > y) then blobs, else tables
IgorekはSQL Azureの懸念事項に対処したと思います。ただし、テーブルとブロブについてはまだ質問があるようです。
あなたの場合、テーブルストレージを使用するのは面倒です。 ATSの各プロパティ/列は最大64KBになる可能性があるため、ドキュメントを複数のプロパティに分割してから再構築する必要があります。エンティティごとに4MBの制限もあり、これは問題になります。 Blobストレージには、これらの制限はありません。
個別に格納してクエリを実行する必要がある多くのプロパティを持つ小さめのエンティティがある場合は、Azure Table Storageを使用する傾向があります。そのため、保存されたオブジェクト、または大量のメタデータを含む小さなドキュメントに適しています。
Blobストレージは、大量のメタデータがない場合に適しています。ファイルシステム上のファイルとしてうまく機能するかもしれないものに適しています。
ドキュメント自体を（テーブルストレージではなく）Azure Blobストレージに格納します。 1 MBあたり1ペニー（またはボリュームによってはそれ以下）を請求するSQL Azureデータベースにドキュメントを保存するのはかなり高価であるという事実を除けば、SQLデータベースは通常、ドキュメントに適した場所ではありません。 SQLはリレーショナルデータベースであり、クエリや結合などの機能を提供します。特に、大容量のドキュメントや画像をSQLデータベースに保存しても、特に拡張性が高く、非常に安価に保存できる中央ストレージシステムがある場合、メリットはありません。 /アクセス。
ここで、ドキュメント自体を検索する必要がある場合は、Lucene.NETのようなものを使用して、ドキュメントベースのリポジトリの検索機能を提供します。
HTH