mongodb事例紹介 - openstandia.jp · 株式会社野村総合研究所...

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

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

MongoDB事例紹介＠db tech showcase 大阪 2014

2014年6月19日

株式会社野村総合研究所

OpenStandiaチーム

主任テクニカルエンジニア

渡部徹太郎


目次

17:00 – 17:50

背景(3分)

MongoDBのキホン(7分)

MongoD流行(5分)

MongoDBの事例(30分)

質疑応答(5分)

1


自己紹介

2

{ "ID" ："fetaro", "名前" ："渡部徹太郎",

"所属" ：[ , ],

"経歴" ："学生時代は情報検索の研究(@日本データベース学会)", "仕事" ：{"昔":"証券会社のオントレシステムのWeb基盤", "今":"オープンソース全般"}, "特技" ：["Linux","ruby","MongoDB"], "ｴﾃﾞｨﾀ" ："emacs派", "趣味" ："自宅サーバ", "MongoDB関連"：{ －"gihyojp「MongoDBでゆるふわDB体験」", －"日経SYSTEMS 8月号「ドキュメント指向データベース」", －"丸の内MongoDB勉強会"} "属性" : ["ギーク", "スーツ"] }

http://fetarodc.blogspot.jp/

http://gihyo.jp/dev/serial/01/mongodb





背景その１ :ビックデータ

近年、コンピュータシステムに置いて扱うデータ量が増えている。 2011年に生成されたデータ量は1.8ZB、2020年には50倍に増加し、必要とされるサーバは現在の10倍、蓄積されるファイル数は75倍に増えると予想されている

インターネットに接続する端末数が増加したため。2011年に40億台、2015年には150億台に拡大と予想。

ソーシャルメディアの利用拡大により情報発信が増えている。情報発信者数は2010年1650万人であったが2012年3290万人と拡大。

クラウドコンピューティングの利用により大容量のデータを安価に扱えるようになった

センサー情報の爆発2010年からの10年間でデータ量は44倍になると予想されている

このようなビックデータをRDBMSで対応するのは困難

スケールアップによる対応では限界がある

スケールアウトは高コスト。

(出典「図解ビックデータ早わかり」）

スケールアップテーブルパーティショニング

スケールアウト

コントローラ

高コスト性能限界

限界がある

CPU↑ メモリ↑

ディスク↑


背景その２：スキーマレスデータ

データの増加に加えて、スキーマレスデータも増えてきた

具体的なケース

アプリケーションの一部でスキーマレスデータを扱う必要があり、RDBMSでは実装困難

ログを集計したいが、プロダクト毎にログのフォーマットがばらばら

様々な会社の音楽配信情報を統合したいが、フォーマットがバラバラで、かつ予告なく変更があるため、スキーマを定義するのは不可能

複数のRDB散在している顧客データを統合したいが、スキーマがそれぞれ異なり、統合が困難

図は「ビックデータ総覧2013」より引用

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

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

声）

電子メール

経理・財務・人事

営業・CRM・経営

センサー情報

位置・地図ソーシャルメディア・Web

動画

販売実績

他社が保有するデー

タ

気象・環境・情報

健康・医療

各種統計行政金融取引

社内社外

スキーマレスデータ

従来のスキーマのあるデータ


従来のままでよい

背景

このような背景からビックデータやスキーマレスデータを得意とするNOSQL NOSQL(Not Only SQL)が登場してきた

RDBMSだけではなくを適材適所でNOSQLを利用していくべき

データを永続化

RDBMS 必須

トランザクション必須

（基幹システムのDB等）

データを正規化して、一貫性を保つ必要あり

RDBMS でなくても

よい

トランザクション不要な参照するだけのアプリ

複数のデータをジョインする必要が無いアプリ

RDBMS ＮＧ

水平分散が要求される

スキーマレスデータを扱う場合

NOSQLにより開発コストやライセンスコストの削減が見込まれる

NOSQLでなければならない


MongoDBの位置づけ(1/3)

MongoDBはドキュメント指向データベースに分類される

6

キーバリュー型 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の例

7

｛ ID ： 12345 , name ： ”渡部”, address ： { Company ： “日本”, City ： ”東京”, ZipNo ： “045-3356”, } friendID ： [ 3134 , 10231 , 10974 , 11165 ] , hobbies ： [ { name ： “自宅サーバ” , “year” : 6 } , { name ： “プログラミング” , “year” : 10 } , { name ： “麻雀” , “no” : 16 } ] }

配列

ハッシュの配列

キーと値

ハッシュ



8

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

MongoDB CouchDB Couchbase Server

データ構造データベース └コレクション └ドキュメント

データベース └ドキュメント

バケット └ドキュメント

インデックスの生成

インデックスを張りたいキーを指定する

MapReduce関数を用いたビューを作成することで対応

クエリー動的クエリ。SQLライクな記述が可能。

基本的なCRUD以外は、静的クエリ。上記MapReduceで作成したビューへのアクセスがクエリにあたる。

主なインターフェース

独自プロトコル。各言語用専用ドライバを利用。

REST(HTTP) memcachedプロトコル

レプリケーション

シングルマスタ型レプリケーション（１ノードにしか書き込めない）

マルチマスタ型レプリケーション（複数ノードに書き込める）

開発言語 C++ Erlang C,C++,Erlang


MongoDBの特徴(1/6)

MongoDBを一言でいうと RDBMSとKVSのいいとこどり

MongoDBの特徴

9

RDBMSから機能を少し

だけ削ることにより、高いスケーラビリティを獲得

水平分散スキーマレス

多機能

リッチなデータ

レプリケーション使いやすい柔軟なクエリ

RDBMSの

いいところ

KVSの

いいところ MongoDBの特徴

(図の出典： Meiko Hori,Jonathan

Reams ,「MongoDBが目指すもの」より

https://wiki.mongodb.com/pages/view

page.action?pageId=20743144)



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

表現力豊かなクエリ

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

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

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

多様なインデックス

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

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

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

10

db.person.find( { "name" : "watanabe", "age" : 30 } ).limit(3)

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

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

リッチなデータ

柔軟なクエリ



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

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

11

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

x ドキュメント

チャンク

アプリケーション

mongosルータ

1 4 9 11 16 20 27

MongoDB ドライバ

23

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

シャードキーで分散

ノードノードノード

シャードキー

水平分散


ドキュメント


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

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

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

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

12


プライマリ

1 4 9

セカンダリ

1 4 9

セカンダリ

1 4

MongoDBドライバ

9

書き込み

レプリカセット

読み込み

データ複製

読み込み

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

読み込みは負荷分散可能

プライマリ

1 4 9

プライマリ

1 4 9

セカンダリ

1 4 9 データ複製


MongoDBドライバ

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

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





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

13

マシン２

マシン３

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

セカンダリデータ１



セカンダリデータ２

プライマリデータ２



セカンダリデータ３


プライマリデータ３


mongosルータ

負荷分散

冗長化




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

14

マシン２

マシン３

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





プライマリデータ２





プライマリデータ３


mongosルータ




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

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

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

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

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

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

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

– 起動

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

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

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

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

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

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

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

15

使いやすい

スキーマレス


Mo

ng

oD

B


多機能

16

多機能

分類機能説明ユースケース

機能 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が複数のドキュメントを一貫性をもって更新する事ができない

ミッションクリティカルで複数のテーブルの更新を保証しなければならないようなシステムでは、利用してはならない。

外部キー・結合が無い他のドキュメントへの参照はアプリケーションで実装する必要がある。

当然ながら、外部キー制約もないため、テーブル間の整合性が重要なシステムには向いていない。

複数のドキュメントの内容を結合して取得することはできない。

スキーマが無いどのようなキー名でデータが入っているかわからない。データ型もわからない。

データ登録間違えの際にエラーが発生しない。

設計書を厳格に管理しないと、どのようなデータが入っているかわからなくなり、保守性の低下を招く恐れがある。

17


MongoDBの流行について(1/4)

db-engines.comでは上位にランキング(2014/3月)

18

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

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

・一般的な人気度

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

・求人サイトにおける募集スキル・プロフィール登場回数

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

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





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

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

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

19

図の引用元： http://www.mongodb.com/leading-nosql-database

http://www.mongodb.com/leading-nosql-database







採用企業600社以上

20



開発元である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

21


MongoDBの事例

MongoDBは様々な用途に幅広く使えるため、事例も幅広い

22

分類利用しているMongoDBの特徴

紹介する事例

Webアプリ・オンラインゲーム

•水平分散 •リッチなデータ

[国内][SNS] CyberAgent [海外][Web] orange [国内][Web] ZenClerk

ログ収集 •スキーマレス •多機能 •レプリケーション

[国内][SIer]野村総合研究所

アジャイル開発 •スキーマレス •多機能 •使いやすい

[国内][Web] 株式会社キッチハイク

データ分析 •水平分散 •柔軟なクエリ

[海外][セキュリティ] McAfee

スキーマレスデータ処理

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

[国内][SIer] 野村総合研究所

データハブ •スキーマレス •使いやすい

[海外][保険] MetLife [海外][金融]グローバル信託銀行 X社(事例１)

データ統合 •スキーマレス •使いやすい

[国内][Sier] ペタデータ株式会社

拠点間データ連携

•レプリケーション •使いやすい

[海外][金融]グローバル信託銀行 X社(事例２)

従来の教科書通りの使い方

近年の新しい使い方


MongoDBの事例 Webアプリ・オンラインゲーム

利用される理由複雑なデータモデルを扱う事ができる

データの水平分散により高スループットを出すことができる

近年は、利用ユーザの増加などによるトラフィックの増加が激しく、RDBMSでは性能の限界になる事が多い

特にユーザログインがあるようなWebアプリケーション

23

水平分散リッチなデータ

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

x ドキュメント

チャンク


mongosルータ

1 4 9 11 16 20 27

MongoDB ドライバ

23

23

ユーザIDで水平分散

ノードノードノード

ユーザID

｛ ID ： 12345 , name ： ”渡部”, address ： { Company ： “日本”, City ： ”東京”, ZipNo ： “045-3356”, } friendID ： [ 3134 , 10231 , 2122 .. photo： [ { date ： “2014/1/1” , image : "/hoge/photo.jpg"


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

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

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

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

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






MongoDBの事例 Webアプリ・オンラインゲーム [海外][Web] orange

700万のウェブ・モバイルユーザに対する広範囲コンテンツ・サービス提供

25

課題選定理由・解決策結果

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

26


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

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

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


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

システム構成

27


MongoDBの事例ログ情報の蓄積

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

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

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

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

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

28

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


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

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

29


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

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

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


MongoDBの事例アジャイル開発

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

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

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

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

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

30

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


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

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

31


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

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

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


MongoDBの事例データ分析

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

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

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

新規分析軸の導入が用意

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

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

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

32

水平分散柔軟なクエリ


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

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

33


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

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

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

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


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

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

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

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

34

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


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

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

35


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

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

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

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


MongoDBの事例データ統合

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

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

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

36

スキーマレス使いやすい

MongoDB

データを集約

ユーザ

既存のデータソース



MongoDBの事例データ統合 [海外][保険] MetLife

70以上の既存RDBMSに拡散した顧客情報をMongoDBで統合

37


•顧客データを個別に管理する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

システム構成

38

MongoDB

データを集約

ユーザ

既存の顧客データ(約70台)



MongoDBの事例データ統合 [国内][SIer] ペタデータ株式会社

音楽専門放送業大手「株式会社スペースシャワーネットワーク」70以上の配信サイトの配信実績情報の統合サービス（Allegro IoT）にMongoDBを活用

公式HP：http://petadata.jp/ja/OurWorks001.html

39


•配信実績情報は事業者毎に異なるフォーマットであり、それを統一する必要があった。 •一部の事業者の配信実績情報を手作業で整形していた。 •フォーマットが変更されることもあり、事前にスキーマが決定できないため、従来のRDBMSに格納が難しかった。

•スキーマを決定する前に、システムに取込む必要があったため。 •容易にレプリケーションが可能なため。

•手作業によるミスがなくなり、事務作業が格段に減った。利用企業より好評を得ている


MongoDBの事例データハブ

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

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

40

アプリ１

アプリ２

アプリ３

データソース１

データソース２

データソース３

Mongo DB

バッチコピー API

・・・

・・・

スキーマレス使いやすい


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

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

41


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

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

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


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

導入前後比較

42

アプリX

アプリ１

アプリ２

アプリ３




データソースN

バッチコピー

アプリX

アプリ１

アプリ２

アプリ３




データソースN

Mongo DB

バッチコピー API

・・・

・・・

・・・

・・・


MongoDB事例拠点間連携

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

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

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

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

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

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

43


使いやすい


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

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

44


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

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

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


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

新旧のシステム構成比較

45

バッチ連携

ゴールデン

コピー


プライマリ


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


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

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

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

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

qlik view(商用BI)

talend(ETL)

Splunk(商用M2M)

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

fluentd(ログ収集基盤)

46


野村総合研究所OpenStandiaの取り組み

野村総合研究所はMongoDB,Incと正式なパートナー契約を結んでおります

OpenStandiaで提供するサービス

MongoDBのサブスクリプション販売

MongoDBの技術サポートサービス

MongoDBの設計支援・構築支援

47

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

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

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

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

mongodb事例紹介 - openstandia.jp · 株式会社 野村総合研究所...

Documents

mongodb事例紹介 - openstandia.jp · 株式会社野村総合研究所...