2010年06月25日

cassandra(悲劇の預言者)に過去データを覚えてもらう。


 さて、1300万レコードを覚えてもらうわけですが、その前に。
 この大量のレコードは情報の極ごく一部です。これはテスト用に貰った5日分データであり、本番は365日×事業者数のデータ量になります。
 なので、この時点で指数乗的に検索時間が増えて行くRDBでは無理になってしまったのです。
 それがcassandraなら比例的な検索時間の増加で済む(らしい)です。

 でもcassandraは「LIKE検索」とか「WHERE検索」とか出来ません(たぶん)
 飽く迄Keyと列で指定された行のValueを取得するだけです。

 じゃあ、どうすればいいのか?というところですが、以下のページがそこそこ分かりやすく説明してくれています。
 
Cassandraで登録しているカラムデータの検索方法(Cassandra:inverted indexの翻訳)

 私がざっくり説明すると「自分で検索用インデックスを作ってね」ということです。
 
 なんということでしょう!
 
 データベースの一部の機能を自前で用意する必要があるのです。
 これはデータベースマニアには堪らないですね。
 でも、残念ながら私はデータベースマニアではないので、あまりうれしくありません。

 それでもここを考えないと進みませんので仕方ないですが、考えます。
 
■1レコードの情報
・オブジェクトID
・時刻
・月
・日
・時
・曜日
・休日フラグ
・天気
・ステータス(%)

 時刻とその他の情報が重複しておりますが、この辺はあとで検索に使いたいので必要になります。
 例えば、「あるオブジェクトIDの日曜日の14時~18時のステータスの平均」とかそういう指定で集計する必要があるのですね。

 まずはインデックス以外のデータ部分を考えます。
 Keyとして登録する必要があるのは「オブジェクトID+時刻」となります。
 データ部分は「月~ステータス」まで普通に登録しましょう。

 次にインデックスをどの情報で持つかを考えます。

■検索するためのインデックス条件
・オブジェクトID
・月
・日
・時
・曜日
・休日フラグ
・天気

 これらに1つずつ登録してもいいのですが、これだと「AND検索」したときにアプリケーション側ですることが多すぎます。
 それに月だけ指定して取得した場合、確実に1300万レコードとか拾ってきそうです。
 仮にどんなに良いマシンを使っても処理が終わる気がしません。

■登録するインデックス
・月→12通り
・日→31通り
・時→24通り
・曜日→7通り
・休日フラグ→2通り
・天気→晴れ、曇り、雨、雪の4通り

 となり、これらの検索条件としてKeyに「Month=7」と指定したレコードを別途作るわけですね。
 で、カラムに「day=12」としたものを作り、valueに「オブジェクトID+時刻」でデータを登録しておき、データ全体を呼び出せるようにしておくわけですね。
 これならば2通りまでの組み合わせなら対処できそうです。
 あとは事前にcassandraの設定が必要になりますが、ColumnFamilyを設定すれば更に3通りの組み合わせに対処できます。
 
 いずれの場合もほぼ自動でインデックス作成ルーチンを組むことが可能です。
 
 Keyspace1.ColumnFamily1.SuperColumn1['key']['column']

 となっているので、実際には、以下のような指定で値をセットしたり、取得したりします。
 
 Keyspace1.Month=04.Day=15['ObjectID=ID0001']['Kindofday=Mon']=【IDリスト】
 
 うーむ、Column名に「=」が使えるのか。
 また取得範囲が広い場合は、絞り込むことも可能だそうです。そこは実際にデータを入れてから取得するときに考えたいと思います。

trackbacks

trackbackURL:

comments

comment form

(LICALD にはじめてコメントされる場合、不適切なコメントを防止するため、掲載前に管理者が内容を確認しています。適切なコメントと判断した場合コメントは直ちに表示されますので、再度コメントを投稿する必要はありません。)

comment form