데이터 마이그레이션 시스템 비교 및 ​​선택

데이터 마이그레이션 시스템 비교 및 ​​선택

데이터 모델은 개발 프로세스 중에 변경되는 경향이 있으며 어느 시점에서는 더 이상 데이터베이스와 일치하지 않습니다. 물론 데이터베이스를 삭제하면 ORM이 모델과 일치하는 새 버전을 생성할 수 있지만 이 절차를 수행하면 기존 데이터가 손실됩니다. 따라서 마이그레이션 시스템의 기능은 스키마 변경으로 인해 기존 데이터 손실 없이 애플리케이션의 데이터 모델과 동기화되도록 하는 것입니다.

이 기사에서는 데이터베이스 마이그레이션을 관리하기 위한 다양한 도구를 살펴보고자 합니다. 이 리뷰가 비슷한 선택에 직면한 개발자에게 도움이 되기를 바랍니다.

태스크

우리 회사는 현재 차세대 제품인 Docs Security Suite(DSS)를 적극적으로 개발하고 있습니다. 서버 부분은 .Net Core로 작성하고, DBMS로는 Entity Framework Core를 사용합니다. 애플리케이션을 디자인할 때 우리는 Code First 접근 방식을 사용합니다.

응용 프로그램 도메인 모델은 여러 개발자가 동시에 생성합니다. 각 개발자는 시스템의 자체 논리적 부분을 담당합니다.

이전 세대의 DSS는 마이그레이션 관리 시스템으로 클래식 EF 6(Entity Framework 마이그레이션)을 사용했습니다. 그러나 이에 대한 일부 불만이 쌓였습니다. 가장 큰 이유는 EF에 버전 충돌을 해결하는 올바른 접근 방식이 부족하다는 것입니다. 이 사실은 지원의 일환으로 버그를 수정할 때 여전히 우리를 당황하게 하므로 우리는 대체 옵션을 고려하기로 결정했습니다.

논의 결과, 마이그레이션 관리 시스템에 대한 다음과 같은 요구 사항이 형성되었습니다.

1. 다양한 DBMS를 지원합니다. MS SQL Server, PostgreSQL, Oracle이 필요하지만 잠재적으로 다른 것을 사용할 수도 있습니다.
2. ORM으로 작업합니다. 처음에는 EF Core를 사용할 계획이었지만 설계 단계에서는 다른 ORM을 고려할 준비가 되었습니다.
3. 마이그레이션 자동 생성. Code First의 개발을 고려하여 마이그레이션을 "직접 작성"할 필요가 없도록 하고 싶습니다.
4. 버전 충돌. 분산 개발 환경에서는 병합 시 EF Core가 충돌할 수 있습니다. 이는 애플리케이션의 여러 부분이 서로 다른 개발자에 의해 생성되므로 각 부분에 많은 시간을 소비해야 하기 때문에 심각한 문제가 됩니다.
5. 고급 문서화 및 지원. 여기서는 설명이 필요하지 않은 것 같습니다.
6. 무료. 기준은 조건부입니다. 시스템은 그다지 비싸지도 비싸지도 않지만 편의성 측면에서 이상적이기 때문에 우리도 고려할 준비가 되어 있었습니다.

약간의 연구 결과 다음과 같은 옵션이 발견되었으며 고려해야 할 바람직한 것으로 나타났습니다.

1. EF 코어 마이그레이션
2. DBup
3. 라운드하우스E
4. ThinkingHome.Migrator
5. 유창한 마이그레이션

이제 좀 더 자세히 설명하겠습니다.

EntityFramework 코어 마이그레이션

당연히 이것이 선택할 첫 번째이자 주요 옵션이었습니다. 탬버린을 만지작거리지 않고도 즉시 사용할 수 있는 기본 악기입니다. 많은 양의 문서, 공식 여부, 단순성 등 그러나 클래식 EF에 대한 불만 사항은 EF Core에도 상당히 관련이 있습니다.

따라서 EF Core의 장점은 다음과 같습니다.

• Microsoft 지원, 문서(러시아어 포함), 대규모 커뮤니티
• CodeFirst 기반 마이그레이션 자동 생성
• EF 6과 비교하여 EF Core는 더 이상 데이터베이스의 스냅샷을 저장하지 않습니다. Code First에서 EF Core로 작업할 때 더 이상 데이터베이스를 배포할 필요가 없습니다.
• Code First에서 춤을 추고 있기 때문에 필요한 모든 데이터 액세스 공급자로 한 번의 마이그레이션을 수행하는 것이 가능합니다.
• 공급자의 경우 PostgreSQL을 지원하고 Oracle을 지원하며 MS SQL Server까지 지원합니다 

그리고 단점도 있습니다:

• 갈등 해결은 동일한 수준으로 유지되었습니다. 마이그레이션 순서를 지정하고 데이터베이스 스냅샷을 업데이트해야 합니다.
• 마이그레이션이 생성되는 모델에 대한 종속성

DbUp

dbup.github.io

DbUp은 NuGet에 의해 설치되고 변경 사항을 SQL Server에 푸시하는 데 도움이 되는 .NET 라이브러리입니다. 이미 실행된 변경 스크립트를 추적하고 데이터베이스 업데이트에 필요한 스크립트를 실행합니다. 라이브러리는 ASP.NET의 오픈 소스 블로그 엔진 프로젝트에서 성장했으며 MIT 라이선스에 따라 존재하며 코드는 GitHub에 있습니다. 마이그레이션은 T-SQL을 사용하여 설명됩니다.

장점은 무엇입니까?

• 다수의 DBMS 지원(MS SQL Server, PstgreSQL, MySQL)
• 스크립트는 T-SQL로 작성되었기 때문에 매우 단순해 보입니다.
• SQL을 사용하여 충돌도 해결됩니다.

그리고 단점:

• 지원되는 DBMS가 다양하기 때문에 Oracle은 그중 하나가 아닙니다.
• ORM과 상호 작용하지 않습니다.
• T-SQL 스크립트를 직접 작성하는 것은 우리가 목표로 했던 것이 아닙니다.
• 문서와 커뮤니티는 그저 그렇습니다. 비록 SQL 스크립트 작성 측면에서는 필요하지 않을 수도 있습니다.

라운드하우스E

github.com/chucknorris/roundhouse

이전 도구와 마찬가지로 Apache 2.0 라이선스에 따라 배포되는 이 마이그레이션 관리 도구는 T-SQL 마이그레이션 엔진에서 실행됩니다. 아무래도 개발자들은 편안한 개발 프로세스를 만들기보다는 DBMS 지원과 관련된 기술적 문제 해결을 우선시한 것 같습니다.

장점 :

• 필요한 DBMS 지원(Oracle 포함)

단점 :

• Oracle(우리와 관련 없는 Access는 물론)은 .NET Core에서 지원되지 않고 .NET Full Framework에서만 지원됩니다.
• ORM에서는 작동하지 않습니다
• 이전 도구보다 문서가 훨씬 적습니다.
• 다시 말하지만 마이그레이션은 스크립트로 작성됩니다.

ThinkingHome.Migrator

MIT 라이선스에 따라 배포되는 .NET Core 플랫폼으로 버전이 지정된 데이터베이스 스키마 마이그레이션을 위한 도구입니다. 개발자는 거의 XNUMX년 전에 최신 버전에 대해 직접 썼습니다..

장점 :

• .NET Core용으로 설계됨
• 마이그레이션의 분기 순서를 구현했습니다.
• 마이그레이션 로깅 구현

단점 :

• XNUMX년 전에 마지막으로 업데이트되었습니다. 분명히 프로젝트가 지원되지 않습니다
• Oracle에서는 지원되지 않습니다(문서에는 .NET Core에 대한 안정적인 구현이 부족하기 때문이라고 명시되어 있지만 이는 XNUMX년 전입니다).
• 마이그레이션 자동 생성 없음

전반적으로 이 프로젝트는 특히 개발의 경우 유망해 보이지만 우리는 지금 여기서 결정을 내려야 했습니다.

유창한 마이그레이션

github.com/fluentmigrator/fluentmigrator

많은 팬을 보유하고 있는 가장 인기 있는 마이그레이션 도구입니다. Apache 2.0 라이센스에 따라 배포됩니다. 설명에 명시된 대로 이는 Ruby on Rails 마이그레이션과 유사한 .NET용 마이그레이션 프레임워크입니다. 데이터베이스 스키마에 대한 변경 사항은 C# 클래스에 설명되어 있습니다.

여기에는 장점이 있습니다.

• 필수 DBMS 지원
• .NET 코어 지원
• 대규모 개발 커뮤니티
• 마이그레이션 간의 충돌은 순차적으로 해결됩니다. 즉, 마이그레이션 실행 순서가 지정됩니다. 또한, 하나의 엔터티 주위에 충돌이 발생하면 코드를 병합할 때 나머지 코드와 동일한 방식으로 해결됩니다.
• 마이그레이션이 성공한 후에 실행되는 프로필이 있습니다. 그리고 서비스 기능을 수행할 수 있습니다. 마지막 업데이트는 한 달 전이었습니다. 즉, 프로젝트가 살아있습니다.

단점은 다음과 같습니다.

• 마이그레이션 자동 생성 없음
• EF 모델과 연결되지 않음
• 데이터베이스 스냅샷 없음

우리의 선택은 무엇이었나요?

열띤 논쟁은 마이그레이션 자동 생성과 건전한 갈등 해결이라는 두 가지 매개변수를 중심으로 진행되었습니다. 다른 요인들은 훨씬 덜 무서웠습니다. 그 결과, 논의 결과를 토대로 팀에서는 새 프로젝트에 Fluent Migrator를 사용하기로 결정했습니다. 앞으로 갈등을 해결하면 훨씬 더 많은 이점을 얻을 수 있기 때문입니다.

조사 결과

물론 완벽한 도구는 없습니다. 그래서 우리는 선택을 하기 위해 '원하는 것'의 우선순위를 정해야 했습니다. 그러나 다른 팀 및 기타 작업의 경우 다른 요소가 결정적일 수 있습니다. 이 기사가 귀하의 선택에 도움이 되기를 바랍니다.

출처 : habr.com