Movatterモバイル変換

[0]ホーム
URL:

Yutuki r, profile picture
Uploaded byYutuki r
PDF, PPTX23,842 views

Cassandraとh baseの比較して入門するno sql

第10回Cassandra勉強会にて発表したスライドに、勉強会後のフィードバックを反映させた物です。

Embed presentation

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

Recommended

PPTX
事例で学ぶApache Cassandra
PDF
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
PPT
インフラエンジニアのためのcassandra入門
PDF
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
PDF
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
PDF
SQL大量発行処理をいかにして高速化するか
PDF
Embulk, an open-source plugin-based parallel bulk data loader
PDF
イミュータブルデータモデル(世代編)
PDF
マルチテナント化で知っておきたいデータベースのこと
PPTX
MLflowで学ぶMLOpsことはじめ
PDF
ドメイン駆動設計 本格入門
PDF
40分でわかるHadoop徹底入門 （Cloudera World Tokyo 2014 講演資料）
PDF
AWSのログ管理ベストプラクティス
PDF
Amazon Athena 初心者向けハンズオン
PDF
Where狙いのキー、order by狙いのキー
PDF
MySQL 5.7にやられないためにおぼえておいてほしいこと
PDF
データベース設計徹底指南
PDF
なぜ、いま リレーショナルモデルなのか（理論から学ぶデータベース実践入門読書会スペシャル）
PPTX
SPAセキュリティ入門～PHP Conference Japan 2021
PDF
イミュータブルデータモデルの極意
PPTX
イベント・ソーシングを知る
PPTX
Apache Spark on Kubernetes入門（Open Source Conference 2021 Online Hiroshima 発表資料）
PDF
PlaySQLAlchemy: SQLAlchemy入門
PPTX
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
PPTX
「実践ドメイン駆動設計」社内読書会まとめ ～IDDD本難民に捧げる1章から7章～
 
PDF
Pythonによる黒魔術入門
PDF
爆速クエリエンジン”Presto”を使いたくなる話
PPTX
Redisの特徴と活用方法について
PPT
Cassandraのしくみ データの読み書き編
PDF
RDB技術者のためのNoSQLガイド　NoSQLの必要性と位置づけ

More Related Content

PPTX
事例で学ぶApache Cassandra
PDF
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
PPT
インフラエンジニアのためのcassandra入門
PDF
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
PDF
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
PDF
SQL大量発行処理をいかにして高速化するか
PDF
Embulk, an open-source plugin-based parallel bulk data loader
PDF
イミュータブルデータモデル(世代編)
事例で学ぶApache Cassandra
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
インフラエンジニアのためのcassandra入門
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
SQL大量発行処理をいかにして高速化するか
Embulk, an open-source plugin-based parallel bulk data loader
イミュータブルデータモデル(世代編)

What's hot

PDF
マルチテナント化で知っておきたいデータベースのこと
PPTX
MLflowで学ぶMLOpsことはじめ
PDF
ドメイン駆動設計 本格入門
PDF
40分でわかるHadoop徹底入門 （Cloudera World Tokyo 2014 講演資料）
PDF
AWSのログ管理ベストプラクティス
PDF
Amazon Athena 初心者向けハンズオン
PDF
Where狙いのキー、order by狙いのキー
PDF
MySQL 5.7にやられないためにおぼえておいてほしいこと
PDF
データベース設計徹底指南
PDF
なぜ、いま リレーショナルモデルなのか（理論から学ぶデータベース実践入門読書会スペシャル）
PPTX
SPAセキュリティ入門～PHP Conference Japan 2021
PDF
イミュータブルデータモデルの極意
PPTX
イベント・ソーシングを知る
PPTX
Apache Spark on Kubernetes入門（Open Source Conference 2021 Online Hiroshima 発表資料）
PDF
PlaySQLAlchemy: SQLAlchemy入門
PPTX
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
PPTX
「実践ドメイン駆動設計」社内読書会まとめ ～IDDD本難民に捧げる1章から7章～
 
PDF
Pythonによる黒魔術入門
PDF
爆速クエリエンジン”Presto”を使いたくなる話
PPTX
Redisの特徴と活用方法について
マルチテナント化で知っておきたいデータベースのこと
MLflowで学ぶMLOpsことはじめ
ドメイン駆動設計 本格入門
40分でわかるHadoop徹底入門 （Cloudera World Tokyo 2014 講演資料）
AWSのログ管理ベストプラクティス
Amazon Athena 初心者向けハンズオン
Where狙いのキー、order by狙いのキー
MySQL 5.7にやられないためにおぼえておいてほしいこと
データベース設計徹底指南
なぜ、いま リレーショナルモデルなのか（理論から学ぶデータベース実践入門読書会スペシャル）
SPAセキュリティ入門～PHP Conference Japan 2021
イミュータブルデータモデルの極意
イベント・ソーシングを知る
Apache Spark on Kubernetes入門（Open Source Conference 2021 Online Hiroshima 発表資料）
PlaySQLAlchemy: SQLAlchemy入門
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
「実践ドメイン駆動設計」社内読書会まとめ ～IDDD本難民に捧げる1章から7章～
 
Pythonによる黒魔術入門
爆速クエリエンジン”Presto”を使いたくなる話
Redisの特徴と活用方法について

Viewers also liked

PPT
Cassandraのしくみ データの読み書き編
PDF
RDB技術者のためのNoSQLガイド　NoSQLの必要性と位置づけ
PDF
Apache Sparkに手を出してヤケドしないための基本 ～「Apache Spark入門より」～ （デブサミ 2016 講演資料）
PDF
ビッグデータ処理データベースの全体像と使い分け
PDF
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
PPTX
これがCassandra
PPTX
HBase スキーマ設計のポイント
PDF
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
 
PPTX
CAPとBASE、ACIDの呪縛
PDF
Goでヤフーの分散オブジェクトストレージを作った話 Go Conference 2017 Spring
PDF
刊行記念セミナー「HBase徹底入門」
PPTX
HBaseサポート最前線 #hbase_ca
PDF
CDHの歴史とCDH5新機能概要 #at_tokuben
PDF
Lars George HBase Seminar with O'REILLY Oct.12 2012
PDF
Osc2012 spring HBase Report
PPSX
HBaseとSparkでセンサーデータを有効活用 #hbasejp
PDF
HBase活用事例 #hbase_ca
PDF
Apache HBase 入門 (第１回)
PDF
Apache HBase 入門 (第２回)
PDF
CAPとBASEとEventually Consistent
Cassandraのしくみ データの読み書き編
RDB技術者のためのNoSQLガイド　NoSQLの必要性と位置づけ
Apache Sparkに手を出してヤケドしないための基本 ～「Apache Spark入門より」～ （デブサミ 2016 講演資料）
ビッグデータ処理データベースの全体像と使い分け
スケーラブルなシステムのためのHBaseスキーマ設計 #hcj13w
これがCassandra
HBase スキーマ設計のポイント
Cassandra導入事例と現場視点での苦労したポイント cassandra summit2014jpn
 
CAPとBASE、ACIDの呪縛
Goでヤフーの分散オブジェクトストレージを作った話 Go Conference 2017 Spring
刊行記念セミナー「HBase徹底入門」
HBaseサポート最前線 #hbase_ca
CDHの歴史とCDH5新機能概要 #at_tokuben
Lars George HBase Seminar with O'REILLY Oct.12 2012
Osc2012 spring HBase Report
HBaseとSparkでセンサーデータを有効活用 #hbasejp
HBase活用事例 #hbase_ca
Apache HBase 入門 (第１回)
Apache HBase 入門 (第２回)
CAPとBASEとEventually Consistent

Similar to Cassandraとh baseの比較して入門するno sql

PPTX
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
PDF
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
PDF
20120409 aws meister-reloaded-dynamo-db
PPT
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ～Apache Cassandra編～
PDF
Nosqlの基礎知識（2013年7月講義資料）
PDF
Introduction to Modern Analytical DB
PDF
[db tech showcase Tokyo 2014] L32: Apache Cassandraに注目！！（IoT, Bigdata、NoSQLのバ...
PDF
About　NoSQL
PPT
Cassandra(no sql)によるシステム提案と開発
PPTX
NoSQL Bigtable and Azure Table
PDF
NoSQLとビックデータ入門編Update版
PPTX
Okuyama説明資料 20120119 ss
PDF
InfoTalk springbreak_2012
PDF
Info talk #36
PDF
[INSIGHT OUT 2011] b21 ひとつのデータベース技術では生き残れない part2 no sql, hadoop
PDF
社会ネットワーク分析第７回
PDF
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
PDF
実務で役立つデータベースの活用法
PDF
「NOSQLの基礎知識」講義資料　第20回JDMC定例セミナー（201310）
2024年度_サイバーエージェント_新卒研修「データベースの歴史」.pptx
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
20120409 aws meister-reloaded-dynamo-db
Devsumi2013【15-e-5】NoSQLの野心的な使い方 ～Apache Cassandra編～
Nosqlの基礎知識（2013年7月講義資料）
Introduction to Modern Analytical DB
[db tech showcase Tokyo 2014] L32: Apache Cassandraに注目！！（IoT, Bigdata、NoSQLのバ...
About　NoSQL
Cassandra(no sql)によるシステム提案と開発
NoSQL Bigtable and Azure Table
NoSQLとビックデータ入門編Update版
Okuyama説明資料 20120119 ss
InfoTalk springbreak_2012
Info talk #36
[INSIGHT OUT 2011] b21 ひとつのデータベース技術では生き残れない part2 no sql, hadoop
社会ネットワーク分析第７回
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
実務で役立つデータベースの活用法
「NOSQLの基礎知識」講義資料　第20回JDMC定例セミナー（201310）

Cassandraとh baseの比較して入門するno sql

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