리뉴얼된 서비스를 테스트 및 안전하게 배포하기 위한 여러 가지 작업이 존재하는데 이때 고려해야 하는 상황이 생겼다.
기존 프로덕션 서비스를 이용하는 데이터베이스 이관
테이블과 여러 칼럼이 변경되었으며 여러 인덱스 및 제약조건이 생겼다.
만약 이를 바로 운영 디비에 붙여버리면 앱의 이전 버전 사용자들은 오류가 발생한다.
따라서 기존 디비를 잠시 보존하고 신규 버전 앱 사용자들이 이용할 수 있는 버전의 데이터베이스가 필요했다.
또한 데이터 이관을 진행하기 위해 데이터 이관 스크립트를 작성하고 이를 테스트해야 한다.
배포 전 충분한 QA 테스트가 필요한 상황이라 리뉴얼이 반영된 전체 서비스를 구성해야 한다.
현재 팀에게 주어진 리소스는 EC2 인스턴스 한 개, RDB(운영, 개발), 로컬 PostgreSQL, S3
그래서 골똘히 생각하는데 이전에 오라클을 이용했을 때 스키마분리(유저)하여 별도의 테이블을 만들어 논리 데이터베이스를 사용했던 것 같아서 PostgreSQL도 이러한 개념이 있지 않을까 해서 정리해본다.
Schema
PostgreSQL에서는 동일한 데이터베이스에서 여러 스키마를 만들 수 있다.
테이블이나 함수들은 다른 스키마라면 같은 이름의 테이블을 만들 수 있다.
간단히 문법을 알아보자.
CREATE SCHEMA schema_name;
CREATE SCHEMA schema_name AUTHORIZATION username;
ALTER SCHEMA username OWNER TO new_username;
DROP SCHEMA schema_name CASCADE;
PostgreSQL의 데이터베이스 스키마 및 테이블의 관계에 대해 알아보자.
스키마라는 여러 함수나 테이블을 그룹화하는 개념이다. PostgreSQL을 설치하면 public이라는 스키마가 자동적으로 생성된다.
이러한 public 스키마는 기본적으로 모든 역할에 권한과 CREATE 권한이 부여되며, public 스키마에 어떤 역할도 테이블을 생성할 수 있다.
내게 가장 중요한점은 동일한 데이터베이스에도 동일한 테이블 이름으로 테이블을 만들 수 있다는 점이다.
(이를 JPA에서 매핑 시키는 방법도 알아보자)
그럼 어떻게 테이블을 만드는 가에 대해서 알아보자.
기본적인 CREATE TABLE 명령으로 테이블을 만들고 스키마 이름을 생략하면 기본적으로 public 스키마에 테이블이 만들어진다.
데이터 그립 쓰는데 UI가.....
기본적으로 public 스키마가 생성되어 있다.
간단히 스키마를 만들어보자. 데이터 그립에서 \dn 명령어가 먹히질 않는다.. 팁 좀..
select nspname from pg_catalog.pg_namespace;
스키마를 만들 경우 작성된 스키마의 소유자는 스키마를 만든 사람이다. 하지만 스키마를 만들 때 다른 역할을 지정하여 스키마를 만들 수 있다.
잠깐 JPA 속성을 통해 스키마를 변경하여 테스트를 좀 진행해보자.
spring.jpa.properties.hibernate.default_schema: myschema
spring.datasource.hikari.schema=your_scheme
일단 히카리 커넥션 풀 사용해서 그런지 밑에 속성 값도 잘 적용되고, 위에 것도 적용된다..
stackoverflow에서는 의견이 갈리는 것 같다...
그런데 아마 위에 속성을 사용하는 것을 보니 위 속성을 사용하는 커넥션 풀과 관계없이 스키마 설정이 되도록 변경된 것 같긴 하다. 위의 속성을 사용을 추천한다.
동일 이름의 테이블이 생성되었다.
실제 로그인데 oracle과 비슷하게 schema.table로 접근하는 것 같다.
다시 돌아오자면 postgresql의 schema는 논리적인 데이터베이스이다.
그래서 궁금했다. 논리적인 데이터베이스가 스키마면 다른 스키마와 조인이 될까?
select * from item i join oncerun.item_type oi on i.id = oi.item_id;
조인이 되더라. 근데 사실 이는 거의 사용이 불가능하다. 외래 키 제약조건을 걸고 사용하는데 다른 스키마의 테이블과 제약조건을 건다?
쓰읍.. 잘 모르겠다. 하여튼 제약조건이 없다면 다른 스키마의 테이블에 접근하여 조인은 되는 것 같다.
이걸 이용해서 데이터 이관 스크립트를 작성하면 은근히 편할지도 모른다.
select * from pg_namespace join pg_authid pa on pg_namespace.nspowner = pa.oid;
alter schema oncerun OWNER TO oncerun;
superuser 권한 주면 다른 소유자의 스키마에 접근하는 것에 대해 문제없는 것으로 보인다.
이를 통해 로컬에 스키마로 테스트한 다음 적용해야겠다.
댓글