[Database] Partitioning
파티셔닝은 데이터베이스의 데이터를 논리적 또는 물리적으로 분할해서 관리하는 작업을 의미한다.
대량의 데이터가 저장되어있는 테이블에서 조회 쿼리를 실행시켰을 때 파티셔널으로 검색 성능을 향상시킬 수 있다.
1,000,000 개의 데이터가 들어있는 테이블에서 id가 700,001 인 데이터를 조회한다고 생각해보자.
세부적인 내용은 DBMS 설정에 따라 다르겠지만.. id 컬럼에 인덱스가 있으면 인덱스를 사용해서 데이터를 조회하겠고.. 인덱스가 없으면 Full Table Scan을 수행한다.
인덱스가 있든 없든 파티셔닝을 사용하면 성능 향상에 도움이 된다.
1,000,000 개의 데이터를 저장하고 있는 테이블을 파티셔닝을 통해 5의 파티션으로 분할한다.
각 파티션은 데이터의 특정 범위를 담당하게 되고, 이런 상황에서 700,001 번째 데이터를 찾는 경우 해당 데이터가 저장된 파티션으로 바로 이동해 목표 데이터를 찾는다.
각 파티션마다 자신만의 인덱스를 가지고 있어 파티셔닝과 인덱싱을 함께 사용해 탐색할 수 있다.
Horizontal Partitioning
위에서 들었던 예시에서 사용한 파티셔닝 기법이다.
테이블의 행을 기준으로 데이터를 분할하는 방식으로, 스키마는 유지하면서 각 파티션에는 데이터의 일부만 저장한다.
쿼리가 자주 접근하는 데이터가 명확하게 구분되는경우 특정 파티션에만 접근할 수 있게 돼 전체 데이터를 스캔할 때 보다 성능이 좋다.
Vertical Partitioning
테이블을 컬럼 단위로 분할하는 파티셔닝 기법이다.
쿼리가 일부 컬럼에만 자주 접근하는 경우 해당 컬럼을 포함하는 테이블을 별도로 분리해서 쿼리 성능을 향상시킨다.
민감한 정보를 포함하는 컬럼을 별도의 테이블로 분리해서 보안성을 높일 수 있다.
샤딩과 다르게 파티셔닝은 쿼리를 작성하고 실행시키는 입장에서 테이블의 어떤 파티션에 쿼리를 보내는지 알 필요 없다.
데이터베이스 내부에서 쿼리를 분석하고 적절한 파티션을 찾아 쿼리를 실행한다.
샤딩의 구현 방법에 따라 다르지만.. 샤딩을 수동으로 구현하는 경우는 개발자가 샤딩 키를 기반으로 어느 샤드에 쿼리를 보내는지 구분하니 라우팅 관련 로직이 필요하다.
테이블을 만들면 자동으로 파티셔닝이 수행되지는 않는다.
파티셔닝 전략을 계획하고 전략에 따라 부모 테이블과 하나 이상의 파티션 테이블을 명시적으로 생성해야 한다.
PostgreSQL 10 버전부터는 선언적 파티셔닝을 지원한다.
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
order_date DATE NOT NULL,
amount DECIMAL NOT NULL
) PARTITION BY RANGE (order_date);
CREATE TABLE orders_2023 PARTITION OF orders
FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
orders 테이블을 생성하면서 order_date 를 기준으로 범위 파티셔닝을 수행함을 선언한다.
이후 구체적인 파티션을 생성해 부모 테이블인 orders 테이블에 파티션을 적용하고, 데이터를 삽입하면 데이터베이스가 알아서 적절한 파티션에 데이터를 배치해준다.
부모 테이블에 설정된 인엑스는 자동으로 파티션에 적용되지는 않고, 필요 시 파티션 테이블마다 인덱스를 따로 생성해 줘야 한다.
글로벌 인덱스는 전체 테이블을 대상으로 하고 모든 파티션에 걸쳐 있는 데이터를 인덱싱하고, 파티션에 설정된 인덱스는 로컬 인덱스로 작동해 해당 파티션 내에서만 유효하다.
데이터베이스마다 Partition Prunning 옵션을 제공해 실행 계획 생성 시 쿼리에 필요하지 않은 파티션을 사전에 제외하도록 설정할 수 있다.
파티셔닝에 대한 전략은 DBMS마다 다르다.
논리적 분할을 사용하는 DBMS는 한 테이블에서 10개의 파티션을 만들 때 하나의 테이블에서 메타데이터를 추가하는 전략을 사용하고,
물리적 분할을 사용하는 DBMS는 실제로 데이터를 서로 다른 물리적 위치에 저장한다.
두 전략 모두 기존 데이터의 양을 증가시키지는 않지만, 각 파티션에 대한 메타데이터와 파티션마다 독립적으로 생성될 수 있는 인덱스로 파티셔닝 도입 시 용량이 조금 더 늘어날 수는 있다.
파티셔닝으로 쿼리 성능을 향상시키고 보안을 향상시킬 수 있지만, 파티셔닝을 사용할 때는 항상 주의해야 한다.
업데이트 쿼리를 실행할 때 파티션 간 행 이동이 발생할 수 있는데, 이 작업은 리소스를 많이 잡아먹고 최악의 경우 실패할 수도 있다.
또한 테이블의 스키마가 변경되는 경우 파티셔닝된 테이블의 구조도 함께 바꿔야 해 SI 같이 변화가 자주 일어나는 환경에서는 파티셔닝을 도입할 때 주의해야 한다.
'Database > Database' 카테고리의 다른 글
[Database] 동시성 처리 (0) | 2024.04.13 |
---|---|
[Database] Sharding (0) | 2024.04.08 |
[Database] B+Tree 자료구조 (0) | 2024.03.30 |
[Database] 내부 저장 구조 (0) | 2024.01.29 |
[Database] ACID (1) | 2024.01.21 |
댓글
이 글 공유하기
다른 글
-
[Database] 동시성 처리
[Database] 동시성 처리
2024.04.13 -
[Database] Sharding
[Database] Sharding
2024.04.08 -
[Database] B+Tree 자료구조
[Database] B+Tree 자료구조
2024.03.30 -
[Database] 내부 저장 구조
[Database] 내부 저장 구조
2024.01.29