スケーラブルな画像ストレージ
現在、何らかの画像ストレージも提供するWebベースのアプリケーションのアーキテクチャを設計しています。ユーザーは、サービスの主要な機能の1つとして写真をアップロードできます。また、これらの画像の表示は、主な用途の1つです（Web経由）。
ただし、アプリケーションでこのようなスケーラブルな画像ストレージコンポーネントを実現する方法がわかりません。私はすでにさまざまな解決策について考えましたが、経験が不足しているため、あなたの提案を聞くのを楽しみにしています。画像とは別に、メタデータも保存する必要があります。私の最初の考えは次のとおりです。
HDFSなどの（分散）ファイルシステムを使用し、アップロードされた画像とサービスリクエストを保存するために、専用のWebサーバーを「ファイルシステムクライアント」として準備します。画像のメタデータは、各画像のファイルパス情報を含む追加のデータベースに保存されます。
HDBaseの上にHBaseのようなBigTable指向のシステムを使用し、画像とメタデータを一緒に保存します。繰り返しますが、ウェブサーバーは画像のアップロードとリクエストをブリッジします。
CouchDBのような完全にスキーマレスのデータベースを使用して、画像とメタデータの両方を保存します。さらに、HTTPベースのRESTful APIを使用して、データベース自体をアップロードおよび解放に使用します。 （追加の質問：CouchDBはBase64経由でBLOBを保存します。ただし、image/jpegなどの形式でデータを返すことはできますか？）
そのためにCouchDBを使用しており、画像を「添付ファイル」として保存しています。しかし、1年後、数十GBのCouchDBデータベースファイルが頭痛の種になりました。たとえば、非常に大きなドキュメントサイズでCouchDBレプリケーションを使用すると、依然として問題が発生します。
そのため、画像情報にCouchDBを使用し、実際の画像ストレージにAmazon S3を使用するようにソフトウェアを書き直しました。コードは http://github.com/hudora/huImages で入手できます。
プロジェクトのオンサイトでAmazon S3互換のストレージサービスをセットアップすることもできます。これにより、柔軟性が保たれ、現時点では外部サービスを必要とせずにAmazonオプションを使用できます。 Walruss は、最も人気がありスケーラブルなS3クローンになりそうです。
また、優れたオープンソース MogileFS および Perlbal の提供物を備えたLivejournalの設計を検討することをお勧めします。 この組み合わせ は、おそらく最も有名な画像提供設定です。
flickr Architecture もインスピレーションになりますが、Livejournalのようにオープンソースソフトウェアを一般に公開していません。
「追加の質問：CouchDBはBase64経由でBLOBを保存します。」
CouchDBはnotブロブをBase64として保存し、ストレートバイナリとして保存します。 ?attachments=trueを使用してJSONドキュメントを取得する場合、JSONに安全に追加するためにオンディスクバイナリをBase64に変換しますが、これは単なるプレゼンテーションレベルのものです。
Standalone Attachments を参照してください。
CouchDBは、保存されているコンテンツタイプの添付ファイルを提供しますが、実際には、HTML、CSS、およびGIF/PNG/JPEG添付ファイルをブラウザに直接サーバーすることが可能です。
添付ファイルをストリーミングすることができ、CouchDB 1.1ではRangeヘッダーもサポートします（メディアストリーミングおよび/または中断したダウンロードの再開用）。
Facebookのhaystack論文の実装である Seaweed-FS （かつてはWeed-FSと呼ばれていました）を使用します。
Seaweed-FSは非常に柔軟であり、基本にまで縮小されています。何十億もの画像を保存し、高速に提供するために作成されました。
Facebook hayStackの説明をご覧ください
MogileFSを使用します。私たちは小規模なユーザーであり、8TB未満で約5,000万個のファイルがあります。ファイル名とパフォーマンスをより適切に制御するために、数年前にAmazon S3での保存から切り替えました。
それは最もきれいなソフトウェアではありませんが、それは非常に「フィールドテスト済み」であり、基本的にすべてのユーザーがあなたと同じようにそれを使用しています。
Amazon Webサービスを検討しましたか？ S3はWebベースのファイルストレージであり、SimpleDBはキー->属性ストアです。どちらもパフォーマンスが高く、スケーラブルです。独自のサーバーとセットアップを維持するよりも費用がかかります（人を雇わずに自分でやろうとしていると仮定します）が、すぐに立ち上げて実行できます。
編集：私はそれを取り戻します-大容量で長期的にはより高価ですが、低容量ではハードウェアを購入する初期コストを上回ります。
S3： http://aws.Amazon.com/s3/ （ここに画像ファイルを保存できます。パフォーマンスのために、サーバーに画像キャッシュがある場合とない場合があります）
SimpleDB： http://aws.Amazon.com/simpledb/ （メタデータはここに行くことができます：保存したいデータへのイメージIDマッピング）
編集2：これについては知りませんでしたが、Amazon CloudFront（ http://aws.Amazon.com/cloudfront/ ）という新しいウェブサービスがあります。これはWebコンテンツの高速配信用であり、S3とうまく統合されます。あなたの画像にはアカマイのようなものがあります。画像キャッシュの代わりにこれを使用できます。
Cloudantの一部として、私は製品をプッシュしたくありません...しかし、BigCouchは私の科学アプリケーションスタックでこの問題を解決します（物理学-Cloudantとは何の関係もなく、確かに利益とは何の関係もありません！）。 CocuhDBの設計のシンプルさと、単一サーバーのCouchDBにはない自動シャーディングとスケーラビリティを組み合わせています。私は通常、少数の大きなファイル（マルチGB）と多数の小さなファイル（100 MB以下）を格納するために使用します。私はS3を使用していましたが、繰り返しアクセスされる小さなファイルの取得コストが実際に増え始めます。
OK、AWSのすべてが機能しない場合、ここにいくつかの考えがあります。
（3）に関しては、データベースにバイナリデータを格納すると、同じデータが出力されます。データベースをjpegにするのはデータの形式であり、データベースが考えるものではありません。クライアント（Webブラウザー）がjpegであると考えるのは、Content-typeヘッダーからimage/jpeg。また、テキストのような他のもの（推奨されません）に設定することもできます。それはブラウザがそれを解釈しようとする方法です。
オンディスクストレージの場合、CouchDBのシンプルさが気に入っていますが、HDFSは確かに機能します。 CouchDBからの画像コンテンツの提供に関する投稿へのリンクは次のとおりです。 http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html
編集：ここでは、memcachedでの画像のキャッシュとLinux/Apacheでのディスクからの画像の提供に関する有用な議論へのリンクがあります。
私はPythonビューサーバーでCouchDBビューサーバーで利用可能な_update機能のいくつかを試してきました。
私が行った本当にすばらしいことの1つは、PILを使用してサムネイルやその他の関連画像を作成し、それらがCouchDBにプッシュされたときにドキュメントに添付できるようにする画像アップロードの更新機能でした。
これは、画像の操作が必要で、維持する必要があるコードとインフラストラクチャの量を削減したい場合に役立ちます。
cassandraの上にイメージストアを作成しました。書き込みが多く、ランダム読み取り読み取り/書き込みが低いです。読み取り/書き込み比率が高い場合は、mongodb（GridFs）をお勧めします。