[PROJECT] MySQL, PostgreSQL

PostgreSQL과 MySQL의 유사점

PostgreSQL과 MySQL은 모두 관계형 데이터베이스 관리 시스템이다. 공통 열 값을 통해 서로 관련된 테이블에 데이터를 저장할 수 있다. 또한 SQL를 인터페이스로 사용하여 데이터를 읽고 편집 가능하다. 그리고 오픈 소스이며 강력한 개발자 커뮤니티 지원 제공하고, 두 제품 모두 데이터 백업, 복제 및 액세스 제어 기능이 내장되어 있다.

차이점

ACID 규정 준수

원자성, 일관성, 격리성, 지속성(ACID)은 예상치 못한 오류가 발생한 후에도 데이터베이스를 유효한 상태로 유지하는 데이터베이스 속성이다. 예를 들어, 많은 수의 행을 업데이트했는데 중간에 시스템이 실패하는 경우 행을 수정해서는 안된다.

MySQL은 InnoDB 및 NDB 클러스터 스토리지 엔진과 함께 사용하는 경우에만 ACID 규정 준수를 제공합니다. PostgreSQL은 모든 구성에서 ACID와 완벽하게 호환됩니다.

 

cf) InnoDB:

• InnoDB는 MySQL의 가장 널리 사용되는 스토리지 엔진 중 하나다.
• ACID 트랜잭션, 외래 키 제약 조건 등을 지원하여 안정성과 데이터 무결성을 보장한다.
• 행 단위의 잠금과 MVCC(Multi-Version Concurrency Control)를 통해 높은 동시성을 지원한다.
• 대규모 데이터베이스 및 고성능 애플리케이션에 적합하다.

동시성 제어

MVCC(다중 버전 동시성 제어)는 데이터베이스 관리 시스템에서 동시성을 관리하는 방식 중 하나로, 레코드의 다중 버전을 유지하여 동시 읽기와 쓰기 작업이 가능하게 한다. 이는 동시에 발생하는 여러 트랜잭션이 서로에게 방해받지 않도록 한다.

MVCC를 사용함으로써 여러 사용자가 데이터 무결성을 손상시키지 않고 동일한 데이터를 동시에 읽고 수정할 수 있다.

MySQL는 InnoDB 스토리지 엔진을 통해 MVCC를 지원하며, PostgreSQL 또한 MVCC를 지원하여 여러 트랜잭션이 동시에 데이터에 접근할 수 있게 한다.

 

PostgreSQL은 데이터 페이지 내에 변경되기 이전 Tuple과 변경된 신규 Tuple을 같은 page에 저장하고
Tuple별로 생성된 시점과 변경된 시점을 기록 및 비교하는 방식으로 MVCC를 제공한다.

(PostgreSQL에서는 record 대신 Tuple이라는 용어를 사용한다)

인덱스

데이터베이스는 인덱스를 사용하여 데이터를 더 빠르게 검색한다. 자주 액세스하는 데이터를 다른 데이터와 다르게 정렬 및 저장하도록 데이터베이스 관리 시스템을 구성하여 검색 선은을 개선한다.

MySQL은 B-트리 및 R-트리 인덱싱을 지원한다. B-트리 인덱스는 범용적으로 사용되며, R-트리 인덱스는 공간 데이터 처리에 적합하다.

PostgreSQL은 다양한 인덱스 유형을 지원한다. 이를 통해 데이터베이스 성능 요구 사항을 세밀하게 조정할 수 있다. 다양한 인덱싱 옵션은 텍스트 검색, 다차원 인덱싱 등의 복잡한 쿼리에 매우 효과적으로 대응할 수 있게 해준다.

데이터 유형

MySQL은 순수 관계형 데이터베이스 시스템이며, 전통적인 관계형 데이터 모델을 따른다.

반면 PostgreSQL은 객체 관계형 데이터베이스로, 객체 지향 프로그래밍의 개념을 데이터베이스에 통합한다. 이를 통해 복잡한 자료구조를 표현하고 상속 및 다형성과 같은 기능을 지원한다. 배열, JSON, XML 등 다양한 데이터 유형을 지원한다.

저장 프로시저

저장 프로시저는 미리 작성하고 저장할 수 있는 구조화된 쿼리 언어(SQL) 쿼리 또는 코드 명령문이다. 동일한 코드를 반복해서 재사용할 수 있으므로 데이터베이스 관리 작업이 더 효율적이다.

MySQL과 PostgreSQL 모두 저장 프로시저를 지원한다.

PostgreSQL은 SQL 이외의 프로그래밍 언어(예: PL/pgSQL, Python)로 작성된 저장 프로시저를 지원하는 반면, MySQL은 주로 SQL 기반의 저장 프로시저를 사용한다.

선택 기준

애플리케이션 범위 및 데이터 베이스 개발 경험

PostgreSQL은 엔터프라이즈급 애플리케이션, 복잡한 쿼리 및 빈번한 쓰기 작업에 적합하다. PostgreSQL은 고급 기능과 높은 유연성을 제공하지만, 설정과 관리가 더 복잡할 수 있다.

MySQL은 프로토타입 개발, 읽기 위주의 애플리케이션에 적합하다. MySQL은 초보자에게 친숙하고 학습하기 쉬우며, 설정과 관리가 상대적으로 간단하다.

성능 요구 사항

애플리케이션에 잦은 데이터 업데이트가 필요한 경우 PostgreSQL이 더 나은 선택이다. 그러나 데이터를 자주 읽어야 하는 경우에는 MySQL을 사용하는 것이 좋다.

WRITE 성능

PostgreSQL은 MVCC를 사용하여 여러 쓰기 작업을 효율적으로 관리한다. 이를 통해 높은 동시성을 제공하며, 쓰기 작업이 빈번하고 동시에 수행되는 경우 효과적이다.

MySQL의 InnoDB 엔진도 MVCC를 지원하여, 쓰기 작업에 있어 PostgreSQL과 유사한 수준의 동시성을 제공한다.

READ 성능

MySQL은 READ COMMITTED보다는 동시 처리 성능은 뛰어난 REPEATABLE READ를 사용한다.

postgresql의 디폴트 격리수준은 Read Committed이다. 따라서 mysql이 좀 더 높은 고립수준을 가져 일관성 있는 데이터를 가져올 확률이 높다고 판단했다.

https://mangkyu.tistory.com/299

[MySQL] 트랜잭션의 격리 수준(Isolation Level)에 대해 쉽고 완벽하게 이해하기

 

UPDATE 성능

MVCC 구현을 위해 PostgreSQL의 update 동작은 아래와 같이 동작하게 된다.

 

1. FSM(FreeSpaceMap, 사용 가능한 공간을 표시한 지도 같은 역할)에 사용 가능한 공간이 있는지 확인, 없으면 FSM을 추가 확보

2. FSM의 사용 가능한 공간에 update된 데이터를 기록함.

3. update된 데이터의 저장이 완료되면 update 이전의 원본 Tuple을 가리키던 포인터를 새로 update된 Tuple을 가리키도록 변경함

 

위 과정에서 update가 완료되면 기존 원본 데이터를 저장한 Tuple은 어디에도 참조되지 않는 Tuple이 되는데
이를 쓸모없는, 죽은 데이터라는 의미로 Dead Tuple이라고 한다.

 

문제는 이 Dead Tuple이 자동으로 정리되거나 FSM으로 반환되지 않기 때문에 쓸데없이 공간만 차지할 뿐만 아니라,
쓸데없이 공간만 차지하는 Dead Tuple 때문에 DB는 더 많은 page를 읽게 되고 이는 쿼리 성능에도 악영향을 끼치게 된다.

 

이 과정은 테이블의크기를 증가시키고, 주기적인 VACUUM 작업을 필요로 하게 한다.

DB 결정 - MySQL

MySQL은 초기 학습 곡선이 낮고 관리가 쉬운 데이터베이스로, 읽기 위주의 작업이 많고 상대적으로 데이터 모델이 간단한 경우 적합하다.

 PostgreSQL은 여러 강력한 개발 편의성을 제공하는 기능을 갖고 있으나 Vacuum과 같은 개념은  Oracle이나 MySQL 같은 다른 RDBMS에는 없는 생소한 개념이다.

단순한 예매 처리와 기본적인 사용자를 관리하는 시스템인만큼 MySQL이 적절하다고 판단된다.