Downloaded 64 times
More Related Content
![[db tech showcase Tokyo 2014] L32: Apache Cassandraに注目！！（IoT, Bigdata、NoSQLのバ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbtstokyo2014l32datastaxapachecassandraiotbigdatanosql-141120022255-conversion-gate02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[db tech showcase Tokyo 2015] A33:Amazon DynamoDB Deep Dive by アマゾン データ サービス ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015a33amazon-dynamodbamazondataservicejapan-150623010315-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[db tech showcase Tokyo 2015] A27: RDBエンジニアの為のNOSQL, 今どうしてNOSQLなのか？](https://cdn.slidesharecdn.com/ss_thumbnails/a27nosqlforrdbengineer-150624020431-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
NoSQLに関するまとめ
- 1.
- 2. NoSQLとは？ • Not OnlySQLの略 – 元々は本当に「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と いった選択肢もある
- 4.
- 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)
- 15.
- 16.
- 17.
- 18. 列指向の表形式 • 行指向の対義語 • 行指向は内部的に行単位でデータを保持 –少数の行に対する多くの列の取得が効率的で ある。行あたりのサイズが小さい場合には、 行全体を1度のディスクシークで読み取ること ができる。 – 少数の行に対する多くの列の更新が効率的で ある。1行全体の書き出しを、1度のディスク シークで行うことができる。 – OLTPに向いている
- 19. 列指向の表形式 • 列指向は内部的に列単位でデータを保持 – 大量の行に対する少数の列の集約処理が効率的で ある。列数が少ないほど、読み込むデータ量を減 らすことができる。 –全行に対する少数の列の一括更新が効率的であ る。新規に列データを作成し、以前のデータと置 換することで、他の列へのアクセスを回避でき る。 – データが列ごとにまとまってるので、列の追加が 容易 – OLAPに向いている
- 20. ドキュメント指向 • XMLやJSONなどの半構造データ • {“name”:“John Smith”, “age”: 33} といった 形でデータを出し入れ • フィールドの数や長さに特に制限はない
- 21. データモデルで分類したソフト ウェア • Key-Value – TokyoCabinet, Dynamo, Redis, Kai, kumofs • 列指向 – Cassndra, hBase, HyperTable, BigTable, Vertica • ドキュメント指向 – CouchDB, SimpleDB, MongoDB, Terrastore
- 22.
- 23. まとめ • データモデル – Key-Value –列指向表形式 – ドキュメント指向 • すべてに共通なのはスキーマレス
- 24.
- 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.
- 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 • この辺から辿れるところを読んでおけば大体把握できるかと