분할된 테이블에 데이터 아카이브 - AWS 권장 가이드

분할된 테이블에 데이터 아카이브

MySQL은 InnoDB 스토리지 엔진에 대한 분할을 지원하며, 이 기능을 통해 대용량 테이블을 분할할 수 있습니다. 분할된 테이블에서 작동하는 SQL은 전체 테이블을 읽지만 테이블 내 파티션은 별도의 물리적 테이블로 저장됩니다. 이 방식을 사용하면 행 단위 삭제를 수행하지 않고도 테이블에서 불필요한 파티션을 자유롭게 제거할 수 있으므로 데이터베이스에서 기록 행을 아카이브할 수 있습니다.

다음 예제 코드를 고려합니다. TABLE orders는 orderprocessing 스키마에 있습니다. 해당 기록 데이터는 2021년 이전에 속하는 데이터를 포함하는 파티션 phistorical에 있습니다. 동일한 테이블에서 애플리케이션 수준 핫 데이터는 2022년 매월 라이브 파티션에 존재합니다. 파티션 phistorical에서 데이터를 아카이브하려면 archive 스키마에서 동일한 구조의 table orders_2021_and_older 아카이브를 생성할 수 있습니다. 그런 다음 MySQL EXCHANGE PARTITION을 사용하여 phistorical 파티션을 해당 테이블로 이동할 수 있습니다. 아카이브 테이블은 분할되지 않습니다. 아카이브한 후 데이터를 확인하고 Amazon S3로 이동할 수 있습니다.

CREATE TABLE orders (
      orderid bigint NOT NULL AUTO_INCREMENT,
      customerid bigint DEFAULT NULL,
      ............
      ............
      order_date date NOT NULL,
      PRIMARY KEY (`orderid`,`order_date`))
    PARTITION BY RANGE (TO_DAYS(order_date)) (
          PARTITION pstart   VALUES LESS THAN (0),
          PARTITION phistorical VALUES LESS THAN (TO_DAYS('2022-01-01')),
          PARTITION p2022JAN VALUES LESS THAN (TO_DAYS('2022-02-01')),
          PARTITION p2022FEB VALUES LESS THAN (TO_DAYS('2022-03-01')),
          PARTITION p2022MAR VALUES LESS THAN (TO_DAYS('2022-04-01')),
          PARTITION p2022APR VALUES LESS THAN (TO_DAYS('2022-05-01')),
          PARTITION p2022MAY VALUES LESS THAN (TO_DAYS('2022-06-01')),
          PARTITION p2022JUN VALUES LESS THAN (TO_DAYS('2022-07-01')),
          PARTITION p2022JUL VALUES LESS THAN (TO_DAYS('2022-08-01')),
          PARTITION p2022AUG VALUES LESS THAN (TO_DAYS('2022-09-01')),
          PARTITION p2022SEP VALUES LESS THAN (TO_DAYS('2022-10-01')),
          PARTITION p2022OCT VALUES LESS THAN (TO_DAYS('2022-11-01')),
          PARTITION p2022NOV VALUES LESS THAN (TO_DAYS('2022-12-01')),
          PARTITION p2022DEC VALUES LESS THAN (TO_DAYS('2023-01-01')),
          PARTITION pfuture       VALUES LESS THAN MAXVALUE
      );
CREATE TABLE orders_2021_and_older (
        orderid bigint NOT NULL AUTO_INCREMENT,
        customerid bigint DEFAULT NULL,
        ............
        ............
        order_date date NOT NULL,
        PRIMARY KEY (`orderid`,`order_date`));
mysql> alter table orderprocessing.orders exchange partition phistorical with table archive.orders_2021_and_older;
  Query OK, 0 rows affected (0.33 sec)

EXCHANGE PARTITION 기능을 사용하여 기록 데이터를 아카이브하는 경우 다음 모범 사례를 따르는 것이 좋습니다.

  • 애플리케이션에 아카이브 데이터를 저장하기 위해 별도의 스키마를 생성합니다. 이 스키마에는 아카이브된 데이터를 보관할 아카이브 테이블이 포함됩니다. 아카이브 스키마의 아카이브 테이블은 인덱스 및 프라이머리 키를 포함하여 라이브 테이블과 구조가 동일해야 합니다. 그러나 대상 아카이브 테이블은 분할된 테이블일 수 없습니다. MySQL에서는 분할된 두 테이블 사이에서 파티션을 교환할 수 없습니다.

  • 아카이브 테이블의 이름 지정 규칙을 따릅니다. 그러면 아카이브 테이블에 저장된 기록 데이터를 식별하는 데 도움이 됩니다. 감사 태스크를 수행하거나이 데이터를 Amazon S3로 이동하는 작업을 설계할 때 유용합니다.

  • Aurora MySQL 호환 라이터, Amazon RDS for MySQL 또는 Amazon RDS for MariaDB 인스턴스로 들어오는 트래픽이 없는 경우 가동 중지 시간 동안 EXCHANGE PARTITION 데이터 정의 언어(DDL) 문을 수행합니다.

    애플리케이션 또는 마이크로서비스에서 트래픽이 적은 기간에 EXCHANGE PARTITION을 실행할 수도 있습니다. 그러나 분할된 테이블에 쓰기가 없고 선택 항목이 없거나 거의 없어야 합니다. 기존의 장기 실행 select 쿼리로 인해 EXCHANGE PARTITION DDL이 대기하여 데이터베이스에서 리소스 경합이 발생할 수 있습니다. 시스템에서 EXCHANGE PARTITION을 실행하기 전에 이러한 모든 조건이 충족되는지 확인하는 스크립트를 설계합니다.

애플리케이션 설계가 분할된 데이터를 지원할 수 있고 현재 분할되지 않은 테이블이 있는 경우 데이터 아카이브를 지원하기 위해 데이터를 분할된 테이블로 이동하는 방법을 고려합니다. 자세한 내용은 MySQL 설명서를 참조하세요.