Download to read offline
![[db tech showcase Tokyo 2015] A14:Amazon Redshiftの元となったスケールアウト型カラムナーDB徹底解説 その...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015a14actian-matrix-insight-technology-150618094408-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Random partionerのデータモデリング
- 1. RandomPartitonerの データモデリング 株式会社ワークスアプリケーションズ 堤 勇人(@2t3)
- 2. 自己紹介 所属 ワークスアプリケーションズ Incubation Labo4 Webmail お仕事 ウェブメールの開発
- 3. 自己紹介 所属 ワークスアプリケーションズ Incubation Labo4 Webmail お仕事 ウェブメールの開発 ・・・という名義で最先端技術を試す実験場
- 4. Webmail AP: jetty DB: cassandra, hbase 全てクラウド (AWS)で動作
- 5. 今回の達成目標 1. CRUDが存在するデータを扱う DELETEが存在する。 2. BETWEEN検索が可能 例えば、このユーザーの3月～5月の データ、という検索をしたい。 3. 余剰リソースを少なく 低予算。
- 6. 前提知識：普通のデータモデリング いわゆるRDB的な 例えば、Accountデータ キー / カラム username(key) password tsutsumi_h tsutsumi_h ******** yutuki_r yutuki_r ********** test_data test_data ******
- 7.
- 8.
- 9. もう一度、今回の達成目標 1. CRUDが存在するデータを扱う DELETEが存在する。 2. BETWEEN検索が可能 例えば、このユーザーの3月～5月の データ、という検索をしたい。 3. 余剰リソースを少なく 低予算。
- 10. 案1：人工キーを利用する キー / カラム username password 1 tsutsumi_h ******** 2 yutuki_r ********** 3 test_data ****** 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
- 11. 案1：人工キーを利用する キー / カラム username password 1 tsutsumi_h ******** 2 yutuki_r ********** 3 test_data ****** 2,3は良いが、1で問題が起こる DELETEが発生すると、キーに抜け ができ、パフォーマンスが落ちる
- 12. 案1：人工キーを利用する キー / カラム username password 1 tsutsumi_h ******** 2 yutuki_r ********** 3 test_data ****** 2,3は良いが、1で問題が起こる DELETEが発生すると、キーに抜け ができ、パフォーマンスが落ちる
- 13. 案2：OrderPreservingPartitioner yutuki_r tsutsumi_h node node node test_data 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
- 14. 案2：OrderPreservingPartitioner yutuki_r tsutsumi_h node node node test_data 1,2は良いが、3が微妙 データの偏りが発生し、仕事をあま りしないノードが出来る
- 15. 案2：OrderPreservingPartitioner yutuki_r tsutsumi_h node node node test_data 1,2は良いが、3が微妙 データの偏りが発生し、仕事をあま りしないノードが出来る
- 16. OPPを使った場合のデータ分布 稼働率が全体で50%以下 仕事をしないノードは仕事をする ノードの25%以下しか働かない。 しかもこの余剰分は他が溢れた時に 活かされることはない。
- 17. 前提知識：RandomPartitioner Columnについては検索ができる 例えば、p～zまでのカラム名を抽出 キー / カラム username(key) … password tsutsumi_h tsutsumi_h … ******** yutuki_r yutuki_r … ********** test_data test_data … ******
- 18. 案3：RPを使って横持ちindex化 key suzuki tamura tsutsumi urata wakui yutuki zhag 1. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
- 19. 案3：RPを使って横持ちindex化 key suzuki tamura tsutsumi urata wakui yutuki zhag 1,2,3を満たす・・・が indexが壊れた場合に、全てのデータ を一括で読むしか修復の方法が なくなる。
- 20. 案3：RPを使って横持ちindex化 key suzuki tamura tsutsumi urata wakui yutuki zhag 1,2,3を満たす・・・が indexが壊れた場合に、全てのデータ を一括で読むしか修復の方法がなく なる
- 21. 案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. CRUDが存在するデータを扱う 2. BETWEEN検索が可能 3. 余剰リソースを少なく
- 22. 案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() も使えるように！
- 23. 案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() も使えるように！
- 24. 横持ちの仕方には色々ある key / column tsutsumi@20110524 tsutsumi@20110525 key tsutsumi@20110524 tsutsumi@20110525 username tsutsumi tsutsumi_h password ******* ****************** active 0 1 完全横持ち 全てのデータが、column名ごとに 横に入る。自由に検索が出来るが、 rowが大きくなる。
- 25. 横持ちの仕方には色々ある 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も出来る。 ただし、ブロック内しか検索できない
- 26. 横持ちの仕方には色々ある key / column tsutsumi@20110524 tsutsumi@20110525 tsutsumi@20110524 tsutsumi@20110524 空 @key tsutsumi@20110524 tsutsumi 空 @username tsutsumi@20110525 空 tsutsumi@20110525 @key tsutsumi@20110525 空 tsutsumi_h @username ナナメ持ち 一つのキー毎に別のカラム名で横持ち する。rowが小さくなり負荷が少ない
- 27. RP横持ちを使ったデータ分布 ブロック持ちの場合 DB1 DB2 DB3 79.82 79.56 79.77 (GB) ほぼ均等なデータ分布・稼働率 個々のノード毎の偏りがなくなり、 負荷も全体に分散するようになった。 さらに、get_Count()関数の利用が 可能になり、range_ghostの呪いから も開放された。
- 28. RP横持ちを使ったデータ分布 ブロック持ちの場合 DB1 DB2 DB3 79.82 79.56 79.77 (GB) ほぼ均等なデータ分布・稼働率 個々のノード毎の偏りがなくなり、 負荷も全体に分散するようになった。 さらに、get_Count()関数の利用が 可能になり、range_ghostの呪いから も開放された。
- 29. 注意事項 key / column a b c d e f g h i j k l m n o key username password active ー データ無し 空データの扱い方 データが無いカラムには、nullではなく、 適当な0xDEADBEEF等を入れないと、 cassandraが左詰めで返してしまう。
- 30.