データベースアーキテクチャとは何ですか？

最新のアプリケーションを設計する際には、データを格納するだけでなく、必要に応じてデータを効率的に変換および抽出するためにも、データベースがほぼ不可欠になります。当初より、データベースアーキテクチャとデータベースマネージメントシステムは、従来の硬直的なシステムから、今日のデジタル化された世界に適した、より現代的な水平方向にスケーラブルなシステムへと進化してきました。

目次

• データベースアーキテクチャとは何ですか？
• データベースアーキテクチャの進化
• 基本的なデータベースシステムアーキテクチャ（コンポーネント）
• データベースモデルの種類
• MongoDB Atlas のデータベースアーキテクチャ
• よくある質問

データベースアーキテクチャとは何ですか？

「データベースアーキテクチャ」という用語は、データベースシステムの構造的な設計と方法論を指し、これが データベースマネジメントシステム（DBMS）の中核を形成しています。このアーキテクチャは、データがどのように保存、整理、抽出されるかを決定し、効果的かつ効率的なデータマネジメントにおいて重要な役割を果たします。

DBMS アーキテクチャを設計する際の最初のステップは、使用するデータベースのタイプを決定することです。データベースは、集中型または分散型にすることができます。

集中型データベースは、通常、サーバーまたはコンピューター上の単一のロケーションに保存および管理されます。ユーザーは、ローカルエリアネットワーク（LAN）やワイドエリアネットワーク（WAN）などのネットワークを介してデータベースにアクセスします。

対照的に、分散データベースや分散型データベースは、複数の物理的な場所（ノード）に保存されたデータで構成されており、通常は異なるシステムやサーバーによって管理されます。各ノードまたはサイトは独立して動作しますが、通信チャネルを介して相互接続されており、データの整合性を確保し、分散操作を可能にしています。

使用するデータベースのタイプを決めたら、使用するアーキテクチャのタイプを決定できます。データベースのアーキテクチャは、組織のニーズ、管理するデータの種類、データベースとやり取りする特定のアプリケーションによって大幅に異なります。

データベースマネジメントシステム

データベースマネジメントシステムは、ユーザーとデータベースの間の仲介役として機能し、データに容易にアクセスでき、一貫して整理され、安全に維持されることを保証します。DBMS の有効性はその根底にあるアーキテクチャにかかっており、堅牢でスケーラブルな必要があり、効率で多彩なデータ関連タスクを扱えることが求められます。

DBMS の主な機能は次のとおりです。

• CRUD 操作（作成、読み取り、更新、削除）：これらは、データを効率的に操作および管理するための基本的な操作です。
• データのセキュリティ：DBMS は、不正アクセスを防止し、暗号化とバックアップの戦略を実装することで、データの機密性、整合性、可用性を確保する必要があります。
• アクセス制御：堅牢な DBMS は、ユーザー認証、権限やロールといったアクセス制御メカニズムの実装、監視やコンプライアンスのためのユーザーアクティビティの追跡を行うことで、データへのアクセスや変更を誰に許可するかを制御するメカニズムを提供します。
• データベース全体のマネジメント：DBMS はデータ整合性、同時実行制御、バックアップおよびリカバリを確保する必要があります。

データベースアーキテクチャの進化

中小企業の日常的なトランザクションを管理する単純な構造から、大企業においてより多くの非構造化データやリアルタイムデータを取り扱う複雑なアーキテクチャまで、データベースアーキテクチャの範囲は幅広く多様であり、時間の経過とともに急速に進化してきました。

これは1950年代にはすでにフラットファイルシステムから始まっており、単純な取得のためにデータはプレーンテキストまたはバイナリファイルとして保存されていました。異なるエンティティ間に確立された関係がなかったため、クエリの実行がやや困難でした。

これに対応するため、1960年代後半には階層型データベースとネットワークデータベースが登場しました。これらのデータベースによって、親子関係と多対多の関係が導入されました。しかし、固定されたスキーマと複雑なナビゲーション（ツリー）のため、データをクエリすることは依然として容易ではありませんでした。

次に登場したのは、データの正規形、つまり第1正規形、第2正規形、第3正規形を導入したリレーショナルデータベースです。これにより、データが正しく分離され、構造化されることが保証されました。これらのシステムは、その信頼性と整合性により、1970年代と1980年代のエンタープライズシステムを支配していました。

企業のデジタル化が進むにつれ、過去のデータの分析と分析プロセシングの必要性が生じ、従来のデータベースではオンライン分析処理（OLAP）とデータウェアハウジングが提供されました。これがビジネスインテリジェンスとレポート作成に寄与しました。

ソーシャルメディアや Web ユーザーの増加に伴い、従来のリレーショナルデータベースでは対応しきれない、膨大なデータ（ビッグデータ）の保存と処理において、より高い柔軟性が求められるようになりました。

これにより、2000年代に最新の NoSQL データベースが台頭しました。これらのデータベースは、水平スケーラビリティを導入し、非構造化データ/半構造化データの柔軟なストレージを可能にしました。

データのユースケースの増加、リアルタイムおよびストリーミングデータへの対応、そしてデータベースの使用方法に革命をもたらしたクラウドネイティブおよびサーバーレスデータベースにより、データベースアーキテクチャのさらなる強化が不可避となりました。これらのデータベースは、単なる CRUD 操作の実行から、データレイヤー自体でのデータの変換および分析へと進化しています。

その他のトレンドとしては、ベクトル検索、AI/ML統合、拡張クエリと取得を実行できる AI 最適化データベースのサポートが挙げられます。

基本的なデータベースシステムアーキテクチャ（コンポーネント）

SQL または NoSQL を問わず、あらゆる種類のデータベースアーキテクチャの4つの基本コンポーネントには、ユーザー (Web ユーザー、アプリケーション、ビジネスアナリスト、データベース管理者)、クエリプロセッサ、ストレージマネージャー、物理データベース自体が含まれます。クエリプロセッサ、ストレージマネージャー、およびインデックスの作成、トランザクションマネジメント、同時実行制御、ログ記録などの他のサブシステムが、データベースマネジメントシステムを構成します。

ユーザーには、Web/インターネットユーザー、データベースからデータを抽出したい開発者、統計情報を取得しようとするビジネスアナリスト、またはログとアクセス制御を監視するデータベース管理者が該当します。

クエリプロセッサは、次の機能を実行します。

• パースとクエリの解釈：クエリを内部形式に変換し、クエリの構文にエラーがないか確認し、クエリ言語を解釈して実行のために加工します。
• クエリの最適化と実行：リソースの使用状況と時間を考慮に入れ、クエリに対して最適な実行プラン（戦略）を生成します。
• インデックスの作成：クエリのパフォーマンスを向上させるために必要な場合はインデックスを使用します。

ストレージマネージャーは、次のタスクを実行します。

• バッファマネージャー：バッファプールを管理し、必要なデータのみをメモリに保持して高速アクセスを確保し、ディスク容量と I/O 操作のバランスを調整します。
• トランザクションマネージャー：並行処理に対応し、障害が発生した場合の復旧メカニズムを実装します。
• ファイルマネージャー：物理データベースデバイス上のデータの格納と取得を管理し、インデックスを作成および保守し、スペースを割り当てまたは割り当て解除し、データを圧縮してパフォーマンスを向上させ、ストレージ容量を節約します。
• 承認および統合マネージャー：承認されたユーザーのみがデータベースの特定のセクションにアクセスできるようにし、全体にわたってデータの整合性を維持します。

物理ストレージは、実際のデータベースが常駐するレイヤーであり、データ、データとクエリに関する重要な統計、実行プラン、ログ、インデックスが保存されます。

データベース設計のプロセスは、コンセプトから実装まで、一連の綿密なステップで構成されます。

• 要件に従ってデータベース構造を定義し、エンティティを特定します。
• データのニーズと、埋め込みと参照のどちらを使用するかを理解することで、さまざまなエンティティ間の関係を決定します（リレーショナルデータベースの場合は、第1正規形、第2正規形、または第3正規形を使用します）。
• コレクション（テーブル）を設計し、プライマリキー（リレーショナルデータベースにのみ適用可能）を指定します。MongoDB などの NoSQL データベースは、プライマリキーが指定されていない場合、自動的に生成します。
• インデックスと制約を定義します。
• 垂直（リレーショナル）および水平（NoSQL）の拡張を計画します。
• スキーマをテストしてモニターします。

ビジネス要件が変化するにつれて、アプリケーションのコードや既存のスキーマを大幅に編集することなく、その変化に対応できるようデータベースのスキーマも進化させる必要があることに注意してください。そのため、柔軟で進化するスキーマを備えた MongoDB のようなデータベースの方が、はるかに適した選択肢です。

データベースモデルの種類

データベースアーキテクチャの基本的な側面の1つは、データベースシステム内でデータがどのように整理、保存、アクセス、抽出されるかです。

大まかに言えば、データベースアーキテクチャモデルのタイプは次の2つに分裂されます。

1. 論理：論理アーキテクチャでは、データの抽象的な表現に焦点を当て、データ間の構造と関係を重視します。たとえば、ドキュメントモデル、階層モデル、オブジェクト指向モデルがあります。
2. 物理：物理アーキテクチャは、システムをインフラストラクチャ全体に物理的にデプロイまたはスケーリングする方法を定義します。

このセクションでは、物理アーキテクチャや階層アーキテクチャ、よりモダンな DBMS アーキテクチャモデルについて理解します。

最も基本的なアーキテクチャはクライアント・サーバーアーキテクチャであり、1層、2層、3層のアーキテクチャが含まれます。クライアント・サーバーアーキテクチャでは、サーバー（バックエンドまたはデータベース）にサービスをリクエストするクライアント（エンドユーザーまたはアプリケーション）が存在します。次に、サーバーがリクエストを加工し、適切な応答を返します。

1層アーキテクチャ

1層アーキテクチャでは、データベース、ユーザーインターフェース、アプリケーションロジックがすべて同じマシン（ローカルマシン）または単一のサーバー自体に配置されます。通常、シンプルさとコスト効率が優先される小規模なアプリケーションに使用されます。ネットワーク遅延が発生しないため、この種類の階層アーキテクチャは一般にデータにアクセスする高速な方法です。

2層アーキテクチャ

2層アーキテクチャでは、1つ以上のクライアントがデータベースサーバーに直接接続します。たとえば、Microsoft Access データベースに接続する社内カスタマー関係マネジメント（CRM）のようなオンプレミスのデータベースサーバーでホストされている単一のデータベースにデスクトップアプリケーションが接続する場合です。

3層アーキテクチャ/ N 層アーキテクチャ

ほとんどの最新の Web アプリケーションは3層アーキテクチャを使用しています。3層アーキテクチャでは、クライアントがバックエンドアプリケーションサーバーに接続し、サーバーがデータベースに接続します。アプリケーションは3つ以上のレイヤー（プレゼンテーション層、ビジネスアプリケーション層、データ層など）に分裂されており、責任の分離が作成されています。このアプローチを使用すると、セキュリティ、スケーラビリティ、迅速な展開が確実になります。

• セキュリティ：データベース接続を単一のバックエンドに対して開いたままにすると、ハッキングのリスクが軽減されます。

• スケーラビリティ：各レイヤーが独立して動作するため、アプリケーションの一部を拡張しやすくなります。

• より迅速な展開：複数の階層があることで、関心の分離が容易になり、より優れた継続的デリバリープロセスなど、クラウドネイティブのベストプラクティスに従いやすくなります。

分散されたアーキテクチャ

最新のアプリケーションに最適な分散データベースアーキテクチャは、レプリケーションやシャーディングなどのさまざまなメソッドを使用してデータを複数のノードに分散させ、高可用性とフォールトトレランスを確保します。

クラウドベースのアーキテクチャ

分散アーキテクチャをさらに強化するのがクラウドベースのアーキテクチャです。このアーキテクチャでは、データベースがクラウド経由で提供されるサービスとして機能し、柔軟性とスケーラビリティが向上し、コスト効率も優れています。MongoDB Atlas は、クラウドベースのデータプラットフォームの好例です。

フェデレーティッドアーキテクチャ

フェデレーティッドアーキテクチャでは、複数の自律型データベースをシングルビューに統合できるため、多様な複数のソースのデータを 1 つのデータベースに統合できます。MongoDB Atlas は Data Federation を提供します。これを使用すると、複数の Atlas データベースにアクセスしてクエリを実行し、その結果を目的のプラットフォームに取り込むことができます。

MongoDB Atlas のデータベースアーキテクチャ

MongoDB は2009年にリリースされ、クラウドや AIといった最新技術と連携して機能する現代的な分散されたアプリケーションの先駆者となりました。MongoDB はドキュメントモデル上に構築されており、リレーショナルデータベースと NoSQL データベースの長所を備えています。

MongoDB では、リレーショナルデータベースのテーブル内の行の代わりに、データの取得やクエリを容易にする柔軟なドキュメントを使用します。MongoDB では、一緒にアクセスされるデータは一緒に保存されます。MongoDB データベースの主な機能は次のとおりです。

• 柔軟なスキーマ：MongoDB は正規化ルールに従いません。関連するすべてのデータは柔軟なドキュメントとしてまとめて保存され、そのスキーマはプロジェクトのどの時点でも変更できるため、データベーススキーマ全体を再設計することなく、新しいフィールドの追加、変更、または削除（制約および制限付き）が可能になります。
• 関係：データの1対1の関係、1対多の関係、複数対複数の関係をサポートしています。
• JSON データ：JavaScript の普及に伴い、データはフロントエンドから JSON 形式で送信されるようになりました。MongoDB はデータを JSON スタイルの形式で保存するため、受信した形式と同じ形式でデータを簡単かつ容易に使用および保存できます。
• 一意の識別子： _id フィールド (ObjectID) は特定のドキュメントを一意に識別するために使用され、MongoDB のプライマリキーのように機能します。ユーザーが指定しない場合、自動的に生成されます。

MongoDB の分散アーキテクチャにより、スケーラブルで耐障害性に優れ、ミッションクリティカルなシステムを実現できます。さらに、MongoDB が提供するサービスとしてのソフトウェアである MongoDB Atlas は、リアルタイムアナリティクスデータワークロード、ストリーム処理、ベクトル検索などの追加サービスをサポートします。

今日では、最新の分散アプリケーションのほぼすべてが3層アーキテクチャに従っており、MongoDB はそれに自然に適合します。フルテクノロジースタック（MEAN スタック、MERN スタック、FARM スタックなど）は、MongoDB をバックエンドデータベースとして使用しています。

詳細なアーキテクチャについては、MongoDB アーキテクチャガイドを参照してください。

MongoDB システム研究グループの取り組みをご覧ください。