2011-07-13 16 views
0


大きなファイル(〜200MB)をdbに直接保存しています。
私はそれに問題があります。ファイルは、DBに保存するときに
は、ステージ上で(スワップのラムと3ギガバイトの3ギガバイト程度)自由RAMの増加巨大な使用によって引き起こさ:大きなファイルをBLOBにアップロード

@job.pdf = params[:job][:pdf].read 

これが完了すると、使用中のいくつかのRAMとスワップがまだあります。
これを最適化する方法はありますか?
P.S. mogrel上で動作するmysqlを使用しています。

+2

ファイルをデータベースに保存する必要がありますか?ファイルをファイルシステムに保存し、そのファイルシステムへの参照をデータベースに保存する方が良いでしょう。 papercliの使用を検討しましたか? (https://github.com/thoughtbot/paperclip) – samullen

+0

私は同様の問題を抱えていました(私のコメントと共にオンライン論文を保存したがっていました)、 '/ public/res// '。それは簡単に実装でき、データベースは小さく保たれました。 – mliebelt

+0

問題は、アプリケーションにのみファイルにアクセスできる必要があることです。 – sfate

答えて

2

MySQLでは、サイズが1MBを超えるBLOBフィールドを保存または読み取るには、サーバー側のパラメータmax_allowed_pa​​cketをデフォルトよりも大きくする必要があります。実際には、このパラメータには16-32MBを大きく超えることはできません。この増加のための価格は、すべての新しいdbクライアントが少なくとも多くのメモリを消費し、一般にサーバーのパフォーマンスが大幅に低下するということです。

つまり、MySQLはBLOBフィールドのサイズが1MBを超えていても(実際にはサーバ設定をしていない、またはしたくない場合)、約16MBまで処理することはできません。

これは哲学的な質問になる可能性があります。大きなブロブをデータベースに保存することをお勧めしますか?私は多くのタスク(ただしすべてではない)は素晴らしいアイデアだと思います.MySQLはそれほど悪く(他の理由のために)、SQLサーバーソリューションとして使用しないでください。

代わりに、私はPostgreSQLを使用しています。これは、BLOB(実際はBYTEA)を完全にサポートしており、クライアントまたはサーバーの調整なしに4GBの上限を宣言しています。それに加えて、実際には、gzipよりもわずかに悪いLZアルゴリズムで透過的に圧縮しますが、圧縮を行わない場合よりもはるかに優れています。

関連する問題