スケーラブルなシステムのための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


17

HBaseを使わない

(必要がない限り)


18

HBase
にはない機能がいっぱい

•  JOINがない

•  セカンダリインデックスも当然ない

•  テーブル間トランザクションがない

•  etc.

RDBMSは超優秀だし最近はハードウェアも安いので

必要ない限りはRDBMS使いましょう

19

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

20


大量のデータがあるとき！

21


大量のデータがあるとき！

•  サーバ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



リージョン1
リージョン2

リージョン1

[r1,
r4)

リージョン2
リージョンはスレーブノード(リージョ
[r4,
r6)
ンサーバ)に別々に配置される

42



リージョン1
リージョン2

リージョン1

MemStore1
MemStore2
MemStore3
MemStore4

[r1,
r4)

リージョン2

[r4,
r6)

43



列ファミリごとにメモリストア(MemStore)

リージョン1
が作られる

リージョン2

リージョン1

MemStore1
MemStore2
MemStore3
MemStore4

[r1,
r4)

書き込みを行う場合、先行書き込みログ(WAL)に書き込ん
だあとはこのMemStoreに書き込まれる

リージョン2

[r4,
r6)
MemStoreはメモリ上にしか存在しない

メモリストアはリージョン☓列ファミリごとに存在する

44



リージョン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が存在する


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:c2:100:‘php’



ストアファイルはリージョン☓列ファミリで作る

列ファミリはスキーマ定義時に一緒に定義する

53

HBase

行キー:列ファミリ:列:タイムスタンプ:値

これらが全て1つのデータで格納されている

cf1
cf2



r1:cf1:c2:100:‘php’

値

タイムスタンプ

列

行キー
列ファミリ

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

w

blog.cloudera.com
com.cloudera.blog
1_com.cloudera.blog

元データ
プ

1358736114
2936231182

1358736150
ハッシュを付与することで配置を分散させる

2936231146

ソルトを使うことでリージョンサーバ間でより均等になる
ように分散させることも可能

72


元データ
これは未ソートの状態

ハッシュ付与
ソルト

(ドメイン名)

www.cloudera.com

実際にはソートされ、元データと逆になる

com.cloudera.www

(新しいタイムスタンプが一番上に来る)

w

blog.cloudera.com
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

まとめ

•  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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

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

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

Más de Cloudera Japan

Más de Cloudera Japan (20)

Último

Último (9)

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