More Related Content
Similar to NOSQLの基礎知識(講義資料) (20)
More from CLOUDIAN KK (20)
NOSQLの基礎知識(講義資料)
- 1. NOSQLについて
河野 達也 / Tatsuya Kawano
CloudianKK
2012年8月24日
日本OSS推進フォーラム勉強会
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 2. 本日の内容
• NOSQLの特徴
• 分類法
• データモデルによる分類
• アーキテクチャによる分類
• 主要な製品(5+1製品)の紹介
• 日本での事例(2件)の紹介
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 5. 次回(9月下旬)の予定
• アーキテクチャによる分類(続き)
• 性能に関わる部分
• ハンズオン
• HBaseクラスターを動かします
• YCSB(Yahoo! Cloud Serving Benchmark)
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 6. 河野 達也 / Tatsuya Kawano
エバンジェリスト
開発者
著者の一人
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 7. CloudianKK
• Cloudian
S3完全準拠クラウドストレージ
• Hibari DB
GBクラスのウェブメール
• NOSQL afternoon in Japanを主催
• グローバル開発リーダー Gary Ogasawara
• InktomiでCAP定理のE. Brewer氏の弟子
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 10. M2M センサーデータ
経済産業省 より抜粋
0
図0-3 「スマートメーター制度研究会報告書」
序
章
ビ
ッ
グ
デ
ー
タ
の
時
代
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 11. 従来のデータベースでは対応が難しい
• 膨大な量
• 12TB/日
• 速く処理する
• 12TB 80MB/秒 42時間
• 半構造データ
• 全てのデータを均一に整えるのは難しい
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 12. Bigtable や Dynamo の論文発表が契機となり、ソフトウェアによる大
規模分散技術は俄かに脚光を浴びました。ビッグデータに直面していた
ビッグデータに対応するための新技術
Web サービスのエンジニア達がこれに触発され、Bigtable や Dynamo の
図0-2 Google Bigtableと Amazon Dynamo の発表論文(表紙の一部)
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 15. なってしまいます。その場合、ハードディスクをより大きな
もうひとつの対策は、新たにサーバーを追加し、各サー
一般的なNOSQL製品の特徴
ることがひとつの対策となります。つまり、ハードウェアの
分割して保存するという方法です。
ップしていくのです。そうしてデータを全て移し替え、また データが増えた場合、
ら、 • スケールアウト
と追加することで、 データの保存容量を拡張していくとい
さらに大きなハードディスクに置換するというサイクル
す。こうした対策方法を「スケールアップ」
の方法を 2
「スケールアウト」 (図
と呼びます
と呼んでいます
• 汎用的なハードウェアが利用できる (図 2-7) NO
。
第
考え方は、スケールアップではなくこちらの方です。
2
章
N
O
ップのイメージ S
図2-7 スケールアウトのイメージ Q
L
の
デ
ー
タ
モ
デ
ル
スケールアップ スケールアウト
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 26. RDBにおけるデータ分散
におけるデータ分割のイメージ
サーバー 1 サーバー 2
性能がスケール
しにくい
サーバー 3 サーバー 4
キーを指定するだけでバリューを探し出せるキー・バリュー型で Inc. & KK
Copyright © 2012 Cloudian All Rights Reserved.
- 27. キー・バリュー型におけるデータ分散
・バリュー型におけるデータ分割のイメージ
サーバー 1 サーバー 2
2
テーブル間の関連やトラン
第
ザクションがないため、
2
章
容易にスケールアウト
N
O
S
させられる Q
L
の
デ
ー
タ
モ
デ
ル
サーバー 3 サーバー 4
複数のサーバーに複数のバリューを複製する © 2012 Cloudian Inc. & KK
Copyright All Rights Reserved.
- 29. ドキュメント指向型
• キー・バリュー型のバリエーション
• バリュー部分に構造を持ったデータを格納
• データ内の各項目にインデックスが付く
{ author: 'joe',
created: new Date('03/28/2009'),
title: 'Yet another blog post',
text: 'Here is the text...',
tags: [ 'example', 'joe' ],
comments : [ { author: 'jim', comment: 'I disagree'},
{ author: 'nancy', comment: 'Good post' }]
}
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 30. タ
モ
そして、RDB 等との決定的な違いとして、カラムの数を後から増やすこと デ
ル
ができます。RDB の行(レコード)のように、データの発生に応じて動的に、
ソート済みカラム指向型
かつほぼ無限に、カラムを追加していくことが可能なのです。
図2-13 カラムの名前を固定しなくてよい
ユーザーライン・カラムファミリー
この SNS がサービスを開始すると、ランダムにツィートが登録されます。
カラム
行キー タイムスタンプ
それを管理するために、ツィートID を行キーとする「ツィート・カラム
キー
(ユーザー ID) 1234567 1234568 1234569
その中でツィートID は、 2-14 のように、
図 新
2
ファミリー」を定義します。
u2415 t342
しいツィートが発生するごとに、 t353 t389
行として縦方向に追加されていきます。
ツィート ID 第
新しいツィートごとに新しい行を加える
2
章
図2-14 カラム指向型における行の追加
N
ツィート・カラムファミリー O
で、カラムの名前が固定ではないことに注意してください。
カラム
S
Q
このタイムスタンプの例のように、
行キー
カラム指向型では、行キーに連なる L
の
キー ィートID)
(ツ ユーザー ID ユーザーネーム ボディ タイムスタンプ デ
カラムの名前を、時間とともに変化する性質のものとすることができます。 ー
t342 u2415 gemini NOSQL is fun 1234567
タ
モ
そして、RDB 等との決定的な違いとして、カラムの数を後から増やすこと デ
新しいツィートごとに新しい行を加える ル
ができます。RDB の行(レコード)のように、データの発生に応じて動的に、
かつほぼ無限に、カラムを追加していくことが可能なのです。 Inc. & KK
Copyright © 2012 Cloudian All Rights Reserved.
- 31. ように、個々のカラムは内部ではキー・バリューとして格納されています。
たとえば、 2-14 のツィートID
図 「t342」の行は、Bigtable 系の HBase では、
ソート済みカラム指向型(続き)
表 2-1に示す 4 つのキー・バリューに分解されて格納されます。
表2-1 HBase において行をキーとバリューに分解する例
キー
バリュー
行キー カラムファ リー名
ミ カラム名
t342 ツ ー
ィ ト・カラムファ リ
ミ ー ユーザー ID u2415
t342 ツ ー
ィ ト・カラムファ リ
ミ ー ユーザーネーム gemini
t342 ツ ー
ィ ト・カラムファ リ
ミ ー ボディ NOSQL is fun
t342 ツ ー
ィ ト・カラムファ リ
ミ ー タイムスタンプ 1234567
• そのためカラム指向型は、キー・バリューと同様にスケールアウトに適
キー・バリュー型のバリエーション
しています。複数のサーバー間にデータを分割して配置し、かつデータを
• 各カラムが独立したキー・バリューになるため
複製することが、データ間の関係性を維持するRDBよりも容易に行える
からです。
ドキュメント指向型よりも書き込み性能の面で
有利 カラム指向型の NOSQL データベースは、名前が似ていることか
なお、
ら、カラムナ(columnar) 両者
データベースと混同されがちです、Inc. & KK All Rights Reserved.
Copyright © 2012 Cloudianしかし、
- 33. Bigtable 系と、Amazon の Dynamo 系の 2 種です。
Bigtable 系の基本的なアーキテクチャは、
「マスタ型」と呼ばれます。ひ
す
マスタ型/P2P ピア・ツゥ・ピア型
とつのマスタノードが、
(図 3-1)
。
配下にある多数のノードを管理するという構造で
図3-1 マスタ型のアーキテクチャ
Dynamo 系は P2P
(ピア・ツゥ・ピア)と呼ばれる構造です。マスタノー
ドに相当するものは存在せず、全てのノードが対等にお互いを管理し合
います(図 3-2)
。
マスタ型の NOSQL データベースには、Bigtable、CouchDB、HBase、
Hibari、MongoDB 等があります。これらの製品では、マスタノードがシス
テム全体の状況を把握しており、
止まってしまいます。
マスタがダウンするとシステム全体が
そのためマスタを冗長化したり、他のノードがマス
3第
タの役割を代行するなどして、そのような障害に備えます。 章
3
基ア
本ー
*
1 アーキテクチャとは、システムの設計方法、設計思想、およびその設計思想に基づいて構築された 概キ
図3-2 ピア・ツゥ・ピア(P2P)型のアーキテクチャ
システムの構造といった意味合いで一般的に使われますが、本書ではシステムの構造を意味します。 念テ
とク
技チ
術ャ
の
74
117_第3章_責.indd 074 2012/04/06 11:06:27
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 34. 3-19 のように Bigtable では、辞書配列に従ってキーの値がソートさ
データ分割 シャーディング
Bigtable のデータ割当て
タブレット(リージョン)
行キー:
[ Arkansas , California ) タブレット
(リージョン)
行キー: サーバー 1
[ California , California-LosAngeles )
行キー:
[ California-LosAngeles , Colorado ) タブレット
(リージョン)
行キー: サーバー 2
[ Colorado , Florida )
ベージコレクショ (Garbage Collection:GC)
ン とは、プログラムが実行の際に確保したメモリ
域のう 不要になった領域を解放する処理です。同様に、2012 ドディ & KK All Rights Reserved.
ち、 Copyright ©ハーCloudian スク上で不要になった領域
Inc.
- 35. して、その整理番号に従って、リングの各スペースにキーを割り当て 0.45
。キーが割り当てられたスペースを時計回りで進み、そこで最初に配 キーのハッシュ値
データ分割 コンシステント・ハッシング
れているノードにデータを書き込むというルールのアルゴリズムです。 が取り除かれた場合
ノード C
コンシステント・ハッシングの概念図 図3-16 コンシステント・ハッシングにおける負荷割り当ての調整
ノード ノード
A A
キーのハッシュ値
0.0 0.0
0.20
ノード 0.75 0.25 ノード
ノード ノード
D B 0.75 0.25
D B
0.70
ノード
0.5 C
データ複製 ノード データ複製
C
ノード C にデータの割り当てを増やす
グレーのノードにデータの複製を割り当て
3-13 では、ハッシュ値を 0.0 から1.0 の間で設定しています。 つの
4
ドがリング状に配置され、ノード Aには 0.0、ノード B には 0.25、 © 2012 Cloudian Inc. & KK
ノー
Copyright All Rights Reserved.
- 36. ACM(Association for Computing Machinery)が主催した PODC
(Prin-
ciple Of Distributed Computing)シンポジウムにおける「Towards Ro-
Eric BrewerのCAP定理
bust Distributed Systems」と題した基調講演の中でのことでした。
図3-6 Eric Brewer の CAP 定理
• 注意
3
• C or Aはクエリの都度 第
3
調整可能
Consistency Availability
章
基ア
整合性 可用性
• 証明されておらず 本ー
概キ
念テ
とク
厳密には定理ではない 技チ
術ャ
の
「分散システムにおいては、
Tolerance to network
これら 3 つのうち最大 2 つ
Partitions しか満たすことができない」
分断耐性 (2000 年 7 月 19 日 PODC 基調講演)
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 37. 通常のケース:
(1)クライアントはデータの更新要求を A または B のいずれか
一方に送る。
データ複製時の整合性
(2) と B はデータが更新されたことを他方に通知する。
(3)
A
通知を受けた側は、自分のデータにその更新を反映する。
クライアント 1 クライアント 2
リクエスト
データ データ
A B
レプリケーション(複製)
①クライアント1が Aに対して更新要求を出し、Aは自身の持つデー
タを更新する。
② A はデータが更新されたことを B に伝え、 は自身の持つデータ
B
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 39. ョンや業務上の要求条件次第です。 ン
ライアント 1 クライアント 2
ア 3 第
ト
が 3A B
CPとAP ネットワーク分割が発生 書
章
生じた場合 き 基ア
込 本ー
CP
(整合性と分断耐性) の場合: み AP 概 キ
(可用性と分断耐性) の場合:
念テ
リクエストは片方のグループ (仮に A)リ リクエストは全てのグループが受け
とク
ク
だけが受け付け、他のグループは エ 付けるが、A と B のデータは不整合
技チ
A B 術ャ
自主的に停止する。 ス となる。
ト の
を
クライアント 1 クライアント 2 送 クライアント 1 クライアント 2
る
ク
ラ
イ
ア
ン データ データ
ト
が A B A B
書
き
込
み AP
(可用性と分断耐性) の場合:
リ リクエストは全てのグループが受け
ク
付けるが、A と B のデータは不整合 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 40. R + W >N の場合には、整合性が保証できる
整合性と性能のトレードオフ
-10 Quorum の概念図[R + W <N]
R+W<N の場合
書き込み(W=1) 読み出し(R=1)
? ? ?
複製(N=3)
ノード 1 ノード 2 ノード 3
書き込みが 1 つのノードに行われているが、ノード
1.2.3 のどのノードから 1 つだけデータを読み出すか
はわからない。
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 41. 果的にデータの整合性を保証できることになります。
整合性と性能のトレードオフ(続き)
図3-11 Quorum の概念図 + W >N]
[R
R+W>N の場合
書き込み(W=2) 読み出し(R=2)
複製(N=3)
ノード 1 ノード 2 ノード 3
書き込みが 2 つのノードに行われ、読み出しが 2 つ
のノードに行われれば、必ず書き込みが行われた 2
つのノードのうちの 1 つに行きつく。
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 43. Apache HBase
• Google Bigtableを参考に設計
• 採用事例 Facebookメッセージング、
LINE、Mozillaクラッシュレポーター
• ソート済みカラム指向型
• 強い整合性(CP)
• スケールアウト型(自動シャーディング)
• マスタ型
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 44. Apache HBase
• 速度:★★★☆☆
• 安定性:★★☆☆☆
• 注意点
• 安定させるのが難しい
• HDFSよりMapRの方が高速、安定する
(MapRはプロプライエタリ)
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 45. Apache Cassandra
• Amazon DynamoとGoogle Bigtableを参考に
設計
• 採用事例 Twitter(分析系)、Digg、Cloudian
• ソート済みカラム指向型
• 緩い整合性(調整可能AP→CP)
• スケールアウト型
(コンシステント・ハッシング)
• P2P型
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 47. Basho Riak
• Amazon Dynamoを参考に設計
• キー・バリュー型
• JSONの扱いに優れ、使い勝手はドキュメン
ト指向型に近い
• 緩い整合性(調整可能AP→CP)
• スケールアウト型
(コンシステント・ハッシング)
• P2P型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 56. Cloudian™の論論理理アーキテクチャ
Admin 認証情報
サーバー (Redis)
HTTPS
ログイン
HTTP QoS DB
アカウント設定/ HTTPS 管理理コンソール S3サーバー
セキュリティキー Servlets (Redis)
HTTP
レポート
HTTP
Data Explorer データサーバー ユーザーデータ
(Cassandra)
ウェブUI
アカウント情報
(Cassandra)
HTTP or
HTTPS
(S3) レポート
アプリケーション
(Cassandra)
56
- 57. オブジェクトストアとしてのCassandra
• BLOBストレージ
• グループごとに column family を作成
• ⾏行行キー <バケットID>/<オブジェクトID>
• オブジェクトのメタデータ
• ACL (アクセスコントロールリスト)、オブジェクトのサイズ・・・
• Cassandra ⾏行行キャッシュを活⽤用
• 巨⼤大なS3オブジェクトのサポート
• マルチパート Amazon S3 multi-‐‑‒part APIを使ってアップロード
• チャンキング ⼤大きなオブジェクトを⼩小さなチャンク(例例 10MB)に分割して保存
• HTTPレンジヘッダー ダウンロード時は HEAD リクエストでオブジェクトのサイズを
取得してから、スタートのバイト位置と⻑⾧長さを指定してダウンロード
• HyperStore™ 巨⼤大なオブジェクトをネイティブなファイルシステムに保存
- 58. ⼤大きなデータの扱いで性能が劣劣化
遅延時間の
遅延時間の中央値 30分間で
バリューサイズ 95パーセンタイル値 スループット
(ミリ秒) 処理理した
(ミリ秒)
100KB (件/秒)
件数
Get Put Get Put
Hibari 0.1.8 9.268 12.299 61.914 75.934 2,073 3,733,136
Cassandra 1.0 28.551 9.992 379.745 155.680 1,699 3,060,198
Cassandra 0.8.6 34.099 8.402 1,015.888 333.048 1,336 2,406,446
バリューサイズ 1KB
Hibari 0.1.8 1.027 1.676 3.069 2.881 8,775 15,804,196
Cassandra 1.0 1.016 0.949 2.476 4.789 8,748 15,755,306
Cassandra 0.8.6 1.282 0.948 5.729 2.243 8,700 15,668,017
出典:「NOSQLの基礎知識識」 リックテレコム、2012年年4⽉月出版
- 59. HyperStore™(特許出願中)
Admin 認証情報
HyperStore サーバー (Redis)
• ストレージのハイブリッド化により S3 QoS
サーバー (Redis)
処理性能とディスク利用効率の向上を実現
• オブジェクトの大きさに応じて
データストア
最適なストレージを自動選択
HyperStore™
• メタデータは引き続きCassandraに格納 Manager
Data Store
• パーティショニング、レプリケーション、ノード (Cassandra)
の死活監視は、Cassandraの分散機能を使用
Cloudian®
• Cassandraのソースをフォークしてカスタマイ サーバー Accounting
(Cassandra)
ズ
Reporting
(Cassandra)
- 60. HyperStore: レイテンシーの測定
50.0
37.5 >30% faster
ms
25.0 PUT-Cass
PUT-HS
12.5
0
0 1 10 100 1000
KB
60.0
45.0
>400% faster
ms
30.0 GET-Cass
GET-HS
15.0
0
0 1 10 100 1000 KB
- 61. 推薦図書
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 63. NoSQLプログラミング
実践活用技法
Shashank Tiwari (著)
中村 泰久 (監修)
長尾 高弘 (翻訳)
HBase、Cassandra、
MongoDB、Redis
407ページ
出版社: 翔泳社 (2012/5/18)
ISBN-10: 4798126055
ISBN-13: 978-4798126050
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 66. HBase
Lars George (著)
Sky株式会社 玉川 竜司 (翻訳)
584ページ
出版社: オライリージャパン (2012/7/25)
ISBN-10: 4873115663
ISBN-13: 978-4873115665
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.
- 68. Questions?
http://gplus.to/tatsuya6502
http://twitter.com/tatsuya6502
Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.