Caché ∼金融サービスにおけるデータ管理 ∼ 概 要 金融サービスにおいて業務効率を改善する１つの方法は、データ管理の基盤を見直すことである。複数のアプリケーショ ンで使うデータのセントラルレポジトリを構築することは、データの一貫性と企業全体としての品質を確保し、統合における ボトルネックを解消し、取引の不成立を低減することに繋がる。 しかし、それぞれのアプリケーションは異なるデータ使用パターンがある。全てを満たすには、いかなるセントラルデータレ ポジトリも、以下の要件が必要である。 高速処理による膨大なトランザクション数をサポートする クエリに対する高速レスポンスを、最新情報を基に提供する 信頼性が高く、スケーラブルな永続性を提供する 全く異なる複数のアプリケーションから簡単にアクセスできる この白書では、多様なデータベース技術について言及し、それらがセントラルデータレポジトリの要件に合致するかを考え る。伝統的なリレーショナルデータベースは、一般的に、「ライブ」トランザクションデータに対するクエリに対して、求められ るパフォーマンスは出せなかった。また、オブジェクト指向技術で書かれたアプリケーションと接続することも困難であっ た。「インメモリデータベース」は高速だが、拡張性に乏しい。また、信頼できるデータの永続性も提供できない。 高速で拡張性に非常にすぐれた多次元データベースである Caché は、クリティカルなデータ管理の能率化を求める金融 サービス業者にとって最適な選択である。 Caché がもつビットマップインデックス技術は、同時クエリとトランザクション処 理を可能にする。さらに、Caché は、広範囲な接続性があり、既存のデータ保存など、全く異なる多くのアプリケーションと コミュニケーションが可能で、従ってデータ管理インフラを段階的に変更することができる。 序 章 多くの金融サービス業者には、段階的にデータ統合をしようという傾向が高まっている。購買側の経営者と販売側の企業 は、彼らの多くのアプリケーションは同じデータを使っており、セントラルデータレポジトリで共通のデータを維持することに よって、業務効率を向上させることができると気付き始めている。そういったアプローチは、クリティカルなアプリケーション によって使用されるデータの一貫性や品質を改善する。それは、企業内の異なるアプリケーション間でのデータ同期の必 要性によって起こる 「統一のボトルネック」 を軽減する。それはまた、リアルタイムレポートと現在のデータによる分析を可 能にする。その結果、取引不成立数を減少させ、パフォーマンスを改善し、よりよい意思決定が可能となる。 しかし、内部セントラルデータレポジトリを構築することは、難しいタスクである。理想的には、セントラルデータレポジトリ は、トランザクションデータベースとデータウェアハウスの両方の属性を持ち合わせていなければならない。最新の大量デ ータを処理しなければならないのと同時に、現在そして過去の膨大なデータが関係するクエリに高速にレスポンスする必 要がある。もう１つの難しさは、異なるアプリケーションは、異なる言語で書かれ、異なるデータアクセスプロトコルを使って いるということである。セントラルデータベースは、それら全てと互換性がなければならない。最後に、理想的なセントラル データレポジトリは、データ統合に対するモジュラアプローチを可能にすることである。既存のメッセージシステム、既存の データストアと連携し、それらへの投資を最大に利用できなければならない。 この白書では、金融サービスにおいて一般に使用されているいくつかのデータベース技術について論じ、それらがセントラ ルデータレポジトリの要件に合致するかについて考える。高速、多次元データベースである Caché が、なぜデータ統合の 最良の選択であるのかを説明し、Caché を使うことで、金融サービス業者がデータ管理インフラの移行によっていかに業 務効率を上るかという例示をする。 データ統合の問題 直進的な処理とリアルタイムのコンプライアンスモニタリングをしながらの取引および、業務効率改善への継続的なニーズ は、多くの金融サービス業者がデータ管理インフラを改善する大きな駆動力となっている。購買側と販売側の企業の多く は、共通のデータ塊にアクセスしており、よって、セントラルレポジトリに共通のデータとして統合することは有意義である。 クリティカルデータの一元化は、企業内の異なるアプリケーションで使われる情報が統一的でかつ最新のものであることを 保証する。その結果、取引不成立が減り、パフォーマンスが改善され（なぜなら、システム間のデータ調整が短時間で行わ れるからである）、現在のデータに基づく意思決定ができるようになる。 データ統合は大きな利益をもたらすが、膨大なデータの集中化プログラムに対しては、躊躇する企業もある。なぜなら、そ こに、大きなコストと難しさがあると思われるからである。理想的には、セントラルデータレポジトリは、リスク管理、パフォー マンス評価、会計、取引や参照データ、コーポレートアクションサービスなど、多くのシステムとのインターフェースをもつこ とである。さらに、セントラルデータレポジトリは、アナリスト、インテグリティユーザ、コンプライアンスユーザから出されたク エリに対し、高速にレスポンスしなければならない。コストを制御し、スムースなオペレーションを保つために、データ管理イ ンフラの変更に対して多くの企業は、段階的、モジュラアプローチを希望する。 先に触れた全てのニーズは、金融サービス業者がセントラルデータレポジトリを可能にさせるデータベース技術に対して大 きなデマンドがあることを示す。新データインフラのためのデータベース技術の選択は、大変重要といえる。その要件は、 以下の通りである。 大量のデータに対し信頼性の高い永続性 データは金融サービス組織にとって、生命線である。それらは、常に利用でき、かつシステムダウン時には、回 復可能で、膨大なデータの保存、取出しが可能でなければならない。 • 大量なトランザクションを高速処理・完結すること セントラルデータレポジトリにアクセスするアプリケーションは、トランザクションデータベースが必要である。デー タ読み取り、挿入、更新が高速に行えなければならない。こうしたアプリケーションは、パフォーマンスが鍵であ る。なぜなら、セントラルデータベースが、変更をより高速に処理できれば、与えられた時間で、それだけ多くのト ランザクションを完結することができるからである。 現在そして過去のデータに対する複雑なクエリへの高速レスポンス セントラルデータレポジトリにアクセスするアプリケーションには、トレンド分析、レポーティング、コンプライアンス モニタなどのためのクエリ処理を行うものがある。そうしたアプリケーションの多くは、最新のデータにアクセスす ることが有益である。（コンプライアンスモニタリングの場合、法的に必須である） 一般的には、データベースシ ステムは、インデックスを使ってクエリ時間を短縮する。それにより、セントラルデータの重要な属性は、素早く変 わりゆくトランザクションデータにインデックス構築ができるのである。 異なる多様なアプリケーションにシームレスで高速なインタラクション 企業内の異なるアプリケーションは、異なる技術、異なるプロトコル、異なる標準を使っている場合がある。それ らを相互に操作可能にするには、セントラルデータは、Java、 C++、.NET、 XML、 Web サービス、FTP、 ODBC, RV, e-JMS あるいは世にある他の技術を使って呼び出され、コミュニケーションする。しかし、相互操 作はそれだけでは不十分だ。異なるアプリケーションとのインターフェースは、全般的なパフォーマンスに影響が ないよう、効率的でかつ高速でなければならない。 適用が簡単で、拡張性が高い 金融サービス業者は、データ管理インフラの改善を段階的に取り組むところが多い。従って、システムにアプリケ ーションを統合するときに新しいデータ吸収するには、セントラルレポジトリは、簡単に適用できなければならな い。拡張性は、セントラルデータが新しい技術との互換性を確保するのに役立つ。 この白書を記憶に留めてもらうため、セントラルデータレポジトリを構築するとき、様々なデータベース技術がもつ困難さに ついて論じる。 リレーショナルデータベース リレーショナルデータベース技術は、信頼性の高いデータ永続性を提供して 25 年以上になる。簡単に理解できるデータ構 造であるところがその利点である − 全ての情報は単純な行と列のテーブルに格納される。さらに、リレーショナル技術 はクエリ言語（SQL）をもち、これがデータベースの世界では、デファクトスタンダードとなっている。 しかし、リレーショナル技術は、超高速処理が必要な場面では、ニーズを満たせない場合がある。テーブル型のデータ構 造は、複雑で現実世界の情報には上手く合致しない。複雑なデータは、複数の関連テーブルに分割され、アクセス・使用 する前にジョイン（結合）しなければならない。データの分割・再構築を繰り返すことで、プロセスのオーバヘッドは増し、トラ ンザクションのパフォーマンスは落ちる。 同様の問題は、リレーショナルデータベースが、Java や C++などのオブジェクト指向技術と動作する必要がある場合にも 起こる。こうした場合、データとリレーショナルデータベースで使うテーブルを、そのアプリケーションが使うオブジェクトに翻 訳するマッピングが必要である。 リレーショナルデータベースのパフォーマンス低下は、シンプルなアプリケーションでは分かりづらい。しかし、リレーショナ ル技術をセントラルデータレポジトリに適用する場合、特にクエリの速度を上げるためにインデックスを構築する場合、パフ ォーマンス低下は顕著になる。リレーショナルデータベースは、トランザクショナルシステムとデータウェアハウスを同時に 行うようには設計されていない。 こうしたことから、企業の中には、２つのセントラルデータレポジトリを構築するアプローチをとることもある。１つは、クエリ 処理するデータウェアハウスに定期的にデータを渡すトランザクションシステムである。しかし、トランザクションシステムの 適正なパフォーマンスを維持するためには、クエリシステムへのダウンロードは頻繁には行えない。よって、クエリシステム にアクセスするアプリケーションは、通常 1 日古い、あるいは 1 週間古いデータを分析することになる。こうした状況は決し て望ましいものではない。そして、リアルタイムコンプライアンスモニタリングが新しく必要になった時点で、これは許容でき ない。 「インメモリ」 データベース いわゆる 「インメモリ」または、「メインメモリ」 データベースは、正に文字通りのものである。データをディスクに書くのでは なく、ローカルなメモリに保持する。ディスクからの読み込みや書き込みがないため、トランザクションは大変高速に処理さ れる。高速処理はインメモリデータベース技術を使う上での最大の利点である。 しかし、インメモリデータベースは、データの永続性を持たず、問題時のデータリカバリのメカニズムは、ほとんどのアプリ ケーションには現実的でない。さらに、全てのデータをメモリ上に保持する必要があるため、システムには、非常に大量の データを処理する拡張性がない。インメモリデータベースは、トランザクション速度が最重要である小規模のアプリケーショ ンには有用だが、セントラルデータレポジトリ構築には適さない。 多次元データベース Caché インターシステムズ社の Caché は、高速多次元データベースである。単純な行・列の形式ではなく、データを柔軟で効率 的な多次元配列に格納する。Caché は、ユニークなアーキテクチャをもち、セントラルデータレポジトリの構築を目指す金 融サービスには最適な選択である。 高速性 行・列の形式にデータを保持しないため、Caché は、複雑なデータを分解せずに格納できる。リレーショナル技術では通 常行われるジョイン（および関連処理のオーバーへッド）をなくすことで、Caché は、信頼性の高いデータ永続性およびイ ンメモリデータベースにも匹敵するトランザクションの高速処理が可能である。 超拡張性 Caché の効率的な多次元データ構造は、本質的に同じ情報をもつリレーショナル表現よりもコンパクトである。データをそ のまま保存するので（関連テーブルに分割することがない）、トランザクションのパフォーマンスは、データサイズの増加に 影響されない。さらに、Caché の ECP 技術は、分散構造におけるアプリケーションサーバとデータサーバ間のネットワー クトラフィックを劇的に減少させ、結果としてアプリケーションサーバの追加やユーザ数の増加を可能にする。Caché ベー スのアプリケーションは、パフォーマンスを犠牲にすることなく、数千もの同時ユーザをサポートする。 トランザクショナルビットマップインデックス Caché は、動的なデータに対するインデックス構築が可能な高速性のある唯一のデータ管理技術だ。この意味するとこ ろは、大量のデータの更新が可能なトランザクショナルデータベースであり、また同時に、複雑なクエリに高速レスポンス が可能なデータウェアハウス機能を提供できるということである。 シームレスな接続性 もう１つの Caché の利点は、多次元データ構造にあり、それにより自動的に様々なフォームに投影することができ、マッ ピングやそれに伴う処理のオーバヘッドなしに他の技術との接続性を提供する。 リレーショナル接続 多次元配列は、2 次元配列（テーブル）として投影することが可能で、よって、Caché は、リレーショナルデータ ベースのように見ることができる。Caché データベースは、ODBC や JDBC 準拠で、SQL によるクエリが可能で ある。さらに、Caché のリレーショナルゲートウェイ機能により、既存のリレーショナルデータベースに保存され たデータにアクセスが可能である。 オブジェクト接続性 Caché の多次元配列は、オブジェクト指向技術で使われる複雑なデータ構造によく適する。データは、オブジェ クトとして格納でき、 Java、C++、 COM、 EJB、XML などの多様な形式に投影される。また、Caché オブジ ェクトメソッドは、マウスの数回のクリックで Web サービスとして公開できる。 他技術との接続性 Caché は、TCP ソケット、FTP、SMTP など他様々なプロトコルや標準とコミュニケート可能である。また、一般 的なミドルウェアやメッセージング技術とも互換性をもつ。 こうした広いオープンな接続性により、Caché ベースのセントラルデータレポジトリは、企業内のいかなるアプリケーション にもシームレスに接続が可能である。 迅速な開発 Caché のオブジェクトモデルは、多重継承、ポリモフィズム（多態性）をサポートし、コンポーネントの再利用やアプリケー ション開発の迅速化が可能だ。オブジェクト指向開発技術は、また、どのような Caché ベースのシステムでも、簡単に適 用可能で拡張性に優れる。 アーキテクチャ例 図１は、アセット管理会社で、Caché がセントラルデータレポジトリで使われる例を示している。Caché が、STP、リスク 管理、パフォーマンス管理、コンプライアンスおよび取引モニタリングをサポートするトランザクショナルデータウェアハウス として機能していることを示す。１つのように表示されているデータインフラは、より優れたデータの一貫性と品質、業務効 率向上を可能にする。 図１− Caché によるデータ管理インフラ 図１は、多くの場合、セントラルデータベースにアプリケーションをリンクする先進的なプロセスの最終結果となる。この例で 仮のアセット管理会社が段階的にデータインフラを改善する多様なステップについては、以下に示す。 1. Caché で構築したリスク管理データモデル DDL を既存のリスク管理システムからインポートし、それを Cache 内のデータ構造の定義に使用して構築している。これは、いくつかの変更を加え、Caché オブジェクト技 術の利点を利用しデータモデルを改善した。その上で、履歴参照とポジションデータを Caché に移行した。 Caché の C+＋オブジェトバインディングが、リスクマ管理システムとコミュニケーションするために使用されてい る。 2. パフォーマンス評価システムは、セントラルレポジトリに接続されている。これは、データモデルにいくつかの変更 が必要で、継承を使うことで簡単に行えた（ステップ１で作成したクラスを拡張）。この仮の例において、Java バイ ンディングは、セントラルデータベースがパフォーマンスシステムとコミュニケーションすることが求められている。 3. 参照データサービスとコーポレートアクションサービスは、Caché データベースに直接データを取り込むように 設定されている。よって、Caché のレポジトリは、全てのセキュリティ参照データ、コーポレートアクション、証券 価格（取引システムより取り込まれる）に対して 「マスタコピー」 となっている。さらに、リレーショナルゲートウェ イにより、セントラルデータベースは、既存のデータウェアハウスと業務システムから必要に応じてデータを引き 出す。 4. 取引システムは、セントラルデータレポジトリにリアルタイムに接続される。これにより、確定収入・株式システム の全てのアクティビティに対するコンプライアンスクエリを走らせることができる。Caché の ECP は、分析、デー タインテグリティユーザおよびコンプライアンスユーザによる膨大な処理ロードの分散に使われる。 結 論 金融サービス組織は、データ管理インフラを変更することで、データの一貫性と業務効率を改善可能で、それにより、クリ ティカルなアプリケーションは、１つのセントラルデータレポジトリにアクセス・更新ができる。効率を考え、セントラルデータ ベースは、一定の機能、主にはトランザクショナルデータベースおよびデータウェアハウスとして同時に機能することが求 められる。また、様々な技術、プロトコル、標準をベースに開発された異種のアプリケーションに対する高パフォーマンスの 接続性も必要である。 金融業界において広く使われているデータベース技術のなかで、唯一、インターシステムズの多次元データベース Caché だけが、セントラルデータレポジトリの厳しい要件を満たすパフォーマンス、拡張性、柔軟性、そして信頼性を備え ている。 * 本白書は、米国インターシステムズ社の“Caché and Data Management in the Financial Services Industry”の 日本語訳です。不明な点は、英文本文にてご確認ください。 インターシステムズジャパン株式会社 http://www.intersystems.co.jp
© Copyright 2024 Paperzz
