PolarDB:テーブルの作成 (自動モード)

パーティション分割タイプ

HASHパーティショニング

PolarDB − XにおけるHASH区分タイプは、HASH区分およびKEY区分を含む。 HASHパーティショニングとKEYパーティショニングは、ネイティブMySQL構文でサポートされています。 PolarDB-Xは、MySQLでパーティションテーブルを作成するために使用されるHASHパーティション分割およびKEYパーティション分割の構文と構文的に互換性があり、分割、マージ、移行などの柔軟で強力なパーティション管理機能を提供し、ベクターパーティションキーでのホットパーティション分割をサポートします。 ただし、PolarDB-Xは、MySQLとは異なる方法でデータをパーティションにルーティングします。 PolarDB-Xは、HASHパーティショニングおよびKEYパーティショニングでデータルーティングを再指定します。 さまざまな分割タイプの構文の詳細については、「分割タイプ」をご参照ください。 次の表は、KEY分割とHASH分割の違いを示しています。

例1-1:KEYパーティショニング

テーブルの作成key_tbl (
 id bigint not null auto_increment,
 bid int,
 名前varchar(30) 、
 birthday datetime not null,
 主キー (id)
)
PARTITION BY KEY(name, id)
パーティー8; 

## 次のSQL文は、パーティションプルーニング条件を満たし、1つのパーティション内のデータのみをスキャンします。
key_tblからのSELECT id (name='Jack'); 

name列のデータが均等に分散されていない場合、または特定のデータに頻繁にアクセスされる場合は、ベクター内の別のパーティションキー列 (id列など) を使用して、パフォーマンスを最適化するためにパーティションを分割できます。 詳細については、「ALTER TABLEGROUP」をご参照ください。

ベクトルパーティションキーがN個のパーティションキー列で構成され、データが最初のK (1 ≦ K ≦ N) 個のパーティションキー列にルーティングされる場合、SQL文のWHERE句のベクトルパーティションキーの最初のK列のみに基づいてパーティションプルーニングの条件を指定する必要があります。

例1-2: HASHパーティショニング

テーブルの作成hash_tbl (
 id bigint not null auto_increment,
 bid int,
 名前varchar(30) 、
 birthday datetime not null,
 主キー (id)
)
ハッシュ (id) によるパーティション
パーティション8; 

テーブルの作成hash_tbl_todays (
 id bigint not null auto_increment,
 bid int,
 名前varchar(30) 、
 birthday datetime not null,
 主キー (id)
)
PARTITION BY HASH(TO_DAYS(birthday))
パーティー8; 

PolarDB-Xでは、次のパーティション分割機能がサポートされています。

• YEAR

• MONTH

• DAYOFMONTH

• デイオフウィーク

• DAYOFYEAR

• TO_DAYS

• TO_MONTHS

• TO_WEEKS

• TO_SECONDS

• UNIX_TIMESTAMP

• SUBSTR/SUBSTRING

したがって、SUBSTRまたはSUBSTRING関数のパーティションキー列のデータ型がSTRINGでなければならないことを除いて、他のパーティション関数のパーティションキー列のデータ型は、DATE、DATETIME、およびTIMESTAMPのタイプでなければなりません。

例1-3: 拡張HASHパーティショニング

テーブルの作成hash_tbl2 (
 id bigint not null auto_increment,
 bid int,
 名前varchar(30) 、
 birthday datetime not null,
 主キー (id)
)
ハッシュによるパーティー (名前、誕生日)
パーティー8; 

HASHパーティション分割タイプを使用してテーブルをパーティション分割する場合は、ベクターパーティションキーが使用されます。 テーブル内のデータは、すべてのパーティションキー列の値のハッシュ値に基づいてパーティションにルーティングされます。 SQL文のWHERE句のすべてのパーティションキー列に基づいて、パーティションプルーニングの条件を指定する必要があります。 以下の例では、SQL1はhash_tbl2テーブルのパーティションプルーニング条件を満たし、SQL2はhash_tbl2テーブルのパーティションプルーニング条件を満たしていません。

## 次のSQL文SQL1は、パーティションプルーニング条件を満たしています。 ステートメントが実行されると、指定されたパーティションのみがスキャンされます。
name='Jack' およびbirthday='1990-11-11' であるhash_tbl2からのSELECT id。## 次のSQL文SQL2は、パーティションプルーニング条件を満たしていません。 ステートメントが実行されると、すべてのパーティションがスキャンされます。
hash_tbl2からのSELECT id (name='Jack'); 

HASHパーティショニングでは、すべてのパーティションキー列の値のハッシュ値に基づいてデータがルーティングされます。 したがって、データは、ベクトル分割キーの特定の列のみの値のハッシュ値に基づいてデータがルーティングされるKEY分割よりも、HASH分割でより均等に分散されます。 すべてのパーティションキー列がデータパーティション分割に使用され、ホットパーティション分割に使用できるパーティションキー列がないため、HASHパーティション分割はホットパーティション分割をサポートしません。

制限

• データ型の制限

  • 整数型: BIGINT、BIGINT UNSINGED、INT UNSINGED、INT、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED。

  • 日付と時刻のタイプ: DATETIME、Date、およびTIMESTAMP。

  • String型: CHARおよびVARCHAR。

• 構文の制限

  • テーブルのパーティションキーが単一列パーティションキーで、パーティションキー列のデータ型がDATETIME、DATE、またはTIMESTAMPの場合、特定のパーティション分割機能がサポートされます。

  • テーブルのパーティションキーがベクターパーティションキーの場合、パーティション分割関数とホットパーティション分割はサポートされません。

  • 既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。

  • デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。

データ分散

• KEYパーティショニングとHASHパーティショニングは、組み込みのコンシステントハッシュアルゴリズムMurmurHash3に基づいて実装されます。 このアルゴリズムは業界で広くテストされており、データの衝突が少なく高性能であることが証明されています。

• KEYパーティショニングまたはHASHパーティショニングを使用すると、MurmurHash3アルゴリズムに基づいて、パーティションキーの異なる値の数が3,000を超えると、異なるパーティション間のデータ分散がバランスを取ります。 パーティションキーがより多くの異なる値を含む場合、データはよりバランスのとれた方法で分散される。

レンジパーティショニング

PolarDB-XのRANGEパーティショニングタイプには、RANGEパーティショニングとRANGE COLUMNSパーティショニングが含まれます。 RANGEパーティショニングとRANGE COLUMNSパーティショニングは、ネイティブMySQL構文でサポートされています。 さまざまな分割タイプの構文の詳細については、「分割タイプ」をご参照ください。 次の表は、RANGEパーティショニングとRANGE COLUMNSパーティショニングの違いを示しています。

例2-1: RANGE COLUMNSパーティショニング

RANGE COLUMNSパーティショニングはベクターパーティションキーをサポートしますが、パーティショニング機能はサポートしません。 たとえば、次のステートメントを実行して、order_id列とorder_time列の指定された値の範囲に基づいてパーティション分割されたテーブルを作成できます。

テーブル注文を作成する (
 order_id int,
 order_time datetimeがnullではない)
範囲列によるPARTITION (order_id,order_time)
(
  パートp1はより少ない値 (10000、'2021-01-01 ') 、
  パートp2はより少ない値 (20000、'2021-01-01 ') 、
  パーティーp3はより少ない値 (30000、'2021-01-01 ') 、
  パートp4はより少ない値 (40000、'2021-01-01 ') 、
  パートp5はより少ない値 (50000、'2021-01-01 ') 、
  PARTITION p6値未満 (MAXVALUE、MAXVALUE)
); 

例2-2: RANGEパーティショニング

RANGEパーティショニングは、単一列パーティションキーのみをサポートします。 日付と時刻の値を含む列をパーティションキーとして使用する場合は、YEAR、TO_DAYS、TO_SECONDS、MONTHなどのパーティション関数を含む式を使用して、列の日付と時刻の値を整数値に変換する必要があります。

たとえば、次のステートメントを実行して、order_time列の指定された範囲の値に基づいてパーティション分割されたテーブルを作成し、データを四半期ごとに異なるパーティションに格納できます。

テーブルorders_todaysを作成する (
 id int,
 order_time datetimeがnullではない)
レンジによるパーティー (to_days(order_time))
(
  PARTITION p1未満の値 (to_days('2021-01-01 ')) 、
  PARTITION p2未満の値 (to_days('2021-04-01 ')) 、
  PARTITION p3はより少ない値 (to_days('2021-07-01 ')) 、
  PARTITION p4はより少ない値 (to_days('2021-10-01 ')) 、
  PARTITION p5 VALUES LESS THAN (to_days('2022-01-01 ')) 、
  PARTITION p6値より少ない (最大値)
); 

制限

• データ型の制限

  • 整数型: BIGINT、BIGINT UNSINGEDINT、INT、INT UNSINGED、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED。

  • 日付と時刻のタイプ: DATETIMEとDate。

  • String型: CHARおよびVARCHAR。

• 構文の制限

  • RANGE COLUMNSパーティショニングとRANGEパーティショニングは、値の範囲の境界としてNULLをサポートしません。

  • RANGE COLUMNSパーティショニングでは、TIMESTAMP型の列をパーティションキー列としてサポートしていません。

  • RANGEパーティショニングでは、整数値を含む列のみをパーティションキー列として使用できます。 TIMESTAMP型の列をパーティションキー列として使用するには、UNIX_TIMSTAMPパーティション分割関数を使用して、タイムスタンプ値を同じタイムゾーンのタイムスタンプに変換する必要があります。

  • RANGEパーティショニングは、ホットパーティション分割をサポートしていません。

  • SQLリクエストでNULL値が指定されている場合、NULL値はデータルーティング中の最小値と見なされます。

  • 既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。

  • デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。

リスト分割

PolarDB-XのLISTパーティショニングタイプには、LISTパーティショニングとLIST COLUMNSパーティショニングが含まれます。 LISTパーティショニングとLIST COLUMNSパーティショニングは、ネイティブMySQL構文でサポートされています。 さまざまなパーティショニングタイプの構文の詳細については、「パーティショニングタイプ」をご参照ください。 PolarDB-XのLISTパーティショニングとLIST COLUMNSパーティショニングもDEFAULTパーティショニングをサポートしています。 次の表に、LISTパーティショニングとLIST COLUMNSパーティショニングの違いを示します。

例3-1: LIST COLUMNSパーティショニング

LIST COLUMNSパーティションは、ベクターパーティションキーをサポートします。 たとえば、次のステートメントを実行して、国列と都市列の値に基づいてパーティション分割されたテーブルを作成できます。

テーブルorders_regionを作成する (
 id int,
 国varchar(64) 、
 都市varchar(64) 、
 order_time datetimeがnullではない)
リストコラムによるパーティー (国、都市)
(
  パートp1の値 (('China','Hangzhou'), ('China','Beijing')),
  パートp2の値 ((「米国」、「ニューヨーク」) 、(「米国」、「シカゴ」)) 、
  PARTITION p3 VALUES IN (('Russian' 、'Moscow'))
); 

例3-2: LISTパーティショニング

LISTパーティショニングは、単一列パーティションキーのみをサポートします。 日付と時刻の値を含む列をパーティションキー列として使用する場合は、YEAR、MONTH、DAYOFMONTH、TO_DAYS、TO_SECONDSなどのパーティション関数を使用して、パーティションキー列のタイムスタンプ値を整数に変換する必要があります。

たとえば、次のステートメントを実行して、order_time列の値に基づいてパーティション分割されたテーブルを作成し、年ごとに異なるパーティションにデータを格納できます。

テーブルのorders_yearsを作成する (
 id int,
 国varchar(64) 、
 都市varchar(64) 、
 order_time datetimeがnullではない)
リストによるパーティション (YEAR(order_time))
(
  パートp1値 (1990,1991、1992,1993、1994,1995、1996,1997、1998,1999) 、
  PARTITION p2の値 (2000,2001、2002,2003、2004,2005、2006,2007、2008,2009) 、
  PARTITION p3の値 (2010,2011、2012,2013、2014,2015、2016,2017、2018,2019)
); 

例3-3: LIST COLUMNSパーティションまたはDEFAULTパーティションを使用したLISTパーティション

PolarDB-Xを使用すると、LIST COLUMNSパーティションまたはDEFAULTパーティションを使用したLISTパーティションを作成できます。 共通パーティションで定義されていないデータは、DEFAULTパーティションにルーティングされます。

テーブルorders_regionを作成する (
 id int,
 国varchar(64) 、
 都市varchar(64) 、
 order_time datetimeがnullではない)
リストコラムによるパーティー (国、都市)
(
  パートp1の値 (('China','Hangzhou'), ('China','Beijing')),
  パートp2の値 ((「米国」、「ニューヨーク」) 、(「米国」、「シカゴ」)) 、
  PARTITION p3 VALUES IN (('Russian' 、'Moscow')) 、
  PARTITION pd値IN (デフォルト)
);

テーブルのorders_yearsを作成する (
 id int,
 国varchar(64) 、
 都市varchar(64) 、
 order_time datetimeがnullではない)
リストによるパーティション (YEAR(order_time))
(
  パートp1値 (1990,1991、1992,1993、1994,1995、1996,1997、1998,1999) 、
  PARTITION p2の値 (2000,2001、2002,2003、2004,2005、2006,2007、2008,2009) 、
  PARTITION p3の値 (2010,2011、2012,2013、2014,2015、2016,2017、2018,2019) 、
  PARTITION pd値IN (デフォルト)
); 

制限

• データ型の制限

  • 整数型: BIGINT、BIGINT UNSINGEDINT、INT、INT UNSINGED、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED。

  • 日付と時刻のタイプ: DATETIMEとDate。

  • String型: CHARおよびVARCHAR。

• 構文の制限

  • LIST COLUMNSパーティション分割では、TIMESTAMP型の列をパーティションキー列として使用することはできません。

  • LISTパーティショニングでは、整数値を含む列のみをパーティションキー列として使用できます。

  • LIST COLUMNSパーティショニングとLISTパーティショニングは、ホットパーティション分割をサポートしていません。

  • 既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。

  • デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。

COHASHパーティショニング

COHASHパーティショニングタイプは、PolarDB-X専用です。

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

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

シナリオ

COHASHパーティショニングタイプは、次のシナリオに適しています。

ビジネステーブルには、1つ以上の同様の列が含まれます。 たとえば、テーブルにはc1列とc2列が含まれており、列の値の最後の4文字は常に同じです。 テーブルを列で分割し、c1列またはc2列と同等のクエリ条件をクエリに含めます。 また、条件を同じパーティションにルーティングする必要があります。

この場合、このパーティション分割タイプを使用するには、パーティション分割テーブルの異なるパーティションキー列の値の類似性を維持する必要があります。

例4-1: パーティション分割関数を使用して、COHASHパーティション分割テーブルの異なるパーティションキー列の値の類似性を定義します

注文テーブルのorder_id列とbuyer_id列が同じ行に同じ最後の6文字を含むと仮定します。 order_id列とbuyer_id列の最後の6文字で注文テーブルを分割し、同じ行の列の同等のクエリ条件を同じパーティションにルーティングする場合は、次のステートメントを実行します。

テーブルの作成t_orders (
 id bigint not null auto_increment, 
 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; 

例4-2: RANGE_HASH構文糖を使用してPolarDB-X 1.0インスタンスをPolarDB-X 2.0インスタンスに移行する

PolarDB-X 1.0インスタンスをPolarDB-X 2.0インスタンスに移行する場合。 ソースインスタンスには、range_hashシャーディングスキーマを使用する注文テーブルがあります。 このテーブルは、DBPARTIITION by RANGE_HASH('order_id','buyer_id', 6) 構文を使用して定義されます。 この場合、AUTOモードのターゲットインスタンスのデータベース内のテーブルに対応するパーティションテーブルは、次のステートメントを使用して定義されます。

テーブル注文を作成する (
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint、
 ...
 主キー (id)
)
RANGE_HASHによるパーティー (order_id, buyer_Id,6)
パーティー8; 

PolarDB-Xは、RANGE_HASH構文を対応するCOHASHパーティション定義に自動的に変換します。 たとえば、PolarDB-Xは、上記のステートメントのRANGE_HASH(order_id, buyer_Id,6) 句を次のCOHASHパーティション分割定義に自動的に変換します。

テーブル注文を作成する (
 id bigint not null auto_increment, 
 buyer_id bigint,
 order_id bigint、
 ...
 主キー (id)
)
CO_HASHによるパーティー (
 	RIGHT('order_id',6) /* c1列の値の最後の6文字でテーブルを分割します。*/,
 	RIGHT('buyer_id',6) /* c2列の値の最後の6文字でテーブルを分割します。* /
)
パーティー8; 

COHASHパーティショニング、HASHパーティショニング、およびKEYパーティショニングの比較

COHASH分割タイプは、HASHおよびKEY分割タイプと同様である。 次の表は、タイプを比較しています。

使用上の注意

• 異なるパーティションキー列の値の類似性を確認する必要があります。 パーティションテーブルはルーティング結果のみをチェックします。 COHASHパーティションテーブルのさまざまなパーティションキー列の値は、ユーザーによって類似性が維持されます。 したがって、各行のテーブルの異なるパーティションキー列の値は、同じパーティションにルーティングする必要があります。 しかしながら、異なるパーティションキー列の値の間の類似性が破壊される可能性がある。 異なるパーティションキー列の値の類似性を確認する必要があります。 PolarDB-Xはルーティング結果のみをチェックし、類似性はチェックしません。

  たとえば、c1列とc2列の値の最後の4文字が同じであることを指定します。 c1=1001234およびc2=1320がシャード0にルーティングされる場合、insert (c1,c2) 値 (100234,1320) がサポートされます。 ただし、列値の最後の4文字は異なります。

• DLMステートメントを使用してパーティションキー列を変更すると、制限が課されます。 COHASHパーティションテーブルの異なるパーティションキー列の値は似ています。 したがって、誤ったデータの配布を防ぐために、DML文を使用してテーブルのパーティションキー列の値を変更する場合、PolarDB-Xは次の制限を課します。

  • INSERTまたはREPLCAEステートメントのvalues句の同じ行にある異なるパーティションキー列の値が異なるパーティションにルーティングされている場合、値を挿入できず、エラーが報告されます。

  • UPDATEステートメントまたはUPSERTステートメントのSET句を使用して複数のパーティションキー列の値を変更する場合は、すべてのパーティションキー列の値を変更する必要があります。 たとえば、c1列とc2列はパーティションキー列です。 UPDATE t1 SET c1='xx',c2='yy' WHERE id=1文を使用して、列の値を変更できます。 SET句を使用して複数のパーティションキー列の値を変更した後、列の新しい値が異なるパーティションにルーティングされた場合、UPDATEまたはUPSERTステートメントは禁止され、エラーが報告されます。

  • COHASHパーティショニングタイプをGSIテーブルに使用した後、INSERTまたはUPDATE操作など、プライマリテーブルで実行されたすべてのDML操作により、同じ行のプライマリテーブルのGSIテーブルの異なるパーティションキー列の値が異なるパーティションにルーティングされる場合、操作も禁止され、エラーが報告されます。

• COHASHパーティションテーブルのパーティションキー列のプレフィックスは0です。 COHASHパーティションテーブルの異なるパーティションキー列の値は似ています。 したがって、列は、SUBSTR、LEFT、またはRIGHTなどの分割関数によって定義される必要があります。 整数型のいくつかの桁が切り捨てられた後、プレフィックス0が生成されます。 たとえば、c1列とc2列の値の最後の4文字が同じであることを指定します。 c1=1000034およびc2=34の場合、c1列値の最後の4文字は「0034」です。 整数型を使用するCOHASHパーティションテーブルのパーティションキー列のすべての元の値が切り捨てられた後、元の値は新しい値に対応する整数に自動的に変換され、ルーティングされます。 したがって、文字列「0034」は文字列「34」に変換される。 次に、文字列「34」のハッシュが計算され、パーティションにルーティングされる。 このようにして、文字列「0034」のプレフィックスが自動的に処理されます。

パーティション分割関数の制限

• 右

• 左

• SUBSTR

データ型の制限

• 整数型: BIGINT、BIGINT UNSINGEDINT、INT、INT UNSINGED、MEDIUMINT、MEDIUMINT UNSINGED、SMALLINT、SMALLINT UNSINGED、TINYINT、およびTINYINT UNSINGED。

• 固定小数点タイプ: DECIMAL。 このデータ型の小数部はゼロでなければなりません。

• 日付と時刻のタイプ: サポートされていません。

• String型: CHARとVARCHR。

構文の制限

• パーティショニング関数がパーティションキー列に使用されている場合、その列では複数のネストされたパーティショニング関数を使用できません。 例: SUBSTR(SUBSTR(c1,-6),-4)

• RANGE_HASHシンタクチックシュガーを使用する場合、最後の長さの値を負にすることはできません。

• すべてのパーティションキー列の型は、次の用語で同じである必要があります。

  • Charsetsと照合。

  • 長さと精度の定義。

• 既定では、パーティション分割テーブルには最大8,192個のパーティションを含めることができます。

• デフォルトでは、パーティションキーは最大5つのパーティションキー列で構成できます。