Download as PDF, PPTX
![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: […]!
! } ]
}](https://image.slidesharecdn.com/mongodboverviewfsj-140827200848-phpapp02/85/MongoDB-MongoDB-8-320.jpg)
![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を持つ顧客のリスト](https://image.slidesharecdn.com/mongodboverviewfsj-140827200848-phpapp02/85/MongoDB-MongoDB-11-320.jpg)
More Related Content
![[よくわかるクラウドデータベース] AWSデータベースアップデート 20140117](https://cdn.slidesharecdn.com/ss_thumbnails/20140117awsdbupdatesv1-140128175124-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
MongoDB概要：金融業界でのMongoDB
- 1.
- 2.
- 3. 3 RDB技術の課題 データボリューム • ペタバイト級 • 兆単位のレコード •秒速数百万件のクエリー 処理 アジャイル開発 • イテレーション • 短期開発サイクル • 新規ワークロード 新しいアーキテクチ • 水平スケーリング • 汎用サーバ • クラウド データタイプとOOP • 非構造型データ • 半構造型データ • ポリモーフィック型データ
- 4. 4 課題を克服するための要求 課題項目 要求事項 内容 データタイプ階層型データ構造 今日のOOP言語のオブジェクト構造をサポートする事 データタイプ、アジ リティー ダイナミックスキーマ テーブル内の異なるデータ構造を取り扱える事 アジリティー ネーティブOOP言語 統一環境で開発を可能とし、機能／ルールを集約する ボリューム スケーラビリティ 効率よく数百テラ／ペタバイト級のデータを取り扱える事 ボリューム、新アー キテクチャ, New 性能 単一ノードで高スループットを提供し、水辺分散が出来る事 未解決 ソフトウェアコスト オープンソース＋付加価値サービスの提供 未解決 データ同期性 書き込みされたデータをどれだけ早くリードできるか 未解決 クエリー機能 任意のフィールドのクエリー 例：セカンダリーインデックス 未解決 使いやすさ 習得しやすい事、開発のしやすさ
- 5. 5 既存データベース技術比較 要求事項 RDBMS MongoDBキー/バリュー カラム型 階層的データ構造 △ ◎ △ ⃝ 動的スキーマ △ ◎ △ ⃝ ネーティブOOP 言語 △ ◎ ◎ ◎ スケーラビリティ △ ◎ ◎ ◎ 性能 △ ◎ ◎ ◎ 価格 △ ◎ ◎ ◎ データ保全性 ◎ ⃝ △ △ クエリー機能 ◎ ⃝ △ △ 使いやすさ ⃝ ◎ ⃝ △
- 6. 6 今後のアプリケーションに必要な要件 要求事項 RDBMS MongoDBキー/バリュー カラム型 階層的データ構造 △ ◎ △ ⃝ 動的スキーマ △ ◎ △ ⃝ ネーティブOOP 言語 △ ◎ ◎ ◎ スケーラビリティ △ ◎ ◎ ◎ 性能 △ ◎ ◎ ◎ 価格 △ ◎ ◎ ◎ データ保全性 ◎ ⃝ △ △ クエリー機能 ◎ ⃝ △ △ 使いやすさ ⃝ ◎ ⃝ △
- 7.
- 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: […]! ! } ] }
- 9. 9 シェル データベースを直接操作す るインラインのシェル 好きな言語を利用可能 ドライバー 殆どの言語とフレームワークを サポート > db.collection.insert({name: "JohnSmith", 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. 10 データモデルを一カ所で管理 アプリケーション Code Relational Database Object Relational Mapping XML ConfigDB スキーマ アプリケーション Code クエリー処理 位置情報 テキスト サーチ Map Reduce Aggregation
- 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のアカウントを全て検索 • 先月アカウントを開いた人を全て捜す 位置情報 • ニューヨーク市内１０マイル以内の顧客を 検索 テキストサーチ • 特定銀行を話題にした呟きを全て検索 データ統合 Aggregation • Markのアカウントの平均貯蓄額 Map Reduce • 普通口座に加え、IRAを持つ顧客のリスト
- 12.
- 13.
- 14.
- 15.
- 16. 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.
- 18. 18 MongoDB Hadoop コネクター オペレーショナル データベース •低レイテンシー" • 高速クエリー処理! • データベースアグリゲーション! • 既知のdata relationships • 長いジョブ" • バッチ処理の分析" • 高度な並列処理" • 未知のdata relationships" アナリティクス MongoDB-Hadoop コネクター
- 19.
- 20. 20 インベストメントバンキング 機能分野 実装されているユースケース リスク分析とレポーティング 企業内統合リスク分析プラットホーム 日中マーケットリスク分析 日中カウンターパーティリスク分析 リスクの例外ワークフロー最適化 リミット管理サービス コンプライアンス要件 柔軟なサイロ間レポーティング: Volker,Dodd-Frank, EMIR, MiFID II, etc 長期オンライン監査証跡 統合型 Know Your Customer (KYC) レポジトリ バイサイド ポータル 対応型ポートフォリオ レポーティング トレード管理 (企業間共通)クロスプロダクトトレードマート 柔軟なOTC デリバティブトレード捕捉 フロントオフィストレーディング 戦略バックテスティング アジャイル戦略設定 戦略パフォーマンス分析 参照データ管理 参照データの配布用ハブ マーケットデータ管理 ティックデータ捕捉 ソーシャルネットワークフィード捕捉 投資アドバイザリー業務 クロスチャンネルのデータをベースとしたクロスセルサービス 拡張された投資リサーチ
- 21. 21 コアバンキング業務 機能分野 実装されているユースケース 顧客エンゲージメント 顧客プロファイルの統一 顧客満足度管理 応答性の良いデジタルバンキングサービス コンシューマアプリのゲーミフィケーション アジャイルな次世代デジタルプラットホーム マーケティング複数チャネル統合の顧客活動記録収集分析 リアルタイムクロスチャネル顧客サービス提案システム ロケーションベースの提案システム リスク分析＆レポーティング 企業内共通流動性リスク分析 トランザクションレポートと分析 規制遵守 柔軟なサイロ間レポーティング: Basel III, Dodd-Frank, etc. 長期オンライン監査証跡 統合型 Know Your Customer (KYC) レポジトリ 参照データ管理 グローバル参照データの配布用ハブ 支払い 企業トランザクションレポーティング 不正検知 統合的なアクセス記録レポジトリ サイバーセキュリティー脅威分析
- 22. 22 保険業界 機能分野 実装されているユースケース 顧客エンゲージメント 統合された顧客情報ポータル 顧客エクスペリエンス管理 アプリケーションのゲーミフィケーション アジャイルな次世代デジタルプラットホーム マーケティング複数チャネル統合の顧客活動記録収集分析 リアルタイムクロスチャネル顧客サービス提案システム エージェントデスクトップ 迅速な顧客動向レポーティング リスク分析＆レポーティング 災害リスクモデリング 流動性リスク分析 規制遵守 柔軟なサイロ間レポーティング: Basel III, Dodd-Frank, etc. 長期オンライン監査証跡 参照データ管理 グローバル参照データの配布用ハブ ポリシーカタログ 不正検知 統合的なアクセス記録レポジトリ
- 23.
- 24.
- 25. 25 High Availability: レプリカセット Read Read ConsistentReads（整合性Read) Eventually Consistent(結果整合性 Reads) ドライバー レプリケーション Read Write プライマリー セカンダリー セカンダリー
- 26.
- 27.
- 28. 28 High Availability: レプリカセット Read ドライバー レプリケーション Readセカンダリー プライマリー セカンダリー Read Write 利用環境：! • 高可用性! • 障害対策! • メンテナンス
- 29.
- 30. 30 • データエンティティの関係を把握しているケース • 例：クエリーに基づいてドキュメントスキーマを設計出来る ! • クロスドキュメントトランザクションがアプリケーションの主 目的では無いケース – トランザクションロジックの重要性と比較して、MongoDBの 利点の方が大きいケース ! • 新規のアプリケーション、もしくはバックエンドのデー タアクセスAPIを変更する事が出来る場合 MongoDBの特性を活かせるケース
- 31. 31 ❑ 複数のソースからデータを収集一極化したい場合 ❑ アジャイル開発を採用、市場にアプリを迅速にリリースしたい場合 ❑スキーマの変更回数が多い事が想定される場合 ❑ 非構造化データ、もしくはデータ構造のばらつきが大きいとき ❑ RDBMSではモデル化しにくい、階層型のデータ構造を持つケース（例：JSON) ❑ データが急激に増加する事が予測される、スケールアウトを活用したいケース ❑ リアルタイムのRead/Writeの性能を重視したい場合 ❑ レプリケーションやキャッシング機能を活用してTCOを出来るだけ低く抑えたいケース ❑ データベースの性能がユーザエクスペリエンスに直接影響を与えるケース ❑ リアルタイム分析やアグリゲーションを必要とする時 ❑ 正準モデル、スケール、TCO、アジリティ面でアプリケーション開発の課題を抱えている ケース Best Fit for MongoDB over RDBMS
- 32.
- 33. 33 課題: 分散しているデータの統合が困難 Cards Loans Deposits … データ ウェアハウス バッチ バッチ バ ッ チ クロスサイロ アプリケーション 課題! • データが古い! • データ詳細が欠落! • 柔軟性の無いスキーマ! • 性能問題 データ マート データ マート データ マート バッチ 影響 • 情報のリアルタイム性 不足! • 顧客満足度の低下! • 機会の損失! • 収益の損失! ! バッチ バッチ レポーティング Cards 株式 Loans 債券 Deposits デリバティブ
- 34. 34 ソリューション: 動的スキーマと水平スケールの採用 データ ウェアハウス リアルタイム／ バッチ … トレーディング アプリケーション リスク アプリケーション 運用データハブ 効果! • リアルタイム性! • 情報の完全性! • 迅速性! • 顧客サービスの質の 向上! • 顧客収益の上昇! • 例外事項への迅速な 対応 戦略的 レポーティング 運用状況 レポーティング Cards Loans Deposits … 顧客 アカウント Cards 株式 Loans 債券 Deposits デリバティブ
- 35. 35 顧客ポリシーや活動情報のグローバル360度ビューを 実現 シングルビューを実現したケーススタディ: Tier 1グローバル保険会社 課題 何故MongoDBなのか？ 成果 • 顧客ポリシー管理に70種の システムと２０種類のスク リーンが必要 • 顧客サービス要求のコール は殆どがコールセンター内 で別担当者に転送される。 • 顧客サービスの評価低下 • データ源のシステムの変更 が困難 • 動的なスキーマ機能を通して 70種のシステムの連携を用意 に実現! • 性能：単一データベースで全 データを運用! • レプリケーション：ローカル リード＋高い可用性! • シャーディング：スケールア ウトを通して用意にデータ拡 張 • $3Mのコスト/3ヶ月の開発作 業 – 過去は同プロジェクトで $25M浪費! • 全販路に対して統一した顧客 データ統合! • サービス要求コールの転送回 数の劇的減少! • 顧客満足度の大幅向上
- 36. 36 課題: レガシーシステムがリアルタイム要 求に対応出来ない データ ソース 1 データ ソース 2 データ ソース N … 開示しにくいエンタプライズシステム! • メインフレーム • 基幹システム! • データウェアハウス! • スケーラブルでないシステム! ! データのバッチコピーは回数が多いと システムが遅くなる! ! ソースデータの変更がシステムに与え る影響が大! ! インパクト • 市場への対応の遅れ! • リソースの消費大! • インタフェースの変更、システム のエンハンスコスト大 アプリ 3 アプリ 1 アプリ 2 アプリ X … バッチコピー 要求に対する 遅いレスポンス
- 37. 37 ソリューション: 固定的なキャッシング サービスでレガシーシステムを仮想化運用 メインフ レーム EDW 基幹 システム … 利点! •市場ニーズへの迅速な対応! • データソース変更に対する 対応も早い ! • 仮想化環境上でのデータ運 用が容易! • 低いTCOでスケーラビリ ティを格段に拡大 アプリ 3 アプリ 1 アプリ 2 アプリ X … … バッチ API バッチコピー バッチコピー
- 38. 38 エンタプライス間共通のデータハブを構築、エンタプ ライス内でのデータアクセスを統合 ケーススタディ: グローバル信託銀行が エンタプライズデータソースを仮想化運用 課題 何故MongoDBなのか？成果 • データの複製がシステム間 で無数に存在する • 一つのシステムでの変更が 複数のグループに影響 • EDWのシステムレスポン スタイムが遅い • 頻繁にアクセスするデータ は集中的に管理したい，と いうニーズ • 動的なスキーマ: 必要な時だ けデータを正規化する! • 性能: 一つの論理DBで全ての データを管理・運用! • シャーディング: スケールア ウトによりデータを容易に追 加 • 一カ所からバッチ，もしくは RESTでデータアクセス可能! • 顧客向けポータルサイトのレ スポンスタイムが90%改善! • 開発期間の短縮! • データソースのエンハンスが 容易
- 39. 39 課題: マスターデータの変更と分散が困難 ゴールデン コピー バッチ 課題! • マスターデータのスキー マ変更が困難! •世界中に配布されたデー タの同期確保が困難! ! ビジネスへの影響" • 同期が保証されていない データによる問題! • 必要な時にアップデート されたデータが無い! • コピー数が多い事による管 理コストが増大 バッチ バッチ バッチ バッチ バッチ バッチ バッチ
- 40. 40 ソリューション: 固定的な動的キャッシュ をグローバルで同期 リアルタイム ソリューション:! • 任意のスキーマでプライマリー DBにデータ追加! •セカンダリーで同期＋Readを 運用 ! 効果" • ビジネススピードに合ったデー タ運用効率! • 容易なスケールアウトによる データ運用! • TCOを大幅に削減 リアルタイム リアルタイム リアルタイム リアルタイム リアルタイム リアルタイム リアルタイム
- 41. 41 各拠点で迅速にローカルアクセス出来る様に、 参照データをリアルタイムで分散／配布 ケーススタディ: グローバル銀行 参照データの配布 課題 何故MongoDBなのか？成果 • バッチ処理によるデータ配 布の遅れが最大36時間に及 ぶ • 同じデータのグローバル配 信に複数課金される • SLA未達成による規制違反 （罰金） • 同じを保有する20カ所の分 散システムを管理する必要性 • 動的スキーマ: データのロード が容易! • 自動レプリケーション: データ 配信がリアルタイム、ローカル にデータを読む事が可能! • キャッシュとデータベースの同 期: キャッシュが常にアップ デート! • 単純なデータモデリングと分 析: 変更が簡単、理解しやすい • 違反金$40,000,000を5年間の 間に節約! • データ配信に対する課金は一 回のみ! • グローバルにデータ同期と各 拠点でのローカルReadが保証 ! • 統一したグローバルデータサー ビスに移行!
- 42. 42 Challenge: Siloed operational applications 株式トレード 債券トレード デリバティブ トレード …影響! • データビューがサイロ 化（個別） • 各システムのデータア クセス層と管理層の重 複! • データ統合のための個 別システムが別途開発 必要 株式システム FI システム デリバティブ システム … レポーティングレポーティングレポーティング
- 43. 43 Solution: Unified dataservices … 効果! • 個々のアプリは独自にデー タを保存可能! • サイロ間のレポーティン グ向けにデータは自動的 に統合される! • 管理対象となるデータア クセスレイヤーの統合! 株式システム FI システム デリバティブ システム … レポーティング ……
- 44. 44 リアルタイムで参照データをリアルタイムでグロー バルに配布、データのローカルアクセスを実現 ケーススタディ: OTCトレードのブローカー 向けのグローバルトレーディングシステム 課題 何故MongoDBなのか？成果 • 各アプリケーションは個 別の監査証跡機能を持つ • 全てのトレーディングア プリに統一した監査向け のデータ収集管理フレー ムワークが必要 • 全ての証券システムの異 なるデータ構造に対応す る必要がある • 動的スキーマ: 一つのデー タサービスに全てのトレー ド関連データを集約出来 る! • スケールが容易: 性能に影 響を及ぼす事無く、長期 持続的にトレード情報を 管理する事が可能! • データの長期保存管理で迅 速な市場展開が可能! • スキーマを意識する事無く、 あらゆる商品/トレード関 連データをストア可能! • 監査／レポート向けに統合 されたトレード関連情報デー タベース
- 45.
- 46.
- 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
- 48. 48 TCO: RDBMSより70%+低い RDBMS CPU: スケールアップ系サーバ ストレージ:SAN 開発／管理工数 CPU: 汎用サーバ ストレージ: ローカルストレージ 開発／管理工数 $1,680K $517K
- 49. 49 アジリティ: 100% 管理工数と比較して開 発工数にリソースを投入 MongoDBを利用RDBMSを利用 DB管理 マッピング管理 ビジネスロジック ビジネスロジック DB 管理 マッピング管理 消費される時間の割合
- 50. 50 MongoDB 製品サービスラインアップ トレーニング 開発者／管理者向けトレーニングをオンライン／オンサイトで実施 MongoDB MonitoringService 無償のクラウドベース監視サービス MongoDB バックアップサービス クラウドベースのバックアップを提供 サブスクリプション MongoDB Enterprise, 監視, 保守サポート, コマーシャルライセンス コンサル MongoDB導入／開発／運用全般に渡る専門家によるリソース提供
- 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