postgresql과 mysql의 차이점은 무엇입니까

차이점: 1. PGSQL에는 CPU 코어 수에 제한이 없지만 mysql에는 제한이 있습니다. 2. PGSQL에는 총 255개의 구성 파일 매개변수가 있는 반면 MySQL에는 총 707개의 매개변수가 있습니다. 다중 필드 통계 정보. 그러나 MySQL은 그렇지 않습니다. 4. PGSQL은 실행 계획의 실시간 컴파일을 지원하지만 MySQL은 이를 지원하지 않습니다.

이 튜토리얼의 운영 환경: windows7 시스템, PostgreSQL 11&&MySQL5.7 버전, Dell G3 컴퓨터.

PostgreSQL은 매우 완벽한 기능을 갖춘 무료 소프트웨어 객체 관계형 데이터베이스 관리 시스템(ORDBMS)입니다.

PostgreSQL은 대부분의 SQL 표준을 지원하며 복잡한 쿼리, 외래 키, 트리거, 보기, 트랜잭션 무결성, 다중 버전 동시성 제어 등과 같은 기타 여러 최신 기능을 제공합니다. 마찬가지로 PostgreSQL은 새로운 데이터 유형, 함수, 연산자, 집계 함수, 인덱스 방법, 절차적 언어 등을 추가하는 등 다양한 방법으로 확장될 수 있습니다. 또한 유연한 라이선스 덕분에 누구나 PostgreSQL을 어떤 목적으로든 무료로 사용, 수정, 배포할 수 있습니다.

postgresql과 mysql의 차이점 비교

비교 버전: PostgreSQL 11 VS MySQL5.7(innodb 엔진) Oracle 공식 커뮤니티 에디션 저작권 상황: PostgreSQL 11(무료 오픈 소스), MySQL5.7 Oracle 공식 커뮤니티 에디션(무료 및 오픈 소스)

1. CPU 제한

PGSQL에는 CPU 코어 수에 제한이 없습니다.

MySQL은 128코어 CPU를 사용할 수 있습니다. 128개 이상의 코어는 사용할 수 없습니다

2. 구성 파일 매개변수

PGSQL에는 총 255개의 매개변수가 있으며, 그 중 약 80개는 비교적 안정적으로 사용됩니다.

MySQL에는 총 707개의 매개변수가 있으며 그 중 약 80개가 사용됩니다. 매개변수는 지속적으로 증가하며 작은 버전에서도 매개변수가 증가하며 일부 매개변수는 대형 버전 간에 호환되지 않습니다

3. 타사 도구 종속성

PGSQL은 타사 미들웨어에 의존하기 위해 고가용성 클러스터만 필요합니다. 예: Patroni+etcd, repmgr

MySQL의 대부분의 작업은 타사 도구(percona-toolkit)에 의존합니다. , XtraBackup) percona의 도구 명령이 너무 많고 학습 비용이 높습니다. 고가용성 클러스터에는 타사 미들웨어도 필요합니다. 고가용성 마스터의 기본 원칙은 아직 없습니다. 슬레이브 복제

PGSQL 물리적 스트림 복제는 SQL Server 미러링/AlwaysOn과 마찬가지로 물리적 복제이며 일관성이 엄격하고 불일치를 일으킬 가능성이 없습니다. 성능 및 안정성 성능 측면에서 물리적 복제가 논리적 복제보다 우수하며 쉽습니다. MySQL 마스터-슬레이브 복제는 논리적 복제에 속합니다. (sql_log_bin 및 binlog_format과 같은 잘못된 매개변수 설정은 마스터-슬레이브 불일치로 이어집니다.) 대규모 트랜잭션의 병렬 복제는 Percona에 의존해야 합니다. 툴킷의 pt-table-checksum 및 pt-table-sync 도구는 마스터-슬레이브 일관성을 정기적으로 비교하고 복구합니다. 심각한 마스터-슬레이브 복제 오류가 발생하면 MySQL의 마스터-슬레이브 논리적 복제를 다시 설정해야 하며 이를 방지하지 않습니다. 두 개의 불일치 데이터베이스가 복제 관계 설정

5. 데이터베이스의 읽기 전용 상태

PGSQL 시스템은 기본적으로 슬레이브 데이터베이스를 읽기 전용으로 자동 설정하며, 수동 개입이 필요하지 않으며 유지 관리가 간단합니다

MySQL 슬레이브 데이터베이스는 슬레이브 데이터베이스를 읽기 전용으로 설정하려면 super_read_only=on 매개변수를 수동으로 설정해야 합니다. super_read_only 매개변수에 버그가 있습니다. 링크: https://baijiahao.baidu.com/s?id=1636644783594388753&wfr= spider&for=pc

6. 버전 분기

PGSQL에는 커뮤니티 버전만 있고 다른 분기 버전은 없습니다. PGSQL은 공식적으로 통합되어 있습니다. 개발, 통합 유지 관리, 커뮤니티 버전에는 SQL Server 및 MySQL과 달리 모든 기능이 있습니다. 표준 버전, 엔터프라이즈 버전, 클래식 버전, 커뮤니티 버전, 개발 버전, 웹 버전으로 구분되며, Enterprise DB, Hangao Database 등 PGSQL을 기반으로 한 일부 데이터베이스도 있습니다. 물론 이는 2차적인 개발일 뿐이고 독립적인 브랜치로 간주되지 않습니다. 역사적 이유로 MySQL은 MariaDB 브랜치, Percona 브랜치, Oracle 공식 브랜치의 세 가지 버전으로 나누어져 있으며 지금까지 브랜치는 기본적으로 오라클의 공식 브랜치도 버전이 나누어져 있는데, 스탠다드 버전, 엔터프라이즈 버전, 클래식 버전, 커뮤니티 버전이 있습니다.

7. SQL 기능 지원

PGSQL SQL 기능 지원은 94가지를 지원합니다. SQL 가장 완벽한 구문 지원 예: 공통 테이블 표현식(WITH 쿼리) 지원

MySQL SQL 기능 지원은 36가지 유형을 지원하지만 SQL 구문 지원은 상대적으로 약합니다. 예: 공통 테이블 표현식(WITH 쿼리)은 지원되지 않습니다. SQL 정보 기능 지원 비교는 http://www.sql-workbench.net/dbms_comparison.html

8을 참조하세요. 마스터-슬레이브 복제 보안

PGSQL 동기 스트리밍 복제, 강력한 동기화(원격 적용), 높은 보안, 데이터 손실 없음 PGSQL 동기 스트림 복제: 모든 슬레이브 데이터베이스가 다운되고 마스터 데이터베이스가 작동하며 마스터 데이터베이스는 자동으로 비동기 스트림 복제(비동기 모드)로 전환할 수 없습니다. 이 문제는 숫자를 늘려 해결해야 합니다. 슬레이브 데이터베이스.

일반적으로 프로덕션 환경에는 두 개 이상의 슬레이브 라이브러리가 있습니다. 수동 솔루션: PG 메인 라이브러리에서 synchronous_standby_names ='' 매개변수를 수정하고 pgctl reload 명령을 실행합니다. 마스터-슬레이브. 데이터는 완전히 일관성이 있습니다. 이것이 고가용성 전환의 첫 번째 단계입니다.

그러므로 PGSQL이 공격할 마스터 데이터베이스를 선택하는 것은 이해할 수 있습니다. MySQL은 반동기 복제를 강화합니다.

mysql5.7 버전의 향상된 반동기화는 마스터-슬레이브 복제 중에 데이터가 손실되지 않도록 보장할 수 있습니다. 동기 복제 관련 매개변수: rpl_semi_sync_master_wait_for_slave_count 매개변수는 대기할 슬레이브 데이터베이스 수 이상 binlog를 수신한 후 기본 라이브러리가 트랜잭션을 제출합니다. 일반적으로 1로 설정됩니다. 가장 높은 성능 매개변수인 rpl_semi_sync_master_timeout은 슬레이브 라이브러리가 기다려야 하는 시간입니다. 응답이 없으면 자동으로 비동기 모드로 전환됩니다. 일반적으로 기본 라이브러리가 비동기 모드로 자동 전환되는 것을 방지하기 위해 무한으로 설정됩니다. 모든 슬레이브 데이터베이스가 다운되고 마스터 데이터베이스는 응답 패킷을 수신할 수 없으므로 파업을 시작합니다. 수동 솔루션: MySQL 마스터 데이터베이스

9에서 rpl_semi_sync_master_wait_for_slave_count=0 매개변수를 수정하세요. 다중 필드 통계 정보

PGSQL은 다중 필드를 지원합니다. 통계

MySQL은 다중 필드 통계를 지원하지 않습니다

10. 인덱스 유형

PGSQL 다중 인덱스 유형(btree, hash, gin, gist, sp-gist, brin, Bloom, rum, zombodb, bitmap, 부분 인덱스, 표현식 인덱스)

MySQLbtree 인덱스, 전체 텍스트 인덱스(비효율적) , 표현식 인덱스(가상 컬럼 생성 필요), 메모리 테이블에서만 해시 인덱스

11. 물리적 테이블 연결 알고리즘

PGSQL은 중첩 루프 조인, 해시 조인, 병합 조인을 지원합니다

MySQL은 중첩 루프만 지원합니다. Join

12. 하위 쿼리 및 뷰 성능

PGSQL 하위 쿼리, 뷰 최적화, 상대적으로 높은 성능

MySQL 뷰 조건자 푸시다운에는 많은 제한 사항이 있으며, 하위 쿼리 풀업 제한 사항도 많습니다

13. 실행 계획의 시간 컴파일

PGSQL은 LLVM 컴파일러를 사용하여 JIT 실행 계획 적시 컴파일을 지원합니다

MySQL은 실행 계획의 적시 컴파일을 지원하지 않습니다

14 PGSQL. 병렬 쿼리(다양한 병렬 쿼리 최적화 방법), 병렬 쿼리는 일반적으로 상용 데이터베이스에서 볼 수 있는 무거운 기능입니다

MySQL은 제한되어 있으며 기본 키 병렬 쿼리만 지원합니다

15 ​​구체화된 뷰

PGSQL은 지원합니다. 구체화된 보기

MySQL은 구체화된 보기를 지원하지 않습니다

16. 플러그인 기능

PGSQL은 PGSQL, GIS 지리 플러그인, 시계열 데이터베이스 플러그인의 기능을 풍부하게 할 수 있는 플러그인 기능을 지원합니다. 벡터화된 실행 플러그인 등

MySQL은 플러그인 기능을 지원하지 않습니다

17. 검사 제약 조건

PGSQL은 검사 제약 조건을 지원합니다

MySQL은 검사 제약 조건을 작성할 수 있지만 저장소는 지원하지 않습니다. 엔진은 그 효과를 무시하므로 검사 제약 조건이 작동하지 않습니다(mariadb 지원)

18. gpu SQL 가속화

PGSQL은 GPU를 사용하여 SQL 실행 속도를 가속화할 수 있습니다

MySQL은 실행 가속화를 위해 GPU를 지원하지 않습니다. SQL의 속도

19. 데이터 유형

PGSQL에는 ltree, hstore, 배열 유형, ip 유형, 텍스트 유형과 같은 풍부한 데이터 유형이 있으므로 텍스트 유형의 최대 저장 공간이 더 이상 필요하지 않습니다. 필드는 1GB입니다.

MySQL 데이터 유형은 충분하지 않습니다

20. 데이터베이스 간 쿼리

PGSQL은 데이터베이스 간 쿼리를 지원하지 않습니다. 이는 Oracle 12C

MySQL에서 데이터베이스 전체를 쿼리할 수 있는 것과 동일합니다.

21. 백업 및 복원

PGSQL 백업 및 복원은 SQL Server 전체 백업 + 월 아카이브 백업(증분)보다 훨씬 간단합니다. 마스터-슬레이브 클러스터, 모든 노드에서 전체 백업 및 월 아카이브 백업을 수행할 수 있습니다

MySQL 백업 및 복원은 상대적으로 간단하지 않으며, 전체 백업 + binlog 백업(증분) 전체 백업에는 물리적 백업을 위한 Percona의 XtraBackup 도구, MySQL 자체 물리적 백업이 필요합니다. 특정 시점 복원 작업은 지원되지 않습니다. 단계는 번거롭고 복잡합니다

22. 성능 보기

PGSQL은 pg_stat_statements 플러그인을 설치해야 합니다. pg_stat_statements 플러그인은 다음과 같은 풍부한 성능 보기를 제공합니다. : 대기 이벤트, 시스템 통계 등 단점은 플러그인을 설치하려면 데이터베이스를 다시 시작해야 하며 성능 정보를 수집해야 하는 데이터베이스는 다음 명령을 실행해야 한다는 것입니다: create Extension pg_stat_statements 명령. 그렇지 않으면 성능 정보가 없습니다. 꽤 귀찮네요

MySQL에는 PS 라이브러리가 기본으로 포함되어 있는데 기본적으로 많은 기능이 켜지지 않고 PS가 켜져 있습니다. 라이브러리의 성능 보기 기능이 성능에 영향을 줍니다(예: 메모리 사용으로 인해 OOM이 발생함) 버그)

23. 설치 방법

PGSQL에는 다양한 플랫폼에 대한 rpm 패키지, deb 패키지 등이 있습니다. MySQL에 비해 일반적으로 소스 코드를 사용하여 설치합니다.

MySQL에는 다양한 플랫폼에 대한 rpm 패키지, deb 패키지 등이 있습니다. 소스 코드 컴파일 및 설치, 바이너리 패키지 설치는 일반적으로 바이너리 패키지를 사용하여 설치하는 것이 편리하고 빠릅니다.

24. DDL 작업

PGSQL은 테이블을 잠그지 않고 필드를 추가하고 가변 길이 필드 유형의 길이를 변경합니다. 모든 DDL 작업에는 타사 도구를 사용할 필요가 없으며 상용 데이터베이스와 마찬가지로 DDL 작업도 가능합니다. 롤백되어 트랜잭션 일관성 보장MySQL 대부분의 DDL 작업은 필드 추가 및 가변 길이 필드 유형의 길이 변경과 같은 테이블을 잠그기 때문에 percona-toolkit의 pt-online-schema-change 도구를 사용해야 합니다. 작업을 완료하고 영향을 최소화하기 위해 특히 대형 테이블의 DDL 작업의 경우 DDL 작업을 롤백할 수 없습니다

25. 대형 버전 출시 속도

PGSQLPGSQL은 매년 메이저 버전을 출시하며, 버전 반복 속도가 매우 빠릅니다. 공식 버전은 2016년에 출시되었습니다. PGSQL 10은 2017년에 출시되었습니다. PGSQL 11의 공식 버전은 2017년에 출시되었습니다. : PGSQL 12 공식 버전 출시 시기 2018년: 2019

MySQL MySQL의 주요 버전이 출시되기까지는 보통 2~3년이 걸립니다. 일반적으로 메이저 버전은 함정을 피하기 위해 출시된 지 2년 후에만 프로덕션 환경에 넣을 수 있습니다. 버전 출시 속도 비교 느린 MySQL 5.5 공식 버전 출시: 2010 MySQL 5.6 공식 버전 출시: 2013 MySQL 5.7 공식 버전 출시: 2015 MySQL 8.0 공식 버전 출시: 2018

26. 반환 구문

PGSQL은 반환 구문을 지원하고 반환 절은 DML 반환 결과 집합을 지원하여 클라이언트 <-> 반환 구문

27. 내부 아키텍처

PGSQL 다중 프로세스 아키텍처는 Oracle과 마찬가지로 동시 연결 수가 너무 많을 수 없으므로 많은 최적화 방법도 동일합니다. 예: 대용량 페이지 메모리 켜기

MySQL 멀티 스레드 아키텍처이지만 시스템의 동시성으로 인해 연결 수가 너무 많으면 공식적인 제한이 있습니다. 스레드 수가 늘어나면 시스템 처리 능력이 저하됩니다. 일반적으로 동시에 200~300개의 데이터베이스 연결만 처리할 수 있습니다.

28PGSQL은 지원하지 않습니다. PGSQL 자체의 MVCC 구현 메커니즘으로 인해 발생하는 클러스터형 인덱스

MySQL은 클러스터형 인덱스를 지원합니다

29. 유휴 트랜잭션 종료 기능

PGSQL은 유휴 트랜잭션을 종료합니다. 예를 들어 애플리케이션 코드가 열린 트랜잭션 트랜잭션을 닫습니다. PGSQL은 이러한 유형의 세션 트랜잭션을 자동으로 확인하고 종료합니다.

MySQL은 유휴 트랜잭션 종료 기능을 지원하지 않습니다

30 매우 큰 데이터 볼륨에 대처하기

PGSQL은 매우 큰 데이터에 대처할 수 없습니다. PGSQL 자체의 MVCC 설계 문제로 인해 가비지 수집을 위해서는 이후 주요 버전에서만 최적화를 기대할 수 있습니다

MySQL은 극도로 큰 데이터 볼륨과 MySQL 자체 아키텍처의 문제를 처리할 수 없습니다

31 . 분산 진화

PGSQLHTAP 데이터베이스: CockroachDB, Tencent Tbase 샤딩 클러스터: Postgres- XC, Postgres - 운영 체제 수준(데이터베이스 중지 시)에서 데이터베이스의 파일 이름 및 명명 규칙, 개수를 명확하게 이해합니다. 파일 및 파일 크기. 운영 체제가 파일 손실 또는 하드 디스크 손상을 겪으면 PGSQL 테이블 데이터에 이름이 없기 때문에 복구가 매우 어렵습니다. 테이블스페이스가 생성되지 않은 경우 기본값은 기본 폴더인 기본 테이블스페이스입니다. 예: /data/base/16454/3599base: 기본 테이블스페이스 pg_default가 있는 물리적 위치입니다. 16454: 테이블이 위치한 데이터베이스의 oid3599: 테이블 객체의 oid입니다. 물론 테이블의 크기가 1GB를 초과하면 여러 개의 물리적 파일이 생성될 뿐만 아니라 해당 테이블의 fsm 파일과 vm 파일도 생성됩니다. 따라서 큰 테이블에는 실제로 여러 개의 물리적 파일이 있습니다. PGSQL에는 데이터 파일 레이아웃 내용이 너무 많기 때문에 관련 정보를 확인할 수 있습니다. 물론 이것이 전적으로 PGSQL의 탓일 수는 없습니다. 데이터베이스 백업 및 재해 복구를 수행합니다. 미디어 복구는 일반적으로 특정 상황에서만 수행됩니다.

MySQL 데이터베이스 이름은 폴더 이름이며, 데이터베이스 폴더 아래에는 각 테이블에 해당하는 데이터 파일이 있습니다. 메타데이터 및 테이블/인덱스 데이터를 저장하는 frm 파일 및 ibd 파일이 명확하고 간단합니다. 미디어 복구 또는 테이블 공간 전송이 매우 편리합니다

33.

PGSQLPGSQL은 권한 설계 측면에서 상당히 까다롭습니다. PGSQL의 권한 수준은 SQL Server와 약간 비슷합니다. 여기서는 Oracle을 비유로 사용합니다. ORACLE 12C 이전에는 인스턴스와 데이터베이스가 일대일이었습니다. 즉, 인스턴스는 하나의 데이터베이스만 가질 수 있으며, 인스턴스는 여러 데이터베이스를 가질 수 있습니다. PGSQL은 데이터베이스 간 쿼리를 수행할 수 없습니다. PGSQL에서는 ORACLE과 유사하게 여러 개의 데이터베이스를 구축할 수 있습니다(앞서 언급한 인스턴스와 데이터베이스는 일대일입니다). -one) 하나의 데이터베이스는 하나의 인스턴스와 동일합니다. PGSQL만으로는 인스턴스를 호출하지 않으며 클러스터 개념은 PGSQL의 관련 정보를 참조할 수 있습니다. PGSQL의 인스턴스/데이터베이스 아래 스키마는 데이터베이스와 동일하므로 이 스키마의 개념은 MySQL의 데이터베이스에 해당합니다. 참고: 데이터베이스는 인스턴스와 동일하므로 데이터베이스는 논리적입니다. 문제는 PGSQL 클러스터에 속한 모든 데이터베이스에 대해 작업을 동시에 수행할 수 없으며 하나씩 수행해야 한다는 것입니다. 예를 들어, 위에서 언급한 pg_stat_statements 플러그인을 설치해야 합니다. PGSQL 클러스터의 모든 데이터베이스에 대해 성능 수집을 수행하려면 로드 명령을 하나씩 실행해야 합니다. 예를 들어, 데이터베이스 간 쿼리에는 dblink 플러그인 또는 fdw 플러그인이 필요합니다. 두 데이터베이스 간 쿼리는 데이터베이스 간 쿼리와 동일합니다. 두 개의 인스턴스가 확장되어 있으므로 dblink 플러그인 또는 fdw 플러그인이 필요하므로 권한 작업도 데이터베이스별로 수행된다는 점은 PGSQL이 SQL과 같다는 것입니다. Server의 권한 계층은 db=》schema=》object이지만 실제로는 SQL Server보다 더 복잡합니다. 또한 새로 생성된 테이블은 PGSQL에서 별도로 권한을 부여해야 하므로 유용합니다. 가끔은 차이점을 구분하지 못하고, 역할을 어떻게 사용하는지 모르기 때문에 PGSQL은 권한 설계 측면에서 정말 까다롭습니다.

MySQL은 권한 매핑을 위해 mysql 라이브러리 아래에 있는 5개의 권한 테이블을 사용합니다. , 이는 간단하고 명확합니다. 유일한 문제는 권한 역할 사용자 테이블 db 테이블 호스트 테이블 tables_priv 테이블 columns_priv 테이블

34. 개발 내역

PGSQL 1995년에 개발자 Andrew Yu와 Jolly Chen이 SQL( 구조적 쿼리 언어(Structured Query Language)를 Postgres(구조적 쿼리 언어)로 변환하는 프로그램인 이 버전은 Postgres95라고 하며 오픈 소스 커뮤니티에 출시되었습니다. 1996년에 다시 Postgres95에 큰 변화가 생겨 PostgresSQL 버전 6.0으로 명명되어 출시되었습니다. PostgresSQL이라는 이름은 1995년부터 계산하면 약 24년의 역사를 가지고 있습니다

MySQL은 1996년에 MySQL 1.0이 출시되었습니다. 이는 내부 릴리스와 동일한 소수의 사람들에게만 제공됩니다. 1996년 10월 MySQL 3.11.1이 출시되었습니다(MySQL에는 2.x 버전이 없습니다). 처음에는 Solaris 운영 체제에서 바이너리 버전만 제공했으며, 한 달 뒤인 1996년부터 Linux 버전이 등장했습니다. 약 23년의 역사를 가지고 있습니다.

【관련 추천: mysql 비디오 튜토리얼】

위 내용은 postgresql과 mysql의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!