KVSをメインストレージと考えた場合のアプリケーション設計

昨日の日記で少し書いたのですが、現在仕事でokuyamaをメインストレージとして
アプリケーションを作成中、そこで感じたことをメモ。


okuyama作ってますが業務ではkvsはキャッシュとしてしか使ったことなかったので。。。




メインストレージといっても、あくまでもRDBMSとセットで利用します。


ほとんどはRDBMSに格納されているんですが、一部のデータを
okuyamaに格納します。
そのデータは日に数万から、数十万増加する試算です。
それをシステムからリアルタイムに何種類かのソートパターンで表示します。
何ともチャレンジングな。。。
挑戦しがいがあります。


で、早々にRDBMSの設計は終わらして、kvsに格納するデータの設計です。
okuyamaはタグという概念があるので少しkey-valueの概念とは異なりますが、
多分他の場合も応用はきくかな。




アプリが都度表示する対象件数は数百件の母数に対して、特定のソート条件で
ソートした中から20ページ程度でページングして表示です。
多分最初の数ページしか見ない感じです。なので、ソートはかなり重要！
で、出来たデータ設計は下




インデックスとなるrow
key, tag, value
ソートキーで並べた場合のインデックスNo_母数全体を束ねるユニーク値_ソート項目名, 母数全体を束ねるユニーク値_ソート項目名_ページNo, KVS全row中でのキー値


実際の表示対象となるrow
key, value
KVS全row中でのキー値, value値




あらかじめデータを登録する処理でソートしてひたすらインデクスのrowを登録します。
最後に表示rowを登録。


後は取得側は表示したい母数を一意にする値をRDBMSから取得して
ソートの要望と表示ページNoに合わせて、ソート項目名、ページNoを連結した
値をtagとしてokuyamaからgetすると、そのtagに紐付くKey値群が取れてくる仕組み。


データイメージは
インデックスとなるrow
母数を束ねる"1"というグループのDATEで並べた、1ページ目を取得したい場合は

こんな感じかな。
これなら表示アプリのソート幅も小さいし、1ぺージあたりの件数を増やしたい場合も
用意に対応できそうなので(1ページあたろ40件とかなら2ページTag分一度にとるとか)、
これで進めることになりました。



さてうまくいくだろうか。。。