Downloaded 64 times
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 • この辺から辿れるところを読んでおけば大体把握できるかと