PolarDB:STR_HASH

注意

STR_HASH関数で作成されたテーブルシャードは、ポイントクエリのシナリオにのみ適用できます。 サービスの範囲クエリでは、テーブル全体のスキャンがトリガーされ、応答が遅くなります。

制限事項

• パーティション分割キーは、文字列 (CHARまたはVARCHAR) である必要があります。
• STR_HASH関数のパラメーターは、テーブルの作成後は変更できません。
• PolarDB-X 1.0インスタンスのバージョンは5.3.5以降である必要があります。

シナリオ

• STR_HASH関数は、1つのテーブルまたはデータベースシャードのみが1つのパーティショニングキーの値に対応する正確なルーティングが必要なシナリオに適用できます。 この値は文字列でなければなりません。

  たとえば、インターネット金融アプリケーションは、YYYYMM関数を使用して、年と月ごとにデータをデータベースシャードに分割し、次に、注文IDごとにデータをテーブルシャードに分割します。 このアプリケーションでは、各注文IDの最後の3文字は、000から999の範囲の整数です。 このアプリケーションは、物理データベースシャード内の各注文IDの最後の3文字を1つの物理テーブルシャードにルーティングするために必要です。 したがって、アプリケーションはYYYYMM関数を使用してデータをデータベースシャードに分割し、次にSTR_HASH関数を使用してデータをテーブルシャードに分割します。 アプリケーションの要件を満たすために、各データベースシャードには1,024テーブルシャードが含まれています。 必要なシャードを作成するには、次のSQL文を使用します。

  テーブルtest_str_hash_tbを作成する (    
      id int NOT NULL AUTO_INCREMENT,
      order_id varchar (30) NOT NULL, 
      create_time datetime DEFAULT NULL、
      主キー (id)
  ) エンジン=InnoDBデフォルト料金=utf8
  YYYYMMによるdbpartition ('create_time')
  tbpartition by STR_HASH('order_id', -1,3, 1) tbpartitions 1024; 

  このSQLステートメントは、各注文IDの最後の3文字を見つけ、それらを整数 (000〜999) に変換してから、モジュロ演算を実行して適切なテーブルシャードを計算します。 テーブルシャードの総数は1,024です。 ルーティング結果により、各物理テーブルシャードが1つのパーティショニングキーのみの値に対応することが保証されます。 PolarDB-X 1.0のデフォルトのパーティション分割関数は、hashCode関数が文字列を一意ではない整数に変換する可能性があるため、この効果を達成できません。 1つの物理テーブルシャードは、複数のパーティショニングキーの値に対応し得る。

• ポイントクエリの典型的なシナリオ

  STR_HASH関数は、文字列がパーティショニングキーとして使用されるシナリオに適用できます。 ポイントクエリは、IDによるトランザクション注文やロジスティクス注文のクエリなど、ほとんどのシナリオで使用されます。

構文

STR_HASH関数を使用すると、開始位置の添字と終了位置の添字を指定して、分割キーの文字列値を部分文字列に切り捨てることができます。 次に、この部分文字列を文字列または整数入力として使用して、特定の物理データベースシャードとテーブルシャードのルートを計算します。 詳細については、次の構文をご参照ください。

STR_HASH( shardKey [, startIndex, endIndex [, valType [, randSeed ] ] ] )

例

order_idのデータ型がVARCHAR(32) であるとします。 データを4つのデータベースシャードと8つのテーブルシャードに分割するためのパーティショニングキーとしてorder_idを使用します。

• order_id文字列の最後の4文字を整数として使用して、データベースシャードとテーブルシャードのルートを計算するとします。 次のSQL文を使用して、テーブルを作成できます。

  create table test_str_hash_tb ()    
      id int NOT NULL AUTO_INCREMENT,
      order_id varchar (32) NOT NULL, 
      create_time datetime DEFAULT NULL、
      主キー (id)
  ) エンジン=InnoDBデフォルト料金=utf8
  STR_HASHによるdbpartition ('order_id', -1,4, 1)
  tbpartition by STR_HASH('order_id', -1,4, 1) tbpartitions 2; 

• order_id文字列の3文字目 (starIndex = 2) から7文字目 (endIndex = 7) までの文字を部分文字列として使用して、データベースとテーブルシャードのルートを計算するとします。 次のSQL文を使用して、テーブルを作成できます。

  create table test_str_hash_tb ()    
      id int NOT NULL AUTO_INCREMENT,
      order_id varchar (32) NOT NULL, 
      create_time datetime DEFAULT NULL、
      主キー (id)
  ) エンジン=InnoDBデフォルト料金=utf8
  STR_HASHによるdbpartition ('order_id', 2, 7)
  tbpartition by STR_HASH('order_id ', 2,7) tbpartitions 2; 

• order_id文字列の最初の5文字を部分文字列として使用して、データベースシャードとテーブルシャードのルートを計算するとします。 次のSQL文を使用して、テーブルを作成できます。

  create table test_str_hash_tb ()    
      id int NOT NULL AUTO_INCREMENT,
      order_id varchar (32) NOT NULL, 
      create_time datetime DEFAULT NULL、
      主キー (id)
  ) エンジン=InnoDBデフォルト料金=utf8
  STR_HASHによるdbpartition ('order_id', 5, -1)
  tbpartition by STR_HASH('order_id ', 5, -1) tbpartitions 2; 

よくある質問

Q: dbpartition by STR_HASH(order\_id) とdbpartition by HASH(order\_id) の違いは何ですか?

A: STR_HASHとHASHはどちらも文字列の値を使用して、データベースシャードとテーブルシャードのハッシュルートを計算します。 ただし、それらは異なるルートアルゴリズムを使用します。 STR_HASHを使用すると、元の文字列を部分文字列に切り捨てることができ、これを使用してテーブルを作成できます。 STR_HASHは、文字列のハッシュ値に基づいてデータベースシャードとテーブルシャードのルートを計算するときにもUNI_HASHアルゴリズムを使用します。 HASHは、単純なモジュロ演算を実行して、文字列のハッシュ値を取得する。