random partionerのデータモデリング
DESCRIPTION
第16回Cassandra勉強会TRANSCRIPT
株式会社ワークスアプリケーションズ
堤 勇人(@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検索とかしたい。超したい。気軽にインデックスとか貼りたい。でも最先端技術使うって名目なんだもの。
1. CRUDが存在するデータを扱う
もう一度、今回の達成目標
2. BETWEEN検索が可能
3. 余剰リソースを少なく
DELETEが存在する。
例えば、このユーザーの3月~5月のデータ、という検索をしたい。
低予算。
案1:人工キーを利用する
キー / カラム username password
1 tsutsumi_h ********
2 yutuki_r **********
3 test_data ******
1. CRUDが存在するデータを扱う
2. BETWEEN検索が可能
3. 余剰リソースを少なく
案1:人工キーを利用する
キー / カラム username password
1 tsutsumi_h ********
2 yutuki_r **********
3 test_data ******
2,3は良いが、1で問題が起こる
DELETEが発生すると、キーに抜けができ、パフォーマンスが落ちる
案1:人工キーを利用する
キー / カラム username password
1 tsutsumi_h ********
2 yutuki_r **********
3 test_data ******
2,3は良いが、1で問題が起こる
DELETEが発生すると、キーに抜けができ、パフォーマンスが落ちる
案2:OrderPreservingPartitioner
1. CRUDが存在するデータを扱う
2. BETWEEN検索が可能
3. 余剰リソースを少なく
node
node
node
tsutsumi_h yutuki_r
test_data
1,2は良いが、3が微妙
データの偏りが発生し、仕事をあまりしないノードが出来る
案2:OrderPreservingPartitioner
node
node
node
tsutsumi_h yutuki_r
test_data
案2:OrderPreservingPartitioner
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化
1. CRUDが存在するデータを扱う
2. BETWEEN検索が可能
3. 余剰リソースを少なく
key suzuki tamura tsutsumi urata wakui yutuki zhag
案3:RPを使って横持ちindex化
key suzuki tamura tsutsumi urata wakui yutuki zhag
1,2,3を満たす・・・が
indexが壊れた場合に、全てのデータを一括で読むしか修復の方法が なくなる。
案3:RPを使って横持ちindex化
key suzuki tamura tsutsumi urata wakui yutuki zhag
1,2,3を満たす・・・が
indexが壊れた場合に、全てのデータを一括で読むしか修復の方法がなくなる
案4:じゃあ全データ横持ちにする
1. CRUDが存在するデータを扱う
2. BETWEEN検索が可能
3. 余剰リソースを少なく
key suzuki tamura tsutsumi urata wakui yutuki zhag
username suzuki tamura tsutsumi urata wakui yutuki zhag
password ***** ***** *** ****** ****** **** ****
active 1 0 0 1 1 1 1
案4:じゃあ全データ横持ちにする
key suzuki tamura tsutsumi urata wakui yutuki zhag
username suzuki tamura tsutsumi urata wakui yutuki zhag
password ***** ***** *** ****** ****** **** ****
active 1 0 0 1 1 1 1
1,2,3を満たす
さらにはcassandraのget_count()も使えるように!
案4:じゃあ全データ横持ちにする
key suzuki tamura tsutsumi urata wakui yutuki zhag
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が大きくなる。
横持ちの仕方には色々ある
key / column tsutsumi@20110524 tsutsumi@20110525
tsutsumi@key tsutsumi@20110524 tsutsumi@20110525
tsutsumi@username tsutsumi tsutsumi_h
tsutsumi@password ******* ******************
tsutsumi@active 0 1
ブロック(?)持ち
ユーザーなど、ブロックごとに横持ちする。rowが比較的小さくなり、 ブロック毎のcountも出来る。 ただし、ブロック内しか検索できない
横持ちの仕方には色々ある
key / column tsutsumi@20110524 tsutsumi@20110525
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)
ブロック持ちの場合
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
ー データ無し
以上、ありがとうございました。