Upload
yutuki-r
View
37.763
Download
0
Embed Size (px)
DESCRIPTION
第10回Cassandra勉強会にて発表したスライドに、勉強会後のフィードバックを反映させた物です。
Citation preview
1
CassandraとHBaseの比較をして入門するNoSQL
HN : 豊月(Yutuki)
Twitter : @yutuki_r
中の人。
2
• 本スライド:Ver1.3
• HN : 豊月(Yutuki)
• Twitter : @yutuki_r
• Wiki : http://lunarium.info/arc/
• 今日のハッシュタグ : #casstudy10th
• Google Group : Cassandra勉強会
改訂履歴
• 1.1 公開
• 1.2 誤記修正 Chunk→Tablet
• 1.3 内容を追記、修正しました。
– CAP定理が証明論文が公開
– Cassandraを利用したアプリ「PARTAKE」が公開
– Cassandra勉強会グループと日本Cassandraユーザ会が統合
– Cassandra0.7で実装されるのはVersionedClock
– その他、わかりにくい箇所に説明追加等の修正
3
AGENDA
• NoSQLって何?
• NoSQLとRDBの関係は?
• どうしてNoSQLが必要になったの?
• Database種類多すぎ!わからないよ!
• じゃどんなNoSQLが出てきたの?
• どんな構造をしてるの?
– HBaseについて
– Cassandraについて
– 障害への対応
• 結局どっちを使えばいいの?
4
ABOUT NOSQL
NoSQLって何?
5
NoSQLとは
• Not Only SQLの略称です。
• 意訳:「SQLだけじゃないぜ!」
• 意味1:SQLを利用しないデータベースの事
• 意味2:上記の様なデータベースを積極的に使っていこうという動き、運動を指す。
6
NoSQLはこんなにたくさんあります
7
BigTable
(Google)
HBase (Yahoo!)
SimpleDB
(Amazon)
Dynamo
(Amazon)
ROMA
(楽天)
Cassandra
(FaceBook) CouchDB
Kai
(goo)
BerkeleyDB
(Oracle)
Flare
(Gree) MongoDB Kumofs
TokyoTyrant
(mixi)
Velocity
(Microsoft)
Voldemort
(Linkdin)
WAS eXtremeScale
(IBM)
NoSQLの特徴
ノード数に
素直に比
例する性能
ノード数に
比例しない
運用コスト
伸縮自在 障害耐性
8
• RDBと比べて利用目的や利用範囲を絞っている
• RDBが搭載している機能を省いている
DATA STORE CONCEPT
NoSQLとRDBの関係は?
9
10
DataStore
Database FileSystem
11
DataStore
Database
【FileSystem】
NTFS
ext4
XFS
UDF
Google FileSystem
Hadoop Distributed FileSystem
12
DataStore
Database
FS
【RDB】 Oracle
DB2
MySQL
SQLite
SQL Server
PostgreSQL
JavaDB
SQL
13
DataStore
Database
FS
SQL 【NoSQL】
KeyValueStore
列指向型 Database Document Database
RDB
14
DataStore
Database
FS
SQL NoSQL
RDB
【KeyValueStore】 Dynamo
Memcached
Voldemort
【列指向型Database】 BigTable
HBase
Cassandra
狭義のKVS、広義のKVS
• KVSの構造
15
Key Value
狭義のKVS、広義のKVS
• 列指向型Databaseの構造
16
Key CF Column TS Value
Key / CF / Column / TS Value
これらをKEYと見なす
この為、列志向型DBは広義のKVSに含まれる事が多い
17
DataStore
Database
FileSystem
SQL NoSQL
RDB
KeyValueStore
列指向型Database
Document
Dataabse
従来のアプリケーションの範囲
18
最近のアプリケーションの範囲(Google、Amazon、Facebook等)
19
ユビキタス 双方向サービス AJAX Hadoop
EVOLUTION OF WEB
どうしてNoSQLが必要になったの?
20
Web1.0 と Web2.0
• 基本的に情報は一方通行
• 通信回数は基本的に一回
• 更新頻度が低い静的HTML
21
• 双方向通信
• 複数通信~常時通信 AJAX通信
• コンテンツはDB上、毎度読み出して動的表示
• ユーザ毎に違うページ
■Web1.0
■Web2.0
Databaseの進化 (ディスクでの応答からメモリでの応答へ)
Memory (20GB/秒) Disk (0.2GB/秒)
Web1.0 Write
Web1.0 Read
Web2.0 Write
Web2.0 Read
Cassandra / HBase
Write
Cassandra / HBase
Read 22
Memcached
非同期書込
BREWER'S CAP THEOREM
Database種類多すぎ!わからないよ!
23
ブリュワーのCAP定理
可用性
ネットワー
ク分断耐
性
一貫性
24
証明された訳ではないので「CAP原則」と呼んだ方が正確ではある
証明された様です→CAP定理の証明論文(PDF)
各種DBの特性を説明するのに非常に役立つ
とあるシステムでは ・一貫性 ・可用性 ・NW分断耐性 の内、二つまでしか 満たす事が出来ない
CAP定理 一貫性 (Consistency)
• 一貫性がある
– ZEROか100か
– YESかNOか
– 白か黒か
– 生か死か
• 重要なのは、「何も出来ない状態」も一貫性が担保された状態である事
• 中途半端な状態が存在しない
25
CAP定理 可用性 (Availability)
• 文字通り、そのサービスが利用出来る事
• そのサービスが動いていた所で利用出来なければ意味がない
• Webで言えば、混雑していてもキチンと応答が返ってくる事
– ■残念な例
– iPhone4発売時のSoftBankとか
– W杯の時のTwitterとか
– ラピュタが放映してる時の2chとか
– ■良い例
– Amazon、Google、Facebookとか
– 新商品発売時のAppleStoreとか
– 最近のmixiとか
– モバゲーとか
26
CAP定理 分割耐性(Partition Tolerance)
• CAP定理の中でも一番難しいポイント
• 「全面的なネットワーク障害以外のネットワーク障害が発生しても、システム全体が間違った結果を返さない」
• よくこのPの部分を間違って「分散しやすい」と理解している人がいますが、それは誤解であり違います
27
RDBをCAP定理で理解する
• RDBは高い一貫性を最大の特徴とする
– 厳密なトランザクション
• 可用性も基本的に高い
• ネットワーク分断耐性は低い – 分散化は可能である。しかし技術的に難易度が高い
• 故にスケールアウトよりもスケールアップ
– Exadataの登場等
• ネットワーク分断耐性(P)を犠牲にして一貫性(C)と可用性(A)をとるCA型
28
可用性
ネットワーク
分断耐性 一貫性
CAP定理によるデータベースの分類
29
Dynamo
Voldemort
KAI
TokyoCabinet Cassandra
SimpleDB
BigTable MongoDB BerkeleyDB HBase Terrastone Memcached
Hypertable Scalaris Redis
Oracle
MySQL
PostgreSQL AsterData
Greenplum
Vertica
RDB KVS 列指向 ドキュメント
BIRTH OF NOSQL
じゃどんなNoSQLが出てきたの?
30
Google BigTable
• Googleの持つ分散ファイルシステム「Google FileSystem(GFS)」の上で動作する列指向DB
• 2006年に論文が公開される
• GFSは大きめのファイルを保存するのが得意
• GFSが苦手な小型ファイル(データ)を取り扱う為に開発される
31
Google BigTable
• Googleの本業はWebのクロールとIndex化
• 複数クローラによる書込とMapReduceによる大規模分散並列Batch処理
32
可用性(A) を犠牲にして、一貫性(C)とNW分断耐性(P)を選択
CP型
大量のデータ
効率的な処理が
必要 分散並列処理が
必要(じゃないと
終わらない)
分散並列処理が
しやすいデータ
Errorや読込遅
延は別のデータを
処理する事で隠
蔽
Amazon Dynamo
• 自社のEコマース基盤の為に開発されたKVS
• 2007年に論文公開される
• Amazonが自社サービスに特化
– 過去の情報を統計分析した結果に基づく
– 一意のKeyのみでやり取りが出来る
– データサイズは1MB以下
33
Amazon Dynamo
• 本業はEコマース
– 大量の商品情報の表示、大量のユーザからのリクエスト
• 殆どのデータや処理が独立している
– 基本的には新規登録、追加のみ
– 購入行為は1ユーザで完結(例外:在庫)
• Web応答速度の遅延は売り上げ低下に直結
– 応答速度が0.1秒遅延すると、1%の売り上げを逃す→blog
• 大量データに対する大量アクセス x ダウンタイムなし
34
一貫性(C)を犠牲にして、可用性(A)とNW分断耐性(P)を選択
AP型
NoSQLの系譜(BigTable族、Dynamo族)
35
BigTable
HyperTable
Apache
HBase
Cassandra
Voldemort
Amazon
S3
Amazon
SimpleDB
FileSystem Apache
Hadoop Google
MapReduce
goo
Kai
Amazon
Dynamo 派生
クローン
クローン 混合
派生
クローン
ARCHITECTURE
どんな構造をしてるの?
36
基本的な構造
BigTable HBase Cassandra Dynamo
CAP CP CP AP AP
データ
分散方法 シャーディング コンシステントハッシング法
データモデル 列志向 KeyValue
ストレージ MemTable
CommitLog / SSTable MySQL
37
SHARDING
Architecture.1
38
シャーディング(BigTable、HBase)
• ある一定の範囲でデータベースを分割する事
• 分割方向は縦だったり横だったりする
• 分割したデータを複数のノードに割り当てて分散管理
• 【問題】どのノードにどのデータがあるか別個管理する必要がある
39
BigTable
Tablet
HBase
Region
CONSISTENT HASHING
Architecture.2
40
コンシステントハッシング法(Cassandra、Dynamo)
• ハッシュ値を元に円を作成し、その上にノードを配置
• データのKeyからハッシュ値を作り、担当するノードへ保存
• 複製ルールに従い別ノードへデータをコピーする
• 【問題】Keyによってはある特定の範囲だけ肥大化 = 特定ノードへデータ集中
41
DATA
保存 複製を保存
COMMITLOG / MEMTABLE /
SSTABLE
Architecture.3
42
CommitLog / Memtable / SSTable
43
MemTable MemTable
Memory
Disk
CommitLog
SSTable
SSTable
SSTable
読込はメモリで応答
1.まずCommitLog
2.メモリへ展開 3.一定サイズになったらDisk保存
4.Disk保存したらCommitLog削除
CommitLog / Memtable / SSTable
44
MemTable MemTable
Memory
Disk
CommitLog
SSTable
SSTable
SSTable
メモリへ展開
Disk保存されてない分を読込
【データ復旧時】
ARCHITECTURE OF HBASE
もっとHBaseについて詳しく!
45
HBaseの構成要素
• HBaseMaster (HM)
– リージョンファイルのロードバランシング
• HRegionServer (RS)
– リージョンファイルの保持
– 読込書込
• ZooKeeper (ZK)
– Rootテーブルの位置情報保持
– HBaseMasterの情報保持
• Hadoop Distributed FileSystem (HDFS)
– 分散ファイルシステム
– ここでデータの複製保存
46
RS RS
RS RS
H
M
Cli
root / meta / UserTableの関係
47
root
meta meta meta meta meta
UT1-a
UT1-b
UT2-a UT3-a
UT3-b
UT3-c
UT4-a
UT4-a UT4-a
UT4-a UT4-a
UT4-a UT4-z UT3-d
UT5-a
UT3-e
UT1-c
UT2-b
データはシャーディングして複数ノードで保持
HBaseの読み出し / 書き込み
1. ZKからrootテーブル持つノードを知る
2. rootから目的のmetaテーブルを保持するノードを知る
3. Metaテーブルから目的のテーブルのRegionを持つノードをしる
4. 目的のデータの取得する
48
ZK
RS root
UserTable
Cli
RS
・途中で取得した情報はClientがキャッシュ ・この仕組みを利用する事で、ノードがどれだけ増加しても同一の手順数でデータ取得が可能である
meta
RS
ARCHITECTURE OF CASSANDRA
もっとCassandraについて詳しく!
49
Cassandra
• 全ノードが同一機能を有する
• 1Hopで接続
• 各ノードが保持するデータが巧く分散するかはKey次第
• データは複製されて複数のノードが保持している
• 「結果整合性」を採用
• 「一貫性強度の選択」による操作
50
Cli
結果整合性
• 「データが一時的に矛盾した状態になるが、結果的には整合性の取れたデータになる」
• Cassandraが犠牲にした一貫性を補完する為の技術
– Gossip Protocol
• ノード同士が常に行う状態確認。データの整合性も確認する
– Read Repair
• 読み出したデータが一致しない場合、データを修正する
– Hinted HandOff
• 本来データを保持すべきノードが応答しない時、データを預かる
– Consistency Level(一貫性強度の選択)
• 速度優先か、一貫性優先かを選ぶことが出来る
51
一貫性強度の選択 (複製数3の場合)
• 「幾つの複製データに処理を施すか」の選択
Aという値をBに書き換え、読み出す処理の例
52
B A A
A
B A
B
B
A
B
B
B B
A B B B
B
B
B
A
B
B
A
B
W:書込数 R:読込数 N:複製数
W + R > N の時、「強い一貫性」を得られる
Write
Read
Cassandraの読み出し / 書き込み
1. まずノードに接続
2. ハッシュ表からデータを持つノードに要求を投げる
3. 必要な数のノードから応答があった時点で、クライアントに値を返す
53
Cli
THE DIFFERENCE BETWEEN
CASSANDRA AND HBASE
CassandraとHBaseとの違いをもっと分かり易く!
54
仕様的な差異
55
HBase Cassandra
SPoF HDFSにあり なし
同一行(同一データ)に 対する読込/書込
単独ノード 複数ノード
ロック単位 Row Column
データ競合解消方法 競合発生なし 時間解決 (Gossip)
データ分散方法 自動分散 手動分散
CAS操作 可能 不可能 (0.7から可能)
データ複製実行層 ディスク層(HDFS) メモリ層
Hop数 1 ~ 3 1
障害発生時(ノードのダウン)
56
HBase Cassandra
欠落ノードが持つデータ 自動で別ノードへ 欠落
欠落ノードが持つデータへの 読込/書込
別ノードへのデータ移動が終わるまで待たされる
別ノードが受け付け データ読込不可の可能性
残存ノードへの影響 処理能力低下
一貫性強度の低下
複製数の減少
データの消失
ユーザからみた動作 待たされるがErrorは返ってこない
Errorが返ってくる事がある
分断した島の動作 小さい方が自動ダウン それぞれ動作
多重ネットワーク障害
(後述) 全体クラッシュの可能性
復旧時間の長期化
データ不整合の可能性
復旧作業
57
HBase Cassandra
ノード復旧 ノード追加
追加方法を選択 ・同一Tokenで復帰
・新規Tokenで復帰
・新規ノードとしてToken指定追加
・新規ノードとして新規Tokenで追加 v0.6.8で改善された
THE HAZARD
多重ネットワーク障害が起きるとどうなるの?
58
HBaseの多重ネットワーク分断
59
• HBaseでネットワーク分断が起きると、ZKが「自分の所属する島が多数側か少数側か」を判断し、少数側が「自殺」する事で一貫性の確保を図る
• ならばもし短時間に連続して分断が発生し、多重分断状態に陥り、全員が「少数側である」と判断をしたら・・・?
• root / metaテーブルが壊れる可能性がある。壊れると全体データに問題が発生する可能性が高まる
RS
RS
RS RS
RS RS
RS
RS
RS RS
Cassandraの多重ネットワーク分断
60
• 分断されまくって1ノードに追いやられても動作する
• ノードに繋がる限り書き込み処理は可能(HintedHandOff)
• 但し読込は失敗する可能性有り
• 分断解消後はデータを自動でMergeする。但し場合に依ってはデータに不整合が発生する可能性がある
– 0.7 VersionedClockで回避出来そう?
RIGHT OPERATION IN THE RIGHT DATABASE
HBaseとCassandra、結局どっちを使えばいいの?
61
選定基準
結果整合性の
許容度
Cassandraは予想
以上に古いデータを
とってくる
受容して問題ない
Or
アプリで防げる
想定データ規模
HBaseの安定稼働
は5ノード以上?
62
0.6.4でかなり改善?
可用性
ネットワーク
分断耐性 一貫性
得意分野(得手不得手であって出来る出来ないではない)
63
■Webフロント寄り 商品情報 ユーザ情報 権限情報 各種Log OLTP
■バックエンド / Batch処理 給与計算 会計計算 各種BI Hadoop OLAP
■トランザクション処理 金融分野 在庫管理 マスター原本
だからこそ敢えて
Cassandra、HBaseを利用したアプリケーションを考えている場合、まず本番の前に調査として
「最も苦手とする機能を作ってみる」 事を提案します。
64
• 回避策を発見出来ます。 • 地雷原を発見出来ます。
• 事前に地雷を踏みまくれ!
• 技術力もつきます。 • 勉強会での発表のネタが出来ます。
苦手機能の例
• @mayahjp氏作成イベント参加者管理アプリ
• 「PARTAKE」
• 要求される機能はどれもCassandraが苦手とする機能
– 一定数で締め切らなければならない
– 参加者数の正確なカウント
– 登録順序の管理
• この辺りを詳しく知りたい方は@mayahjp氏のスライド
「CassandraでWebAppを」を見てみてください。
65
ご静聴閲覧有り難う御座いました
以上。
66
Powered by & Special Thanks!
• @mayahjp氏
• @ashato氏
• @2t3氏
• 日本Cassandraユーザー会
• Hadoopソースコードリーディング
67