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