基礎知識：分散SQLとは何か

[51CTO.com クイック翻訳] 過去 40 年近くにわたって、SQL はリレーショナル データベース (RDBMS とも呼ばれます) の共通言語になりました。このため、リレーショナル データベースは単に SQL データベースと呼ばれることがよくあります。アーキテクチャの観点から見ると、Oracle、PostgreSQL、MySQL などの従来の SQL データベースはモノリシックです。つまり、データとクエリを複数のインスタンスに自動的に分散することはできません。 NewSQL データベースの出現により、SQL はスケーラブルかつ高性能になりました。もちろん、このようなデータベースには依然として固有の制限があります。

2015 年には、Docker コンテナと Kubernetes オーケストレーションの登場により、柔軟で構成可能なインフラストラクチャ方式でさまざまなマイクロサービス ベースのアプリケーションを作成できるようになりました。その中で、組み込みのスケーラビリティ、柔軟性、地理的分散は、このタイプのクラウドネイティブ アーキテクチャの中心的な機能です。これはよく「分散 SQL」と呼ばれる、新しいタイプのデータベースです。アプリケーションの観点から見ると、このタイプの分散 SQL データベースの注目すべき特徴は、ノードの数に関係なく、データベース クラスター全体がアプリケーションによって単一の論理 SQL データベースとして認識されることです。

データベースアーキテクチャ

分散 SQL データベースは通常、次の 3 層アーキテクチャを備えています。

1. SQL API

名前が示すように、分散 SQL データベースは、アプリケーションがリレーショナル データをモデル化し、さまざまなリレーショナル情報を含むクエリ操作を実行できるように、SQL API サービスを提供する必要があります。インデックス、外部キー制約、JOIN クエリ、複数行の ACID トランザクション (翻訳者注: 原子性、一貫性、独立性、永続性) など、SQL データベースの一般的なデータ モデリング構造が保持されます。

2. 分散クエリ実行

分散 SQL クエリはターゲット クラスター内の複数のノードに自動的に分散できるため、単一のノードがクエリ処理のボトルネックになるという問題を効果的に回避できます。具体的なクエリ プロセスは次のとおりです。ターゲット クラスター内の任意のノードが着信クエリを受け入れることができます。ネットワーク内のノード間でデータを転送し、連携することで、ノードはクエリ要求内のタスクの一部のみを共有し、処理の遅延を最小限に抑えることができます。他のノードは残りの作業の完了を支援します。最後に、リクエストを受信した元のノードはすべてのクエリ結果を集約し、クライアント アプリケーションに送り返します。

3. 分散データストレージ

インデックス情報を含むデータは、クラスター内の複数のノードに自動的に分散（シャード化とも呼ばれます）されます。これにより、単一のノードが高パフォーマンスと高可用性のボトルネックになることがなくなります。さらに、データベース クラスターは、一貫性の高いレプリケーションと複数行 (分散型とも呼ばれる) ACID トランザクションをサポートできるため、単一の論理データベースという基本的な概念が維持されます。

一貫性の高いレプリケーション

データベース管理の概念では、いわゆる強力な SQL API レイヤーのサポートには、基本的に、基盤となるストレージ レイヤーがデータベースのクラスター ノード間で強力な一貫性のあるレプリケーションを確立できることが必要です。つまり、障害発生時にデータの可用性を確保するために、データベースへの書き込み操作が複数のノードで同期的に送信されます。読み取り操作は、最後にコミットされた書き込みデータ、またはエラーが発生する前のデータに基づいて行われます。この特性は、線形化可能性 (http://www.bailis.org/blog/linearizability-versus-serializability/) と呼ばれることがよくあります。有名な CAP 原則 (https://towardsdatascience.com/cap-theorem-and-distributed-database-management-systems-5c2be977950e、翻訳者注: 一貫性、可用性、分断耐性) によれば、分散 SQL データベースは一貫性があり、分断耐性があります。

分散ACIDトランザクション

分散 ACID トランザクションをサポートするには、分散データベースのストレージ層で、複数のノード上の複数のデータ行でトランザクション調整タスクを実行する必要があります。ここでは、2 フェーズ コミット (2PC) プロトコルを使用します。 ACID の I (分離) の要件を参照すると、同時データ アクセスの厳密な分離を実現するために、分散 SQL データベースは、最も厳格な分離レベルとして直列化可能性 (http://www.bailis.org/blog/linearizability-versus-serializability/) を使用し、スナップショットなどの他の方法を通じてより弱い分離レベルをサポートします。

ビジネスアプリケーションの利点

分散 SQL の 4 つの主な利点を下の図に示します。

1. SQLとトランザクション開発をよりアジャイルにする

現在でも、SQL は関係性や複数行の操作を簡単にモデル化できるデータモデリング言語であるため、SQL データベースに対するアプリケーション開発者の継続的な操作習慣とニーズを満たすために、Amazon DynamoDB、MongoDB、FaunaDB などの NoSQL データベースでもトランザクション操作機能が導入され始めています。たとえば、SQL では、複数行のトランザクションを明示的に (BEGIN および END TRANSACTION 構文を使用して) および暗黙的に (外部キーや JOIN クエリなどのセカンダリ インデックスを使用して) 許可します。これは、従来のキー値 NoSQL よりもはるかに便利です。

さらに、開発者は多くの場合、SQL を使用してデータ (およびストレージ) を一度で簡単にモデル化することを好む傾向があります。ビジネス要件が変更された場合は、JOIN を変更してクエリに反映させるだけで済みます。

2. ローカルフェイルオーバーと修復による優れた回復力

分散 SQL データベースでは、シャードごとの分散コンセンサス レプリケーションなどのテクノロジを使用して、障害発生時に各シャード (各インスタンスではなく) の高可用性が維持されるようにします。

このように、インフラストラクチャに障害が発生した場合、クラスター全体に影響することなく、ターゲット データのサブセット (つまり、リーダーによって分離されたフラグメント) のみに影響します。さらに、残りのシャード コピーは数秒以内に自動的に新しいリーダーを選出できるため、障害が発生した場合でもクラスターはある程度の自己修復能力を発揮します。

さらに、クラスター構成へのこれらの変更はバックグラウンドで行われ、アプリケーションに対して完全に透過的であるため、中断やパフォーマンスの低下なしに通常どおり実行を継続できます。

3. オンデマンドの横書きのスケーラビリティ

記事「分散 SQL データベースでのデータ シャーディングの仕組み」では、開発者が分散 SQL データベースで自動データ シャーディングを実装する一般的な方法について説明します。新しいノードが追加されたか、既存のノードが削除されたかに関係なく、シャードは利用可能なすべてのノード間で自動的にバランスが保たれます。

現在、トランザクションを処理する必要があるアプリケーションには、スケーラブルな機能を備えたマイクロサービスが存在します。新しいインフラストラクチャを必要とせず、メモリ内キャッシュ (書き込み要求の処理を維持しながらデータベースから要求を読み取る必要がない) または NoSQL データベース (書き込み操作を拡張できるが ACID を保証することはできない) に直接依存できます。

4. 地理的に分散したデータの低遅延

「低レイテンシでクラウドネイティブな地理的に分散された SQL アプリケーションを構築するための 9 つのテクニック」という記事で強調されているように、分散 SQL データベースは地理的に分散されたアプリケーションを構築するためのさまざまなテクニックを提供できます。これらのテクノロジーは、地域的な障害に対する災害復旧の自動化に役立つだけでなく、データを地域のエンドユーザーに近づけることで、データの遅延を短縮することもできます。

元のタイトル: 分散 SQL とは何ですか?著者: シド・チョードリー

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。