호스트 취약성 데이터 세트
PostgreSQL 은 거의 모든 SQL 표준을 지원하며, 지원되는 유형도 상당히 풍부합니다. PostgreSQL 데이터베이스의 소스 코드는 MySQL 데이터베이스의 소스 코드보다 읽기가 더 쉽습니다. 팀이 강력한 C 언어 능력을 가지고 있다면 greenplum 과 같은 시스템을 구현하는 것과 같이 PostgreSQL 데이터베이스에서 개발하거나 현재의 분산 추세에 부합할 수 있습니다.
PostgreSQL 의 기능을 설명하기 위해 "Oracle 에서 MySQL 로 마이그레이션하기 전에 알아야 할 50 가지 사항" 에서 PostgreSQL 데이터베이스와 Mysql 데이터베이스를 간단히 비교해 보십시오.
50 Oracle 에서 Mysql 로의 마이그레이션의 어려움, 1, 하위 쿼리 성능 저하. (PostgreSQL 은 해결할 수 있음)
복잡한 쿼리는 처리 능력이 약합니다. (PostgreSQL 은 해결할 수 있음)
쿼리 최적화 프로그램은 아직 성숙하지 않습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 SQL-92 표준 및 SQL 을 완벽하게 지원하며 복잡한 SQL 조회를 지원합니다.
성능 최적화 도구 및 측정 정보가 부족합니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 실행 계획과 자세한 오버헤드 값을 제공하여 SQL 의 실행 효율성을 쉽게 확인할 수 있습니다.
감사 기능이 상대적으로 약합니다.
6. 보안 기능이 미성숙하고, 사용자 그룹 및 역할의 개념이 없으며, 권한을 회수하는 기능이 없습니다 (권한만 부여할 수 있음). 한 사용자가 다른 호스트/네트워크에서 동일한 사용자 이름/비밀번호를 사용하여 로그인할 경우 Oracle 과 유사한 내장 암호화 기능이 없는 완전히 다른 사용자로 간주될 수 있습니다.
7. 인증 기능은 완전히 내장되어 있으며 LDAP, ActiveDirectory 또는 기타 유사한 외부 인증 기능을 지원하지 않습니다.
8. MySQL 클러스터는 당신이 생각하는 것과 크게 다를 수 있습니다.
9. 저장된 프로시저와 트리거의 기능은 제한적입니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 저장된 프로시저와 트리거에 대한 완벽한 지원을 제공합니다.
10, 수직 확장성이 약합니다.
1 1, MPP (대규모 병렬 처리) 를 지원하지 않습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 Oracle 데이터베이스와 유사한 다중 프로세스 스키마로 MySQL 과는 달리 멀티 스레드 스키마이므로 MPP 를 지원할 수 있습니다.
/kloc-SMP (symmetric multi-processors) 를 지원하는 0/2, 각 프로세서가 4 코어 이상인 경우 Mysql 의 확장성이 떨어집니다.
13. 시간, 날짜 및 간격과 같은 시간 유형의 경우 초 아래에 저장 유형이 없습니다.
14, 저장된 프로시저, 트리거, 예정된 이벤트, 저장된 함수를 작성하는 데 사용할 수 있는 언어 함수가 약합니다.
15, 롤백 기반 복구 기능 없음, 롤 포워드 복구 기능만 제공.
16. 스냅샷 기능이 지원되지 않습니다.
17. databaselink 는 지원되지 않습니다. Federated 라는 스토리지 엔진이 있습니다. 이 엔진은 쿼리 문을 원격 서버의 테이블로 전송하는 트렁킹으로 사용할 수 있습니다. 그러나 그 기능은 거칠고 허점이 많다.
18, 데이터 무결성 검사가 매우 약해서 기본적인 무결성 제약 조건조차 구현되지 않는 경우가 많습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 전체 데이터 무결성 검사 메커니즘을 제공하며 외래 키를 지원합니다.
19. 쿼리 문의 실행 계획을 최적화하는 최적기 프롬프트는 거의 없습니다.
20. 중첩 루프, 정렬 병합 조인 및 해시 조인이 지원되지 않는 테이블 조인 유형은 하나뿐입니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 이러한 테이블 연결 유형을 지원합니다.
2 1, 대부분의 쿼리는 테이블에서 단일 인덱스만 사용할 수 있습니다. 경우에 따라 여러 인덱스를 사용하는 쿼리가 있을 수 있지만 쿼리 최적기는 일반적으로 비용을 과소평가하며 일반적으로 테이블 스캔보다 느립니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 데이터에는 이 문제가 없습니다. 테이블 t 에 있는 col 1 의 col2 에 idx_ 1 과 idx_2 라는 두 개의 색인이 있다고 가정하면 select * from where col/kloc-0 쿼리 시 PostgreSQL 데이터베이스는 이 쿼리를 select * from where col1=: ainterectselect * from where col2 =: b 로 변환할 수 있으므로 두 색인이 모두 유지됩니다
22. bitmapindex 는 지원되지 않습니다. 각 스토리지 엔진은 서로 다른 유형의 인덱스를 지원합니다. 대부분의 스토리지 엔진은 b 트리 인덱스를 지원합니다.
관리 도구가 적고 기능이 충분히 성숙하지 않습니다.
24. 성숙하고 만족스러운 IDE 도구 및 디버거가 없습니다. 텍스트 편집기에서 저장 프로시저를 작성하고 레코드를 테이블 (디버그 로그 테이블) 에 삽입하여 디버깅해야 할 수도 있습니다.
각 테이블은 다른 스토리지 엔진을 사용할 수 있습니다. (PostgreSQL 은 해결할 수 있음)
26. 각 스토리지 엔진은 동작, 특징 및 기능에 큰 차이가 있을 수 있습니다. (PostgreSQL 은 해결할 수 있음)
대부분의 스토리지 엔진은 외래 키를 지원하지 않습니다. (PostgreSQL 은 해결할 수 있음)
28. 기본 스토리지 엔진 (MyISAM) 은 트랜잭션을 지원하지 않으며 쉽게 손상될 수 있습니다. (PostgreSQL 은 해결할 수 있음)
29.InnoDB 는 Oracle 이 소유한 가장 선진적이고 인기 있는 스토리지 엔진입니다. (PostgreSQL 은 해결할 수 있음)
30. 일부 실행 계획은 특정 스토리지 엔진만 지원합니다. 한 유형의 카운트 쿼리는 이 스토리지 엔진에서 빠르지만 다른 스토리지 엔진에서는 느릴 수 있습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 에는 스토리지 엔진이 하나뿐이므로 위의 경우는 없습니다. PostgreSQL 은 완벽한 트랜잭션을 지원합니다.
3 1. 실행 계획은 전역적으로 공유되지 않고 연결 내에서만 공유됩니다.
32. 전체 텍스트 검색 기능은 제한적이며 트랜잭션되지 않은 스토리지 엔진에만 적용됩니다. GIS/ 공간 유형 및 조회에 대해 위와 같습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 데이터베이스는 전체 텍스트 검색 및 공간 유형 및 쿼리에 사용할 수 있는 b 트리, r 트리, 해시, GIST, GIN, r 트리, GiST, GIN 인덱스 등 다양한 유형의 인덱스를 지원합니다.
33. 자원 통제가 없습니다. 완전히 권한이 없는 사용자는 서버의 모든 메모리를 쉽게 다 소모하고 충돌을 일으키거나 모든 CPU 자원을 다 소모할 수 있습니다.
34, 통합 비즈니스 인텔리전스 없음), OLAP** * * 데이터 세트 및 기타 패키지.
35. 그리드 컨트롤 같은 도구는 없습니다.
36. RAC 와 같은 기능은 없습니다. 만약 당신이' Mysql 로 RAC 를 만드는 방법' 을 묻는다면, 단지 당신이 잘못된 질문을 했다고 말할 수 있을 뿐이다.
37. 사용자 정의 유형이나 도메인은 지원되지 않습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 다양한 유형과 사용자 정의 유형을 지원합니다.
38. 쿼리당 지원되는 최대 연결 수는 6 1 입니다.
39.MySQL 에서 지원하는 SQL 구문의 작은 부분 (ANSISQL 표준). 반복 질의, 일반 테이블 표현식 (Oracle with 문) 또는 창 함수 (분석 함수) 는 지원되지 않습니다. Merge 와 같은 SQL 구문 확장 또는 유사한 기능을 지원하지만 기능은 Oracle 에 비해 매우 간단합니다. (PostgreSQL 은 해결할 수 있음)
이러한 PostgreSQL 데이터베이스는 창 함수와 같은 모든 것을 지원합니다.
40. 함수 열은 지원되지 않습니다 (Oracle 1 1g 가 계산된 열을 지원하기 시작하고 이전 버전은 rownum, rowid 를 지원했습니다).
4 1. 함수 인덱스는 지원되지 않으며 특정 열을 기반으로 하는 인덱스만 만들 수 있습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 함수 인덱스를 지원합니다.
42. 구체화된 뷰는 지원되지 않습니다.
43. 스토리지 엔진마다 통계 차이가 매우 커서 모든 스토리지 엔진은 간단한 기수와 일정 범위의 레코드 (범위 내의 행) 만 지원합니다. 즉, 데이터 분포 통계는 제한적입니다. 통계를 업데이트하는 메커니즘은 많지 않다.
44. 내장 로드 밸런싱 및 장애 조치 메커니즘이 없습니다.
복제 기능은 비동기적이며 큰 제한이 있습니다. 예를 들어, 단일 스레드이기 때문에 처리 능력이 비교적 느린 호스트보다 처리 능력이 높은 슬레이브 시스템에서 더 빨리 복구하기가 어렵습니다.
클러스터는 생각만큼 완벽하지 않습니다. 어쩌면 내가 이미 이 점을 언급했을지도 모르지만, 그것은 반복할 가치가 있다.
47. 데이터 사전 (INFORMATION_SCHEMA) 의 기능은 매우 제한적이며 액세스 속도가 매우 느립니다 (사용량이 많은 시스템에서 쉽게 충돌할 수 있음).
48. 온라인 변경 테이블 작업은 지원되지 않습니다.
49. 시퀀스는 지원되지 않습니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 은 시퀀스를 지원합니다.
50. ALTERTABLE 또는 CREATETABLE 과 같은 작업은 비트랜잭션적입니다. 커밋되지 않은 트랜잭션을 커밋하며 롤백이나 재해 복구를 수행할 수 없습니다. Schame 은 사용하는 스토리지 엔진에 관계없이 파일 시스템에 저장됩니다. (PostgreSQL 은 해결할 수 있음)
PostgreSQL 에는 이 문제가 없습니다.
각 데이터베이스에는 서로 다른 응용 프로그램 장면이 있습니다. PostgreSQL 은 더 높은 신뢰성을 제공하며 MySQL 보다 데이터 일관성 및 무결성에 대한 지원이 높습니다. 따라서 PostgreSQL 은 엄격한 엔터프라이즈 어플리케이션 시나리오에 더 적합합니다. MySQL 쿼리 속도가 더 빠르고 비즈니스 논리가 비교적 간단하며 데이터 안정성 요구 사항이 높지 않은 인터넷 시나리오에 더 적합합니다. 위의 개인적인 견해는 비판과 시정을 환영한다.
내 의견에 동의하니, 다시 가는 것을 좋아하십시오. 감사합니다.
당신이 나를 좋아한다면 나를 지켜봐 주세요. 다시 한번 감사드립니다!