PolarDB-X パーティション作成列タイプの変更

バックグラウンド

データベース分野の数十年にわたる開発を通じて、リレーショナルデータベースが傑出している重要な理由は、ユーザーが「データモデル」を柔軟に定義および変更できるようサポートしていることです。

クラウドネイティブのリレーショナルデータベースとして、PolarDB-X は、ユーザーのビジネスの継続的な発展に合わせて、さまざまな DDL ステートメントによるデータモデルの変更もサポートしています。たとえば、ALTER TABLE ステートメントを使用して列の追加、列の削除、列の型などの操作を変更します。ただし、分散データベースとして、PolarDB-X は通常、何らかのパーティション方式を通じてデータを論理テーブル内の複数のシャード (物理テーブルとも呼ばれます) に分割し、これらのシャードは異なるデータノードに分散されます [1][2]。 DDL ステートメントの実装がより複雑になります。

この記事では、列タイプの変更を例として、PolarDB-X で ALTER TABLE ステートメントを実行する方法を簡単に紹介します。まず、列タイプの変更には 2 つのタイプがあります。1 つはパーティション・キーの列タイプの変更で、もう 1 つは非パーティション・キーの列タイプの変更です。非パーティションキー列タイプの変更の場合は、論理 DDL を複数の物理 DDL に直接分割し、対応するシャードに直接プッシュダウンして実行できますが、パーティションキー列タイプの変更の場合は、比較的複雑です。パーティションキー列の型の変更はフラグメンテーションのルーティングに影響するため、データを再配布することも必要です。単純にプッシュダウンした場合、パーティションキーがクエリに使用されるときにデータはクエリされません。

実際、分散データベースとしてテーブルの列タイプを変更する場合は、それがパーティションキーであるかどうかに関係なく、各シャードとメタデータの一貫性を確保する必要があるため、非パーティションキーの列タイプを変更する必要があります。単純なプッシュダウン実行だけで十分なので、詳しくは後ほど記事で説明しますが、この記事では主にパーティションキーのカラム型を変更する方法について説明します。

従来の実装

従来の分散データベースミドルウェアは、テーブルをサブデータベースとサブテーブルで分割します。通常、分割キー列の型を変更することはできません。変更したい場合は、通常、テーブルを再構築して書き込みを停止する必要があります。データをインポートします。

変更したいときに書き続けたい場合は、ストックデータをインポートする際に一連の二重書き込みロジックを維持する必要があり、この操作方法は複雑であるだけでなく、最終的なデータの正確性を検証することも困難です。データの不整合の問題が発生しやすいです。

達成

前回の記事ではPolarDB-X 分割ルール変更の実装原理を紹介しました [3] が、変更プロセスにはデータの再分割も必要です。

データ再分散の典型的なケースとして、分割ルールの変更プロセスでは、新しいテーブルの作成、二重書き込み、既存データのインポート、データ検証、トラフィックの切り替えなどの手順を実行する必要があり、プロセス全体は非常に成熟しています。この処理変更により、パーティションキーカラムの型を変更できることが容易に想像できますが、この機能の詳細な実装を以下に紹介します。

増分データの二重書き込み、ストックデータの同期、データ再配布プロセス中のトラフィックの切り替え方法については、記事で詳しく説明されているため、ここでは詳しく説明しません。この記事とオンラインスキーマをもう一度読み、この論文を変更します[4]。

追加する必要があるのは、変更前後のデータの正確性を保証するために、TSO スナップショット [5] に基づく物理データ検証機能も実装したことです。この記事の主題に戻りますが、パーティション作成列の種類の変更は、次の点で分割ルールの変更とは異なります。詳細については、以下で説明します。

新しいテーブルを作成する
グローバルセカンダリインデックス (GSI) 処理用
データ検証

新しいテーブルを作成する

分割ルールの変更については、分割ルールのみを変更し、列の定義は変更しないため、新しく作成されるテーブルのテーブル構造は元のテーブルと全く同じであり、列の定義は変更されません。ただし、パーティションキーのカラムタイプを変更するには、パーティションキーのカラム定義を変更する必要があるため、新しく作成されたテーブルのテーブル構造は、パーティションキーのカラム定義やその他の定義を除き、元のテーブルと完全には一致しません。同じだ。

新しいテーブルの列定義が元のテーブルの列定義と矛盾しているため、元の増分データの二重書き込みプロセスとストックデータの同期プロセスで暗黙的な型変換が行われます。これら 2 つのプロセスを変更する必要がありますか? 答えは「いいえ」です。パーティションキーの場合、DN (データノード) の暗黙的な型変換は CN (コンピューティングノード) と互換性があり、暗黙的変換前のデータと暗黙的変換後のデータの使用を保証できるからです。ルーティングの問題を気にせずに同じシャードにルーティングできます。

さらに、MySQL に精通している学生は、MySQL では ALTER TABLE MODIFY COLUMN の変換と DML の暗黙的な変換ロジックの間に違いがあり、BINLOG を介して同期されたダウンストリームデータとアップストリームデータの間で不整合が発生する可能性があることを知っているかもしれません。データ検証の章で説明して回答します。

グローバルセカンダリインデックスの処理

記事では、PolarDB-X のグローバルセカンダリインデックス [6] が紹介されていますが、テーブルへのクエリを容易にするために、グローバルセカンダリインデックスには、デフォルトでメインテーブルの主キーとパーティションキーがカバー列として含まれています。

GSI とメインテーブルのデータの一貫性を確保するために、メインテーブルのパーティションキーの列タイプを変更するときは、すべての GSI の対応するカバー列のタイプも同時に変更する必要があるため、メインテーブルのパーティションキーの列タイプを変更する必要があります。実際には地理院表が変更されます。データも再配布されます。

メインテーブルのパーティションキーが地理院のパーティションキーと一致せず、地理院のパーティションキーの列型が変更された場合でも、データの整合性を確保するために同じプロセスに従う必要があります。

データ検証

変更が正確であることを確認するには、新しいテーブルを作成し、増分データの二重書き込みを有効にし、既存のデータを同期した後、データ検証ステップを挟む必要があります。データ検証に合格した後、トラフィックが切り替えられ、元のテーブルは正常にオフラインになります。

データ検証のロジックを簡単に紹介します。まず、シーケンスに依存しないハッシュアルゴリズムを DN 側に実装し、UDF としてカプセル化しました。CN が検証を開始すると、まず TSO トランザクションを使用してソーステーブルの整合性スナップショットを取得します。ターゲットテーブルとターゲットテーブルのハッシュチェック計算 (並列) を、ソーステーブルとターゲットテーブルの DN 端に対応するフラグメントごとに実行し、その結果を CN ノードにプルして要約します。ソーステーブルのチェックサムを計算し、最後にターゲットテーブルのチェックサムと比較することができます。

同型テーブル (シャード間の並列):

異種テーブル (シャード間で並列):

パーティションキーの列タイプの変更の場合、ソーステーブルとターゲットテーブルの列定義が完全に一致していないため、直接検証すると必ず検証が失敗します。たとえば、ソーステーブルのパーティションキーの列タイプが VARCHAR で、「123abc」というデータがある場合、パーティションキーの列タイプを INT に変更すると、ターゲットテーブルのパーティションキーに対応するデータが次のハッシュチェックに変換されます。 123、123、'123abc' 当然値が違うので検証は失敗します。上記の問題を解決するために、新しいテーブルを作成した後、データ検証のみに使用される仮想列 (外部からは見えない) をソーステーブルに追加し、その仮想列が列の型変換関数を呼び出します。パーティションキー列の基礎。たとえば、上記の例では、仮想列がソーステーブルに追加された場合、仮想列の値は '123abc' となり、これは変換関数 123 を呼び出した結果であり、結果はターゲットと一致します。テーブル。データ検証は仮想カラムを追加することで完了でき、仮想カラムが呼び出すカラム型変換関数はMySQLにおけるALTER TABLE MODIFY COLUMN変換の処理ロジックと一致しているため、DML暗黙的な変換やALTER TABLEが正しく行われていることも検証できます。 MODIFY COLUMN 変換に一貫性がありません。

DDL 実行計画の表示

パーティション・キー列タイプの変更には、必ずしもデータの再分散が必要ではありません。たとえば、文字列列タイプの場合、文字列の CHARSET および COLLATE を変更せずに長さを増やすだけの場合は、実際にはデータの再分散は必要ありません。実行このプロセスは、非パーティションキー列タイプの変更の場合と同様です。さらに、ユーザーはメインテーブルのパーティションキーではなく、GSI のパーティションキー列タイプを変更するだけで済みますが、それでもデータの再分散が発生します。実際には列タイプの変更にはいくつかのシナリオがあることがわかります。ユーザーが列タイプ変更の特定のプロセスを簡単に区別できるようにするために、使用する DDL ステートメントに explian と同様の操作を提供します。以下では sysbench テーブルを使用して、いくつかの例を挙げて説明します。

テーブル作成ステートメント:

例 1、非パーティションキー列の型を変更します。

例 2: パーティションキー列のタイプを変更し、データの再分散を必要とします。

このうち、CREATE TABLEは新しいテーブルを作成するもの、DROP TABLEは検証完了後に古いテーブルを削除するもの、ALTER TABLEはデータ検証用の仮想カラムを追加するものです。

例 3: データを再分散せずにパーティションキー列の型を変更します。

まず、パーティションキー ID 列を varchar(30) に変更します。このプロセスではデータの再配布が必要です。次に、その型を varchar(60) に変更します。結果は次のようになります。データの再配布は必要ないことがわかります (必要ありません)。テーブルの作成と削除)。

要約する

列タイプの柔軟な変更は、分散データベースの重要な機能です。PolarDB-X はパーティションキー列タイプの変更をサポートしていますが、強力なデータ一貫性、高可用性、ビジネスへの透明性を確保し、分散によって生じる制限を取り除き、非常に使いやすくなっています。この記事では、PolarDB-X 分割ルールの変更に基づいて、パーティションキーカラムタイプの変更を実装するプロセスで使用されるさまざまな技術的なポイントを簡単に説明します。PolarDB-X がこの機能をサポートできる理由は、次のような多くの機能を使用しているためです。 TSO トランザクション: これは、分散データベースと分散データベースミドルウェアを区別する重要な機能の 1 つでもあります。

著者: ウー・ムー

クリックして今すぐクラウド製品を無料で試し、クラウドでの実践的な取り組みを始めましょう!

元のリンク

この記事は Alibaba Cloud のオリジナルのコンテンツであり、許可なく複製することはできません。