NOSQLの基礎知識（講義資料）

NOSQLについて
河野達也 / Tatsuya Kawano
CloudianKK

2012年8月24日
日本OSS推進フォーラム勉強会

Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

本日の内容

• NOSQLの特徴
• 分類法
• データモデルによる分類
• アーキテクチャによる分類
• 主要な製品（5+1製品）の紹介
• 日本での事例（2件）の紹介

この勉強会を終えると

• NOSQL製品を分類するための
キーワードが理解できる

• 主要な５+1製品の特徴が説明できる
• NOSQLの使いどころが説明できる


駆け足です

• 本当は１日半くらいかけて学ぶ内容を
２時間でやります

• スライドは後日SlideShareにアップします
• 推薦図書（５冊）も紹介します


次回（９月下旬）の予定

• アーキテクチャによる分類（続き）
• 性能に関わる部分
• ハンズオン
• HBaseクラスターを動かします
• YCSB（Yahoo! Cloud Serving Benchmark）

河野達也 / Tatsuya Kawano

エバンジェリスト

開発者

著者の一人


CloudianKK

• Cloudian
S3完全準拠クラウドストレージ

• Hibari DB
GBクラスのウェブメール

• NOSQL afternoon in Japanを主催
• グローバル開発リーダー Gary Ogasawara
• InktomiでCAP定理のE. Brewer氏の弟子

NOSQLの
特徴
高速
大容量
半構造のデータ


http://www.slideshare.net/sunsuk7tp/hbase-at-line

M2M センサーデータ
経済産業省より抜粋

0
図0-3 「スマートメーター制度研究会報告書」

序
章

ビ
ッ
グ
デ
ー
タ
の
時
代


従来のデータベースでは対応が難しい

• 膨大な量
• 12TB/日
• 速く処理する
• 12TB 80MB/秒 42時間
• 半構造データ
• 全てのデータを均一に整えるのは難しい

Bigtable や Dynamo の論文発表が契機となり、ソフトウェアによる大
規模分散技術は俄かに脚光を浴びました。ビッグデータに直面していた
ビッグデータに対応するための新技術
Web サービスのエンジニア達がこれに触発され、Bigtable や Dynamo の

図0-2 Google Bigtableと Amazon Dynamo の発表論文（表紙の一部）


いてメッセージを保存しているIn-Box サーチのために開発され、オープ
ンソースとしてリリースされました。その後 Cassandra は、大規模な

大手Webサービスが利用を開始
ニュース関連 SNS であるDigg
（ディッグ）クラウドサービスの大手
や、

図1-2 代表的なNOSQL の利用企業の例


SQL以外のデータベースを総称

• 世界に100種類以上


なってしまいます。その場合、ハードディスクをより大きな
もうひとつの対策は、新たにサーバーを追加し、各サー
一般的なNOSQL製品の特徴
ることがひとつの対策となります。つまり、ハードウェアの
分割して保存するという方法です。
ップしていくのです。そうしてデータを全て移し替え、またデータが増えた場合、
ら、 • スケールアウト
と追加することで、データの保存容量を拡張していくとい
さらに大きなハードディスクに置換するというサイクル
す。こうした対策方法を「スケールアップ」
の方法を 2
「スケールアウト」（図
と呼びます
と呼んでいます
• 汎用的なハードウェアが利用できる（図 2-7） NO
。
第
考え方は、スケールアップではなくこちらの方です。
2
章
N
O
ップのイメージ S
図2-7 スケールアウトのイメージ Q
L
の
デ
ー
タ
モ
デ
ル

スケールアップスケールアウト


一般的なNOSQL製品の特徴（続き）

• 複雑で多種多様に変化するデータ構造に対応
• 高可用性と高信頼性
• 耐障害性
• サービス無停止で拡張


NOSQLは用途を絞り込んだデータベース

• 機能が少ない
• データの整合性が緩い（結果整合性）
• 製品の成熟度？


事例1
LINE

http://www.slideshare.net/sunsuk7tp/hbase-at-line


データモデル
による分類

キー・バリュー型
ドキュメント指向型
ソート済みカラム指向型
http://beautifuldata.net/2012/01/
telling-stories-with-network-data-instagram-in-china/


RDB では、行と列で構成されるテーブル（表）の形でデータ構造の設
計をし、そのうえでテーブル間の関係性を定義します。図にすると図 2-1

RDBのデータモデル
2-1 RDB のデータモデルのイメージ

• 行と列で構成されるテーブルを定義
• テーブル間の関係性を定義
• 正規化により冗長生と不整合を排除
_責.indd 050 2012/04/06 10:59:32


キー・バリュー型
型データモデルのイメージ

す。新しいデータが追加されるごとに、行が加えられて
が増えるに従って、表が縦の方向に伸びていくイメージ
• 辞書のようなデータ形式
ー型に該当する NOSQL データベースには、Dynamo、
、Hibari、Redis、Scalaris スカラリス） Tokyo Cabi-
（、
あります。 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

RDBにおけるデータ分散
におけるデータ分割のイメージ

サーバー 1 サーバー 2

性能がスケール
しにくい


キーを指定するだけでバリューを探し出せるキー・バリュー型で Inc. & KK
Copyright © 2012 Cloudian All Rights Reserved.

キー・バリュー型におけるデータ分散
・バリュー型におけるデータ分割のイメージ


2
テーブル間の関連やトラン
第
ザクションがないため、
2
章
容易にスケールアウト
N
O
S
させられる Q
L
の
デ
ー
タ
モ
デ
ル

複数のサーバーに複数のバリューを複製する © 2012 Cloudian Inc. & KK
Copyright All Rights Reserved.

キー・バリュー型におけるデータの複製
0 キー・バリュー型におけるデータの複製

複製

複製複製

サーバー 3

単独のサー
のような課題に対するソリューションを実装しておらず、

ドキュメント指向型

• キー・バリュー型のバリエーション
• バリュー部分に構造を持ったデータを格納
• データ内の各項目にインデックスが付く
{ 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' }]
}


タ
モ
そして、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.

ように、個々のカラムは内部ではキー・バリューとして格納されています。
たとえば、 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しかし、

アーキテクチャ
による分類
マスタ型、P2P型
データ分割
CAP定理


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


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.

して、その整理番号に従って、リングの各スペースにキーを割り当て 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.

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 基調講演）


通常のケース：
（1）クライアントはデータの更新要求を A または B のいずれか
一方に送る。
データ複製時の整合性
（2）と B はデータが更新されたことを他方に通知する。
（3）
A
通知を受けた側は、自分のデータにその更新を反映する。

クライアント 1 クライアント 2

リクエスト

データデータ

A B

レプリケーション（複製）

①クライアント1が Aに対して更新要求を出し、Aは自身の持つデー
タを更新する。
② A はデータが更新されたことを B に伝え、は自身の持つデータ
B

分割耐性
• ネットワークが分断されても
間違った結果を起こさない

• 間違った結果が何にあたるかは
CP、APで異なる


ョンや業務上の要求条件次第です。ン
ライアント 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.

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 つだけデータを読み出すか
はわからない。


果的にデータの整合性を保証できることになります。

整合性と性能のトレードオフ（続き）
図3-11 Quorum の概念図＋ W ＞N］
［R
R＋W＞N の場合

書き込み（W＝2）読み出し（R＝2）

複製（N＝3）
ノード 1 ノード 2 ノード 3

書き込みが 2 つのノードに行われ、読み出しが 2 つ
のノードに行われれば、必ず書き込みが行われた 2
つのノードのうちの 1 つに行きつく。


主な製品
HBase
Cassandra
Riak
Redis
MongoDB
VoltDB (NewSQL)


Apache HBase

• Google Bigtableを参考に設計
• 採用事例 Facebookメッセージング、
LINE、Mozillaクラッシュレポーター

• ソート済みカラム指向型
• 強い整合性（CP）
• スケールアウト型（自動シャーディング）
• マスタ型

Apache HBase

• 速度：★★★☆☆
• 安定性：★★☆☆☆
• 注意点
• 安定させるのが難しい
• HDFSよりMapRの方が高速、安定する
（MapRはプロプライエタリ）


Apache Cassandra

• Amazon DynamoとGoogle Bigtableを参考に
設計

• 採用事例 Twitter（分析系）、Digg、Cloudian
• ソート済みカラム指向型
• 緩い整合性（調整可能AP→CP）
• スケールアウト型
（コンシステント・ハッシング）

• P2P型

Apache Cassandra

• 速度：★★★★☆
• 安定性：★★★★☆
• 注意点
• ディスク容量の使用効率が悪い
• データ再配置の性能が悪い

Basho Riak

• Amazon Dynamoを参考に設計
• キー・バリュー型
• JSONの扱いに優れ、使い勝手はドキュメン
ト指向型に近い

• 緩い整合性（調整可能AP→CP）
（コンシステント・ハッシング）

• P2P型 Copyright © 2012 Cloudian Inc. & KK All Rights Reserved.

Basho Riak

• 速度：★★★☆☆
• 安定性：★★★★★
• 注意点：なし


MongoDB

• ドキュメント指向型
• スケールアップ
• シャーディングに対応しているが、、、
• インメモリ、高速

MongoDB

• 速度：★★★★★
• 安定性：★★★☆☆
• 注意点
• メモリーの使用効率が悪い
• メモリー不足でレスポンスが極度に悪化

Redis

• キーバリュー型
（配列やリストの扱いに優れる）

• スケールアップ型
• インメモリ、高速

Redis

• 速度：★★★★★
• 安定性：★★★★☆
• 注意点
• 格納できるデータサイズがメモリーの
搭載量に制限される


VoltDB

• NewSQL
• SQLとACIDトランザクションが使える
インメモリ・データベース



VoltDB

• 超高速、高い安定性
（発表者自身は試せていない）

• 柔軟性が犠牲に
• アドホックなクエリはできない。
事前にJavaでストアドプロシージャを
書く

• ノード追加時はサービスをいったん停止

事例2
Cloudian

Redis
Cassandra
HyperStore
http://cloudian.jp/cloud-storage-products/cloudian.html


Cloudian™の論論理理アーキテクチャ
Admin 認証情報
サーバー (Redis)
HTTPS
ログイン

HTTP QoS DB
アカウント設定/ HTTPS 管理理コンソール S3サーバー
セキュリティキー Servlets (Redis)

HTTP
レポート

HTTP
Data Explorer データサーバーユーザーデータ
(Cassandra)
ウェブUI

アカウント情報
(Cassandra)
HTTP or
HTTPS
(S3) レポート
アプリケーション
(Cassandra)

56

オブジェクトストアとしてのCassandra

• BLOBストレージ

• グループごとに column family を作成
• ⾏行行キー　<バケットID>/<オブジェクトID>

• オブジェクトのメタデータ

• ACL (アクセスコントロールリスト)、オブジェクトのサイズ・・・
• Cassandra ⾏行行キャッシュを活⽤用

• 巨⼤大なS3オブジェクトのサポート

• マルチパート　Amazon S3 multi-‐‑‒part APIを使ってアップロード
• チャンキング　⼤大きなオブジェクトを⼩小さなチャンク（例例 10MB）に分割して保存
• HTTPレンジヘッダー　ダウンロード時は HEAD リクエストでオブジェクトのサイズを
取得してから、スタートのバイト位置と⻑⾧長さを指定してダウンロード
• HyperStore™ 　巨⼤大なオブジェクトをネイティブなファイルシステムに保存

⼤大きなデータの扱いで性能が劣劣化
遅延時間の
遅延時間の中央値 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⽉月出版

HyperStore™（特許出願中）
Admin 認証情報

HyperStore サーバー (Redis)

• ストレージのハイブリッド化により S3 QoS
サーバー (Redis)
処理性能とディスク利用効率の向上を実現

• オブジェクトの大きさに応じて
データストア
最適なストレージを自動選択
HyperStore™
• メタデータは引き続きCassandraに格納 Manager
Data Store
• パーティショニング、レプリケーション、ノード (Cassandra)
の死活監視は、Cassandraの分散機能を使用
Cloudian®
• Cassandraのソースをフォークしてカスタマイサーバー Accounting
(Cassandra)
ズ

Reporting
(Cassandra)

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

推薦図書


NOSQLの基礎知識

ビッグデータを活かす
データベース技術
本橋信也 (著)
河野達也 (著)
鶴見利章 (著)
太田洋 (監修)

256ページ
出版社: リックテレコム (2012/4/25)
ISBN-10: 4897978874
ISBN-13: 978-4897978871


NoSQLプログラミング
実践活用技法
Shashank Tiwari (著)
中村泰久 (監修)
長尾高弘 (翻訳)

HBase、Cassandra、
MongoDB、Redis

407ページ
出版社: 翔泳社 (2012/5/18)
ISBN-10: 4798126055
ISBN-13: 978-4798126050


まつもとゆきひろ
コードの未来
まつもとゆきひろ (著)

MongoDB、VoltDB

360ページ
出版社: 日経BP社 (2012/5/17)
ISBN-10: 4822234630
ISBN-13: 978-4822234638


NoSQLデータベース
ファーストガイド
佐々木達也 (著)

MongoDB、Redis

232ページ
出版社: 秀和システム (2011/04)
ISBN-10: 4798029599
ISBN-13: 978-4798029597


HBase
Lars George (著)
Sky株式会社玉川竜司 (翻訳)

584ページ
出版社: オライリージャパン (2012/7/25)
ISBN-10: 4873115663
ISBN-13: 978-4873115665


この勉強会を終えると（再）

• NOSQL製品を分類するための
キーワードが分かる

• 主要な５製品の特徴が説明できる
• NOSQLの使いどころが説明できる


Questions?

http://gplus.to/tatsuya6502

http://twitter.com/tatsuya6502


NOSQLの基礎知識（講義資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to NOSQLの基礎知識（講義資料）

Similar to NOSQLの基礎知識（講義資料） (20)

More from CLOUDIAN KK

More from CLOUDIAN KK (20)

Recently uploaded

Recently uploaded (9)

NOSQLの基礎知識（講義資料）