Weitere ähnliche Inhalte Ähnlich wie スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w (20) Mehr von Cloudera Japan (20) Kürzlich hochgeladen (10) スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w1. スケーラブルなシステムのための
HBaseスキーマ設計
Cloudera株式会社
カスタマーオペレーションズエンジニア
嶋内
翔
2013年1月21日
1
2. 自己紹介
• 嶋内 翔(しまうち しょう)
• 2011年4月にClouderaの最初の日本人社員として入
社
• カスタマーオペレーションズエンジニアとしてテクニ
カルサポート業務を担当
• email:
sho@cloudera.com
• twi=er:
@shiumachi
2
3. Agenda
• Apache
HBase
とは
• スキーマ設計の話の前に
• HBase
ストレージアーキテクチャ
• スキーマ設計のポイント
3
4. セッション概要
• Hadoop
上で動作する分散ストレージシステム
HBase
を活用するためのスキーマ設計のポイントに
ついて紹介します
• ゴール
• 性能が出る、正しいHBaseのスキーマ設計ができるように
なること
• アンチパターンを知り、誤ったスキーマ設計を避けるよう
になること
4
5. 対象者・レベル
• 対象者
• HBase
の構築・運用担当者
• HBase
アプリケーションの開発者
• 対象レベル:
中級
• Hadoop
(特に
HDFS)
について、アーキテクチャをある程度
理解している
5
6. 本セッションで取り扱わない内容
(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
7. 本セッションで取り扱わない内容
(2)
Hadoop/HBaseの運用・チューニング
Cloudera
Managerを使えば1時間でCDHクラスタの構
築ができ、管理も非常に簡単です
HBaseを使うなら
Cloudera
Enterprise
(CDH
+
Cloudera
Manager)
を選びましょう
ダウンロードはこちら
h=p://www.cloudera.com/downloads/
7
9. HBase
• HDFS
上で動作する NoSQL
• Google
の開発した NoSQL
BigTable
に基づいて作成され
ている
•
HDFS
が苦手とする低レイテンシのアクセスや小さいファ
イルの操作を得意とする
h=p://ja.fotopedia.com/items/flickr-‐1999559141
10. なぜHBaseを使うのか
• シャーディングをサポートしてる
• 自動シャーディング
• コマンド一発で手動シャーディング
• 書き込みが高速で、しかもスケールアウト可能
• データの耐障害性も確保されてる
• これはHadoopのファイルシステムHDFSの機能
12. HBaseのテーブル構造(概要)
• 行キーの一定範囲ごとに別ファイルに分割
• この範囲のことをリージョンという
• 1リージョンには列ファミリの数以上のストアファイルが存在
• ここではかなり簡略化して説明している。詳細は後述
列ファミリ1
列ファミリ2
リージョン
ストアファイル
ストアファイル
a
-‐
c
リージョン
ストアファイル
ストアファイル
d
-‐
f
リージョン
ストアファイル
ストアファイル
h
-‐
j
13. HBaseの構成図
※マスタサーバは存在するが、
クライアント
データ通信には使わない
リージョンサーバ
リージョンサーバ
リージョンサーバ
リージョンa
リージョンb
リージョンc
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
ブロック1
ブロック1
ブロック1
ブロック2
ブロック2
ブロック2
ブロック3
ブロック3
ブロック3
14. HBaseの動作概要
クライアント
HDFSと同様、クライアントはマスタを介さず
直接リージョンサーバと通信する
リージョンサーバ
リージョンサーバ
リージョンサーバ
リージョンサーバはHDFSのクライアントとして
データノードと通信する
リージョンa
リージョンb
リージョンc
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
データノード
ブロック1
ブロック1
ブロック1
ブロック2
ブロック2
ブロック2
ブロック3
ブロック3
ブロック3
18. HBaseを使わない
(必要がない限り)
h=p://ja.fotopedia.com/items/flickr-‐1999559141
18
19. HBase
にはない機能がいっぱい
• JOINがない
• セカンダリインデックスも当然ない
• テーブル間トランザクションがない
• etc.
RDBMSは超優秀だし最近はハードウェアも安いので
必要ない限りはRDBMS使いましょう
19
22. じゃあどんなときにHBaseを使えばいいの?
大量のデータがあるとき!
• サーバ1台のメモリに載りきらない
• サーバ1台のディスクに入りきらない
• etc.
• 最近のサーバだとメモリ100GB、ディスク10TB(RAID5)ぐ
らいなら余裕のはず
• Hadoopを既に使っている人は大量データがあるはずな
ので利用の検討はあり
22
23. HBaseとRDBの比較
RDB
HBase
• RDBMSが高機能
• 非正規化前提
• きちんとDB設計すればほ • 特定のクエリに特化して
ぼどんなクエリにも対応 設計
可能
• 用途を絞ってしまえば、
• スケールしない
容量や読み書きがスケー
• ストレージ容量
ルするので非常に強力
• 書き込み
• Hadoop
との連携がしや
すい
23
26. しかし、設計段階でも物理表現を知ることは
重要
• HBaseはユースケースやアクセスパターンに基づい
て自動的に最適化したりしない
• HBaseの実装を知らないと正しいスキーマ設計がで
きない
• このセッションではまずHBaseのストレージアーキテ
クチャを理解し、その上でスキーマ設計の話に移る
26
28. HBaseテーブル
列ファミリA
列ファミリB
列a
列b
列c
列a
列b
行
r1
リージョン1
行
r2
行
(r3,
A:b)
r3
ver.1
行
リージョン2
r4
行
r5
28
29. HBaseテーブル
• 行と列によるテーブル構造
• 行は一定範囲ごとに「リージョン」という単位で区切られて
いる
• 列は「列ファミリ」という単位でグループ化されている
• セル
=
行と列の交点
• セルはタイムスタンプを持っている
• バージョンとタイムスタンプはほぼ同じ意味
29
30. HBaseテーブル
列ファミリA
列ファミリB
列a
列b
列c
列a
列b
行
r1
リージョン1
行
r2
行
(r3,
A:b)
r3
ver.1
行
リージョン2
r4
行
r5
30
31. HBaseテーブル
列ファミリA
列ファミリB
列a
列b
列c
列a
列b
行
テーブルに対する行、列、そして行と列の交差する部分
r1
のセル
リージョン1
論理的なテーブル構造は基本的にRDBと変わらない
行
r2
行
(r3,
A:b)
r3
ver.1
行
リージョン2
r4
行
r5
31
32. 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
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
33
34. 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. リージョンと列ファミリ
• テーブルは複数のリージョンで構成されている
• リージョン =
一定範囲の行キーの集合
• リージョンは行キーのスタートキーとエンドキーで区分け
される
• それぞれのリージョンは別々のリージョンサーバに割り当
てられている
• 列(カラム)は、列ファミリと列が存在する
• 列ファミリごとに別々の物理ファイルが作成される
• 「列ファミリ:列」の記述を列修飾子というが、これで単に列
ということも多い
35
36. リージョンと列ファミリ
列ファミリA
列ファミリB
列a
列b
列c
列a
列b
行
r1
リージョン1
行
r2
行
(r3,
A:b)
r3
ver.1
行
リージョン2
r4
行
r5
36
37. リージョンと列ファミリ
列ファミリA
列ファミリB
列a
列b
テーブルは複数のリージョンで
列c
列a
列b
行
構成されている
r1
リージョン1
行
r2
行
(r3,
A:b)
r3
ver.1
行
リージョン2
r4
行
r5
37
38. リージョンと列ファミリ
列ファミリA
列ファミリB
列a
列b
列c
列a
列b
行
r1
リージョン1
行
r2
行
(r3,
A:b)
r3
ver.1
行
列ファミリごとに別々の物理ファ
リージョン2
r4
イルに格納される
行
r5
38
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
39
40. リージョンと列ファミリ
リージョンはスタートキーとエンド
列ファミリ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
41. リージョンと列ファミリ
リージョンサーバA
リージョンサーバB
リージョン1
リージョン2
リージョン1
[r1,
r4)
リージョン2
[r4,
r6)
41
42. リージョンと列ファミリ
リージョンサーバA
リージョンサーバB
リージョン1
リージョン2
リージョン1
[r1,
r4)
リージョン2
リージョンはスレーブノード(リージョ
[r4,
r6)
ンサーバ)に別々に配置される
42
43. リージョンと列ファミリ
リージョンサーバA
リージョンサーバB
リージョン1
リージョン2
リージョン1
MemStore1
MemStore2
MemStore3
MemStore4
[r1,
r4)
リージョン2
[r4,
r6)
43
44. リージョンと列ファミリ
リージョンサーバA
リージョンサーバB
列ファミリごとにメモリストア(MemStore)
リージョン1
が作られる
リージョン2
リージョン1
MemStore1
MemStore2
MemStore3
MemStore4
[r1,
r4)
書き込みを行う場合、先行書き込みログ(WAL)に書き込ん
だあとはこのMemStoreに書き込まれる
リージョン2
[r4,
r6)
MemStoreはメモリ上にしか存在しない
メモリストアはリージョン☓列ファミリごとに存在する
44
45. リージョンと列ファミリ
リージョンサーバ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
46. リージョンと列ファミリ
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
47. 論理テーブルから物理ファイルへ
列ファミリ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
48. 論理テーブルから物理ファイルへ
列ファミリ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
49. 論理テーブルから物理ファイルへ
列ファミリ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
50. HBase
テーブルと物理レイアウト
• テーブルでは、辞書順に行をソートしている
• 全ての値は行キー、列ファミリ、列修飾子、タイムス
タンプと一緒に保存される
• テーブルのスキーマは列ファミリのみ定義している
• それぞれの列ファミリは任意の数の列を格納可能
• 列ファミリと異なり、スキーマ定義は不要
• それぞれのセル(行と列の交点)は任意の数のバージョン
を格納可能
• セルは挿入されたときにしか作成されないのでNULLはコ
ストゼロ
• テーブル名以外はすべて
byte[]
として格納される
50
51. 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
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’
52
53. 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
54. 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
56. スキーマ設計
• 最高のパフォーマンスを得るのに正しいスキーマ設
計は不可欠
• HBaseでの正しいスキーマ設計にはストレージアー
キテクチャの知識が不可欠
• これまでのアーキテクチャの説明を踏まえて、ス
キーマ設計のポイントを説明します
56
57. スキーマ設計の前に(再)
• 論理設計までは同じです
• 設計する前に、「どういう問い合わせをしたいか」を
きちんと考えましょう
• ユーザ同士のソーシャルグラフを見たい
• ユーザ単位のメッセージを一括取得したい
• etc.
57
58. 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/finish/22-‐white-‐papers/68-‐cloud-‐data-‐structure-‐
diagramming
58
59. 非正規化
• HBaseにはJOINがない
• JOINなしでエンティティ間のリレーションを表現する
方法は2つ
• 自力でJOINを実装する
• 極めて困難。ていうか無理
• データを非正規化する
• 非正規化
=
2つの論理エンティティで1つの物理表現
を共有すること
59
60. 非正規化の例
Order
Item
id
id
amount
name
customer_id
price
item_id
Customer
普通のリレーショナルモデルの設計
id
これを……
name
60
61. 全部くっつける!
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
62. 非正規化のメリットとデメリット
• メリット
• あらかじめ非正規化しておいたリレーションに関するクエ
リは、たとえ大量のデータであっても超高速に結果が返っ
てくる
• デメリット
• 更新が大変
• 非正規化していないエンティティ同士のリレーションに関
するクエリは、JOINがないので結局できない
• ユースケースの絞り込みが重要
62
63. パフォーマンスとカーディナリティ
行単位でのスキップが可能
タイム
行キー
列ファミリ
列
値
スタンプ
ストアファイル単位でのスキップが可能
パフォーマンスが高い
カーディナリティが高い
63
64. パフォーマンスとカーディナリティ
• 行キーを使うときが一番パフォーマンスが高い
• 列ファミリの選択はスキャン対象のデータの数を減
らす
• 値だけのフィルタはフルスキャンと同じ
• 要するに重い(ネットワーク負荷は減るかもしれないが)
64
65. 値のシフト
r1:cf1:c1:100:‘python’¥x00
r1:cf1:c1‘python’:100:¥x00
r1‘python’:cf1:c1:100:¥x00
• 一つのキーと値は、列ファミリー・列の名前も込みで格
納されている
• だから値を列や行キーにシフトしてもデータサイズは変
わらない
• 値を空にして、意味のある情報を列や行キーに含めると
いう手法もある
65
67. Tall
vs.
Wide
• Tall:
行が多く、列が少ない
• Wide:
行が少なく、列が多い
• Tall
の特長
• Scan
に向いている
• Wide
の特長
• Get
(特定の行のみ取得)に向いている
• HBaseは行単位ならアトミックに処理可能なので、アトミッ
クな処理をしたい場合に有効
67
68. キー設計
シーケンシャルキー
Saltedキー
フィールド昇格キー
ランダムキー
シーケンシャルリードのパフォーマンスが高い
書き込みパフォーマンスが高い
68
69. キー設計
• アクセスパターンに基づき、シーケンシャルキーかラ
ンダムキーのいずれかを選択
• 両方使う場合もある
• アーキテクチャの限界を乗り越える
• どちらも使いどころを間違えなければ有用
• シーケンシャルキーにはバルクインポートを使う
• ランダムアクセスをしたい場合にはランダムキーを使う
69
70. 具体的なキー設計の手法
• リバースドメイン
• com.cloudera.www,
com.cloudera.blog,
etc.
• サイトごとの行キーが近くなる、つまりレンジスキャンがしやすくなる
• ハッシュ付与
• データをばらつかせるのに有効
• 例:
MD5(逆ドメイン)
+
逆ドメイン
• ソルト
• 単にハッシュをとるのではなく、リージョンサーバの数で割ってmodを
とる
• リージョンサーバ単位で正確に均等にしたい場合に便利
• リバースタイムスタンプ
• LONG_MAX
-‐
タイムスタンプ
• 降順にすることで、一番最近のデータが一番上に来るようにする
70
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
71
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
ソルトを使うことでリージョンサーバ間でより均等になる
ように分散させることも可能
72
73. 具体的なキー設計の手法
元データ
これは未ソートの状態
リバースドメイン
ハッシュ付与
ソルト
(ドメイン名)
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
74. キー設計の例:
カウンタ
• ドメイン毎、URL毎のカウンタを保存する
• HBase
のインクリメント(アトミックな
read-‐modify-‐write
)機
能を使う
• それぞれの行は一つのドメインあるいはURL
• 列は特定のメトリクスのカウンタ
• 列ファミリは時間範囲のグループカウンタとして使う
• 列ファミリレベルでTTL(生存期間)を設定して、一定期間経過後に
メトリクスが削除されるようにしてストレージ領域を節約
• 例:
“Daily
Counters”
(日次カウンタ)
列ファミリには2週間のTTLを
設定
74
75. キー設計の例:
カウンタ
• ドメインの行キー
=
MD5(リバースドメイン)
+
リバー
スドメイン
• 行キーを分散させ、バラバラのリージョンに配置されるよ
うにする
• ロードバランシングの方法として有効
• URLの行キー
=
MD5(リバースドメイン)
+
リバースド
メイン
+
URL
ID
• 行キーのサイズ節約のため、URL
ID
を作っておいてそれ
を使った方がいい
75
76. 列修飾子設計
(1)
列ファミリ
• データは複数のストレージファイルに保存されることを考
慮する
• 列ファミリは少なめにする
• HFileの数
=
リージョン
*
列ファミリ
*
(3〜6ぐらい)
• HBase
は全ての HFile
をオープンする
• つまり列ファミリが多いと必要なファイルディスクリプタの数が
増大する
• 多くても3つぐらい。1つだけで運用する場合もあり
• アクセスパターンが全く異なるデータがあるときに使うの
が◯
• 例1:
メタデータ
+
実データ
• 例2:
日次データ
+
週次データ
+
月次データ
76
77. 列修飾子設計 (2)
名前
• 列ファミリ・列の名前は短い方がいい
• 列修飾子全体が1行ごとに保存されるため、ここが長いと
データ量が大幅に増加する
77
78. 列修飾子設計の例:
カウンタ
• 列ファミリ
• 1時間毎のカウンタ
• 日次カウンタ
• 総計カウンタ
• 列名は分かりやすく日本語にしているのでそのまま使わないよう
に
時間毎
日次
総計
実際にはこんな感じでいい
h
(hourlyの略)
d
(dailyの略)
t
(totalの略)
78
79. 列修飾子設計の例:
カウンタ
• 単位時間のメトリックのカウンタを配置
• <時間><メトリック>
時間毎
18時合計
18時東京
18時大阪
19時合計
19時東京
……
日次
1/1合計
1/1東京
1/1大阪
1/2合計
1/2東京
……
79
80. ホットスポット
• HBaseは1リージョンは1リージョンサーバが担当する
• だから特定のリージョンだけにアクセスが集中する
ということがありうる(ホットスポット)
• シーケンシャルキーだとホットスポットができるかも
しれない
• 午前中のキーノートでもNHN
Japanの中村さんが
LINEでホットスポットが発生していたという事例を紹
介していた
• h=p://www.slideshare.net/naverjapan/storage-‐
infrastructure-‐using-‐hbase-‐behind-‐line-‐messages
80
81. ホットスポットの例:タイムスタンプを使う
• <タイムスタンプ><他のキー>:
{
列ファミリ:
{
列修飾
子:
{
タイムスタンプ
:
値
}}}
• これはダメな例
• ホットスポットが発生する
cf1
行キーの頭がほとんど同じ
cf1:c1
cf1:c2
これだと、ある時間帯に1つのRSだけが
1358682406_metricA
処理をすることになる
1358682406_metricB
1358682407_metricA
1358682410_metricA
81
82. ホットスポットの例:タイムスタンプを使う
解決策1:
タイムスタンプをソルトする
(事前にリージョンを分割して別々のRSに割り当てておく)
cf1
cf1:c1
cf1:c2
0_1358682406_metricA
1_1358682200_metricA
4_1358672200_metricB
9_1358662211_metricA
82
83. ホットスポットの例:タイムスタンプを使う
解決策2:
<他のキー>を前に持ってくる
cf1
cf1:c1
cf1:c2
metricA_1358682406
metricA_1358682407
metricA_1358682410
metricB_1358682406
83
84. 例:
OpenTSDB
• OpenTSDB
は、メトリクスを保存するための時系列データ
ベース
• h=p://opentsdb.net/
• スキーマは以下のようになっている
• メトリックの種類とタグは行キーに保存されている
• 新しいタイムスタンプによる行キーは定期的に作成
• ホットスポットの解決策2の典型例
メトリクス(列ファミリ)
<時間差分><フラグ>
<時間差分><フラグ>
<メトリック><タイムスタンプ><タグ>
値
値
84
85. 例:
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
87. まとめ
• HBaseにおける正しいスキーマ設計には、ユース
ケースやアクセスパターンと、HBaseの内部構造を
知ることが不可欠です
• 非正規化・インテリジェントキーなど、RDBと異なるテ
クニックを駆使することで、性能をスケールさせるこ
とができます
• 正しくスキーマを設計して、快適なHBaseライフを満
喫しましょう!
87
88. HBase
本日本語訳出ました
• Cloudera
の
Lars
George
が
書いた HBase
のバイブル
• 訳は安心の玉川さん
• レビュー手伝ってました
89. Cloudera
の HBase
トレーニング
HBase
トレーニングではスキーマ設計もあります
今日の話だけでは物足りないという方は今すぐ登録
を!
次回は3/25
-‐
26
開催です
申し込みはこちら
h=p://www.cloudera.co.jp/university/hbase.html
90. CDHコミュニティ・MLの紹介
CDH
ユーザ メーリングリスト(日本語)
cdh-‐user-‐jp@cloudera.org
CDH
の質問についてはこちら
Cloudera
ニュースレター
h=p://www.cloudera.co.jp/newsle=er
Cloudera
に関するニュースをお届けします
CDHの最新情報・使い方なども紹介します
90
91. 宣伝
Cloudera
Managerを使えば1時間でCDHクラスタの構
築ができ、管理も非常に簡単です
HBaseを使うなら
Cloudera
Enterprise
(CDH
+
Cloudera
Manager)
を選びましょう
ダウンロードはこちら
h=p://www.cloudera.com/downloads/
91