개요#

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')
=> #

장점#

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

1. ActiveRecord 통합: 복잡한 PostgreSQL 메타데이터 조회가 익숙한 ActiveRecord 모델로 감싸집니다.
2. 유지 관리 자동화: 데이터베이스 유지 관리 작업을 Ruby 코드로 자동화할 수 있습니다.
3. 모니터링: 데이터베이스 상태 모니터링과 메트릭 수집이 간단해집니다.
4. 일관성: 데이터베이스 작업에 표준화된 인터페이스를 제공합니다.

단점#

1. 성능 부담: 뷰는 접근 시점의 구체화와 연산 때문에 추가 조회 부담을 일으킬 수 있습니다.
2. 디버깅 복잡성: Ruby/Rails 계층과 PostgreSQL 계층을 모두 따라가야 하므로 디버깅이 더 어려워질 수 있습니다.
3. 마이그레이션 난이도: 스키마 마이그레이션 중에는 뷰를 신중하게 관리해야 합니다. 기반 테이블이 바뀌면 뷰도 그에 맞게 갱신되도록 해야 합니다. Rails 마이그레이션은 일반 테이블만큼 뷰를 매끄럽게 처리하지 못합니다.
4. 유지 관리 부담: 뷰는 데이터베이스 스키마에서 유지 관리해야 할 프로그래밍 언어 계층을 하나 더 추가합니다.
5. 테스트 복잡성: 뷰에 의존하는 코드를 테스트할 때는 대개 더 많은 테스트 준비가 필요합니다.

가이드라인#

뷰를 다룰 때는 원시 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 System Catalogs
• PostgreSQL Views