PHPでの大量な画像を用いる場合のシステム設計

質問

PHPは以前より、簡単なシステム
（文字中心の掲示板、少量の画像を用いたシステム、など）
は趣味程度で作成はしていたのですが
今後、多くの画像を用いたシステムを作成したいと考えています。
作成した、雛形システムを利用して
新たなテーマのコンテンツ作成のきっかけになればと思っています。

■質問の動機
さて本題ですが、質問はタイトルの通りでして、
やはりシステムのテーマに色濃くなりますと、
どうしても大量の画像を使用した、アップロード⇔表示などが
頻繁なページの作成を想定しなければならないと考えています。

既にWEBでも、PHP等を用いそのようなサイトを個人運営している型も少なくなく
そのような方がどのようなファイル管理をしているのか
参考に出来ればと考えております。

■質問
システム的には、あるキーワード、ファイル名などで検索すると
一覧にそれに対応する画像が、表示されるようにしたい。
その際にアップロード処理、画像管理として一般的な方法を知りたいです。

例１
MYSQLなどのDBに、ファイルパスを登録、
実際の画像ファイルのリソース自体は、指定の格納フォルダを作成し順次格納していく

例2
もしくはDBにSQLでBLOB型で画像ごと一緒に登録する

等が思いつくのですが
例１の場合の方が、ファイル管理が楽そうだなと思っています。
しかしながら質問の動機通り、画像アップロードを基本としたシステムとする場合、
将来的に、DBに一緒に格納した方が処理が早いものなのかな？などと。も考えています。

何分そういうシステムを作成した事がないため、
もしくは自分で作成しながら試していくと言うのも手なのですが
大量画像となると試験的なことも難しいため、
こういう方法が既知としてベターだというものがあれば、
さっくりでいいので、参考程度にお聞かせ願えますでしょうか。

たいした質問でもありませんが、よろしくお願いいたします。

回答No.2

particlebeam · ベストアンサー

squidというプロキシーがあるんですが、これは大量の画像やhtmlを
キャッシュしています(たぶんご存じですよね＾＾：）

で、そのファイル管理方法なんですけど、ディレクトリをそのまま使ってます。
例えば　abc.png ならば a/b/abc.png のように適度な階層を作ります。
これは１つのディレクトリに大量のファイルを入れるとパフォーマンスに
問題が出るからだろうと思います。

またsmtpのqmailなんかも似たような階層構造で大量のメールを管理する
ためのパッチがあります。こっちは数字ですけどデフォルトでは２階層です。
何万件というメール配信を数十分で扱うためにはこれで十分だったりします。

まあ何が言いたいかというと普通はディレクトリを活用する方向で十分だと
いうことです。（個人的見解です）

この場合パフォーマンスの問題もBLOBのような特殊なシステムを考えるより、
単純によいディスク（SCSIとか）を使う方向で解決しやすい気がします。

BLOBは逆に困ったことがいくつかありました。
１、DBがでかくなりすぎる（これはバックアップで困ります）。
　一部しか変更がなくても単一ファイルだと毎回丸ごとコピーがめんどい。
２、変なファイルがまぎれこんだとき
　一覧するIFを別途作るのがめんどかった。
　さらにそれをウィルススキャンする必要が出たのですが、
　BLOBから全部ファイルに書き戻して、スキャンして、またBLOBに
　戻してキレそうになった。すなわちUNIXのツールがBLOBに対応して
　ないことを考慮してなかった。

まあ基本面倒くさいかどうかで決めてるから参考にならないですね・・

お礼

squidについては恥ずかしながら、今知りました。
今後の為、色々調べておきたいと思います。

たしかにメールの管理とかがあんな概算工になりますね。
デフォルトで2階層なんですね。
ディレクトリの階層分けについては
色々と試行しようによって成果がありそうで興味ありますね。

BLOBバックアップの話、チェック処理は目にうかぶようですね（汗
やはり、案１を基に進めてみたいと思います

回答No.3

crzmoto

ワタシも1案ですねー。

実際、業務としてWEBシステムを組んだりしてますが、
DBに画像を格納するのは容量のコトとか、いろいろ面倒臭いです。

逆に1案で問題出ることは殆どないですね。

この場合、システムの組み方でちょっとだけ気を使いますが・・・
・ファイル名が被らないようにする
被ると上書きされてしまう。ユニークな名称になるようにする。
タイムスタンプ+元のファイル名といった風にファイル名を生成する
DB側でシリアルナンバーを取って、そのナンバー自体をファイル名にする
など。

・ファイルサイズの調整
でかすぎる画像はUPできないようにする、必要に応じてリサイズするなど

・余裕があればディレクトリを分ける
余裕があれば保存先ディレクトリをわける。
ファイルの拡張子をみてjpg,gif,pngなどで分けるとか
もし会員制のサイトなら、会員ごとにUP先を分けるとか。
一応、アクセス先が集中しない方が負荷分散という意味ではよいのですが、
まー個人レベルでは大きなサイトでも、そこまで気を使わなくてもよいかな～とは思いますが。

こんなトコですかね。

お礼

ありがとうございます。
ファイル名は、やはりタイムスタンプが無難ですよね。
ディレクトリ分けで、少し考えなければってとこですね。
こういうのを考えるのは好きなので頑張ってみます
参考になりました

回答No.1

tomonkey0225

不動産サイトの構築をしてる者です。

一般的な事はわかりませんが、
不動産サイトともなると物件の画像や、店舗の画像、販売員の画像や町の画像等
大量どころの騒ぎではない量の画像を取り扱います。

で、実際にわれわれのやってる管理方法は質問者様の１の案にです。
(※正確には画像ファイル名のみ格納しています)

■理由
基本的に大量になればなるほどDBへの画像保存は控えたほうがいいです。
たしかにDBへ直接保存することでシステム構築という面では楽ですが運用・保守と
なってくるとそうもいかなくなります。

まず画像というものは、ファイルサイズが特定しにくいという事です。
またサイズが大きいものが入ってくるとHDDを圧迫していきますし大量にそれも頻繁に
アップロードされていくとなるとHDDの減りも激しくなります。

HDDを変えればすむ話なのですがこれがDBとなってくるとそうもいかず
DBの移行作業にもかなりの時間と工数がかかってきます。
またその移行作業をする際にはWEBも停止しなくてはなりません。

逆にパス及び、画像名だけであればリソースが保存されていくHDDだけを取り換えれば
すんでしまうので作業的にも楽に終わります。
またその間も別のシステムは稼働させられるというメリットもあります。
パスやファイル名(命名規則をつける)であればカラムサイズもしっかり指定できますし
よいと思います。

お礼

不動産も物件の画像など、大きな画像が結構多いですよね。
私も以前、不動産のサイト作成に興味がありまして
貴重な意見ありがとうございます。
私も今後、そういう機会があると良いですが。

運用についても、リソース種類ごとに分別して
管理の仕方は考えなくてはいけないですね。
稼動・メンテナンスしやすいように心がけます。

他の方の、書き込みでもありますが
この場合は、例えば画像は、[土地/新築/中古など]のカテゴリの下に、
物件ID毎やなどで、ディレクトリを分けたりとかですかね。

参考になりました。ありがとうございます