프로젝트를 준비하고 있다. DB Schema가 중요한 부분이지만 형상 관리가 되어 있지 않다. 사람에 의해서 관리가 되고 있는 실정이다. 소스 코드는 형상 관리를 하고 있지만 DB Schema는 형상 관리를 하고 있지 않기에 관련해서 정보를 찾아보았다. 데이터베이스에 대해서도 지속적인 통합이 필요하다. 본 글에서는 오픈소스 DB 형상 관리 툴인 Liquibase와 Flyway에 대해서 비교하고 bytebase에 대해서 언급하고자 한다.

Liquibase와 Flyway의 유사점

Liquibase와 Flyway는 진화되는 데이터베이스 설계를 원칙으로 하기에 유사한 기능들이 많다.

• 일부 오픈소스이며 데이터베이스 스키마 변경 사항을 관리, 추적 및 배포에 도움이 된다.
• 데이터베이스 스키마 변경에 대한 버전을 관리한다.
• Java를 기반으로 하며 Spring Boot 및 Vert.x와 같은 프레임워크에 대한 지원을 제공한다.
• Maven 및 Gradle과 같은 빌드 도구와 통합을 지원한다.
• 스크립트를 지원한다.
• 다양한 데이터베이스를 지원한다.

Liquibase와 Flyway의 차이점

변경사항 정의

Flyway는 변경 사항에 대해서 정의하기 위해 SQL을 사용한다. 반면 Liquibase는 XML, YAML, JSON과 같은 SQL을 포함한 다양한 형식으로 정의할 수 있는 유연성을 제공한다. Liquibase를 사용하면 데이터베이스에 구애받지 않는 언어로 작업할 수 있으며 스키마 변경 사항을 다양한 데이터베이스 유형에 쉽게 적용할 수 있다.

Flyway는 변경 사항에 따라 버전이 증가하는 방식으로 구동된다. 이 부분은 병렬 개발에 대해 충돌을 일으킬 수 있다. Flyway의 경우에는 스크립트 파일 이름으로 마이그레이션 유형을 정의한다. e.g. V01__Add_New_Column.sql

변경사항 저장

두 툴 모두 배포된 변경 사항을 테이블에 저장한다. Flyway의 경우 flyway_schema_history라는 테이블에 히스토리를 저장한다. Liquibase의 경우 databasechangelog라는 테이블에 히스토리를 저장한다.

변경 실행 순서

Flyway에서는 변경 순서를 관리하는 것이 어렵다. 파일 이름의 버전 번호와 마이그레이션 유형에 따라 달라지기 때문이다. Liquibase는 master_changelog라는 별도의 파일을 사용하여 변경 사항이 정의된 순서대로 배포된다.

변경 사항 롤백

잘못된 변경 상황이 발생할 경우 롤백이 필요하다. Liquibase는 모든 것을 롤백하거나 특정 마이그레이션을 실행 취소하는 방법을 제공한다. 하지만 유료 버전에서만 가능하다. Flyway도 유료 버전에서만 가능하다.

변경 사항의 선택적 배포

선택적 배포의 경우에는 Liquibase가 유리하다. Flyway도 가능하지만 각 환경 및 데이터베이스에 대해서 다른 구성 파일을 설정해야 하는 단점이 있다. Liquibase는 레이블과 컨텍스트를 추가하여 특정 위치에 배포할 수 있다.

스냅샷 및 데이터베이스 비교

Liquibase는 사용자가 데이터베이스의 현재 상태를 스냅샷을 생성 할 수 있다. 이것을 사용하여 다른 데이터베이스와 비교가 가능하다. 이는 데이터베이스 복제 및 장애 조치 시나리오에 매우 유용하다. Flyway는 스냅샷 기능을 지원하지 않는다.

조건부 배포

Liquibase는 사전 조건이라는 추가 기능을 제공한다. 사전 조건을 통해 사용자는 데이터베이스의 현재 상태를 기반으로 변경 사항을 적용할 수 있다. Flyway는 이 기능을 지원하지 않는다.

Bytebase

Bytebase는 데이터베이스 스키마 변경 및 버전 관리 도구이다. 웹 콘솔과 백엔드로 구성되어 있다.

기능

• SQL 검토
• 버전 관리 (GitOps)
• 데이터베이스 관리
• SQL 편집기
• SQL 어드바이저
• 마이그레이션 이력
• 백업 및 복원
• 아카이빙
• 이상 감지

지원 데이터베이스

Liquibase

Amazon Aurora(MySQL, PostgreSQL), Amazon RDS(MariaDB, MySQL, MSSql, Oracle, PostgreSQL), RedShift, Azure SQL(MSSql), Cassandra(Apache), Cassandra(DatastaxAstra), CockroachDB, Derby, EnterpriseDB, Firebird, Google Cloud Spanner, H2, Hibernate, Hive, HyperSQL(HSQL), DB2, Impala, Informix, MariaDB, Azure SQL, MSSql, MongoDB, MySQL, Oracle, Percona XtraDB, PostgreSQL, SAP Hana, SAP MaxDB, SkySQL, Snowflake, SQLite, Sybase Anywhere, Sybase Enterprise, Vertica, VoltDB

Flyway

Oracle, SQL Server(Amazon RDS, Azure SQL Database 포함), Azre Synapse, DB2, MySQL(Amazon RDS, Azure Database, Google Cloud SQL 포함), Aurora MySQL, MariaDB, Percona XtraDB Cluster, TestContainers, PostgreSQL(Amazon RDS, Azure Database, Google Cloud SQL, TimescaleDB, YugabyteDB), Aurora PostgreSQL, Redshift, CockroachDB, SAP HANA, Sybase ASE, Informix, H2, HSQLDB, Derby, Snowflake, SQLite, Firebird

Bytebase

MySQL, PostgreSQL, TiDB, ClickHouse, Snowflask를 지원하고 Oracle, SQL Server와 같은 상용 데이터베이스 지원 계획은 없음 (이 부분이 아쉬움)

결론

도구를 사용함에 있어서는 현재 상황에 대한 절충이 필요하다. 애플리케이션의 요구 사항에 따라 Liquibase 또는 Flyway를 선택해서 사용할지 상용툴을 이용할지 고민이다. 무엇보다 Schema를 관리하시는 분들이 선호하는 툴을 이용해야 할 것 같다.

References

• https://nubenetes.com/liquibase/#evolutionary-database-design