ユーザのキャッシュを、Twitter APIベースのキャッシュから、ユーザ毎にデータベースのような機構を用いて管理する。

問題¶

ユーザ情報を求めるAPIには回数の制限があるが、 user/lookup エンドポイントは、1回のリクエストで100人まで同時にリクエストできる。よってこのエンドポイントに一回でできるだけたくさんのユーザ情報をリクエストできれば、レートリミットの節約になる。しかし、このAPIにはそもそも以下のような問題があり:

• #685 users/lookup がHTTPステータスコード403 を返すことがある

更に、APIキャッシュはエンドポイントとパラメータの両方が完全に一致しないと使えないため、全く同じ100ユーザに対してリクエストしないとキャッシュヒットしない(一人でも変わればヒットしない)ので、現実的にはほぼこのキャッシュは使われない。

ユーザデータベース¶

そこで、mikutterが取得したユーザデータを恒久的に維持し、Retrieverがユーザデータをローカルストレージ上から返すようにする。
具体的には、ユーザIDとスクリーンネームからユーザを探索できるようなデータベースを構築する。

• SQLite。IDとScreenNameにインデックスを貼れば高速に検索できることが期待できる。パフォーマンスも期待できる。ただし、Cエクステンションのライブラリが新たに必要になってしまうことや、一度過去にSQLiteは取りやめたことがあったので、また使うとなれば慎重に検討しなければならない
• ファイルシステム。APIキャッシュのようにディレクトリに散らして1ユーザ1ファイルに保存しておくことで、IDから一意にファイル名を特定すれば十分なパフォーマンスを期待できる。スクリーンネームからも検索できる必要があるので、スクリーンネーム→ID変換も別途必要。

他の方法が思いつかなければファイルシステムで実装して、問題があればSQLiteを検討する。