random partionerのデータモデリング

株式会社ワークスアプリケーションズ

堤勇人(@2t3)

RandomPartitonerのデータモデリング

所属

自己紹介

ワークスアプリケーションズ

Incubation Labo4 Webmail

お仕事

ウェブメールの開発

所属

自己紹介

ワークスアプリケーションズ

Incubation Labo4 Webmail

お仕事

ウェブメールの開発

・・・という名義で最先端技術を試す実験場

Webmail

AP: jetty

DB: cassandra, hbase

全てクラウド(AWS)で動作

1. CRUDが存在するデータを扱う

今回の達成目標

2. BETWEEN検索が可能

3. 余剰リソースを少なく

DELETEが存在する。

例えば、このユーザーの3月～5月のデータ、という検索をしたい。

低予算。

いわゆるRDB的な

前提知識：普通のデータモデリング

キー / カラム username(key) password

tsutsumi_h tsutsumi_h ********

yutuki_r yutuki_r **********

test_data test_data ******

例えば、Accountデータ

RDBを使え？

RDBを使え？

知らん！

批判は断る！

いやいや、分かってる分かってるんだ。最初から動的なウェブアプリケーションにCassandraなんて無理だし。アトミック操作も無いしね。件数表示とかすごい勢いでズレるし。それは分かっていながら、敢えて、そう敢えてのチャレンジなのですよ。本当はlike検索とかしたい。超したい。気軽にインデックスとか貼りたい。でも最先端技術使うって名目なんだもの。


もう一度、今回の達成目標



DELETEが存在する。

例えば、このユーザーの3月～5月のデータ、という検索をしたい。

低予算。

案1：人工キーを利用する

キー / カラム username password

1 tsutsumi_h ********

2 yutuki_r **********

3 test_data ******




案1：人工キーを利用する

キー / カラム username password

1 tsutsumi_h ********

2 yutuki_r **********

3 test_data ******

2,3は良いが、1で問題が起こる

DELETEが発生すると、キーに抜けができ、パフォーマンスが落ちる

案2：OrderPreservingPartitioner




node

node

node

tsutsumi_h yutuki_r

test_data

1,2は良いが、3が微妙

データの偏りが発生し、仕事をあまりしないノードが出来る


node

node

node

tsutsumi_h yutuki_r

test_data


node

node

node

tsutsumi_h yutuki_r

test_data

1,2は良いが、3が微妙

データの偏りが発生し、仕事をあまりしないノードが出来る

OPPを使った場合のデータ分布

稼働率が全体で50%以下

仕事をしないノードは仕事をするノードの25%以下しか働かない。

しかもこの余剰分は他が溢れた時に活かされることはない。

Columnについては検索ができる

前提知識：RandomPartitioner

例えば、p～zまでのカラム名を抽出

キー / カラム username(key) … password

tsutsumi_h tsutsumi_h … ********

yutuki_r yutuki_r … **********

test_data test_data … ******

案3：RPを使って横持ちindex化




key suzuki tamura tsutsumi urata wakui yutuki zhag



1,2,3を満たす・・・が

indexが壊れた場合に、全てのデータを一括で読むしか修復の方法がなくなる。



1,2,3を満たす・・・が

indexが壊れた場合に、全てのデータを一括で読むしか修復の方法がなくなる

案4：じゃあ全データ横持ちにする





username suzuki tamura tsutsumi urata wakui yutuki zhag

password ***** ***** *** ****** ****** **** ****

active 1 0 0 1 1 1 1

案4：じゃあ全データ横持ちにする


username suzuki tamura tsutsumi urata wakui yutuki zhag

password ***** ***** *** ****** ****** **** ****

active 1 0 0 1 1 1 1

1,2,3を満たす

さらにはcassandraのget_count()も使えるように！

横持ちの仕方には色々ある

key / column tsutsumi@20110524 tsutsumi@20110525

key tsutsumi@20110524 tsutsumi@20110525

username tsutsumi tsutsumi_h

password ******* ******************

active 0 1

完全横持ち

全てのデータが、column名ごとに横に入る。自由に検索が出来るが、 rowが大きくなる。



tsutsumi@key tsutsumi@20110524 tsutsumi@20110525

tsutsumi@username tsutsumi tsutsumi_h

tsutsumi@password ******* ******************

tsutsumi@active 0 1

ブロック(?)持ち

ユーザーなど、ブロックごとに横持ちする。rowが比較的小さくなり、ブロック毎のcountも出来る。ただし、ブロック内しか検索できない



tsutsumi@20110524

@key tsutsumi@20110524 空

tsutsumi@20110524

@username tsutsumi 空

tsutsumi@20110525

@key 空 tsutsumi@20110525

tsutsumi@20110525

@username 空 tsutsumi_h

ナナメ持ち一つのキー毎に別のカラム名で横持ちする。rowが小さくなり負荷が少ない

RP横持ちを使ったデータ分布

ほぼ均等なデータ分布・稼働率

個々のノード毎の偏りがなくなり、負荷も全体に分散するようになった。

さらに、get_Count()関数の利用が可能になり、range_ghostの呪いからも開放された。

DB1 DB2 DB3

79.82 79.56 79.77 (GB)

ブロック持ちの場合

注意事項

空データの扱い方データが無いカラムには、nullではなく、適当な0xDEADBEEF等を入れないと、 cassandraが左詰めで返してしまう。

key / column a b c d e f g h i j k l m n o

key

username

password

active

ーデータ無し

以上、ありがとうございました。

random partionerのデータモデリング

Technology