Postgres 9.1 vs Mysql 5.6 InnoDB?

Postgres 9.1 vs Mysql 5.6 InnoDB?

---

간단한 질문-2012 년에 ACID와의 호환성을 요구하는 중대형 데이터베이스의 경우 무엇이 더 좋을까요?

나는 mySQL과 pgSQL에 대한 모든 것을 (대부분) 읽었지만 대부분의 게시물은 각각 버전 4,5.1 및 7,8과 관련이 있으며 상당히 오래되었습니다 (2008,2009). 이제 거의 2012 년이 되었기 때문에이 문제를 새롭게 살펴볼 수있을 것 같습니다.

기본적으로 PostgreSQL에 MySQL의 사용 용이성, 가용성 및 더 큰 개발자 / 지식 기반을 능가하는 것이 있는지 알고 싶습니다.

MySQL의 쿼리 최적화 프로그램은 여전히 ​​어리 석습니까? 매우 복잡한 쿼리에서 여전히 매우 느린가요?

나를 때리는! :)

추신. 저를 고글이나 위키로 보내지 마세요. 나는 개요가 아닌 몇 가지 특정 포인트를 찾고 있습니다 + 나는 그의 빛을 비추는 '똑똑한 사람'이있는 임의의 페이지보다 StackOverflow를 더 신뢰합니다.

추가

프로젝트 규모 : 계정 당 하루 약 10 ~ 100 개의 주문, 2 천 개의 계정이있는 주문 시스템을 가정하면 결국 각각 수백에서 수천 명의 사용자를 가질 수 있습니다.

더 나은 점 : 증가하고 변화하는 요구 사항에 대해 미래를 보장하고 유연하게합니다. 하드웨어 부서의 비용을 낮게 유지하려면 성능도 중요합니다. 숙련 된 인력의 가용성도 요인이 될 것입니다.

OLTP 또는 OLAP : OLTP

---

MySQL의 쿼리 최적화 프로그램은 여전히 ​​어리 석습니까? 매우 복잡한 쿼리에서 여전히 매우 느린가요?

모든 쿼리 최적화 프로그램은 때때로 어리 석습니다. PostgreSQL은 대부분의 경우 덜 어리 석습니다. PostgreSQL의 최신 SQL 기능 (윈도우 기능, 재귀 적 WITH 쿼리 등) 중 일부는 매우 강력하지만 멍청한 ORM이 있으면 사용하지 못할 수 있습니다.

프로젝트 규모 : 계정 당 하루 약 10 ~ 100 개의 주문, 2 천 개의 계정이있는 주문 시스템을 가정하면 결국 각각 수백에서 수천 명의 사용자가있을 수 있습니다.

그렇게 크게 들리지 않습니다-큰 상자에 닿을 수 있습니다.

더 나은 점 : 증가하고 변화하는 요구 사항에 대해 미래를 대비하고 유연하게.

PostgreSQL에는 광범위한 기여자 커뮤니티가있는 강력한 개발자 팀이 있습니다. 릴리스 정책 은 엄격하며 포인트 릴리스에서만 버그 수정이 있습니다. 항상 최신 9.1.x 릴리스에서 버그 수정을 추적하십시오.

MySQL은 과거에 버전 번호에 대해 다소 편안한 태도를 보였습니다. 이는 오라클이 담당하는 상황에서 바뀔 수 있습니다. 나는 다양한 포크의 정책에 익숙하지 않습니다.

하드웨어 부서의 비용을 낮게 유지하려면 성능도 중요합니다.

하드웨어가이 규모의 프로젝트에서 주요 구성 요소로 판명되면 놀랄 것입니다.

숙련 된 인력의 가용성도 요인이 될 것입니다.

그것이 당신의 핵심 결정자입니다. 경험 많은 Perl + PostgreSQL 해커 팀이 유휴 상태로 앉아 있다면 그것을 사용하십시오. 사람들이 Lisp와 MySQL을 알고 있다면 그것을 사용하십시오.

OLTP 또는 OLAP : OLTP

PostgreSQL은 항상 OLTP에 강했습니다.

제 개인적인 관점은 PostgreSQL 메일 링리스트가 예의 바르고 도움이되고 지식이 풍부한 사람들로 가득 차 있다는 것입니다. 코드의 주요 부분을 구축 한 Terabyte 데이터베이스 및 해커가있는 사용자와 직접 접촉합니다. 지원의 품질은 정말 우수합니다.

---

PostgreSQL은 SQL 기능과 관련하여 훨씬 더 발전했습니다.

MySQL에는 아직없는 것 (그리고 PostgreSQL에는있는 것) :

• 지연 가능한 제약
• 확인 제약 (MySQL은 8.0. (16) 를 추가, MariaDB 10.2을 가지고)

• 완전 외부 조인
  MySQL은 일부 구문 변형이있는 내부 조인을 자동으로 사용합니다.
  https://rextester.com/ADME43793
  

• 측면 결합

• 정규식 이 UTF-8에서 작동하지 않음 ( MySQL 8.0으로 수정 됨 )
• 정규식은 대체 또는 하위 문자열을 지원하지 않습니다 ( MySQL 8.0에서 도입 됨 ).
• 테이블 함수 ( select * from my_function())
• 공통 테이블 표현식 ( MySQL 8.0에 도입 됨 )
• 재귀 쿼리 ( MySQL 8.0에 도입 됨 )
• 쓰기 가능한 CTE
• 창 함수 ( MySQL 8.0에 도입 됨 )
• 기능 기반 색인
• 부분 색인
• 다중 열 통계
• 트랜잭션 테이블에 대한 전체 텍스트 검색 (MySQL 5.6이이를 지원함)
• 트랜잭션 테이블의 GIS 기능
• EXCEPT 또는 INTERSECT 연산자
• 동일한 select 문에서 임시 테이블을 두 번 사용할 수 없습니다.
• 하위 선택에서 변경중인 테이블 (업데이트 / 삭제 / 삽입)을 사용할 수 없습니다.

• 파생 테이블을 사용하는 뷰를 생성 할 수 없습니다 (MySQL 8.0부터 가능).

   create view x as select * from (select * from y);
  

• 문 수준 읽기 일관성. 예 :
  update foo set x = y, y = x또는
  update foo set a = b, a = a + 100
• 트랜잭션 DDL
• DDL 트리거
• 제외 제약
• 키 / 값 저장소
• 완전한 JSON 문서 인덱싱
• 범위 유형
• 도메인
• 배열 (배열의 인덱스 포함)
• 사용자 권한을 관리 할 수있는 역할 (그룹) (MariaDB는 그들을 가지고 , MySQL은 8.0 도입 )
• 병렬 쿼리 (Postgres 9.6 이후 )
• 병렬 인덱스 생성 (Postgres 11 이후)
• 사용자 정의 데이터 유형 (검사 제약 포함)
• 구체화 된 뷰
• 사용자 지정 집계
• custom window functions
• proper boolean data type
  _{(treating any expression that can be converted to a non-zero number as "true" is not a proper boolean type)}

When it comes to Spatial/GIS features Postgres with PostGIS is also much more capable. Here is a nice comparison.

Not sure what you call "ease of use" but there are several modern SQL features that I would not want to miss (CTEs, windowing functions) that would define "ease of use" for me.

Now, PostgreSQL is not perfect and probably the most obnoxious thing can be, to tune the dreaded VACUUM process for a heavy write database.

---

As an addition to @a_horse_with_no_name answer, I want to name some features which I like so much in PostgreSQL:

• arrays data type;
• hstore extension - very useful for storing key->value data, possible to create index on columns of that type;
• various language extensions - I find Python very useful when it comes to unstructured data handling;
• distinct on syntax - I think this one should be ANSI SQL feature, it looks very natural to me (as opposed to MySQL group by syntax);
• composite types;
• record types;
• inheritance;
• Version 9.3 features:
  • lateral joins - one thing I miss from SQL Server (where it called outer/cross apply);
  • native JSON support;
  • DDL triggers;
  • recursive, materialized, updatable views;

---

PostgreSQL is a more mature database, it has a longer history, it is more ANSI SQL compliant, its query optimizer is significantly better. MySQL has different storage engines like MyISAM, InnoDB, in-memory, all of them are incompatible in a sense that an SQL query which runs on one engine may produce a syntax error when executed on another engine. Stored procedures are better in PostgreSQL.

참고URL : https://stackoverflow.com/questions/8181604/postgres-9-1-vs-mysql-5-6-innodb