MySQL 대 PostgreSQL?

MySQL 대 PostgreSQL? Django 프로젝트에 어떤 것을 선택해야합니까?

---

내 Django 프로젝트는 수십만 개의 항목이있는 대규모 데이터베이스에 의해 지원되며 검색을 지원해야합니다 (아마 djangosearch 또는 유사한 프로젝트를 사용하게 될 것입니다.)

내 프로젝트에 가장 적합한 데이터베이스 백엔드는 무엇이며 그 이유는 무엇입니까? 더 읽어 볼만한 좋은 자료가 있습니까?

---

최근에 MySQL에서 Postgresql로 프로젝트를 전환 한 사람으로서 저는 전환을 후회하지 않습니다.

Django의 관점에서 볼 때 가장 큰 차이점은 Postgresql에서 더 엄격한 제약 조건 검사를한다는 것입니다. 이는 좋은 일이며 수동 스키마 변경 (일명 마이그레이션)을 수행하는 것도 약간 더 지루합니다.

아마 6 개 정도의 Django 데이터베이스 마이그레이션 애플리케이션이 있으며 적어도 하나는 Postgresql을 지원하지 않습니다. 나는 당신이 다른 것 중 하나를 사용하거나 수동으로 할 수 있기 때문에 이것을 단점이라고 생각하지 않습니다 (나는 atm을 선호합니다).

MySQL에서는 전체 텍스트 검색 이 더 잘 지원 될 수 있습니다. MySQL에는 Django 내에서 지원되는 전체 텍스트 검색이 내장되어 있지만 꽤 쓸모가 없습니다 (단어 형태소 분석, 구문 검색 등 없음). 내가 사용했습니다 장고 - 스핑크스 MySQL의 전체 텍스트 검색을위한 더 나은 옵션으로.

전체 텍스트 검색은 Postgresql 8.3에 내장되어 있습니다 (이전 버전에는 TSearch 모듈이 필요함). 다음은 좋은 교육용 블로그 게시물입니다. PostgreSQL 및 tsearch2를 사용하여 Django에서 전체 텍스트 검색

---

Django의 제작자는 PostgreSQL을 권장합니다.

레거시 시스템에 묶여 있지 않고 데이터베이스 백엔드를 자유롭게 선택할 수있는 경우 비용, 기능, 속도 및 안정성 간의 균형을 잘 잡는 PostgreSQL을 권장합니다. ( Django에 대한 결정적인 가이드 , p. 15)

---

수십만 개의 항목이있는 대형 데이터베이스,

이것은 큰 데이터베이스가 아니라 매우 작은 데이터베이스입니다.

PostgreSQL은 더 많은 기능을 가지고 있기 때문에 선택합니다. 가장 중요한 것은이 경우입니다. PostgreSQL에서는 Python을 절차 언어로 사용할 수 있습니다.

---

Postgresql이 더 좋아 보이더라도 Django에서 성능 문제가 있음을 발견했습니다.

Postgresql은 "긴 연결"(연결 풀링, 지속성 연결 등)을 처리하도록 만들어졌습니다.

MySQL은 "짧은 연결"을 처리하도록 만들어졌습니다 (연결, 쿼리 수행, 연결 해제, 많은 열린 연결에 대한 성능 문제가 있음 ).

문제는 Django가 연결 풀링 또는 지속성 연결을 지원하지 않기 때문에 각 뷰 호출에서 데이터베이스에 연결 / 연결 해제해야한다는 것입니다.

Postgresql과 함께 작동하지만 Postgresql에 연결하는 데는 MySQL 데이터베이스에 연결하는 것보다 훨씬 많은 비용이 듭니다 (Postgresql에서는 각 연결에 자체 프로세스가 있으며 MySQL에서 새 스레드를 팝하는 것보다 훨씬 느립니다).

그런 다음 일부 경우에 실제로 유용 할 수있는 쿼리 캐시와 같은 일부 기능을 얻을 수 있습니다. (하지만 PostgreSQL의 뛰어난 텍스트 검색을 잃었습니다)

---

당신이 더 익숙한 것을 사용하십시오. MySQL과 PostgreSQL은 끝없는 전쟁입니다. 둘 다 훌륭한 데이터베이스 엔진이며 둘 다 주요 사이트에서 사용되고 있습니다. 실제로는 중요하지 않습니다.

---

모든 답변은 흥미로운 정보를 테이블에 가져 왔지만 일부는 약간 구식이므로 여기에 제 소금이 있습니다.

1.7부터 마이그레이션 은 이제 Django의 필수 기능입니다. 그래서 그들은 Django 개발자가 미리 알고 싶어 할 수있는 주요 차이점을 문서화했습니다.

백엔드 지원

마이그레이션은 Django와 함께 제공되는 모든 백엔드뿐만 아니라 스키마 변경 ( SchemaEditor 클래스 를 통해 수행됨 ) 을 지원하도록 프로그래밍 된 타사 백엔드에서도 지원됩니다 .

그러나 일부 데이터베이스는 스키마 마이그레이션과 관련하여 다른 데이터베이스보다 성능이 더 뛰어납니다. 몇 가지주의 사항은 아래에 설명되어 있습니다.

PostgreSQL

PostgreSQL은 스키마 지원 측면에서 여기에있는 모든 데이터베이스 중 가장 능력이 있습니다. 유일한주의 사항은 기본값이있는 열을 추가하면 크기에 비례하는 시간 동안 테이블이 완전히 다시 작성된다는 것입니다.

따라서 항상 null = True로 새 열을 만드는 것이 좋습니다. 이렇게하면 열이 즉시 추가됩니다.

MySQL

MySQL은 스키마 변경 작업에 대한 트랜잭션을 지원하지 않습니다. 즉, 마이그레이션이 적용되지 않으면 다시 시도하기 위해 수동으로 변경 사항을 선택 해제해야합니다 (이전 지점으로 롤백 할 수 없음).

또한 MySQL은 거의 모든 스키마 작업에 대해 테이블을 완전히 다시 작성하며 일반적으로 열을 추가하거나 제거하는 데 테이블의 행 수에 비례하는 시간이 걸립니다. 느린 하드웨어에서 이것은 백만 행당 1 분보다 더 나쁠 수 있습니다. 단 몇 백만 행이있는 테이블에 몇 개의 열을 추가하면 사이트가 10 분 이상 잠길 수 있습니다.

마지막으로 MySQL은 열, 테이블 및 인덱스의 이름 길이에 대해 상당히 작은 제한과 인덱스가 다루는 모든 열의 결합 크기에 대한 제한이 있습니다. 즉, 다른 백엔드에서 가능한 인덱스는 MySQL에서 생성되지 않습니다.

SQLite

SQLite는 내장 된 스키마 변경 지원이 거의 없기 때문에 Django는 다음을 통해이를 에뮬레이트하려고합니다.

• 새 스키마로 새 테이블 만들기
• 데이터 복사
• 이전 테이블 삭제
• 원래 이름과 일치하도록 새 테이블 이름 바꾸기

이 프로세스는 일반적으로 잘 작동하지만 느리고 가끔 버그가있을 수 있습니다. 위험과 한계를 잘 알고 있지 않는 한 프로덕션 환경에서 SQLite를 실행하고 마이그레이션하는 것은 권장되지 않습니다. Django가 제공하는 지원은 개발자가 로컬 컴퓨터에서 SQLite를 사용하여 전체 데이터베이스 없이도 덜 복잡한 Django 프로젝트를 개발할 수 있도록 설계되었습니다.

---

django-south에서 마이그레이션이 실패하면 개발자는 MySQL을 사용하지 않는 것이 좋습니다.

! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)

---

이전 답변에 추가하려면 :

• "MySQL에서 전체 텍스트 검색이 더 잘 지원 될 수 있습니다."

MySQL의 FULLTEXT 인덱스는 농담입니다.

• MyISAM 테이블에서만 작동하므로 ACID, 트랜잭션, 제약 조건, 관계, 내구성, 동시성 등을 잃게됩니다.
• INSERT/UPDATE/DELETE to a largish TEXT column (like a forum post) will a rebuild a large part of the index. If it does not fit in myisam_key_buffer, then large IO will occur. I've seen a single forum post insertion trigger 100MB or more of IO ... meanwhile the posts table is exclusiely locked !
• I did some benchmarking (3 years ago, may be stale...) which showed that on large datasets, basically postgres fulltext is 10-100x faster than mysql, and Xapian 10-100x faster than postgres (but not integrated).

Other reasons not mentioned are the extremely smart query optimizer, large choice of join types (merge, hash, etc), hash aggregation, gist indexes on arrays, spatial search, etc which can result in extremely fast plans on very complicated queries.

---

Will this application be hosted on your own servers or by a hosting company? Make sure that if you are using a hosting company, they support the database of choice.

---

There is a major licensing difference between the two db that will affect you if you ever intend to distribute code using the db. MySQL's client libraries are GPL and PostegreSQL's is under a BSD like license which might be easier to work with.

---

Having gone down the road of MySQL because I was familiar with it (and strugglign to find a proper installer and a quick test of the slow web "workbench" interface of postgreSQL put me off), at the end of the project, after a few months after deployment, while looking into back up options, I see you have to pay for MySQL's enterprise back features. Gotcha right at the very end.

I have had to write some ugly monster raw SQL queries in Django because no select distinct per group for retrieving the latest per group query. Also looking at postgreSQL's full-text search and wishing I had used postgresSQL.

I recommend PostgreSQL even if you are familiar with MySQL, but your mileage may vary.

참고URL : https://stackoverflow.com/questions/585549/mysql-vs-postgresql-which-should-i-choose-for-my-django-project