Your SlideShare is downloading. ×
0
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
NoSQLに関するまとめ
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

NoSQLに関するまとめ

8,226

Published on

Published in: Technology
0 Comments
30 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
8,226
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
48
Comments
0
Likes
30
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. NoSQLに関するまとめ2010/05/28宮下 剛輔
  • 2. NoSQLとは?• Not Only SQLの略– 元々は本当に「No SQL」だったみたいだけど、印象悪いのでこうなったらしい• SQLを使わない非リレーショナルなデータベースの総称– おおざっぱに言うとMySQLとかPostgreSQL以外• どんなものがあるか– kumofs, redis, AmazonSimpleDB, hBase, Cassandra, memcachedb, CouchDB, MongoDB, ...
  • 3. NoSQL登場の背景• RDBでは大規模なウェブ環境に対応できなくなってきた。特にスケーラビリティの面で。– MySQLでのスケーラビリティを考える– readのスケーラビリティ: レプリケーション+ロードバランシング– writeのスケーラビリティ: sharding/partitioning– いずれにしろ、MySQL単体では実現できず、別の技術やアプリケーション側での工夫が必要• sharding/partitioningについてはSpiderやPacificといった選択肢もある
  • 4. NoSQL登場の背景• スケーラビリティ向上のためには、ACIDからBASEへ
  • 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対BASEACID• Strong Consistency• Isolation• Focus on “commit”• Nested transactions• Availability?• Conservative(pessimistic)• Difficult evolution(e.g.schema)BASE• Weak consistency – staledata 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. データモデルによるNOSQLデータベースの分類
  • 16. NoSQLのデータモデルによる分類• Key-Value• 列指向の表形式• ドキュメント指向
  • 17. 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
  • 22. すべてのデータモデルに共通なこと• スキーマレス– 柔軟な拡張が可能
  • 23. まとめ• データモデル– Key-Value– 列指向表形式– ドキュメント指向• すべてに共通なのはスキーマレス
  • 24. CAP定理に基づくデータベースの分類
  • 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• この辺から辿れるところを読んでおけば大体把握できるかと

×