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

552 vues

Publié le

GMOインターネット次世代システム研究室の勉強会発表資料。
2013年3月に作成。

Publié dans : Internet
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
552
Sur SlideShare
0
Issues des intégrations
0
Intégrations
44
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

  1. 1. 1 HBaseスキーマ設計のポイント 2013.3 松井
  2. 2. 2 HBaseで SNSの データストレージ やりたいこと
  3. 3. 3 SNSによくある問題 ユーザデータ の肥大化 スケールアウト しない パフォーマンス 悪化
  4. 4. 4 • 優れた書き込み・読み出し性能 • 自動シャーディング(データ分散) • 自動フェイルオーバー(障害復旧) • 行レベルでのアトミック性の保証 (更新の一貫性) HBase の優れた点のおさらい
  5. 5. 5 HBase 特有のスキーマ設計
  6. 6. 6 SNSタイムラインの機能要件は? 自分+友達の 投稿を表示 最新投稿順に 並べたい 指定件数で 次へ次へ
  7. 7. 7 結論、HBase でのタイムラインの テーブル設計はこうなった Rowkey TLのユーザID + リバースtimestamp + 投稿したユーザID ColumnFamily:Qualifier manga : title タイトル : nickname ニックネーム : like_count いいね数 : koma_count コメント数
  8. 8. 8 デモ
  9. 9. 9 RDBじゃない! 理解のポイント
  10. 10. 10 1. JOINができない 2. 並べ替えができない RDBではないことによる制約
  11. 11. 11 JOINと並べ替えができる場合 User Manga Friend JOIN +並べ替え
  12. 12. 12 JOINできない = 同じデータをコピーして保持 User Manga Friend TimeLine
  13. 13. 13 • 行レベルでのアトミック性の保証 - 同じRowkeyでの更新状態の一貫性。 - 他のKVS(Cassandra、MongoDBなど)に比べて データの一貫性と速度を両立。 • INDEXが1箇所にだけある - Rowkeyには検索インデックス RDBに近いところ
  14. 14. 14 INDEXが1箇所 • データは以下の順でソートされて格納されている Rowkey ColumnFamily Qualifier Timestamp
  15. 15. 15 1. JOIN&並べ替えができない → 非正規化&複製 2. INDEXが1箇所 → Rowkeyで検索 Hbase の特徴 まとめ
  16. 16. 16 RowKeyを活かす。 いいたいこと = RowKey だけで 検索できるようにする!
  17. 17. 17 • タイムラインの要件 1.指定した件数の自分+友達のデータを取得できる。 (クエリではユーザIDと件数を指定する) 2.最新順で並んでいる。 要件を考えてからRowkeyを設計する
  18. 18. 18 • auto increment しない! ( = 意味のないキーはつくらない) • フィルターしない!中身は見ない! (カラム単位のインデックスは使えないので☓) RDBのノウハウを下手に利用しない
  19. 19. 19 •レンジSCAN •リバースTimestamp Rowkeyの検索手法
  20. 20. 20 SCAN ( Java API ) Rowkey の範囲検索 ユーザIDをPrefixにすることで、 対象のデータの範囲の StartRow / StopRow を 決定できる。 ユーザID をキーにした検索
  21. 21. 21 リバースtimestamp 最新投稿を上にソートするテクニック (新しい時間が小さい値になる) Long.MAX_VALUE - 現在時間 (9223372036854775807) 最新順に並べる
  22. 22. 22 100 _ 9223370672552094052 _ 1 100 _ 9223370672551411750 _ 52 100 _ 9223370672550612514 _ 100 101 _ 9223370672551093583 _ 79 101 _ 9223370672551093583 _ 7 101 _ 9223370672550612514 _ 100 102 _ 9223370672551093583 _ 79 103… 実際のデータ
  23. 23. 23 テーブル設計まとめ 「DDI」 - Denormalization (非正規化) -Duplication (複製) -Intelligent Keys (インテリジェントキー)
  24. 24. 24 性能評価
  25. 25. 25 どのぐらいスピードが出るのか? • 書き込みの速度 • 読み込みの速度 しりたいこと
  26. 26. 26 友達のタイムラインに猛烈にコピーしまくる timeline 複製の懸念 POST timeline timeline timeline timeline timeline timeline 投稿 + timeline timeline timeline timeline
  27. 27. 27 この設計で ちゃんと速度出るの? 疑問
  28. 28. 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 4個、ディスク容量 320 GB、メモリ容量 16GB 評価環境
  29. 29. 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. 30. 30 全体レコード数 平均応答ミリ秒 1000件 0 ~ 4ms 250万件 0 ~ 4ms 3億5000万件 0 ~ 4ms TIMELINEテーブル へ 単発のPUT (書き込み)
  31. 31. 31 タイムラインテーブルへバッチ PUT (同時書き込み=同時コピー数) 全体レコード数 友達数 平均応答ミリ秒 3億5000万件 10人 0 ~ 4ms 1000人 70 ~ 120ms 10000人 500 ~ 1200ms
  32. 32. 32 SCAN(レンジ検索) 全体レコード数 自分の レコード数 平均応答 ミリ秒 3億5000万件 10件 0 ~ 10ms 1000件 0 ~ 10ms 10000件 0 ~ 10ms
  33. 33. 33 初回のSCAN(リージョンルックアップ)は遅い 全体レコード数 平均応答ミリ秒 10万件 0 ~ 10ms 8000万件 50~90ms 3億5000万件 100 ~ 500ms
  34. 34. 34 まとめ
  35. 35. 35 • Row Key を第一に考えて行う • フィルターを使わずに STARTROWとエンドキーを指定したスキャンで シンプルに行うことが有効 設計のまとめ
  36. 36. 36 • 読み書きはレコードの母数に関係なく速い • リージョンの初回ルックアップに多少時間がかかる 性能評価のまとめ
  37. 37. 37 ご清聴ありがとうございました

×