データの抽象化により、開発者や管理者は、データサイロ全体にアクセスする必要がないため、必要なデータのみをフロントエンドのユーザーに表示できます。抽象化はソフトウェア開発のいくつかの分野で使用され、アプリケーションのデータ層はデータベースをユーザー・インターフェースから分離します。インフラ変更時のスケーラビリティの向上とリファクタリングの低減を目的としています。
DBMS（データベース管理システム）
データベース管理システム（DBMS）は、ユーザーと未加工の保存データとのインターフェースとして使用されるツールです。管理者は DBMS を使用して、データベースに保存されているデータの表示、新しいデータの更新や挿入、クエリを実行してデータを取得できます。管理者は、ストアド・プロシージャ、トリガー、テーブル、インデックス、その他のオブジェクトなどのデータベース項目を管理することもできます。DBMS は、多くの場合、データベースを構築し、後で管理するために使用されます。
DBMS の例としては、MySQL があります。MySQL はリレーショナル・データベースであるため、管理者は DBMS を使用してデータベース・オブジェクトの表示、テーブルの作成、データのクエリを行います。アプリケーションは DBMS を使用して、データのクエリやデータベースへのデータの追加を行います。MySQL はリレーショナル・データベースであるため、データは各列に制約のあるテーブルに格納され、格納されるデータ・タイプを制御します。
DBMS のもう 1 つの例が、MongoDB です。MongoDB は、非構造化データを保存する NoSQL オープンソースのデータベースです。データはドキュメントに格納され、管理者はドキュメント内の任意の数とタイプの項目を保存できます。管理者は、MongoDB DBMS を使用してデータベースの構造を管理し、アプリケーションはそれを使用してデータのクエリと追加を行います。
データの抽象化
データの抽象化は、アプリケーション内の論理関数で、未加工データをフロントエンドから分離します。簡単にいえば、データ・レイヤーはデータベースへの接続を処理し、フロントエンドからクエリを実行します。データの抽象化により、フロントエンド・アプリケーションは、データの格納場所に関係なくデータをクエリできます。開発者は、コードの大部分をリファクタリングすることなく、バックエンド・データベースを入れ替え、新しいデータベース・エンジンに接続して作業することができます。
例えば、MongoDB を開発段階で使用すると、処理が必要なデータの種類が判断できるとします。その後、本番運用環境で MySQL を使用します。データの抽象化レイヤーは、フロントエンドのコードベースに影響を与えることなく、MongoDB と MySQL の両方からデータベースへの接続とクエリを処理します。ユーザーはデータベース・エンジンの変更に気付いていませんが、必要な情報を取得できます。
データ抽象化のレベル
データの抽象化とは、データ管理のさまざまな側面を扱う包括的な用語です。開発者がアプリケーションを作成し、管理者と連携する場合、抽象化には、物理、論理、ビューの 3 つのレベルがあります。これらのレベルについて簡単に説明します。
- 物理的／内部レベル：このレベルには、サーバーのネットワーク情報やサーバーの場所など、データベースを格納するインフラが含まれます。例えば、物理コンポーネントは、中レベルの CPU とメモリ・リソースを備えたクラウド VM です。
- 論理的／概念的レベル：論理層は、物理層への接続に使用されるコードです。接続、クエリ、エラー処理のためのロジックが含まれています。論理レイヤーには、入力要素に応じて複数のデータベースに接続するためのコードが含まれる場合があります。
- 表示／外部レベル：フロントエンド・アプリケーションにより、ユーザーはデータを表示できます。このレベルの抽象化は、未加工データ・ストレージの場所から最も遠いものですが、データをフォーマットしてビューアーに提示し、有用なものにします。
多層データベース・アーキテクチャ
抽象層は、アプリケーションに埋め込まれた論理層ですが、物理的に異なるリソースに配置することもできます。多層抽象化の目的は、他の層に影響を与えずに単一の層をスケーリングすることを容易にすることです。多層アーキテクチャは、「n 層アーキテクチャ」とも呼ばれます。管理者は、アプリケーション内の各コンポーネントに対して複数の層を選択できます。
多層アーキテクチャには、プレゼンテーション、データ、アプリケーションの 3 つの層があります。これらの層の概要を以下に示します。
- データ層：この層はデータを保存し、データベース・エンジンを実行します。専用のベアボーン・サーバーや、仮想マシン上に配置できます。データベースは、ユースケースのシナリオに応じて、複雑なデータ・パイプラインを持つデータ・ウェアハウス内のクラスタでも動作します。
- アプリケーション層：この層は、アプリケーションを処理します。例えば、フロントエンドがカスタム Web アプリケーションである場合、Web サーバーはアプリケーション・ファイルを保存して実行します。ユーザーは、このサーバーに接続してアプリケーションを実行します。
- プレゼンテーション層：プレゼンテーション層は、似ているように聞こえても、アプリケーション層とは異なります。アプリケーション層にはコードベースとアプリケーション・ロジックがあり、プレゼンテーション層はユーザーが見るものです。Web アプリケーションでは、プレゼンテーション層は、アプリケーション・コードをフォーマットしてユーザーに表示するために使用される CSS と HTML です。
データ抽象化のメリット
データ・レイヤーをフロントエンド・アプリケーションから分離することで、リソースをきめ細かく拡張できます。データ・レイヤーの変更もフロントエンドに影響しないため、他のデータベース・エンジンを使用したり、データ層が場所を変更したりした場合に、データの抽象化によってコードのリファクタリングが制限されます。
例えば、オンプレミスの場所からデータベースをクラウドに移動することを決めたとします。データ・レイヤーの変更のみが必要で、フロントエンドのアプリケーション・コードの変更は必要ありません。管理者は、必要でなければアプリケーション・レイヤーのリソースを拡張することなく、データ・レイヤーのリソースを拡張できます。
まとめ
エンタープライズ・アプリケーションでは、DBMS に接続するためのデータの抽象化レイヤーを使用することで、スケールアップやスケールダウンが可能です。また、コードベースに多くのコード変更を加えることなく、アーキテクチャ内のデータ層のアーキテクチャを変更することもできます。複数のデータベース・エンジンを使用したり、データベースを新しい場所に移動しても、それほどオーバーヘッドになりません。
データの抽象化アーキテクチャを計画する際には、統合ブロック／ファイル・ストレージのためのピュア・ストレージの FlashArray をご覧ください。クラウドのストレージについては、ピュア・ストレージのクラウド・ブロック・ストレージをご覧ください。
