MD5でもGUIDでもお好きなように。そういうのはファイル名をタイムスタンプにすると思うけどな、普通は。
可逆性があるワケでもないのであまり意味がない。uniqid() か、2の言うように microtime() でも使えばいい。
内容を元に考えるかな。まずファイルとしてってのも問題だから今後はRedisとかに変えようね。まずAPIのレスポンス内容がどれぐらいの頻度で変わるかによってexpireも変わるし、リクエストキーを名前に付けた方が管理しやすいなら、ユニークなリクエストキー+ハッシュとかかな。タイムスタンプは被る可能性もあるから要注意。あとレスポンスが帰ってくる前にリクエストが発生するケースも考えてabort処理やトランザクションも初心者は忘れないように。
Re:2 回答ありがとうございます。追加で質問になってしまい恐縮ですが、タイムスタンプをファイル名にした場合、再度同じリクエストが発生した時にどうやってそのキャッシュを読みにいけばいいんでしょうか？
Re:5 基本的にファイル名が被らないようにするためのタイムスタンプだから、APIで使ってるキー名を使いなよ。何かユニークなIDがあるだろ？ないならmokuteki_key1_key2って名前にしておいて、同じキーでリクエストする前にファイルが存在すれば、ファイルを読み、無ければリクエストとする。
重要なデータ（個人情報とか）を扱ってたりしなければそれで一応実用になるんじゃないですかね。あとは、ファイルアクセスを排他制御すること、APIのレスポンスが変わるの考慮してファイルを一定時間内にexpireすることあたりを気にすればOKかな。
Re:3 今回MD５を利用したのは、リクエストURLが長すぎるためそのままのファイル名ではなく、短くしたかったからという理由のみです。
Re:4 ありがとうございます。Redisですか。いずれMemcachedを利用しようと検討していたのですが、>あとレスポンスが帰ってくる前にリクエストが発生するケースも考えてabort処理やトランザクションも初心者は忘れないように。こちらはAPIのレートリミットとして１秒に１リクエストというのがありましたので、その対応と合わせて考えたいと思います。忠告ありがとうございます。
ユーザのリクエストによってパラメータが可変になるような感じですかね？値も自由な感じで。例えば住所から緯度経度とったり天気情報とったりするAPIの類とか。それでキャッシュはパラメータからファイル名を導き出したいけど、パラメータが長すぎるみたいな。簡易的に対応したいならmd5してしまっていいと思う。ただ衝突リスクはあるから、md5よりsha1を採用するとか。それでも衝突リスクがあることには変わりはないけど。まだマシかな程度。ただ上にあるようにRedisのようなNoSQLデータベース使った方が確実だし綺麗ではあるね。
Re:10 あとファイルの場合は、ディクトリ内に保存できるファイル数の上限には気をつけて。生成されるキャッシュが多い場合はそれを考慮しないとキャッシュファイルが生成出来なくなるので。
Re:7 ありがとうございます。公開情報のみですので、扱いに慎重にならないといけないデータというのはないかと思います。ファイルの作成日から一定時間たっていたら再度APIにリクエストするようにしているのですが、古いデータについては、cronなどで消すのがてっとり早いでしょうか？
Re:10 ありがとうございます。説明不足で失礼しました。そうです。ユーザーのリクエストによってパラメータは可変になります。キーワードや絞り込み条件が変更される仕様です。＞あとファイルの場合は、ディクトリ内に保存できるファイル数の上限には気をつけてありがとうございます。上限が有ることを知りませんでした。NoSQLでいくか、ファイル管理についてしっかりやっていくか検討致します。
12 件の回答
MD5でもGUIDでもお好きなように。
そういうのはファイル名をタイムスタンプにすると思うけどな、普通は。
可逆性があるワケでもないのであまり意味がない。uniqid() か、2の言うように microtime() でも使えばいい。
内容を元に考えるかな。
まずファイルとしてってのも問題だから今後はRedisとかに変えようね。
まずAPIのレスポンス内容がどれぐらいの頻度で変わるかによってexpireも変わるし、リクエストキーを名前に付けた方が管理しやすいなら、ユニークなリクエストキー+ハッシュとかかな。
タイムスタンプは被る可能性もあるから要注意。
あとレスポンスが帰ってくる前にリクエストが発生するケースも考えてabort処理やトランザクションも初心者は忘れないように。
Re:2
回答ありがとうございます。
追加で質問になってしまい恐縮ですが、タイムスタンプをファイル名にした場合、再度同じリクエストが発生した時にどうやってそのキャッシュを読みにいけばいいんでしょうか？
Re:5
基本的にファイル名が被らないようにするためのタイムスタンプだから、APIで使ってるキー名を使いなよ。
何かユニークなIDがあるだろ？ないなら
mokuteki_key1_key2って名前にしておいて、同じキーでリクエストする前にファイルが存在すれば、ファイルを読み、無ければリクエストとする。
重要なデータ（個人情報とか）を扱ってたりしなければそれで一応実用になるんじゃないですかね。
あとは、ファイルアクセスを排他制御すること、APIのレスポンスが変わるの考慮してファイルを一定時間内にexpireすることあたりを気にすればOKかな。
Re:3
今回MD５を利用したのは、リクエストURLが長すぎるためそのままのファイル名ではなく、短くしたかったからという理由のみです。
Re:4
ありがとうございます。
Redisですか。いずれMemcachedを利用しようと検討していたのですが、
>あとレスポンスが帰ってくる前にリクエストが発生するケースも考えてabort処理やトランザクションも初心者は忘れないように。
こちらはAPIのレートリミットとして１秒に１リクエストというのがありましたので、
その対応と合わせて考えたいと思います。
忠告ありがとうございます。
ユーザのリクエストによってパラメータが可変になるような感じですかね？値も自由な感じで。例えば住所から緯度経度とったり天気情報とったりするAPIの類とか。
それでキャッシュはパラメータからファイル名を導き出したいけど、パラメータが長すぎるみたいな。
簡易的に対応したいならmd5してしまっていいと思う。ただ衝突リスクはあるから、md5よりsha1を採用するとか。それでも衝突リスクがあることには変わりはないけど。まだマシかな程度。
ただ上にあるようにRedisのようなNoSQLデータベース使った方が確実だし綺麗ではあるね。
Re:10
あとファイルの場合は、ディクトリ内に保存できるファイル数の上限には気をつけて。生成されるキャッシュが多い場合はそれを考慮しないとキャッシュファイルが生成出来なくなるので。
Re:7
ありがとうございます。
公開情報のみですので、扱いに慎重にならないといけないデータというのはないかと思います。
ファイルの作成日から一定時間たっていたら再度APIにリクエストするようにしているのですが、
古いデータについては、cronなどで消すのがてっとり早いでしょうか？
Re:10
ありがとうございます。説明不足で失礼しました。
そうです。ユーザーのリクエストによってパラメータは可変になります。
キーワードや絞り込み条件が変更される仕様です。
＞あとファイルの場合は、ディクトリ内に保存できるファイル数の上限には気をつけて
ありがとうございます。上限が有ることを知りませんでした。
NoSQLでいくか、ファイル管理についてしっかりやっていくか検討致します。