Int 범위 파티셔닝

GitLab 16.8에서 도입되었습니다.

설명

Int 범위 파티셔닝은 정수 열을 기반으로 대규모 테이블을 더 작고 관리하기 쉬운 청크로 나누는 기술입니다. 이는 특히 행의 수가 많은 테이블의 경우, 쿼리 성능을 크게 향상시키고, 저장 요구 사항을 줄이며, 유지 관리 작업을 간단화하는 데 유용할 수 있습니다. 이러한 유형의 파티셔닝이 잘 작동하려면 대부분의 쿼리가 특정 int 범위의 데이터에 액세스해야 합니다.

더 자세히 살펴보면, 단순화된 merge_request_diff_files 스키마를 상상해보십시오.

CREATE TABLE merge_request_diff_files (
  merge_request_diff_id INT NOT NULL,
  relative_order INT NOT NULL,
  PRIMARY KEY (merge_request_diff_id, relative_order));

이제 UI의 일반적인 쿼리가 특정 int 범위의 데이터를 표시하는 것으로 상상해보십시오.

SELECT *
FROM merge_request_diff_files
WHERE merge_request_diff_id > 1 AND merge_request_diff_id < 10
LIMIT 100

테이블이 merge_request_diff_id 열에 대해 파티션화되면 기본 테이블은 다음과 같이 보일 것입니다.

CREATE TABLE merge_request_diff_files (
  merge_request_diff_id INT NOT NULL,
  relative_order INT NOT NULL,
  PRIMARY KEY (merge_request_diff_id, relative_order))
PARTITION BY RANGE(merge_request_diff_id);

참고: 파티션화된 테이블의 기본 키는 기본 키 정의의 일부로 파티션 키를 포함해야 합니다.

그리고 테이블의 파티션 목록이 있을 수 있습니다.

merge_request_diff_files_1 FOR VALUES FROM (1) TO (20)
merge_request_diff_files_20 FOR VALUES FROM (20) TO (40)
merge_request_diff_files_40 FOR VALUES FROM (40) TO (60)

각 파티션은 기본 merge_request_diff_files 테이블과 동일한 구조를 가진 별도의 물리적 테이블이지만, 지정된 범위 내에 파티션 키가 있는 행 데이터만 포함합니다. 예를 들어, 파티션 merge_request_diff_files_1에는 merge_request_diff_id 열이 1 이상이고 20 미만인 행 데이터가 포함됩니다.

이제 이전 예시 쿼리를 다시 살펴보면, 데이터베이스는 WHERE를 사용하여 모든 일치하는 행이 merge_request_diff_files_1 파티션에 있는 것을 인식할 수 있습니다. 모든 파티션의 모든 데이터를 검색하는 대신에 대량의 데이터에 대한 액세스를 크게 줄일 수 있습니다.

예시

단계 1: 파티션화된 복사본 생성 (릴리스 N)

첫 번째 단계는 원본 테이블의 파티션화된 복사본을 만들기 위한 마이그레이션을 추가하는 것입니다. 이 마이그레이션은 원본 테이블의 데이터를 기반으로 적절한 파티션을 만들고, 원본 테이블에서 파티션화된 복사본으로 쓰기를 동기화하는 트리거를 설치합니다.

merge_request_diff_commits 테이블을 merge_request_diff_id 열을 기준으로 파티션화하는 예시 마이그레이션은 다음과 같을 것입니다.

class PartitionMergeRequestDiffCommits < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::PartitioningMigrationHelpers

  disable_ddl_transaction!

  def up
    partition_table_by_int_range(
      'merge_request_diff_commits', 
      'merge_request_diff_id', 
      partition_size: 10_000_000,
      primary_key: %w[merge_request_diff_id relative_order]
    )
  end

  def down
    drop_partitioned_table_for('merge_request_diff_commits')
  end
end

이후에 이것이 실행되면, 원본 테이블에서의 삽입, 업데이트 또는 삭제는 새 테이블에서도 복사됩니다. 업데이트 및 삭제의 경우, 해당 행이 파티션화된 테이블에 있는 경우에만 작업이 영향을 미칩니다.

단계 2: 파티션화된 복사본을 백필함 (릴리스 N)

두 번째 단계는 원본 테이블에서 기존 데이터를 파티션화된 복사본으로 백필하는 백포스트-디플로이 마이그레이션을 추가하는 것입니다.

위의 예시를 계속해서, 마이그레이션은 다음과 같을 것입니다.

class BackfillPartitionMergeRequestDiffCommits < Gitlab::Database::Migration[2.2]
  include Gitlab::Database::PartitioningMigrationHelpers

  마일스톤 '16.10'

  disable_ddl_transaction!

  restrict_gitlab_migration gitlab_schema: :gitlab_main

  def up
    enqueue_partitioning_data_migration :merge_request_diff_commits
  end

  def down
    cleanup_partitioning_data_migration :merge_request_diff_commits
  end
end

이 단계는 내부적으로 BATCH_SIZE 및 SUB_BATCH_SIZE가 50,000 및 2,500로 배치 배경 마이그레이션을 예약합니다. 자세한 내용은 Batched Background migrations guide를 참조하세요.

단계 3: 후속 채우기 정리 (릴리스 N+1)

이 단계는 (2) 단계를 포함하는 릴리스 이후 적어도 한 번 발생해야 합니다. 이는 Self-Managed 설치에서 백그라운드 마이그레이션이 제대로 실행될 수 있는 시간을 제공합니다. 이 단계에서는 백그라운드 마이그레이션 이후 정리하는 다른 후발 배포 마이그레이션을 추가합니다. 이는 잔여 작업을 실행하고 삭제된 또는 실패한 작업으로 인해 놓칠 수 있는 데이터를 복사하는 것을 포함합니다.

경고: 2단계와 3단계 사이에 필수적인 중지가 있어야 합니다. 이로써 2단계의 백그라운드 마이그레이션이 성공적으로 완료될 수 있습니다.

다시 한번 예시를 들어서, 이 마이그레이션은 다음과 같이 보일 것입니다:

class CleanupPartitionMergeRequestDiffCommitsBackfill < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::PartitioningMigrationHelpers

  disable_ddl_transaction!

  restrict_gitlab_migration gitlab_schema: :gitlab_main

  def up
    finalize_backfilling_partitioned_table :merge_request_diff_commits
  end

  def down
    # no op
  end
end

이 마이그레이션이 완료된 이후에는, 원본 테이블과 파티션된 테이블이 동일한 데이터를 포함해야 합니다. 원본 테이블에 설치된 트리거는 이후 데이터가 동기화되어 유지되도록 보장합니다.

단계 4: 파티션된 테이블과 비 파티션된 테이블 교체 (릴리스 N+1)

이 단계는 비 파티션된 테이블을 해당 파티션된 복사본으로 교체합니다. 다른 모든 마이그레이션 단계가 성공적으로 완료되고 난 뒤에만 사용해야 합니다.

해당 방법의 일부 제한 사항은 필수적으로 교환 마이그레이션 이전 또는 중에 해결되어야 합니다:

보조 인덱스와 외래 키는 파티션된 테이블에 자동으로 재생성되지 않습니다.
인덱스에 의존하는 일부 유형의 제약조건(UNIQUE 및 EXCLUDE)은 기본 인덱스가 존재하지 않기 때문에 파티션된 테이블에 자동으로 재생성되지 않습니다.
원본 비 파티션된 테이블을 참조하는 외래 키를 파티션된 테이블을 참조하도록 업데이트해야 합니다. 이는 PostgreSQL 11에서 지원되지 않습니다.
원본 테이블을 참조하면서 일어나는 뷰는 파티션된 테이블을 참조하도록 자동으로 업데이트되지 않습니다.

# frozen_string_literal: true

class SwapPartitionMergeRequestDiffCommits < ActiveRecord::Migration[6.0]
  include Gitlab::Database::PartitioningMigrationHelpers

  def up
    replace_with_partitioned_table :audit_events
  end

  def down
    rollback_replace_with_partitioned_table :audit_events
  end
end

이 마이그레이션이 완료된 이후에:

파티션된 테이블이 비 파티션된(원본) 테이블을 대체합니다.
이전에 생성된 동기화 트리거가 삭제됩니다.

파티션된 테이블은 이제 애플리케이션에서 사용할 준비가 되었습니다.

Int 범위 파티셔닝

설명

예시

단계 1: 파티션화된 복사본 생성 (릴리스 N)

단계 2: 파티션화된 복사본을 백필함 (릴리스 N)

단계 3: 후속 채우기 정리 (릴리스 N+1)

단계 4: 파티션된 테이블과 비 파티션된 테이블 교체 (릴리스 N+1)

도움말

기능 사용 가능성과 제품 평가판

도움받기