sql >> データベース >  >> RDS >> MariaDB

MariaDBがXpandでグローバルスケールを実現する方法

    この記事はInfoWorldに最初に掲載されました 。許可を得て転載しています。 ©IDGCommunications、Inc.、2020.無断複写・転載を禁じますMariaDBがXpandで世界規模を達成する方法。 XpandがMariaDBSkySQLで利用できるようになり、クラウドでのスケーラビリティと弾力性のために分散SQLが追加されました。

    情報と処理のニーズが高まるにつれ、パフォーマンスや復元力などの問題点により、新しいソリューションが必要になりました。データベースは、ACIDのコンプライアンスと一貫性を維持し、高可用性と高性能を提供し、リソースを浪費することなく大量のワークロードを処理する必要があります。シャーディングはソリューションを提供しましたが、多くの企業にとって、シャーディングはその複雑さとリソース要件のために限界に達しています。より良い解決策は分散SQLです。

    分散SQL実装では、データベースは複数の物理システムに分散され、グローバルにスケーラブルなレベルでトランザクションを提供します。 MariaDBプラットフォームのあらゆる側面へのアップグレードを含むメジャーリリースであるMariaDBプラットフォームX5は、Xpandと呼ばれる新しいスマートストレージエンジンの追加を通じて、分散SQLと大規模なスケーラビリティを提供します。シェアードナッシングアーキテクチャ、完全に分散されたACIDトランザクション、および強力な一貫性を備えたXpandを使用すると、1秒あたり数百万のトランザクションに拡張できます。

    最適化されたプラグ可能なスマートエンジン

    MariaDB Enterprise Serverは、プラグ可能なストレージエンジン(Xpandなど)を使用して、単一のプラットフォームから特定のワークロードを最適化するように設計されています。特定のワークロードを処理するための専用データベースは必要ありません。分散SQL用のスマートエンジンであるMariaDBXpandは、最新のラインナップです。 Xpandは、他のエンジンが提供するオプションに、非常にスケーラブルな分散トランザクション機能を追加します。他のプラガブルエンジンは、分析(列型)、読み取りが多いワークロード、および書き込みが多いワークロードの最適化を提供します。複製されたテーブル、分散されたテーブル、および列状のテーブルを組み合わせて、特定の要件に合わせてすべてのデータベースを最適化できます。

    MariaDB Xpandを追加すると、企業のお客様は、使い慣れたMariaDBのメリットを維持しながら、分散SQLのすべてのメリット(速度、可用性、スケーラビリティ)を得ることができます。

    MariaDBXpandが分散SQLを提供する方法の概要を見てみましょう。

    SQLをインデックスに分散

    Xpandは、ノード間でデータをスライス、複製、および分散することにより、分散SQLを提供します。これは何を意味するのでしょうか?概念を示すために、1つのテーブルと3つのノードを持つ非常に単純な例を使用します。この例には、すべてのスライスが複製されていることは示されていません。

    上記の図1には、2つのインデックスを持つテーブルがあります。テーブルにはいくつかの日付があり、列2にインデックスがあり、列3と1に別のインデックスがあります。インデックスは、ある意味でテーブルそのものです。それらはテーブルのサブセットです。主キーはid 、テーブルの最初のインデックス。これが、テーブルデータをハッシュしてデータベース全体に分散させるために使用されます。

    次に、スライスの概念を追加します 。スライスは、基本的にテーブルの水平パーティションです。テーブルには5つの行があります。図2では、テーブルがスライスされて分散されています。ノード#1には2つの行があります。ノード#2には2つの行があり、ノード#3には1つの行があります。目標は、データをノード間で可能な限り均等に分散させることです。

    インデックス スライスされて配布されています。これは、Xpandと他の分散ソリューションの主な違いです。通常、分散データベースにはローカルインデックスがあるため、すべてのノードに独自のデータのインデックスがあります。 Xpandでは、インデックスはテーブルとは独立して分散および格納されます。これにより、すべてのノードにクエリを送信する必要がなくなります(分散/収集)。上記の例では、ノード#1にはテーブルの行2と4が含まれ、行32と35、および行4月と3月のインデックスも含まれています。テーブルとインデックスは、ノード間で個別にスライス、分散、および複製されます。

    クエリエンジンは、分散インデックスを使用して、データの場所を決定します。必要なインデックスパーティションのみを検索し、必要なデータが存在する場所にのみクエリを送信します。クエリはすべて配布されます。それらは同時に並行して行われます。それらがどこに行くかは、データとクエリを解決するために何が必要かによって完全に異なります。

    すべてのスライスは少なくとも2回複製されます。スライスごとに、他のノードに存在するレプリカがあります。デフォルトでは、そのデータの3つのコピー(スライスと2つのレプリカ)があります。各コピーは異なるノードに配置され、複数のアベイラビリティーゾーンで実行している場合、それらのコピーも異なるアベイラビリティーゾーンに配置されます。

    読み取りおよび書き込み処理

    別の例を見てみましょう。図3には、Xpand(ノード)を備えたMariaDBEnterpriseServerの5つのインスタンスがあります。顧客プロファイルを保存するためのテーブルがあります。シェーンのプロファイルのスライスはノード#1にあり、コピーはノード#3とノード#5にあります。クエリはどのノードでも受信でき、読み取りか書き込みかによって処理が異なります。

    分散トランザクション内で同期的にすべてのコピーに書き込みが行われます。メールやアドレスを変更したために「シェーン」プロファイルを更新するたびに、それらの書き込みはトランザクション内のすべてのコピーに同時に送信されます。これが強い一貫性を提供するものです。

    図3では、UPDATEステートメントはノード#2に送られました。ノード#2には私のプロファイルに関して何もありませんが、ノード#2は私のプロファイルがどこにあるかを認識し、ノード#1、ノード#3、およびノー​​ド#5に更新を送信し、そのトランザクションをコミットしてアプリケーションに戻ります。

    >

    読み取りの処理方法は異なります。この図では、プロファイルが含まれているスライスはノード#1にあり、コピーはノード#3とノード#5にあります。これにより、ノード#1がランキングレプリカになります。すべてのスライスにはランキングレプリカがあり、これはデータを「所有する」ノードであると言えます。デフォルトでは、読み取りがどのノードに入っても、それは常にランキングレプリカに移動するため、私に解決されるすべてのSELECTはノード#1に移動します。

    弾力性の提供

    Xpandのような分散データベースは、アプリケーション内のデータに応じて絶えず変化し、進化しています。リバランサープロセスは、データ分散を現在のニーズに適合させ、ノード間でスライスの最適な分散を維持する役割を果たします。再配布を必要とする一般的なシナリオは3つあります。ノードの追加、ノードの削除、および不均一なワークロードまたは「ホットスポット」の防止です。

    たとえば、3つのノードで実行しているが、トラフィックが増加していることがわかり、スケーリングする必要があるとします。トラフィックを処理するために4番目のノードを追加します。図4に示すように、ノード#4を追加すると、ノード#4は空になります。図5に示すように、リバランサーはノード#4を利用するためにスライスとレプリカを自動的に移動します。

    ノード#4に障害が発生した場合、リバランサーは自動的に再び機能します。今回は、レプリカからスライスを再作成します。データが失われることはありません。レプリカも再作成され、ノード#4に存在していたレプリカが置き換えられるため、高可用性を確保するために、すべてのスライスに他のノードにレプリカが再び存在します。

    図6.ノードに障害が発生した場合、Xpandリバランサーは、障害が発生したノードに存在していたスライスとレプリカを、他のノードのレプリカデータから再作成します。

    ワークロードのバランスをとる

    スケールアウトと高可用性に加えて、リバランサーは、ホットスポットまたは十分に活用されていない不均等なワークロード分散を軽減します。完全なハッシュアルゴリズムを使用してデータがランダムに分散されている場合でも、ホットスポットが発生する可能性があります。たとえば、今月発売された10個の製品がたまたまノード#1に置かれている可能性があります。データは均等に分散されますが、ワークロードは分散されません(図7)。このタイプのシナリオでは、リバランサーはスライスを再配布してリソース使用率のバランスを取ります(図8)。

    図7.Xpandはデータを均等に分散していますが、ワークロードは不均一です。ノード1のワークロードは、他の3つのノードよりも大幅に高くなっています。

    図8.Xpandリバランサーはデータスライスを再配布して、ノード間でワークロードのバランスを取ります。

    スケーラビリティ、速度、可用性、バランス

    情報と処理のニーズは今後も増え続けるでしょう。それは当然のことです。 MariaDB Xpandは、レプリケーションやシャーディングなどの他の代替手段では満たすことができない要件を持つ企業向けに、一貫性のあるACID準拠のスケーリングソリューションを提供します。

    分散SQLはスケーラビリティを提供し、MariaDBXpandは必要なスケーラビリティを選択する柔軟性を提供します。 1つのテーブルまたは複数のテーブル、あるいはデータベース全体を配布します。選択はあなた次第です。運用上、容量はいつでも変化するワークロードの需要に対応するように簡単に調整できます。過剰にプロビジョニングする必要はありません。

    Xpandはまた、不均一なリソース使用率から透過的に保護し、データを動的に再配布して、ノード間でワークロードのバランスを取り、ホットスポットを防ぎます。開発者にとって、スケーラビリティとパフォーマンスについて心配する必要はありません。 Xpandは弾力性があります。 Xpandは、冗長性と高可用性も提供します。データをスライス、複製、ノード間で分散することで、データが保護され、ハードウェア障害が発生した場合でも冗長性が維持されます。

    また、MariaDBのアーキテクチャを使用すると、分散テーブルは、クロスエンジンJOINを含め、他のMariaDBテーブルとうまく連携します。 MariaDBプラットフォーム上の単一のデータベースで、複製、分散、または列状のテーブルをすべて混合して照合することにより、必要なデータベースソリューションを作成します。


    1. カウントを使用して発生数を見つける

    2. SQL Serverで末尾の空白を削除する方法– RTRIM()

    3. SQLIN句1000項目の制限

    4. Oracleでのカンマ区切り値の分割