hbase workshop in tokyo #001

HBase ワークショップ (第１回）アプリケーション設計１

by Tatsuya Kawano <http://twitter.com/tatsuya6502>2011年5月20日

1

2011年5月22日日曜日

[ ]自己紹介 Twitter: @tatsuya6502個人研究として、2009年秋から HBase を評価

ここ５年間は金融系のソフトウェアエンジニアをしてました

20年ほど前は TANDEM という分散コンピュータのシステム管理者をしてました

グラフィックデザイナーでもある（あった）ニューヨークの美大を卒業し数年間、現地アメリカ企業に勤務

6502は、高校時代に使っていた Apple II のCPU名

HBase エバンジェリスト！

2


[ ]転職しましたジェミナイ・モバイル・テクノロジーズでNOSQLデータベース「Hibari / 雲雀」の開発に関わってます

http://www.geminimobile.jp/

3


[ ]HBaseの英語ドキュメントが日本語に翻訳されました！ (2011年5月2日公開)

あしたのオープンソース研究所http://oss.infoscience.co.jp/

4


[ ]ワークショップの進めかた

5


[ ]全６回5/20(金) アプリケーション設計１

6/16(木) HBaseのアーキテクチャ

7/15(金) OS、ハードウェア、ネットワーク

8/24(水) 運用

9月後半アプリケーション設計２

10月後半テスト、パフォーマンスチューニング

詳しくは http://j.mp/HBase3 大文字小文字は正確に

6


http://j.mp/HBase3

http://j.mp/HBase3

[ ]本日のお題：アプリケーション設計HBaseの性能特性と HBaseの用途（向き・不向き）

設計上の注意点（テーブル設計、行キーの分散）

API利用上の注意点

Map Reduce利用時の注意点

Twitter ハッシュタグ #hbaseworkshop

7


[ ]HBaseの用途について

8


[ ]HBaseの特徴柔軟なテーブル構造

事前に定義するのはカラムファミリーのみ

強い一貫性

古いデータが見えることがない（縮退時も同様）

大規模データ向け

自動シャーディング

高可用性 (HA) ̶ 故障を優雅に扱う

数十億件を超えたあたりから本領発揮9


[ ]HBaseの特徴インデックスを持たない。行(row) はキー順に格納される

単純化されたクエリ。SQLはサポートしない

テーブルの join はサポートしない

Hadoop Map Reduce (MR) をネイティブにサポート

10


[ ]柔軟なテーブル構造

11http://www.slideshare.net/clehene/hbase-and-hadoop-at-adobe2011年5月22日日曜日

[ ]write性能と read性能のトレードオフ

一般的なRDB： read 性能 > write 性能

HBase： read 性能 < write 性能

（詳しくは、第２回アーキテクチャで説明します）

12


[ ]read 性能を引き出すための設計

行キーの設計（分散させつつ、局所性を持たせる）

テーブルの設計（非正規化）行キーの選択

（後ほどディスカッション）

13


[ ]Facebook メッセージング

14


[ ]Adobe Systems

15


[ ]Adobe Systems

16


[ ]Adobe Systems

17


[ ]Mozilla Soccoro

18


[ ]Mozilla Soccoro

19


[ ]OpenTSDB

20


[ ]OpenTSDB

21


[ ]Lily CMS

22


[ ]HBaseをどんな用途に使いたいですか？

23


[ ]行キーの設計とリージョン分割

24


[ ]データ操作の基本API

put 行を挿入または上書き

get　指定したキーを持つ行を取得

scan　キーの昇順に複数の行を取得（降順は不可）

delete 指定したキーを持つ行を削除

25


[ ]データ操作の基本API (CAS操作)

checkAndPut

checkAndDelete

incrementColumnValue

26


[ ]自動シャーディングテーブルは行キーでソートされている

テーブルサイズが拡大すると、キー空間を自動的に分割する

分割した各領域を「リージョン」と呼ぶ

27

[00 - ) [00 - )

[00 - 62)

[62 - )

[00 - 62)

[62 - )

[00 - 28)

[28 - 62)

[62 - 80)

[80 - )


[ ]自動シャーディングリージョンはクラスター上の各ノードにランダムに配置される（１ノードあたり数十～数百リージョン）

28

[00 - 05)

[00 - 05)

[05 - 12)

[12 - 18)

[18 - 22)

[18 - 22)

[05 - 12)

[12 - 18)


[ ]write時に考慮すること

行キーの値の分布に気を配る（分散させる）

連番だと１つのリージョンにアクセスが集中するのでNG

これをホットスポットと言います

キーの重複に注意

putにはユニーク制約がないので、他の行を上書きしてしまう可能性がある

29


[ ]read時に考慮すること

データの局所性（ローカリティ）が重要

ローカリティを持たせることで、関連する行をまとめて scan できる

ランダムなキー（例：UUID）は避けたほうがよい

検索条件を吟味し、検索に適したキーを設計する

30


[ ]行キーの例Webコンテンツを格納するテーブル

行キー → <逆順のURL>

org.apache.hbase

org.apache.hbase.wiki

org.apache.hbase.wiki.home

org.apache.hbase.wiki.faq

org.apache.zookeeper

31


[ ]行キーの例ユーザーの行動ログ

行キー → <user> - <Long.MAX_VALUE - System.currentTimeMills()> -<event id>

0001122-200023402-010 ・・・10:10:42 am

0001122-200050000-009 ・・・10:08:29 am

0003344-200098881-550

32


[ ]行キーの分散が難しいとき

キーが連番の場合はどうしたらいいのか？（例：伝票番号）

Saltテクニック

行キーの先頭にランダムな文字を追加する例：0～9（10種類）　　A～Z（26種類）

検索では、本来のキーと全ての文字との組み合わせを使う

例：伝票番号 00100を検索0-00100、1-00100、2-00100 ... 　9-00100

33


[ ]バランサーについて

34


[ ]どんな行キーをお使いですか？

35


[ ]テーブルの設計

36


[ ]カラムファミリー

行の一貫性は、カラムファミリーをまたがって保証される

カラムファミリーごとに別のファイルに格納される

ローカリティ

テーブル構造

37


[ ]非正規化により苦手な read を克服

やってはいけないこと

1 + N 回 get問題

テーブルの非正規化

38


[ ]正規化されたテーブル

39http://www.mediawiki.org/wiki/Manual:Database_layout/ja

ページ（記事）変更履歴本文

MediaWiki のテーブル設計（MySQL）

外部リンクサイト内リンク

1

1 0..＊

0..＊


http://www.mediawiki.org/wiki/Manual:Database_layout/ja






[ ]変更履歴と本文は、タイムスタンプで表現

リンクの一覧は、カラム番号で表現

テーブルの非正規化の例

40


[ ]OpenTSDB

Read の性能向上のために複数行の情報を１行にまとめる

例）行：分単位、カラムファミリー：５秒単位

データのパッキング

41


[ ]テーブル設計で工夫している点、悩んでいる点は？

42


[ ]APIでハマりやすいポイント

43


[ ]new Configuration() は重い操作

HTableはスレッドセーフではない

タイムスタンプを指定する時は注意が必要

ビギナーがはまりやすい落とし穴

44


[ ] new Configuration()

45


[ ]HTable はスレッドセーフでない

46


[ ]Delete 操作の怪

47


[ ]タイムスタンプを指定する時の注意

48


[ ]カラムファミリー名・カラム名は短めに

49


[ ]クライアントからの行ロックは推奨しない

リージョンのflushで解除されてしまう

Lily の RowLog ライブラリーがおすすめ

複数行のトランザクション

50


[ ] // === ステップ１ === // 各テーブルの put の準備

Put putA = new Put(テーブルAの行キー); putA.set(テーブルAの更新後の値);

Put putB = new Put(テーブルBの行キー); putB.set(テーブルBの更新後の値);

Put putC = new Put(テーブルCの行キー); putC.set(テーブルCの更新後の値);


51


[ ] // === ステップ２ === // テーブルBとCテーブルの更新内容を RowLog に登録する。 // テーブルAの行の RowLog 用カラムファミリーに登録される。

RowLogMessage walB = wal.putMessage(rowA, Bytes.toBytes("テーブルB"), putB, putA)

RowLogMessage walC = wal.putMessage(rowA, Bytes.toBytes("テーブルC"), putC, putA)


52


[ ]複数行のトランザクション

53

// === ステップ３ === // 更新の前提条件チェックと、テーブルAの更新。 // ここでは、前提条件として、テーブルAの指定したカラムの更新前の値と // 現在の値を比較し、それらが同一なら、他のプロセスと競合していないと // みなして更新する。

boolean tableA_updated = テーブルA.checkAndPut(更新前の値、putA);

boolean tableB_updated = false; boolean tableC_updated = false;


[ ]複数行のトランザクション

54

// === ステップ４ === // 登録しておいたテーブルBとテーブルCの更新内容をすぐに実行する。 if (tableA_updated) { tableB_updated = wal.processMessage(walB); tableC_updated = wal.processMessage(walC); }


[ ]ハマったこと、工夫していること？

55


[ ]Map Reduceでのノウハウ

56


[ ]Hadoop MRとの親和性性能の最適化

HBase は MR の主要なアクセスパターンであるwrite とシーケンシャル read に最適化されている

Yahoo! Cloud Serving Benchmark Report v4.4 http://research.yahoo.com/node/320257


[ ]Hadoop MRとの親和性: HDFS

HBase では、データファイルが HDFS に格納されている

MR から、HFile を直接出力できる

バージョン 0.90 以降は、オンライン中に差分を反映できる

原理上は、オンライン中の HFile の読み込みも可能

HFile の内容は不変なので、安全にアクセスできる

58


hbase workshop in tokyo #001

Technology