世界が注目！mongodb - obci.jp · mongodbの流行について(4/4)...

株式会社野村総合研究所オープンソースソリューション推進室

Mail ： [email protected] Web： http://openstandia.jp/

OSC 2014 Enterprise Osaka

世界が注目！MongoDB

2014年9月5日

野村総合研究所

オープンソースソリューション推進室

林田敦


目次

自己紹介

はじめに

MongoDBの流行について

技術説明 MongoDBの位置づけ

MongoDBの特徴

MongoDBを使う上での注意点

MongoDB適用パターン MMSのご紹介

NRIのサポートサービス

1


自己紹介

{

"名前": "林田敦",

"年齢": 26,

“仕事”: “NRI OpenStandiaチームでOSS全般を扱う",

"趣味": [

"レザークラフト“,"ダイビング“,"スキー“,"キャンプ“,"ジェットスキー“,"カメラ“

],

"リンク": {

"facebook": "https://www.facebook.com/atsushi.hayashida.5“

},

"MongoDB関連": [

"丸の内MongoDB勉強会運営",

"MongoDB JP会計担当",

"技術評論社「MongoDBでゆるふわDB体験」執筆“

]

} 2


近年増えている「非構造データ」「ビッグデータ」処理はRDBMSには不向き全体の9割のデータはこの２年で作られています→ビッグデータ

生成されるデータの８割が非構造データです→非構造データ

非構造データはRDBMSには格納できない非構造データの例

ビックデータはRDBMSでは扱えない RDBMSのスケールアップでは限界がある。スケールアウト（水平分散）では高コスト。

はじめに

3

オフィス文章システムログ

顧客対応履歴（テキスト・音

声）

電子メール

経理・財務・人事

営業・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月)

5

図の引用元： http://db-engines.com/en/ranking

【指標の考え方】・ウェブサイトでのシステム名称の登場回数(Google,

Bing)

・一般的な人気度(Google

Trends)

・技術的なディスカッションの頻度(Stack

Overflow,DBA Stack

Exchange)

・求人サイトにおける募集スキル(Indeed, Simply

Hired)

・プロフィール登場回数(LinkedIn)

・インストール数は考慮されていない

http://db-engines.com/en/ranking





転職サイト(LinkedIN)における人気 NOSQLスキルランキングでは他を圧倒

NoSQLではMongoDBの技術者が圧倒的に多い

NoSQL技術の標準になりつつある

6

図の引用元： http://blogs.the451group.com/information_management/2013/12/

18/nosql-linkedin-skills-index-december-2013/

http://blogs.the451group.com/information_management/2013/12/18/nosql-linkedin-skills-index-december-2013/














採用企業600社以上

7



開発元である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はドキュメント指向データベース

9

キーバリュー型 Riak, memcached,

Redis

KVS

RDBMS MySQL,PostgreSQL,

Oracle,SQL Server,DB2

列指向 Bigtable,Cassandra,

HBase, DynamoDB

キー列 array

hash

ドキュメント

NOSQL（Not Only SQL）

ドキュメント指向 MongoDB,CouchDB,

CouchbaseServer

ドキュメント

データベース

キー値

キー

値



ドキュメント指向データベースとはデータを階層構造のドキュメント(≒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 } ] }

配列

ハッシュの配列

キーと値

ハッシュ



11

ドキュメント指向データベースの比較

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)



. JSON(階層型データ)は、Key-Valueに比べて、リッチなデータモデル

このようにKey-Valueで１対多を表現しようとすると、key名に"-1"等の配列の番号を持たせなければならず非常に扱いにくい。

13

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] }

リッチなデータ



表現力豊かなクエリ

SQLの文法に似せたクエリが扱いやすい。

動的に作成可能。事前に定義不要。

単純な条件検索だけでなく、集計等の高度なクエリも書ける。

多様なインデックス

セカンダリインデックス：主キー以外でインデックスを作成可能

複合キーインデックス：複数のキーでインデックスを作成可能

マルチキーインデックス：配列の要素に対してインデックス作成可能

14

db.person.find( { "name" : “hayashida", "age" : 26 } ).limit(3)

例）コレクションpersonに、“name”が“hayashida”で、

“age”が26のドキュメントを3つだけ取得したい

柔軟なクエリ



水平分散（シャーディング）が簡単

キーによってデータをノードに分散することができる。また、ノードを動的に追加し、データの自動バランシング機能もある。

15

範囲 0-9 範囲10-19 範囲20-

x ドキュメント

チャンク

アプリケーション

mongosルータ

1 4 9 11 16 20 27

MongoDB ドライバ

23

23 クエリを適切なノードに分散

シャードキーで分散

ノードノードノード

シャードキー

水平分散


ドキュメント


複製（レプリケーション）が簡単

簡単なコマンドで、マスターセカンダリ型のレプリケーションを構築可能。

シャーディングと組み合わせることも可能

MongoDBドライバが自動的に書き込み先を切り替えるため、仮想IPなどを用意しなくてもフェイルオーバが可能（≒クラスタソフトウェアが不要）

16


プライマリ

1 4 9

セカンダリ

1 4 9

セカンダリ

1 4

MongoDBドライバ

9

書き込み

レプリカセット

読み込み

データ複製

読み込み

書き込めるのはマスタのみ

読み込みは負荷分散可能

プライマリ

1 4 9

プライマリ

1 4 9

セカンダリ

1 4 9 データ複製


MongoDBドライバ

書き込み読み込み読み込み

プライマリが障害になったら、プライマリノードを選出し、自動フェイルオーバ





レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立

17

マシン２

マシン３

マシン１プライマリデータ１

セカンダリデータ１



セカンダリデータ２

プライマリデータ２



セカンダリデータ３


プライマリデータ３


mongosルータ

負荷分散

冗長化




レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立

18

マシン２

マシン３

マシン１プライマリデータ１





プライマリデータ２





プライマリデータ３


mongosルータ




スキーマレスデータを扱える

テーブル定義など無しに、すぐにデータをCRUDできる

セットアップが非常に簡単

OS毎にバイナリがあるため、ライブラリの追加インストール不要。

起動までわずか３ステップ。

– OS毎のバイナリをダウンロード

– データディレクトリを作成

– 起動

RDBMSを使っていた人が使いやすいように作られている

データベース＞テーブル(コレクション)＞ドキュメントというデータ構造

SQLとMongoクエリ言語は大部分マッピング可能

インデックスもSQLと同じような宣言ができる

豊富なドキュメント・ノウハウ

英語ではあるが公式ドキュメントは他のNOSQLに比べても豊富

多くの人が使っているため、ノウハウが豊富。日本語のノウハウも多い。

19

使いやすい

スキーマレス


Mo

ng

oD

B


多機能

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とは相性がよい

21


ユースケース：非構造データ処理

データ集約既存のレガシーデータの集約基盤として利用。

スキーマレスであるため、様々なスキーマの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が主流のデータ形式であるが、それをそのまま格納でき、開発不要

23

既存の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として

ユーザの増加に合わせて横に並べればＯＫ

リッチなデータ構造を扱えるので、複雑なアプリケーションにも対応

25

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を利用


ユースケース：その他

拠点間連携各拠をまたがりレプリカセットを組むことにより、多拠点で同じデータが見れる

レプリケーションの耐久性が高く、多少遅延のある通信経路でも構築可能

レプリケーションの機能により、物理的に近い拠点からデータを複製することが可能

27

Mongo

Mongo

Mongo

Mongo

Mongo

バッチコピーレプリケーション


•バッチ処理によるデータ配布の遅れが最大36時間に及ぶ •同じデータのグローバル配信に複数課金されるSLA未達成による規制違反（罰金） •同じを保有する20カ所の分散システムを管理する必要性

•自動レプリケーション: データ配信がリアルタイム、ローカルにデータを読む事が可能 •キャッシュとデータベースの同期: キャッシュが常にアップデート •単純なデータモデリングと分析: 変更が簡単、理解しやすい

•違反金$40,000,000を5年間の間に節約 •データ配信に対する課金は一回のみ •グローバルにデータ同期と各拠点でのローカルReadが保証 •統一したグローバルデータサービスに移行

活用事例：グローバル信託銀行X社 (金融業）各拠点で迅速にローカルアクセス出来る様に、データをリアルタイムで配布


ユースケース：その他

ログ格納様々なログの形式を蓄積可能

キャップ付きコレクションで、古いログを自動的に消せる

とりあえずレプリケーションしておけば、データは冗長化できる

MongoDBにとりあえずログをためておき、そのほかの集計ミドルウェアで集計するという使い方がよい

アジャイル開発アジャイル開発ではスキーマの変更頻度が非常に高い

直観的にデータを表現できるため、データの扱いが簡単

ORマッパーを使う必要はなく、ライトウェイトなスクリプト言語(javascript,ruby)との相性がよい。

アプリ開発をサポートする機能が沢山ある

28


MMS～MongoDB管理サービス～

MongoDBの自動運用管理をしてくれるサービス

監視 MongoDBの各種統計情報収集、グラフ化、監視

閾値を指定して超えたらアラートメール送付

バックアップスナップショット取得・リカバリ

差分バックアップ

ポイントインタイムリカバリ（時間指定リカバリ）

オートメーション無停止バージョンアップ

ワンクリック環境構築

29



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はクラウド版とオンプレ版があります。MMSエージェントはその区別はありません。

クラウド版

インターネットにあり、アカウントを作るとだれでも利用可能。

モニタリングは無料

バックアップは有料だが、$5/月以下の利用は無料

オンプレ版

自前の環境にMMSサーバをインストールできる

情報を外に出せない企業向け

31


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サーバ

33

プライマリ

セカンダリ

セカンダリ

データ複製

例）３台レプリケーション

サブスクリプション：３つ

プライマリ

セカンダリ

アービタ

データ複製

例）２台レプリケーション

サブスクリプション：２つ

例）３台シャーディング

サブスクリプション：３つ

データ複製

mongosルータ 1

2 3

1

2 1 2 3

config

サーバ

株式会社野村総合研究所オープンソースソリューション推進室 34 株式会社野村総合研究所オープンソースソリューション推進室

[email protected] http://openstandia.jp/

お問い合わせは、NRIオープンソースソリューション推進室へ

本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。


【補足】MongoDB機能一覧

35

機能 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アプリケーション

37

水平分散リッチなデータ


MongoDBの事例 Webアプリ・オンラインゲーム [国内][SNS] Cyber Agent

アメーバピグにて利用国内のMongoDB事例の先駆け

slideshareの「MongoDBを半年間運用してみた」(2011/7)は有名

38 引用元：http://www.slideshare.net/matsukaz/mongo-db-8707809

http://www.slideshare.net/matsukaz/mongo-db-8707809






MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] 楽天

楽天のWebサイトポータルにて利用

39


•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

http://www.mongodb.com/customers/orange-digital




MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] ZenClerk

MongoDBを活用した分析でサイト訪問者の購買意欲の高まりをいち早く察知し、クーポンの"ベストタイミングオファー"を実現

41


•PCとスマートフォンから来る大量のジェスチャー情報を書き込む必要があった •RDBMSでは安定した処理ができなかった。

•スキーマレスデータを扱える •RDBMSと遜色がないほど柔軟なクエリを組むことができ •柔軟なインデックスを用いて高速な読み込みができた。 •サーバーを増やすだけで容易にスケールアウトすることができた。

•サーバー1台だけで秒間1,000アクセス以上の負荷に耐えることができた。 •性能向上はサーバの台数を増やすだけで良く、コストが見積もり易い。 •レプリケーションを柔軟に利用し、ホットスタンバイ、バッチ集計用、リアルタイム集計を分けて、柔軟な運用ができた


MongoDBの事例 Webアプリ・オンラインゲーム [国内][Web] ZenClerk

システム構成

42


MongoDBの事例スキーマレスデータ処理

利用される理由近年、データの種類が多様になってきており、事前にスキーマを定義することが困難

代表的なものはユーザプロファイルデータ。ユーザによって項目がまちまち。

MongoDBはスキーマレスデータを扱える上に、他のNOSQLにはない強力なクエリを持っている

43

スキーマレス柔軟なクエリ


MongoDBの事例スキーマレスデータ処理 [国内][SIer] 野村総合研究所

カード会社向けシステムで、アプリケーションの一部のスキーマレスデータ処理にMongoDBを利用

44


•要件として「スキーマレスデータに対してSQLと同等のクエリをかけたい」「NOSQLに不慣れな開発者にも簡単にクエリをかける」というものがあった •従来のRDBMSでは上記の要件を満たせなかった。

•MongoDBであれば要件を満たしていた •他のNOSQL技術と比較しても、利用実績が多く、流行してるため技術者も多かった •NOSQLの中では唯一社内のサポート体制が整っていた。

•開発者が簡単にスキーマレスデータを操作でき、開発生産性を高く保つことができた •スキーマデータはRDBMS、スキーマレスデータはMongoDBという使い分けがうまくできた •冗長化の設計工数が、他のDB技術と比較し、飛躍的に少なくすんだ

ー開発チームの所感ー RDBMSである必要がなく、「スキーマレスデータが扱いたい」、もしくは「極端に性能が必要」な場合は、MongoDBは非常にマッチする


MongoDBの事例データ統合

利用される理由多数の分散された既存データソースのデータをMongoDBに集約して、アプリケーションに対してビューとして提供する

既存のデータソースに手を加える必要はない

アプリケーションに対しては高速なビューを提供可能

45

スキーマレス使いやすい

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

システム構成

47

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

49


•リアルタイム温度管理が必要だった。 •温度センサーからの温度情報のフォーマットが変更されることがあり、その都度システムの修正が必要だった。 •温度情報のフォーマットが変更された場合、設定の変更だけで対応する手段がなかった。 •温度情報はXMLだったが、XMLのツリー情報をそのまま取り込む必要があった。

•パフォーマンスを保ちつつ、スキーマレスで温度情報を取り込む必要があったため。 •ツリー情報をそのまま取り込むことができるため。（JSONを取り込めるため） •容易にレプリケーションが可能なため。

•温度情報のフォーマットの変更があっても取得が可能になった。（取得後にフォーマット変更があったか判断すればよくなった。） •リリース以来（2014年3月で2年2か月）一度も停止することなく運用しているため、システム運用の手間が減った。


MongoDBの事例データハブ

利用される理由スキーマレスであるため、様々な形式のデータソースのデータを格納できる

ドライバが豊富であり、アプリも作りやすい

50

スキーマレス使いやすい

アプリX

アプリ１

アプリ２

アプリ３

データソース１

データソース２

データソース３

データソースN

バッチコピー

アプリX

アプリ１

アプリ２

アプリ３




データソースN

Mongo DB

バッチコピー API

・・・

・・・

・・・

・・・


MongoDBの事例データハブ [海外][金融]グローバル信託銀行 X社（事例１）

企業内でのデータアクセスを統合するために、データハブとして利用

51


•データの複製がシステム間で無数に存在する •一つのシステムでの変更が複数のグループに影響 •EDWのシステムレスポンスタイムが遅い •頻繁にアクセスするデータは集中的に管理したい，というニーズ

•動的なスキーマ: 必要な時だけデータを正規化する •性能: 一つの論理DBで全てのデータを管理・運用 •シャーディング: スケールアウトによりデータを容易に追加

•一カ所からバッチ，もしくはRESTでデータアクセス可能 •顧客向けポータルサイトのレスポンスタイムが90%改善 •開発期間の短縮データソースのエンハンスが容易


MongoDBの事例データハブ [海外][金融]グローバル信託銀行 X社（事例１）

導入前後比較

52

アプリX

アプリ１

アプリ２

アプリ３




データソースN

バッチコピー

アプリX

アプリ１

アプリ２

アプリ３




データソースN

Mongo DB

バッチコピー API

・・・

・・・

・・・

・・・


MongoDBの事例データ分析

利用される理由水平分散で大量のデータを扱う事ができる

安価なハードウェアで大量データを扱える

動的に柔軟にクエリー組み立てる事ができる

新規分析軸の導入が用意

様々なキーに対して、複雑なインデックスを張ることができる

大容量でなければ、既存機能だけでSQL並みの集計をすることができる

注意点現状のMap Reduce機能は、単一ノードでしか動作せず、分散しない。分散処理させたければMongo-Hadoop連携機能などを利用することを推奨する。

53

水平分散柔軟なクエリ


MongoDBの事例データ分析 [海外][セキュリティ] McAfee

セキュリティサービスのビッグデータ解析にMongoDBを利用

54


•他技術ではスケーラビリティと機能がともに十分なものが無い •Hbase/Hadoopでは複雑なクエリに対応できない •Luceneではスケーラビリティに問題があり

•MongoDBの自動シャーディングでスケーラビリティを実現 •動的に柔軟なクエリが書けるため、新しい分析結果を追加する場合の開発が簡単 •地理空間インデックスの利用により、地理的な観点でのデータ分析が容易に

•レイテンシーを1/3に削減 •動的スキーマの変更が可能になり、開発者の生産性が大幅に向上 •市場に対する新しいサービスの投入が迅速化

(事例の出典 MongoDB,Inc http://www.mongodb.com/customers/mcafee)


MongoDB事例拠点間連携

利用される理由各拠をまたがりレプリカセットを組むことにより、タ拠点で同じデータが見れる

レプリケーションの耐久性が高く、多少遅延のある通信経路でも構築可能

レプリケーションの機能により、物理的に近い拠点からデータを複製することが可能

レプリケーションの構成が柔軟

書き込み一貫性が柔軟(w値,j値)

多様なセカンダリreadonly,hidden,delayed

55


使いやすい


MongoDBの事例拠点間連携 [海外][金融]グローバル信託銀行 X社（事例２）

各拠点で迅速にローカルアクセス出来る様に、参照データをリアルタイムで分散／配布

56


•バッチ処理によるデータ配布の遅れが最大36時間に及ぶ •同じデータのグローバル配信に複数課金されるSLA未達成による規制違反（罰金） •同じを保有する20カ所の分散システムを管理する必要性

•自動レプリケーション: データ配信がリアルタイム、ローカルにデータを読む事が可能 •キャッシュとデータベースの同期: キャッシュが常にアップデート •単純なデータモデリングと分析: 変更が簡単、理解しやすい

•違反金$40,000,000を5年間の間に節約 •データ配信に対する課金は一回のみ •グローバルにデータ同期と各拠点でのローカルReadが保証 •統一したグローバルデータサービスに移行


MongoDBの事例拠点間連携 [海外][金融]グローバル信託銀行 X社（事例２）

新旧のシステム構成比較

57

バッチ連携

ゴールデン

コピー


プライマリ


近い拠点からデータを読み取る


MongoDBの事例拠点間連携 [国内][VOD]ビデオオンデマンド業Ｃ社

スキーマレスデータであるメタデータやユーザの行動履歴の格納レプリケーションを使って拠点間連携も容易に

58


•ビデオのメタデータやユーザの行動履歴等、高スループットで高更新が求められるデータを格納したい •データ毎に格納すべき情報が異なるため、スキーマレスで格納したい •拠点間をまたがってデータをレプリケーションしたい •商用RDBMSを利用していたが、ライセンス費用が高かったため、低コストで実現したい

•MongoDBのレプリカセット機能を用いて、拠点間でデータをレプリケーション。拠点ごとに読み込みを分散させると同時に、冗長性も確保。 •課金などのミッションクリティカルな部分は、RDBMS(PostgreSQL)を利用。SQLとNOSQLのハイブリッド構成


MongoDBの事例拠点間連携 [国内][VOD]ビデオオンデマンド業Ｃ社

システム構成図

59

拠点A

拠点B

アプリケーションサーバ

アプリケーションサーバ

ユーザ

読み込み

書き込み

データ


MongoDB レプリカセット


MongoDBの事例アジャイル開発

利用される理由アジャイル開発ではスキーマの変更頻度が非常に高い

直観的にデータを表現できるため、データの扱いが簡単

ORマッパーを使う必要はなく、ライトウェイトなスクリプト言語(javascript,ruby)との相性がよい。

アプリ開発をサポートする機能が沢山ある

その他ハッカソンなどでは常連のDB

60

スキーマレス多機能使いやすい


MongoDBの事例アジャイル開発 [国内][SIer] M社

Webシステム作成案件で可用性を求めてMongoDBを利用

61


•新規に構築するWebサービスにおいてダウンタイムレスでレプリケーションによる高可用性を実現したい。 •RDBMSではレプリケーションを行うにはそれなりの手間が必要 •新規案件であるためスピード感のある開発が求められた

•MongoDBを採用し、レプリカセットの構成を実現

•スキーマレスの利点を生かし作りながら考えることにより、短期間で開発を完了できた。 •レプリカセットによりシンプルな構成でダウンタイムレスの高可用性を実現できた。


MongoDBの事例アジャイル開発 [国内][Web] 株式会社キッチハイク

スタートアップ企業にてRuby on Railsのバックグラウンドで採用

62


•機能追加・仕様変更が多い •新規Webサービスではデータサイズの見積りが難しい。 •位置情報（経度・緯度）の扱いに適したデータベースを探していた。 •Ruby on Railsで利用できるDBを利用したい

•スキーマを決めずに開発を開始できる •データ容量の拡張が簡単 •位置情報の扱いが得意

•日常的に起こる機能追加・仕様変更に素早く対応できた。 •ユーザー数増加に伴うデータサイズの増加にも対応できるので、安心してサービス成長に取り組める。 •地理空間インデックス機能を使って、位置情報を使用するクエリを簡単に実装できた。


MongoDBの事例ログ情報の蓄積

利用される理由様々なログの形式を蓄積可能

キャップ付きコレクションで、古いログを自動的に消せる

とりあえずレプリケーションしておけば、データは冗長化できる

MongoDBにとりあえずログをためておき、そのほかの集計ミドルウェアで集計するという使い方がよい

注意点他の集計ミドルがよい理由は、たとえば、時系列データを日付をキーにして水平分散させると、検索頻度の高いレンジ（例えば今週、今月）のデータが格納されているシャードに負荷が偏ってしまう

63

スキーマレス多機能レプリケーション


MongoDBの事例ログ情報の蓄積 [国内][SIer] 野村総合研究所

サーバのログ収集にログ収集ミドルウェア(fluentd)と MongoDBを組みあわせて利用

64


•サーバが多く、障害時にログ情報を収集する手間がかかっていた

•ログ収集ミドルウェア(fluentd)と組み合わせて各サーバのログを自動的に収集できる。

•障害対応の効率UP •MongoDBは運用が簡単であるためログ運用負荷も高くない


MongoDBの事例ソフトウェア組み込み

OSSのバックグラウンドDBとして数多く利用されている

Jaspersoft(ETL・レポーティング・BI)

Pentaho(ETL・レポーティング・BI)

qlik view(商用BI)

talend(ETL)

Splunk(商用M2M)

MongoDBをデフォルトとしているソフトウェアもある

fluentd(ログ収集基盤)

65

世界が注目！mongodb - obci.jp · mongodbの流行について(4/4)...

Documents