Embed Size (px)
Citation preview
1
HBaseスキーマ設計のポイント
2013.3松井
2
HBase でSNS の
データストレージ
やりたいこと
3
SNS によくある問題
ユーザデータの肥大化
スケールアウトしない
パフォーマンス
悪化
4
• 優れた書き込み・読み出し性能
• 自動シャーディング（データ分散）
• 自動フェイルオーバー（障害復旧）
• 行レベルでのアトミック性の保証
（更新の一貫性）
HBase の優れた点のおさらい
5
HBase 特有のスキーマ設計
6
SNS タイムラインの機能要件は？
自分＋友達の投稿を表示
最新投稿順に並べたい
指定件数で次へ次へ
7
結論、 HBase でのタイムラインのテーブル設計はこうなった
RowkeyTL のユーザ ID + リバース timestamp + 投稿したユーザ ID
ColumnFamily： Qualifiermanga : title タイトル : nickname ニックネーム : like_count いいね数 : koma_count コメント数
8
デモ
9
RDB じゃない！
理解のポイント
10
• JOIN ができない• 並べ替えができない
RDB ではないことによる制約
11
JOIN と並べ替えができる場合
User
Manga
FriendJOIN
＋並べ替え
12
JOIN できない ＝ 同じデータをコピーして保持
User
Manga
Friend
TimeLine
13
• 行レベルでのアトミック性の保証 - 同じ Rowkey での更新状態の一貫性。 - 他の KVS （ Cassandra 、 MongoDB など）に
比べて データの一貫性と速度を両立。
• INDEX が 1 箇所にだけある - Rowkey には検索インデックス
RDB に近いところ
14
INDEX が１箇所
• データは以下の順でソートされて格納されている
RowkeyColumnFamily
QualifierTimestamp
15
• JOIN ＆並べ替えができない
→ 非正規化＆複製２． INDEX が１箇所
→ Rowkey で検索
Hbase の特徴 まとめ
16
RowKey を活かす。
いいたいこと
= RowKey だけで検索できるようにする！
17
• タイムラインの要件
１．指定した件数の自分＋友達のデータを取得できる。
（クエリではユーザ ID と件数を指定する）
２．最新順で並んでいる。
要件を考えてから Rowkey を設計する
18
• auto increment しない！ （ = 意味のないキーはつくらない）
• フィルターしない！中身は見ない！ （カラム単位のインデックスは使えない
ので ）☓
RDB のノウハウを下手に利用しない
19
•レンジ SCAN•リバース Timestamp
Rowkey の検索手法
20
SCAN （ Java API ）Rowkey の範囲検索
ユーザ ID を Prefix にすることで、対象のデータの範囲の StartRow ／ StopRow
を決定できる。
ユーザ ID をキーにした検索
21
リバース timestamp
最新投稿を上にソートするテクニック
（新しい時間が小さい値になる）
Long.MAX_VALUE － 現在時間 （ 9223372036854775807 ）
最新順に並べる
22
100 _ 9223370672552094052 _ 1100 _ 9223370672551411750 _ 52100 _ 9223370672550612514 _ 100101 _ 9223370672551093583 _ 79101 _ 9223370672551093583 _ 7101 _ 9223370672550612514 _ 100102 _ 9223370672551093583 _ 79103…
実際のデータ
23
テーブル設計まとめ
「 DDI 」- Denormalization ( 非正規化 )
-Duplication ( 複製 )
-Intelligent Keys ( インテリジェントキー )
24
性能評価
25
どのぐらいスピードが出るのか？
• 書き込みの速度
• 読み込みの速度
しりたいこと
26
友達のタイムラインに猛烈にコピーしまくる
timeline
複製の懸念
POST timeline
timeline
timeline
timeline
timeline
timeline
投稿
＋
timeline
timeline
timeline
timeline
27
この設計で ちゃんと速度出るの？
疑問
28
• HBase/Hadoop には CDH を使用– Cloudera‘s Distribution, including Apache Hadoop 4.2.0-1
• hadoop-2.0.0+922
• hbase-0.94.2+202
• 評価用環境としてアプリクラウドを利用– 仮想サーバー S x 8 台
• 仮想 CPU ４個、ディスク容量 320 GB 、メモリ容量 16GB
評価環境
29
評価環境
IP HDFS (HA/QJM) HBase ZooKeeper Other
10.112.21.20 Apache/AP
10.112.21.21 NameNode JournalNode HMaster ZooKeeper
10.112.21.22 NameNode (stand-by) JournalNode HMaster ZooKeeper
10.112.21.23 JournalNode ZooKeeper JobTracker
10.112.21.24 DataNode RegionServer TaskTracker
10.112.21.25 DataNode RegionServer TaskTracker
10.112.21.26 DataNode RegionServer TaskTracker
10.112.21.27 DataNode RegionServer TaskTracker
30
全体レコード数 平均応答ミリ秒1000 件 0 ～ 4ms
250 万件 0 ～ 4ms
3 億 5000 万件 0 ～ 4ms
TIMELINE テーブル へ 単発の PUT （書き込み）
31
タイムラインテーブルへバッチ PUT （同時書き込み＝同時コピー数）
全体レコード数 友達数 平均応答ミリ秒3 億 5000 万件 10 人 0 ～ 4ms
1000 人 70 ～ 120ms
10000人 500 ～ 1200ms
32
SCAN （レンジ検索）
全体レコード数 自分のレコード数 平均応答
ミリ秒3 億 5000 万件 10 件 0 ～ 10ms
1000 件 0 ～ 10ms
10000 件 0 ～ 10ms
33
初回の SCAN （リージョンルックアップ）は遅い
全体レコード数 平均応答ミリ秒10 万件 0 ～ 10ms
8000 万件 50 ～ 90ms
3 億 5000 万件 100 ～ 500ms
34
まとめ
35
• Row Key を第一に考えて行う
• フィルターを使わずに STARTROW とエンドキーを指定したスキャン
で シンプルに行うことが有効
設計のまとめ
36
• 読み書きはレコードの母数に関係なく速い
• リージョンの初回ルックアップに多少時間がかかる
性能評価のまとめ
37
ご清聴ありがとうございました
