큰 데이터 볼륨의 분산은 두 가지 주요 방법으로 달성됩니다:
파티셔닝 (partitioning): 하나의 데이터베이스 내에서 특정 키(보통 날짜나 값의 범위)에 따라 테이블을 논리적으로 나누는 것입니다. 이를 통해 개별 파티션에 대해 빠른 작업을 수행할 수 있으며, 검색 속도가 빨라지고 유지 관리가 용이해집니다.
샤딩 (sharding): 특정 알고리즘에 따라 데이터를 여러 데이터베이스/서버에 물리적으로 분할하는 것입니다. 테이블이 여러 클러스터에 실제로 복사되어 각각의 데이터 세그먼트를 포함합니다.
파티셔닝의 장점은 요청 라우팅에 대한 별도의 비즈니스 로직을 유지 관리할 필요가 없다는 것이며, 애플리케이션에 대해 "투명하게" 진행됩니다; 단점은 단일 DBMS의 제한된 기능성입니다.
샤딩은 수평적 확장을 제공하지만(제한은 서버 수에만 의존함) 복잡한 동기화, 라우팅 및 "샤드 간" 요청 처리가 필요합니다.
-- 기본 파티셔닝 테이블 CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT, order_date DATE ) PARTITION BY RANGE (order_date); CREATE TABLE orders_2023 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
질문: 주요 테이블을 잠그지 않고 파티션 간에 행을 "실시간으로" 이동할 수 있습니까?
답변: 대부분의 DBMS에서 파티션 간에 행을 이동하는 것은 삭제 및 삽입의 동등한 작업으로 간주되며, 이러한 작업은 특히 트리거 또는 외부 키가 관련된 경우 행과 테이블 자체를 잠글 수 있습니다. 이는 대량의 데이터 "롤오버" 처리 시 유의해야 할 사항입니다.
-- ALTER TABLE ... MOVE PARTITION은 일반적으로 잠금에 대해 특히 주의가 필요합니다. 부하가 적은 시간에 수행하는 것이 좋습니다.
이야기 1: 프로젝트는 모든 파티션에 대해 동시에 분석 보고서를 작성하여, 수천 개의 파티션을 가진 섹션화된 테이블로 인해 거대 실행 계획이 생성되는 것을 고려하지 않았습니다. 결과적으로 실행 시간 급증과 서버 부담 증가가 발생했습니다. 해결책: 쿼리의 실제 비즈니스 축에 해당하는 파티션 수를 늘리고 스캔 계획을 최적화했습니다.
이야기 2: 샤딩을 추가할 때 샤드 간의 식별자 비유일성을 고려하지 않았습니다. 샤드 간 집계 시 키 충돌이 자주 발생했습니다.
이야기 3: "오래된" 파티션을 자동으로 아카이브하는 과정에서 외부 관계를 다시 확인하지 않고 삭제하여 다른 테이블과의 연결이 끊기고 "활성" 데이터의 일부가 손실되었습니다. 이후 모든 파티션 삭제 로직을 연결성에 대한 다중 테스트로 다시 작성했습니다.