私はいくつかのサイトでこの問題に対処してきましたが、上で説明したいくつかのテクニックと、そうでないいくつかのテクニックを使用しています。幸いなことに、大規模なアップロードを許可することは、実際にはかなり現実的です。
これの多くは、ファイルをアップロードした後に実際に何をする予定かによって異なります...ファイルに対して行う作業が増えるほど、ファイルをサーバーに近づけたいと思うようになります。アップロード時にすぐに処理を行う必要がある場合は、おそらく純粋な Rails ソリューションを使用することをお勧めします。処理を行う必要がない場合、または時間が重要でない場合は、「ハイブリッド」ソリューションの検討を開始できます...
信じられないかもしれませんが、 mod_porterを使用するだけでかなり幸運に恵まれました。Mod_porter は、アプリが通常行う多くの作業を apache に実行させます。アップロード中にスレッドと大量のメモリを拘束しないようにするのに役立ちます。簡単に処理できるように、アプリに対してローカルなファイルが生成されます。アップロードされたファイル (ストリームを考えてください) を処理する方法に注意を払えば、従来はかなりコストのかかる操作であっても、プロセス全体でメモリをほとんど使用しないようにすることができます。このアプローチでは、アプリを機能させるために実際にセットアップする必要はほとんどなく、コードを実際に変更する必要はありませんが、特定の環境 (Apache サーバー) とそれを構成する機能が必要です。
また、チャンクアップロードや再開可能なアップロードなどの優れた機能をサポートするjQuery-File-Uploadを使用して幸運に恵まれました。mod_porter のようなものがなくても、これはアップロード中に実行スレッド全体を拘束する可能性がありますが、適切に実行されれば、メモリ上で適切なはずです。これにより、ファイルが「クローズ」され、その結果、処理が容易になります。このアプローチを実装するには、ビュー レイヤーを調整する必要があり、すべてのブラウザーで機能するとは限りません。
可能なオプションとして FTP と bittorrent について言及しました。サーバーにかなり近いファイルを取得できるため、これらは思ったほど悪いオプションではありません。(ご指摘のとおり)アップロードするマシンに存在する場合と存在しない場合がある追加のクライアントが必要になるため、それらは相互に排他的ではありません。これが機能する方法は、基本的に、アプリから見えるようにダンプする領域を設定することです。次に、何らかの処理を行う必要がある場合は、cron ジョブ (または何でも) を実行して、その場所のアップロードを監視し、サーバーの処理方法をトリガーします。これは、上記のメソッドが提供できる即時の応答を取得しませんが、間隔を十分に小さく設定してかなり近づけることができます。この方法の唯一の本当の利点は、使用されるプロトコルが大きなファイルの転送により適していることです。
処理がまったく必要ない場合は、それらを使用して S3 に直接移動することをお勧めします。このソリューションは、実際にサーバー以外のファイルで何かをする必要があるとすぐに失敗します..
Rails アプリで HTML5 FileSystemAPI を使用した経験がないため、その点について話すことはできませんが、サポートできるクライアントが大幅に制限されるようです。
残念ながら、真の特効薬は 1 つではありません。達成しようとしていることに照らして、これらのオプションのすべてを環境と比較検討する必要があります。たとえば、Web サーバーを構成したり、ローカル ファイル システムに永続的に書き込んだりすることができない場合があります。jQuery-File-Upload は、実際にはアプリケーションを変更するだけでよく、実装を別の環境に最も簡単に移動できるため、ほとんどの環境でおそらく最善の策だと思います。