MongoDB 概要

!鈴木逸平 ippei.suzuki@mongodb.com

�2

データベース技術の進化

2010RDBMS

キーバリュー/カラムストア

OLAP/DW

Hadoop

2000

RDBMS

OLAP/DW

1990

RDBMS

オペレーショナル データベース

データウェアハウジング

Document DB

NoSQL

�3

RDB技術の課題

データボリューム • ペタバイト級 • 兆単位のレコード • 秒速数百万件のクエリー処理

アジャイル開発 • イテレーション • 短期開発サイクル • 新規ワークロード

新しいアーキテクチ • 水平スケーリング • 汎用サーバ • クラウド

データタイプとOOP • 非構造型データ • 半構造型データ • ポリモーフィック型データ

�4

課題を克服するための要求課題項目 要求事項 内容

データタイプ 階層型データ構造 今日のOOP言語のオブジェクト構造をサポートする事

データタイプ、アジリティー

ダイナミックスキーマ テーブル内の異なるデータ構造を取り扱える事

アジリティー ネーティブOOP言語 統一環境で開発を可能とし、機能／ルールを集約する

ボリューム スケーラビリティ 効率よく数百テラ／ペタバイト級のデータを取り扱える事

ボリューム、新アーキテクチャ, New

性能 単一ノードで高スループットを提供し、水辺分散が出来る事

未解決 ソフトウェアコスト オープンソース＋付加価値サービスの提供

未解決 データ同期性 書き込みされたデータをどれだけ早くリードできるか

未解決 クエリー機能 任意のフィールドのクエリー 例：セカンダリーインデックス

未解決 使いやすさ 習得しやすい事、開発のしやすさ

�5

既存データベース技術比較要求事項 RDBMS MongoDB キー/バリュー カラム型

階層的データ構造 △ ◎ △ ◯

動的スキーマ △ ◎ △ ◯

ネーティブOOP 言語 △ ◎ ◎ ◎

スケーラビリティ △ ◎ ◎ ◎

性能 △ ◎ ◎ ◎

価格 △ ◎ ◎ ◎

データ保全性 ◎ ◯ △ △

クエリー機能 ◎ ◯ △ △

使いやすさ ◯ ◎ ◯ △

�6

今後のアプリケーションに必要な要件要求事項 RDBMS MongoDB キー/バリュー カラム型

階層的データ構造 △ ◎ △ ◯

動的スキーマ △ ◎ △ ◯

ネーティブOOP 言語 △ ◎ ◎ ◎

スケーラビリティ △ ◎ ◎ ◎

性能 △ ◎ ◎ ◎

価格 △ ◎ ◎ ◎

データ保全性 ◎ ◯ △ △

クエリー機能 ◎ ◯ △ △

使いやすさ ◯ ◎ ◯ △

�7

オペレーショナルDBMSランドスケープ

• 自動ジョイン機能が不要!• ドキュメント型データ!• 高速，スケーラブルR/W

�8

アプリケーションのデータ形式に合わせる

RDB MongoDB{! customer_id : 1, ! first_name : "Mark", ! last_name : "Smith", ! city : "San Francisco", ! accounts : [! { ! ! account_number : 13, ! ! branch_ID : 200, ! ! account_type : "Checking" ! }, ! {! account_number : 14, ! ! branch_ID : 200, ! ! account_type : ”IRA”, ! ! beneficiaries: […]!! } ] }

�9

シェル データベースを直接操作するインラインのシェル

好きな言語を利用可能

ドライバー 殆どの言語とフレームワークをサポート

> db.collection.insert({name: "John Smith", address: "10 3rd St.", phone: {home: 1234567890, mobile: 1234568138}})!> !> db.collection.findOne() {!! “_id”: ObjectId(“5106c1c2fc629bfe52792e86”),! ! “name”: “John Smith”, ! “address”: “10 3rd St.”, ! “phone”: { ! ! “home”: 1234567890, ! ! “mobile”: 1234568138 } }

Java

Python

Perl

Ruby

Haskell

JavaScript

�10

データモデルを一カ所で管理

アプリケーション

Code

Relational Database

Object Relational Mapping

XML Config DB スキーマ

アプリケーション

Code

クエリー処理 位置情報

テキストサーチ

Map Reduce

Aggregation

�11

No SQL でありながらクエリー処理が充実

MongoDB{! customer_id : 1, ! first_name : "Mark", ! last_name : "Smith", ! city : "San Francisco", ! accounts : [! { ! ! account_number : 13, ! ! branch_ID : 200, ! ! account_type : "Checking" ! }, ! {! account_number : 14, ! ! branch_ID : 200, ! ! account_type : "Savings" ! } ] }

高度なクエリー処理

• Markのアカウントを全て検索 • 先月アカウントを開いた人を全て捜す

位置情報 • ニューヨーク市内１０マイル以内の顧客を検索

テキストサーチ • 特定銀行を話題にした呟きを全て検索

データ統合Aggregation

• Markのアカウントの平均貯蓄額

Map Reduce • 普通口座に加え、IRAを持つ顧客のリスト

�12

オペレーショナルデータベースのユースケース

RDBMSs

キーバリュー／カラムストア!

MongoDB

�13

DB-Engines.com ランキング

MongoDBのユーザ層

MongoDB ソリューション

�16

MongoDB 機能の特長

Application

Driver

Mongos

Primary

Secondary

Secondary

Shard  1

Primary

Secondary

Secondary

Shard  2

…Primary

Secondary

Secondary

Shard  N

db.customer.insert({…})!db.customer.find({ ! name: ”John Smith”})

1. ダイナミックスキーマ{ name: “John Smith”,! date: “2013-08-01”,! address: “10 3rd St.”,! phone: {!! home: 1234567890,! ! mobile: 1234568138 } !}

2.  言語ドライバー

4.  高性能"- データローカリティ!- インデックス!- RAM

3.  高い可用性"-レプリカセット

5.  水平スケーラビリティ!-シャーディング

�17

データローカリティの改善

性能

インメモリ

キャッシング

In-Place アップデート

�18

MongoDB Hadoop コネクター

オペレーショナルデータベース

• 低レイテンシー"• 高速クエリー処理!• データベースアグリゲーション!• 既知のdata relationships

• 長いジョブ"• バッチ処理の分析"• 高度な並列処理"• 未知のdata relationships"

アナリティクス

MongoDB-Hadoop コネクター

金融業界でのMongoDB

�20

インベストメントバンキング

機能分野 実装されているユースケース

リスク分析とレポーティング

企業内統合リスク分析プラットホーム 日中マーケットリスク分析 日中カウンターパーティリスク分析 リスクの例外ワークフロー最適化 リミット管理サービス

コンプライアンス要件柔軟なサイロ間レポーティング: Volker, Dodd-Frank, EMIR, MiFID II, etc 長期オンライン監査証跡 統合型 Know Your Customer (KYC) レポジトリ

バイサイド ポータル 対応型ポートフォリオ レポーティング

トレード管理(企業間共通)クロスプロダクトトレードマート 柔軟なOTC デリバティブトレード捕捉

フロントオフィストレーディング戦略バックテスティング アジャイル戦略設定 戦略パフォーマンス分析

参照データ管理 参照データの配布用ハブ

マーケットデータ管理 ティックデータ捕捉 ソーシャルネットワークフィード捕捉

投資アドバイザリー業務 クロスチャンネルのデータをベースとしたクロスセルサービス 拡張された投資リサーチ

�21

コアバンキング業務

機能分野 実装されているユースケース

顧客エンゲージメント 顧客プロファイルの統一 顧客満足度管理 応答性の良いデジタルバンキングサービス コンシューマアプリのゲーミフィケーション アジャイルな次世代デジタルプラットホーム

マーケティング 複数チャネル統合の顧客活動記録収集分析 リアルタイムクロスチャネル顧客サービス提案システム ロケーションベースの提案システム

リスク分析＆レポーティング 企業内共通流動性リスク分析 トランザクションレポートと分析

規制遵守 柔軟なサイロ間レポーティング: Basel III, Dodd-Frank, etc.長期オンライン監査証跡統合型 Know Your Customer (KYC) レポジトリ

参照データ管理 グローバル参照データの配布用ハブ

支払い 企業トランザクションレポーティング

不正検知 統合的なアクセス記録レポジトリ サイバーセキュリティー脅威分析

�22

保険業界

機能分野 実装されているユースケース

顧客エンゲージメント 統合された顧客情報ポータル 顧客エクスペリエンス管理 アプリケーションのゲーミフィケーション アジャイルな次世代デジタルプラットホーム

マーケティング 複数チャネル統合の顧客活動記録収集分析 リアルタイムクロスチャネル顧客サービス提案システム

エージェントデスクトップ 迅速な顧客動向レポーティング

リスク分析＆レポーティング 災害リスクモデリング 流動性リスク分析

規制遵守 柔軟なサイロ間レポーティング: Basel III, Dodd-Frank, etc. 長期オンライン監査証跡

参照データ管理 グローバル参照データの配布用ハブ ポリシーカタログ

不正検知 統合的なアクセス記録レポジトリ

High  Availability  概要

�24

ドライバー

High Availability: レプリカセット

レプリケーションRead

Write

プライマリー

セカンダリー

セカンダリー

�25

High Availability: レプリカセット

Read

Read

Consistent Reads（整合性Read)

Eventually Consistent(結果整合性 Reads)

ドライバー レプリケーション

Read

Write

プライマリー

セカンダリー

セカンダリー

�26

Read

プライマリー

High Availability: レプリカセット

Read

ドライバー

セカンダリー

セカンダリー

�27

プライマリー

High Availability: レプリカセット

Read

Write

Read

自動的な次期リーダーの選挙ド

ライバー

Primary

セカンダリー

�28

High Availability: レプリカセット

Read

ドライバー

レプリケーション

Read セカンダリー

プライマリー

セカンダリー

Read

Write

利用環境：!• 高可用性!• 障害対策!• メンテナンス

MongoDBのベストプラクティス

�30

• データエンティティの関係を把握しているケース • 例： クエリーに基づいてドキュメントスキーマを設計出来る !

• クロスドキュメントトランザクションがアプリケーションの主目的では無いケース – トランザクションロジックの重要性と比較して、MongoDBの利点の方が大きいケース !

• 新規のアプリケーション、もしくはバックエンドのデータアクセスAPIを変更する事が出来る場合

MongoDBの特性を活かせるケース

�31

❑ 複数のソースからデータを収集一極化したい場合

❑ アジャイル開発を採用、市場にアプリを迅速にリリースしたい場合

❑ スキーマの変更回数が多い事が想定される場合

❑ 非構造化データ、もしくはデータ構造のばらつきが大きいとき

❑ RDBMSではモデル化しにくい、階層型のデータ構造を持つケース（例：JSON)

❑ データが急激に増加する事が予測される、スケールアウトを活用したいケース

❑ リアルタイムのRead/Writeの性能を重視したい場合

❑ レプリケーションやキャッシング機能を活用してTCOを出来るだけ低く抑えたいケース

❑ データベースの性能がユーザエクスペリエンスに直接影響を与えるケース

❑ リアルタイム分析やアグリゲーションを必要とする時

❑ 正準モデル、スケール、TCO、アジリティ面でアプリケーション開発の課題を抱えているケース

Best Fit for MongoDB over RDBMS

共通アーキテクチャパターンと ソリューションのケーススタディ

�33

課題: 分散しているデータの統合が困難

Cards  

Loans

Deposits

…

データ  ウェアハウス

バッチ

バッチ

バッチ

クロスサイロ  アプリケーション

課題!• データが古い!• データ詳細が欠落!• 柔軟性の無いスキーマ!• 性能問題

データマート

データマート

データマート

バッチ

影響  • 情報のリアルタイム性不足!

• 顧客満足度の低下!• 機会の損失!• 収益の損失!!

バッチ

バッチ

レポーティング

Cards  株式

Loans債券

Depositsデリバティブ

�34

ソリューション: 動的スキーマと水平スケールの採用

データ  ウェアハウス

リアルタイム／  バッチ

…

トレーディング  アプリケーション

リスクアプリケーション

運用データハブ 効果!• リアルタイム性!• 情報の完全性!• 迅速性!• 顧客サービスの質の向上!

• 顧客収益の上昇!• 例外事項への迅速な対応

戦略的

レポーティング

運用状況  レポーティング

Cards  

Loans

Deposits

…

顧客  アカウント

Cards  株式

Loans債券

Depositsデリバティブ

�35

顧客ポリシーや活動情報のグローバル360度ビューを実現

シングルビューを実現したケーススタディ: Tier 1 グローバル保険会社

課題 何故MongoDBなのか？ 成果

• 顧客ポリシー管理に70種のシステムと２０種類のスクリーンが必要

• 顧客サービス要求のコールは殆どがコールセンター内で別担当者に転送される。

• 顧客サービスの評価低下 • データ源のシステムの変更が困難

• 動的なスキーマ機能を通して70種のシステムの連携を用意に実現!

• 性能：単一データベースで全データを運用!

• レプリケーション：ローカルリード＋高い可用性!

• シャーディング：スケールアウトを通して用意にデータ拡張

• $3Mのコスト/3ヶ月の開発作業 – 過去は同プロジェクトで$25M浪費!

• 全販路に対して統一した顧客データ統合!

• サービス要求コールの転送回数の劇的減少!

• 顧客満足度の大幅向上

�36

課題: レガシーシステムがリアルタイム要求に対応出来ない

データ  ソース  1

データ  ソース  2

データ  ソース  N

…

開示しにくいエンタプライズシステム!• メインフレーム  • 基幹システム!• データウェアハウス!• スケーラブルでないシステム!!データのバッチコピーは回数が多いとシステムが遅くなる!!ソースデータの変更がシステムに与える影響が大!!インパクト  • 市場への対応の遅れ!• リソースの消費大!• インタフェースの変更、システムのエンハンスコスト大

アプリ  3

アプリ  1

アプリ  2

アプリ  X

…

バッチコピー

要求に対する  遅いレスポンス

�37

ソリューション: 固定的なキャッシングサービスでレガシーシステムを仮想化運用メインフレーム

EDW

基幹  システム

…

利点!• 市場ニーズへの迅速な対応!• データソース変更に対する対応も早い  !

• 仮想化環境上でのデータ運用が容易!

• 低いTCOでスケーラビリティを格段に拡大  アプリ  3

アプリ  1

アプリ  2

アプリ  X

…

…

バッチ

API

バッチコピー

バッチコピー

�38

エンタプライス間共通のデータハブを構築、エンタプライス内でのデータアクセスを統合

ケーススタディ: グローバル信託銀行が エンタプライズデータソースを仮想化運用

課題 何故MongoDBなのか？ 成果

• データの複製がシステム間で無数に存在する

• 一つのシステムでの変更が複数のグループに影響

• EDWのシステムレスポンスタイムが遅い

• 頻繁にアクセスするデータは集中的に管理したい，というニーズ

• 動的なスキーマ: 必要な時だけデータを正規化する!

• 性能: 一つの論理DBで全てのデータを管理・運用!

• シャーディング: スケールアウトによりデータを容易に追加

• 一カ所からバッチ，もしくはRESTでデータアクセス可能!

• 顧客向けポータルサイトのレスポンスタイムが90%改善!

• 開発期間の短縮!

• データソースのエンハンスが容易

�39

課題: マスターデータの変更と分散が困難

ゴールデンコピー

バッチ

課題!• マスターデータのスキーマ変更が困難!

• 世界中に配布されたデータの同期確保が困難!!ビジネスへの影響"• 同期が保証されていないデータによる問題!

• 必要な時にアップデートされたデータが無い!

• コピー数が多い事による管理コストが増大

バッチ バッチバッチ

バッチ

バッチ

バッチ

バッチ

�40

ソリューション: 固定的な動的キャッシュをグローバルで同期

リアルタイム

ソリューション:!• 任意のスキーマでプライマリー

DBにデータ追加!• セカンダリーで同期＋Readを運用  !

効果"• ビジネススピードに合ったデータ運用効率!

• 容易なスケールアウトによるデータ運用!

• TCOを大幅に削減

リアルタイム

リアルタイムリアルタイム

リアルタイム

リアルタイム

リアルタイム

リアルタイム

�41

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

ケーススタディ: グローバル銀行 参照データの配布

課題 何故MongoDBなのか？ 成果

• バッチ処理によるデータ配布の遅れが最大36時間に及ぶ

• 同じデータのグローバル配信に複数課金される

• SLA未達成による規制違反（罰金）

• 同じを保有する20カ所の分散システムを管理する必要性

• 動的スキーマ: データのロードが容易!

• 自動レプリケーション: データ配信がリアルタイム、ローカルにデータを読む事が可能!

• キャッシュとデータベースの同期: キャッシュが常にアップデート!

• 単純なデータモデリングと分析: 変更が簡単、理解しやすい

• 違反金$40,000,000を5年間の間に節約!

• データ配信に対する課金は一回のみ!

• グローバルにデータ同期と各拠点でのローカルReadが保証 !

• 統一したグローバルデータサービスに移行!

�42

Challenge: Siloed operational applications

株式トレード

債券トレード

デリバティブトレード

…

影響!• データビューがサイロ化（個別）  

• 各システムのデータアクセス層と管理層の重複!

• データ統合のための個別システムが別途開発必要

株式システム

FI  システム

デリバティブ  システム

…

レポーティング

レポーティング

レポーティング

�43

Solution: Unified data services

…

効果!• 個々のアプリは独自にデータを保存可能!

• サイロ間のレポーティング向けにデータは自動的に統合される!

• 管理対象となるデータアクセスレイヤーの統合!

株式システム

FI  システム

デリバティブ  システム

…レポーティング

……

�44

リアルタイムで参照データをリアルタイムでグローバルに配布、データのローカルアクセスを実現

ケーススタディ: OTCトレードのブローカー向けのグローバルトレーディングシステム

課題 何故MongoDBなのか？ 成果

• 各アプリケーションは個別の監査証跡機能を持つ

• 全てのトレーディングアプリに統一した監査向けのデータ収集管理フレームワークが必要

• 全ての証券システムの異なるデータ構造に対応する必要がある

• 動的スキーマ: 一つのデータサービスに全てのトレード関連データを集約出来る!

• スケールが容易: 性能に影響を及ぼす事無く、長期持続的にトレード情報を管理する事が可能!

• データの長期保存管理で迅速な市場展開が可能!

• スキーマを意識する事無く、あらゆる商品/トレード関連データをストア可能!

• 監査／レポート向けに統合されたトレード関連情報データベース

�45

課題 5: アプリケーション開発のアジャイル性が不足

変更要求

変更

変更 変更

�46

ソリューション: データモデルをアプリケーションに動的に合わせる

�47

性能: 水平スケーリング規模事例

Top 5 マーケティング企業

米国政府省庁 Top 5 投資銀行

データ キー/バリュー 10+ フィールド数, アレイ, ネストドキュメント

20+ フィールド数, アレイ, ネストドキュメント

クエリー キーベース 1 – 100 ドキュメント/クエリー 80/20 read/write

Compound queries Range queries MapReduce 20/80 read/write比率

Compound queries Range queries 50/50 read/write比率

サーバ台数 ~250 ~50 ~5

トラフィック 1,200,000 ops/sec 500,000 ops/sec 30,000 ops/sec

�48

TCO: RDBMSより70%+低い

RDBMS

CPU: スケールアップ系サーバ

ストレージ: SAN

開発／管理工数

CPU: 汎用サーバストレージ: ローカルストレージ

開発／管理工数

$1,680K

$517K

�49

アジリティ: 100% 管理工数と比較して開発工数にリソースを投入

MongoDBを利用 RDBMSを利用DB管理

マッピング管理ビジネスロジック ビジネスロジック

DB  管理

マッピング管理

消費される時間の割合

�50

MongoDB 製品サービスラインアップ

トレーニング 開発者／管理者向けトレーニングをオンライン／オンサイトで実施

MongoDB Monitoring Service 無償のクラウドベース監視サービス

MongoDB バックアップサービス クラウドベースのバックアップを提供

サブスクリプション MongoDB Enterprise, 監視, 保守サポート, コマーシャルライセンス

コンサル MongoDB導入／開発／運用全般に渡る専門家によるリソース提供

�51

さらに情報はここから

Resource Location

MongoDB ダウンロード mongodb.com/download

無償オンライントレーニング education.mongodb.com

ウェビナー／イベント mongodb.com/events

ホワイトペーパー mongodb.com/white-papers

事例紹介 mongodb.com/customers

プレゼン資料 mongodb.com/presentations

ドキュメント docs.mongodb.org

追加情報要求 info@mongodb.com

リソース URL