きんとう旅館／埼玉深谷[ビジネスホテル・宴会・懐石]に行ってきました。静かだし、お風呂も24時間入れるので、(開発)合宿向けですね。メンバーはid:repose、id:yag_ays、id:mickey24、id:wakuteka、id:iNut。Rubyで色々やる人が多かった感じです。
この前も書きましたが、僕はデータがストリーミングな感じでどんどんくるような場合でも使えるような検索エンジンを書きました。検索対象のテキストがstaticではなく、動的に増えていくので、インデックスの構築をどーするのかとかそういうところを考える必要がありそう。書いたものはgithubに置いてます。
はまったところ
Twitter Streaming APIからデータを受けつつ、検索もできるようにするにはWriteとReadを(ほぼ)同時にできないといけないんですが、TokyoCabinet(以下TC)ではそれができないということに気づくのにそもそも時間がかかってました。。。
高速で便利なTCですが、不便な点もあります。データベースの整合性を保証するために、ひとつのプロセスがデータベースを書き込みモードで開いている間は、別のプロセスがデータベースを開こうとするとブロックして待たされてしまうのです。TCはマルチスレッドのプログラミングモデルに最適化されていて、マルチプロセスでアクセスするのには向いていません。
1978th.net
で、どうしようかと思ったんだけど、TokyoTyrant(以下TT)だとそれが可能になるらしいです。
とはいえ、Apacheなどのマルチプロセスモデルのサーバ上でプログラムを動かすような場合にはどうしてもマルチプロセスでデータベースを共有したくなります。そこで、Tokyo Tyrant（以下TTと呼びます）というサーバを開発しました。TCのデータベースを抱え込んだ単一のサーバプロセスに対して複数のクライアントがネットワーク経由で操作指示を出すことで並列処理を実現します。
1978th.net
TTはTCとインターフェイスがほとんど一緒なのでコードの書き換えは最小限で済みました。素晴らしい。
やってないこと
要するに何もやってないんじゃないんか、って感じですが色々はまりまくってました。。。
- 文字の出現位置まで保存していない
- そのためN-gramで検索したあとの積集合を取った後のものが、クエリーと一致するとは限らない作りになってる
- クエリーが「月曜日」だったら「月曜」と「曜日」が別々で入ってるものの結果に出てくる
- 今はBigramでやっていて、一文字のクエリーで動かない
- Twitterの発言自体をTTに保存してないので、発言を蓄えておくデータベースを他に作る必要がある
- この辺のTTとかの構成をどういう風にするのがいいのかがまだよく分かってない
- posting listをちゃんと圧縮できてない
- pack、unpackとかでやってるけど、最低限ソートして差分と取るとか、圧縮率は多少悪くてもいいので高速に圧縮できるアルゴリズムを使う
