新しいWebサイトを開発し、すべてのユーザーアップロードのストレージとしてGridFSを使用します。これは、通常のファイルシステムストレージと比較して多くの利点があるためです。
Nginxが提供するGridFSのベンチマークは、nginxが提供する通常のファイルシステムほど高速ではないことを示しています。
すでに運用環境でGridFSを使用している人、または新しいプロジェクトに使用する人はいますか?
私は、名誉あるトラフィック統計(1日あたり約25,000人の訪問者)を備えた価格比較Webサイトの一部であるサーバーの1つで、仕事でgridfsを使用しています。サーバーのRAM、2ギガはそれほど多くなく、CPUでさえ実際には高速ではありませんが(コア2デュオ1.8Ghz)、サーバーには十分なストレージスペースがあります:RAID 0構成で10Tb(sata)。サーバーが実行するジョブは非常に簡単です。
価格比較ツールの各製品にはイメージがあり(製品データベースによると約1,000万の製品があります)、サーバーの仕事はイメージのダウンロード、サイズ変更、gridfsへの保存、訪問者のブラウザーへの配信です。 ..グリッドに存在しない場合...または...既にグリッドに保存されている場合、訪問者のブラウザに配信します。したがって、これは「従来のcdnスキーマ」と呼ばれます。
このサーバーは稼働しているため、このサーバーに400万枚の画像を保存して処理しました。サイズ変更と保存はシンプルなphpスクリプトで行われます...しかし、確かに、pythonスクリプト、またはJavaのようなものがより高速かもしれません。
現在のデータサイズ:11.23g
現在のストレージサイズ:12.5g
インデックス:5
インデックスサイズ:849.65m
信頼性について:これは非常に信頼性があります。サーバーがロードされず、インデックスサイズは問題なく、クエリは高速です
速度について:確かに、ローカルファイルストレージとしては高速ではなく、おそらく10%低速ですが、画像を処理する必要がある場合でもリアルタイムで使用するのに十分な速度です。メンテナンス時間と開発時間も削減されました。単一または複数のイメージを削除するのが非常に簡単になりました。単純な削除コマンドでデータベースを照会するだけです。もう1つの興味深い点は、ローカルファイルストレージ(数千のフォルダーにある数百万のファイル)を使用して古いサーバーを再起動すると、システムがファイルの整合性チェックを実行するために数時間ハングすることがあります(これには本当に時間がかかりました...)。 gridfsではもうこの問題はありません。画像は大きなmongodbチャンク(2gbファイル)に保存されます
そう...私の考えでは...はい、gridfsは本番環境で使用するのに十分なほど高速で信頼性があります。
前述のように、通常のファイルシステムほど高速ではないかもしれませんが、 通常のファイルシステム に比べて人に利点があります。
最終的に、シャーディングを使用すると、通常のファイルシステムや単一ノードとは対照的に、GridFSストレージが実際に高速なオプションになるポイントに到達する可能性があります。
mdirolfのnginx-gridfsモジュールは素晴らしく、セットアップはかなり簡単です。 Paint.ly で本番環境で使用して、すべての絵画を提供していますが、これまで問題はありませんでした。
ただし、大規模なDBの修復に注意を向ける-開発中の新しいシステム、mongoは正常に終了せず、7TB GridFSの修復には130時間かかるようです。
このため、OpenStack SwiftまたはCephに切り替えることを検討すると思います。それでも、それまでは良かったです。nginx-gridfsモジュールは便利です。
何をしているのかわからない限り、gridfsを使用することはお勧めしません。 GridFSは、チャンク用にファイルを分割し、2つのコレクションにファイルを保存する単なる抽象化レイヤーです。より多くのファイル-より多くのオーバーヘッド。ファイルが32Mを超えない、ほぼ同じサイズであると予想される場合は、正しい方法です。 gridfsに大きなファイルを保存しようとしないでください。どうして?
読み込まれたプロジェクトの読み込みを検討している場合は、ファイルをドキュメントに直接読み込むか(16M以下のサイズの場合)、別のclusterfsを選択して、ファイル名/ inodeをロジックにリンクすることを検討してください。
お役に立てれば。