データベースミドルウェアの紹介

データベース ミドルウェアは、データベースとアプリケーションを接続してデータベース管理を簡素化し、パフォーマンスとスケーラビリティを向上させ、追加の機能とサービスを提供するソフトウェア層です。分散システムや大規模アプリケーションでは、データベースミドルウェアが重要な役割を果たします。

データベースミドルウェアとは何ですか?

データベース ミドルウェアは、データベース システムとアプリケーションの間のソフトウェア層です。これは抽象化レイヤーとして機能し、基礎となるデータベースの詳細を保護し、アプリケーションへのよりシンプルなインターフェイスを提供します。データベース ミドルウェアの主な目標は、より高いパフォーマンス、可用性、拡張性を提供し、データベース管理を簡素化することです。
典型的なデータベース ミドルウェア設計ソリューションには、プロキシ、スマート クライアント、ユニット化アーキテクチャの 3 つがあります。

スマートクライアントモード

独立した論理層を通じてデータのシャーディングとルーティングのルールを確立して単一データベースの事前管理を実現し、アプリケーションが複数の単一データベースに接続して同時実行性とストレージ機能を拡張できるようにします。アプリケーション システムの一部として、ビジネスに深く侵入します。この種のクライアント コンポーネントの代表的な製品は Sharding-JDBC です。

アドバンテージ

実装が簡単。ほとんどのデータベース ベンダーは、さまざまな言語に対応するデータベース ドライバー ドライバーを提供しています。たとえば、mysql では、Java 言語には mysql-connector-java ドライバーが、Python には mysql-connector-python ドライバーが提供されています。クライアント通信プロトコルはすでにドライバー レベルです。それ。したがって、スマート クライアント モードのミドルウェアは通常、これに基づいてカプセル化するだけで済みます。

自然な分散化。スマート クライアント方式は、SDK の形式でアプリケーションによって直接導入され、アプリケーションは別のノードにデプロイされるため、データベースに直接接続され、中間のプロキシ層は必要ありません。したがって、ネットワークリソースを除いて、他のリソースの競合は基本的になく、高可用性の問題を考慮する必要はありません。すべてのアプリケーション ノードがダウンしていない限り、データベースにアクセスできます。

欠点がある

通常、特定の言語のみがサポートされます。たとえば、tddl、zebra、sharding-jdbc はすべて Java 言語を使用して開発されているため、他の言語を使用しているユーザーはこれらのミドルウェアを使用できません。他の言語を使用する場合は、多言語クライアントを開発する必要があります。
バージョンアップが難しい。アプリケーションはデータ ソース プロキシを使用して、jar パッケージへの依存関係を導入するため、複数のアプリケーションが特定のバージョンの jar パッケージに依存する場合、このバージョンにバグがあると、すべてのアプリケーションをアップグレードする必要があります。データベース プロキシのアップグレードは、サービスが個別にデプロイされるため比較的簡単で、プロキシ サーバーがアップグレードされる限り、プロキシに接続されているすべてのアプリケーションも自然にアップ​​グレードされます。

プロキシモード

データ ルールとルーティング ルールを独立したミドルウェアの形式で管理し、独立したプロセスとして存在し、ビジネス アプリケーション層や単一のデータベースから分離されているため、アプリケーションへの影響が軽減されます。エージェント ミドルウェアの開発により、いくつかの分散トランザクション処理機能も派生します。このミドルウェアの代表的な製品は MyCat です。

アドバンテージ

多言語サポート。php、java、その他の言語を使用してもサポートされます。mysql データベースを例にとると、プロキシ自体が mysql 通信プロトコルを実装している場合、それを mysql サーバーとみなすことができます。公式の mysql チームは、Java 言語の mysql-connector-java、Python 言語の mysql-connector-python など、言語ごとに異なるクライアント ドライバーを提供しています。したがって、さまざまな言語の開発者は、mysql によって公式に提供される対応するドライバーを使用して、このプロキシ サーバーとの通信を確立できます。
ビジネス開発の学生に対して透明性を保ちます。プロキシは mysql サーバーとして使用できるため、理論的には、ビジネスの学生はアクセスを完了するためにあまり多くのコードを変更する必要はありません。

欠点がある

実装は複雑です。プロキシは、プロキシされるデータベースのサーバー側に通信プロトコルを実装する必要があるため、実装が困難です。通常、プロキシ モードのデータベース ミドルウェアがいくつか見られますが、実際には、mysql など、特定の種類のデータベースのみをプロキシすることができます。複数のデータベース (sqlserver、PostgreSQL、Oracle) を同時にプロキシできるデータベース ミドルウェアはほとんどありません。
プロキシ自体は高可用性を確保する必要があります。アプリケーションは元々データベースに直接アクセスしていましたが、現在はプロキシにアクセスしています。これは、プロキシが高可用性を確保する必要があることを意味します。そうしないと、プロキシがハングアップし、データベースに正常にアクセスできなくなり、厄介なことになります。
テナントの隔離。プロキシの基盤となるデータベースにアクセスするアプリケーションが複数存在する可能性があり、プロキシ自体のメモリ、ネットワーク、CPU などのリソース競合が必然的に発生します。プロキシには分離機能が必要です。

ユニットアーキテクチャ

ユニット化アーキテクチャとは、業務アプリケーションシステムを完全に再構築したもので、アプリケーションシステムを複数のインスタンスに分割し、それぞれのインスタンスが一定範囲のデータを管理できる独立した単一のデータベースを構成します。たとえば、食品配達システムの場合、都市ごとに独立したアプリケーション インスタンスを構築して、独自のデータを管理できます。都市をまたぐビジネスが発生した場合は、ユーザー情報を移行して発注します。

アドバンテージ

柔軟な拡張性。ユニット化アーキテクチャでは、統一されたセグメンテーションルールによりアプリケーション層とデータ層を三次元的に分割し、伸縮自在な拡張・縮小シナリオでも、多拠点・多拠点のシナリオでも、論理的な「スライス」の数を自由に分割できます。データセンターの容量に応じて。
ネットワークの消費時間が短くなり、リンクの安定性が高くなります。ユニット化されたアーキテクチャでは、「ユニット」を使用して、「ユニット」内の論理呼び出しとデータ アクセスの閉ループを形成します。特定のシナリオでの少数の呼び出しのみがユニット間でアクセスされます。このようにして、ほとんどのリクエストはリージョン内で返されます。これにより、ユニットの効率が大幅に向上し、アクセス時間が短縮され、リージョン間のアクセス リンクの輻輳によるサービスの中断が回避され、リンクの安定性が向上します。重要なのは、本装置による大きな障害分離効果であり、リンクの可観測性も大幅に向上しました。つまり、前述の地域間アクセスによる問題がリンクのアクセスレベルから遮断されています。

欠点がある

複雑なスケジュール管理。まず、統一されたルールセンターを決定して、統一されたルールを保存および発行する必要があります。実装方法としては、ユニット化されたルール サービスを単独で実装することも、登録構成センターを使用することもできます。また、この 2 つを共存させることもできます。ユニット化ルールを有効にした後に変更するのは難しいため、ユニット化スライスの分割次元を選択するときは注意する必要があります。
改修費用は高額です。ユニット化には、グローバルな視点でインフラ変革を考える必要があり、構築するということは、現在あるいは将来的に、より多くの機械を購入し、より多くのコンピュータ室を建設し、より多くのサポートのためのフレームワークプラットフォームを構築する必要があることを意味します。アーキテクチャのアップグレード プロセス: このような問題には、より多くの資金、人員、時間が必要です。
リスクは高いです。ユニット化の変革には多くの関係者が関与し、実装には長い時間がかかり、ビジネスに大きな影響を及ぼします。たとえば、アーキテクトはアーキテクチャを再設計する必要があり、研究開発担当者はユニット化に適応して開発する必要があり、運用保守担当者は購入して導入する必要があります。すべてのビジネスに戻るなど、いずれかのビジネスに問題があると遅延が発生したり、隠れた危険が生じたりする可能性があります。

要約する

方法	アドバンテージ	欠点がある
プロキシモード	1. 多言語サポート 2. ビジネス開発への透過性	1. 複雑な実装 2. プロキシは高可用性を確保する必要がある 3. テナントの分離を考慮する必要がある
スマートクライアントモード	1. 実装が簡単で使いやすい 2. 自然に分散化されている	1. 通常は特定の言語しかサポートしていない 2. バージョンアップが難しい
ユニット化	1. 柔軟な拡張 2. 低いネットワーク消費量と高いリンク安定性	1. 複雑な管理とスケジュールが必要 2. 高い変革コスト 3. 高いリスク