1

今、私はこの質問と関係があるかもしれないこれらの質問を読みました:スケーラブルな画像ストレージ大規模な画像ストレージ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 データとそのメタ データを取得し、それをBLOBOracle データベースでは、これが機能する可能性があると感じています。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

4

4 に答える 4

1

画像をS3に保存することをお勧めします。経済的に強制されるまで、画像をローリングする必要はありません。BLOBがどのように格納されるかよりも、ユーザーが気にすることを心配する方がはるかに優れています。

Couchbase(私は共同創設者です)に関しては、同様のユースケースでそれを使用している人々がいます:通常、メタデータと画像の追跡(所有者、タイムスタンプ、タグ、基本的に保存またはクエリしたいものすべて)Couchbaseレコードその場合、S3に保存されている実際の画像へのURLが含まれるだけです。

于 2012-07-17T04:21:12.213 に答える
1

データベースについて

ファイルとはデータではなく、ファイル システムとはデータベースではありませんか? データベースのレコード、ファイル システムのファイル、KV ストアのキーと値 - これらはすべて同じツリーの果実です。

プレーン ファイル システムは、ファイルをローカルに配信する目的で数十年にわたって開発されてきました。その上で、配布モデルを構築できます。

HDFS のようなものには、ファイル システム自体の一部としてディストリビューションが含まれますが、ファイルをローカルで操作しようとすると不要なオーバーヘッドが発生します。

リレーショナル データベースや KV ストアのようなものは、ダイアグラムをレイアウトしたり、より多くのメタデータを簡単に保存したりするのに役立つかもしれませんが、ファイル ストレージ システムとして機能するように特別に設計されていない限り、失敗するでしょう。

ストレージ システムの選択はトレードオフがすべてであり、問​​題に対する最善の解決策を見つけるのはあなた次第です。そして、あなたの問題は Facebook の問題にさえ近くない可能性があります。それらの上にcdnを備えたサーバーはほとんどなく、問題ありません。

ファイル形式について

  1. SVG は通常の画像では機能しません。夢にも思わないでください。
  2. 大規模な場合、ファイルを受け入れるときに最小限の変換を実行する必要があります。要件に合わない場合は、画像を再スケーリング/圧縮/トリミングして保存します。これらの画像に何らかの魔法をかけている場合を除き、それらを別の形式に変換したり、実際に必要とせずに圧縮したりしたくはありません。
  3. 大規模にファイルを作成する場合 (優先度順):
    • クライアントのキャッシュから提供される
    • OSキャッシュ/メモリから提供
    • ファイルシステムから直接提供
于 2012-07-16T16:25:19.950 に答える
1

まず、画像ファイル形式についてのあなたの理解は、多くの詳細を提供していないため、ナイーブである可能性があることに言及したいと思います。PNG画像を「SVG形式として」(たとえば)どのように保存するつもりですか?

すべての質問にお答えすることはできませんが、できる限りお答えします。

  1. 「ファイル システムまたは SVG」は誤った二分法です。データベースに JPG BLOB を格納したり、ファイル システム ストレージに SVG ファイルを格納したりすることは簡単に可能です。任意のビットマップ イメージ形式もテキストとして処理できます。例が必要な場合は、ビットマップ データが埋め込まれた PostScript ファイルを開いてみてください。「なぜ」というあなたの質問は、2つが交換可能であることを意味しますが、通常はそうではありません。例として、私の会社ではドキュメントの保存用にさまざまなファイル形式を評価してきましたが、状況に応じて PDF (身震い) と PS を使用しました。SVG を使用しなかった理由は 2 つあります。まず、複数ページのドキュメントは公式の標準に含まれていますが、SVG エディターとビューアーはそれらをサポートしていないようです。第 2 に、SVG は自動化された方法で印刷されるときにいくつかの複雑さを示します (実証するために、この実験を試してください: SVG ファイルと同等の PostScript ファイルを作成し、次に を使用して両方を印刷してみてくださいlp)。

  2. すでに 2 つ挙げました (ただし、Web アプリを扱っている場合、クライアントはおそらくブラウザーのレンダリング エンジンを使用しており、複数のページは必要ない可能性があるため、どちらも問題ありません)。他の唯一のものはブラウザーのサポートです。これは、いつものように、古いエディションの IE では途切れ途切れです。フォントの状況にも注意する必要があります。ファンシーなタイポグラフィがパスとして扱われることを確認するか、視聴者がアクセスできることがわかっているフォントのみを使用するようにしてください (Web アプリの場合、CSS3 が少し役立ちます)。

  3. SVG やその他のベクトル/手続き型表現は小さくなる傾向があるため、サーバーでの処理が容易になると私は言いがちです。これはテストに基づいたものではないので、参考程度に考えてください。クライアント側でより多くのリソースを消費する傾向がありますが、Web の状況ではそれほど大きな問題ではないことに注意してください。

  4. 画像を SVG として表現できる場合、はい、非常に良い考えです。ただし、任意のビットマップをベクトル表現に変換することは、私の知る限り未解決の問題です。手動でもうまく変換できないものもあれば、実際には JPG よりも SVG で表現した方がサイズが大きくなるものもあります。ビジネス文書、フローチャート、タイポグラフィなどの場合は、ベクトルの方が絶対に優れています (上記のフォントの問題を除けば)。特定の種類のイラストはベクターの方が適していますが、ラスターの方が適しているものもあります。最後に、ビットマップ (写真など) から開始する場合、SVG への変換は品質が著しく低下するか、手作業で多くの時間がかかります (うまく処理できたとしても)。

  5. これは、あなたが目指していると思われる規模で何かを構築したことがないため、私が本当に答えることができないものです.

于 2012-07-16T13:18:52.040 に答える
0

「SVG は通常の画像では機能しません。夢にも思わないでください。」

「しかし、任意のビットマップをベクトル表現に変換することは、私の知る限り、未解決の問題です。手動でもうまく変換できないものもあれば、JPG よりも SVG として表現した方が実際にはサイズが大きくなるものもあります。」

私は、これらの記述は両方とも間違っていると思います。

https://sites.google.com/site/jcdsvg/svg_paradoxes.svg

例 3 と 4 を参照してください。猫の画像は中解像度の png ファイルとして保存されるため、画像を高解像度でズームできます。通常の Web 画像よりファイル サイズが大きくなっていますが、これは意図的なものです。

ビットマップ イメージを SVG として保存するのは、それらを SVG コンテナーに入れるのと同じくらい簡単です。

于 2012-07-25T00:21:17.960 に答える