mongodb事例紹介 - openstandia.jp · 株式会社 野村総合研究所...
TRANSCRIPT
株式会社 野村総合研究所 オープンソースソリューション推進室
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勉強会"} "属性" : ["ギーク", "スーツ"] }
株式会社 野村総合研究所 オープンソースソリューション推進室
背景その1 :ビックデータ
近年、コンピュータシステムに置いて扱うデータ量が増えている。 2011年に生成されたデータ量は1.8ZB、2020年には50倍に増加し、必要とされるサーバは現在の10倍、蓄積されるファイル数は75倍に増えると予想されている
インターネットに接続する端末数が増加したため。2011年に40億台、2015年には150億台に拡大と予想。
ソーシャルメディアの利用拡大により情報発信が増えている。情報発信者数は2010年1650万人であったが2012年3290万人と拡大。
クラウドコンピューティングの利用により大容量のデータを安価に扱えるようになった
センサー情報の爆発2010年からの10年間でデータ量は44倍になると予想されている
このようなビックデータをRDBMSで対応するのは困難
スケールアップによる対応では限界がある
スケールアウトは高コスト。
(出典「図解ビックデータ早わかり」)
スケールアップ テーブルパーティショニング
スケールアウト
コントローラ
高コスト 性能限界
限界がある
CPU↑ メモリ↑
ディスク↑
株式会社 野村総合研究所 オープンソースソリューション推進室
背景その2:スキーマレスデータ
データの増加に加えて、スキーマレスデータも増えてきた
具体的なケース
アプリケーションの一部でスキーマレスデータを扱う必要があり、RDBMSでは実装困難
ログを集計したいが、プロダクト毎にログのフォーマットがばらばら
様々な会社の音楽配信情報を統合したいが、フォーマットがバラバラで、かつ予告なく変更があるため、スキーマを定義するのは不可能
複数のRDB散在している顧客データを統合したいが、スキーマがそれぞれ異なり、統合が困難
図は「ビックデータ総覧2013」より引用
オフィス文章 システムログ
顧客対応履歴 (テキスト・音
声)
電子メール
経理・財務・人事
営業・CRM・経営
センサー 情報
位置・地図 ソーシャルメディア・Web
動画
販売実績
他社が保有するデー
タ
気象・環境・情報
健康・医療
各種統計 行政 金融取引
社内 社外
スキーマレスデータ
従来の スキーマの あるデータ
株式会社 野村総合研究所 オープンソースソリューション推進室
従来のままでよい
背景
このような背景からビックデータやスキーマレスデータを得意とするNOSQL NOSQL(Not Only SQL)が登場してきた
RDBMSだけではなくを適材適所でNOSQLを利用していくべき
データを 永続化
RDBMS 必須
トランザクション必須
(基幹システムのDB等)
データを正規化して、一貫性を保つ必要あり
RDBMS でなくても
よい
トランザクション不要な 参照するだけのアプリ
複数のデータをジョインする必要が無いアプリ
RDBMS NG
水平分散が要求される
スキーマレスデータを扱う場合
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
ドキュメント
データベース
キー 値
キー
値
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの位置づけ(2/3)
ドキュメント指向データベースとは データを階層構造のドキュメント(≒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 } ] }
配列
ハッシュの配列
キーと値
ハッシュ
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの位置づけ(3/3)
8
ドキュメント指向データベースの比較
MongoDB CouchDB Couchbase Server
データ構造 データベース └コレクション └ドキュメント
データベース └ドキュメント
バケット └ドキュメント
インデックスの生成
インデックスを張りたいキーを指定する
MapReduce関数を用いたビューを作成することで対応
クエリー 動的クエリ。SQLライクな記述が可能。
基本的なCRUD以外は、静的クエリ。上記MapReduceで作成したビューへのアクセスがクエリにあたる。
主なインターフェース
独自プロトコル。各言語用専用ドライバを利用。
REST(HTTP) memcachedプロトコル
レプリケーション
シングルマスタ型レプリケーション (1ノードにしか書き込めない)
マルチマスタ型レプリケーション (複数ノードに書き込める)
開発言語 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)
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの特徴(2/6)
JSON(階層型データ)は、Key-Valueに比べて、リッチなデータモデル
表現力豊かなクエリ
SQLの文法に似せたクエリが扱いやすい。
動的に作成可能。事前に定義不要。
単純な条件検索だけでなく、集計等の高度なクエリも書ける。
多様なインデックス
セカンダリインデックス:主キー以外でインデックスを作成可能
複合キーインデックス:複数のキーでインデックスを作成可能
マルチキーインデックス:配列の要素に対してインデックス作成可能
10
db.person.find( { "name" : "watanabe", "age" : 30 } ).limit(3)
例)コレクションpersonに、“name”が“watanabe”で、
“age”が30のドキュメントを3つだけ取得したい
リッチなデータ
柔軟なクエリ
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの特徴(3/6)
水平分散(シャーディング)が簡単
キーによってデータをノードに分散することができる。また、ノードを動的に追加し、データの自動バランシング機能もある。
11
範囲 0-9 範囲10-19 範囲20-
x ドキュメント
チャンク
アプリケーション
mongosルータ
1 4 9 11 16 20 27
MongoDB ドライバ
23
23 クエリを適切なノードに分散
シャードキーで分散
ノード ノード ノード
シャードキー
水平分散
株式会社 野村総合研究所 オープンソースソリューション推進室
ドキュメント
MongoDBの特徴(4/6)
複製(レプリケーション)が簡単
簡単なコマンドで、マスターセカンダリ型のレプリケーションを構築可能。
シャーディングと組み合わせることも可能
MongoDBドライバが自動的に書き込み先を切り替えるため、仮想IPなどを用意しなくてもフェイルオーバが可能(≒クラスタソフトウェアが不要)
12
アプリケーション
プライマリ
1 4 9
セカンダリ
1 4 9
セカンダリ
1 4
MongoDBドライバ
9
書き込み
レプリカセット
読み込み
データ複製
読み込み
書き込めるのはマスタのみ
読み込みは負荷分散可能
プライマリ
1 4 9
プライマリ
1 4 9
セカンダリ
1 4 9 データ複製
アプリケーション
MongoDBドライバ
書き込み 読み込み 読み込み
プライマリが障害になったら、プライマリノードを選出し、自動フェイルオーバ
レプリカセット
レプリケーション
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの特徴(5/6)
レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立
13
マシン2
マシン3
マシン1 プライマリデータ1
セカンダリ データ1
セカンダリ データ1
レプリカセット
セカンダリ データ2
プライマリ データ2
セカンダリ データ2
レプリカセット
セカンダリ データ3
セカンダリ データ3
プライマリ データ3
レプリカセット
mongosルータ
負荷分散
冗長化
アプリケーション
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの特徴(5/6)
レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立
14
マシン2
マシン3
マシン1 プライマリデータ1
セカンダリ データ1
セカンダリ データ1
レプリカセット
セカンダリ データ2
プライマリ データ2
セカンダリ データ2
レプリカセット
セカンダリ データ3
セカンダリ データ3
プライマリ データ3
レプリカセット
mongosルータ
アプリケーション
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの特徴(6/6)
スキーマレスデータを扱える
テーブル定義など無しに、すぐにデータをCRUDできる
セットアップが非常に簡単
ZIPひとつ。OS毎にバイナリがあるため、ライブラリの追加インストール不要。
起動までわずか3ステップ。
– OS毎のバイナリをダウンロード
– データディレクトリを作成
– 起動
RDBMSを使っていた人が使いやすいように作られている
データベース>テーブル(コレクション)>ドキュメント というデータ構造
SQLとMongoクエリ言語は大部分マッピング可能
インデックスもSQLと同じような宣言ができる
豊富なドキュメント・ノウハウ
英語ではあるが公式ドキュメントは他のNOSQLに比べても豊富
多くの人が使っているため、ノウハウが豊富。日本語のノウハウも多い。
15
使いやすい
スキーマレス
株式会社 野村総合研究所 オープンソースソリューション推進室
Mo
ng
oD
B
MongoDBの特徴(6/6)
多機能
16
多機能
分類 機能 説明 ユースケース
機能 GridFS 大容量ファイル(16M以上)を扱うことができる。 大容量ファイルをドキュメントに分割して格納し、アプリケーションには等価的なAPIを提供。
大容量ファイルの管理
地理空間インデックス 2Dや3Dのデータを格納し、それに対して交点や近傍などの検索をかけることができる。 アプリでのつくり込不要。
地図アプリのデータベース
キャップ付きコレクション
期限を指定したコレクションを作り、自動的に古いドキュメントを引き落とせる
ログ保管
集計機能 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
【指標の考え方】 ・ウェブサイトでのシステム名称の登場回数
・一般的な人気度
・技術的なディスカッションの頻度
・求人サイトにおける募集スキル・プロフィール登場回数
・インストール数は考慮されていない
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの流行について(2/4)
転職サイト(LinkedIN)における人気 NOSQLスキルランキングでは他を圧倒
NoSQLではMongoDBの技術者が圧倒的に多い
NoSQL技術の標準になりつつある
19
図の引用元: http://www.mongodb.com/leading-nosql-database
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの流行について(3/4)
採用企業600社以上
20
株式会社 野村総合研究所 オープンソースソリューション推進室
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
21
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例
MongoDBは様々な用途に幅広く使えるため、事例も幅広い
22
分類 利用しているMongoDBの特徴
紹介する事例
Webアプリ・オンラインゲーム
•水平分散 •リッチなデータ
[国内][SNS] CyberAgent [海外][Web] orange [国内][Web] ZenClerk
ログ収集 •スキーマレス •多機能 •レプリケーション
[国内][SIer]野村総合研究所
アジャイル開発 •スキーマレス •多機能 •使いやすい
[国内][Web] 株式会社キッチハイク
データ分析 •水平分散 •柔軟なクエリ
[海外][セキュリティ] McAfee
スキーマレスデータ処理
•スキーマレス •柔軟なクエリ
[国内][SIer] 野村総合研究所
データハブ •スキーマレス •使いやすい
[海外][保険] MetLife [海外][金融]グローバル信託銀行 X社(事例1)
データ統合 •スキーマレス •使いやすい
[国内][Sier] ペタデータ株式会社
拠点間データ連携
•レプリケーション •使いやすい
[海外][金融]グローバル信託銀行 X社(事例2)
従来の教科書通りの使い方
近年の新しい使い方
株式会社 野村総合研究所 オープンソースソリューション推進室
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
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 Webアプリ・オンラインゲーム [海外][Web] orange
700万のウェブ・モバイルユーザに対する広範囲コンテンツ・サービス提供
25
課題 選定理由・解決策 結果
•MySQLがスケーラビリティの上限に達して性能要件を達成できなくなった •RBMSでは非定型なメタデータの管理が困難
•性能とスケーラビリティに期待しMongoDBを導入 •60億におよぶ属性情報データの代わりに、1コンテンツを1ドキュメントにする構造を導入
•秒間11万件以上のクエリに対応 •3年で200万ドル以上のコスト削減 •新規機能の導入のスピードが著しく早くなった •新規プロジェクトでは全てMongoDBを利用する方針となった
引用元: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の開発容易性から、2週間でプロトタイプが作成でき、90日でリリースできた。
•10年間できなかった顧客データの統合が実現。それも既存の顧客データには手を入れずに実現できた •巨額な投資が必要な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
アプリ1
アプリ2
アプリ3
データソース1
データソース2
データソース3
Mongo DB
バッチコピー API
・・・
・・・
スキーマレス 使いやすい
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 データハブ [海外][金融]グローバル信託銀行 X社(事例1)
企業内でのデータアクセスを統合するために、データハブとして利用
41
課題 選定理由・解決策 結果
•データの複製がシステム間で無数に存在する •一つのシステムでの変更が複数のグループに影響 •EDWのシステムレスポンスタイムが遅い •頻繁にアクセスするデータは集中的に管理したい,というニーズ
•動的なスキーマ: 必要な時だけデータを正規化する •性能: 一つの論理DBで全てのデータを管理・運用 •シャーディング: スケールアウトによりデータを容易に追加
•一カ所からバッチ,もしくはRESTでデータアクセス可能 •顧客向けポータルサイトのレスポンスタイムが90%改善 •開発期間の短縮データソースのエンハンスが容易
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 データハブ [海外][金融]グローバル信託銀行 X社(事例1)
導入前後比較
42
アプリX
アプリ1
アプリ2
アプリ3
データソース1
データソース2
データソース3
データソースN
バッチコピー
アプリX
アプリ1
アプリ2
アプリ3
データソース1
データソース2
データソース3
データソースN
Mongo DB
バッチコピー API
・・・
・・・
・・・
・・・
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDB事例 拠点間連携
利用される理由 各拠をまたがりレプリカセットを組むことにより、タ拠点で同じデータが見れる
レプリケーションの耐久性が高く、多少遅延のある通信経路でも構築可能
レプリケーションの機能により、物理的に近い拠点からデータを複製することが可能
レプリケーションの構成が柔軟
書き込み一貫性が柔軟(w値,j値)
多様なセカンダリreadonly,hidden,delayed
43
レプリケーション
使いやすい
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 拠点間連携 [海外][金融]グローバル信託銀行 X社(事例2)
各拠点で迅速にローカルアクセス出来る様に、参照データをリアルタイムで分散/配布
44
課題 選定理由・解決策 結果
•バッチ処理によるデータ配布の遅れが最大36時間に及ぶ •同じデータのグローバル配信に複数課金されるSLA未達成による規制違反(罰金) •同じを保有する20カ所の分散システムを管理する必要性
•自動レプリケーション: データ配信がリアルタイム、ローカルにデータを読む事が可能 •キャッシュとデータベースの同期: キャッシュが常にアップデート •単純なデータモデリングと分析: 変更が簡単、理解しやすい
•違反金$40,000,000を5年間の間に節約 •データ配信に対する課金は一回のみ •グローバルにデータ同期と各拠点でのローカルReadが保証 •統一したグローバルデータサービスに移行
株式会社 野村総合研究所 オープンソースソリューション推進室
MongoDBの事例 拠点間連携 [海外][金融]グローバル信託銀行 X社(事例2)
新旧のシステム構成比較
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オープンソースソリューション推進室へ
本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。