NoSQLに関するまとめ
2010/05/28
宮下 剛輔

NoSQLとは？
• Not Only SQLの略
– 元々は本当に「No SQL」だったみたいだけ
ど、印象悪いのでこうなったらしい
• SQLを使わない非リレーショナルなデータ
ベースの総称
– おおざっぱに言うとMySQLとかPostgreSQL以外
• どんなものがあるか
– kumofs, redis, Amazon
SimpleDB, hBase, Cassandra, memcachedb, Couch
DB, MongoDB, ...

NoSQL登場の背景
• RDBでは大規模なウェブ環境に対応できな
くなってきた。特にスケーラビリティの
面で。
– MySQLでのスケーラビリティを考える
– readのスケーラビリティ: レプリケーション
＋ロードバランシング
– writeのスケーラビリティ: sharding/partitioning
– いずれにしろ、MySQL単体では実現できず、
別の技術やアプリケーション側での工夫が必
要
• sharding/partitioningについてはSpiderやPacificと
いった選択肢もある

NoSQL登場の背景
• スケーラビリティ向上のためには、ACID
からBASEへ

ACIDからBASEへ
• ACID: データベースのトランザクション特性
– Atomicity - トランザクションに含まれるタスクが
全て実行されるか、あるいは全く実行されないこ
とを保証する性質
– Consistency -トランザクション開始と終了時にあ
らかじめ与えられた整合性を満たすことを保証す
る性質
– Isolation -トランザクション中に行われる操作の過
程が他の操作から隠蔽されることを指す
– Durability -トランザクション操作の完了通知を
ユーザが受けた時点で、その操作は永続的とな
り、結果が失われないことを指す。

ACIDからBASEへ
• ACIDからConsistencyとIsolationを捨て去る
ことによって、
– 可用性が向上
– 性能劣化しにくい
– スケーラビリティが向上
• BASE
– Basically Available
– Soft-state
– Eventual consitency

BASE
• Basically Available
– いつでもデータにアクセスできることが重要
• Soft-state
– ゆるい状態管理/データ管理
– 高負荷時の耐性が高い
• Eventual consistency
– 結果整合性。途中でデータに不整合が起きて
も、結果的に整合性がとれてればOK

Soft-stateをちょっと詳しく
• 状態管理の手法には、Hard-stateとSoft-stateがある
• 状態とは、ノードの生死やデータの状態
• 定期的にリフレッシュデータを送って状態確認す
るのがSoft-state
– データはベストエフォートで送信
• 状態が変わったときだけデータ送信して状態確認
するのがHard-state
– データは信頼性の高い方法で送信
– 再送制御が必要
• 高負荷の時にはソフトステートの方が耐障害性が
高いという調査結果

ACID対BASE
ACID
• Strong Consistency
• Isolation
• Focus on “commit”
• Nested transactions
• Availability?
• Conservative(pessimistic)
• Difficult evolution(e.g.
schema)
BASE
• Weak consistency – stale
data ok
• Availability first
• Best effor
• Approximate answers OK
• Aggressive(optimistic)
• Simpler!
• Faster
• Easier evolution

ACIDからBASEへ
• スケーラビリティのためにACID の概念を緩
和。その結果出てくる考えがBASE。
• ただし ACID は個別のデータベースのトラン
ザクション特性なのに対し、BASE はデータ
ベース機能を含んだシステム全体の特性をさ
すものなので、一概に比較できるものでもな
い
• ACIDとBASEは共存可能。システム全体は
BASE、システムを構成する個別のDBはACID、
といった感じで。
• 実際のシステムはACIDが必要なところとBASE
で十分な部分が混在している

CAP定理
• スケーラビリティや整合性に関する定理
• Consitency
– 誰かがデータを更新したら、その後は必ず更新後の
データが返る
• Availability
– クライアントは必ずデータにアクセスできる
• Partition tolerance
– 耐ネットワーク分断性
– データを複数サーバに分散して保存できる、と読み
替えても良い
• この3つのうち、2つまでしか同時に満たせない、
というのがCAP定理

CAP定理の適用
• ConsistencyとAvailability
– データはいつでも利用可能で一貫している
– 単一データベースサーバ
– 可用性あげるためには HA 構成になる？（この辺
微妙）
• ConsitsencyとPartition torelance
– データを分散しつつも整合性を保持
– 整合性保持のため、複製中はすべてのノードで
データが更新されるまでロックをかけて不整合を
阻止
– ロックかかってる最中はAvailableではない

CAP定理の適用
• AvailabilityとPartition torelance
– データは分散され、いつでもデータにアクセスでき
る
– データ複製中は不整合な状態になりえる
– DNSなんかはその例
• 大規模分散システムにはこのAとPを満たすことが
重要
• Cはある程度妥協する(Eventual Consistency)
• ただし、VerticaはNoSQLながらもStrong Consitency
らしい
• CとAを満たすものがRDB。CとPやAとPを満たすも
のがNoSQL

ここまでのまとめ
• NoSQLはSQLをつかわない非RDBなデータ
ベース
• ACIDとBASE
• CAP定理
• 大規模ウェブはPとAが重要
• Cは妥協する(Eventual consistency)

データモデルによるNOSQLデー
タベースの分類

NoSQLのデータモデルによる分
類
• Key-Value
• 列指向の表形式
• ドキュメント指向

Key-Value
• キーと値のペアの格納に特化したもの

列指向の表形式
• 行指向の対義語
• 行指向は内部的に行単位でデータを保持
– 少数の行に対する多くの列の取得が効率的で
ある。行あたりのサイズが小さい場合には、
行全体を1度のディスクシークで読み取ること
ができる。
– 少数の行に対する多くの列の更新が効率的で
ある。1行全体の書き出しを、1度のディスク
シークで行うことができる。
– OLTPに向いている

列指向の表形式
• 列指向は内部的に列単位でデータを保持
– 大量の行に対する少数の列の集約処理が効率的で
ある。列数が少ないほど、読み込むデータ量を減
らすことができる。
– 全行に対する少数の列の一括更新が効率的であ
る。新規に列データを作成し、以前のデータと置
換することで、他の列へのアクセスを回避でき
る。
– データが列ごとにまとまってるので、列の追加が
容易
– OLAPに向いている

ドキュメント指向
• XMLやJSONなどの半構造データ
• {“name”: “John Smith”, “age”: 33} といった
形でデータを出し入れ
• フィールドの数や長さに特に制限はない

データモデルで分類したソフト
ウェア
• Key-Value
– Tokyo Cabinet, Dynamo, Redis, Kai, kumofs
• 列指向
– Cassndra, hBase, HyperTable, BigTable, Vertica
• ドキュメント指向
– CouchDB, SimpleDB, MongoDB, Terrastore

すべてのデータモデルに共通なこ
と
• スキーマレス
– 柔軟な拡張が可能

まとめ
• データモデル
– Key-Value
– 列指向表形式
– ドキュメント指向
• すべてに共通なのはスキーマレス

CAP定理に基づくデータベースの
分類

ConsistencyとAvailability
• MySQL
• PostgreSQL
• Aster Data
• Greenplum
• Vertica
赤はリレーショナル, 緑は列指向

ConsistencyとPartition torelance
• BigTable
• Hypertable
• Hbase
• MongoDB
• Terrastore
• MemcacheDB
• Redis
緑は列指向、紫はドキュメント指向、青はKey-
Value

AvailabilityとPartition torelance
• Cassandra
• SimpleDB
• CouchDB
• Riak
• Dynamo
• Voldemort
• Kai
緑は列指向、紫はドキュメント指向、青はKey-
Value

CAP定理による分類まとめ
• CAP定理にしたがって分類してみた（って
いうかひとが分類したのを載せただけ）
• でも、あまり厳密に理論のことは考えな
くていいです
• おおざっぱにしっておけばOK

まとめ

まとめ
• ACIDとかBASEとかCAPとか説明したけど、ACIDと
BASEは適用範囲も違ったり、ACIDのCとCAPのCは
意味が違ったりするので、厳密に考えると混乱す
るから、なんとなくの考え方を掴んでおけばOK
• NoSQLといっても、BigTableはGQLというSQLライク
な言語が使えるし、NoSQLでも厳密な整合性やト
ランザクションを実現しよう、という動きもある
から、結局はNoSQLとSQLの境目ってなくなるのか
も
• NoSQLを採用するなら、どこで採用するかは慎重
に考えよう。SQLなRDBの方が向いてる領域もたく
さんある。

参考リンク
• NoSQL登場の背景、CAP定理、データモデルの分類
– http://www.publickey1.jp/blog/10/nosqlcap.html
• クラウド上のリレーショナルデータベースはなぜ難しいの
か？ BASEとCAP定理について
– http://www.publickey1.jp/blog/09/_basecap.html
• CAP と BASE について調べたこと
– http://yohei-y.blogspot.com/2009/03/cap-base.html
• CAPのCとACIDのC
– http://yohei-y.blogspot.com/2009/04/yokohamapm-eventually-
consistent.html
• 分散環境でのデータ管理におけるソフトステートのロバスト
性の評価
– http://www-imase.ist.osaka-u.ac.jp/paper/Yamaguchi05_IN12-J.pdf
• この辺から辿れるところを読んでおけば大体把握できるかと