Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie NoSQLに関するまとめ
Ähnlich wie NoSQLに関するまとめ (20)
Mehr von Gosuke Miyashita
Mehr von Gosuke Miyashita (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
NoSQLに関するまとめ
- 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定理にしたがって分類してみた（って いうかひとが分類したのを載せただけ） • でも、あまり厳密に理論のことは考えな くていいです • おおざっぱにしっておけばOK
- 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 • この辺から辿れるところを読んでおけば大体把握できるかと