Mongo dbを知ろう devlove関西

1. MongoDBを知ろう＠DevLove関西 2014/10/20 玉川竜司

2. 自己紹介 • 玉川竜司 • FB: Ryuji Tamagawa • Twitter: @tamagawa_ryuji • 本業ソフト開発（Sky株式会社） • 兼業翻訳者（ほぼオライリー）

3. What’s New & Next

4. 今日のお題は MongoDB

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. ご清聴ありがとうございました。

SlideShare for iOS

Mongo dbを知ろう devlove関西

by 玉川竜司 , Software Developer, Translator at Sky / home

on Oct 20, 2014

Statistics

Views

Actions

1 Embed 7

Accessibility

Categories

Upload Details

Usage Rights

Report content