データストレージ管理ツールとしてのデータアクセスレイヤー

エンタープライズアプリケーションのライフサイクル全体を設計する場合、データへのアクセスを整理するという問題は非常に重要です。 これにはいくつかの理由があります。

• データウェアハウスプロバイダーの価格またはその他のポリシーは定期的に変更されますが、データウェアハウスを使用する企業はこれらの変更に必ずしも同意しません。
• 企業の成長とITインフラストラクチャの規模の拡大に伴い、既存のデータストレージソリューションがニーズや財務能力を満たせなくなる可能性があります。
• データストレージテクノロジーが開発されており、特殊な問題を解決するために設計された新しいツールが登場しています。
• オープンソースプロジェクトは、高価な商用ソリューションに代わる安価な、あるいは無料の代替品でさえ成長しています。

これはすべて、ある時点で企業がデータストレージのテクノロジーを変更したい（または強制する）か、現在のテクノロジーと同時に新しいテクノロジーを使用し始めるという事実につながる可能性があります。 ただし、自動化システムの設計において、ビジネスロジックとデータウェアハウスの操作が分離されていない場合、ストレージツールを変更すると、コストがかかり管理が不十分な移行につながる可能性があります。



ビジネスロジックを分離し、個々のアプリケーションレベルでデータを操作する問題は、Habrahabrで繰り返し説明されているよく知られているアーキテクチャテンプレートのData Access Layer（DAL）によって解決されます。 このテンプレートを企業全体のレベルに合わせてスケーリングするには、この記事で検討する多くのアーキテクチャの原則でテンプレートを補足する必要があります。 これらの原則に従うことで、企業は管理された（管理された）交換を実行したり、ITアーキテクチャにストレージテクノロジーを追加したりできます。

発行

このセクションでは、DALコンセプトの開発に至った初期の問題と背景について詳しく説明します。

特殊なデータベースを使用する必要性

現在、従来のリレーショナルDBMS（RDBMS）は、アプリケーション開発中のデータストレージの問題を解決する唯一の手段ではありません。 ユニバーサルDBMSから特殊化への移行があります。 同時に、ストレージ施設の専門化はさまざまな方向に進みます。ボリューム（Big Dataクラス）、負荷（HighLoadクラス）、パフォーマンス（High Performance、Fast Dataクラス）などの点で。



特定のアプリケーションのアーキテクチャの場合、特定のタスク用のツールまたはストレージメディアのクラスの選択が標準に含まれます。 大規模なITシステムでは、同じアプリケーション（異種ストレージ、図1）内でさまざまなタイプの複数のデータベースを異なるデータグループに同時に使用することが最適になることがよくあります。





図 1.ユニバーサルおよび専用データベース



たとえば、リレーショナルモデルで単純な構造データを提示する必要はないが、パフォーマンスとスケーラビリティの要件を高める必要がある個々のタスクでは、専用のキーと値のストアを使用できます。 他の特別な種類のデータ（ドキュメント、写真、ビデオ、Excel、テキスト）およびさまざまな非機能要件には、さまざまなアクセスインターフェイス（NoSQL）を備えた他のストレージデバイスが多数存在し、広く使用されています。



同時に、アプリケーションが中程度の非機能要件（ストレージボリューム、スケーリング、並列処理、パフォーマンス）を伴う複雑なデータ構造と分析クエリを必要とする場合、SQL言語はリレーショナルデータを操作するための最適なインターフェイスのままです。



したがって、開発されたITアーキテクチャを備えた現代の企業は、DBMS（多くの場合OracleまたはMicrosoftデータベース）で使用される「単一のゴールドスタンダード」から離れる必要性にますます直面し、複数のデータベースおよびストレージの形でアプリケーションインフラストラクチャを提供する必要性に直面しています、NoSQLクラスを含む。



これにより、アプリケーションアーキテクチャレベルでは、以前はアクセスできなかった特殊なデータベースを使用する機会が多く出現し、開発を加速し、メンテナンスコストを削減し、根本的に新しいビジネスチャンスを提供できます（もちろん、新しい機能が賢明に使用されない限り）。 たとえば、インメモリストレージを備えたクラスターデータベース（いわゆるインメモリデータベース、一般的な代表はVoltDBまたはSAP HANA）を使用すると、計算を数桁高速化することでビジネスインテリジェンスの問題を解決するための根本的に異なるアプローチを実装できます。



次に、企業の技術アーキテクチャのレベルで、多数の異種データベースを操作する必要が生じます。これにより、すべてのITサービスプロセスのコストが大幅に複雑化および増加し、専門家の再トレーニングが必要になり、使用されるテクノロジーのライフサイクル管理を含む管理タスクが複雑になります。



これらの問題の最適な解決策は、一方で、いくつかの最新の特殊なデータベースを同時に使用する機能と、他方で、企業の一般的なポリシーおよび技術戦略のレベルでのこの設計の制御可能性を組み合わせる必要があります。

環境条件への暴露

企業の技術インフラストラクチャの変更プロセスを開始する2番目の重要な要因は、企業のソリューションプロバイダーの商業（またはその他の）条件の変更です。 これは、RDBMSに特に当てはまります。RDBMSを使用すると、多くの場合、ビジネスアプリケーションは、オペレーティングシステム、ネットワーク機器、またはファイルストレージシステムとより密接に接続されます。



特定の条件下では、いずれかのサプライヤのRDBMSを緊急に交換する必要がある場合があります。 この場合、アクティブに動作する多くのビジネスアプリケーションでデータベースを緊急に交換すると、非常に高価で複雑なプロジェクトになり、情報システム、ひいてはビジネスの障害やダウンタイムが発生する可能性があります。 企業にとってこのような困難な状況に陥るリスクは、必要に応じてDBMSを変更するためのビジネスアプリケーションを段階的かつ体系的に準備することで軽減できます。

近代化と技術開発の必要性

外部条件の変化だけでなく、技術の近代化と開発の必要性も、貯蔵施設を交換するタスクの出現につながる可能性があります。



外部の変更の場合、設計者は、使用されているストレージ施設が古くなっているか、製造業者がサポートしていないか、他の理由で競争力を失っているという事実に直面しています。 ストレージデバイスを交換するためにアプリケーションの大幅な再設計が必要になった場合、支出の面で長い間不合理のままになります。 その結果、企業のアーキテクチャの一部は次第に時代遅れになり、ITサービスは、時代遅れの製品で作業する従業員を選択することが困難であるため、サポート、サポート、および人員配置で問題が発生し始めています。



2番目のケースでは、特定の記憶媒体が競争力を維持している場合でも、技術開発の傾向とタスクは、アプリケーション機能の開発の根本的に異なる機会を開く新しい技術への移行を必要とする場合があります。 既存のアプリケーションが1種類のデータベースまたは企業全体のアーキテクチャのフレームワーク内で密接に接続されている場合、1種類のデータベースのみが固定され、ビジネスアプリケーション開発の多くの可能性が閉じられます。

データアクセス層の概念

このセクションでは、上記の問題を解決できるDALの一般的な概念と原則について説明します。 ここでは、概念が抽象的に説明されており、特定の技術やソフトウェア製品の使用とはまだ関連付けられていません。

管理された特殊なストレージの原則

そのため、開発中のコンセプトは、記載されている問題に対処する必要があります。

• 管理性を維持しながら、企業のITアーキテクチャで特殊なデータベースを使用する機能を提供します（たとえば、その多様性とアプリケーションを制御することにより）。
• DBMSサプライヤとの関係が悪化した場合、または場合によっては技術の近代化と技術開発の理由で、DBMSのスムーズで技術的な変更のためにビジネスアプリケーションを準備する。

この概念は、制御された特殊なデータストレージの原則に基づいており、アプリケーションのさまざまなデータにアクセスする統一された制御された方法を導入します（図2）。





図 2.管理された特殊なデータストレージの原理



企業の技術ポリシーレベルでは、データクラスの固定セットが定義され、インフラストラクチャにいくつかのストレージ機能が提供されます。 この場合、各データクラスは、このクラスに最適な特殊なアクセスインターフェイス（これまで-論理レベル）を想定しています。 たとえば、キー値データクラスの場合、アクセスインターフェイスはキーデータの読み取りおよび書き込み操作を提供する必要があります。 また、「リレーショナルモデル」データクラスの場合、アクセスインターフェイスはいくつかの固定SQLダイアレクトの形式で表示されます。



このような論理データクラスごとに、インフラストラクチャはストレージファシリティにさまざまなレベルの非機能要件を提供できますが、これは一部のSLA（ストレージクラスで定義）によって明確に修正されます。



エンタープライズアプリケーションは、さまざまなデータクラスと対応するアクセスインターフェイスを要求して使用し、現在1つまたは別のインターフェイスを実装している特定のテクノロジから抽象化します。 さまざまなデータベースへのアクセス制御は制御モードで提供され、アプリケーションはどのデータベース実装を使用するかを「知りません」。



その結果、一方では、アプリケーションは、明確に定義されたプログラムインターフェイスを介してアクセスする特殊なストレージ機能を使用できます。 一方、特定のDBMSを同様のDBMSに置き換える必要がある場合は、アプリケーションに重大な変更を加える必要はありません。 極端な場合、アーキテクチャの改訂を必要とせずに、新技術の小さな機能に比較的安価に適応する。 企業レベルのデータ「アプリケーション-さまざまなDBMS」へのアクセスの構造全体が観察可能になり、制御されます。

ソフトウェアアーキテクチャレベルでデータにアクセスする方法を制限する

図 3.ソフトウェアアーキテクチャレベルでデータにアクセスする方法を制限する



もう1つの重要なDALの原則は、ビジネスアプリケーションにデータアクセスの選択された方法を提供するメカニズムに関連しています（図3）。 理論的には、企業のアーキテクチャポリシーのレベルでデータへのアクセスに関する多くの制限を修正し、情報システムを設計および開発する際にこれらの制限への準拠を監視すれば十分です。



ただし、実際には、このような制御を整理することは困難です。 これには、時間のかかるエンタープライズの専門家アーキテクトが必要です。 同時に、何らかの理由で情報システムの製造業者が契約データクラスとSLAを超えない可能性があります。 このような先例の経時的な蓄積は、データアクセスインターフェイスが正式に制限されているにもかかわらず、アプリケーションが別のDBMSに移植できないという事実につながります。



この問題の解決策は、アプリケーションをDBMSから完全に分離することです。そのため、アプリケーションは原則としてDBMSに直接アクセスできず、専用のデータアクセスモジュール（データアクセスレイヤー）を介してのみ動作します。 実際、DALはソフトウェアアーキテクチャレベルでのデータアクセスに関する企業のアーキテクチャポリシーをキャプチャし、仕様および規則のレベルでの修正と比較して、データクラス契約のパフォーマンスをはるかに保証します。



さまざまな基本技術で実装され、さまざまなデータアクセスインターフェイスを必要とする情報システムでは、DALモジュールの実装が異なる場合があります。 これらのモジュールのインスタンスは、アプリケーションごとに異なる場合もありますが、リソースを節約するため、または逆にシステムの機能の独立性を確保するために、一般的な場合もあります。 ただし、すべての場合において、ストレージ施設へのアプリケーションの間接的なアクセスの原則を尊重する必要があります。

データベースからビジネスロジックを削除する

ユニファイドアクセスインターフェイスを介してアプリケーションをストレージから分離するという原則は、アプリケーション自体がデータベースの外部に展開されている場合にのみ、代替ストレージテクノロジーにすばやく切り替える問題を解決できます。 実際には、アプリケーションのビジネスロジックの大部分が組み込みの手続き型言語でDBMS内に実装されている情報システムが依然として頻繁に見つかり、積極的に使用されています。 このようなシステムの場合、ビジネスロジックをDBMSから別のアプリケーションサーバーに削除してシステムを処理することによってのみ、他のDBMSへの容易な移植性を実現できます。



新しく開発された、または積極的に開発されているすべてのシステムでは、DBMS内に大量の機能が蓄積しないようにする必要もあります。これにより、別のストレージメディアへの切り替えが困難になります。 データにアクセスするプロセスだけでなく、データ構造とDBMS設定を管理するプロセスにも中間リンクを埋め込む必要があるため、これを制御することは技術的に困難です。 したがって、このような制御は、新しいシステムとその更新の展開中、および専門家の評価を使用して提案された技術ソリューションのアーキテクチャ監査のプロセス中に確保する必要があります。

コンセプト

このセクションでは、前のセクションで簡単に紹介したDAL記述オブジェクトモデルを改良し、詳細に説明します。





図 4. DALの概念の概念モデル



この概念では、いくつかの概念を紹介しています（図4）：

• データクラス
• 記憶媒体;
• 記憶媒体の特性。
• ストレージクラス
• データグループ;
• データコンテナ。

これらの概念と分類法は、ASを設計するための方法論的なツールとして、また企業全体のデータストレージのレベルを管理する手段として使用されます。

データクラス

特定の技術や実行可能性の制限に依存しない理想的なデータ抽象化を定義します。

• データ自体の抽象（「論理数学」）モデル（たとえば、「関係関係のセット」または「キーと値のペアのセット」）。
• データへのデータアクセスと計算のモデル（または複数のモデル）（「リレーショナル代数」またはMapReduceなど）。
• セキュリティモデル（たとえば、「名前付きコンテナー」、「ユーザー」、および「権利」）;
• データ構造モデル（たとえば、「テーブルの説明を含むスキーマ」または「属性グループのリスト」）。

データクラスレベルでは、トランザクションの問題、パフォーマンスの問題、メモリ内実装の特性はありません。 アプリケーションのビジネスロジックは特定のデータクラスに基づいて実装されており、アプリケーションロジックを再設計しない限り、データクラスの変更は一切発生しません。

データ構造

特定のアプリケーションに固有の特定のモデル（データクラスで定義）のデータ構造を定義します。たとえば、リレーショナルモデル、テーブルのリスト、列、キーなどです。

保管施設

市場で入手可能な、または企業で展開されている特定のストレージ施設（さまざまな種類のデータベース）は、複数のデータクラスに対して1つ以上のクラスのストレージ施設の機能を提供します。

ストレージ機能

記憶媒体の重要な数値的、定性的特性、またはバイナリ記号を表します。

• 読み取り/書き込みパフォーマンス。
• 拡張性
• メモリー内での作業（メモリー内）。
• 制限事項
• 専門化（例：ビッグデータまたは高速データ）
• ACIDトランザクションなどのサポート

ストレージクラス（SLA）

1つのデータクラス内で、このような一連のストレージ特性をグループ化します。これは、一方でアプリケーションで頻繁に需要があり、他方で代替実装（ストレージツール）を提供します。



データクラスごとに異なるSLAを定義できます。 あるストレージクラスから別のストレージクラスにアプリケーションデータを転送するには、SLAプロパティの弱体化または欠落に対する補償が必要になるため、部分的な再設計が必要になる場合があります。 別のデータクラスまたはストレージメディアに配置するためにアプリケーション内のデータの別のグループを分離する必要がある場合、変更を行うこともできます。その後、このデータを他のグループと統合します。

データグループ

特定のアプリケーション内のデータは、このアプリケーションのロジックに従って、同じデータクラスに属し、1つのSLAが必要です。 たとえば、アプリケーションでは、キー値クラスに属し、キーによる迅速な読み取りが必要な「Xリファレンスブック」データグループを選択できます。

データコンテナ

何らかの記憶媒体を使用して保存され、1つのアプリケーションの1つのデータグループに対応する識別可能な量のデータ。 データストレージリクエストに応じて、1つ以上のデータコンテナがアプリケーションに割り当てられます。

データアクセス層の構造

このセクションでは、統合データアクセスの概念を実装するDALソフトウェアの基本構造について説明します。 DAL構造の説明には、特に、特定のテクノロジーとソフトウェア製品の選択と適用の問題が含まれます。

エンタープライズITランドスケープのDAL機能と境界

DAL構造は、エンタープライズITアーキテクチャのフレームワーク内で統合データアクセスレイヤーを構築するために使用できるソフトウェアツールのセットであり、「マネージドスペシャライズドデータストレージ」の原則を実装し、ソフトウェアアーキテクチャの厳密な形式で修正します。 DALは、ビジネスアプリケーションとストレージ施設（データベース）の間に制御された「レイヤー」を形成します（図5）。





図 5.エンタープライズアーキテクチャのDAL構造



DAL構造は、さまざまなアプリケーションのデータへのアクセスを整理するための疎結合ソフトウェアモジュールのセットです。 モジュールの弱い接続性により、さまざまなアプリケーションおよびDALソフトウェアの開発および更新プロセスの同期における問題を回避できます。 アクセスモジュール自体は、ビジネスアプリケーションが開発されるさまざまな基盤技術の特定の実装を持つことができます。

DALの設計原則

1. タスクは、自動的に、ノンストップで、無料で、または作業中のスピーカーをある記憶媒体から別の記憶媒体に即座に切り替えるように設定されていません。 設計上の決定は完全に除外するべきではありません（長くて困難です）が、可能な移行を大幅に促進するような方法で、ストレージメディアへのアプリケーションロジックの依存を大幅に減らします。 AC設計者の合理的なアプローチと、アーキテクチャの原理と目標に対する彼らの理解に頼る必要があるため、超保護された技術システムを構築しようとはしません。
2. 設計するときは、既成の、市場にすでに存在する標準化されたツールとコンポーネントを最大限に使用する必要があります。 企業がベンダーから最大限の独立性を確保したい場合は、オープンソースの製品とテクノロジーを使用することが望ましいが、十分な成熟度があり、適切なコミュニティサイズと責任ある企業での実装例が必要です。
3. 既存のスピーカーをDALに簡単に転送できるように努力する必要があります。
4. 実装されたDALの機能を徐々に、反復的に増やしていくことをお勧めします。 最初のステップは、最も差し迫った問題（特に、リレーショナルDBMSの移植性）を解決することを目的とした、シンプルで安価で迅速なものでなければなりません。
5. ストレージ管理への新しいアプローチは技術的手段に限定されないかもしれませんが、例えば、インフラ管理の観点から企業の組織メカニズムの変更、ならびに原子力発電所の設計と技術監査を含みます。

DAL構造コンポーネントの配置オプション

図 6. DAL構造コンポーネントの配置オプション



DAL構造には、データアクセスモジュールを配置するための2つのオプションが含まれます（図6）。

1. アプリケーションに含まれるライブラリの形式。 このオプションでは、さまざまなスピーカー開発テクノロジー用にさまざまなタイプのアクセスモジュールを開発する必要があります。
2. ネットワークサービスの形式。 このオプションは、何らかの理由で、データアクセスサービスがライブラリの形で不可能または望ましくない場合を対象としています（たとえば、ISは、DALを操作するためのライブラリを持たないプラットフォームで開発されています）。 このバージョンでは、DALはHTTP経由でネットワークサービスを操作できるすべてのアプリケーションで使用できます。 この配置方法では、提供されるデータアクセスインターフェイスのセットが制限される場合があります。

データアクセスプログラミングインターフェイス

各クラスのデータへのビジネスアプリケーションのアクセスを実装するには、プログラムアクセスインターフェイス（API）の業界標準および事実上の標準を優先する必要があります。 これにより、既存のスピーカーをDALで動作するようにできるだけ簡単に適応できるだけでなく、その後の技術的変化に対するデータアクセスレイヤーの長期的な安定性も確保できます。



ビジネスアプリケーションが使用するために受け取るデータアクセスプログラミングインターフェイス（API）は、基になるアプリケーションテクノロジによって異なる場合があります。 これにより開発が合理化され、この基盤となるテクノロジーの事実上の標準に適合します。 この分離は、統一されたデータアクセスの概念の一般原則に違反しないことに注意することが重要です。これは、アプリケーションが使用される特定のデータベーステクノロジーから独立しているためです。 たとえば、Javaで開発されたアプリケーションの場合、リレーショナルデータにアクセスするための標準インターフェースはJavaの世界で受け入れられているJDBCインターフェースであり、C / C ++のアプリケーションではODBCインターフェースが提供されます。

ODBC / JDBCインターフェースを介して作業する場合のSQLダイアレクトの制限

図 7. SQLの統合と翻訳



リレーショナルデータの場合、最新のDBMSは、SQL言語の多くの特定の機能と方言を提供します。 アプリケーションでさまざまなツールを積極的に使用すると、移植性が低下します。 したがって、DAL実装の一部として、SQLベースのリレーショナルデータアクセスモジュールは、アプリケーションが原則として特定のDBMSの機能に依存できないように、使用するSQL方言を明確に制限する必要があります（図7）。



使用される方言を制限するタスクに加えて、個々のSQL構文要素を特定のDBMSの方言に変換するという問題も発生します。 この必要性は、アプリケーション機能RDBMSの一般的で広く使用されているものが、それらの大部分に存在するものの、SQL標準に含まれていないという事実により発生します。

Javaアプリケーション用のRDBMSアクセスモジュール

上記の設計原則に基づいて、DALを実装するための最初で最も関連性の高いモジュールは、リレーショナルデータアクセスモジュールです。 問題のある企業ビジネスアプリケーションで説明されているように、NoSQLデータベースを使用する可能性をますます活用しているという事実にもかかわらず、リレーショナルデータベースは依然として最も広く使用され、要求されているタイプのストレージツールです（多くの場合、多くのアプリケーションソフトウェアが既に開発されているためです） RDBMSに基づく）。



また、さまざまな基盤技術に実装されたアプリケーションの場合、さまざまなアクセスモジュールの開発が必要になる可能性が高いことを思い出してください。 このセクションでは、Javaアプリケーション用のDALモジュールの設計について説明します。 この技術は大企業や銀行に広く普及しており、統一されたデータアクセスインターフェイスの開発の基盤として利用できる、安定したサポート対象の業界標準が多数あります。

リレーショナルデータアクセスインターフェイス

Javaアプリケーションの場合、2つの標準RDBMSアクセスインターフェイスが広く普及しています。

• JDBCインターフェースおよびSQL言語を介したリレーショナルデータへの直接アクセス。
• JPA Object Relational Adapter（Java Persistence API）を介したオブジェクトモデルを介したアクセス。

実際には、アプリケーションはこれら2つのアクセス方法の組み合わせを使用します。 JPAはデータの変更と単一オブジェクトの読み取りによく使用され、複雑なレポートと選択の場合、SQLクエリはJDBC接続または特別なJPA入力（いわゆるネイティブクエリ）を介して直接実行されます。



これらの2つの方法を統合アクセスインターフェイスとして一緒に修正することをお勧めします。 JDBCおよびJPAネイティブクエリを使用すると、任意のDBMSの構文で任意のクエリを実行できるため、上記のように、直接クエリで使用されるSQLダイアレクトを何らかの「統一」オプションに明示的に制限する必要があります。

Java用のDALモジュールの建設的な実装

したがって、JavaアプリケーションにRDBMSにアクセスするためのDALモジュールは、JPAおよびJDBCインターフェースを提供する必要がありますが、同時に、必要に応じて別のRDBMSへの最も効率的な変換を提供するために、SQLの使用を「統一」バージョンのみに制限する必要があります。



このような要件を備えたモジュールは独立して開発できますが、最適なオプションは、これに近い機能を備えた既製のソフトウェアコンポーネントを使用することです。 弊社では、このようなコンポーネントとしてDALを実装する際に、多数の利用可能な最終製品を分析した後、元々 は企業全体のデータへのアクセスのフェデレーション（仮想化）を目的としたJBoss Teiid製品を選択しました（図8）。





図 8. Java用のDALモジュールの建設的な実装



JBoss Teiidの次の機能とプロパティは、上記のDAL要件を満たしています。

• Javaアプリケーション用のJPAインターフェースの提供
• Javaアプリケーション用のJDBCインターフェースの提供
• （SQL-99標準に基づく）独自の統合SQLダイアレクトを使用します。
• 独自のSQL方言の、サポートされているデータベースの特定の方言への翻訳。
• 最も使用されるRDBMSへのコネクタの可用性と単純な拡張性。
• 組み込みモジュールモードとネットワークサービスモードの両方で動作する機能。
• オープンソースコード（オープンソース）、商用目的での無料使用の可能性、開発されたコミュニティ、および大企業での実装例。

さらに、Teiidを使用すると、次の追加機能が開きます。

• ビジュアルデザイナーを使用して、設定でいわゆる「仮想DB」（仮想DB、VDB）を作成することにより、データベースを結合します。 このような「仮想データベース」は、（リレーショナルだけでなく）実際のストレージ機能に関連付けられています。
• 「クロスクエリ」の効率的な実行-「仮想データベース」へのSQLクエリ。これは、実際のデータベースへのSQLクエリに自動的に変換されます。
• クエリの結果を「仮想データベース」にキャッシュします。

DALの例

PostgreSQLへの移行の可能性を検討する一環として、当社は、ITシステムの1つをOracleからこのDBMSに移行するパイロットプロジェクトを実施しました。 オブジェクトは、3層アーキテクチャの原則に基づいて構築された決済バックオフィスシステムでした。 ITシステムのビジネスロジック（基本的な計算）のほとんどはアプリケーションサーバーレベルにあり、ロジック（アカウンティング）の一部はOracleストアドプロシージャにありました。 このITシステムを設計する際、データアクセスレイヤーを介したデータアクセスの原則はもともとアーキテクチャに組み込まれていました。 この層は、Hibernateを実装したJPAテクノロジーに基づいて構築されました。



移行は短時間で実行する必要があり、アカウンティングコンポーネントロジックのPostgreSQLへの転送にはかなりの時間がかかるため、最初に中間オプション-OracleとPostgreSQLでのハイブリッドデータストレージを同時に実装することにしました。Oracleでは、アカウンティングロジックとそれに必要なテーブルが残り、PostgreSQLでは、アプリケーションデータの残りが移行されました。アカウンティング部分のPostgreSQLへの移行は、移行の第2段階で計画されました。



JBoss Teiid: « », PostgreSQL Oracle. . DAL, . DAL Oracle SQL- Teiid . - . .



Oracle PostgreSQL 同僚のマキシム・トレグボフ。



また、DALを介したデータへのアクセスを整理するアプローチは、当社の多くのアプリケーションの近代化に積極的な役割を果たしました。アップグレード中に、さまざまなアプリケーション操作ログ（監査ログ、外部システムとの対話など）がHadoopに基づいてアーカイブストレージに転送されました。残りのアプリケーションデータは、運用リレーショナルDBMSに残りました。ログデータへのアクセスは独自のAPIを備えた別のコンポーネントを介して実行されたため、ストレージツールの置き換えはアプリケーションの残りの機能に影響を与えず、大幅な変更を必要としませんでした。

おわりに

企業がITインフラストラクチャの特定のソリューションのサプライヤーからの独立性を維持したい場合、エンタープライズITシステムの開発者は、これらのソリューションの仕様から可能な限り抽象化する必要があります。データアクセスレイヤーのアーキテクチャ原則に従うことにより、企業は独自のDBMSの人質にならず、データストレージの機能とコストに最適なソリューションを選択できます。さらに、会社は、AUに大幅な変更を加えることなく、新しいテクノロジを使用してデータを操作する機会を得ることができます。