書くことがいっぱいあって分割する羽目に(ﾉ∀`)
設定ファイルを見た限りではDBへの格納は避けられないと思う。
検証してみる
ひらめいた。
DBに格納されるのは まぁ置いといて（何
キャッシュって言うくらいだから、表示するときはDBからの画像情報取得より先に
ファイルの存在有無を見に行きそうなもんだ。
表示するファイルがあればそれで良し、なかった場合はDBへ となるのではないか。
（面倒なのでソース追う気なしｗ）
VM検証環境で動かして試してみましょう。
diaryを作成し、画像を3つ登録。
DBに3レコード増えているのと、キャッシュとして画像ファイルがあることを確認。
画像に対して
- キャッシュの画像を削除
- DBのレコードを削除
- キャッシュの画像とDBのレコードを削除
を実施。
で、記事を表示してみると
- 画像は表示される。キャッシュの画像も復活していた。
- 画像は表示される。
- 画像は表示されない。
やっぱりね(･∀･)
あれ？
なんでDBから消したのにdiaryの関連する画像を引っ張ってこられるんだ？
レコード消えたら追えなくなるような？
c_diaryのテーブル定義書で項目を見ると
c_diary_id
c_member_id
subject
body
r_datetime
r_date
image_filename_1
image_filename_2
image_filename_3
is_checked
public_flag
u_datetime
is_comment_input
ファイル名で管理してるんかいｗ( ;ﾟ;ж;ﾟ;)`;ﾞ:;`;
画像が格納されているテーブル（c_image）は
c_image_id filename bin r_datetime type
こうなっている。c_image_id はシーケンス。
なんつーか、c_image_idというシーケンスで一意になっているのに、
何故それをキーにしてc_diaryで定義しないんだ？
何か意味があってこうなっているんだろうけど、DB設計的には凄く気持ち悪い。
※てっきり c_diary に設定されている c_image_id をキーに c_image にある
c_image_idを取りに行くものだとばかり思っていた。
この微妙にアレなDB設計のおかげで多少楽になったのは事実なので文句は言わないけど。
対応
対応方針が決定した。
- 量の多い diary、コミュニティ系、コメント の画像をなんとかして実ファイルにする
- ファイルとして出力した画像のレコードを消す
で、応急対応としては充分だろう。
一定期間経った画像のレコードを定期的に削除する仕組みを作らないといけないけど
これは緊急ではないので後々。
問題は1番目。最初にして最大の関門。
しかも画像名は何処で使われたかによってファイル名が違うし、出力先も異なる。
キャッシュ画像については説明を簡単にするために省いていたけど
実際にはサムネ用の画像と実寸の画像（場合によっては＋α）の最低2つの画像が存在する。
参ったな・・・(ﾉ∀`)
仕方がないのでツールを作って検証環境でゴリゴリ回して
画像ファイルをキャッシュのディレクトリに出力するようにした。
凄ぇ時間かかったｗ（数時間
ファイル数は85,000ぐらい。
それを1回ローカルにコピーして、FTPでレンタルサーバのディレクトリにコピー。
予想完了時間が24時間とか出て泣きそうになる。
設定で同時転送数を9にしたらサクサク進んで1時間ちょっとで終わったけど。
DBのダンプを取った日より前で、日記、コミュニティ、コメントに使われている画像のレコードを
バッサリDelete。
25,000レコード以上あったものが183レコードにｗ
忘れてた。
アクセスログ（c_access_log）も不要だ。
config.phpにある
// アクセスログを取得するかどうか(c_access_log)
define('LOG_C_ACCESS_LOG', false);
LOG_C_ACCESS_LOGをfalseにする。
で、DBは全レコード削除。truncateで根こそぎ。
ちなみに約607万レコードあったｗ
これでひとまず容量超過しているDBから余計な物を消して、問題のない容量になった。
実施前のダンプファイル容量
実施後のダンプファイル容量
えれぇ減ったなｗ
ひとまず緊急対応はこれでOK。しばらく大丈夫でしょう。
余談
画像キャッシュをpublic_html以下に置くかどうかのOPENPNE_IMG_CACHE_PUBLICだけど、
trueにすると<img>タグの指定でpublic_html配下のディレクトリ構造がわかってしまう。
直接ファイルのパスを見るから速いだろうけど。
逆にfalseにするとimg.phpにパラメータを付けて処理が走る。
処理が走る分遅いけど、内部の構造がわからないので良い とも言える。
どっちも一長一短なので、何を重視するかで選択できますよ という設定項目なんだろう。
危機は脱したので一安心。
あとはDBの定期的な掃除をする方法を考えなくては。
構想自体は頭の中にあるけど。
