狈辞厂蚕尝に関するまとめ
- 2. NoSQLとは？ ? Not Only SQLの略 – 元々は本当に「No SQL」だったみたいだけ ど、印象悪いのでこうなったらしい ? SQLを使わない非リレーショナルなデータ ベースの総称 – おおざっぱに言うとMySQLとかPostgreSQL以外 ? どんなものがあるか – kumofs, redis, Amazon SimpleDB, hBase, Cassandra, memcachedb, Couch DB, MongoDB, ...
- 3. NoSQL登場の背景 ? RDBでは大規模なウェブ環境に対応できな くなってきた。特にスケーラビリティの 面で。 – MySQLでのスケーラビリティを考える – readのスケーラビリティ: レプリケーション ＋ロードバランシング – writeのスケーラビリティ: sharding/partitioning – いずれにしろ、MySQL単体では実現できず、 別の技術やアプリケーション側での工夫が必 要 ? sharding/partitioningについてはSpiderやPacificと いった選択肢もある
- 5. ACIDからBASEへ ? ACID: データベースのトランザクション特性 – Atomicity - トランザクションに含まれるタスクが 全て実行されるか、あるいは全く実行されないこ とを保証する性質 – Consistency -トランザクション開始と終了時にあ らかじめ与えられた整合性を満たすことを保証す る性質 – Isolation -トランザクション中に行われる操作の過 程が他の操作から隠蔽されることを指す – Durability -トランザクション操作の完了通知を ユーザが受けた時点で、その操作は永続的とな り、結果が失われないことを指す。
- 6. ACIDからBASEへ ? ACIDからConsistencyとIsolationを捨て去る ことによって、 – 可用性が向上 – 性能劣化しにくい – スケーラビリティが向上 ? BASE – Basically Available – Soft-state – Eventual consitency
- 7. BASE ? Basically Available – いつでもデータにアクセスできることが重要 ? Soft-state – ゆるい状態管理/データ管理 – 高負荷時の耐性が高い ? Eventual consistency – 結果整合性。途中でデータに不整合が起きて も、結果的に整合性がとれてればOK
- 8. Soft-stateをちょっと詳しく ? 状態管理の手法には、Hard-stateとSoft-stateがある ? 状態とは、ノードの生死やデータの状態 ? 定期的にリフレッシュデータを送って状態確認す るのがSoft-state – データはベストエフォートで送信 ? 状態が変わったときだけデータ送信して状態確認 するのがHard-state – データは信頼性の高い方法で送信 – 再送制御が必要 ? 高負荷の時にはソフトステートの方が耐障害性が 高いという調査結果
- 9. 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
- 10. ACIDからBASEへ ? スケーラビリティのためにACID の概念を緩 和。その結果出てくる考えがBASE。 ? ただし ACID は個別のデータベースのトラン ザクション特性なのに対し、BASE はデータ ベース機能を含んだシステム全体の特性をさ すものなので、一概に比較できるものでもな い ? ACIDとBASEは共存可能。システム全体は BASE、システムを構成する個別のDBはACID、 といった感じで。 ? 実際のシステムはACIDが必要なところとBASE で十分な部分が混在している
- 11. CAP定理 ? スケーラビリティや整合性に関する定理 ? Consitency – 誰かがデータを更新したら、その後は必ず更新後の データが返る ? Availability – クライアントは必ずデータにアクセスできる ? Partition tolerance – 耐ネットワーク分断性 – データを複数サーバに分散して保存できる、と読み 替えても良い ? この3つのうち、2つまでしか同時に満たせない、 というのがCAP定理
- 12. CAP定理の適用 ? ConsistencyとAvailability – データはいつでも利用可能で一貫している – 単一データベースサーバ – 可用性あげるためには HA 構成になる？（この辺 微妙） ? ConsitsencyとPartition torelance – データを分散しつつも整合性を保持 – 整合性保持のため、複製中はすべてのノードで データが更新されるまでロックをかけて不整合を 阻止 – ロックかかってる最中はAvailableではない
- 13. CAP定理の適用 ? AvailabilityとPartition torelance – データは分散され、いつでもデータにアクセスでき る – データ複製中は不整合な状態になりえる – DNSなんかはその例 ? 大規模分散システムにはこのAとPを満たすことが 重要 ? Cはある程度妥協する(Eventual Consistency) ? ただし、VerticaはNoSQLながらもStrong Consitency らしい ? CとAを満たすものがRDB。CとPやAとPを満たすも のがNoSQL
- 14. ここまでのまとめ ? NoSQLはSQLをつかわない非RDBなデータ ベース ? ACIDとBASE ? CAP定理 ? 大規模ウェブはPとAが重要 ? Cは妥協する(Eventual consistency)
- 16. NoSQLのデータモデルによる分 類 ? Key-Value ? 列指向の表形式 ? ドキュメント指向
- 18. 列指向の表形式 ? 行指向の対義語 ? 行指向は内部的に行単位でデータを保持 – 少数の行に対する多くの列の取得が効率的で ある。行あたりのサイズが小さい場合には、 行全体を1度のディスクシークで読み取ること ができる。 – 少数の行に対する多くの列の更新が効率的で ある。1行全体の書き出しを、1度のディスク シークで行うことができる。 – OLTPに向いている
- 19. 列指向の表形式 ? 列指向は内部的に列単位でデータを保持 – 大量の行に対する少数の列の集約処理が効率的で ある。列数が少ないほど、読み込むデータ量を減 らすことができる。 – 全行に対する少数の列の一括更新が効率的であ る。新規に列データを作成し、以前のデータと置 換することで、他の列へのアクセスを回避でき る。 – データが列ごとにまとまってるので、列の追加が 容易 – OLAPに向いている
- 20. ドキュメント指向 ? XMLやJSONなどの半構造データ ? {“name”: “John Smith”, “age”: 33} といった 形でデータを出し入れ ? フィールドの数や長さに特に制限はない
- 21. データモデルで分類したソフト ウェア ? Key-Value – Tokyo Cabinet, Dynamo, Redis, Kai, kumofs ? 列指向 – Cassndra, hBase, HyperTable, BigTable, Vertica ? ドキュメント指向 – CouchDB, SimpleDB, MongoDB, Terrastore
- 23. まとめ ? データモデル – Key-Value – 列指向表形式 – ドキュメント指向 ? すべてに共通なのはスキーマレス
- 25. ConsistencyとAvailability ? MySQL ? PostgreSQL ? Aster Data ? Greenplum ? Vertica 赤はリレーショナル, 緑は列指向
- 26. ConsistencyとPartition torelance ? BigTable ? Hypertable ? Hbase ? MongoDB ? Terrastore ? MemcacheDB ? Redis 緑は列指向、紫はドキュメント指向、青はKey- Value
- 27. AvailabilityとPartition torelance ? Cassandra ? SimpleDB ? CouchDB ? Riak ? Dynamo ? Voldemort ? Kai 緑は列指向、紫はドキュメント指向、青はKey- Value
- 28. CAP定理による分類まとめ ? CAP定理にしたがって分類してみた（って いうかひとが分類したのを載せただけ） ? でも、あまり厳密に理論のことは考えな くていいです ? おおざっぱにしっておけば翱碍
- 29. まとめ
- 30. まとめ ? ACIDとかBASEとかCAPとか説明したけど、ACIDと BASEは適用範囲も違ったり、ACIDのCとCAPのCは 意味が違ったりするので、厳密に考えると混乱す るから、なんとなくの考え方を掴んでおけばOK ? NoSQLといっても、BigTableはGQLというSQLライク な言語が使えるし、NoSQLでも厳密な整合性やト ランザクションを実現しよう、という動きもある から、結局はNoSQLとSQLの境目ってなくなるのか も ? NoSQLを採用するなら、どこで採用するかは慎重 に考えよう。SQLなRDBの方が向いてる領域もたく さんある。
- 31. 参考リンク ? 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 ? この辺から辿れるところを読んでおけば大体把握できるかと