개요#

GitLab에서는 PostgreSQL 시스템 카탈로그(pg_* 테이블)에 대한 추상화 레이어로 SQL 뷰를 사용합니다. 이를 통해 Rails에서 시스템 카탈로그를 더 쉽게 쿼리할 수 있습니다.

예시#

예를 들어, SQL 뷰 postgres_sequences는 pg_sequence 및 기타 pg_* 테이블에 대한 추상화 레이어입니다. 다음 Rails 모델을 사용하여 쿼리합니다:

module Gitlab
  module Database
    # Backed by the postgres_sequences view
    class PostgresSequence < SharedModel
      self.primary_key = :seq_name

      scope :by_table_name, ->(table_name) { where(table_name: table_name) }
      scope :by_col_name, ->(col_name) { where(col_name: col_name) }
    end
  end
end

이를 통해 Ruby 코드로 데이터베이스 유지보수 작업을 관리할 수 있습니다:

Gitlab::Database::PostgresSequence.by_table_name('web_hook_logs')
=> #

장점#

이러한 뷰를 사용하면 다음과 같은 여러 이점이 있습니다:

• ActiveRecord 통합: 복잡한 PostgreSQL 메타데이터 쿼리를 친숙한 ActiveRecord 모델로 래핑합니다.

• 유지보수 자동화: Ruby 코드를 통한 자동화된 데이터베이스 유지보수 작업을 가능하게 합니다.

• 모니터링: 데이터베이스 상태 모니터링 및 메트릭 수집을 간소화합니다.

• 일관성: 데이터베이스 작업을 위한 표준화된 인터페이스를 제공합니다.

단점#

• 성능 오버헤드: 뷰는 접근 시 구체화(materialization)와 계산으로 인해 추가적인 쿼리 오버헤드를 유발할 수 있습니다.

• 디버깅 복잡성: Ruby/Rails 레이어와 PostgreSQL 모두를 추적해야 하므로 디버깅이 더 어려워질 수 있습니다.

• 마이그레이션 어려움: 스키마 마이그레이션 시 뷰를 신중하게 관리해야 합니다. 기반 테이블이 변경되면 뷰도 그에 따라 업데이트해야 합니다. Rails 마이그레이션은 일반 테이블만큼 뷰를 원활하게 처리하지 않습니다.

• 유지보수 오버헤드: 뷰는 데이터베이스 스키마에서 유지보수해야 할 프로그래밍 언어 레이어를 하나 더 추가합니다.

• 테스트 복잡성: 뷰에 의존하는 코드를 테스트하려면 더 많은 테스트 설정이 필요한 경우가 많습니다.

가이드라인#

뷰를 사용할 때는 원시 SQL 쿼리 대신 적절한 스코프와 관계가 있는 ActiveRecord 모델을 항상 사용하십시오. 뷰는 설계상 읽기 전용입니다. 새 뷰를 추가할 때는 적절한 마이그레이션, 모델, 테스트, 문서가 준비되어 있는지 확인하십시오.

테스트#

뷰를 테스트할 때는 swapout_view_for_table 헬퍼를 사용하여 뷰를 임시로 테이블로 교체하십시오. 이 방법으로 팩토리를 사용하여 뷰가 반환하는 것과 유사한 레코드를 생성할 수 있습니다.

RSpec.describe Gitlab::Database::PostgresSequence do
  include Database::DatabaseHelpers

  before do
    swapout_view_for_table(:postgres_sequences, connection: ApplicationRecord.connection)
  end
end

추가 읽기#

• PostgreSQL 시스템 카탈로그

• PostgreSQL 뷰