株式会社 野村総合研究所 オープンソースソリューション推進室
OSC 2014 Enterprise Osaka
世界が注目！MongoDB
2014年9月5日 野村総合研究所 オープンソースソリューション推進室 林田 敦
目次
自己紹介 はじめに
MongoDBの流行について 技術説明
MongoDBの位置づけ MongoDBの特徴
MongoDBを使う上での注意点
MongoDB適用パターン
MMSのご紹介
NRIのサポートサービス
自己紹介
{
"名前": "林田 敦", "年齢": 26,
“仕事”: “NRI OpenStandiaチームでOSS全般を扱う", "趣味": [
"レザークラフト“,"ダイビング“,"スキー“,"キャンプ“,"ジェットスキー“,"カメラ“
],
"リンク": {
"facebook": "https://www.facebook.com/atsushi.hayashida.5“
},
"MongoDB関連": [
"丸の内MongoDB勉強会運営", "MongoDB JP会計担当",
"技術評論社「MongoDBでゆるふわDB体験」執筆“
] }
2
近年増えている「非構造データ」「ビッグデータ」処理はRDBMSには不向き
全体の9割のデータはこの２年で作られています→ビッグデータ 生成されるデータの８割が非構造データです→非構造データ
非構造データはRDBMSには格納できない
非構造データの例
ビックデータはRDBMSでは扱えない
RDBMSのスケールアップでは限界がある。スケールアウト（水平分散）では高コスト。
はじめに
オフィス文章 システムログ 顧客対応履歴
（テキスト・音 声）
電子メール
経理・財務・人 事
営業・CRM・経 営
センサー
情報 位置・地図 ソーシャルメ
ディア・Web 動画 販売実績 他社が保有
するデータ
気象・環境・
情報
健康・医 療
各種統計 行政 金融取引
社内 社外
非構造 化データ
構造化 データ
スケールアップ CPU↑
メモリ↑
ディスク↑
スケールアウト
コントローラ
性能限界
高コスト 限界有り
「MongoDB World 2014 key note」より
「ビックデータ総覧」より
はじめに
NOSQLを検討するのであれば、まずMongoDBを試してください
世界には数多くのNOSQLがありますが、どれも独自のノウハウが必要で、学習コストは高い です
OpenStandiaでは「まずMongoDB」を推奨しています。
MongoDBはRDBMSユーザに使いやすいように作られているため、NOSQLの中では最も学習コス トは低いものの一つです。
また数多くの機能があるため、多くの場合MongoDBを使えば、お客様のRDBMSの課題が解決す ると思います。
利用者が多いため、ノウハウが多い
AWS上で動作保証されている唯一のNOSQL
まずMongoDBを利用し、それでも課題が解決しない場合は、他のNOSQLを検討すべきと考えてい ます
4
MongoDBの流行について(1/4)
db-engines.comでは上位にランキング(2014/9月)
図の引用元：
http://db-engines.com/en/ranking
【指標の考え方】
・ウェブサイトでのシステム 名称の登場回数(Google, Bing)
・一般的な人気度(Google Trends)
・技術的なディスカッション の頻度(Stack
Overflow,DBA Stack Exchange)
・求人サイトにおける募集 スキル(Indeed, Simply Hired)
・プロフィール登場回数 (LinkedIn)
・インストール数は考慮さ れていない
MongoDBの流行について(2/4)
転職サイト(LinkedIN)における人気 NOSQLスキルランキングでは他を圧倒
NoSQLではMongoDBの技術者が圧倒的に多い NoSQL技術の標準になりつつある
6
図の引用元：
http://blogs.the451group.com/information_management/2013/12/
18/nosql-linkedin-skills-index-december-2013/
MongoDBの流行について(3/4)
採用企業600社以上
MongoDBの流行について(4/4)
開発元であるMongoDB,Incは絶好調
MongoDBはオープンソースなので誰でも開発できるが、現時点では実質 MongoDB,Incが開発している。
2013年10月に150,000,000$(約150億円)の投資を受けた。
米MongoDB、1億5000万ドルの資金調達「Oracleに追いつく成熟度を 目指す」
引用元：
http://internet.watch.impress.co.jp/docs/news/20131007_618340.
html
8
MongoDBの位置づけ(1/3)
MongoDBはドキュメント指向データベース
キーバリュー型
Riak, memcached, Redis
KVS RDBMS
MySQL,PostgreSQL, Oracle,SQL Server,DB2
列指向
Bigtable,Cassandra, HBase, DynamoDB
キー 列 array
hash ドキュメント
NOSQL（Not Only SQL）
ドキュメント指向
MongoDB,CouchDB, CouchbaseServer
ドキュメント
データベース
キー 値
キー 値
MongoDBの位置づけ(2/3)
ドキュメント指向データベースとは
データを階層構造のドキュメント(≒JSON)で扱う
JSONとは
ハッシュと配列をネストして使うことができる
XMLよりシンプルに表現できる。読みやすく直観的 ネストが深くなる場合に、より効率的に扱える。
JSONの例
10
｛
ID ： 12345 , name ： ”林田”, address ： {
Company ： “日本”, City ： ”東京”,
ZipNo ： “045-3356”, }
friendID ： [ 3134 , 10231 , 10974 , 11165 ] , hobbies ：
[
{ name ： “自転車” , “year” : 6 } ,
{ name ： “インターネット” , “year” : 10 } , { name ： “読書” , “no” : 16 }
] }
配列
ハッシュの配列 キーと値
ハッシュ
MongoDBの位置づけ(3/3)
ドキュメント指向データベースの比較
MongoDB CouchDB Couchbase Server データ構造 データベース
└コレクション └ドキュメント
データベース └ドキュメント
バケット
└ドキュメント
インデックスの 生成
インデックスを張りたいキーを指定 する
MapReduce関数を用いたビューを作成することで対 応
クエリー 動的クエリ。SQLライクな記述が可 能。
基本的なCRUD以外は、静的クエリ。上記MapReduce で作成したビューへのアクセスがクエリにあたる。
主なインター フェース
独自プロトコル。各言語用専用ドラ イバを利用。
REST(HTTP) memcachedプロトコル レプリケーショ
ン
シングルマスタ型レプリケーション
（１ノードにしか書き込めない）
マルチマスタ型レプリケーション
（複数ノードに書き込める）
開発言語 C++ Erlang C,C++,Erlang
MongoDBの特徴(1/7)
MongoDBを一言でいうと
RDBMSとKVSのいいとこどり
MongoDBの特徴
12
RDBMSから機能を少し だけ削ることにより、高い
スケーラビリティを獲得
水平分散
スキーマレス
多機能 リッチなデータ
レプリケーション
使いやすい
柔軟なクエリ
KVSと比較して RDBMSと比較し
て
MongoDBの特徴
(図の出典： Meiko Hori,Jonathan Reams ,「MongoDBが目指すもの」より https://wiki.mongodb.com/pages/view page.action?pageId=20743144)
MongoDBの特徴(2/7)
.
JSON(階層型データ)は、Key-Valueに比べて、リッチなデータモデル
このようにKey-Valueで１対多を表現しようとすると、key名に"-1"等の 配列の番号を持たせなければならず非常に扱いにくい。
key value
id 10
10-name “hayashida"
10-friendId-0 4 10-friendId-1 7 10-friendId-2 12 10-friendId-3 19
{
id: 10
name: “hayashida"
friendId : [4, 7, 12, 19]
}
リッチなデータ
MongoDBの特徴(3/7)
表現力豊かなクエリ
SQLの文法に似せたクエリが扱いやすい。
動的に作成可能。事前に定義不要。
単純な条件検索だけでなく、集計等の高度なクエリも書ける。
多様なインデックス
セカンダリインデックス：主キー以外でインデックスを作成可能
複合キーインデックス：複数のキーでインデックスを作成可能
マルチキーインデックス：配列の要素に対してインデックス作成可能
14
db.person.find( { "name" : “hayashida", "age" : 26 } ).limit(3) 例）コレクションpersonに、“name”が“hayashida”で、
“age”が26のドキュメントを3つだけ取得したい 柔軟なクエリ
MongoDBの特徴(4/6)
水平分散（シャーディング）が簡単
キーによってデータをノードに分散することができる。また、ノードを動 的に追加し、データの自動バランシング機能もある。
範囲 0-9 範囲10-19 範囲20- x ドキュメント
チャンク
アプリケーション
mongosルータ
1 4 9 11 16 20 27
MongoDB ドライバ
23
23 クエリを適切な
ノードに分散
シャードキーで分 散
ノード ノード ノード
シャードキー
水平分散
ドキュメント
MongoDBの特徴(5/7)
複製（レプリケーション）が簡単
簡単なコマンドで、マスターセカンダリ型のレプリケーションを構築可能。
シャーディングと組み合わせることも可能
MongoDBドライバが自動的に書き込み先を切り替えるため、仮想IPなどを用意しなく てもフェイルオーバが可能（≒クラスタソフトウェアが不要）
16
アプリケーション
プライマリ
1 4 9
セカンダリ
1 4 9
セカンダリ
1 4 MongoDBドライバ
9
書き込み
レプリカセット 読み込み
データ複製
読み込み
書き込めるのは マスタのみ 読み込みは負荷
分散可能
プライマリ
1 4 9
プライマリ
1 4 9
セカンダリ
1 4 9 データ複製
アプリケーション MongoDBドライバ
書き込み 読み込み 読み込み
プライマリが障 害になったら、
プライマリノード を選出し、自動 フェイルオーバ
レプリカセット
レプリケーション
MongoDBの特徴(5/7)
レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立
マシン２
マシン３ マシン１
プライマリ データ１
セカンダリ データ１
セカンダリ データ１ レプリカセット
セカンダリ データ２
プライマリ データ２
セカンダリ データ２ レプリカセット
セカンダリ データ３
セカンダリ データ３
プライマリ データ３ レプリカセット mongosルータ
負荷分散
冗 長 化
アプリケーション
MongoDBの特徴(5/7)
レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立
18
マシン２
マシン３ マシン１
プライマリ データ１
セカンダリ データ１
セカンダリ データ１ レプリカセット
セカンダリ データ２
プライマリ データ２
セカンダリ データ２ レプリカセット
セカンダリ データ３
セカンダリ データ３
プライマリ データ３ レプリカセット mongosルータ
アプリケーション
MongoDBの特徴(6/7)
スキーマレスデータを扱える
テーブル定義など無しに、すぐにデータをCRUDできる
セットアップが非常に簡単
OS毎にバイナリがあるため、ライブラリの追加インストール不要。
起動までわずか３ステップ。
– OS毎のバイナリをダウンロード – データディレクトリを作成 – 起動
RDBMSを使っていた人が使いやすいように作られている
データベース＞テーブル(コレクション)＞ドキュメント というデータ構造
SQLとMongoクエリ言語は大部分マッピング可能
インデックスもSQLと同じような宣言ができる 豊富なドキュメント・ノウハウ
英語ではあるが公式ドキュメントは他のNOSQLに比べても豊富
多くの人が使っているため、ノウハウが豊富。日本語のノウハウも多い。
使いやすい スキーマレス
MongoDB
MongoDBの特徴(7/7)
多機能
20
多機能
分類 機能 説明 ユースケース
機能 GridFS 大容量ファイル(16M以上)を扱うことができる。
大容量ファイルをドキュメントに分割して格納し、アプリ ケーションには等価的なAPIを提供。
大容量ファイルの管理
地理空間インデックス ２Dや３Dのデータを格納し、それに対して交点や近傍など の検索をかけることができる。
アプリでのつくり込不要。
地図アプリのデータベース
キャップ付きコレクショ ン
期限を指定したコレクションを作り、自動的に古いドキュメ ントを引き落とせる
ログ保管
集計機能 SQLのグループ関数のように集計できる。
またmap/reduceによる集計も可能。
データの集計
耐障害 ジャーナリング 単一ドキュメントに対して、書き込みの一貫性が保持でき る。
突然の電源停止等に対応したい
運用性 各種統計コマンド 様々なサーバの統計情報を取得するツールや、JSON形 式で出力するコマンドがある
運用監視ツールとの連携 障害対応効率化
MMS (MongoDB Management Service)
MongoDBの監視やアラート、自動バックアップ、ポイント インタイムリカバリ等ができるサービス
運用監視の仕組みを簡単に作り たい
GridFS API GridFSのイメージ
db.map.find({loc:{$near:[ 139.701238, 35.658871 ]}}) 大容量ファイル 地理空間インデックスを使ったデータに対するクエリ
$nearにより、座標に近 い点を検索
MongoDBを使う上での注意点
トランザクションが無い
MongoDBが複数のドキュメントを一貫性をもって更新する事ができない
ミッションクリティカルで複数のテーブルの更新を保証しなければならないようなシステムで は、利用してはならない。
外部キー・結合が無い
他のドキュメントへの参照はアプリケーションで実装する必要がある。
当然ながら、外部キー制約もないため、テーブル間の整合性が重要なシステムには向いて いない。
複数のドキュメントの内容を結合して取得することはできない。
スキーマが無い
どのようなキー名でデータが入っているかわからない。データ型もわからない。
データ登録間違いの際にエラーが発生しない。
設計書を厳格に管理しないと、どのようなデータが入っているかわからなくなり、保守性の 低下を招く恐れがある。
集計が分散しない
MongoDBのaggregationやMapReduceは分散せず、DBのノードのCPU１コアを使って行わ れる
大規模な集計が必要な場合は他の集計ミドルとの連携が必要。Hadoopとは相性がよい
ユースケース：非構造データ処理
データ集約
既存のレガシーデータの集約基盤として 利用。
スキーマレスであるため、様々なスキーマ のRDBMSからデータを集約することが容 易。
集計したデータは、性能要件の高いモバ イルアプリ等に提供
22
Mongo 集約
既存のSQL資産
app
課題 選定理由・解決策 結果
•顧客データを個別に管理する70以 上の既存RDBMSが存在し、その データを統合をしたいが、RDBMSで は工数がかかりすぎた
•モバイルで利用したいという要件が あるが、端末の増加に合わせてス ケールアップすることがRDBMSでは 難しかった
•既存のRDBMSの情報を統合してア プリケーションを開発。
•MongoDBの開発容易性から、２週 間でプロトタイプが作成でき、90日 でリリースできた。
•１０年間できなかった顧客データの 統合が実現。それも既存の顧客 データには手を入れずに実現できた
•過去同プロジェクトでは約$25M だったものが、約$3Mで達成できた
•企業内外でNOSQLの標準として MongoDBを採用
活用事例： Metlife (保険業）
70以上の既存RDBMSに拡散した顧客情報をMongoDBで統合
ユースケース：非構造データ処理
データハブ/M2M(Machine to Machine)/IOT(Internet of Things)
コストのかかる商用製品の代わりに、MongoDBをデータハブとして利用
M2MではJSONが主流のデータ形式であるが、それをそのまま格納でき、開発不要
既存のDB 既存のアプリ
集約
Mong o
既存のDB 既存のアプリ
API 提供
課題 選定理由・解決策 結果
•データの複製がシステム間で無数に 存在する
•一つのシステムでの変更が複数の グループに影響
•EDWのシステムレスポンスタイムが 遅い
•頻繁にアクセスするデータは集中的 に管理したい，というニーズ
•動的なスキーマ: 必要な時だけデー タを正規化する
•性能: 一つの論理DBで全てのデー タを管理・運用
•シャーディング: スケールアウトにより データを容易に追加
•一カ所からバッチ，もしくはRESTで データアクセス可能
•顧客向けポータルサイトのレスポン スタイムが90%改善
•開発期間の短縮データソースのエン ハンスが容易
活用事例： グローバル信託銀行X社 (金融業）
企業内でのデータアクセスを統合するために、データハブとして利用
ユースケース：非構造データ処理
RDBMSとMongoDBのハイブリッド
スキーマレスが向いているデータのみを MongoDBで処理することにより、スキーマ 変更の負荷軽減や、性能向上が可能。
特に商品カタログ等のフォーマットが様々で 更新頻度が多いデータに向いている。
24
Mong o app
カタログ
（スキーマレス）
課金情報等
（SQL）
カタログ メンテナンス
課題 選定理由・解決策 結果
•要件として
「スキーマレスデータに対してSQLと 同等のクエリをかけたい」
「NOSQLに不慣れな開発者にも簡 単にクエリをかける」
というものがあった
•従来のRDBMSでは上記の要件を満 たせなかった。
•MongoDBであれば要件を満たして いた
•他のNOSQL技術と比較しても、利 用実績が多く、流行してるため技術 者も多かった
•NOSQLの中では唯一社内のサポー ト体制が整っていた。
•開発者が簡単にスキーマレスデータ を操作でき、開発生産性を高く保つ ことができた
•スキーマデータはRDBMS、スキーマ レスデータはMongoDBという使い分 けがうまくできた
•冗長化の設計工数が、他のDB技術 と比較し、飛躍的に少なくすんだ
活用事例： 野村総合研究所 (SIer）
カード会社向けシステムで、スキーマレスデータ処理にMongoDBを利用
ユースケース：ビッグデータ
Webアプリ／オンラインゲーム
大量トラフィックのWebシステム/オンラインゲー ムでメインDBとして
ユーザの増加に合わせて横に並べればＯＫ リッチなデータ構造を扱えるので、複雑なアプリ ケーションにも対応
app
Mong o Mong
o
app
Mong o internet
app Mong
o Mong
o Mong
o
Mong o Mong
o Mong
o
課題 選定理由・解決策 結果
•MySQLがスケーラビリティの上限に 達して性能要件を達成できなくなっ た
•RBMSでは非定型なメタデータの管 理が困難
•性能とスケーラビリティに期待し MongoDBを導入
•60億におよぶ属性情報データの代 わりに、１コンテンツを１ドキュメント にする構造を導入
•秒間11万件以上のクエリに対応
•３年で200万ドル以上のコスト削減
•新規機能の導入のスピードが著しく 早くなった
•新規プロジェクトでは全てMongoDB を利用する方針となった
活用事例： orange(Webサービス事業）
７００万ユーザを超えるWebサービスのバックグラウンドDBとして利用
ユースケース：ビッグデータ
分析データ格納
安価なハードウェアに大量データを分散して格納できる
データが大規模でなければ、MongoDBの集計機能で十分に要件を満たせる
動的に柔軟にクエリー組み立てる事ができ、新規分析軸の導入が容易
様々なキーに対して、複雑なインデックスを張ることができる
データのクリーニングせずにとりあえず入れて、集計時に必要な項目のみ集計する事が可能
– RDBMSであればデータの挿入にひと手間あったが、それが不要
連携できるBIツールが多い(Pentaho,Jaspersoft等)
データが大規模な場合は、他の分析基盤（Hadoop等)との連携を推奨
26
課題 選定理由・解決策 結果
•他技術ではスケーラビリティと機能 がともに十分なものが無い
•Hbase/Hadoopでは複雑なクエリに 対応できない
•Luceneではスケーラビリティに問題 があり
•MongoDBの自動シャーディングでス ケーラビリティを実現
•動的に柔軟なクエリが書けるため、
新しい分析結果を追加する場合の 開発が簡単
•地理空間インデックスの利用により、
地理的な観点でのデータ分析が容 易に
•レイテンシーを1/3に削減
•動的スキーマの変更が可能になり、
開発者の生産性が大幅に向上
•市場に対する新しいサービスの投入 が迅速化
活用事例： McAfee
セキュリティサービスのビッグデータ解析にMongoDBを利用
ユースケース：その他
拠点間連携
各拠をまたがりレプリカセットを組むことにより、多拠点で同じデータが見れる レプリケーションの耐久性が高く、多少遅延のある通信経路でも構築可能
レプリケーションの機能により、物理的に近い拠点からデータを複製することが可能
Mongo
Mongo
Mongo Mongo
Mongo
バッチコピー レプリケーション
課題 選定理由・解決策 結果
•バッチ処理によるデータ配布の遅れ が最大36時間に及ぶ
•同じデータのグローバル配信に複数 課金されるSLA未達成による規制 違反（罰金）
•同じを保有する20カ所の分散シス テムを管理する必要性
•自動レプリケーション: データ配信が リアルタイム、ローカルにデータを読 む事が可能
•キャッシュとデータベースの同期:
キャッシュが常にアップデート
•単純なデータモデリングと分析: 変 更が簡単、理解しやすい
•違反金$40,000,000を5年間の間 に節約
•データ配信に対する課金は一回の み
•グローバルにデータ同期と各拠点で のローカルReadが保証
•統一したグローバルデータサービス に移行
活用事例： グローバル信託銀行X社 (金融業）
各拠点で迅速にローカルアクセス出来る様に、データをリアルタイムで配布
ユースケース：その他
ログ格納
様々なログの形式を蓄積可能
キャップ付きコレクションで、古いログを自動的に消せる
とりあえずレプリケーションしておけば、データは冗長化できる
MongoDBにとりあえずログをためておき、そのほかの集計ミドルウェアで集計するという使 い方がよい
アジャイル開発
アジャイル開発ではスキーマの変更頻度が非常に高い 直観的にデータを表現できるため、データの扱いが簡単
ORマッパーを使う必要はなく、ライトウェイトなスクリプト言語(javascript,ruby)との相性が よい。
アプリ開発をサポートする機能が沢山ある
28
MMS～MongoDB管理サービス～
MongoDBの自動運用管理をしてくれるサービス 監視
MongoDBの各種統計情報収集、グラフ化、監視 閾値を指定して超えたらアラートメール送付
バックアップ
スナップショット取得・リカバリ 差分バックアップ
ポイントインタイムリカバリ
（時間指定リカバリ）
オートメーション
無停止バージョンアップ ワンクリック環境構築
MMS～MongoDB管理サービス～
MMSとMMSエージェントの役割分担
MMS監視エージェント
MongoDBから情報を取得し、暗号化してMMSに情報を送る
MMSバックアップエージェント
MongoDBから定期的にスナップショットや更新ログ(oplog)を取得する。
MMS指示のもと、MongoDBのリストアやポイントインタイムリカバリを行う
30
アラート メール
MMS 監視エージェント
MMS
バックアップエージェント
MongoDB oplog data
MongoDB oplog data
MongoDB oplog data
MMS (MongoDB Monitoring Service) 監視ダッシュ
ボード
バックアップ・
リストア指示
情報収集 バックアップ
（oplogコピー）
ブラウザ
リストア
データ送付（暗号化） データ送付（暗号化）
・MongoDBに接続できる 場所であればどこでもOK
・一台のMMSエージェント で、複数台のMongoDBと 接続することができる
MMS～MongoDB管理サービス～
クラウド版とオンプレ版
MMSはクラウド版とオンプレ版があります。MMSエージェントはその区別 はありません。
クラウド版
インターネットにあり、アカウントを作るとだれでも利用可能。
モニタリングは無料
バックアップは有料だが、$5/月以下の利用は無料
オンプレ版
自前の環境にMMSサーバをインストールできる
情報を外に出せない企業向け
NRIのサポートサービス (1/2)
野村総合研究所はMongoDB Incと正式な代理店契約を結んでおり、MongoDBのサブスクリプ ションを販売しております
MongoDBのサブスクリプションの種類
サブスクリプションを購入いただくと、OpenStandiaのオープンソース年間サポートサービスを受け ることができます。
製品ライフサイクル
以下のうち長い方が製品のライフサイクルとなる
リリースされてから18ヶ月
次のバージョンがリリースされてから1年
32
コミュニティー版 Core Advanced
ライセンス AGPL 商用ライセンス 商用ライセンス
利用バイナリ コミュニティ版 商用版 商用版
機 能
SSL暗号化 × ○ ○
ケルベロス/LDAP認証 × × ○
監査 × × ○
Red Hat Identity Management Certification × ○ ○ ＯＳ動作保証Windows ,
Linux(RHEL, CentOS, Ubuntu, Amazon, SuSE)
× × ○
SNMP × × ○
オンプレミス版MMS × ○ ○
緊急パッチ × ○ ○
NRIのサポートサービス(2/2)
サポート対象
MongoDB本体(MongoDB, Mongosルータ, MongoDBクライアント,各種ツール) MongoDB Management Service オンプレミス版
各言語のMongoDB用ドライバ C#,Casbah,ScalaDriver,Java,Node.js,Python,PHP,Ruby
サブスクリプションの数え方
サブスクリプションは１インスタンス単位で購入が必要 1インスタンスは「データの入っているインスタンス」である 以下のインスタンスはカウントしない
アービタ(レプリカセットに入るがデータは持っていなく、プライマリ選出の投票にのみ 参加するノード)
mongosルータ
configサーバ
プライマ リ
セカンダ リ
セカンダ リ データ
複製
例）３台レプリケーション サブスクリプション：３つ
プライマ リ
セカンダ リ
アービタ データ
複製
例）２台レプリケーション サブスクリプション：２つ
例）３台シャーディング サブスクリプション：３つ
データ 複製
mongosルータ
1
2 3
1
2 1 2 3
config サーバ
株式会社 野村総合研究所 オープンソースソリューション推進室 34
[email protected] http://openstandia.jp/
お問い合わせは、NRIオープンソースソリューション推進室へ
本資料に掲載されている会社名、製品名、サービス名 は各社の登録商標、又は商標です。
【補足】MongoDB機能一覧
機能 MongoDBでの対応状況
機能性 問合せ 条件検索 ○可能
DISTINCT ○可能
LIKE検索 △英語のみ可能（日本語は不可）
ROWID、ROWNUM、
ROW_NUMBER △結果行数指定の使い方は可能
グループ集計 ○可能
ソート ○可能
正規表現 ○可能
WITH句/副問い合わせ △パイプラインで一部代替可能
TRUNCATE ○可能
再帰クエリ ×不可
ユニオン/結合 ×不可
全文検索 △英語のみ可能（日本語は不可）
トランザクション管理 ×不可
排他制御 ×不可
制約/整合性機能 ×不可 インデック
ス オンライン追加・削除 ○可能 セカンダリインデックス ○可能 複合インデックス ○可能 マルチキーインデックス ○可能 データ 基本データ型 ○可能
大容量ファイル格納 △16M以上のファイルは別DB（GridFS）での管 理
マルチメディア △大容量ファイルの分散管理が可能 空間データ ◎座標系データの検索が可能
OLAP ×不可
操作 管理ツール（CUI） ○可能
管理ツール（GUI） △基本操作が可能（アドバイザ等はなし）
その他 動的SQL ○可能 データベーストリガ ×なし
ジャーナリング ○ドキュメント単位で一貫性保証 ストアドプロシージャ/ファン
クション ○可能 javascriptで記述
一時表 △キャップ付きコレクションで保管期間を決め られる
シーケンス △ストアドプロシージャで処理を代替可能
機能 MongoDBでの対応状況
可用性 耐障害性 ○レプリケーションで冗長構成可能 復旧容易性(ノード復旧） ○ノード起動により自動復旧 データ損失許容時間 ○クエリごとに制御可能 拡張性 シャーディングノード追加 ○オンラインで追加可能 レプリケーションノード追加 ○オンラインで追加可能
メモリ追加 ○可能
ディスク追加 ○可能
運用性 統計情報出力 ○付属のコマンドで可能 データダンプ・リストア ○付属のコマンドで可能 インポート ○JSONをインポート可能
監視 ○MMSで監視可能
OS監視 ○MMSとmuninの組み合わせにより可能
バックアップ ○MMSにて自動バックアップ、ポイントインタイ ムリカバリ可能
バージョンアップ ○レプリケーションを組んでローリングアップデー トすればシステム停止無しで実施可能 サポート ○OpenStandiaにてサポート可能
機密性 アクセス制御 ○可能
暗号化 ○商用版でSSL利用可能 監査ログ ○商用版で利用可能
MongoDBの事例
MongoDBは様々な用途に幅広く使えるため、事例も幅広い
36
分類 利用している
MongoDBの特徴
紹介する事例 Webアプリ・オンラ
インゲーム
•水平分散
•リッチなデータ [国内][SNS] CyberAgent
[国内][Web] 楽天 [海外][Web] orange [国内][Web] ZenClerk スキーマレスデー
タ処理
•スキーマレス
•柔軟なクエリ [国内][SIer] 野村総合研究所
データハブ •スキーマレス
•使いやすい [海外][保険] MetLife
[海外][金融]グローバル信託銀行 X社(事例１) データ統合 •スキーマレス
•使いやすい [国内][Sier] ペタデータ株式会社(事例１)
[国内][Sier] ペタデータ株式会社(事例２) データ分析 •水平分散
•柔軟なクエリ [海外][セキュリティ] McAfee
拠点間データ連 携
•レプリケーション
•使いやすい [海外][金融]グローバル信託銀行 X社(事例２)
アジャイル開発 •スキーマレス
•多機能
•使いやすい
[国内][Web] 株式会社キッチハイク [国内][SIer] M社
ログ収集 •スキーマレス
•多機能
•レプリケーション
[国内][SIer]野村総合研究所
MongoDBの事例 Webアプリ・オンラインゲーム
利用される理由
複雑なデータモデルを扱う事ができる
データの水平分散により高スループットを出すことができる
近年は、利用ユーザの増加などによるトラフィックの増加が激しく、RDBMS では性能の限界になる事が多い
特にユーザログインがあるようなWebアプリケーション
水平分散 リッチなデータ
MongoDBの事例 Webアプリ・オンラインゲーム [国内][SNS] Cyber Agent
アメーバピグにて利用
国内のMongoDB事例の先駆け
slideshareの「MongoDBを半年間運用してみた」(2011/7)は有名
38 引用元：http://www.slideshare.net/matsukaz/mongo-db-8707809
MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] 楽天
楽天のWebサイトポータルにて利用
課題 選定理由・解決策 結果
•MySQLベースのストレージシ ステムがEOSの為、システム 再構築を行う必要があった
•ポータルサイトは書き込みが 少なく、読み出しが非常に 多い非対称なクエリバラン スである事から MongoDBを 採用した。
•性能検証の結果、キャッシュ 層が必要無い程の性能が 確認できた。
• レプリケーションによるデー タ冗長性、安全性も優れて いた事からRDBMSから完全 に脱却した。
•ロジック過負荷になっても MongoDBの超えることは無 かったため データ破壊など 致命的な状態には至らな かった。
MongoDBの事例 Webアプリ・オンラインゲーム [海外][Web] orange
700万のウェブ・モバイルユーザに対する広範囲コンテンツ・サ ービス提供
40
課題 選定理由・解決策 結果
•MySQLがスケーラビリティの 上限に達して性能要件を達 成できなくなった
•RBMSでは非定型なメタ データの管理が困難
•性能とスケーラビリティに期 待しMongoDBを導入
•60億におよぶ属性情報 データの代わりに、１コンテ ンツを１ドキュメントにする構 造を導入
•秒間11万件以上のクエリ に対応
•３年で200万ドル以上のコ スト削減
•新規機能の導入のスピード が著しく早くなった
•新規プロジェクトでは全て MongoDBを利用する方針と なった
引用元：http://www.mongodb.com/customers/orange-digital
MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] ZenClerk
MongoDBを活用した分析でサイト訪問者の購買意欲の高まりを いち早く察知し、 クーポンの"ベストタイミングオファー"を実現
課題 選定理由・解決策 結果
•PCとスマートフォンから来る 大量のジェスチャー情報を 書き込む必要があった
•RDBMSでは安定した処理 ができなかった。
•スキーマレスデータを扱える
•RDBMSと遜色がないほど柔 軟なクエリを組むことができ
•柔軟なイン デックスを用い て高速な読み込みができた。
•サーバーを増やす だけで容 易にスケールアウトすること ができた。
•サーバー1台だけで秒間 1,000アクセス以上の負荷 に耐えることができた。
•性能向上はサーバの台数を 増やすだけで良く、コス トが 見積もり易い。
•レプリケーションを柔軟に利 用し、ホットス タンバイ、
バッチ集計用、リアルタイム 集計を分けて、柔軟な運用 ができた
MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] ZenClerk
システム構成
42
MongoDBの事例 スキーマレスデータ処理
利用される理由
近年、データの種類が多様になってきており、事前にスキーマを定義する ことが困難
代表的なものはユーザプロファイルデータ。ユーザによって項目がまちまち。
MongoDBはスキーマレスデータを扱える上に、他のNOSQLにはない強力 なクエリを持っている
スキーマレス 柔軟なクエリ
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 スキーマレスデータ処理 [国内][SIer] 野村総合研究所
カード会社向けシステムで、アプリケーションの一部のスキーマレ スデータ処理にMongoDBを利用
44
課題 選定理由・解決策 結果
•要件として
「スキーマレスデータに対し てSQLと同等のクエリをかけ たい」
「NOSQLに不慣れな開発者 にも簡単にクエリをかける」
というものがあった
•従来のRDBMSでは上記の 要件を満たせなかった。
•MongoDBであれば要件を満 たしていた
•他のNOSQL技術と比較して も、利用実績が多く、流行 してるため技術者も多かっ た
•NOSQLの中では唯一社内 のサポート体制が整ってい た。
•開発者が簡単にスキーマレ スデータを操作でき、開発 生産性を高く保つことがで きた
•スキーマデータはRDBMS、
スキーマレスデータは
MongoDBという使い分けが うまくできた
•冗長化の設計工数が、他の DB技術と比較し、飛躍的に 少なくすんだ
ー 開発チームの所感 ー
RDBMSである必要がなく、「スキーマレスデータが扱いたい」、
もしくは「極端に性能が必要」な場合は、MongoDBは非常にマッチする
MongoDBの事例 データ統合
利用される理由
多数の分散された既存データソースのデータをMongoDBに集約して、ア プリケーションに対してビューとして提供する
既存のデータソースに手を加える必要はない
アプリケーションに対しては高速なビューを提供可能
スキーマレス 使いやすい
MongoDB
データを集約 ユーザ
既存のデータソース
アプリケーション
MongoDBの事例 データ統合 [海外][保険] MetLife
70以上の既存RDBMSに拡散した顧客情報を MongoDBで統合
46
課題 選定理由・解決策 結果
•顧客データを個別に管理す る70以上の既存RDBMSが 存在し、そのデータを統合を したいが、RDBMSでは工数 がかかりすぎた
•モバイルで利用したいとい う要件があるが、端末の増 加に合わせてスケールアッ プすることがRDBMSでは難 しかった
•既存のRDBMSの情報を統 合してアプリケーションを開 発。
•MongoDBの開発容易性か ら、２週間でプロトタイプが 作成でき、90日でリリースで きた。
•１０年間できなかった顧客 データの統合が実現。それ も既存の顧客データには手 を入れずに実現できた
•巨額な投資が必要な RDBMS統合を、安価(約
$3M)に、迅速に、達成でき た(過去同プロジェクトでは 約$25M)
•企業内外でNOSQLの標準 としてMongoDBを採用
(出典 MongoDB Inc http://www.mongodb.com/press/metlife-leapfrogs-insurance-industry-mongodb-powered-big-data-application)
MongoDBの事例 データ統合 [海外][保険] MetLife
システム構成
MongoDB
データを集約 ユーザ
既存の顧客データ(約70台)
アプリケー ション
MongoDBの事例 データ統合
[国内][SIer] ペタデータ株式会社（事例１）
音楽専門放送業 大手「株式会社スペースシャワーネットワーク」70以上の配 信サイトの配信実績情報の統合サービス （Allegro IoT）にMongoDBを活用
公式HP：http://petadata.jp/ja/OurWorks001.html
48
課題 選定理由・解決策 結果
•配信実績情報は事業者毎 に異なるフォーマットであり、
それを統一する必要があっ た。
•一部の事業者の配信実績 情報を手作業で整形してい た。
•フォーマットが変更されるこ ともあり、事前にスキーマが 決定できないため、 従来の RDBMSに格納が難しかった。
•スキーマを決定する前に、シ ステムに取込む必要があっ たため。
•容易にレプリケーションが可 能なため。
•手作業によるミスがなくなり、
事務作業が格段に減った。
利用企業より好評を得てい る
MongoDBの事例 データ統合
[国内][SIer] ペタデータ株式会社（事例2）
製薬会社 中堅S社 異なる温度センサーのリアルタイム温度情報の統合サー ビス （Allegro IoT）にMongoDBを活用
公式HP：http://petadata.jp/ja/OurWorks002.html
課題 選定理由・解決策 結果
•リアルタイム温度管理が必 要だった。
•温度センサーからの温度情 報のフォーマットが変更され ることがあり、その都 度シ ステムの修正が必要だった。
•温度情報のフォーマットが変 更された場合、設定の変更 だけで対応する手段が な かった。
•温度情報はXMLだったが、
XMLのツリー情報をそのまま 取り込む必要があった。
•パフォーマンスを保ちつつ、
スキーマレスで温度情報を 取り込む必要があった ため。
•ツリー情報をそのまま取り込 むことができるため。（JSON を取り込めるため）
•容易にレプリケーションが可 能なため。
•温度情報のフォーマットの変 更があっても取得が可能に なった。 （取得後にフォー マット変更があったか判断 すればよくなった。）
•リリース以来（2014年3月 で2年2か月）一度も停止す ることなく運用しているため、
システム運用の手間が減っ た。
MongoDBの事例 データハブ
利用される理由
スキーマレスであるため、様々な形式のデータソースのデータを格納でき る
ドライバが豊富であり、アプリも作りやすい
50
スキーマレス 使いやすい
アプリX アプリ１
アプリ２
アプリ３ データソース１
データソース２
データソース３
データソースN
バッチコピー
アプリX アプリ１
アプリ２
アプリ３ データソース１
データソース２
データソース３
データソースN
Mongo DB
バッチコピー API
・・・・・・ ・・・ ・・・
MongoDBの事例 データハブ
[海外][金融]グローバル信託銀行 X社（事例１）
企業内でのデータアクセスを統合するために、データ ハブとして利用
課題 選定理由・解決策 結果
•データの複製がシステム間 で無数に存在する
•一つのシステムでの変更が 複数のグループに影響
•EDWのシステムレスポンスタ イムが遅い
•頻繁にアクセスするデータ は集中的に管理したい，と いうニーズ
•動的なスキーマ: 必要な時 だけデータを正規化する
•性能: 一つの論理DBで全て のデータを管理・運用
•シャーディング: スケールアウ トによりデータを容易に追加
•一カ所からバッチ，もしくは RESTでデータアクセス可能
•顧客向けポータルサイトのレ スポンスタイムが90%改善
•開発期間の短縮データソー スのエンハンスが容易
MongoDBの事例 データハブ
[海外][金融]グローバル信託銀行 X社（事例１）
導入前後比較
52
アプリX アプリ１
アプリ２
アプリ３ データソース１
データソース２
データソース３
データソースN
バッチコピー
アプリX アプリ１
アプリ２
アプリ３ データソース１
データソース２
データソース３
データソースN
Mongo DB
バッチコピー API
・・・・・・ ・・・ ・・・
MongoDBの事例 データ分析
利用される理由
水平分散で大量のデータを扱う事ができる
安価なハードウェアで大量データを扱える
動的に柔軟にクエリー組み立てる事ができる
新規分析軸の導入が用意
様々なキーに対して、複雑なインデックスを張ることができる
大容量でなければ、既存機能だけでSQL並みの集計をすることができる
注意点
現状のMap Reduce機能は、単一ノードでしか動作せず、分散しない。
分散処理させたければMongo-Hadoop連携機能などを利用することを 推奨する。
水平分散 柔軟なクエリ
