26.2.5 KEY Partitioning

26.2.5 KEY Partitioning

key에 의한 partitioning은 hash에 의한 partitioning과 유사하지만, hash partitioning이 사용자 정의 표현식을 사용하는 것과 달리, key partitioning을 위한 해싱 함수는 MySQL 서버에서 제공합니다. NDB Cluster는 이 목적을 위해 MD5()를 사용합니다. 다른 스토리지 엔진을 사용하는 테이블의 경우, 서버는 자체 내부 해싱 함수를 사용합니다.

CREATE TABLE ... PARTITION BY KEY에 대한 구문 규칙은 hash로 partitioning된 테이블을 생성하는 것과 비슷합니다. 주요 차이점은 다음과 같습니다:

• HASH 대신 KEY를 사용합니다.

• KEY는 0개 이상의 컬럼 이름 목록만 받습니다. partitioning key로 사용되는 컬럼들은, 테이블에 프라이머리 키가 있는 경우, 그 프라이머리 키의 일부 또는 전체를 구성해야 합니다. 어떤 컬럼 이름도 partitioning key로 지정되지 않은 경우, 테이블에 프라이머리 키가 있다면 그 프라이머리 키가 사용됩니다. 예를 들어, 다음 CREATE TABLE 문은 MySQL 9.5에서 유효합니다:

1CREATE TABLE k1 (
2      id INT NOT NULL PRIMARY KEY,
3      name VARCHAR(20)
4)
5PARTITION BY KEY()
6PARTITIONS 2;

프라이머리 키는 없지만 유니크 키가 있는 경우, 그 유니크 키가 partitioning key로 사용됩니다:

1CREATE TABLE k1 (
2      id INT NOT NULL,
3      name VARCHAR(20),
4      UNIQUE KEY (id)
5)
6PARTITION BY KEY()
7PARTITIONS 2;

그러나 유니크 키 컬럼이 NOT NULL로 정의되지 않았다면, 위의 문은 실패합니다.

이 두 경우 모두에서 partitioning key는 id 컬럼이지만, SHOW CREATE TABLE의 출력이나 Information Schema PARTITIONS 테이블의 PARTITION_EXPRESSION 컬럼에는 표시되지 않습니다.

다른 partitioning 타입과는 달리, KEY에 의한 partitioning에 사용되는 컬럼은 정수나 NULL 값으로 제한되지 않습니다. 예를 들어, 다음 CREATE TABLE 문은 유효합니다:

1CREATE TABLE tm1 (
2      s1 CHAR(32) PRIMARY KEY
3)
4PARTITION BY KEY(s1)
5PARTITIONS 10;

위의 문은 다른 partitioning 타입이 지정되었다면 유효하지 않습니다. (이 경우, 단순히 PARTITION BY KEY()를 사용하는 것도 유효하며, s1이 테이블의 프라이머리 키이기 때문에 PARTITION BY KEY(s1)와 동일한 효과를 가집니다.)

이 이슈에 대한 추가 정보는 Section 26.6, “Restrictions and Limitations on Partitioning”을 참조하십시오.

인덱스 프리픽스가 있는 컬럼은 partitioning key에서 지원되지 않습니다. 이는 CHAR, VARCHAR, BINARY, VARBINARY 컬럼들은 프리픽스를 사용하지 않는 한 partitioning key로 사용할 수 있다는 의미입니다. 한편, 인덱스 정의에서 BLOB 및 TEXT 컬럼에는 프리픽스를 반드시 지정해야 하므로, 이 두 타입의 컬럼을 partitioning key로 사용하는 것은 불가능합니다. 프리픽스를 사용하는 컬럼이 하나 이상 포함된 partitioned 테이블에 영향을 주는 어떤 CREATE TABLE 또는 ALTER TABLE 문에 대해, 서버는 오류를 발생시키고 이를 거부합니다. Column index prefixes not supported for key partitioning을 참조하십시오.

참고

NDB 스토리지 엔진을 사용하는 테이블은, 다른 MySQL 스토리지 엔진과 마찬가지로, 테이블의 프라이머리 키를 partitioning key로 사용하여 암묵적으로 KEY에 의해 partitioning됩니다. 만약 NDB Cluster 테이블에 명시적인 프라이머리 키가 없다면, 각 NDB Cluster 테이블에 대해 NDB 스토리지 엔진이 생성하는 “hidden” 프라이머리 키가 partitioning key로 사용됩니다.

NDB 테이블에 대해 명시적인 partitioning scheme을 정의하는 경우, 그 테이블은 명시적인 프라이머리 키를 가져야 하며, partitioning 표현식에 사용되는 모든 컬럼은 이 키의 일부여야 합니다. 그러나 테이블이 컬럼 참조가 없는, 즉 PARTITION BY KEY()와 같은 “empty” partitioning 표현식을 사용하는 경우에는 명시적인 프라이머리 키가 필요하지 않습니다.

이 partitioning은 -p 옵션과 함께 ndb_desc 유틸리티를 사용하여 확인할 수 있습니다.

주의

key-partitioned 테이블에 대해서는 ALTER TABLE DROP PRIMARY KEY를 실행할 수 없습니다. 이렇게 하면 ERROR 1466 (HY000): Field in list of fields for partition function not found in table 오류가 발생하기 때문입니다. 이는 KEY에 의해 partitioning된 NDB Cluster 테이블에는 해당되지 않습니다. 이런 경우에는 “hidden” 프라이머리 키를 테이블의 새 partitioning key로 사용하여 테이블이 재구성됩니다. Chapter 25, MySQL NDB Cluster 9.5를 참조하십시오.

테이블을 linear key로 partitioning하는 것도 가능합니다. 다음은 간단한 예입니다:

1CREATE TABLE tk (
2    col1 INT NOT NULL,
3    col2 CHAR(5),
4    col3 DATE
5)
6PARTITION BY LINEAR KEY (col1)
7PARTITIONS 3;

LINEAR 키워드는 partition 번호를 모듈러 산술 대신 2의 거듭제곱 알고리즘을 사용하여 구한다는 점에서, HASH partitioning의 경우와 마찬가지로 KEY partitioning에도 동일한 효과를 가집니다. 이 알고리즘과 그 의미에 대한 설명은 Section 26.2.4.1, “LINEAR HASH Partitioning”을 참조하십시오.