免責事項: Amazon S3 や Azure Blob Storage などのクラウド サービスを使用することは、まったく選択肢ではありません。
目標: Windows Server で数百万 (*) の画像とビデオ ファイルをホストする。そのコンテキストでの NTFS の制限を認識しています。そこで、2 GB のコンテナーを備えた GridFS を使用した MongoDB を試してみましたが、うまく機能しましたが、少し遅くなりました (理由はまだわかりませんでした)。
私の質問:
私のシナリオが非常に曖昧に説明されていることは承知していますが、今のところ実際のデータはありませんので、私を責めないでください ;-)。
(*) おそらく数万から数十万にすぎませんが、いつかは数百万になることを願っています ...
ありがとう！
私たちのサクセスストーリーを共有したいと思います。何百万もの画像を保存するためにMongoDB GridFSを使用しています。私たちのストレージの1つには次のものがあります。
フロントエンドとして、nginx と Go で記述された単純なデーモンがあり、GridFS から 1 秒あたり 1,000 を超えるリクエストでデータを処理できます。
私は GridFS について何も知らないという事実を考慮して、数年前にかなり大きな (10kb から数百 mb のサイズで 2 億 5000 万以上のドキュメント) システムで見たものを書き留めておきます。
ドキュメントの取得は、ドキュメントのリポジトリ名とトークンしか認識していないホスト システム (おそらくコア アプリケーション) によって開始されました。
ドキュメント ストレージ自体は、Web サーバー、データベース、および (静かで洗練された) ファイル システム (SAN、SATA、SCSI、およびテープ) で構成されていました。
Web サーバーは、特定のレポ内のドキュメントのリクエストを受信し、データベースからメタデータを取得し (レポ名、トークン -> フォルダー名、ファイル名)、ディスクからファイルを取得し、ネットワーク経由で吐き出しました。データベース統合ファイルストリームなどは使用されていませんでした。このコンセプトは非常に速く、簡単で、頑丈でした。以前、一部のデータベース ストレージ (IIRC Oracle および MSSQL) との比較を行ったことがありますが、これらのデータベースは特に速度の面で大惨事になりました。当時、MSSQL はネイティブ ファイルシステムを使用していなかったと思います。
水平方向のスケーラビリティを追加するには、サーバー間で負荷を分散するメカニズム (別名リポジトリ、シャード) を見つけるだけでよいでしょう。
私の経験から、このようなドキュメント ストアでのファイルの取得と読み込みの速度は、使用するストレージの種類と密接に関連しています。要件に応じて、RAID システム、SAN、インメモリ ファイルシステム、または RAMSAN が必須です。
速度が必要な場合は、常にネイティブファイルシステムを使用し、それが何をしているかを理解してください。これは、いくつかの汚い作業 (特にシャーディング) を自分で行う必要があることを意味します。