More Related Content
Similar to MongoDB概要:金融業界でのMongoDB
Similar to MongoDB概要:金融業界でのMongoDB (20)
More from ippei_suzuki (7)
MongoDB概要:金融業界でのMongoDB
- 4. 4
課題を克服するための要求
課題項目 要求事項 内容
データタイプ 階層型データ構造 今日のOOP言語のオブジェクト構造をサポートする事
データタイプ、アジ
リティー
ダイナミックスキーマ テーブル内の異なるデータ構造を取り扱える事
アジリティー ネーティブOOP言語 統一環境で開発を可能とし、機能/ルールを集約する
ボリューム スケーラビリティ 効率よく数百テラ/ペタバイト級のデータを取り扱える事
ボリューム、新アー
キテクチャ, New
性能 単一ノードで高スループットを提供し、水辺分散が出来る事
未解決 ソフトウェアコスト オープンソース+付加価値サービスの提供
未解決 データ同期性 書き込みされたデータをどれだけ早くリードできるか
未解決 クエリー機能 任意のフィールドのクエリー 例:セカンダリーインデックス
未解決 使いやすさ 習得しやすい事、開発のしやすさ
- 5. 5
既存データベース技術比較
要求事項 RDBMS MongoDB キー/バリュー カラム型
階層的データ構造 △ ◎ △ ⃝
動的スキーマ △ ◎ △ ⃝
ネーティブOOP
言語
△ ◎ ◎ ◎
スケーラビリティ △ ◎ ◎ ◎
性能 △ ◎ ◎ ◎
価格 △ ◎ ◎ ◎
データ保全性 ◎ ⃝ △ △
クエリー機能 ◎ ⃝ △ △
使いやすさ ⃝ ◎ ⃝ △
- 8. 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: […]!
! } ]
}
- 11. 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のアカウントを全て検索
• 先月アカウントを開いた人を全て捜す
位置情報
• ニューヨーク市内10マイル以内の顧客を
検索
テキストサーチ • 特定銀行を話題にした呟きを全て検索
データ統合
Aggregation
• Markのアカウントの平均貯蓄額
Map Reduce • 普通口座に加え、IRAを持つ顧客のリスト
- 30. 30
• データエンティティの関係を把握しているケース
• 例: クエリーに基づいてドキュメントスキーマを設計出来る
!
• クロスドキュメントトランザクションがアプリケーションの主
目的では無いケース
– トランザクションロジックの重要性と比較して、MongoDBの
利点の方が大きいケース
!
• 新規のアプリケーション、もしくはバックエンドのデー
タアクセスAPIを変更する事が出来る場合
MongoDBの特性を活かせるケース
- 31. 31
❑ 複数のソースからデータを収集一極化したい場合
❑ アジャイル開発を採用、市場にアプリを迅速にリリースしたい場合
❑ スキーマの変更回数が多い事が想定される場合
❑ 非構造化データ、もしくはデータ構造のばらつきが大きいとき
❑ RDBMSではモデル化しにくい、階層型のデータ構造を持つケース(例:JSON)
❑ データが急激に増加する事が予測される、スケールアウトを活用したいケース
❑ リアルタイムのRead/Writeの性能を重視したい場合
❑ レプリケーションやキャッシング機能を活用してTCOを出来るだけ低く抑えたいケース
❑ データベースの性能がユーザエクスペリエンスに直接影響を与えるケース
❑ リアルタイム分析やアグリゲーションを必要とする時
❑ 正準モデル、スケール、TCO、アジリティ面でアプリケーション開発の課題を抱えている
ケース
Best Fit for MongoDB over RDBMS
- 33. 33
課題: 分散しているデータの統合が困難
Cards
Loans
Deposits
…
データ
ウェアハウス
バッチ
バッチ
バ
ッ
チ
クロスサイロ
アプリケーション
課題!
• データが古い!
• データ詳細が欠落!
• 柔軟性の無いスキーマ!
• 性能問題
データ
マート
データ
マート
データ
マート
バッチ
影響
• 情報のリアルタイム性
不足!
• 顧客満足度の低下!
• 機会の損失!
• 収益の損失!
!
バッチ
バッチ
レポーティング
Cards
株式
Loans
債券
Deposits
デリバティブ
- 34. 34
ソリューション:
動的スキーマと水平スケールの採用
データ
ウェアハウス
リアルタイム/
バッチ
…
トレーディング
アプリケーション
リスク
アプリケーション
運用データハブ 効果!
• リアルタイム性!
• 情報の完全性!
• 迅速性!
• 顧客サービスの質の
向上!
• 顧客収益の上昇!
• 例外事項への迅速な
対応
戦略的
レポーティング
運用状況
レポーティング
Cards
Loans
Deposits
…
顧客
アカウント
Cards
株式
Loans
債券
Deposits
デリバティブ
- 35. 35
顧客ポリシーや活動情報のグローバル360度ビューを
実現
シングルビューを実現したケーススタディ:
Tier 1 グローバル保険会社
課題 何故MongoDBなのか? 成果
• 顧客ポリシー管理に70種の
システムと20種類のスク
リーンが必要
• 顧客サービス要求のコール
は殆どがコールセンター内
で別担当者に転送される。
• 顧客サービスの評価低下
• データ源のシステムの変更
が困難
• 動的なスキーマ機能を通して
70種のシステムの連携を用意
に実現!
• 性能:単一データベースで全
データを運用!
• レプリケーション:ローカル
リード+高い可用性!
• シャーディング:スケールア
ウトを通して用意にデータ拡
張
• $3Mのコスト/3ヶ月の開発作
業 – 過去は同プロジェクトで
$25M浪費!
• 全販路に対して統一した顧客
データ統合!
• サービス要求コールの転送回
数の劇的減少!
• 顧客満足度の大幅向上
- 36. 36
課題: レガシーシステムがリアルタイム要
求に対応出来ない
データ
ソース
1
データ
ソース
2
データ
ソース
N
… 開示しにくいエンタプライズシステム!
• メインフレーム
• 基幹システム!
• データウェアハウス!
• スケーラブルでないシステム!
!
データのバッチコピーは回数が多いと
システムが遅くなる!
!
ソースデータの変更がシステムに与え
る影響が大!
!
インパクト
• 市場への対応の遅れ!
• リソースの消費大!
• インタフェースの変更、システム
のエンハンスコスト大
アプリ
3
アプリ
1
アプリ
2
アプリ
X
…
バッチコピー
要求に対する
遅いレスポンス
- 41. 41
各拠点で迅速にローカルアクセス出来る様に、
参照データをリアルタイムで分散/配布
ケーススタディ: グローバル銀行
参照データの配布
課題 何故MongoDBなのか? 成果
• バッチ処理によるデータ配
布の遅れが最大36時間に及
ぶ
• 同じデータのグローバル配
信に複数課金される
• SLA未達成による規制違反
(罰金)
• 同じを保有する20カ所の分
散システムを管理する必要性
• 動的スキーマ: データのロード
が容易!
• 自動レプリケーション: データ
配信がリアルタイム、ローカル
にデータを読む事が可能!
• キャッシュとデータベースの同
期: キャッシュが常にアップ
デート!
• 単純なデータモデリングと分
析: 変更が簡単、理解しやすい
• 違反金$40,000,000を5年間の
間に節約!
• データ配信に対する課金は一
回のみ!
• グローバルにデータ同期と各
拠点でのローカルReadが保証 !
• 統一したグローバルデータサー
ビスに移行!
- 43. 43
Solution: Unified data services
… 効果!
• 個々のアプリは独自にデー
タを保存可能!
• サイロ間のレポーティン
グ向けにデータは自動的
に統合される!
• 管理対象となるデータア
クセスレイヤーの統合!
株式システム
FI
システム
デリバティブ
システム
…
レポーティング
……
- 47. 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
- 51. 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