Django가 지원하는 DBMS
PostgreSQL
PostgreSQL is the most capable of all the databases here in terms of schema support.
공식문서에 따르면 Django에서 가장 추천하는 DB이다.
또한 다음과 같은 이유로 Django와 잘어울린다.
- Django는 PostgreSQL에서만 지원하는 데이터 타입들을 지원한다.
- Django에서는 PostgreSQL관련 여러 함수를 제공한다.
- 지리정보를 사용하기 위해 GeoDjango를 사용하게 되면 PostGIS등을 통해 PostgreSQL과 잘 어울린다.
MariaDB & MySQL
MySQL lacks support for transactions around schema alteration operations.
In addition, MySQL will fully rewrite tables for almost every schema operation and generally takes a time proportional to the number of rows in the table to add or remove columns.
Finally, MySQL has relatively small limits on name lengths for columns, tables and indexes, as well as a limit on the combined size of all columns an index covers.
Django에서는 이 둘에 대해 같은 Database Backend를 사용한다. 공식문서에서는 스키마 변경작업에 대한 지원이 부족하다 한다. 스키마 변경시 테이블을 완전히 다시 쓰게되어 성능저하가 발생하게 된다.
SQLite
SQLite has very little built-in schema alteration support. It can be slow and occasionally buggy. It is not recommended that you run and migrate SQLite in a production environment.
SQLite를 사용할 때 스키마 변경 시 Django가 다음과 같은 작업을 한다.
- Creating a new table with the new schema
- Copying the data across
- Dropping the old table
- Renaming the new table to match the original name
이 작업들은 느리며 배포 환경에서는 추천하지 않는다. 개발환경에서만 쓰도록 권장한다.
그 외 DBMS
- Oracle
- CockroachDB
- Firebird
- Google Cloud Spanner 등..
Transactional DDL
Transactional DDL?
공식문서에 DB를 비교해 놓은 부분을 보면 PostgreSQL이 가장 좋다고 하며 그 뒤로 계속 스키마 변경에 대해 얘기하고 있다. Transactional DDL은 말 그대로 스키마에 대한 작업인 DDL을 Transactional하게 처리한다는 뜻이다. 즉 DDL에 대해서도 roll back이 가능하다.
테이블에 대해서도 Atomic, Consistency, Durability를 보장하지만 성능이 저하될 수 있다.
For DDL to be transactional you need to support multiple versions concurrently. Similar to multiversion concurrency control (MVCC), readers don’t block writers and writers don’t block readers. Without MVCC it’s hard to have transactional DDL. Traditionally, databases started with a locking system instead of MVCC. That implementation wasn’t suited to transactional DDL, which is why around 2005 there was a big shift towards MVCC — to provide concurrent access to the database, and to implement transactional memory in programming languages.
이를 위해서는 DDL이 멀티비저닝을 지원해야 한다. 따라서 모든 DBMS가 이를 지원하지는 않는다.
사용 가능한 DBMS
- PostgreSQL
- DB2
- MS SQL
Oracle Database나 MySQL, MariaDB는 지원하지 않는다.(Atomic DDL을 지원)
Atomic DDL: DDL이 실행되면 트랜잭션이 닫힌것으로 간주한다(암시적으로 커밋한다). 즉 DDL이 섞여있으면 트랜잭션을 커밋한 후 별도의 트랜잭션으로 커밋하게 된다.
사용 이유
Django에서는 DB의 변경에 대해 Migration으로 관리한다. Migrate실행 시 DDL이 발생하며 이를 적용하게 된다. Migration실행 시 ACID를 지키기 위해 Transaction DDL을 사용하게 된다.
Migration
Why Migrate?
DB는 바뀔 수 있고 바뀐다 해서 값을 잃어버리면 안된다. Migration은 DDl을 추상화함으로써 일관성을 유지함과 동시에 작업에 대해 추상화를 제공한다. 이를 통해 스키마 변경에 대해 일관성을 유지할 수 있다.
Spring Boot에서의 DB Migration
- JPA를 사용하며 Hibernate ddl-auto를 사용했었다. 이는 테이블을 drop하게 된다. update를 해도 스키마 변경에 대응할 수 없다. ⇒ Flyway와 같은 migration툴을 사용한다.
[달록의 데이터베이스 마이그레이션을 위한 Flyway 적용기](https://hudi.blog/dallog-flyway/)
실행 순서
python manage.py makemigration을 하게 되면 migration이 생성된다. 이 파이썬 코드에는 CreateModel, DeleteModel 등 스키마 변경에 대한 내용이 담겨 있다.
이후 python manage.py migrate 를 하면 RunPython클래스를 통해 migration을 시작한다. 이때 기본적으로 transactional ddl을 가정하고 실행하게 된다.
결론.
Django가 PostgreSQL의 다양한 기능을 제공하는 것은 PostgreSQL이 좋아서가 아닌 Transactional DDL을 지원하는 DBMS중 PostgreSQL이 가장 좋기 때문이다. 사용자는 Django의 MIgration덕분에 편하게 DB 스키마 변경을 진행할 수 있으며 이는 모두 Transactional DDL이 가능하기 때문이다.
참고.
Why Django is so impressive for developing with PostgreSQL and Python
Migrations | Django documentation
Why Django prefers Postgresql?
Migration Operations | Django documentation
Digging Deeper Into Django Migrations – Real Python
Django Migrations - what benefits do they bring?
Transactional DDL in PostgreSQL: A Competitive Analysis - PostgreSQL wiki
