HeatHashのアーキテクチャについて

HeatHashのアーキテクチャについての解説を書こうと思う。

入力から出力まで順番に書いていこうと思う。

まず、Twitterの収集はTwitterStreamingAPIをRubyで読んでいる。そして、位置情報付きのTweetがあったら、RubySTOMPを使ってHornetQのキューにそのTweetの情報を投げる。なお、このときにキーワードデータベースから検索用キーワードを取り出して、TwitterStreamingAPIに渡している。また、もうひとつのRubyプログラムで、sampleストリームから位置情報付きのTweetを同様に収集している。

次に、キューから取り出したTweetをTokyo Cabinetに格納する部分をJavaで作った。ここで、独自に考えた空間インデックス構造をキーとして、TCのB-TreeDBに格納している。また、格納時にキーワードをAC法で検索・分類し、キーワードごとと、ズームレベルごとに、あらかじめ分割してTCに格納している。この部分は後ほど別記事でまとめる。

最後にヒートマップの表示は、サーバーライブラリとしてnettyを用いたJPEG画像送出に特化したHTTPサーバープログラムとなっている。ここで、以前書いたJPEG直接生成を使っている。TCからデータを取り出し、二次元配列にしてJPEG画像を生成している。ここも、nettyの使い方のまとめも含めて別記事でまとめたい。

また、Webのキーワード入力の裏で動くのが、Rubyで作ったCGIで、新しいキーワードが入力されるとTCのTableDBに格納し、DBにあるキーワードならカウントアップする仕組みになっている。また、入力されたキーワードのヒートマップ表示URLにリダイレクトする。

以上、大まかに分けると4つのパートがHornetQとTCを介して協調して動作する、結構複雑な仕組みとなっている。

以後の記事で、各部分について述べていきたい。

追記：図があるとわかりやすいと思うので、時間のあるときに描きます。