KEYパーティション分割は、PolarDB-Xの組み込みのコンシステントハッシュアルゴリズムに基づいてデータをパーティション分割するHASHパーティション分割に似ています。 したがって、PolarDB-XのKEYパーティショニングのルーティングアルゴリズムはMySQLのそれとは異なります。
KEYパーティショニングとHASHパーティショニングの違いは、次の点にあります。
keyパーティショニングでパーティションキー列を指定できません。 この場合、主キー列はデフォルトでパーティションキーとして使用されます。 主キー列が指定されていない場合、パーティショニングは一意のキーに基づいて実行されます。
KEYパーティショニングは、ベクターパーティションキーをサポートします。 複数のパーティションキー列で構成されるベクターパーティションキーがkeyパーティション分割で使用されている場合、最初のパーティションキー列はデフォルトでデータのルーティングに使用されます。
KEYパーティショニングは、INT、STRING、DATE、およびDATETIMEのデータ型をサポートします。
構文
テーブルを作成...
PARTITION BY KEY(partition_column_list)
パーティー番号
partition_column_list:
partition_column_list[, partition_column, partition_column, ...]
HASHパーティショニングとKEYパーティショニングの違いの詳細については、「概要」トピックの「KEYパーティショニングとHASHパーティショニングの比較」をご参照ください。
使用上の注意
KEYパーティショニングはパーティショニング機能をサポートしていません。
既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。
デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。
例
単一列のパーティションキーを使用する
keyパーティション分割の単一列パーティションキーとしてid列を指定し、パーティション数を8に設定します。
テーブルの作成tb_k (
id bigint not null auto_increment,
bid int,
名前varchar(30) 、
birthday datetime not null,
主キー (id)
)
キーによるパーティション (id)
パーティー8;
ベクターパーティションキーを使用する
keyパーティション分割には、bid列とid列で構成されるvectorパーティションキーを使用し、パーティションの数を8に設定します。
デフォルトでは、最初のパーティションキー列がハッシュ値の計算に使用されます。 プレフィックスパーティションキー列を含む等価条件がクエリに含まれている場合、パーティションプルーニング条件は満たされます。 idなどのデータのルーティングに使用されない残りのパーティションキー列は、ホットデータパーティション分割に使用されます。
テーブルの作成tb_k (
id bigint not null auto_increment,
bid int,
名前varchar(30) 、
birthday datetime not null,
主キー (id)
)
キーによるパーティー (bid, id)
パーティー8;
制限
データ型の制限
整数型: BIGINT、BIGINT UNSINGEDINT、INT、INT UNSINGED、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED
日付と時刻のタイプ: DATETIME、Date、およびTIMESTAMP
文字列型: CHAR、VARCHR、およびBINARY
固定小数点タイプ: DECIMAL。小数部の桁数は0でなければなりません。
データ分散バランシング
KEYパーティショニングとHASHパーティショニングは、組み込みのコンシステントハッシュアルゴリズムMurmurHash3に基づいて実装されます。 このアルゴリズムは業界で広くテストされており、データの衝突が少なく高性能であることが証明されています。
KEYパーティショニングまたはHASHパーティショニングを使用する場合、MurmurHash3アルゴリズムに基づいてパーティションキーの異なる値の数が3,000を超えると、異なるパーティション間のデータ分散のバランスが取れます。 パーティションキーの値が異なる場合、データはよりバランスの取れた方法で分散されます。