• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Random partionerのデータモデリング
 

Random partionerのデータモデリング

on

  • 1,131 views

第16回Cassandra勉強会

第16回Cassandra勉強会

Statistics

Views

Total Views
1,131
Views on SlideShare
1,131
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Random partionerのデータモデリング Random partionerのデータモデリング Presentation Transcript

    • RandomPartitonerのデータモデリング 株式会社ワークスアプリケーションズ 堤 勇人(@2t3)
    • 自己紹介 所属 ワークスアプリケーションズ Incubation Labo4 Webmail お仕事 ウェブメールの開発
    • 自己紹介 所属 ワークスアプリケーションズ Incubation Labo4 Webmail お仕事 ウェブメールの開発 ・・・という名義で最先端技術を試す実験場
    • Webmail AP: jetty DB: cassandra, hbase 全てクラウド (AWS)で動作
    • 今回の達成目標 1. CRUDが存在するデータを扱う DELETEが存在する。 2. BETWEEN検索が可能 例えば、このユーザーの3月~5月の データ、という検索をしたい。 3. 余剰リソースを少なく 低予算。
    • 前提知識:普通のデータモデリング いわゆるRDB的な 例えば、Accountデータキー / カラム username(key) passwordtsutsumi_h tsutsumi_h ********yutuki_r yutuki_r **********test_data test_data ******
    • RDBを使え?
    • RDBを使え?知らん!批判は断る!いやいや、分かってる分かってるんだ。最初から動的なウェブアプリケーションにCassandraなんて無理だし。アトミック操作も無いしね。件数表示とかすごい勢いでズレるし。それは分かっていながら、敢えて、そう敢えてのチャレンジなのですよ。本当はlike検索とかしたい。超したい。気軽にインデックスとか貼りたい。でも最先端技術使うって名目なんだもの。
    • もう一度、今回の達成目標 1. CRUDが存在するデータを扱う DELETEが存在する。 2. BETWEEN検索が可能 例えば、このユーザーの3月~5月の データ、という検索をしたい。 3. 余剰リソースを少なく 低予算。
    • 案1:人工キーを利用するキー / カラム username password1 tsutsumi_h ********2 yutuki_r **********3 test_data ****** 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
    • 案1:人工キーを利用するキー / カラム username password1 tsutsumi_h ********2 yutuki_r **********3 test_data ****** 2,3は良いが、1で問題が起こる DELETEが発生すると、キーに抜け ができ、パフォーマンスが落ちる
    • 案1:人工キーを利用するキー / カラム username password1 tsutsumi_h ********2 yutuki_r **********3 test_data ****** 2,3は良いが、1で問題が起こる DELETEが発生すると、キーに抜け ができ、パフォーマンスが落ちる
    • 案2:OrderPreservingPartitioner yutuki_rtsutsumi_h node node node test_data 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
    • 案2:OrderPreservingPartitioner yutuki_rtsutsumi_h node node node test_data 1,2は良いが、3が微妙 データの偏りが発生し、仕事をあま りしないノードが出来る
    • 案2:OrderPreservingPartitioner yutuki_rtsutsumi_h node node node test_data 1,2は良いが、3が微妙 データの偏りが発生し、仕事をあま りしないノードが出来る
    • OPPを使った場合のデータ分布 稼働率が全体で50%以下 仕事をしないノードは仕事をする ノードの25%以下しか働かない。 しかもこの余剰分は他が溢れた時に 活かされることはない。
    • 前提知識:RandomPartitioner Columnについては検索ができる 例えば、p~zまでのカラム名を抽出キー / カラム username(key) … passwordtsutsumi_h tsutsumi_h … ********yutuki_r yutuki_r … **********test_data test_data … ******
    • 案3:RPを使って横持ちindex化key suzuki tamura tsutsumi urata wakui yutuki zhag 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
    • 案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:じゃあ全データ横持ちにするkey suzuki tamura tsutsumi urata wakui yutuki zhagusername suzuki tamura tsutsumi urata wakui yutuki zhagpassword ***** ***** *** ****** ****** **** **** active 1 0 0 1 1 1 1 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
    • 案4:じゃあ全データ横持ちにするkey suzuki tamura tsutsumi urata wakui yutuki zhagusername suzuki tamura tsutsumi urata wakui yutuki zhagpassword ***** ***** *** ****** ****** **** **** active 1 0 0 1 1 1 1 1,2,3を満たす さらにはcassandraのget_count() も使えるように!
    • 案4:じゃあ全データ横持ちにするkey suzuki tamura tsutsumi urata wakui yutuki zhagusername suzuki tamura tsutsumi urata wakui yutuki zhagpassword ***** ***** *** ****** ****** **** **** active 1 0 0 1 1 1 1 1,2,3を満たす さらにはcassandraのget_count() も使えるように!
    • 横持ちの仕方には色々あるkey / column tsutsumi@20110524 tsutsumi@20110525key tsutsumi@20110524 tsutsumi@20110525username tsutsumi tsutsumi_hpassword ******* ******************active 0 1 完全横持ち 全てのデータが、column名ごとに 横に入る。自由に検索が出来るが、 rowが大きくなる。
    • 横持ちの仕方には色々あるkey / column tsutsumi@20110524 tsutsumi@20110525tsutsumi@key tsutsumi@20110524 tsutsumi@20110525tsutsumi@username tsutsumi tsutsumi_htsutsumi@password ******* ******************tsutsumi@active 0 1 ブロック(?)持ち ユーザーなど、ブロックごとに横持ち する。rowが比較的小さくなり、 ブロック毎のcountも出来る。 ただし、ブロック内しか検索できない
    • 横持ちの仕方には色々あるkey / column tsutsumi@20110524 tsutsumi@20110525tsutsumi@20110524 tsutsumi@20110524 空@keytsutsumi@20110524 tsutsumi 空@usernametsutsumi@20110525 空 tsutsumi@20110525@keytsutsumi@20110525 空 tsutsumi_h@username ナナメ持ち 一つのキー毎に別のカラム名で横持ち する。rowが小さくなり負荷が少ない
    • RP横持ちを使ったデータ分布ブロック持ちの場合 DB1 DB2 DB3 79.82 79.56 79.77 (GB) ほぼ均等なデータ分布・稼働率 個々のノード毎の偏りがなくなり、 負荷も全体に分散するようになった。 さらに、get_Count()関数の利用が 可能になり、range_ghostの呪いから も開放された。
    • RP横持ちを使ったデータ分布ブロック持ちの場合 DB1 DB2 DB3 79.82 79.56 79.77 (GB) ほぼ均等なデータ分布・稼働率 個々のノード毎の偏りがなくなり、 負荷も全体に分散するようになった。 さらに、get_Count()関数の利用が 可能になり、range_ghostの呪いから も開放された。
    • 注意事項key / column a b c d e f g h i j k l m n okeyusernamepasswordactive ー データ無し 空データの扱い方 データが無いカラムには、nullではなく、 適当な0xDEADBEEF等を入れないと、 cassandraが左詰めで返してしまう。
    • 以上、ありがとうございました。