JD Cloud Director が分散コンピューティングの本質を説明します (ビデオを含む)

[[264940]]

1953 年、エブ・グロッシュは、コンピュータのパフォーマンスはコストの 2 乗に比例して増加するという「グロッシュの法則」を提唱しました。 1965 年、ゴードン・ムーアは「価格が変わらない場合、集積回路に収容できるコンポーネントの数はおよそ 18 ～ 24 か月ごとに 2 倍になる」という「ムーアの法則」を提唱しました。

今日では、コンピュータの普及により、アイドル状態のコンピュータがますます増えており、電源がオンになっている場合でも、CPU の潜在能力が完全に活用されているとは言い難い状況になっています。インターネットの出現により、アイドル状態のコンピューティング リソースを使用してコンピュータ システムに接続し、呼び出すことが可能になりました。

その結果、分散コンピューティングが普及しました。分散コンピューティングを学ぶのは難しいですか?難しいですね！したがって、私たちを指導してくれる有名な教師がもっと必要です!以下のコースは、JD Cloud のシニア ディレクターが指導します。ぜひ読んでみてください！

このライブ コースは、JD Cloud シニア ディレクターの Guo Lijing が指導します。データベースの基礎から実践的な応用まで、スタンドアロンデータベースから分散データベースまでの技術の発展と反復を深く分析します。同時に、理論と実践を組み合わせて、企業がデータベース サービスを選択するための黄金律と、この点に関する JD Cloud のアプリケーション プラクティスをすべての人に伝えます。

コース概要

このコースで共有される内容は、データベース サービスの進化に関するもので、スタンドアロンから分散への変化がどこから来たのか、分散データベース サービスを実現するためにスタンドアロン データベースをどのように改善するかに重点が置かれています。

以下は Guo Lijing 氏が共有したすべてのコンテンツです。すべての開発者にとってさらなる助けとなることを願っています。

スタンドアロンから分散型へ、データベースサービスの進化

JD Cloud シニアディレクター、Guo Lijing 氏

1 Redis から MongoDB へ

RedisからMongoDBまで、最初の世代はシンプルだった

多くの場合、テクノロジーや製品も最初は非常にシンプルなアイデアから生まれます。たとえば、2019 年の DB エンジン ランキングには、MongoDB と Redis という 2 つのよく知られた名前が登場しました。

興味深いことに、MongoDB は DocumentDB に属しています。 DocumentDB-Engines Ranking を振り返ってみると、MongoDB が 1 位にランクされており、2 位から 10 位を圧倒的に上回っていることがわかります (2 位はわずか 56 ポイントです)。 DB エンジン全体では、Oracle と MySQL のスコアは非常に近いです。しかし、DocumentDB では、MongoDB は 400 ポイント以上を獲得していますが、2 位でも 100 ポイント以上しか獲得していない可能性があります。

同様に、Redis は K/V フィールドでも 146 ポイントという非常に高いスコアを獲得しました。 3 位は MemcacheD (2 位は 56 ポイントの Amazon DynamoDB) で、獲得ポイントはわずか 28.7 ポイントでした。

したがって、これら 2 つのデータベースは、それぞれの専門分野で非常に高い評価を受けていますが、登場してからまだ 10 年も経っていません。Redis は MongoDB よりも早い 2009 年に登場し、MongoDB も 2009 年頃に登場しました。

なぜ Redis が登場し、K/VDB でトップクラスのデータベースになったのでしょうか?

実際、Redis が登場する以前にも、2003 年にリリースされた Memcached と呼ばれる K/V データベースがすでに存在していました。このバージョンは元々 Perl で書かれていましたが、後に C 言語で書き直されました。 Redis が登場する前は、Memcached が常に K/V データベースのリーダーでした。 2009 年に登場した Redis が、なぜすぐに Memcached に取って代わったのでしょうか?現在でも、ほとんどのキャッシュには Redis を使用しています。業界に入ったばかりの学生でさえ、Memcached のようなデータベースについて聞いたことがありません。このプロセスで Redis は具体的に何を行うのでしょうか?

問題は比較的単純です。設計の観点から、元の Memcached ストレージ構造が変更されました。以前は、キーは文字列に対応していましたが、Redis は文字列を構造化ストレージに変更しました。つまり、Redis はリスト、ソートされたセット、ハッシュなど、いくつかの構造化データをサポートできます。

なぜこのような小さな変更が、これほど大きな利点をもたらすのでしょうか?このためには、やはり Memcached に戻る必要があります。

Memcached と同じ設計目標を持つキャッシュ システムを独自に設計し、その過程でキー文字列キャッシュ システムを設計する必要があるとします。では、このキャッシュ システムではどのようなサービスを提供できるのでしょうか?さらに、ストレージ オブジェクトが String の場合、どのような操作を実行できますか?

C++ や Java などのプログラミング言語では、文字列を設定したり、文字列を取得したり、もちろん文字列を削除したりできることが想像できます。さらに、文字列に対して、追加、先頭への追加など、文字列の末尾と先頭にコンテンツを追加したり、文字列全体を置き換えたりするなどの他の操作を実行することもできます。もちろん、挿入、消去、トリム、検索、置換などの操作も実行できます。

設計プロセス中に、Memcached が insert、find、substr などの操作をサポートしない理由についても考えたほうがよいでしょう。

これは実は非常に興味深いトピックです。理論的には、Memcached はこれらの操作をサポートできます (Memcached ソース コードを変更した後のこれらの関数と呼び出しのサポートを含む)。ただし、サポートしない理由は、効率性を考慮したためである可能性があります。

たとえば、Memcached で substr または find 操作をサポートするプロセスでは、Memcached サーバーのパフォーマンスが浪費されます。 find は文字列全体をローカルマシンに転送してから検索を実行できるため、substr についても同様です。実際のところ、すべてはパフォーマンスにかかっています。

もちろん、Memcached は、add やいくつかの gets 操作などのより高度な操作も提供し、incr/decr、つまり数値のアトミック加算と減算も実行できます。 Memcached のリリース履歴全体を調べてみると、2003 年にリリースされたバージョンであることがわかります。初期のサポート作業は非常に限られていたため、その後の高度な機能は徐々に追加されました。

Redis を見てみましょう。文字列、リスト、セット、ソートされたセット、ハッシュ、ビット配列、HyperLogLog、ストリームなど、多くのデータ構造をサポートします。 Streams は 5.0 であり、最新バージョンでは一部の時系列データもサポートできます。

反復プロセス全体を通して、Redis の当初のシンプルなアイデアは、文字列のより多くの構造とストレージ構造をサポートできるかどうかを確認することでした。このアイデアから始まり、徐々に、より多くのデータ構造とより多くの操作タイプをサポートする状況へと発展していきます。

C++ を例にとると、リスト操作はポップ/プッシュをサポートし、リストの途中への挿入/消去もサポートできます。 Redisについては、一般的な操作に加えて、Redisの全体的なリリース履歴を調べました。当初は、pop/push などの比較的単純な操作もサポートされていました。時間が経つにつれて、共通の操作に基づいたより高度な機能がサポートされるようになりました。

たとえば、BRPOPLPUSH 関数は、リストからデータを POP し、別のリストに挿入します。これは比較的高度な機能ですが、ユーザーがこのシナリオが必要であることに気付いた後にも追加されます。

MongoDB について調べてみましょう。 MongoDB の「動作」は、実際には Redis と多少似ています。 Redis は K/V 構造を使用して、文字列を JSON に似た型に置き換えていると考えられます。 JSON は幅広いデータ構造もサポートします。

MongoDB によって実現される機能は非常に似ています。以前は、データベースを設計する際に、リレーショナル データベースの場合は、最初にスキーマを設計してから DDL 操作を実行する必要がありました。列を追加または削減する必要がある場合、上記の操作はあまり便利ではありません。特にフォームが非常に大きい場合、操作には長い時間がかかります。

ビジネスが発展するにつれて、プロトタイプの MySQL スキーマを JSON に置き換えることは可能でしょうか?このシンプルなアイデアに基づいて、MySQL やリレーショナル データベースは依然としてスキーマを中心にしていますが、MongoDB はドキュメント、つまり JSON 形式をコアとして使用して、データベース全体の機能とエコロジーを構築します。

ご覧のとおり、MySQL の一般的な SQL ステートメントの長さは MongoDB では異なります。これは、すべてのコマンドが JSON 形式に関連しており、基盤となるストレージ構造も JSON 形式で保存する必要があるため大幅に変更されるためです。

このセクションで私が表現したいのは、多くのデータベースや技術製品の進化には、実際には追跡可能なスレッドがあり、それは主に問題を解決するという目標を設定し、次に基礎となるデータ構造の変更を完了することであるということです。基礎構造が決まると、製品の機能にもある程度影響します。たとえば、MongoDB は長い間トランザクションをサポートしていませんでした。これは、サポートしようとしなかったからではなく、基礎となるストレージ構造のストレージ エンジンがトランザクションをサポートできなかったためです。

同様に、Memcached と Redis のメモリ管理設計を調べると、Memcached の開発者やコミュニティも Redis と同じ機能をサポートしたいと考えていることがわかりますが、実際には、基盤となるストレージ構造ではそのようなサービスを提供できない運命にあります。

2配布元はどこでしょうか?

分散コンピューティングはなぜ存在するのでしょうか?これは主に、私たちが情報爆発の時代に生きているからです。業務量が増大するにつれて、単一マシンのデータベースではニーズを満たすことができなくなり、当然ながら実行可能なソリューションを見つける必要があります。

ここでの解決策は 2 つのタイプに分けられます。 1 つのタイプは表面ソリューションに相当し、操作が比較的簡単です。これには、クライアント ソリューションと、プロキシ ソリューションなどの統合プロキシ ソリューションが含まれます。

対照的に、基礎となるソリューションは 3 つのカテゴリに分けることができます。最初のカテゴリは分散ブロック ストレージ ソリューション、2 番目のカテゴリはコンピューティングとストレージを分離するソリューション、3 番目のカテゴリはゼロから始めるソリューションです。

まず、クライアント ソリューションは、より明確なソリューションのアイデアを持つ TDDL という友好的な企業のオープン ソース プロジェクトによって表すことができます。分散システムを独自に構築し、分散ソリューションをクライアントに組み込む必要がある場合、最も重要なことは、SQL ステートメントをその背後でどのデータベースにリンクする必要があるかをクライアントに「伝える」ことです。結局のところ、異なるデータが異なるマシンに保存されるからです。クライアント ソリューションの場合、より重要なのは、バックエンドとの接続と SQL ステートメントを解析する方法です。

2 番目のソリューションはプロキシ ソリューションです。プロキシ ソリューションはクライアント ソリューションよりも開発が少し難しいですが、アイデアは非常に一貫しています。たとえば、ユーザー テーブルの場合、ユーザー テーブルのコンポーネントは ID です。 IDの分散キーを配布します。特定のユーザー ID を照会する場合、実際にはプロキシが存在します。クエリのユーザー ID が 0 の場合、バックグラウンドに 0 が存在する MySQL がわかります。

したがって、プロキシの場合、特定の SQL ステートメントを解析することが非常に重要です。このプロセスでは、識別を完了するための独自のルートが必要です。

クライアント ソリューションとプロキシ ソリューションの違いは何ですか?違いは、クライアント ソリューションの開発が比較的簡単であることです。 JDBC の場合、またはクライアントからの呼び出しが必要な場合、クライアントは SQL 文を解析する必要がなく、ガイダンスを簡単に完了できます。

プロキシ ソリューションは、元の MySQL プロトコルと互換性がある必要があります。 MySQL 接続を確立し、バックエンドとの接続を維持するのは非常に困難です。しかし、相対的に言えば、プロキシ ソリューションにはより多くの制限があります。クライアント サーフェス ソリューションであっても、プロキシ サーフェス ソリューションであっても、SQL の使用に対する要件は比較的高くなります。たとえば、一部の結合はサポートが難しく、ビジネス側との合意が必要になります。

さらに、クライアント ソリューションであってもプロキシ ソリューションであっても、全体的なアーキテクチャは比較的似ています。たとえば、プロキシ ソリューションには、フロントエンドがクライアントと接続する方法とバックエンド接続、さらに実際に MySQL サービスを提供するバックエンドとの接続を維持する方法が含まれます。これには 2 つの接続の管理が含まれます。

理解すると、ルーティング情報はプロキシ自体に保存されるため、プロキシ全体の一般的な設計はステートレスになります。しかし、ルーティングに関しては、制御を分散および変更するための相対的なルーティング管理センターが必要です。業界のほとんどのプロキシ設計では、プロキシ ソリューションのアーキテクチャ設計は非常に似ており、唯一の違いはエンジニアリングの品質にあります。

さらに、プロキシ ソリューションの欠点は、分散トランザクションの順序を保証できないことです。通常、分散状況では、各ノード上のトランザクションが想定どおりの順序で実行されることを保証するのは困難です。

表面的な解決策について話した後は、より深い根本的な解決策についても話し合う必要があります。表面的には、クライアント ソリューションであろうとプロキシ ソリューションであろうと、基盤となる MySQL の全体的なプロトコルは変更されず、データベースのネイティブ サービスも変更されません。基礎となる MySQL コードはまったく変更されていないと考えられます。

現在知られている基本的なソリューションは主に 3 つあります。 1 つ目は、SAN ソリューションを含むブロック ストレージ ソリューションです。クラウド関連のものはクラウド ハードディスク ソリューションで、すべて同じタイプです。

しかし、本当にデータベース ソリューションを作りたい場合、コンピューティングとストレージを分離するのが現在の主流の考え方です。コンピューティングとストレージが分離されているのはなぜですか?主な理由は、現在のネットワーク遅延が減少し、帯域幅が増加していることです。私の個人的な仕事経験からすると、将来的にはネットワーク帯域幅がさらに大きくなる可能性があります。しかし同時に、ディスク IO のスループットはネットワークほど速くは増加していません。

さらに、ストレージ仮想化はコストの削減に役立ち、分散ストレージは IOPS の向上に役立ちます。マシン上で RAID を実行すると、単一のハードディスクよりもパフォーマンスが大幅に向上します。分散システムを使用して書き込む場合、IOPS は実際には高くなります。

業界にはコンピューティングとストレージを分離するためのよく知られたソリューションがいくつかあり、その中で最も有名なのは Amazon の Aurora です。

Aurora がコンピューティングとストレージを分離することを選択したのはなぜですか?これに関しては、当時の Amazon の RDS ソリューションがどのようなものであったかを調べる必要があります。 Amazon RDS は同社のリアルティナル データベース サービスであり、すべてのデータはローカル ディスク/EBS に保存されます。

IO 書き込みチェーン全体が比較的長いことがわかります。データ、バイナリログ、および redo ログをディスクに書き込む必要があり、バイナリログ全体を両側で同期する必要があります。最後に、EBS データをクラウド ストレージに適切にバックアップする必要があります。 (これは単なるバックアップであり、リアルタイムの書き込みとは関係ありません)。

リンクが比較的長く、EBS 実装全体が含まれるため、EBS は分散高速ストレージであり、本質的にはマルチコピーです。複数のコピーがある場合、EBS もデータ全体をリモートで同期する必要があるため、それに応じてストレージとコンピューティングを分離できるかどうかを検討するのが Aurora の設計目標です。出発点は、データベース ストレージ エンジンを分散ブロック ストレージと統合して新しいストレージ エンジンを形成できるかどうかです。

もう 1 つのソリューションは、F1/Spanner ソリューションです。そのアイデアは何ですか?

分散システムを作る際に、MySQL と互換性を持たせるのが面倒であれば、最初から新しい分散システムを作ることは可能でしょうか？

アイデアは非常にシンプルで、いくつかの SQL を書き直すことです。したがって、F1/Spanner が一部の MySQL プロトコルと互換性がない場合は、SQL をいくつかの K/V 操作構造に分解する新しい分散トランザクション管理が導入されます。このソリューションでは、SQL の互換性は長く時間のかかるプロセスであり、既存のエコシステムとの互換性を保つのがさらに困難になります。しかし、新しいビジネスであれば、この分散ソリューションを使用しても問題はありません。独自の成熟した SQL を持つ古いビジネスの場合、それを使用することはさらに困難になります。

MySQL サービスは実際には 2 つの部分で構成されており、1 つはサーバー、もう 1 つはストレージであることがわかります。ストレージの標準アーキテクチャは、InnoDB の構造である REDO ログとデータです。現在、InnoDB は MySQL の標準となり、誰もがこのやり方で実行しています。

マスターとスレーブの同期に関しては、バイナリログをスレーブ側にコピーするためにバイナリログレプリケーションが使用されます。スレーブはバイナリログを再生し、スレーブは完全なデータを取得します。これは従来のデータベース構成モデルです。

MySQL のデータフローはどのようなものですか?まず、トランザクションまたは SQL ステートメントの場合、大量の REDO ログが書き込まれます。 2 番目のステップでは、データが binlog に書き込まれ、その後半同期されてスレーブに同期され、メッセージが返されます。この時点で、全体のコミットを実行できます。

マスターとスレーブが全体的な binlog レプリケーション方式を使用する、データ フロー全体の概略図。分散システムを構築したい場合、同じ分散システムに同じデータを置くことができないという出発点から始めるとしたら、何をする必要がありますか?

コンピューティングとストレージが分離され、すべてのストレージが分散ストレージ システムに配置されている場合、マスターとスレーブは同じデータを読み取るため、実際には binlog は必要ないことがわかりました。これは比較的理解しやすいです。 Binlog は、データがまとめられているため、特定のデータを送信するために使用されます。

コンピューティングとストレージの分離による3つの利点

分散ストレージのストレージスペースは比較的大きいです。もう 1 つのポイントは、新しいスレーブを追加する場合、通常、MySQL マスター スレーブ レプリケーションで新しいスレーブを追加するにはどうすればよいでしょうか。

新しい空のスレーブを作成し、その組み合わせからゆっくりとデータの同期を開始します。つまり、binlog を使用してデータを同期します。ただし、データ全体の量が大きい場合、新しいスレーブを作成したり、バックアップに基づいて新しいスレーブを再構築してからデータベースのバックアップをコピーしたりするには、非常に長い時間がかかります。これを踏まえると、新しいログを追跡し続ける場合、ノードを追加する方法に関係なく、時間は依然として分単位、少なくとも 10 分単位で測定されるはずです。

しかし、コンピューティングとストレージを分離した後は、新しいスレーブを作成するのにかかる時間は非常に短くなり、データのバックアップも大幅に高速化されます。従来のマスタースレーブシステムをバックアップする場合、実際にはファイルシステムをバックアップする必要があるためです。ファイル システムのスナップショットを作成するか、mysql ダンプを使用して、ローカル ファイルをクラウド ストレージに転送する必要があります。分散ストレージ システムでは、このタスクを基盤となるシステムに転送できます。もちろん、データの強力な一貫性は、依然として基盤となるストレージに依存します。

コンピューティングとストレージが分離されている場合、高可用性スイッチ全体はどのようになるでしょうか?以前の MySQL の場合、マスターとスレーブはそれぞれ独立したストレージとコンピューティングであり、それらの間に相関関係がないため、マスターとスレーブの切り替えは実際には比較的簡単です。マスターがスレーブに切り替わると、バイナリログが完全に再生されていないことが最大限に発生します。しかし、コンピューティングとストレージ全体が分離された後でも、まだいくつかの変更があります。

たとえば、最初の変更では、従来のデータベースの場合、その Redo ログは循環ファイル システムであり、3 つの Redo ログを循環的に使用できることがわかります。ストレージとコンピューティングが分離された環境の場合、その Redo ログは基本的に番号でソートされるように設計されます。

マスターとスレーブの切り替え後、ログ バッファーとバッファー プールの 2 つのバッファー プールを再構築するのに時間がかかる場合があります。従来の意味では、従来の MySQL マスター/スレーブ スイッチでは、ログに基づいてバッファー プールをわずかに再構築する必要があるためです。

バックアップに関しては、基本的に大きな変更があります。バックアップ全体は、基礎となるブロック ストレージに基づいて行われます。1 つの部分でページ全体のデータをバックアップできます。他の部分では、データベースのバックアップを迅速に完了できるように、REDO ログの増分バックアップを実行する必要があります。

実際、クラウドでデータベースをバックアップする方が、バックアップを実行するために 2 台の物理マシンをセットアップするよりも高速です。なぜ？

クラウド分散システムでは、バックアップ時にデータが複数のマシンに保存されるため、バックアップされるのは 1 台のマシンだけではありません。新しく作成されたスレーブの場合、クラウド コンピューティングとストレージを分離して新しいスレーブを作成すると、データ ブロック全体がすでに存在し、再度コピーする必要なく直接読み取ることができるため、新しいスレーブの作成速度は従来の方法よりもはるかに速くなります。

しかし、この状況は多くの問題も引き起こします。基盤となるファイル システムのバックアップとコピーの数が限られているため、より深い理由は、基盤となる分散ファイル システムの IOPS が限られていることです。従来モードの MySQL のようなマスター/スレーブ関係の場合、実際にはそのような制限はありません。

4 結論

***これらのソリューションの利点と欠点をまとめます。

たとえば、クライアント ソリューションには、さまざまなデータ ソースに接続できるという利点があります。データベースが JDBC 互換であれば接続でき、パフォーマンスも向上します。しかし、パフォーマンスが向上する一方で、別の問題も生じます。接続数は比較的多い可能性があります。クライアントの数が非常に多いため、各クライアントが MySQL に接続すると、MySQL 接続も多数発生します。

欠点も非常に明白です。会社が Java のみを使用している場合は、問題はありません。 jar パッケージを開発するだけで、誰もがそれを使い慣れるようになります。企業が Python、C++、Go を使用する場合、言語ごとにクライアントを作成する必要があり、これは実は非常に面倒です。また、クライアントがリリースされた後に SDK をアップグレードするのも非常に面倒です。

そのため、ほとんどのメーカーはプロキシ ソリューションを採用します。プロキシ ソリューションは管理が容易で、アップグレードも容易であり、構文は基本的に互換性があり、多言語 SDK の問題がないためです。一部の MySQL 構文と互換性があるため、従来の MySQL クライアント、さまざまな言語の SDK、およびサードパーティが MySQL 用に開発したすべての SDK を使用できます。欠点は、トランザクションをサポートしていないか、トランザクションのサポートが制限されていることです。

コンピューティングとストレージを分離するソリューションの場合、その利点は非常に明白で、コスト効率に優れています。なぜ？

クラウドでクラウド データベースを購入する場合、パフォーマンスが購入に関係することがよくあります。たとえば、1C2G10GB の小さなデータベースを購入した場合、OPS は数百または数千にしかならない可能性があります。しかし、コンピューティングとストレージを真に分離するソリューションの場合、購入を開始するタイプは比較的小さく、購入する仕様も比較的小さい可能性がありますが、非常に高い IOPS パフォーマンスを実現でき、データベース パフォーマンスは購入する仕様によって制限されません。

デメリットとしては、全体的なストレージスペースが限られていることです。最大で64Tまたは128Tしかサポートされない場合があります。各データベースの分散ストレージ内のコピー数は限られているため、読み取り専用ノードは 15 または 14 に制限される場合がありますが、これは問題ではありません。大多数のユーザーにとってはこれで十分だと考えています。もう一つのデメリットは開発の難しさですが、このデメリットは開発者にとっての悩みの種であり、ユーザーとは何の関係もありません。

ゼロから始めたい場合には、Spanner/TiDB などのデータベース ソリューションの方がスケーラビリティが高くなります。コンピューティングとストレージを分離する Aurora のようなデータベースの場合、ストレージ スペースは結局のところ限られているからです。ただし、この種類のデータベースの場合、そのストレージ スペースは完全に拡張可能であり、1P を超えるデータベースをサポートできると考えられます。

欠点についても話しましょう。既存の SQL 構文との互換性を保つのは非常に難しく、大きな課題となっています。例えば、TiDB は比較的優秀な国産データベースであり、MySQL との構文互換性が最も優れていることでも知られています。しかし、実際には、多くのステートメントは互換性がありません。やりたくないわけではないのですが、やるのは非常に難しいのです。基礎となるデータ構造によって一部の機能が決まるため、一部の SQL ステートメントとの互換性を保つためのコストが非常に高くなることも決まります。

【この記事は51CTOコラムニスト「JD Cloud」によるオリジナル記事です。転載する場合は著者のWeChat公開アカウントJD-jcloudを通じて許可を得てください]

この著者の他の記事を読むにはここをクリックしてください