Mongo dbを知ろう devlove関西
•
11 gostaram•2,512 visualizações
2014/10/20 DevLove関西 「MongoDBを知ろう」発表スライドです。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Mongo dbを知ろう devlove関西
Semelhante a Mongo dbを知ろう devlove関西 (20)
Mais de Ryuji Tamagawa
Mais de Ryuji Tamagawa (16)
Último
Último (12)
Mongo dbを知ろう devlove関西
- 2. 自己紹介 • 玉川竜司 • FB: Ryuji Tamagawa • Twitter: @tamagawa_ryuji • 本業ソフト開発（Sky株式会社） • 兼業翻訳者（ほぼオライリー）
- 3. What’s New & Next
- 5. 話の流れ • NoSQLってなんだろう • MongoDBの概要 • MongoDBのユースケース • MongoDBの特徴
- 6. NoSQLってなんだろう
- 7. NoSQLムーブメント • Not Only SQL : SQL（RDB）以外の選択肢 • 2010年前後のビッグデータブームの立ち上がりとともに 注目を集め始めた技術／データベース／バズワード／… • 特徴を一言で言うなら、RDBの特徴（の一部）を捨てる ことで「データの量に対するスケーラビリティ」を大幅 に向上させたもの
- 8. RDBが抱えている（いた）課題 • データの量に対してスケーラビリティが低い • 大きな要因は、ストレージのランダムI/Oの低速 性、テーブルの結合処理のコスト、ACID属性 • ただしこれらは、実はRDBの長所の裏返しで もある • 商用DBは、一般にスケールアウトのオプション が非常に高価 https://www.youtube.com/watch?v=9eMWG3fwiEU
- 9. シンプルなNoSQL • 基本的には、主キーだけをインデックスとして持つフラットな（分 散）ストレージ • ACID属性？何それ美味しいの？ • アプリケーション側から見ると、 単純なインデックスで高速にアクセスできる、スケーラビリティの 高い永続化層
- 10. もう少し高機能なNoSQL • ドキュメント（JSON）ストレージへの進化 • セカンダリインデックス • MongoDBやCouchBaseが代表選手
- 11. RDBとNoSQL：得意な領域 データの量 RDBが 得意な領域 どうやっても 難しい領域 NoSQLが 得意な領域 なんでもOKな 領域 データモデルの厳密性
- 12. RDBとNoSQL：デバイスの進化の影響 データの量 RDBが 得意な領域 NoSQLが 得意な領域 なんでもOKな データモデルの厳密性 領域 どうやっ ても 難しい領域 メモリ容量の増大と SSDの普及
- 13. RDBとNoSQL：トレードオフ • データ量の増大に伴って、単純な2択ではすまなくなることがでてきた • ストレージ層を選択する上で、データモデル、スケーラビリティ、動作 環境、運用コスト、開発工数などを考慮しなければならない ファイルシステムRDB ファイルシステム単純なNoSQL 高機能なNoSQL RDB
- 14. RDBとNoSQL • RDBの重要性に変わりはない。技術として、しっかり持っておくべきもの • その上で、状況によってはNoSQLを使ったほうがいい場合を判断する • 一般に、RDBに比べてNoSQLでの開発は、アプリケーション側のロジッ クの複雑化を招くことには注意 • そして、RDBに比べれば、NoSQLははるかに多種多様であり、１つのカ テゴリにくくること自体に無理がある。技術者の知識とセンスが問われる
- 15. MongoDBの概要
- 16. MongoDBのいいところ • 一言で言うなら「お手軽」 - いい意味で • Webアプリケーションで求められる機能が手っ取り早く使える • 多目的の高性能「オートマ車」 • インストーラやパッケージですぐ動きます • セカンダリインデックスやクエリオプティマイザがある • 多くの言語で、仕様がある程度統一されているドライバが利用可能
- 17. MEANスタック • JSONでバックエンドからフロント エンドまで統一 • MongoDB、Express、 AngularJS、Node.js • 英語の本はたくさん出てます
- 18. エコシステムの形成 • 世界的に見れば、NoSQLデータベースとしては最もメジャーな存在になっ てきた → 周辺が充実してきている • クラウド上で実績多数。MongoHQなど、as a serviceでも提供されてい る • GUIツールも増えてきました • MMS（http://www.mongodb.com/mongodb-management-service） - バックアップ、運用管理などを行ってくれる本家のクラウドサービス
- 19. ただし • 集計は（今のところ）ちょっと苦手 - とはいえ改善中 • （ほんとの）ビッグデータはちょっと難しいかも • 基本的に、オンメモリでいけるかどうかが問題 • そういえば、でかいメモリのインスタンス、AWSでもAzureで もさくらでも増えましたね･･･
- 20. MongoDBのユースケース
- 21. openstandia.jp
- 22. MongoDBの特徴
- 23. RDBとの違い • 物理構造の違い • 論理構造の違い • トレードオフの柔軟性 • レプリカセット • シャーディング
- 24. 物理構造の違い RDB MongoDB 物理メモリ物理メモリ DBエンジンが管理する メモリバッファ サイズを 指定できる データファイル メモリにマップされた ファイルの内容 サイズを 指定できない データファイル （メモリマップドファイル）
- 25. 物理構造の違い（２） • とにかく、「ホット」なデータが物理メモリに収まるかが肝心 • RDBほど細かなメモリのチューニングはできない • データが大きいなら、RAMを増やすか、シャーディングでスケール アウト
- 26. 論理構造の違い RDB MongoDB { _id: new ObjectId(""), slug: "gardening-tools", ancestors: [{ name: "Home", _id: new ObjectId(""), slug: "home" }, { name: "Outdoors", _id: new ObjectId(“"), slug: "outdoors" } ], }
- 27. 論理構造の違い（２） • スキーマの自由度は高い（特に変更に強い） • ドキュメントを超えたアトミック性はない • 設計上のトレードオフが生じる • 一つのドキュメントで閉じない場合はIDで参照 • そうなると、処理をプログラムで書く必要が出てくる
- 28. トレードオフの柔軟性 RDB MongoDB 書いたら 必ず 永続化 書き込み結果は 必ず確認 書き込み保証 する？しない？ しなけりゃ高速 WAL使う？ いくつのレプリ カへ書けたら成功 したことにする？
- 29. トレードオフの柔軟性（2） • 書き込みの確実性とパフォーマンスはトレードオフ • 大量のログの記録などでは、多少こぼれるリスクを抱えてもコストダウ ンしたいこともある • 逆に、データセンター間で複製できていることを保証したいこともある • 書き込み保証（Write Concern）、WAL、レプリカへの書き込み、タ ギングなどで、多彩な調整が可能
- 30. レプリカセットとシャーディングについて • これらについては、「技術的には」RDBとの対立概念ではない • ただし、商用RDBではコストが跳ね上がる（ですよね？）機能 • MongoDBでは最初から組み込まれて、非常にお手軽 & 便利 • 大まかには • 読み込みのパフォーマンスと耐障害性を向上させるのがレプリカセット • 書き込みのパフォーマンスを向上させるのがシャーディング
- 31. レプリカセット Repreca-Master Client-App Driver Repreca-Slave Repreca-Slave 書込 複製 読取 oploogplog oplog oplog
- 32. oplogについて • Capped Collection : 追記のみ、古いデー タが自動的に削除される • oplog : データベースの更新処理を時系 列で記録するcapped collection • プライマリのoplogをセカンダリのoplog が追いかけることでレプリケーションを 行う Primary Secondary Secondary
- 33. レプリカセット Repreca-Master Client-App Driver Repreca-Slave Repreca-Slave 書込 複製 読取 oploogplog oplog oplog
- 34. レプリカセット（マスター交代） Repreca-Master Repreca-Master Repreca-Slave 書込 複製 Client-App Driver 読取 oploogplog opolopglog oploogplog
- 35. 障害発生時のoplog • 交代したプライマリと生きているセ カンダリのoplogは先へ進んでいく • 停止中の元プライマリのoplogはも ちろん止まったまま 元Primary （停止中） 現Primary Secondary
- 36. レプリカセット（リカバリ中） Repreca-Slave (リカバリ中) Repreca-Master Repreca-Slave 書込 複製 Client-App Driver 読取 追いつくまで複製 もしくはフルコピー opolopglog opolopglog
- 37. 障害回復時のoplog（1） • 回復したセカンダリが、現プラ イマリのoplogを見て追いつい ていく Secondary 現Primary Secondary
- 38. 障害回復時のoplog（2） • 障害が長く続き、現プライマリの oplogと回復したセカンダリのoplog がオーバーラップしなくなってしまっ た場合 • 仕方ないので自動的にfull syncに移 行する • こうなると時間も負荷もかかるので、 oplogの期間設定やファイルベースの バックアップ間隔は重要 Secondary 現Primary Secondary
- 39. レプリカセット（リカバリ後） Repreca-Slave Repreca-Master Repreca-Slave 書込 複製 Client-App Driver 読取 複製oopplologg opolpolgog opolpolgog
- 40. レプリカセット（バックアップのコストダウン） Repreca-Master （インデックスあり） Client-App Driver Repreca-Slave （インデックスあり） Repreca-Slave （バックアップ） 書込 複製 読取 バックアップ用のインスタン スにはインデックスを付けず、 非力なマシンで済ませる
- 41. レプリカセット （誤操作、バグ対策） Repreca-Master （インデックスあり） Client-App Driver Repreca-Slave （インデックスあり） 指定した時間遅らせて複製。 誤操作によるデータ消去 などの対策 Repreca-Slave （バックアップ） 書込 複製 読取 Repreca-Slave （delayed）
- 42. レプリカセット（DC間での分散） Repreca-Master 複製 Client-App Driver Repreca-Slave Repreca-Slave 書込 読取 DC-1 DC-2
- 43. レプリカセットのまとめ • 読み取り負荷の分散 • 耐障害性 • 自動フェイルオーバー & リカバリ • 多彩なトレードオフ
- 44. シャーディング • 書き込み負荷を1/nに • メモリ量をn倍に • パフォーマンスは上がる •障害は起きやすくなる →レプリカセットと併用 Client-App Driver mongos mongod for あかさたな mongod for はまやらわ
- 45. 改善継続中 - 2.6以降について少し • 最新バージョンは2.6系 • aggregation framework - サイズの制約の緩和 • Write protocolの改善 - レイテンシの低減 • Index Intersection - 複数インデクスの同時活用のはず… • 2.8/3.0はかなり大規模なアップデートになる模様
- 46. まとめ
- 47. 今日話したこと • 運用についてはドキュメントをきっちり読見ましょう • この本に基本は書かれています。概要把握にどうぞ。 • 電子書籍もあります。 • http://www.oreilly.co.jp/books/ 9784873115900/ • そのほかにもMongoDB関連の電子書籍があるの で、オライリージャパンのサイトで検索を。
- 48. それはともかく • 簡単に始められて • かなり深く使うこともできます • ただし落とし穴もあります →コミュニティへどうぞ！ http://www.mongodb.jp • まずは手を動かしてみましょう！ • レプリカセットをお手軽に試せます： • https://bitbucket.org/tamagawa_ryuji/mongodb_replicaset_playground_on_vagrant
- 49. ご清聴ありがとうございました。