NoSQL に関するまとめ

2010/05/28宮下 剛輔

NoSQL とは？• Not Only SQL の略– 元々は本当に「 No SQL 」だったみたいだけど、

印象悪いのでこうなったらしい• SQL を使わない非リレーショナルなデータ

ベースの総称– おおざっぱに言うと MySQL とか PostgreSQL 以外

• どんなものがあるか– kumofs, redis, Amazon SimpleDB, hBase, Cassandra,

memcachedb, CouchDB, 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

• この辺から辿れるところを読んでおけば大体把握できるかと