主流のリレーショナル分散データベースの選択と設計

[[420327]]

[[420328]]

王宗瑞

Alibaba Cloud データベース配信アーキテクト

彼はインターネット業界のデータベース分野で 9 年間の経験を持ち、DBA、プリセールス アーキテクト、デリバリー アーキテクトとして活躍してきました。彼は、分散データベース技術とデータベースの運用および保守の自動化に特に経験があります。彼の現在の仕事の方向性は、情報技術革新の分野における国内データベースの変革と分散変革です。

著者はMySQL DBAとして業界に入り、分散データベースの運用・保守や自動化開発に5年間携わり、大規模データベースクラスターの管理経験を積んできました。その後、クラウド データベースのプリセールス ソリューションおよび配信ソリューション アーキテクトとして働きました。顧客の研究開発部門や DBA とコミュニケーションを取り、協力する過程で、多くの学生が市場にあるデータベース、特に分散型データベースの多種多様な種類に圧倒され、選択に困惑していることに気づきました。ここでは、分散データベースの分野における私の実際の運用、保守、アーキテクチャ、実装の経験を皆さんと共有し、議論を刺激し、皆さんの共感を得ることができればと思います。

4つの側面からご紹介します。

1. 集中型から分散型へのデータベースの進化

1. 従来のスタンドアロンデータベース

狭義では、「データベース」とは、Oracle や DB2 などの古い商用データベースや、MySQL や PostgreSQL などのオープンソース製品など、OLTP シナリオ用のリレーショナル スタンドアロン データベースを指します。これらは主に、オンライン データベースへのリアルタイムで効率的なアクセスとトランザクションの保証という 2 つのビジネス上の問題を解決します。

従来のスタンドアロン データベースは、基本的な機能に加えて、特定のビジネス シナリオを満たすために、ビュー、トリガー、外部キー制約、ストアド プロシージャなどの多くの従来のデータベース機能もサポートしています。率直に言って、従来のスタンドアロン データベースの容量とパフォーマンスは、大多数の中小規模の顧客のニーズを満たすのに十分です。特定のソフトウェアおよびハードウェアの条件に依存して、商用データベースは、一部の大規模顧客のデータベース使用ニーズを満たすこともできます。

しかし、インターネット時代の到来とともに、ビジネス データは爆発的に増加し、スタンドアロン データベースでは、ストレージ容量、コンピューティング、スループットのボトルネックが発生しました。データ量の拡大は、ストレージコストの増加だけでなく、データベースの運用・保守の難しさやデータセキュリティリスクも増大させます。同時実行性の高いビジネス シナリオ、特に同時実行性の高い更新シナリオでは、十分なデータベース コンピューティング リソースとディスク IO リソースが必要ですが、スタンドアロン データベースでは不十分です。業務を通じてデータを複数のデータベースインスタンスに合理的に分割することで、単一マシンのリソースがピークに達する時間を遅らせることができますが、アーキテクチャの変革には継続的な高いコストが必要です。

2. 分散データベース

この場合、分散データベースが解決策として登場しました。基本的な考え方は、複数の物理マシンのリソースをデータベースとして整理し、アプリケーションにサービスを提供することです。理想的には、高同時実行シナリオにおけるコンピューティング、ストレージ IO、およびネットワーク IO の負荷は、物理マシン間でバランスが取れています。同時に、ビジネスの将来の成長ニーズに完全に対応するために、リソースを水平方向に拡張する機能も必要です。

現在の分散データベースは、分散データベース ミドルウェアとネイティブ分散データベースの 2 種類に分類できると一般に考えられており、すべての主要データベース ベンダーも例外ではありません。

分散データベース ミドルウェアのアーキテクチャはボトムアップです。つまり、単一マシンのデータベース インスタンスが基盤となるストレージ ノードとして結合され、プロキシ レイヤーとして使用され、大量のデータのサブライブラリとテーブル分割のロジックをアプリケーションから保護します (理想的には、アプリケーションは分散ロジックをまったく認識せず、SQL 最適化設計を実現するのは困難です)。基盤となるストレージ リソースの拡張もアプリケーションには認識されず、これは典型的な ShareNothing アーキテクチャです。

ネイティブ分散データベースは、過去数年間人気があった NewSQL データベースであり、コンピューティング層とストレージ層が緊密に結合された統合アーキテクチャを備えています。コンピューティング層の OLTP データベースは、負荷分散と高可用性を実現できる SMP アーキテクチャを使用します。 OLAP データベースは、並列処理を使用して複雑なクエリを高速化するマルチビット MPP アーキテクチャを使用します。ストレージ層では、IO リソースを分離するために ShareNothing アーキテクチャがよく使用され、データの可用性と一貫性のバランスをとるために複数のコピー間で分散一貫性アルゴリズムが使用されます。コンピューティング層とストレージ層は統合された全体として設計されているため、従来のスタンドアロン データベースの製品機能との互換性が高くなることがよくあります。

3. クラウドネイティブデータベース

これは近年人気のデータベース分類です。分散データベースと混同されることがよくありますが、両者の間には当然の違いがあります。

クラウド ネイティブとは、本質的には、クラウド コンピューティング インフラストラクチャの高パフォーマンス、高信頼性、高弾力性を最大限に活用してクラウド製品を開発する方法です。クラウド コンピューティング リソースに基づいて特別に開発されたデータベースは、AWS の Aurora や Alibaba Cloud の PolarDB などのクラウド ネイティブ データベースです。従来のスタンドアロン データベースに近い機能サポートと使用エクスペリエンスを提供できるだけでなく、リソース (コンピューティングとストレージ) を迅速かつ柔軟に拡張する機能も備えています。リソースは分散されていますが、データベース アーキテクチャの本質は依然としてスケールアップにあります。

クラウド インフラストラクチャとの強力な結合は、クラウド ネイティブ データベースと分散データベースを区別する最大の特徴です。

4. さまざまなシナリオにおける分散データベースの選択

一部のビジネス シナリオでは、分散データベース ソリューションを採用する必要がないことがよくあります。簡素化するために、より軽量なソリューションがあります。

• 一部のニュースおよびリソース アプリケーションでは、書き込みよりも読み取りが多くなるという特性がよくあります。これに対処するには、クエリ キャッシュと単一マシン データベースの読み取り/書き込み分離を導入することをお勧めします。分散データベースのアップグレードはお勧めしません。

• 一部の電子商取引アプリケーションには、同時更新が多いという特徴があります。業務負荷が高いという問題を低コストで解決するには、業務モジュールを垂直分割する手法を使用することをお勧めします。その後、ビジネスの成長に応じて、高同時実行モジュールごとに分散データベースを個別にアップグレードします。

• 一部の国家レベルのオンライン サービスでは、膨大な量のリアルタイム データを保存し、高い同時スループットを処理します。これは分散データベースを使用する典型的なシナリオです。

• 歴史的な理由により、MySQL データベースに代表される一部のアプリケーションでは、1 つのテーブルに数億のデータが蓄積され、1 つのテーブルのデータ ファイルが GB レベルに達し、パフォーマンスが大幅に低下するようになりました。このシナリオでは、オンライン データの保持時間を短縮し、データ アーカイブ ソリューションを開始するよう企業と交渉することをお勧めします。同時に、インデックスが完璧ではないか、最適化の余地があるかどうかを検討する必要があります。分散データベースはバックアップ ソリューションです。

• OLAP シナリオの場合、データベース アーキテクチャをアップグレードせずに、コストが低いストリーム コンピューティングや事前計算などのビッグ データ処理ソリューションと製品を導入することをお勧めします。これらのソリューションでもビジネス ニーズを満たすことができない場合は、専用の OLAP データベースを導入する必要があります。

• 現在、中国のさまざまな業界における IT 変革にとって、国内データベースの変革は重要な方向性となっています。これまで従来の商用データベースを選択していたお客様にとって、最も必要なのは、変換と移行のコストを抑えるために互換性の高いデータベースです。分散データベースを選択するかどうかは、顧客のビジネス シナリオが上記の指標を満たしているかどうかによって決まります。

• ネイティブ分散データベースには、データベースの災害復旧やマルチサイトのアクティブ/アクティブ シナリオにおいて当然の利点があります。基本的なリソース、ビジネスの一貫性要件、および可用性要件を満たすために、さまざまなデプロイメント アーキテクチャを使用できます。アプリケーションの災害復旧とマルチサイト アクティブ/アクティブの研究開発に集中するだけで済みます。

2. 分散データベースの分類

アプリケーション シナリオの観点から見ると、市場にある分散データベースは、OLTP、OLAP、非機関および独自の NOSQL の 3 つのカテゴリに分類できます。これは、ほとんどのクラウド ベンダーのデータベース製品ページにおける一般的な分類でもあります。

1. OLTPデータベース

Mycat と PlarDB-X (旧 DRDS) は同じ起源を持っています。どちらも元々は Taobao のデータベース ミドルウェア TDDL でした。 1 つはオープンソースであり、もう 1 つは商用製品です。

• TiDB は、非常に活発なエコシステムと多くのパートナーを擁する、非常に成功したオープンソース分散データベースです。

• OceanBase は、Ant Group によって開発された最も初期の分散データベースです。主にAlipayの事業全体をサポートします。金融業界で多くの成功した顧客事例を持ち、オープンソース エコシステムを採用しています。

2. OLAPデータベース

OLAP データベースでは、多くの場合、膨大な量のデータの複雑な分析を処理する必要があり、MPP アーキテクチャを使用する必要があるため、当然、分散アーキテクチャ、データ シャーディング、並列コンピューティングの高速化が必要になります。

3. 非機関向けおよび独自仕様のNoSQL

キャッシュ分野では、Codis は TP データベース ミドルウェア ソリューションに似ています。

ワイドカラム データベース (bigtable) は、大量の非構造化データを格納するためによく使用されます。これには高い書き込みスループットが必要であり、当然ながら分散アーキテクチャが必要になります。

時系列データベースとグラフ データベースの分野では、すべての製品が分散されているわけではありませんが、これら 2 つのシナリオに関係するデータの量が急速に増加する場合、分散アーキテクチャはプラスになります。

III.リレーショナル分散データベースのベストプラクティス

1. 分散データベースミドルウェア

1) シナリオ1

分散データベース ミドルウェアを使用する前提は、データが完全かつ合理的に垂直に分割されていることです。

ベストプラクティスは、ビジネスとデータが自然な水平分割の特性を備えていることです。たとえば、ユーザー ID 分割に自然に適した個人ネットワーク ディスク、購入者 ID 分割に自然に適した電子商取引購入者データベース、カード番号分割に自然に適した電子社会保障カードなどです。

同時更新が多い大規模なデータ テーブルは、水平分割に適しています。それに関連付けられた小さなテーブルは、ブロードキャスト テーブルとして使用されます。関連付けられていない単一のテーブルは分割しないでください。

2) シナリオ2

スムーズな拡張機能は、分散ミドルウェアの核となる技術的競争力です。ビジネス無感覚は最高レベルですが、実際に達成するのは困難です。

容量拡張時の操作可能なデータの粒度は諸刃の剣です。ビジネスの柔軟性と O&M の利便性を同時に実現することはできません。

分割キーレベルでのデータ移行と拡張は、データベースのホットスポットを解決する良い方法です。

最高レベルの容量拡張は、基盤となるデータ ノードとミドルウェア コンピューティング層の適応型弾性スケーリングです。現時点では、クラウドネイティブデータベースとの組み合わせが解決策であると思われます。

3) シナリオ3

このソリューションは主に分散データベースミドルウェアのルーティング柔軟性をテストします。

アクセスの有効性と頻度が許せば、アーカイブ ライブラリまたはアーカイブ ストレージはコールド デバイスであってもよく、必要に応じて自動的に電源がオンになり、ロードされることもできます。

アーカイブ ライブラリへの OLAP アクセスの場合、専用の MPP アーキテクチャを備えたミドルウェア プロキシ レイヤーを構成して、並列コンピューティングの高速化効果を実現し、競合を回避するために OLTP ビジネスからリソースを分離できます。

2. ネイティブ分散データベース

1) シナリオ1

• 大きな利点は、自動リソース管理です。新しいマシンがリソース プールに追加されると、データの再バランスが有効になっている場合は、そのマシンは自動的に移行され、バランスが取られます。これは、弾力的なリソース スケーリングの基礎でもあります。

• このアーキテクチャに基づいて、上位層は理論的にはさまざまなデータベース インターフェースと互換性があり、スムーズなデータベース移行エクスペリエンスを提供できます。

2) シナリオ2

• 単一のコンピュータ ルームでのラック レベルの災害復旧から 2 つのサイトと 3 つのセンターのコンピュータ ルームでの部屋レベルの災害復旧まで、従来のデータベースのマスター スレーブ レプリケーション アーキテクチャを同期に使用すると、一貫性と可用性のジレンマが発生します。データ監査やデータ修復などの複数の保険メカニズムが必要となり、複雑なアプリケーションやデータベースの開発が困難になります。

• ネイティブ分散データベースは、クラスター化されたストレージに分散一貫性アルゴリズムを使用して、強力な一貫性と書き込み効率を保証します。少数のノードに障害が発生しない限り、データベース サービスの可用性も保証されます。

• マルチアクティブ アーキテクチャには、データベースに対する要件だけでなく、複数のアプリケーション レイヤーのトラフィック エラー修正に対する厳しい要件もあります。また、データベース自体に書き込みエラーを防ぐ機能も必要であり、全体的な設計ソリューションが必要になります。

3) シナリオ3

• 国内データベースの変換に分散ソリューションを選択する必要はありませんが、分散は従来のスタンドアロン データベースよりも国内データベースの利点となることがよくあります。国内のスタンドアロンデータベースを選択すると、天機の競馬のような受動的な状況に陥ります。

• 取得および再生テクノロジはこのプロセスの重要なリンクであり、移行後にデータベースの機能特性とパフォーマンスが低下しないことを強力に保証します。

• 分散データベース変換を使用した後は、分割する必要があるテーブルのみをパーティション分割用に設計する必要があります。 「分散されているからといって、すべてのテーブルを分散する必要がある」と考えないでください。

4. リレーショナル分散データベースの概要と展望

一言でまとめると、テクノロジーには特効薬はないということです。最適なデータベース製品や、万能の分散データベース アーキテクチャ ソリューションは存在しません。特定のビジネス シナリオに最適なソリューションのみが存在します。

分散データベース ミドルウェアは、データが自然なシャーディング特性を持つシナリオに特に適していますが、SQL 開発では非分割キー クエリと分散トランザクションを回避する必要があります。そうしないと、スループットが非常に低下します。

ネイティブ分散データベースは、リソースの弾力的なスケーリング、可用性、強力な一貫性に対する要件が高いシナリオに適しています。従来のデータベースと互換性がありますが、アーキテクチャが非典型的であることが多く、操作と保守が若干難しくなります。分散実行プランを最適化するスキルも必要です。

分散ミドルウェア製品は、適応型パーティション テーブル、データ一貫性ハッシュ、統合バイナリ ログ サービスなどの新機能の開発を通じて、ネイティブ分散データベースにますます近づきつつあることは注目に値します。同様に、ネイティブ分散データベースでは、データの透過的な水平分割を実現するミドルウェア ソリューションを完全に排除することはできません。今後両者の境界は徐々に曖昧になっていくと思われます。

ネイティブ分散データベースの運用と保守のアーキテクチャは従来のデータベースとは大きく異なり、関連する人材の蓄積と使用経験の蓄積と共有が必要になります。これは、オープンソース コミュニティを受け入れ、テクノロジー エコシステムの開発に努める重要な理由でもあります。

> > > >

質疑応答

Q1: 分散最終データ整合性の一般的なプラクティスとベスト プラクティスは何ですか?

A1: この質問に答えるために、分散ミドルウェアの例を挙げてみましょう。私は、柔軟なトランザクション アプローチを使用して分散トランザクションを初めて実装した分散ミドルウェアに精通しています。この方法は基本的に、トランザクションが実行されるたびに、ミドルウェア自体が各 SQL ステートメントの UNDO ログと REDO ログを記録することを意味します。問題が発見されると、状況に応じて再試行するかロールバックするかを決定します。このプロセス中、データの中間状態が存在します。このプロセス中にクエリを実行すると、データに矛盾があることがわかります。ただし、UNDO ログと REDO ログのメカニズムにより、各トランザクションのデータの最終状態の一貫性を確保できます。同時に、この柔軟なトランザクションはクエリのレイテンシと SQL スループットの点で非常に優れたパフォーマンスを発揮し、最終的な一貫性を確保できるものの、金融業界や電子商取引業界の一部のトランザクション シナリオなど、多くの顧客のより厳格なデータ一貫性要件を満たすことができないこともわかりました。そのため、彼らはこのソリューションを分散トランザクションの代替として使用しました。同時に、分散トランザクションの補足ソリューションとして XA トランザクションも実装し、グローバル論理クロック トランザクションのソリューションにさらに近づきました。これが彼らが最終的にやったことだ。まとめると、最終的なデータの一貫性は、一部のビジネス シナリオのニーズを満たすことしかできません。一般的かつ理想的な分散トランザクション ソリューションは、強力な一貫性を備えている必要があります。

Q2: ビジネス上の複雑な複数条件クエリ用のミドルウェアの分散データベースに関して、共有できる経験はありますか?

A2: この質問は実際に記事に記載されています。現在、優れたミドルウェア分散データベース製品の中には、グローバルセカンダリインデックスを持つ機能を備えているものもあります。つまり、制限された多次元クエリをサポートできます。たとえば、マスター データは注文 ID に基づいて分割されていますが、クエリ用に販売者 ID または購入者 ID をインストールしたいと考えています。どうすればいいですか？次のように実行できます。販売者 ID または購入者 ID のセカンダリ インデックスを作成し、そのセカンダリ インデックスを使用して購入者 ID または販売者 ID と注文 ID 間のマッピング関係を保存します。同時に、パフォーマンスをさらに向上させるために、グローバルセカンダリインデックスでより多くのフィールドをカバーし、セカンダリインデックスをクエリするときにいくつかの要件に従ってテーブルが返されることを回避することもできます。この方法は、多次元クエリの問題を解決するために使用できます。

Q3: 分散データベースでネットワーク パーティションの問題に遭遇したことがありますか?

A1: この質問はネイティブ分散データベースに関するものです。ネイティブ分散データベースのいわゆる半同期、強力な同期などの方法を使用したり、一貫性のあるパーティションに Zookeeper に基づくフォールト トレランスを使用したりすると、実際にはスプリット ブレインなどの問題が発生します。しかし基本的に、現在のネイティブ分散データベースはすべて、Poxos タイプの分散一貫性プロトコルに基づくソリューションを使用しています。このソリューションの最大の特徴は、多数派ノードに障害が発生しない限り、少数派ノードに障害が発生した後、多数派ノードが自然にマスターを選択し、外部へのサービスを迅速に復旧し、データの一貫性を確保することです。少数派がネットワークの分断を発見し、自分たちが少数派であり選挙ができないと知ると、自然に外部へのサービスの提供を停止するでしょう。このようにして、ネットワーク パーティションとスプリット ブレインの問題を回避できます。