数億枚の画像用のストレージを準備する必要があります (現在、7,000 万枚あり、この数は増え続けています)。各画像には約があります。20kB。もちろん、それらをファイルシステムに保存することはできますが、inode の数が心配です。MongoDB と Cassandra をテストしました。どちらにも欠点があります (HDD リソースが限られています)。
誰でもこの種の問題の適切な解決策を提案できますか?
私はこれまで、S3 (Rackspace クラウドファイルを含む) と MongoDB の両方で動画配信を行ってきました。
ほとんどの人は、一瞥もせずに S3 を選びますが、どちらにも欠点があることがわかりました。大きな問題の 1 つは、S3 が CDN ではないことです。実際には、他の S3 リージョンにレプリケートされない特定のリージョン内の冗長ストレージです。つまり、S3 の上にあるクラウドフロントのようなものを使用してイメージに ping を実行する必要があります。サイトに深刻な負荷がかかる場合は、一種のキャッシュに。
S3 には、CDN らしくなく、ストレージ ウェアハウスのような他の機能もあります。そうは言っても、アクセス頻度の低いファイルの場合、S3 は非常に高速です。
もちろん、この二重層はメンテナンスなどの複雑さを生み出します。それだけでなく、CDN は TTL で機能します。現在、多くの CDN がエッジ パージ機能を備えていますが、ファイルにアクセスできないようにする 100% 確実な方法ではありません。
したがって、セットアップとアクセス (削除する必要のあるファイルへのアクセスの可能性) により、これは非常に迅速にコストがかかる可能性があります。
これは、MongoDBが勝つ可能性がある場所です。シナリオによっては、MongoDB の方が実際にはここで安くなる可能性があります。これは、AWS で大量のマイクロ インスタンスを使用して実際に情報を保持し、これらのインスタンスにスポット インスタンスの予約を追加し (非常に安価)、必要なものをすべて追加できるためです。単一のマシン上の大きなディスクです。
地獄、S3 を使用してイメージを保存し、MongoDB をクラウドフロントの代替として使用することもできます。
異なるリージョンにイメージを ping する場合は、そのターゲット リージョンでいくつかのスポット インスタンスを作成し、MongoDB にそのデータをレプリケートさせるだけです。そのリージョンから頻繁にアクセスされるファイルのみがそのリージョンに配置されるようにするために、レプリケーションでもいくつかのクールなことを行うことができます。
したがって、私は MongoDB (または Cassandra でさえ) を捨てることはせず、むしろ 2 つの間の手段テストを行います。
S3 の価格設定に関する追加の注意事項として、ファイルを RR (Reduced Redundancy) に保存すると、価格が (約) 半分になり、S3 が非常に安くなりますが、S3 が CDN ではないという問題が依然としてあります。
私は実際には@cirrusの回答から続けただけなので、上記の回答のような質問を実際に再評価します。
一例として、Youtube は実際にすべての画像を 1 台のコンピューターに保存し、それを配布しています。そのため、2 億のサムネイルを簡単に管理でき、ファイル システムから毎日多くのビューを簡単に取得できます。したがって、ファイル システムに関するあなたの心配は過大評価されていると思います。
どちらのデータベースが優れているかについては...わかりません。それはあなたのテスト次第です。
つまり、問題に対する答えは、シナリオ、予算、ハードウェア、およびリソースによって異なります。つまり、AWS サーバーを使用している場合、これは専用の社内サーバーとはまったく異なる答えになります。
Amazon の S3 または Azure Blob Storage に貼り付けてみませんか? それらははるかに適合しており、スペースやメモリの問題はなく、展開を管理する必要もありません。