18장. 장고 코어 모듈을 교체할 때 주의점

18장. 장고 코어 모듈을 고체할 때 주의점

장고 코어 부분을 자신만의 것으로 교체했다고 자랑하는 경우가 있는데 굳이 "그럴 필요가 없다"

BUT 아래와 같은 경우에는 교체를 할 만한 가치가 있다.

1. 일부 또는 모든 장고 서드 파티 패키지를 포기할 수 있다면
2. 장고 어드민의 강력한 기능을 포기해도 문제가 없다면
3. 장고의 기능을 기반으로 프로젝트를 제작하기 위해 이미 부단히 노력했으나 더는 해결할 수 없는 거대한 장벽에 부딪혔을 때
4. 문제의 원인을 찾기 위해 코드 분석을 끝냈을 경우, 예를 들면 템플릿에서 쿼리를 줄이기 위한 작업을 다했을 경우
5. 캐잇과 비정규화 등 가능한 모든 옵션을 다 고려했을 경우
6. 많은 사용자가 이용하는 상용으로 서비스 중인 프로젝트인 경우, 다시 말해 성급하게 최적화하는 단계가 아닌 경우
7. SOA ( 링크 )를 고려했으나 이를 장고에서 처리하기 곤란하여 이용을 보류해야만 할 때
8. 장고를 업그레이드하는 것이 불가능하거나 가능하더라도 매우 고통스러운 절차를 수반하는 것을 감수할 경우

18.1 프랑켄장고(FrankenDjango)를 만들려는 유혹

• 유행에 치우친 나머지 해마다 특정 장고 코어 컴포넌트를 새로운 것으로 교체하자는 개발자들의 의견이 상당히 나온다.

1. 성능 문제로 장고의 데이터베이스/ORM을 NoSQL 데이터베이스와 이에 해당하는 ORM으로 변경하자
2. 데이터 프로세싱을 위해 장고의 데이터베이스/ORM을 NoSQL 데이터베이스와 이에 해당하는 ORM으로 변경하자
3. 장고의 기본 템플릿 엔진을 Jinja2나 마코(Mako)또는 다른 것으로 바꾸자

18.2 비관계형 데이터베이스 대 관계형 데이터베이스

• 데이터 저장을 위해 관계형 데이터베이스를 쓰는 장고 프로젝트라 할지라도 비관계형 데이터베이스를 필요로 하고 이를 이용하는 경우가 많다.
• 캐시를 위해 Memcached, Queue System Redis를 사용하고 있다면 이미 비관계형데이터베이스 (NoSQL)을 쓰고 있는것이다.

18.2.1 모든 비관계형 데이터베이스가 ACID를 충족하는 것은 아니다.

1. 원자성 - 모든 트랜잭션이 전부 성공하면 처리하고, 그렇지 않으면 모두 처리하지 않는 것을 의미 한다 ( ex - transaction.atomic 이지 않을까..)
2. 일관성 - 모든 데이터 트랜잭션이 데이터를 유효한 상태로 유지하는 것을 의미 한다. (문자열은 문자열로, 정수는 정수로)
3. 고립성 - 트랜잭션을 실행할 때 다른 트랜잭션이 끼어들거나 다른 트랜잭션으로 끼어들지 못하게 하는 것을 의미한다.(ex - db lock)
4. 지속성 - 한번 트랜잭션이 수행되면 데이터베이스가 정지하더라도 지속적으로 데이터가 남아 있어야 하는 것을 의미한다.

• NoSQL 엔진의 경우에 대부분 이 ACID에 해당하는 매커니즘이 매우 약하거나 거의 없기 때문에 오류를 일으키기가 매우 쉽다.

18.2.2 관계형 작업에 비관계형 데이터베이스를 이용하지 않는다.

18.2.3 유행을 너무 따르기보다는 스스로의 연구를 더 신뢰하라

• 관계형 DB보다 비 관계형 DB가 더 빠르고 스케일링하기에 더 좋다는 이야기를 종종 듣든다. 그렇다고 현혹되면 안된다.

18.2.4 장고와 비관계형 데이터베이스를 어떻게 이용하는가

• 비관계형 데이터 스토어를 써야 한다면 캐시나 큐와 같이 일시적으로 데이터를 저장하거나 비정규화된 데이터를 다룰 때로 국한한다. 시스템을 단순화하기 위해서 이용하지는 않도록 한다.

18.3 장고 템플릿 언어를 바꾸는 것에 대해

18.4 요약

• 항상 용도에 맞는 도구가 있다는 것을 잊지 말아야 한다.