디렉터리 분할

설명

테이블에 파티션 키 열을 추가합니다. 다음 제약 조건에 파티션 키를 포함합니다.

  • 주 키.
  • 테이블을 파티션하는 외래 키 모두.
  • 모든 고유 제약 조건.

예제

단계 1 - 파티션 키 추가

파티션 키 열을 추가합니다. 예를 들어, Rails 마이그레이션에서: 

class AddPartitionNumberForPartitioning < Gitlab::Database::Migration[2.1]
  enable_lock_retries!
  
  TABLE_NAME = :테이블_이름
  COLUMN_NAME = :파티션_ID
  DEFAULT_VALUE = 100
  
  def change
    add_column(TABLE_NAME, COLUMN_NAME, :bigint, default: 100)
  end
end

단계 2 - 필요한 인덱스 생성

파티션 키 열을 포함한 인덱스를 추가합니다. 예를 들어, Rails 마이그레이션에서: 

class PrepareIndexesForPartitioning < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  TABLE_NAME = :테이블_이름
  INDEX_NAME = :인덱스_이름
  
  def up
    add_concurrent_index(TABLE_NAME, [:id, :partition_id], unique: true, name: INDEX_NAME)
  end
  
  def down
    remove_concurrent_index_by_name(TABLE_NAME, INDEX_NAME)
  end
end

단계 3 - 고유 제약 조건 강화

파티션 키 열을 포함한 모든 고유 인덱스를 변경합니다. 주 키 인덱스를 포함합니다. 다음과 같이, Rails 마이그레이션에서: 

class PrepareUniqueContraintForPartitioning < Gitlab::Database::Migration[2.1]
  disable_ddl_transaction!
  
  TABLE_NAME = :테이블_이름
  OLD_UNIQUE_INDEX_NAME = :이전_고유_인덱스_이름
  NEW_UNIQUE_INDEX_NAME = :새로운_인덱스_이름
  
  def up
    add_concurrent_index(TABLE_NAME, [:id, :partition_id], unique: true, name: NEW_UNIQUE_INDEX_NAME)
    
    remove_concurrent_index_by_name(TABLE_NAME, OLD_UNIQUE_INDEX_NAME)
  end
  
  def down
    add_concurrent_index(TABLE_NAME, :id, unique: true, name: OLD_UNIQUE_INDEX_NAME)
    
    remove_concurrent_index_by_name(TABLE_NAME, NEW_UNIQUE_INDEX_NAME)
  end
end

(TO BE CONTINUED…)

단계 7 - 외부 키를 상위 테이블로 재지정

초기 파티션을 참조하는 테이블은 이제 상위 테이블을 가리키도록 업데이트해야 합니다. 이 변경을 하지 않으면 해당 테이블의 레코드들은 다음 파티션의 행을 찾을 수 없게 됩니다. 왜냐하면 그들은 초기 파티션에서 그것들을 찾으려고 할 것이기 때문입니다.

단계:

  • 파티션된 테이블에 외부 키를 추가하고 비동기적으로 유효성을 검증하세요, 예시를 참고하세요.
  • GitLab.com에서 비동기 검증이 완료된 후 동기적으로 유효성을 검증하세요, 예시를 참고하세요.
  • 이전 외부 키를 제거하고 새로운 외부 키를 이전 이름으로 변경하세요, 예시를 참고하세요.

단계 8 - 파티션 간 ID 고유성 보장

모든 고유성 제한은 파티션 키를 포함해야 하므로 파티션 간에 중복된 ID가 발생할 수 있습니다. 이 문제를 해결하기 위해 ID 값을 설정하는 것은 데이터베이스만이 허용하고, 시퀀스를 사용하여 고유한 값을 생성하도록 보장합니다. 왜냐하면 시퀀스는 고유한 값을 생성할 것이기 때문입니다.

예시: 

class EnsureIdUniquenessForPCiBuilds < Gitlab::Database::Migration[2.1]
  include Gitlab::Database::PartitioningMigrationHelpers::UniquenessHelpers
  
  enable_lock_retries!
  
  TABLE_NAME = :p_ci_builds
  SEQ_NAME = :ci_builds_id_seq
  
  def up
    ensure_unique_id(TABLE_NAME, seq: SEQ_NAME)
  end
  
  def down
    revert_ensure_unique_id(TABLE_NAME, seq: SEQ_NAME)
  end
end

단계 9 - 파티션된 테이블 분석 및 새 파티션 생성

autovacuum 데몬은 파티션된 테이블을 처리하지 않습니다. 따라서 테이블 계층 구조의 통계를 최신 상태로 유지하기 위해 주기적으로 매뉴얼 ANALYZE를 실행해야 합니다.

Ci::Partitionable을 사용하여 partitioned: true 옵션으로 구현한 모델은 기본적으로 매주 분석됩니다. 이를 가능하게 하고 새로운 파티션을 생성하려면 PostgreSQL 초기화 파일에 모델을 등록해야 합니다.

단계 10 - 애플리케이션에서 파티션된 테이블 사용으로 업데이트

이제 상위 테이블이 준비되었으므로 애플리케이션을 업데이트하여 사용할 수 있습니다: 

class Model < ApplicationRecord
  self.table_name = :partitioned_table
end

모델에 따라, 변경 관리 이슈를 사용하는 것이 더 안전할 수 있습니다.