分散アーキテクチャでは、従来のデータベースの運用と保守はどのような変化に直面するでしょうか?

[[319472]]

分散アーキテクチャは近年最もホットなトピックかもしれません。この記事では、集中型の SOA から分散アーキテクチャまで、金融業界が近年経験してきたアーキテクチャの進化について説明します。この記事では、今日の一般的な分散データベースの実装原則と組み合わせて、分散データベースの 3 つの開発段階を分析します。分散データベースの適用により、従来のデータベースのパフォーマンス拡張の問題が解決されますが、運用および保守担当者にとっての課題も生じます。では、分散データベースの管理には具体的に何が含まれるのでしょうか?どうすればうまく管理できるでしょうか?将来、データベースとデータベース操作はどこに向かうのでしょうか?この記事を読めば答えが見つかります。

1. 金融業界は長年にわたってどのような構造的進化を経験してきましたか?

1. 集中型アーキテクチャ

分散アーキテクチャは近年最もホットなトピックかもしれません。その反対は集中型アーキテクチャであり、これは銀行などの従来の金融業界で最も一般的な展開アーキテクチャです。 「脱IOE」以前、大手銀行の目標は依然として集中化された単一ポイントの強化と拡大にありました。多くの銀行が IBM のメインフレーム システムを使用していることは、その顕著な例です。これは、通常は最高のマシンを使用するデータベース サーバーの場合に特に当てはまります。

近年、銀行業務の成長、インターネット業界の爆発的な成長、ユーザーの行動パターンの変化により、集中型アーキテクチャシステムは大きな課題に直面しています。問題は主に、スケーラビリティと可用性という 2 つの側面にあります。

1. スケーラビリティ

集中型アーキテクチャの水平スケーラビリティは非常に低くなります。パフォーマンスが不十分な場合、ユーザーが実行できるのは、CPU の追加、メモリの追加、ストレージの変更、マシンの変更などだけです。

2. 可用性

集中型アーキテクチャのサービス機能は、高性能なホストに依存します。ただし、ホストに障害が発生すると、上記のサービスに影響が出ます。この問題の解決策は、高可用性アーキテクチャを構築することです。冗長性と HA はあらゆる段階で考慮する必要があります。これは、集中型アーキテクチャではほぼ最善の方法です。ただし、どのリンクに障害が発生した場合でも、グローバル サービスに影響が及びます。

このアーキテクチャのデータベースは、マスター/スレーブ冗長性を提供することで高可用性も実現し、HA サービスによって切り替えが自動的に管理されます。性能面では垂直拡張が採用されることが多いです。ただし、垂直方向の拡張には制限があります。最も強力なホストでも対処できない場合はどうなるでしょうか?

図1. 集中型アーキテクチャ

集中型アーキテクチャ データベースには例外があり、それが MPP データベースです。単一ノード データベースのパフォーマンス上限問題を解決するために、一部のデータベース ベンダーは MPP データベースを開発しました。このタイプのデータベースはクラスターと見なされ、データはこれらのクラスターのノード全体に分散され、データ クエリ サービスもこれらのノードにプッシュダウンできます。データと機能を分散することで、複数のノードの処理能力を最大限に活用できるようになり、まさに今日の分散コンピューティングの先駆けと言えます。

図2. 集中型MPPアーキテクチャ

図の調整ノード CN は特別なコンポーネントではなく、任意の DN にすることができます。ただし、このタイプの製品は OLAP を指向しており、大規模なクエリ問題を解決するように設計されており、現在の分散方向とは異なります。

2. サービス指向アーキテクチャ (SOA)

インターネットの波が到来し、分散アーキテクチャが台頭する以前は、単一マシンのパフォーマンスボトルネックとグローバルなサービス可用性の問題を解決するために、ビジネスを分割することが最初の解決策であり、つまりサービス指向アーキテクチャ (SOA) が適用され始めました。純粋な SOA は、実際には、アプリケーションのさまざまな機能単位 (サービスと呼ばれる) を分割し、明確に定義されたインターフェースとプロトコルを通じてそれらを接続するコンポーネント モデルです。 SOA アーキテクチャは一時期人気がありましたが、もちろん現在はマイクロサービス モデルの方が人気があります。

図3. SOAアーキテクチャ

当時、多くの銀行がこの考え方に従って基幹システムを分割し、大規模なシステムを複数の小さなシステムまたはコンポーネントに分割しました。利点は、サービス分割後にパフォーマンスがいくらか拡張されることです。パートと呼ばれる理由は、ホットであり分割できないコア サービスが常にいくつか存在するためです。その結果、システム コール チェーンがより複雑になり、異なるサービス間のデータ同期要件がより多く複雑になり、システムとサーバーの数が増加するという欠点があります。 SOA を導入しても、ホットスポット機能のパフォーマンスと可用性の問題は完全に解決されていません。

1. コア機能の水平展開が実現されておらず、個々の機能は依然として集中型アーキテクチャで展開されています。

2. 水平方向のデータ分割が実現できない場合、大量のデータの問題は解決できず、代わりに異なるシステム間のデータ同期に関する複雑な要件が生じます。

3. 分散アーキテクチャ

金融業界が依然としてシステム機能の分割と変革、そして新しい小型マシンへの予算の割り当てに忙しい一方で、中国のインターネット技術業界は大きな変化を遂げている。

ビッグデータ技術の発展：最初の大きな変化は、さまざまな分散型オープンソースソフトウェアが成熟し、十分に活用されるようになったことです。分散ストレージ、分散コンピューティング、分散メッセージング ミドルウェアがビッグ データ業界の変革をリードしています。これらの分散テクノロジーは、大量のデータ、高スループット、高可用性の問題を単純かつ大まかに解決します。これらの問題は、ビジネス システムやバックエンド データベースにも存在します。最終的な解決策はデータベースを分散することのようです。しかし、データベース業界のリーダーたちは、クラウド テクノロジーと同様に分散データベースを採用しませんでした。代わりに、彼らは多くのデータベーススタートアップに機会を与えました。

インターネット消費行動：もう一つの大きな変化は、インターネット業界がユーザーの消費行動を変えたことです。近年、ネットワーク事業者は速度の向上や料金の引き下げを進めており、インターネットモバイルデバイスの出荷台数は急増し、ユーザーの消費習慣もオフラインからオンラインへと大きくシフトしています。中国の人口ボーナスはインターネット業界で十分に活用されている。金融業界にとって、ユーザーの消費行動の変化は金融テクノロジーに課題をもたらします。取引量とデータ量は常に新たなピークに達しています。特に、オンライン バンキング、モバイル バンキング、その他のチャネル ビジネスでは、集中型アーキテクチャでパフォーマンスのボトルネックが発生します。

最も典型的な例はアリババです。アリババは2011年以降、コスト面を考慮してIOEを徐々に廃止し、毎年「ダブルイレブン」の成績表も発表している。高帥夫はミニコンピュータを PC に置き換え、Oracle データベースをオープンソースの MySQL データベースに置き換え、同時に自社開発の分散ミドルウェア TDDL を開発して水平展開を実現しました。アリババは、安価な PC を積み上げて大規模なダブル イレブン プロモーション事業をサポートし、最終的に取引量、最高値、金額の点で印象的な結果を達成しました。現在、Alibaba の分散ミドルウェアはリレーショナル データベース DRDS に発展しています。同時に、アリババは金融分野向けに完全に自社開発したカーネルを持つOceanBaseと、クラウドデータベースストレージとコンピューティング分離アーキテクチャに重点を置いたPolarDBも保有しています。

技術の自主性と管理：近年、国際関係全体の環境も変化しており、中国では技術の自主性と管理を求める声がますます大きくなっている。それに応じて、中国ではデータベース製品やサービスに重点を置く企業が数多く登場しています。特に分散データベース技術においては、国際的なデータベースリーダーがまだ十分な投資を行っていなかった時代に、多くの国内企業がオープンソースの分散技術ソリューションを借用し、独自の分散データベースを開発しました。書き写す宿題がなかったため、各自の宿題は非常に異なっていました。

まとめると、金融業界では、大量のデータ、高スループット、高可用性、そして独立した制御が緊急に求められています。社外的には、ビッグデータ分散技術ソリューションが認められています。インターネット業界ソリューションのリーダーシップと相まって、金融業界における優れた国内分散データベースに対する需要はますます高まっています。

2. 分散データベースはどのような開発段階を経てきましたか?

分散データベースは、大量のデータ、高スループット、高可用性の問題を解決し、データとコンピューティングのシャーディングを通じて水平方向のスケーラビリティを提供するように設計されています。しかし、アイデアは明確ですが、実装は複雑です。現在のいくつかの分散データベースの実装原理をよりよく理解するために、まずデータベースを解析層、コンピューティング層、ストレージ層の 3 つの層に分割します。分散実装は、これらのレイヤーの実装問題を解決するためのものです。分散データベースの開発は 3 つの段階に分けられます。

1. 読み取りと書き込みの分離

集中型アーキテクチャにおける単一ノードのコンピューティング パフォーマンス問題を解決するために、最初に登場したソリューションは、読み取りと書き込みの分離モードでした。当時、MySQL オープンソース データベースは非常に人気がありました。ただし、単一の MySQL ノードの処理パフォーマンスではボトルネックが発生する可能性が高くなります。 MySQL マスター スレーブ レプリケーション アーキテクチャでは、マスター データベースは読み取りおよび書き込み可能ですが、スレーブ データベースは読み取り専用にすることをお勧めします。したがって、SQL 解析層が読み取りと書き込みの分離を実現できれば、メイン データベースへの負荷が大幅に軽減されます。

図4. 読み取りと書き込みの分離アーキテクチャ

このアーキテクチャはしばらくの間人気がありました。この期間中、MySQL は急速に発展し、商用データベースの地位に挑戦し始めました。商用データベースのユーザーも、IBM、Oracle などに対して関連する要求を行っています。このアーキテクチャでは、各データ ノードのデータは完全です。クライアントまたはデータベース ミドルウェアは、データの一貫性を確保する方法、SQL 分離レベルを設計する方法、ロック問題を解決する方法など、SQL の読み取りおよび書き込み分散問題を解決する必要があります。

• 解析レイヤー

解析層では、読み取り/書き込み分散を実装する必要があります。

• 計算層

スレーブ データベースは読み取りトランザクションを受け入れることができるため、ある程度の負荷が軽減されます。

• ストレージ層

単一のノードにすべてのデータが含まれます。データの同期は、データベースのマスター/スレーブ レプリケーション テクノロジによって実現されます。

ストレージとコンピューティングを分離すると、分散ストレージを実現できます。このアーキテクチャにより、ストレージ層での圧力の問題もさらに解決できます。現在最も代表的なものは Alibaba Cloud の polardb です。

図5. Alibaba Cloud PolarDB分散ストレージ

Alibaba Cloud の polardb 実装は、単純な読み取りと書き込みの分離よりもはるかに豊富です。まず、これはハードウェアとソフトウェアが統合されたソリューションであるクラウドネイティブ データベースです。

• 解析レイヤー

読み取りと書き込みの分離と負荷分散を実現します。

• 計算層

単一ノードのパフォーマンスを垂直方向にスケールアウトし、読み取りパフォーマンスを水平方向にスケールアウトします。

• ストレージ層

分散ストレージでは、シャーディング方法はアプリケーションに対して透過的です。 FPGA や RDMA などのハードウェア テクノロジーを通じてパフォーマンスを高速化します。

個人的には、クラウド データベースが今後のトレンドであり、Alibaba PolarDB と Tencent TDSQL が輝くと考えています。

2. 分散ミドルウェアモード

読み取りと書き込みの分離は、依然として中国のインターネットの膨大なユーザーベースを満たすことができません。銀行には数千万、あるいは数億人のユーザーがおり、インターネットにはさらに多くのユーザーがいます。昇進があるたびに、運用・保守担当者は緊張します。読み取りと書き込みの分離だけでは、このタイプの集中化された同時パフォーマンスのボトルネックを解決することはできません。では、これらのユーザーのトランザクション データを異なるノードに分離して、これらのユーザーが対応するノードでのみデータを処理できるようにすることは可能ですか?これが、分散コンピューティングの現在の主流の考え方、つまりデータシャーディングです。

図6. データベースミドルウェア

図内の各シャードは、単なる物理ノードではなく、マスター/スレーブ データベースになることができます。

• 解析レイヤー

SQL 分散クエリと結果の集約を実装します。データ シャードの定義はこのレイヤーに保存する必要があります。ノード間の分散トランザクションのサポートは非​​常に弱いです。これは主に、分散ミドルウェアの製品機能に依存します。

• 計算層

基盤となるデータをシャーディングすることで、コンピューティング層は負荷の分離を完全に実現しました。

• ストレージ層

データシャーディング後、ストレージ層のパフォーマンス問題も完全に解決されます。

このアーキテクチャの代表的なものとしては、Alibaba のオリジナル データベース ミドルウェア製品である TDDL と、オープンソース データベース ミドルウェアである Mycat があります。 Alibaba の TDDL データベース ミドルウェアは、現在の DRDS クラスターに進化しました。

まず、Mycat のソリューションを見てみましょう。

図 7. Mycat データベース ミドルウェア

Mycat データベース ミドルウェアは、アプリケーションと基盤となるデータベースの間に構築されます。アプリケーション SQL は解析され、変換され、基盤となる複数のデータベース マスター クラスターとスタンバイ クラスターにルーティングされます。このソリューションでは、基盤となるデータベースを変更する必要はありません。ただし、複雑な SQL をサポートする機能は限られています。このアーキテクチャを使用する場合は、分散トランザクションを避けてください。

Alibaba Cloud の DRDS ソリューションを見てみましょう。 DRDS はミドルウェア モデルですが、現在リリースされているソリューションは、完全な分散クラスター データベースに似ています。 DRDS は分散ミドルウェアであり、その基盤となるレイヤーは RDS データベース クラスター (MySQL) です。 RDS データベース サービスは、Alibaba Cloud が提供するリレーショナル データベース サービス (主に MySQL) の総称です。 DRDS は、2 フェーズ コミットを通じて分散トランザクションを実装します。

図8. Alibaba Cloud DRDS

分散トランザクションがある場合、このアーキテクチャではアプリケーション レベルで解決するのが最適です。この点で最も優れた銀行は中国招商銀行だと思います。招商銀行は当初から、分散トランザクションとシャーディングの役割をビジネス アプリケーション開発レベルに置いていたため、シャーディングを実装するために基盤となるデータベースに依存する必要はありませんでした。

3. 分散クラスタモード

ミドルウェア モデルは実際にはデータベース エンジンから分離されています。分散ミドルウェアは、ミドルウェアと基盤となるデータベースを組み合わせて製品として開発・利用する場合、これが現在の分散クラスタデータベースになります。国内各社による分散データベースの実装を観察し、基本的には以下の図にまとめました。

図9. 分散データベースクラスター

調整ノード: これは、ユーザー要求を受け入れてデータを返す、分散データベース内の処理ノードです。通常、マルチアクティブ モードで複数の物理ノードに展開されます。調整ノード間のトランザクション制御は、グローバル管理ノードに要求することで、グローバルトランザクション情報やロック情報を取得します。コーディネーションノードの SQL がコンパイルされ、実行されて、対応するデータノードが呼び出されます。

データノード: データが実際に保存される場所。コーディネーション ノードからインポートされたデータは、シャーディングまたはレプリケーションを通じてデータ ノードに保存されます。通常、データ ノードは、調整ノードからの呼び出しに応答するだけで済みます。データ ノードは、1 つのマスターと複数のバックアップ モデルを通じてデータの可用性を向上させます。スタンバイ ノードは通常、読み取りサービスを提供しません。

グローバル管理ノード: 分散データベースの中核であり、分散ミドルウェア ソリューションと区別する重要なコンポーネントです。グローバル管理ノードは、グローバル トランザクション制御、メタデータ管理などに使用されます。グローバル制御を必要とするこれらの機能は、展開のために複数のコンポーネントに分割される場合があります。これは、異なる分散データベース クラスター間の基本的な違いでもあります。

クラスター管理ノード: データベース クラスターの高可用性を保証します。さまざまなデータベース コンポーネントの状態をグローバルに監視し、状態の変化に基づいて自動的に応答するために使用されます。クラスタ管理ノードは、クラスタ全体のコンポーネントの切り替えとメンテナンスを制御します。

上記の論理ノードは、データセンターの概念に加えて、物理ノード上に混在して展開できます。クラスターを複数のセンターに展開して、データセンター レベルの災害復旧を実現できます。現在、中国で有名な分散データベースには、gaussT、TIDB、glodendb、sequoiadb、antdb などがあり、これらはすべてこのタイプのアーキテクチャを備えています。典型的な国内データの事例を2つ見てみましょう。ほとんどの分散データベース ソリューションとは異なり、データベース エンジンは MySQL に基づいていません。

1つ目は、Huawei の Gaussian データベース gaussT です。

図10. Huawei gaussTデータベース

これは Huawei の公式 Gaussian データベースです。このうち、ETCD と CM はクラスタ マネージャであり、クラスタ全体を選択および操作するために使用されます。その中で、ETCD はクラスターの全体的なステータス情報を保存し、Paxos プロトコルに基づいて可用性を確保します。 CN は、ユーザー要求を受け入れ、データと SQL の配布と集約を担当する調整ノードです。 CN はマルチアクティブであり、クライアントは負荷分散モードを通じて CN に接続します。 GTS は、トランザクション番号の要求のみを処理するグローバルトランザクション管理ノードであり、キャッシュ機構を備えているため、処理性能が比較的高いです。 DN はデータ ノードであり、1 つのマスターと複数のスタンバイ モードにより高い可用性が保証されます。クラスター内にテーブルを作成する方法は 2 つあります。 1 つは、選択した分散キーを使用してシャード データ テーブルを作成することであり、もう 1 つは、グローバル同期レプリケーションを使用して複製されたテーブルを作成することです。 Gaussian データベースのアーキテクチャは、従来の典型的なリレーショナル データベースのアップグレード バージョンです。分散トランザクションを完全にサポートし、クラスターをユーザー フレンドリな方法でデータベースとして使用します。

分散データベースについて話すとき、TIDB についても言及する必要があります。 TIDB は、PingCAP によって開始されたオープン ソースの分散データベースです。分散データベース メーカーのグループの中で、TIDB は異端者です。異なるアプローチを採用し、高度なデータベース アーキテクチャと優れたオープン ソース エコシステムに重点を置いています。

図11. TIDBデータベース

TIDB アーキテクチャ図では、TiDB クラスターはリクエストを受信し、SQL の解析と転送に使用される調整ノードです。 TiKV はデータを保存するデータ ノードです。他の分散データベースとは異なり、TIDB は分散 KV ストレージ エンジンを使用します。 TIDB のデータ分散は、パーティション キー シャーディング ルールを指定する必要がある他の分散データベースとも異なります。リージョン レベルに基づいてラフト レプリケーションを実装し、負荷状況に応じてマージおよび分割することもできます。この機能は他の分散データベースでは利用できません。 PD クラスターは、グローバル トランザクション マネージャーに相当します。図ではクラスター マネージャーはマークされていませんが、実際には各クラスターには対応するクラスター サービスがあります。

3つの分散ソリューションがほぼ完全に導入されました。最後に、ZTE Goldendbを見てみましょう。

図12. GoldenDBの3つのデプロイメントモード

ZTE Goldendb は 3 つの展開モードすべてを統合します。 No-Sharding は、1 つのマスターと複数のバックアップを備えた単一マシンのデプロイメントであり、読み取りと書き込みを分離した負荷ソリューションを提供します。シャーディング クラスターはミドルウェアの展開モードであり、コンピューティング ノードは転送に使用され、分散トランザクションはサポートされません。分散トランザクション クラスターは、分散トランザクションをサポートするために GTM グローバル トランザクション マネージャーを追加します。

4. 分散データベーステストの経験

数多くの分散データベース アーキテクチャを導入した後、多くの企業のデータベース製品もテストしました。分散プロセスのテストにおける銀行の経験の一部を以下に示します。

1. 単一ポイントデータの追加、削除、変更、およびクエリについては、いずれも非常に優れたパフォーマンスを発揮しますが、最終的なボトルネックが発生するのは通常、グローバルトランザクション管理のリンクです。したがって、この部分でのパフォーマンスの違いは、このグローバル トランザクションの処理にあります。これにより、分散データベースのパフォーマンス上限も決まります。

2. ノード間のデータアクセスを必要とする分散トランザクションの場合、すべてのパフォーマンスはあまり良くありません。実際、分散トランザクションは分散データベースにとって依然として大きな課題となっています。分散データベースを使用する企業では、分散トランザクションを減らし、分散データベースを混合負荷として使用しないことが推奨されます。特に、異なる分散キーを持つ大きなテーブルがリンクされている場合、調整ノードを停止するには数分しかかかりません。この部分のテクノロジーは、データ ウェアハウスの MPP データベースに適しています。 MPP データベースのこの機能が分散データベースに統合されると、この分散データベースは非常に強力になり、HTAP を簡単に処理できるようになります。

3. 分散データベースを使用する場合は、分散キーに注意する必要があります。シャーディングにしろレプリケーションにしろ、ビジネス開発者は独自のビジネスロジックに基づいて開発し、合理的に設定する必要があります。誤った選択をすると、分散データベースのパフォーマンスは単一ノードよりも低下します。

4. 分散データベースにおけるデータの再配分、つまり水平方向の拡張は問題点です。基本的に、すべての分散データベースには、操作方法とパフォーマンスへの影響の両方の点で問題があります。おそらく、自動的に分散され、スケーラブルなストレージ エンジンを使用することが究極の解決策です。

5. 分散データベース クラスターには多くのコンポーネントがあり、管理が比較的複雑です。各コンポーネントには独自のログがあり、パフォーマンスのボトルネックが発生する可能性があります。分散データベース環境では、運用および保守コストが比較的高くなります。

3. 従来のデータベース運用および保守の職務はどのような課題に直面していますか?

分散データベースの適用により、従来のデータベースのパフォーマンス拡張の問題が解決されますが、運用および保守担当者にとっての課題も生じます。これまでは、従来のデータベースを運用および保守し、パラメータ ルールを設定し、緊急時の保護を提供するには、一連の標準があれば十分でした。現在、分散データベースが存在します。これは単なる新しいデータベース製品ではなく、データベースを使用する新しい方法です。

1. 分散データベース管理にはどのような利点がありますか?

統合データ ビュー: 分散データベース データが分割された後、運用および保守担当者はデータの観点の問題を解決する必要があります。どのテーブルがシャード テーブルで、どのテーブルがレプリケート テーブルですか?データを他のシステムにエクスポートまたは同期する必要がある場合、このソリューションをどのように実装すればよいでしょうか?テーブルはいくつの部分に分かれており、合計データ量はどれくらいですか?成熟した分散データベース製品を選択した場合は、これらの部分に対して製品レベルのソリューションが存在します。ミドルウェア型の配布はさらに困難です。ユーザーにとっては、クラスター内のデータをデータベースとして操作できれば理想的です。

多数のノードの管理: 分散を選択することは、水平拡張を選択することを意味します。対応する運用および保守ノードの数も爆発的に増加します。運用・保守能力が一気に向上しました。幸いなことに、使用する必要がある分散システムはそれほど多くありません。現在、これらのノードは個別に監視および管理する必要があるだけでなく、ノードの役割も適切に管理する必要があります。

容量管理: ここでの容量管理には、パフォーマンスとデータという 2 つの側面が含まれます。分散環境では、負荷分散の問題に注意する必要があります。なぜなら、基本的に、ディストリビューションはパフォーマンス負荷を解決するために作成されたからです。運用および保守担当者は、負荷がバランスが取れていて期待どおりであるかどうかを検出する必要があります。問題がある場合は、データ分布とビジネス行動の観点から分析する必要があります。これは比較的複雑で困難です。一方、分散データベースで最も恐れられる問題はデータの偏りです。重大なデータ スキューは、パフォーマンスのボトルネックや容量のボトルネックにつながる可能性があります。偏りが発生した後にデータをどのように再分配するかも難しい問題です。

データの一貫性: 分散データベースのデータの一貫性はユーザーによって無視される可能性があります。この問題は集中型データベースではほとんど発生しないからです。ただし、分散データベースにおける分散トランザクションは、基本的に 2 フェーズ コミット アプローチを通じて実装されます。問題が発生した場合、提出の残りが発生する可能性があります。したがって、ユーザーはデータベース内に 2 フェーズ コミットの残りがあるかどうかを定期的に確認し、データを定期的に比較する必要があります。

変更管理: 分散環境における変更の問題も真剣に受け止める必要があります。ノードの数が増え、データベースが分割されると、変更にもグローバルおよび単一ポイントのディメンションが含まれるようになります。クラスター内のすべてのマシンが漏れなく完了するように、統一された変更を行うにはどうすればよいでしょうか?すべてのノードが変更されていますか?異なるパラメータを持つノードを、時間指定のパラメータ比較やその他の方法でプロンプトできますか?

災害復旧計画: 分散データベースの災害復旧計画をどのように実装するか? 3 つのセンターを 2 つの場所に実装するにはどうすればよいでしょうか?異種データベースのデータ同期ソリューションは何ですか?データ移行ソリューションについてはどうでしょうか?単一ノード データベースの場合に使用できる、成熟した実績のあるソリューションは数多くあります。しかし、分散型の環境においては、メーカーとともに成長しているとしか言いようがありません。

マルチテナント管理: マルチテナント管理は、分散データベース環境で解決する必要がある重要な機能です。運用保守担当者は、対応する製品ソリューションを使用し、運用保守プロセス中にテナントの容量とパフォーマンスの要件に注意し、それに応じてデータベースを調整する必要があります。

2. 分散データベースの管理方法

分散データベースは新しい技術であり、成熟した商用データベースから派生したものではないため、まだ未完成な部分が多く残っています。特に金融業界のユーザーは、従来の商用データベースに「甘やかされて」きました。新しいデータベースに初めて触れたとき、彼らはどこでも壁にぶつかっているように感じます。しかし、たとえ硬い骨であっても、噛まなければなりません。

制御アプリケーションシナリオ:

分散は万能薬ではありません。特殊なシナリオ向けのデータベース製品です。適格な取引のみを上方移行できます。面倒なことをしたくない場合は、分散データベースを気にする必要はありません。これには、運用担当者が製品を確認するだけでなく、ビジネス担当者や開発者と緊密に連携することが求められます。データベースは、ビジネス シャーディングの観点から管理する必要があります。したがって、分散データベースを使用する場合は、使用シナリオ仕様を定義する必要があります。

統合管理プラットフォーム:

分散データベース データが分割された後、運用および保守担当者は、全体的なデータ計画、データ分割ルール、レプリケーション ソリューション、同期ソリューションなどについて理解する必要があります。分散データベース クラスターのユーザーにとっては、これらの製品には対応する製品レベルのソリューションが用意されている可能性があるため、理解が容易になる可能性があります。分散ミドルウェアを使用するユーザーは、データ テーブル間の関係をいつでもクエリおよびピボットするにはどうすればよいでしょうか。これには別の解決策が必要です。方法に関係なく、これらは分散データベースの運用と保守において適切に実行する必要があることです。

そのため、運用・保守担当者はデータ管理プラットフォームを確立する必要があります。プラットフォーム上の分散データベース クラスターのステータスを表示および操作し、データベース ユーザー、権限、配布ルール、構成の配布、構成の比較、ログの表示、分析などの管理機能を管理します。マルチテナント管理も含まれるとベストです。

インテリジェント監視プラットフォーム:

分散データベースを導入した後、運用・保守担当者は分散データベースノードの状態と各ノードのパフォーマンスを監視する必要があります。解決すべき最初の問題は、新しいデータベースを監視およびアラーム プラットフォームに接続することです。もともとスタンドアロン データベースに適用可能なすべての監視機能は、クラスター データベースに適合させる必要があります。さらに一歩進んで、運用および保守担当者も、分散データベースの精密な監視を実現するために、インテリジェントな運用と保守に頼る必要があります。インテリジェント監視プラットフォームでは、分散データベースの不均衡な負荷や異常なノードの動作などの問題を分析して検出し、障害の影響チェーンをインテリジェントに表示する必要があります。インテリジェント監視プラットフォームは、パフォーマンスと容量の傾向分析と予測を実行し、パフォーマンスと容量の警告を事前に発行することもできます。

キャパシティ管理:

このトピックは非常に重要なので、別途リストされています。データ スキューと負荷スキューの問題を監視する方法が必要であり、管理プラットフォームに負荷再配分機能とデータ再配分機能を実装する必要があります。分散データベースでサポートされるデータ シャーディング方法には、一般にハッシュ、範囲、リストの 3 つがあります。データ スキューが発生した場合、運用および保守担当者はスキューの原因を確認し、いくつかの既存の方法を使用してデータを分割し続ける必要があります。したがって、キャパシティ管理の観点では、運用および保守担当者は、ビジネスおよび開発担当者と緊密にコミュニケーションを取り、データのビジネス情報を理解し、ビジネスの成長予測を取得して、適切なパフォーマンスとキャパシティ計画を作成する必要があります。

変更リリース:

データベース パラメータの変更は、統合管理プラットフォームを通じて実行できます。ただし、管理プラットフォームに統合機能がない場合、コンテンツの変更は自動公開プラットフォームを利用して行う必要があります。特に、複数のデータ センターの災害復旧の場合、人為的な変更は見逃されやすくなります。 DevOps プラットフォームを起動し、分散データベースへの変更をプラットフォームに統合するのが最適です。

これらの管理プラットフォームとツールを確立することにより、データベースの操作とメンテナンス担当者は、さまざまな問題を解決するのに忙しく、データアーキテクトに成長するというジレンマから解放できます。 DBAはビジネスシナリオと接続し、適切なデータベーステクノロジーを選択し、標準化された自動化された展開およびメンテナンス方法に基づいて安定したビジネスオペレーションを確保します。

4.データベースとデータベース操作は将来どこに進みますか？

私たちは、データベーステクノロジーの爆発の時代になっています。近年、NOSQLデータベース、NewsQLデータベース、時系列データベース、グラフデータベース、分散データベース、ハイパーコンバージドデータベースに関連するテクノロジーが栄え、国内のデータベースも強く開発されています。では、次世代の主流データベースはどのようになりますか？将来の運用およびメンテナンスモデルでどのような変更が発生しますか？

クラウドデータベース：近年、クラウドへの移行システムがホットトピックになっています。大手企業は、独自のクラウドデータベースも立ち上げました。クラウドデータベースは将来の傾向になります。データベースサービスは、出力をさらに標準化します。プライベートクラウドであろうとパブリッククラウドであろうと、ユーザーがデータベースを使用する方法が変化しています。分散データベースとハイパーコンバージドデータベースの強力なパフォーマンスは、クラウド環境でのマルチテナント使用にも適しています。

サブセグメント：データベースアプリケーション領域はますますセグメント化されます。たぶん今、私たちはまだHTAPシナリオに使用できるオールラウンドのデータベースを持っていることを望んでいますが、将来のデータベース関数はより差別化されます。特に、データベースクラウドを介して、さまざまな機能を備えたデータベースを簡単に適用して、さまざまなビジネスシナリオを解決できます。

インテリジェントな操作とメンテナンス：データベースがクラウドの展開とクラウドサービスを提供するため、データベースの操作とメンテナンスはインテリジェントな操作とメンテナンスに移行する必要があります。機械学習インテリジェントアルゴリズムを使用して、システムの動作ステータスを監視し、データパフォーマンスに基づいて意思決定、自動修理、自動拡張を提供します。

最後に、ユーザーがクラウドデータベースを適用するシナリオを想像してください。しばらくの間実行されていた後、インテリジェントな操作とメンテナンスロボットは、最近データベースに何が起こったのか、自動チューニングが発生した回数、自動修理が発生した回数など、合計の時間が節約されていることをユーザーに伝えます。ユーザーの使用シナリオに基づいて、ユーザーが容量を拡大するか、より適切なデータベースサービスを購入することをお勧めします。

上記は、近い将来に起こると思う変更です。どう思いますか？

【著者】Kong Zaihua、IBM認定シニアDBA、SAP認定ベースは、データベース環境の問題の診断とパフォーマンスの調整において豊富な経験があります。私たちは、同じ都市、クラスター、マルチパーティション、分散型、その他のプロジェクトでアクティブアクティブデータベースを実装する豊富な経験を持っています。彼は現在、中国Minsheng銀行のテクノロジー部門で働いており、同じ都市でのデータベースアクティブアクティブアーキテクチャ、データベース分散アーキテクチャ、およびデータベースのインテリジェントな操作とメンテナンス（AIOPS）の建設に焦点を当てています。彼は、運用とメンテナンスの分野でAIテクノロジーを適用する方法に革新に強い関心と熱意を持っています。