今、私はこの質問と関係があるかもしれないこれらの質問を読みました:スケーラブルな画像ストレージ、大規模な画像ストレージ、https://serverfault.com/q/95444 .
質問する前に、私が見つけた次のこと:
1. Facebook は、非常に効率的なHaystack (オープンソースの世界に対するクローズド ソースのようなもの)を使用しています。これは、速度と大規模なメタデータ管理
のために設計されたファイル システム ストレージの形式です。2. どのオペレーティング システムにもディレクトリ内のファイル制限があり、この制限を超えるとパフォーマンスが極端に低下することがあります。3. ほとんどの NoSQL 開発者は、ドキュメント (データベース内のレコード) に貼り付けられた添付ファイルとして画像を処理するため、 CouchDB / CouchBase Serverを使用して画像を処理するのが簡単であることに気付きました。ただし、これはファイル システム ストレージです。4. HDFS、NFS、ZFS はすべてファイル システムであり、大規模なファイルを簡単に処理できる可能性があります。
分散データ。ただし、Facebook のようなアプリケーションでは、それらは役に立ちませんでした5. 適切な形式のキャッシュは、画像に大きく依存するアプリケーション
にとって非常に重要です 6. 一部の PHP 開発者 (ほとんど) は、MySQL を使用して、フォルダーとサブフォルダーを作成しながら画像のメタデータを保持しています。 (メタ情報に一致する) ファイル システム上。各イメージには、データベース内のメタデータに関連するランダムなハッシュ名が付けられ、ファイル システム上の高速な場所を有効にします。
これらのステートメントと他の多くのステートメントを理解した後、私は、ファイルシステム上で絶え間なく増加する数十億のイメージを保持するのは非常にコストがかかることに気づきました。のようなクラウド ストレージを使用するAmazon S3
と、アプリケーションからのストレージだけでなく、画像のトラフィックが増えるため、ビジネスが台無しになります。画像を添付ファイルとして管理するCouchBase Server
の使用を評価しました。ただし、画像を成長させるアプリケーションの場合、これはファイル システム ストレージでもあり、何百、何千人もの人々が同時に画像にアクセスしている場合、Couch ベースはどのように動作するのだろうかと思います。Cloudant/Big Couchを使用できます自動シャーディング/負荷分散があります。重要なポイントは、NoSQL ソリューションはファイル システムにイメージを保持することであり、イメージが高い同時レートで要求されると、サービス全体がダウンする可能性があるということです (イメージは重い可能性があります)。
私の考え
私は自分の画像を次のように管理しようと考えていますSVG
フォーマット。これは、この SVG データをストレージ内のテキストとして扱うことができると考えているためです。現在、ほとんどの NoSQL データベースでは、ドキュメント (レコード) のサイズに少なくとも 4MB 以下のサイズ制限があります (不明)。画像によっては SVG ファイルが 6 ~ 10 MB に達することもあるため、これは問題を引き起こします。したがって、SVG ストレージに Couch ベース サーバーを使用することはできないと思います。さらに、アプリケーションの性質上、画像データは成長し続け、アーカイブされたり削除されたりすることはありません。ソファーベースはそのようなデータ (非常に永続的で不変のデータ) には適していません。
これにより、優れたテキスト圧縮で知られる RDBMS (特に Oracle) に戻ります。SVG データとそのメタ データを取得し、それをBLOB
Oracle データベースでは、これが機能する可能性があると感じています。Oracle テーブルは、おそらくパーティショニングまたは何らかの断片化により、テラバイトにまで拡大する可能性があると聞いたことがあります。しかし要点は、Oracle テーブルがテキストを含む 20GB に達するためには、これは大量のデータになると思うということです。
ここで、上記のすべての調査結果から疑問が生じ
ます。 1. なぜ開発者は SVG ではなくファイル システム ストレージを選択し続けるのでしょうか。私の (おそらく素朴な) 考えでは、SVG はテキストとして処理できるため、圧縮できるからです。 、暗号化、消化、分割、簡単に保存など?
2. アプリケーションが画像を完全に SVG として処理し、実際の画像ファイルではなくブラウザに SVG を提供する場合、どのような複雑さがありますか?
3. 技術的には、どちらが Web サーバーにとってより多くのメモリを乱すか: ファイル システム (.png、.jpg、.gif) から読み取った画像を提供し、(おそらくデータベースまたは中間層から) SVG として画像を提供する (特に負荷が高い場合)。 Facebookのシナリオ例?
4. SVG は、異なる「ズーム」または解像度でレンダリングしても品質が低下しないように見えますが、開発者が画像動的アプリケーションで SVG をあまり使用していないのはなぜですか? つまり、PNG、JPG、または GIF からSVG
.
5. 非常に永続的なメタデータと永続的な SVG データを格納するために、Oracle/MySQL Cluster のような RDBMS を使用するという私の見解は非常に単純ですか?
大きな画像の保存形式について強調表示し、提案をしてください。ありがとう
編集/更新
画像を操作するためのコマンド ライン オプションを提供するImage Magick
のようなツールがあります。おそらく私が必要とする最も重要なアイデアは次のとおりsingle server
ですversion 2.0
。