私の人生では、S3（Rackspaceクラウドファイルを含む）とMongoDBの両方でビデオ配信を行ってきました。
ほとんどの人は、一目見ずにS3を選択しますが、どちらにも欠点があることがわかりました。大きな問題の1つは、S3がCDNではなく、実際には特定のリージョン内の冗長ストレージであり、他のS3リージョンに複製されないことです。つまり、S3の上にクラウドフロントなどを使用してイメージにpingを実行する必要があります。サイトに深刻な負荷がかかる場合は、一種のキャッシュに変換します。
S3には、CDNのようなものを減らし、ストレージウェアハウスを増やす他の機能もあります。そうは言っても、アクセス頻度の低いファイルの場合、S3は非常に高速です。
もちろん、この二重層はメンテナンスなどの複雑さを生み出します。それだけでなく、CDNはTTLで機能します。現在、多くのCDNにはエッジパージ機能がありますが、ファイルにアクセスできないようにするための100％確実な方法ではありません。
そのため、セットアップとアクセス（削除する必要のあるファイルへのアクセスも可能）により、これは非常に迅速にコストがかかる可能性があります。
これは、MongoDBができた場所です。 勝つ。シナリオによっては、MongoDBは、AWS上の多数のマイクロインスタンスを使用して実際に情報を保持し、これらのインスタンスにスポットインスタンスの予約を追加して（ダートチープ）、必要なものをすべて使用できるため、実際にはここで安くなる可能性がありますは1台のマシン上の大きなディスクです。
地獄、S3を使用して画像を保存し、MongoDBをクラウドフロントの代替として使用することもできます。
異なるリージョンに画像をpingする場合は、そのターゲットリージョンにいくつかのスポットインスタンスを作成し、MongoDBにそのデータを複製させます。そのリージョンから頻繁にアクセスされるファイルのみがそのリージョンに配置されるようにするために、レプリケーションを使用していくつかのクールな作業を行うこともできます。
したがって、MongoDB（またはCassandra）を捨てるのではなく、2つの間でミーンズテストを行います。
編集
S3の価格設定に関する追加の注意事項として、ファイルをRR（Reduced Redundancy）に保存すると、価格が半分（約）になり、S3は非常に安価になりますが、S3がCDNではないという問題があります。
さらに編集
私は実際には@cirrusの回答からのみ引き継いだので、実際にあなたの質問を再評価します。これはちょっと上で回答されたものです。
一例として、Youtubeは実際にすべての画像を単一のコンピューターに保存し、それを配布するので、200mのサムネイルを簡単に管理でき、ファイルシステムから毎日多くのビューを簡単に管理できます。ですから、ファイルシステムについてのあなたの心配は過大評価されていると思います。
どのデータベースが優れているかについては...わかりません、それはあなたのテストに帰着します。
つまり、問題に対する答えは、シナリオ、予算、ハードウェア、リソースによって異なります。つまり、AWSサーバーを使用している場合、これは社内サーバー専用とはまったく異なる答えになります。