Random partionerのデータモデリング

1,363 views
1,303 views

Published on

第16回Cassandra勉強会

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,363
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Random partionerのデータモデリング

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

×