データベースで画像管理していますが、ユーザーからのファイルアップロードが増え、日々ディスクが少なくなっています。いずれディスク交換かサーバー増設はするにして、それ以外にこの問題に対処する有効な方法を教えて下さい。

ユーザーからのアップロードファイルをbase64エンコードしてテキストとしてDBに格納。

この部分に無駄があります。

BASE64にすると、元データ（バイナリ）よりデータサイズが２～３割大きくなります。

一般的に、画像データなどのバイナリデータはDBレコードに格納せず、単独のファイルとして保存します。DBに格納するのは、検索に必要なファイル名、登録日、登録者、タグなどとします。

その画像へのアクセス回数を記録しておき、アクセス頻度の少ない画像データは圧縮したり、削除対象とすることが考えられます。

ファイルの保存単位を制限して、且つ保存しきれなくなった分を圧縮して圧縮ファイルとして保管していくとかはいかかですか？

そうするとコミュニティのメンバーがその圧縮ファイルを観覧するには毎回ダウンロードして展開する羽目になるかもしれませんが。というか、なりますね^^;

ファイルの保管数的に考えるとこちらの方が効率がいいかなとか思いました。

DBMSで長大なデータを管理させようとした場合、行の管理情報、列の管理情報など付加情報が少なからず発生します。DBMSでは、同時実行性、I/O、空きサーチ等を効率化するため、4KBや8KBなどのページ（ブロックに相当）といった単位でデータを管理します。textやvarchar、blobなどの列データは、ページ長を超えて持つことが可能です。その実装方法は、1列のデータを、物理的には複数のレコードとして管理しています。各物理レコードには、それぞれDBMSが管理するための付加情報が存在します。

つまり、DBMSで長大データを管理させる場合、OSレベルのファイルで管理するより、付加情報が多くなるのです。しかし、DBMSで管理することで、セキュリティの一元化、同時実行性、障害回復などが容易になります。

データ量が膨大なシステムでは、DBMS上では格納先のパスのみ管理する方式を採用している例が少なくありません。しかし、そういった形態では、DBMSで管理している部分と、OSのファイルシステムで管理している部分で、上述のようなセキュリティ、同時実行性、障害回復などの問題点をクリアする必要があります。

自分のところでは、ユーザからアップされた画像の解像度やサイズの長辺が指定サイズよりも大きい場合は1024pxにするように、TIFFやPICT等の場合はjpgに圧縮するように等、ImageMagickで自動的に変換させています。

その変換後のイメージをファイルサーバーに保存し、パスをDBに登録して読み出す形にしています。

生成されたイメージには16桁の固有のIDが割り当てされ、格納されるフォルダ名が保存時に生成されますので、URL直打ちでデタラメにイメージにアクセスしようとしてもそうそう引っかからないですし、そもそも外部から引っかからない設定になってます。

それから、cbicさまがおっしゃる「コミュニティのため、アクセス管理が重要でして、また、ファイル管理の都合などを総合的に考えると、DBでの画像管理は外せそうにありません。」ということですが

自分ところは一応これで問題なく管理が出来ていますが、このような方法では問題ありますでしょうか？