mysqlでデータセグメンテーションを実装する方法-mysql チュートリアル-php.cn

データセグメンテーションを実装するための Mysql メソッド: 1. データの垂直セグメンテーションを使用する; 2. データの水平セグメンテーションを使用する; 3. MySQL Proxy を使用してデータのセグメンテーションと統合を実現する; 4. Amoeba を使用してデータセグメンテーションを実装する; 5. データのセグメンテーションを実装するために、Amoeba を使用する。 5. HiveDB を使用してデータのセグメント化と統合を実現します。

mysqlでデータセグメンテーションを実装する方法

その他の関連する無料学習の推奨事項: mysql チュートリアル#(ビデオ)
#Mysql によるデータセグメンテーションの実装方法:

データセグメンテーションとは

#簡単に言うとつまり、同じデータベースに格納されているデータを、特定の条件下で複数のデータベース（ホスト）に分散させ、単一のデバイスの負荷を分散する効果を実現することを意味します。データスライスにより、システム全体の可用性も向上します。これは、単一のデバイスがクラッシュした後は、すべてのデータではなく、データ全体の特定の部分のみが使用不能になるためです。データシャーディング (シャーディング) は、シャーディングルールの種類に応じて 2 つのシャーディングモードに分類できます。 1 つは、異なるテーブル (またはスキーマ) に従って異なるデータベース (ホスト) に分割することです。この分割は、データの垂直 (垂直) 分割と呼ぶことができます。もう 1 つは、テーブル内のデータに従ってデータを分割することです。論理的な関係において、同じテーブル内のデータを一定の条件に従って複数のデータベース（ホスト）に分割するこのような分割をデータの水平（水平）セグメンテーションと呼びます。

垂直セグメンテーションの最大の特徴は、ルールがシンプルで導入が容易であることであり、特に各事業間の結合が非常に低く、相互影響が小さく、ビジネスが複雑化しているシステムに適しています。ロジックは非常に明確です。この種のシステムでは、さまざまなビジネスモジュールで使用されるテーブルをさまざまなデータベースに簡単に分割できます。異なるテーブルに従って分割すると、アプリケーションへの影響が少なくなり、分割ルールがより単純かつ明確になります。

水平方向のセグメンテーションは、垂直方向のセグメンテーションよりも少し複雑です。同じテーブル内の異なるデータを異なるデータベースに分割する必要があるため、アプリケーションにとっては、テーブル名に基づいて分割するよりも分割ルール自体が複雑になり、その後のデータ保守もより複雑になります。

特定の (または一部の) テーブルに特に大量のデータとアクセスがあり、独立したデバイス上で垂直方向にスライスした後でもパフォーマンス要件を満たせない場合は、垂直方向にシャーディングする必要があります。最初に垂直セグメンテーション、次に水平セグメンテーションを行うことで、この非常に大きなテーブルのパフォーマンスの問題を解決できます。

以下は、垂直、水平、結合セグメンテーションの 3 つのデータセグメンテーション方法とセグメント化されたデータの統合のアーキテクチャ実装の対応する分析です。

データの垂直方向のセグメント化

まず、データの垂直方向のセグメント化がどのように行われるかを見てみましょう。データの垂直セグメント化は、垂直セグメント化とも呼ばれます。データベースは多数の「データブロック」(テーブル) で 1 つずつ構成されていると考え、これらの「データブロック」を垂直に切り取り、複数のデータベースホストに分散します。このようなスライス方法は、垂直（縦方向）データスライスです。適切に設計されたアーキテクチャを持つアプリケーションシステムの全体的な機能は、多くの機能モジュールで構成されている必要があり、各機能モジュールが必要とするデータはデータベース内の 1 つ以上のテーブルに対応します。アーキテクチャ設計では、各機能モジュール間の相互作用ポイントがより統合され、少なくなるほど、システムの結合が低くなり、システムの各モジュールの保守性と拡張性が向上します。このようなシステムにより、データの垂直分割が容易になります。

機能モジュールが明確になり、結合度が低ければ低いほど、垂直方向のデータセグメンテーションのルールを定義することが容易になります。データは機能モジュールに基づいてセグメント化できます。異なる機能モジュールのデータは異なるデータベースホストに保存されます。データベース間の結合は簡単に回避でき、システムアーキテクチャも非常に明確です。

もちろん、すべての機能モジュールが使用するテーブルを完全に独立させるシステムを実現することは困難であり、お互いのテーブルにまったくアクセスする必要がないか、テーブルを結合する必要はありません。 2 つのモジュールのうち。この場合、実際のアプリケーションシナリオに基づいて評価とトレードオフを行う必要があります。アプリケーションに対応して、結合する必要があるテーブルの関連モジュールを同じデータベースに保存するか、アプリケーションにさらに多くのことを実行させるか (モジュールインターフェイスを通じて完全に異なるデータベースからデータを取得し、その後で結合操作を完了する) を決定します。プログラムを

一般的に言えば、負荷が比較的軽く、テーブルの関連付けが非常に頻繁に行われるシステムの場合、データベースはアプリケーションの作業を軽減するために、いくつかの関連モジュールをマージする可能性があります。解決。

もちろん、データベースの譲歩を通じて、複数のモジュールがデータソースを一元的に共有できるようにすることは、実際には各モジュールアーキテクチャの結合の増大の開発を間接的に黙認することになり、将来のアーキテクチャを悪化させる可能性があります。特に、開発の特定の段階に達し、データベースがこれらのテーブルによってもたらされる圧力に耐えられず、再びセグメンテーションに直面しなければならないことが判明した場合、アーキテクチャ変更のコストは、セグメンテーションを使用した最初のアーキテクチャ設計よりもはるかに大きくなる可能性があります。

したがって、データベースが垂直方向にセグメント化されている場合、それをどのようにセグメント化し、どの範囲までセグメント化するかが難しい問題になります。実際のアプリケーションシナリオにおけるあらゆる側面のコストと利点のバランスを取ることによってのみ、本当に適切な分割計画を分析することができます。

たとえば、この記事で使用されているサンプルシステムのサンプルデータベースでは、簡単に分析してから、垂直分割を実行するための単純なセグメンテーションルールを設計します。

システム機能は基本的に、ユーザー、グループメッセージ、フォトアルバム、イベントの 4 つの機能モジュールに分割できます。これらは次の表に対応します。

ユーザーモジュールテーブル: user,user_profile,user_group,user_photo_album
グループディスカッションテーブル: groups,group_message,group_message_content,top_message
アルバム関連テーブル: photo,photo_album 、 photo_album_relation,photo_comment
イベント情報テーブル:event

一見すると、どのモジュールも他のモジュールから独立して存在することはできません。モジュール間の関係を分離することは不可能ですか?

もちろんそうではありません。もう少し詳しく分析すると、各モジュールで使用されるテーブルは相互に関連していますが、その関係は比較的明確かつ単純であることがわかります。

グループディスカッションモジュールとユーザーモジュールは、主にユーザーまたはグループの関係を通じて関連付けられます。一般的にはユーザーのIDまたはニックネームとグループのIDで関連付けを行いますが、モジュール間のインターフェースを介して実装してもそれほど問題はありません。

フォトアルバムモジュールには、ユーザーモジュールとのユーザー関連付けのみがあります。これら 2 つのモジュール間の関連付けは、基本的にユーザー ID に関連付けられたコンテンツのみであり、シンプルかつ明確であり、インターフェイスも明確です。

イベントモジュールは各モジュールに関連付けることができますが、各モジュール内のオブジェクトの ID 情報のみに焦点を当てているため、分割も容易です。

したがって、最初のステップは、機能モジュールに関連するテーブルに従ってデータベースを垂直に分割することです。各モジュールに含まれるテーブルは、別個のデータベースに分割されます。モジュール間のテーブルの関連付けは、アプリケーション内にあります。システム側はインターフェースを介して処理されます。データの垂直分割の模式図 (図 1) に示すように、

このような垂直分割の後、これまで 1 つのデータベースでしか提供できなかったサービスが 4 つのデータベースに分割されてサービスが提供されるようになり、サービス容量が自然に増加しました。数倍に増えた。

垂直分割の利点:

データベースの分割はシンプルかつ明確であり、分割ルールも明確です;
アプリケーションモジュールは明確で統合が簡単です。
データの保守は便利で、見つけやすいです。

垂直セグメンテーションの欠点:

一部のテーブルの関連付けはデータベースレベルでは完了できず、プログラム内で完了する必要があります;
非常に頻繁にアクセスされ、大量のデータが含まれるテーブルの場合は、依然としてパフォーマンスのボトルネックがあり、必ずしも要件を満たさない可能性があります。
トランザクション処理は比較的複雑です。
セグメンテーションが特定のレベルに達すると、スケーラビリティが制限されます。
#過度のセグメンテーションはシステムを複雑にしすぎてしまう可能性があります。維持するのが難しい。

垂直セグメンテーションで発生する可能性のあるデータのセグメンテーションとトランザクションの問題を考慮すると、データベースレベルでより良い解決策を見つけることは非常に困難です。実際のアプリケーションの場合、データベースの垂直分割はアプリケーションシステムのモジュールにほぼ対応しており、同じモジュールのデータソースは同じデータベースに格納されるため、モジュール内でのデータの関連付けの問題は解決できます。モジュール間では、必要なデータがサービスインターフェイスの形式でアプリケーションプログラムを通じて相互に提供されます。これにより、データベースに対する全体的な操作数は確かに増加しますが、システム全体のスケーラビリティとアーキテクチャのモジュール化の観点からは有益です。一部の操作の単一応答時間はわずかに増加する可能性がありますが、システム全体のパフォーマンスはある程度向上する可能性があります。拡張ボトルネックの問題は、次のセクションで紹介するデータ水平セグメンテーションアーキテクチャに依存することによってのみ解決できます。

データの水平方向のセグメンテーション

上のセクションではデータの垂直方向のセグメンテーションを分析して紹介しましたが、このセクションではデータの水平方向のセグメンテーションを分析します。データの垂直方向のセグメンテーションは基本的にテーブルまたはモジュールに従ってデータを分割することとして単純に理解できますが、水平方向のセグメンテーションは異なります。一般に、単純な水平シャーディングとは、アクセスが極めて軽微なテーブルを、ある分野の一定のルールに従って複数のテーブルに分散することが主であり、各テーブルにはデータの一部が含まれます。

簡単に言えば、データの水平セグメント化は、データ行に応じたセグメント化として理解できます。つまり、テーブル内の一部の行はデータベースにセグメント化され、他の行は他のデータベースにセグメント化されます。。もちろん、データの各行がどのデータベースに分割されたかを簡単に判断するには、分割は常に特定のルールに従って実行する必要があります。たとえば、数値型フィールドに基づく特定の数値に基づいてモジュロを取得します。ある時点の型フィールドの範囲、または文字型フィールドのハッシュ値。システム全体のコアテーブルのほとんどが特定のフィールドを介して関連付けられる場合、当然、使用できない非常に特殊な場合を除き、このフィールドが水平パーティション化に最適な選択肢になります。

一般的に言えば、現在非常に人気のある Web 2.0 Web サイトと同様に、基本的にほとんどのデータはメンバーユーザー情報を通じて関連付けることができます。おそらく、多くのコアテーブルはメンバー ID によるデータの水平セグメント化に非常に適しています。たとえば、フォーラムコミュニティディスカッションシステムはセグメント化が容易で、フォーラム番号に応じて水平方向にセグメント化できます。分割後は基本的にライブラリ間の相互作用はなくなります。

サンプルシステム内のすべてのデータがユーザーに関連付けられている場合、ユーザーに基づいて水平分割を実行でき、異なるユーザーのデータを異なるデータベースに分割できます。もちろん、唯一の違いは、ユーザーモジュールのグループテーブルがユーザーに直接関連していないため、グループをユーザーに基づいて水平に分割できないことです。この特殊なケースでは、テーブルを完全に分離して、独立したデータベースに配置できます。実はこのアプローチは、前節で紹介した「データの垂直分割」手法を利用しているとも言えますが、この垂直分割と水平分割を同時に利用する結合分割手法については、次回で詳しく紹介します。セクション。

したがって、サンプルデータベースの場合、ほとんどのテーブルはユーザー ID に基づいて水平方向に分割できます。さまざまなユーザーに関連するデータはセグメント化され、さまざまなデータベースに保存されます。たとえば、すべてのユーザー ID は 2 を法として取得され、2 つの異なるデータベースに保存されます。ユーザー ID に関連付けられた各テーブルは、次のように分割できます。このように、基本的にすべてのユーザー関連データは同じデータベース内にあり、相関関係が必要な場合でも実装が非常に簡単です。

水平セグメンテーション図 (図 2) を使用すると、水平セグメンテーションの関連情報をより直観的に表示できます。

水平セグメンテーションの利点:

#テーブルの関連付けは基本的にデータベース側で完了できます。

このセクションでは、垂直スライシングと水平スライシングの長所と短所を組み合わせて、アーキテクチャ全体をさらに改善し、システムのスケーラビリティを向上させます。

一般に、1 つ (またはいくつか) のフィールドを介してデータベース内のすべてのテーブルを関連付けるのは難しいため、データの水平方向のセグメント化だけではすべての問題を解決できません。垂直シャーディングでは問題の一部しか解決できず、負荷が非常に高いシステムでは、単一のテーブルですら単一のデータベースホストではその負荷に耐えることができません。「縦」と「横」の2つの分割方法を組み合わせて、それぞれのメリットを生かし、デメリットを回避する必要があります。

各アプリケーションシステムの負荷は段階的に増加します。パフォーマンスのボトルネックに遭遇し始めると、ほとんどのアーキテクトや DBA は、最初にデータを垂直分割することを選択します。これが最もコストが低いためです。これが最も適切です。この期間で最大の入出力比を追求しました。しかし、ビジネスが拡大し続け、システム負荷が増大し続けると、システムが一定期間安定した後、垂直分割されたデータベースクラスターが再び過負荷になり、パフォーマンスのボトルネックが発生する可能性があります。

現時点でどのように選択すればよいでしょうか?モジュールを再度さらに細分化する必要がありますか、それとも他の解決策を模索する必要がありますか?最初と同じようにモジュールを細分化し、データの垂直分割を実行し続けると、近い将来、現在直面しているのと同じ問題に遭遇する可能性があります。さらに、モジュールが改良され続けるにつれて、アプリケーションシステムのアーキテクチャはますます複雑になり、システム全体が制御不能になる可能性があります。

現時点では、直面している問題を解決するには、水平データセグメンテーションを利用する必要があります。さらに、水平データセグメンテーションを使用する場合、垂直データセグメンテーションの以前の結果を覆す必要はなく、代わりに、水平セグメンテーションの利点を利用して垂直セグメンテーションの欠点を回避し、ますます複雑になるデータセグメンテーションの問題を解決できます。システムの質問です。横分割のデメリット（ルールが統一しにくい）も、以前の縦分割によって解決され、横分割が容易になりました。

サンプルデータベースでは、当初はデータが垂直に分割されていたと想定していましたが、ビジネスが成長し続けるにつれてデータベースシステムにボトルネックが発生し、データベースクラスターのアーキテクチャを再構築することにしました。リファクタリングするにはどうすればよいですか?データの垂直分割は以前から行われており、モジュール構造は明確で明確であり、ビジネスの成長の勢いはますます高まっていることを考慮すると、たとえ今再びモジュールが分割されたとしても、それは長くは続かないでしょう。したがって、垂直セグメンテーションに基づいて水平セグメンテーションを実行することを選択しました。

垂直分割されたデータベースクラスター内の各データベースは機能モジュールを 1 つだけ持ち、各機能モジュール内のすべてのテーブルは基本的に特定のフィールドに関連付けられます。たとえば、すべてのユーザーモジュールはユーザー ID ごとに分割することができ、グループディスカッションモジュールはグループ ID ごとに分割することができ、フォトアルバムモジュールはアルバム ID ごとに分割することができ、データの期限を考慮した最終的なイベント通知情報テーブルが作成されます。 (最近のイベントセグメントの情報のみにアクセスします)、時間ごとに分割されています。

結合セグメンテーションは、セグメンテーション後のアーキテクチャ全体を示します。

実際、多くの大規模なアプリケーションシステムでは、垂直セグメンテーションと水平セグメンテーションは基本的に共存しており、交互に実行されることがよくあります。システムの拡張性を高めます。さまざまなアプリケーションシナリオに対処する場合は、これら 2 つのセグメント化方法の制限と利点も十分に考慮し、異なる期間 (負荷圧力) で異なる方法を使用する必要があります。

結合セグメンテーションの利点:

垂直セグメンテーションと水平セグメンテーションのそれぞれの利点を最大限に活用し、それぞれの欠点を回避できます。
#ジョイントセグメンテーションの欠点:

データベースシステムアーキテクチャはより複雑で、保守がより困難です。

##アプリケーションのアーキテクチャもより複雑です。
データのセグメント化と統合ソリューション
これまでの章を通じて、データベースによるデータのセグメント化により、パフォーマンスが大幅に向上することが明らかでした。システム、スケーラビリティ。ただし、データベース内のデータが垂直および/または水平セグメンテーション後に異なるデータベースホストに保存された後、アプリケーションシステムが直面する最大の問題は、これらのデータソースをどのようにより適切に統合するかということであり、これは多くの読者にとって大きな懸念事項となる可能性があります。一つの質問。このセクションの主な内容は、データのセグメンテーションとデータ統合の実現に役立つさまざまな全体的なソリューションを分析することです。

データ統合は、データベース自体に依存すると実現が困難です。MySQL には同様の問題を解決できる Federated Storage エンジンがありますが、実際のアプリケーションシナリオでそれをうまく使用するのは困難です。では、さまざまな MySQL ホストに分散しているこれらのデータソースを統合するにはどうすればよいでしょうか?

一般に、2 つのソリューションがあります:

各アプリケーションモジュールで必要な 1 つ (または複数) のデータソースを構成および管理する。各データベースと完全なデータに直接アクセスする。モジュール内の統合;

すべてのデータソースは中間プロキシ層を通じて均一に管理され、バックエンドデータベースクラスターはフロントエンドアプリケーションに対して透過的です。

おそらく、90% 以上の人は、これら 2 つのソリューションに直面した場合、特にシステムがより大規模で複雑になり続ける場合には、2 番目のソリューションを選択する傾向があるでしょう。確かに、これは非常に正しい選択であり、短期的に支払うコストは比較的大きくなるかもしれませんが、システム全体の拡張性には非常に役立ちます。

したがって、最初の解決策についてはあまり分析せず、2 番目のアイデアのいくつかの解決策の分析に焦点を当てましょう。

自社開発の中間プロキシ層

データベースの中間プロキシ層を介したデータソース統合のアーキテクチャの方向性を選択することを決定した後、多くの企業 (または企業)当社は、特定のアプリケーションシナリオに適合する独自のプロキシレイヤーアプリケーションを開発しました。

自社開発の中間プロキシ層は、自身のアプリケーションの特性に最大限に対応し、個別のニーズに最大限のカスタマイズを加え、変化に直面した場合にも柔軟に対応できます。これが独自のプロキシレイヤーを開発する最大の利点です。

もちろん、自分で開発してパーソナライズされたカスタマイズを最大限に楽しむことを選択すると、当然のことながら、初期の研究開発とその後の継続的なアップグレードと改善により多くのコストを投資する必要があり、自分の技術的限界が高くなる可能性があります。シンプルな Web アプリケーションの方が高いです。したがって、独自に開発することを決定する前に、より包括的な評価を行う必要があります。

自己開発では、自社のアプリケーションシステムにどのように適応し、独自のビジネスシナリオに対処するかを検討することが多いため、ここであまり分析するのは簡単ではありません。以下では主に、現在人気のあるいくつかのデータソース統合ソリューションを分析します。

MySQL Proxy を使用してデータのセグメント化と統合を実現する

MySQL Proxy は、MySQL によって公式に提供されているデータベースプロキシ層製品であり、MySQL Server と同様に GPL に基づいています。オープンソースライセンスに基づくオープンソース製品。それらの間の通信情報を監視、分析、送信するために使用できます。その柔軟性により最大限に使用することができ、現在の機能には主に接続ルーティング、クエリ分析、クエリのフィルタリングと変更、負荷分散、および基本的な HA メカニズムが含まれます。

実際には、MySQL Proxy 自体は上記の機能をすべて備えているわけではありませんが、上記の機能を実現するための基盤を提供します。これらの機能を実現するには、LUA スクリプトも自分で記述する必要があります。

MySQL プロキシは、実際にはクライアントリクエストと MySQL サーバーの間に接続プールを確立します。すべてのクライアントリクエストは MySQL Proxy に送信され、MySQL Proxy は対応する分析を実行して、それらが読み取り操作であるか書き込み操作であるかを判断し、対応する MySQL Server に配信します。マルチノードのスレーブクラスターの場合、負荷分散も実現できます。たとえば、MySQL Proxy の基本的なアーキテクチャ図 (図 4):

上記のアーキテクチャ図を通じて、実際のアプリケーションにおける MySQL Proxy の位置と、MySQL Proxy で実行できる基本的なことが明確にわかります。 MySQL Proxy の詳細な実装内容は、MySQL の公式ドキュメントで詳細と例が紹介されており、興味のある読者は MySQL の公式 Web サイトから無料で直接ダウンロードするか、オンラインで読むことができるため、ここでは詳しく説明しません。

Amoeba を使用したデータセグメンテーションの実現

Amoeba は、Java に基づいて開発されたオープンソースフレームワークで、分散データベースデータソース統合プロキシプログラムの解決に重点を置いています。 GPL3プロトコルに基づいています。現在、Amoeba には、図 5 に示すように、クエリルーティング、クエリフィルタリング、読み書き分離、ロードバランシング、HA メカニズムおよびその他の関連コンテンツがすでに実装されています。

Amoeba は主に次の問題を解決します:

データ分割後の複雑なデータソースの統合;
データ分割の提供ルールを削除し、データベースに対するデータセグメンテーションルールの影響を軽減します;
データベースとクライアント間の接続数を削減します;
分離読み取りおよび書き込みルーティング。

Amoeba が行っていることは、まさにデータのセグメント化を通じてデータベースのスケーラビリティを向上させるために必要なことであることがわかります。

Amoeba はプロキシ層の Proxy プログラムではなく、データベースプロキシ層の Proxy プログラムを開発するためのフレームワークであり、現在、Amoeba をベースにして開発された Proxy プログラムは Amoeba For MySQL と Amoeba For Aladin の 2 つがあります。

Amoeba For MySQL は MySQL データベースに特化したソリューションであり、フロントエンドアプリケーションが要求するプロトコルとバックエンドが接続するデータソースデータベースは MySQL である必要があります。どのクライアントアプリケーションでも、Amoeba For MySQL と MySQL データベースの間に違いはなく、MySQL プロトコルを使用するクライアントリクエストはすべて Amoeba For MySQL によって解析され、それに応じて処理されます。 Amoeba For は、Amoeba For MySQL のアーキテクチャ情報を教えてくれます (Amoeba 開発者ブログから):

Amoeba For Aladin は、より広範囲に適用可能で、より強力なプロキシプログラムです。異なるデータベースのデータソースに同時に接続してフロントエンドアプリケーションにサービスを提供できますが、受け入れられるのは MySQL プロトコルに準拠するクライアントアプリケーションのリクエストのみです。言い換えれば、フロントエンドアプリケーションが MySQL プロトコルを介して接続されている限り、Amoeba For Aladin は Query ステートメントを自動的に分析し、クエリデータソースが要求されたデータに基づいて、どの種類のデータベースのどの物理ホストであるかを自動的に識別します。 Query ステートメントの方が優れています。 Amoeba For Aladdin のアーキテクチャ図 (図 6) は、Amoeba For Aladdin のアーキテクチャの詳細を示しています (Amoeba 開発者ブログより)。

一見すると、この 2 つはまったく同じように見えます。よく見ると、この 2 つの主な違いは、MySQL プロトコルアダプターによる処理後、分析結果に基づいてデータソースデータベースが決定され、接続するために特定の JDBC ドライバーと対応するプロトコルが選択されることです。バックエンドデータベース。

実は、上記の 2 つのアーキテクチャ図を通じて、Amoeba の特徴がわかったかもしれませんが、これは単なる開発フレームワークであり、提供されている 2 つの製品 (For MySQL と For Aladin) を選択することに加えて、独自のニーズに応じて二次開発を実施し、独自のアプリケーションの特性により適した Proxy プログラムを取得して、それをベースに使用することもできます。

ただし、MySQL データベースを使用する場合は、Amoeba For MySQL と Amoeba For Aladin の両方を使用できます。もちろん、システムが複雑になるほど性能は確実に低下し、維持コストも当然高くなります。したがって、MySQL データベースのみを使用する必要がある場合は、Amoeba For MySQL を使用することをお勧めします。

Amoeba For MySQL は非常に使いやすいです。すべての設定ファイルは標準の XML ファイルです。次のように、合計 4 つあります:

amoeba.xml—— Main設定ファイル、すべてのデータソースとアメーバ独自のパラメータを設定します;
rule.xml - すべてのクエリルーティングルールの情報を設定します;
functionMap .xml - Query で関数を解析するために使用する Java 実装クラスを構成します;
rullFunctionMap.xml - ルーティングルールの種類で使用する必要がある特定の関数の実装を構成します。

ルールがそれほど複雑でない場合は、基本的に上記の 4 つの構成ファイルのうち最初の 2 つを使用するだけですべてが完了します。読み取りと書き込みの分離、負荷分散、その他の設定など、プロキシプログラムの一般的に使用される機能はすべて amoeba.xml で設定されます。さらに、Amoeba では、データの垂直方向および水平方向の分割に対する自動ルーティングがすでにサポートされており、ルーティングルールは、rule.xml で設定できます。

HiveDB を使用してデータのセグメント化と統合を実現する

以前の MySQL Proxy や Amoeba と同様、HiveDB も Java ベースのオープンソースフレームワークであり、MySQL データベースのデータセグメンテーションと統合を提供します。ただし、現在の HiveDB はデータの水平セグメンテーションのみをサポートします。これは主に、データの冗長性と基本的な HA メカニズムをサポートしながら、データベースのスケーラビリティと大規模なデータ量での高パフォーマンスのデータアクセスの問題を解決します。

HiveDB の実装メカニズムは、MySQL Proxy や Amoeba とは若干異なります。MySQL のレプリケーション機能を使用してデータの冗長性を実現するのではなく、独自のデータ冗長性メカニズムを実装します。その基礎となる層は主にデータセグメンテーション作業ベースの実装です。 Hibernate Shards について。

HiveDB では、データはさまざまなユーザー定義のパーティションキー (つまり、データセグメンテーションルールの定式化) を通じて複数の MySQL サーバーに分散されます。アクセス中にQueryリクエストを実行すると、フィルタ条件が自動的に解析され、複数のMySQLサーバーから並行してデータが読み込まれ、結果セットがマージされてクライアントアプリケーションに返されます。

純粋に機能的な観点から言えば、HiveDB は MySQL Proxy や Amoeba ほど強力ではないかもしれませんが、そのデータセグメンテーションの考え方は前の 2 つと本質的に変わりません。さらに、HiveDB はオープンソース愛好家によって共有される単なるコンテンツではなく、営利企業によってサポートされるオープンソースプロジェクトです。

HiveDB 公式 Web サイトの HiveDB アーキテクチャ図 (図 7) には、HiveDB がデータをどのように編成するかの基本情報が記載されています。アーキテクチャ情報を詳細に示すことはできませんが、基本的にデータの切断における HiveDB の役割を示すことができます。独特の側面を持っています。

データのセグメント化と統合のためのその他のソリューション

上で紹介したデータのセグメント化と統合のためのいくつかの全体的なソリューションに加えて、HSCALE などの他の多くのソリューションがあります。これは、MySQL Proxy、Rails を介して構築された Spock Proxy、Pathon をベースとした Pyshards などに基づいてさらに拡張されています。

どのソリューションを使用することを選択しても、基本的に全体的な設計思想に変更はありません。つまり、データの垂直方向および水平方向のセグメント化を通じて、データベースの全体的なサービス機能が強化され、アプリケーションシステム全体拡張機能は可能な限り向上し、拡張方法は可能な限り便利である必要があります。

データのセグメント化とデータソースの統合の問題が中間層のプロキシアプリケーションによってうまく解決されている限り、データベースの線形拡張機能はアプリケーションと同じくらい便利です。安価な PC サーバーを追加するだけです。つまり、データベースクラスターの全体的なサービス能力を直線的に向上させることができるため、データベースがアプリケーションシステムのパフォーマンスのボトルネックになりにくくなります。

データのセグメント化と統合で起こり得る問題

ここでは、誰もがデータのセグメント化と統合の実装について一定の理解を持っている必要があります。おそらく多くの読者が、利点と統合に基づいています。さまざまなソリューションの短所を考慮して、アプリケーションシナリオに適したソリューションを基本的に選択しました。次の作業は主に実装の準備です。

データ分割計画を実装する前に、考えられるいくつかの問題を分析する必要があります。一般に、遭遇する可能性のある主な問題は次のとおりです:

分散トランザクションの導入の問題、
クロスノードの問題結合の問題;
クロスノードマージソートページングの問題。
分散トランザクション導入の問題

データが分割され、複数の MySQL サーバーに保存されると、分割ルールの設計に関係なく、問題ありませんどれほど完璧であっても (実際には完璧なセグメンテーションルールはありません)、以前のトランザクションに含まれるデータが同じ MySQL Server 内に存在しなくなる可能性があります。

このようなシナリオで、アプリケーションが依然として古いソリューションに従っている場合は、それを解決するために分散トランザクションを導入する必要があります。さまざまな MySQL バージョンの中で、分散トランザクションのサポートを提供しているのは MySQL 5.0 以降のバージョンのみであり、現在、分散トランザクションのサポートを提供しているのは Innodb だけです。ただし、分散トランザクションをサポートするバージョンの MySQL を使用し、Innodb ストレージエンジンも使用したとしても、分散トランザクション自体が多くのシステムリソースを消費するため、パフォーマンスはあまり高くありません。それは制御が難しい多くの問題を引き起こすでしょう。＃＃＃＃＃＃何をするか？実際、この問題は回避策によって解決できます。最初に考慮すべきことは、トランザクションを解決できるのはデータベースだけなのかということです。実はそうではなく、データベースとアプリケーションを組み合わせることで解決できるのです。各データベースは独自のトランザクションを解決し、アプリケーションは複数のデータベース上のトランザクションを制御します。

言い換えれば、その気になれば、複数のデータベースに分散されたトランザクションを、単一のデータベース上にのみ存在する複数の小さなトランザクションに分割し、アプリケーションを通じてそれぞれの小さなトランザクションを制御することができます。もちろん、これを行うにはアプリケーションが十分に堅牢である必要があり、当然、アプリケーションに技術的な問題も発生します。

クロスノード結合の問題

上記では、分散トランザクションを引き起こす可能性のある問題を紹介しましたが、次に、クロスノード結合が必要な問題を見てみましょう。データが分割されると、Join で使用されるデータソースが複数の MySQL Server に分割される可能性があるため、一部の古い Join ステートメントは使用できなくなる場合があります。

＃＃＃何をするか？ MySQL データベースの観点から見ると、この問題をデータベース側で直接解決する必要がある場合、MySQL の特別なストレージエンジンである Federated を通じてのみ処理できるのではないかと思います。 Federated Storage エンジンは、Oracle の DB Link と同様の問題に対する MySQL のソリューションです。 Oracle DB Link との主な違いは、Federated がリモートテーブル構造の定義情報のコピーをローカルに保存することです。一見したところ、Federated は確かにクロスノード結合に対する非常に優れたソリューションです。ただし、リモートテーブルの構造が変更された場合、ローカルテーブルの定義情報はそれに応じて変更されないことも明確にしておく必要があります。リモートテーブルの構造を更新する際に、ローカルのFederatedテーブルの定義情報が更新されていないと、クエリが正しく実行されず、正しい結果が得られない可能性があります。

このような問題に対処するには、まず駆動テーブルが配置されている MySQL サーバーから駆動結果セットを取得し、その後、対応する結果を取得するアプリケーションプログラムを通じて対処することをお勧めします。駆動結果セットに基づいて、駆動テーブルが配置されている MySQL Server から設定されます。多くの読者は、そうすることでパフォーマンスに一定の影響があるのではないかと考えているかもしれませんが、確かに一定の悪影響はありますが、それ以外に、基本的にこれより優れたソリューションはあまりありません。さらに、データベースがより適切に拡張されるため、各 MySQL サーバーの負荷をより適切に制御できるようになり、単一のクエリの場合、その応答時間がセグメント化されない前よりもわずかに増加する可能性があるため、パフォーマンスに悪影響が及ぶことはありません。素晴らしい。さらに、このようなクロスノード結合の需要はそれほど多くはなく、全体のパフォーマンスと比較するとほんの一部にすぎない可能性があります。したがって、全体的なパフォーマンスを向上させるためには、実際には、時には少し犠牲にする価値がありますが、結局のところ、システムの最適化自体は、多くのトレードオフとバランスのプロセスです。

クロスノードマージの並べ替えとページングの問題

データが水平方向に分割されると、クロスノード結合が正常に実行できないだけでなく、ソートとページングの問題が発生します。クエリステートメントのデータソースも複数のノードに分割される可能性があります。その直接的な結果として、これらのソートとページングのクエリが正常に実行され続けることができなくなります。実際、これはクロスノード結合と同じであり、データソースは複数のノード上に存在し、クロスノード結合操作であるクエリを通じて解決する必要があります。同様に、Federated も部分的に解決できますが、リスクは同じです。ただし、違いが 1 つあります。結合にはドライバー主導の関係が存在することが多いため、関係する複数のテーブル間のデータ読み取りには通常、順次関係が存在します。ただし、ソートとページングは異なります。ソートとページングのデータソースは基本的にテーブル (または結果セット) であると言え、順序関係は存在しないため、複数のデータソースからデータをフェッチするプロセスは完全に並列できます。。この方法では、ソートおよびページングのデータ取得効率がデータベース間結合よりも高くなるため、パフォーマンスの低下が比較的少なくなり、場合によっては、データをセグメント化しない元のデータベースよりも効率が向上する可能性があります。もちろん、クロスノード結合であっても、クロスノードソートおよびページングであっても、結果セットの読み取り、アクセス、およびマージのプロセスには、マージを処理しない場合よりも多くのデータが必要となるため、アプリケーションサーバーはより多くのリソース、特にメモリリソースを消費します。 . .

以上がmysqlでデータセグメンテーションを実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。