スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w

スケーラブルなシステムのための HBaseスキーマ設計 Cloudera株式会社カスタマーオペレーションズエンジニア嶋内翔 2013年1月21日 1

自己紹介 •  嶋内　翔(しまうちしょう) •  2011年4月にClouderaの最初の日本人社員として入社 •  カスタマーオペレーションズエンジニアとしてテクニカルサポート業務を担当 •  email: sho@cloudera.com •  twi=er: @shiumachi 2

Agenda •  Apache HBase とは •  スキーマ設計の話の前に •  HBase ストレージアーキテクチャ •  スキーマ設計のポイント 3

セッション概要 •  Hadoop 上で動作する分散ストレージシステム HBase を活用するためのスキーマ設計のポイントについて紹介します •  ゴール •  性能が出る、正しいHBaseのスキーマ設計ができるようになること •  アンチパターンを知り、誤ったスキーマ設計を避けるようになること 4

対象者・レベル •  対象者 •  HBase の構築・運用担当者 •  HBase アプリケーションの開発者 •  対象レベル: 中級 •  Hadoop (特に HDFS) について、アーキテクチャをある程度理解している 5

本セッションで取り扱わない内容 (1) HDFSの信頼性 •  HBaseはデータの信頼性をファイルシステムに依存しています •  HDFSは十分信頼性が高いです •  数年以上の稼動実績 •  HDFS HA によるSPOFの排除 •  詳細は下記スライドを参照してください •  Cloudera Manager4.0とNameNode-‐HAセミナー資料 •  h=p://www.slideshare.net/Cloudera_jp/cloudera-‐ manager4namenodeha •  CDH4.1オーバービュー(HA機能についての説明があります) •  h=p://www.slideshare.net/Cloudera_jp/cdh41 6

本セッションで取り扱わない内容 (2) Hadoop/HBaseの運用・チューニング Cloudera Managerを使えば1時間でCDHクラスタの構築ができ、管理も非常に簡単です HBaseを使うなら Cloudera Enterprise (CDH + Cloudera Manager) を選びましょうダウンロードはこちら h=p://www.cloudera.com/downloads/ 7

Apache HBase とは 8

HBase •  HDFS 上で動作する NoSQL •  Google の開発した NoSQL BigTable に基づいて作成されている •  HDFS が苦手とする低レイテンシのアクセスや小さいファイルの操作を得意とする h=p://ja.fotopedia.com/items/ﬂickr-‐1999559141

なぜHBaseを使うのか •  シャーディングをサポートしてる •  自動シャーディング •  コマンド一発で手動シャーディング •  書き込みが高速で、しかもスケールアウト可能 •  データの耐障害性も確保されてる •  これはHadoopのファイルシステムHDFSの機能

HBaseのデータ構造キーバリューがソートされて並んでいるタイム行キー列ファミリ列値スタンプ r1 cf1 c1 1000 ‘python’ r1 cf1 c2 1000 ‘php’ r1 cf2 c1 1000 ‘ruby’ r2 cf1 c2 1000 ‘java’

HBaseのテーブル構造(概要) •  行キーの一定範囲ごとに別ファイルに分割 •  この範囲のことをリージョンという •  1リージョンには列ファミリの数以上のストアファイルが存在 •  ここではかなり簡略化して説明している。詳細は後述列ファミリ1 列ファミリ2 リージョンストアファイルストアファイル a -‐ c リージョンストアファイルストアファイル d -‐ f リージョンストアファイルストアファイル h -‐ j

HBaseの構成図 ※マスタサーバは存在するが、クライアントデータ通信には使わないリージョンサーバリージョンサーバリージョンサーバリージョンa リージョンb リージョンc データノードデータノードデータノードデータノードデータノードデータノードデータノードデータノードデータノードブロック1 ブロック1 ブロック1 ブロック2 ブロック2 ブロック2 ブロック3 ブロック3 ブロック3

HBaseの動作概要クライアント HDFSと同様、クライアントはマスタを介さず直接リージョンサーバと通信するリージョンサーバリージョンサーバリージョンサーバリージョンサーバはHDFSのクライアントとしてデータノードと通信するリージョンa リージョンb リージョンc データノードデータノードデータノードデータノードデータノードデータノードデータノードデータノードデータノードブロック1 ブロック1 ブロック1 ブロック2 ブロック2 ブロック2 ブロック3 ブロック3 ブロック3

スキーマ設計の話の前に 15

究極のベストプラクティス、それは…… 16

h=p://ja.fotopedia.com/items/ﬂickr-‐1999559141 17

HBaseを使わない (必要がない限り) h=p://ja.fotopedia.com/items/ﬂickr-‐1999559141 18

HBase にはない機能がいっぱい •  JOINがない •  セカンダリインデックスも当然ない •  テーブル間トランザクションがない •  etc. RDBMSは超優秀だし最近はハードウェアも安いので必要ない限りはRDBMS使いましょう 19

じゃあどんなときにHBaseを使えばいいの? 20

じゃあどんなときにHBaseを使えばいいの? 大量のデータがあるとき！ 21

じゃあどんなときにHBaseを使えばいいの? 大量のデータがあるとき！ •  サーバ1台のメモリに載りきらない •  サーバ1台のディスクに入りきらない •  etc. •  最近のサーバだとメモリ100GB、ディスク10TB(RAID5)ぐらいなら余裕のはず •  Hadoopを既に使っている人は大量データがあるはずなので利用の検討はあり 22

HBaseとRDBの比較 RDB HBase •  RDBMSが高機能 •  非正規化前提 •  きちんとDB設計すればほ •  特定のクエリに特化してぼどんなクエリにも対応設計可能 •  用途を絞ってしまえば、 •  スケールしない容量や読み書きがスケー •  ストレージ容量ルするので非常に強力 •  書き込み •  Hadoop との連携がしやすい 23

RDBとHBaseにおけるスキーマ設計の違い 24

RDBとHBaseにおけるスキーマ設計の違い論理設計まではほぼ同じ •  論理データモデルが間違ってたらこの先の議論は無意味 •  RDBとHBaseの違いは物理表現レベルの話 25

しかし、設計段階でも物理表現を知ることは重要 •  HBaseはユースケースやアクセスパターンに基づいて自動的に最適化したりしない •  HBaseの実装を知らないと正しいスキーマ設計ができない •  このセッションではまずHBaseのストレージアーキテクチャを理解し、その上でスキーマ設計の話に移る 26

HBase ストレージアーキテクチャ 27

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 r5 28

HBaseテーブル •  行と列によるテーブル構造 •  行は一定範囲ごとに「リージョン」という単位で区切られている •  列は「列ファミリ」という単位でグループ化されている •  セル = 行と列の交点 •  セルはタイムスタンプを持っている •  バージョンとタイムスタンプはほぼ同じ意味 29

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 r5 30

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行テーブルに対する行、列、そして行と列の交差する部分 r1 のセルリージョン1 論理的なテーブル構造は基本的にRDBと変わらない行 r2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 r5 31

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, A:b) (r3, A:b) r3 ver.2 ver.1 行リージョン2 r4 行 r5 32

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, AA:b) (r3, :b) (r3, A:b) r3 ver.3 ver.2 ver.1 行リージョン2 r4 行 r5 33

HBaseテーブル列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行セルには複数のバージョンを格 r1 納することができるリージョン1 行 r2 行 (r3, AA:b) (r3, :b) (r3, A:b) r3 ver.3 ver.2 ver.1 行リージョン2 r4 行 r5 34

リージョンと列ファミリ •  テーブルは複数のリージョンで構成されている •  リージョン = 一定範囲の行キーの集合 •  リージョンは行キーのスタートキーとエンドキーで区分けされる •  それぞれのリージョンは別々のリージョンサーバに割り当てられている •  列(カラム)は、列ファミリと列が存在する •  列ファミリごとに別々の物理ファイルが作成される •  「列ファミリ:列」の記述を列修飾子というが、これで単に列ということも多い 35

リージョンと列ファミリ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 r5 36

リージョンと列ファミリ列ファミリA 列ファミリB 列a 列b テーブルは複数のリージョンで列c 列a 列b 行構成されている r1 リージョン1 行 r2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 r5 37

リージョンと列ファミリ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 行 (r3, A:b) r3 ver.1 行列ファミリごとに別々の物理ファリージョン2 r4 イルに格納される行 r5 38

リージョンと列ファミリ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行リージョン1 r2 [r1, r4) 行 (r3, A:b) r3 ver.1 行リージョン2 r4 リージョン2 行 [r4, r6) r5 39

リージョンと列ファミリリージョンはスタートキーとエンド列ファミリA 列ファミリB 列a 列b 列c キーで範囲を決定する列a 列b エンドキーは含まないので注意行 r1 リージョン1 行リージョン1 r2 [r1, r4) 行 (r3, A:b) r3 ver.1 行リージョン2 r4 リージョン2 行 [r4, r6) r5 40

リージョンと列ファミリリージョンサーバA リージョンサーバB リージョン1 リージョン2 リージョン1 [r1, r4) リージョン2 [r4, r6) 41

リージョンと列ファミリリージョンサーバA リージョンサーバB リージョン1 リージョン2 リージョン1 [r1, r4) リージョン2 リージョンはスレーブノード(リージョ [r4, r6) ンサーバ)に別々に配置される 42

リージョンと列ファミリリージョンサーバA リージョンサーバB リージョン1 リージョン2 リージョン1 MemStore1 MemStore2 MemStore3 MemStore4 [r1, r4) リージョン2 [r4, r6) 43

リージョンと列ファミリリージョンサーバA リージョンサーバB 列ファミリごとにメモリストア(MemStore) リージョン1 が作られるリージョン2 リージョン1 MemStore1 MemStore2 MemStore3 MemStore4 [r1, r4) 書き込みを行う場合、先行書き込みログ(WAL)に書き込んだあとはこのMemStoreに書き込まれるリージョン2 [r4, r6) MemStoreはメモリ上にしか存在しないメモリストアはリージョン☓列ファミリごとに存在する 44

リージョンと列ファミリリージョンサーバA リージョンサーバB リージョン1 リージョン2 リージョン1 MemStore1 MemStore2 MemStore3 MemStore4 [r1, r4) HDFS HFile 1 HFile 1 HFile 1 HFile 1 HFile 2 HFile 1 リージョン2 [r4, r6) HFile 1 HFile 3 HFile 1 HFile 4 HFile 1 HFile 1 45

リージョンと列ファミリ MemStoreに対し複数のHFileが存在するリージョンサーバA リージョンサーバB Memstoreからフラッシュされるたびに作成され、リージョン1 リージョン2 コンパクションによってまとめられるリージョン1 MemStore1 MemStore2 MemStore3 MemStore4 [r1, r4) HDFS HFile 1 HFile 1 HFile 1 HFile 1 HFile 2 HFile 1 リージョン2 [r4, rHFileは HDFS 上に格納される 1 6) HFile 3 HFile HFile 1 HFile 4 データブロックの複製や配置は HFile 1 HFile 1 全てHDFS側で管理 (図ではHDFSのレプリカは省略) 46

論理テーブルから物理ファイルへ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行リージョン1 r2 [r1, r4) 行 (r3, A:b) r3 ver.1 行リージョン2 r4 リージョン2 行 [r4, r6) r5 47

論理テーブルから物理ファイルへ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 MemStore 1 MemStore 2 行 (r3, A:b) r3 ver.1 行リージョン2 r4 行 MemStore 3 MemStore 4 r5 48

論理テーブルから物理ファイルへ列ファミリA 列ファミリB 列a 列b 列c 列a 列b 行 r1 リージョン1 行 r2 HFile 1-‐3 HFile 2-‐2 行 (r3, A:b) r3 ver.1 行 HFile 4-‐5 リージョン2 r4 行 HFile 3-‐1 r5 49

HBase テーブルと物理レイアウト •  テーブルでは、辞書順に行をソートしている •  全ての値は行キー、列ファミリ、列修飾子、タイムスタンプと一緒に保存される •  テーブルのスキーマは列ファミリのみ定義している •  それぞれの列ファミリは任意の数の列を格納可能 •  列ファミリと異なり、スキーマ定義は不要 •  それぞれのセル(行と列の交点)は任意の数のバージョンを格納可能 •  セルは挿入されたときにしか作成されないのでNULLはコストゼロ •  テーブル名以外はすべて byte[] として格納される 50

HBase テーブルと物理レイアウト以下のようなテーブルを例に考える cf1:c1 cf1:c2 cf2:c1 cf1:c2 ‘python’ ‘php’ ‘ruby’ r1 ts = 100 ts = 100 ts = 100 r2 ‘scala’ ‘java’ ts = 100 ‘scala’ ts = 100 ‘java’ ts = 90 51

HBase テーブルと物理レイアウトストアファイルにはこのように保存されているストアファイル cf1 ストアファイル cf2 r1:cf1:c1:100:‘python’ r1:cf2:c1:100:‘ruby’ r1:cf1:c2:100:‘php’ r2:cf1:c1:100:‘scala’ r2:cf1:c1:90:‘java’ 52

HBase テーブルと物理レイアウトストアファイル cf1 ストアファイル cf2 r1:cf1:c1:100:‘python’ r1:cf2:c1:100:‘ruby’ r1:cf1:c2:100:‘php’ r2:cf1:c1:100:‘scala’ r2:cf1:c1:90:‘java’ ストアファイルはリージョン☓列ファミリで作る列ファミリはスキーマ定義時に一緒に定義する 53

HBase テーブルと物理レイアウト行キー:列ファミリ:列:タイムスタンプ:値これらが全て1つのデータで格納されているストアファイル cf1 ストアファイル cf2 r1:cf1:c1:100:‘python’ r1:cf2:c1:100:‘ruby’ r1:cf1:c2:100:‘php’ r2:cf1:c1:100:‘scala’ 値 r2:cf1:c1:90:‘java’ タイムスタンプ列行キー列ファミリ 54

スキーマ設計のポイント 55

スキーマ設計 •  最高のパフォーマンスを得るのに正しいスキーマ設計は不可欠 •  HBaseでの正しいスキーマ設計にはストレージアーキテクチャの知識が不可欠 •  これまでのアーキテクチャの説明を踏まえて、スキーマ設計のポイントを説明します 56

スキーマ設計の前に(再) •  論理設計までは同じです •  設計する前に、「どういう問い合わせをしたいか」をきちんと考えましょう •  ユーザ同士のソーシャルグラフを見たい •  ユーザ単位のメッセージを一括取得したい •  etc. 57

DDI(でぃーでぃーあい) •  Denormalizajon(非正規化) •  複数のエンティティのリレーションを一つのテーブルで表現する •  一回の読み込みでそのリレーションに関するデータ取得が可能 •  Duplicajon(複製) •  Intelligent Keys(インテリジェントキー) •  属性の組み合わせを行キーとすることで検索を容易にする •  RDBにおける複合キーのようなもの •  の略 •  詳細は「Cloud Data Structure Diagramming Techniques and Design Pa=erns」を参照 •  h=ps://www.data-‐tacjcs-‐corp.com/index.php/component/ jdownloads/ﬁnish/22-‐white-‐papers/68-‐cloud-‐data-‐structure-‐ diagramming 58

非正規化 •  HBaseにはJOINがない •  JOINなしでエンティティ間のリレーションを表現する方法は2つ •  自力でJOINを実装する •  極めて困難。ていうか無理 •  データを非正規化する •  非正規化 = 2つの論理エンティティで1つの物理表現を共有すること 59

非正規化の例 Order Item id id amount name customer_id price item_id Customer 普通のリレーショナルモデルの設計 id これを…… name 60

全部くっつける！ Order Item id id amount Order name customer_id price item_id order_id order_amount customer_id Customer customer_name id item_id name item_name item_price 61

非正規化のメリットとデメリット •  メリット •  あらかじめ非正規化しておいたリレーションに関するクエリは、たとえ大量のデータであっても超高速に結果が返ってくる •  デメリット •  更新が大変 •  非正規化していないエンティティ同士のリレーションに関するクエリは、JOINがないので結局できない •  ユースケースの絞り込みが重要 62

パフォーマンスとカーディナリティ行単位でのスキップが可能タイム行キー列ファミリ列値スタンプストアファイル単位でのスキップが可能パフォーマンスが高いカーディナリティが高い 63

パフォーマンスとカーディナリティ •  行キーを使うときが一番パフォーマンスが高い •  列ファミリの選択はスキャン対象のデータの数を減らす •  値だけのフィルタはフルスキャンと同じ •  要するに重い(ネットワーク負荷は減るかもしれないが) 64

値のシフト r1:cf1:c1:100:‘python’¥x00 r1:cf1:c1‘python’:100:¥x00 r1‘python’:cf1:c1:100:¥x00 •  一つのキーと値は、列ファミリー・列の名前も込みで格納されている •  だから値を列や行キーにシフトしてもデータサイズは変わらない •  値を空にして、意味のある情報を列や行キーに含めるという手法もある 65

Tall vs. Wide Tall Wide 66

Tall vs. Wide •  Tall: 行が多く、列が少ない •  Wide: 行が少なく、列が多い •  Tall の特長 •  Scan に向いている •  Wide の特長 •  Get (特定の行のみ取得)に向いている •  HBaseは行単位ならアトミックに処理可能なので、アトミックな処理をしたい場合に有効 67

キー設計シーケンシャルキー Saltedキーフィールド昇格キーランダムキーシーケンシャルリードのパフォーマンスが高い書き込みパフォーマンスが高い 68

キー設計 •  アクセスパターンに基づき、シーケンシャルキーかランダムキーのいずれかを選択 •  両方使う場合もある •  アーキテクチャの限界を乗り越える •  どちらも使いどころを間違えなければ有用 •  シーケンシャルキーにはバルクインポートを使う •  ランダムアクセスをしたい場合にはランダムキーを使う 69

具体的なキー設計の手法 •  リバースドメイン •  com.cloudera.www, com.cloudera.blog, etc. •  サイトごとの行キーが近くなる、つまりレンジスキャンがしやすくなる •  ハッシュ付与 •  データをばらつかせるのに有効 •  例: MD5(逆ドメイン) + 逆ドメイン •  ソルト •  単にハッシュをとるのではなく、リージョンサーバの数で割ってmodをとる •  リージョンサーバ単位で正確に均等にしたい場合に便利 •  リバースタイムスタンプ •  LONG_MAX -‐ タイムスタンプ •  降順にすることで、一番最近のデータが一番上に来るようにする 70

具体的なキー設計の手法元データリバースドメインハッシュ付与ソルト (ドメイン名) www.cloudera.com com.cloudera.www 276e_com.cloudera.ww 4_com.cloudera.www w blog.cloudera.com com.cloudera.blog c75d_com.cloudera.blog 1_com.cloudera.blog 元データリバースタイムスタン (タイムスタンプ) プ 1358736114 2936231182 1358736150 2936231146 71

具体的なキー設計の手法元データリバースドメインハッシュ付与ソルト (ドメイン名) www.cloudera.com com.cloudera.www 276e_com.cloudera.ww 4_com.cloudera.www w blog.cloudera.com com.cloudera.blog c75d_com.cloudera.blog 1_com.cloudera.blog 元データリバースタイムスタン (タイムスタンプ) プ 1358736114 2936231182 1358736150 ハッシュを付与することで配置を分散させる 2936231146 ソルトを使うことでリージョンサーバ間でより均等になるように分散させることも可能 72

具体的なキー設計の手法元データこれは未ソートの状態リバースドメインハッシュ付与ソルト (ドメイン名) www.cloudera.com 実際にはソートされ、元データと逆になる com.cloudera.www 276e_com.cloudera.ww 4_com.cloudera.www (新しいタイムスタンプが一番上に来る) w blog.cloudera.com com.cloudera.blog c75d_com.cloudera.blog 1_com.cloudera.blog 元データリバースタイムスタン (タイムスタンプ) プ 1358736114 2936231182 1358736150 2936231146 73

キー設計の例: カウンタ •  ドメイン毎、URL毎のカウンタを保存する •  HBase のインクリメント(アトミックな read-‐modify-‐write )機能を使う •  それぞれの行は一つのドメインあるいはURL •  列は特定のメトリクスのカウンタ •  列ファミリは時間範囲のグループカウンタとして使う •  列ファミリレベルでTTL(生存期間)を設定して、一定期間経過後にメトリクスが削除されるようにしてストレージ領域を節約 •  例: “Daily Counters” (日次カウンタ) 列ファミリには2週間のTTLを設定 74

キー設計の例: カウンタ •  ドメインの行キー = MD5(リバースドメイン) + リバースドメイン •  行キーを分散させ、バラバラのリージョンに配置されるようにする •  ロードバランシングの方法として有効 •  URLの行キー = MD5(リバースドメイン) + リバースドメイン + URL ID •  行キーのサイズ節約のため、URL ID を作っておいてそれを使った方がいい 75

列修飾子設計 (1) 列ファミリ •  データは複数のストレージファイルに保存されることを考慮する •  列ファミリは少なめにする •  HFileの数 = リージョン * 列ファミリ * (3〜6ぐらい) •  HBase は全ての HFile をオープンする •  つまり列ファミリが多いと必要なファイルディスクリプタの数が増大する •  多くても3つぐらい。1つだけで運用する場合もあり •  アクセスパターンが全く異なるデータがあるときに使うのが◯ •  例1: メタデータ + 実データ •  例2: 日次データ + 週次データ + 月次データ 76

列修飾子設計 (2) 名前 •  列ファミリ・列の名前は短い方がいい •  列修飾子全体が1行ごとに保存されるため、ここが長いとデータ量が大幅に増加する 77

列修飾子設計の例: カウンタ •  列ファミリ •  1時間毎のカウンタ •  日次カウンタ •  総計カウンタ •  列名は分かりやすく日本語にしているのでそのまま使わないように時間毎日次総計実際にはこんな感じでいい h (hourlyの略) d (dailyの略) t (totalの略) 78

列修飾子設計の例: カウンタ •  単位時間のメトリックのカウンタを配置 •  <時間><メトリック> 時間毎 18時合計 18時東京 18時大阪 19時合計 19時東京 …… 日次 1/1合計 1/1東京 1/1大阪 1/2合計 1/2東京 …… 79

ホットスポット •  HBaseは1リージョンは1リージョンサーバが担当する •  だから特定のリージョンだけにアクセスが集中するということがありうる(ホットスポット) •  シーケンシャルキーだとホットスポットができるかもしれない •  午前中のキーノートでもNHN Japanの中村さんが LINEでホットスポットが発生していたという事例を紹介していた •  h=p://www.slideshare.net/naverjapan/storage-‐ infrastructure-‐using-‐hbase-‐behind-‐line-‐messages 80

ホットスポットの例:タイムスタンプを使う •  <タイムスタンプ><他のキー>: { 列ファミリ: { 列修飾子: { タイムスタンプ : 値 }}} •  これはダメな例 •  ホットスポットが発生する cf1 行キーの頭がほとんど同じ cf1:c1 cf1:c2 これだと、ある時間帯に1つのRSだけが 1358682406_metricA 処理をすることになる 1358682406_metricB 1358682407_metricA 1358682410_metricA 81

ホットスポットの例:タイムスタンプを使う解決策1: タイムスタンプをソルトする (事前にリージョンを分割して別々のRSに割り当てておく) cf1 cf1:c1 cf1:c2 0_1358682406_metricA 1_1358682200_metricA 4_1358672200_metricB 9_1358662211_metricA 82

ホットスポットの例:タイムスタンプを使う解決策2: <他のキー>を前に持ってくる cf1 cf1:c1 cf1:c2 metricA_1358682406 metricA_1358682407 metricA_1358682410 metricB_1358682406 83

例: OpenTSDB •  OpenTSDB は、メトリクスを保存するための時系列データベース •  h=p://opentsdb.net/ •  スキーマは以下のようになっている •  メトリックの種類とタグは行キーに保存されている •  新しいタイムスタンプによる行キーは定期的に作成 •  ホットスポットの解決策2の典型例メトリクス(列ファミリ) <時間差分><フラグ> <時間差分><フラグ> <メトリック><タイムスタンプ><タグ> 値値 84

例: OpenTSDB 時間の差分を列にとる例) 1358600000 + 1 = 1358600001 +1 +2 +4 metricA_1358600000 10 12 15 metricA_1358600600 11 17 metricB_1358600000 100 105 一定時間ごとに新しい行を作成詳細は h=p://opentsdb.net/misc/opentsdb-‐hbasecon.pdf 85

まとめ 86

まとめ •  HBaseにおける正しいスキーマ設計には、ユースケースやアクセスパターンと、HBaseの内部構造を知ることが不可欠です •  非正規化・インテリジェントキーなど、RDBと異なるテクニックを駆使することで、性能をスケールさせることができます •  正しくスキーマを設計して、快適なHBaseライフを満喫しましょう！ 87

HBase 本日本語訳出ました •  Cloudera の Lars George が書いた HBase のバイブル •  訳は安心の玉川さん •  レビュー手伝ってました

Cloudera の HBase トレーニング HBase トレーニングではスキーマ設計もあります今日の話だけでは物足りないという方は今すぐ登録を！次回は3/25 -‐ 26 開催です申し込みはこちら h=p://www.cloudera.co.jp/university/hbase.html

CDHコミュニティ・MLの紹介 CDH ユーザメーリングリスト(日本語) cdh-‐user-‐jp@cloudera.org CDH の質問についてはこちら Cloudera ニュースレター h=p://www.cloudera.co.jp/newsle=er Cloudera に関するニュースをお届けします CDHの最新情報・使い方なども紹介します 90

宣伝 Cloudera Managerを使えば1時間でCDHクラスタの構築ができ、管理も非常に簡単です HBaseを使うなら Cloudera Enterprise (CDH + Cloudera Manager) を選びましょうダウンロードはこちら h=p://www.cloudera.com/downloads/ 91

スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w

by Cloudera Japan on Jan 21, 2013

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 77

Statistics

スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w Presentation Transcript

https://twitter.com	76
http://tweetedtimes.com	1