26.2.4 HASH Partitioning

26.2.4 HASH Partitioning

26.2.4.1 LINEAR HASH Partitioning

HASH에 의한 파티셔닝은 미리 정해진 수의 파티션들 사이에 데이터를 고르게 분산되도록 하는 데 주로 사용됩니다. Range 또는 list 파티셔닝의 경우, 어떤 컬럼 값 또는 컬럼 값들의 집합이 어느 파티션에 저장되어야 하는지를 명시적으로 지정해야 합니다. Hash 파티셔닝에서는 이 결정이 자동으로 처리되며, 사용자는 해시 대상이 되는 컬럼 값이나 컬럼 값을 기반으로 한 표현식, 그리고 파티셔닝된 테이블을 몇 개의 파티션으로 분할할지만 지정하면 됩니다.

HASH 파티셔닝을 사용하여 테이블을 파티셔닝하려면, CREATE TABLE 문에 PARTITION BY HASH (expr) 절을 추가해야 하며, 여기서 _expr_은 정수를 반환하는 표현식입니다. 이는 MySQL의 정수 타입 중 하나인 컬럼 이름일 수 있습니다. 또한 일반적으로 이 뒤에 PARTITIONS num을 사용하게 되며, _num_은 테이블이 분할될 파티션 수를 나타내는 양의 정수입니다.

참고

단순화를 위해, 이어지는 예제들에 나오는 테이블들은 어떤 키도 사용하지 않습니다. 만약 테이블에 유니크 키가 있다면, 이 테이블의 파티셔닝 표현식에 사용된 모든 컬럼은 프라이머리 키를 포함한 모든 유니크 키의 일부여야 한다는 점을 알아두어야 합니다. 자세한 내용은 Section 26.6.1, “Partitioning Keys, Primary Keys, and Unique Keys”를 참고하십시오.

다음 문은 store_id 컬럼에 대해 해싱을 사용하고 4개의 파티션으로 분할되는 테이블을 생성합니다:

1CREATE TABLE employees (
2    id INT NOT NULL,
3    fname VARCHAR(30),
4    lname VARCHAR(30),
5    hired DATE NOT NULL DEFAULT '1970-01-01',
6    separated DATE NOT NULL DEFAULT '9999-12-31',
7    job_code INT,
8    store_id INT
9)
10PARTITION BY HASH(store_id)
11PARTITIONS 4;

PARTITIONS 절을 포함하지 않으면, 파티션 수는 기본적으로 1로 설정됩니다. 숫자 없이 PARTITIONS 키워드만 사용하는 것은 구문 오류를 발생시킵니다.

_expr_으로 정수를 반환하는 SQL 표현식을 사용할 수도 있습니다. 예를 들어, 직원이 채용된 연도에 기반하여 파티셔닝을 하고자 할 수 있습니다. 이는 다음과 같이 수행할 수 있습니다:

1CREATE TABLE employees (
2    id INT NOT NULL,
3    fname VARCHAR(30),
4    lname VARCHAR(30),
5    hired DATE NOT NULL DEFAULT '1970-01-01',
6    separated DATE NOT NULL DEFAULT '9999-12-31',
7    job_code INT,
8    store_id INT
9)
10PARTITION BY HASH( YEAR(hired) )
11PARTITIONS 4;

_expr_은 비상수이면서 비랜덤인 정수 값을 반환해야 하며(즉, 변하지만 결정적이어야 합니다), Section 26.6, “Restrictions and Limitations on Partitioning”에 설명된 금지된 구성 요소를 포함해서는 안 됩니다. 또한 이 표현식은 행이 insert되거나 update될 때마다(또는 경우에 따라 delete될 때) 평가된다는 점을 염두에 두어야 합니다. 이는 매우 복잡한 표현식이 특히 많은 행에 동시에 영향을 주는 작업(예: 배치 insert)을 수행할 때, 성능 문제를 야기할 수 있음을 의미합니다.

가장 효율적인 해시 함수는 단일 테이블 컬럼에 대해 동작하며, 컬럼 값이 증가하거나 감소함에 따라 그 값도 지속적으로 증가하거나 감소하는 함수입니다. 이렇게 되면 파티션 범위에 대한 “프루닝(pruning)”이 가능해집니다. 즉, 표현식이 기반이 되는 컬럼 값과 얼마나 밀접하게 함께 변하느냐에 따라 MySQL이 hash 파티셔닝을 위해 이 표현식을 얼마나 효율적으로 사용할 수 있는지가 결정됩니다.

예를 들어, date_col이 DATE 타입의 컬럼이라고 할 때, TO_DAYS(date_col) 표현식은 date_col 값에 직접적으로 따라 변한다고 말할 수 있습니다. 이는 date_col 값이 변경될 때마다 표현식 값도 일관된 방식으로 변경되기 때문입니다. date_col에 대한 YEAR(date_col) 표현식의 변화는 TO_DAYS(date_col)의 그것만큼 직접적이지는 않습니다. date_col의 가능한 모든 변경이 YEAR(date_col)의 동일한 변화를 유발하는 것은 아니기 때문입니다. 그럼에도 YEAR(date_col)은 좋은 해시 함수 후보입니다. 이는 date_col의 일부에 대해 직접적으로 변하며, date_col의 어떤 변경도 YEAR(date_col)에 불균형적인 변화를 초래하지 않기 때문입니다.

대조를 위해, 타입이 INT인 int_col이라는 컬럼이 있다고 가정해 봅시다. 이제 POW(5-int_col,3) + 6 표현식을 생각해 봅니다. 이는 해시 함수로는 좋지 않은 선택입니다. int_col 값의 변화가 표현식 값의 비례적인 변화를 보장하지 않기 때문입니다. int_col 값을 일정량 변경해도 표현식 값은 매우 다양한 변화를 보일 수 있습니다. 예를 들어, int_col을 5에서 6으로 변경하면 표현식 값은 -1만큼 변하지만, int_col을 6에서 7로 변경하면 표현식 값은 -7만큼 변합니다.

다시 말해, 컬럼 값 대 표현식 값의 그래프가 y=cx(여기서 _c_는 0이 아닌 상수)라는 방정식이 그리는 직선에 얼마나 가깝게 따라가는지가 표현식이 해싱에 얼마나 적합한지를 결정합니다. 이는 표현식이 비선형적일수록 파티션들 사이의 데이터 분포가 더 불균등해지는 경향이 있기 때문입니다.

이론적으로, 둘 이상의 컬럼 값을 포함하는 표현식에 대해서도 프루닝이 가능하지만, 그러한 표현식들 중 어떤 것이 적합한지를 판별하는 것은 상당히 어렵고 시간이 많이 걸릴 수 있습니다. 이러한 이유로, 여러 컬럼을 포함하는 해싱 표현식의 사용은 특히 권장되지 않습니다.

PARTITION BY HASH를 사용할 때, 스토리지 엔진은 표현식 결과의 모듈러스를 기반으로 _num_개의 파티션 중 어느 것을 사용할지를 결정합니다. 다시 말해, 주어진 표현식 _expr_에 대해 레코드가 저장되는 파티션은 파티션 번호 _N_이며, N = MOD(expr, num)입니다. 예를 들어, 테이블 t1이 다음과 같이 정의되어 있고, 4개의 파티션을 가진다고 가정해 봅시다:

1CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
2    PARTITION BY HASH( YEAR(col3) )
3    PARTITIONS 4;

col3 값이 '2005-09-15'인 레코드를 t1에 insert하면, 이 레코드가 저장될 파티션은 다음과 같이 결정됩니다:

1MOD(YEAR('2005-09-01'),4)
2=  MOD(2005,4)
3=  1

MySQL 9.5는 또한 HASH 파티셔닝의 변형인 linear hashing을 지원합니다. 이는 파티셔닝된 테이블에 새 행을 insert할 때, 그 위치를 결정하기 위해 더 복잡한 알고리즘을 사용합니다. 이 알고리즘에 대한 설명은 Section 26.2.4.1, “LINEAR HASH Partitioning”을 참고하십시오.

User가 제공한 표현식은 레코드가 insert되거나 update될 때마다 평가됩니다. 또한 상황에 따라 레코드가 delete될 때도 평가될 수 있습니다.