CO_HASHパーティショニング - PolarDB - Alibaba Cloud ドキュメントセンター

サポートされているバージョン

PolarDB-Xのバージョンは5.4.18-17047709以降である必要があります。

該当するシナリオ

電子商取引のシナリオでは、ビジネス注文テーブル内の2つ以上の列の値が類似性を有することがある。例えば、order_id列の下N桁は、buyer_id列と同じである。ビジネス注文テーブルのデータ量が多いため、order_id列とbuyer_id列の最後のN桁に基づいて注文テーブルを水平方向に分割できます。このようにして、アプリケーションは、注文IDまたは購入者IDに基づいてデータを読み取るか書き込むかに関係なく、発注シナリオで同じ物理パーティションにデータをルーティングできます。これにより、多数のデータベース間トランザクションが防止される。

PolarDB-Xは、次のシナリオの問題を解決するためのCO_HASHパーティショニングポリシーをサポートしています。

分割されるテーブルの2つ以上の列の値は、類似性を有する。例えば、列の最後または最初のN桁は、テーブル内の別の列のものと同じである。
データは、パーティションテーブル内の異なるパーティションキー列に基づいて同時に個別にルーティングできます。これらのパーティションキー列は互いに独立しています。等しい条件がパーティションキー列の1つを含むクエリは、パーティションプルーニング条件を満たすことができます。

構文

PolarDB-Xでは、CO_HASHパーティショニングポリシーを使用して、複数のパーティションキー列の異なる値に基づいてデータを同時にルーティングできます。

テーブルを作成...
PARTITION BY CO_HASH(partition_expr_list)
パーティー番号

partition_expr_list:
  partition_expr, partition_expr [, partition_expr, ...]
  
partition_expr:
    partition_column	
  | partition_func(partition_column)


# パーティション関数を定義します。
partition_func:
     
  | 左
  | SUBSTR
  | SUBSTRING

説明

CO_HASHパーティショニングとHASHまたはKEYパーティショニングの違いの詳細については、「概要」トピックのCOHASHパーティショニング、HASHパーティショニング、およびKEYパーティショニングの比較テーブルを参照してください。

使用上の注意

SUBSTR(SUBSTR(c1,-6),4) などのパーティションキー列にネストされたパーティション分割関数を使用することはできません。
すべてのパーティションキー列のデータ型は、次の用語で同じである必要があります。
- 文字セットと照合。
- 長さと精度の定義。
既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。
デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。
CO_HASHパーティショニングは、次のパーティショニング関数のみをサポートします。
- 右
- 左
- SUBSTR

例

たとえば、order_id列の下6桁は、orderという名前のテーブルの各行のbuyer_id列の下6桁と同じです。

order_id列とbuyer_id列の最後の6桁に基づいて注文テーブルを分割し、行のorder_id列とbuyer_id列の値を同じパーティションにルーティングする場合は、次の構文を使用できます。

テーブルの作成t_orders (
 id bigint not null auto_increment, 
 seller_id bigint、
 order_id bigint、 
 buyer_id bigint,
 order_time datetimeがnullでない場合、
 主キー (id)
)
CO_HASHによるパーティー (
  	RIGHT('order_id',6) /* 列c1の最後の6桁を取得します。 */,
  	RIGHT('buyer_id ',6) /* 列c2の下6桁を取得する。 * /
)
パーティー8;

CO_HASHパーティショニングポリシーとその他のパーティショニング関数の使用方法の詳細については、「パーティショニング関数」をご参照ください。

制限事項

データ型の制限

整数型: BIGINT、BIGINT UNSINGEDINT、INT、INT UNSINGED、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED
日付と時刻のタイプ: DATETIME、Date、およびTIMESTAMP
文字列型: CHARおよびVARCHR
固定小数点タイプ: DECIMAL。小数部の桁数は0でなければなりません。

パーティションキー列の制限

異なるパーティションキー列の値の類似性を確認する必要があります。 PolarDB-Xは、パーティションテーブルのルーティング結果のみをチェックします。 CO_HASHパーティションテーブルのさまざまなパーティションキー列の値には類似性があります。 CO_HASHパーティションテーブルにデータの行を書き込む場合、行の異なるパーティションキー列の値を同じパーティションにルーティングする必要があります。ただし、PolarDB-Xは、異なるパーティションキー列の値の類似性を保証しません。したがって、異なるパーティションキー列の値の類似性を確認する必要があります。 PolarDB-Xは、パーティションテーブルのルーティング結果のみをチェックし、データの類似性は検証しません。たとえば、c1列の最後の4桁は、テーブルのc2列の4桁と同じです。 PolarDB-Xでは、列c1の値が1001234、列c2の値が1320の行をパーティション0にルーティングできます。この場合、c1列とc2列の最後の4桁は異なる。
PolarDB-Xは、DMLステートメントを使用してパーティションキー列の値を変更することに制限を課します。 CO_HASHパーティションテーブルの複数のパーティションキー列の値が類似しているため、PolarDB-XはDMLステートメントを使用してパーティションキー列の値を変更することに制限を課します。これにより、CO_HASH分割テーブルのルーティング結果のエラーを防ぎます。
- INSERTまたはREPLACEステートメントを実行するときに、ルーティングアルゴリズムによって生成された結果に基づいて、values句の同じ行にある異なるパーティションキー列の値を異なるパーティションにルーティングする場合、INSERTまたはREPLACEステートメントは禁止され、エラーが報告されます。
- UPDATEステートメントまたはUPSERTステートメントを実行するときに、SET句がパーティションキー列の値を変更する場合、すべてのパーティションキー列の値を同時に変更する必要があります。たとえば、c1列とc2列がパーティションキー列として指定されている場合は、次のステートメントを実行する必要があります。UPDATE t1 SET c1='xx',c2='yy' WHERE id=1。 SET句がパーティションキー列の値を変更した後、同じ行の異なるパーティションキー列の値を異なるパーティションにルーティングする場合、UPDATEステートメントまたはUPSERTステートメントは禁止され、エラーが報告されます。
- CO_HASHパーティショニングポリシーを使用してグローバルセカンダリインデックス (GSI) をパーティション分割した後、INSERTやUPDATEなどのDML操作がプライマリテーブルで実行されると、プライマリテーブルのGSIの同じ行にある異なるパーティションキー列の値が異なるパーティションにルーティングされると、DML操作は禁止され、エラーが報告されます。
PolarDB-Xは、CO_HASHパーティションテーブルの整数型のパーティションキー列のプレフィックスが0の値を自動的に処理します。 CO_HASHパーティションテーブルのパーティションキー列の値は類似しているため、パーティションキー列を定義するにはSUBSTR、LEFT、RIGHTなどのパーティション関数を使用する必要があります。いくつかの整数型の値が切り捨てられた後、これらの値のプレフィックスとして0が追加され得る。たとえば、c1列の最後の4桁は、テーブルのc2列の4桁と同じです。列c1の値が1000034、列c2の値が34の行を挿入します。この場合、列c1の最後の4桁は0034である。 CO_HASHパーティションテーブルでは、整数型のパーティションキー列のすべての元の値が切り捨てられた後、新しい値は自動的にパーティションキー列の整数型に変換され、ルーティングされます。したがって、文字列0034は文字列34に変換される。次に、文字列34のハッシュ値が計算され、パーティションにルーティングされる。このようにして、文字列0034のプレフィックスが自動的に処理されます。