PostgreSQL과 MariaDB의 사이에서의 선택
PostgreSQL과 MariaDB의 사이에서의 선택
클라우드가 대세가 되고, 오픈소스가 많은 영역에서 중요한 자리를 차지하게 됨에 따라서, 데이터베이스 영역 역시 오픈소스 DB가 많은 시장 점유율을 차지하고 있습니다. 여전히 성능과 안정성, 모든 부분에서 상용인 오라클이 가장 뛰어나다는 것은 부정할 수 없지만, 비싼 라이선스 정책으로 인해 많은 사용자가 오픈소스로 눈을 돌리는 것도 사실입니다.
OLTP와 OLAP, 그리고 DW
OLTP (OnLine Transaction Processing) – 실시간 업무처리에 최적화된 프로세스를 말합니다. 가장 우선시 하는것은 업무의 효율적인 처리입니다.
OLAP (OnLine Analytical Processing) – 다차원으로 이루어진 데이터로 부터 통계적인 요약정보를 제공하고, 의사 결정에 도움이 되는 데이터 분석 업무에 최적화된 것을 일컫습니다.
DW (Data Warehouse) – 오랜기간을 통해 축척된 데이터를 하나의 통합 데이터베이스로 구축해 놓은 것을 의미합니다.
PostgreSQL & MariaDB
데이터베이스를 선택하는데 있어서 가장 중요한 것은 역시 성능입니다. 최적의 성능을 서비스에 적용하기 위해서는 서비스의 업무가 어떠한 용도인지, 어떻게 구성 할 것인지, 다양한 요소를 고려해야 합니다. 현재 시장에서 가장 많이 사용하는 오픈소스 DB는 첫번째가 MySQL, 그 다음이 PostgreSQL 입니다. MySQL은 오라클이 인수한 후에 엔터프라이즈 버전을 배급하고, 소스 공개를 비공개로 전환하는 등 기본적인 기능만을 갖춘 커뮤니티 버전만을 오픈소스로 제공하고 있습니다. MySQL을 오라클이 인수한 이 후 MariaDB라는 이름으로 데이터베이스를 개발하고 있습니다. MariaDB의 점유율을 아직까지는 그렇게 높지 않지만, MySQL과의 높은 호환성과 오픈소스로 누구나 무료로 사용할 수 있는 편리한 접근성으로 MySQL의 자리를 점점 차지하고 있습니다. PostgreSQL은 오랜 역사를 가지고 있고, 오픈소스가 가지는 최대의 장점인 많은 그룹에서 다양한 방향성을 가지고 지속적으로 발전하고 있습니다.
PostgreSQL vs MariaDB
두 DB의 가장 큰 차이점은 PostgreSQL은 멀티 프로세스 방식이며, MariaDB는 멀티쓰레드 방식을 사용하고 있는것 입니다. 여기서 오는 가장 큰 차이점은 CPU 멀티 코어의 사용여부인데, 멀티 프로세스를 사용하는 PostgreSQL의 경우 복잡한 쿼리나 join의 처리 방식에서 좀 더 뛰어난 성능을 보여줍니다. MariaDB의 멀티쓰레드 방식에서 Join이 중첩루프 방식으로 실행 되며 코어를 1개밖에 사용할 수 없기 때문에 복잡한 쿼리나 join 방식의 쿼리를 처리하는데 있어서 성능저하가 발생하기도 합니다.
PostgreSQL | MariaDB | |
방식 | Multi Processes | Multi Threads |
성능 | 복잡한 쿼리를 실행해야 하는 환경에서 더 뛰어나다. 하드웨어의 읽기/쓰기 속도가 받쳐줘야 하며, 광범위한 데이터 분석, DW, 데이터 분석 응용 부분에서 뛰어난 성능을 보여준다. Disk I/O가 많은 편으로 HDD 환경보다는 SSD 환경을 추천한다. |
단순한 데이터 트랜잭션에 뛰어남. OLTP/OLAP 시스템에서 읽기 속도만 필요한 경우 좋은 성능을 보여준다. InnoDB는 OLTP/OLAP 환경에서 READ/WRITE 모두 뛰어난 성능을 보여준다. 복잡한 쿼리를 실행해야 하는 환경에서는 성능 저하 발생. |
SQL Compliance | SQL: 2011의 대부분의 기능을 지원한다. 완전한 Core 적합성을 위해 필요한 179 개의 필수 기능 중 PostgreSQL은 최소 160 개를 준수한다. 또한 지원되는 선택 사양 기능 목록이 많이 있다. | MariaDB는 일부만 준수하고 있다. |
ACID | PostgreSQL은 처음부터 ACID 를 지향했으며 모든 요구사항을 만족한다. | MariaDB는 InnoDB를 사용했을 때만 만족한다. |
High Availability | Wal log를 이용한 replication 구축. Master – Slave의 구조를 가지고 있으나, 단순 조회 업무라면 slave에서도 조회가 가능하다. 기본적으로 Slave를 Master로 승격시키면 기존 Master가 Slave 역할을 하는 것이 아니기 때문에 M-S-S의 3노드 구성을 권장한다. | 갈레라 클러스터를 이용한 Master – Master 구성 방식을 사용한다. 3 노드를 권장한다. |
Materialized Views | 지원 | 지원하지 않음 |
Programming Languages | DB 단에서 C/C++, Java, JavaScript, .Net, R, Perl, Python, Ruby, Tcl 등 많은 프로그래밍 언어를 지원. | 지원하지 않음 |
일반적으로 PostgreSQL는 좀 더 큰 규모의 비지니스에서 복잡한 쿼리를 사용하는 OLTP 환경 또는 많은 저장 데이터를 분석하고 응용할수 있는 OLAP 환경에서 많이 선택을 합니다. 병렬쿼리 기능이 구현되어 있어 멀티 쓰레드에서 쿼리를 처리할 수 있습니다. 또한 Geo Server + PostGIS + Openlayers 를 이용한 GIS 서비스 용도로 많이 선택을 합니다. JSON 형식을 빠르게 처리하는 능력을 갖추고 있고, 다양한 extension을 통한 확장성을 가지고 있습니다. Pgbouncer 같은 툴을 이용해 세션처리를 할수 있고, Pg_pool을 이용한 로드밸런스, Failover 기능을 사용 할 수 있습니다. 하지만 빠르게 버전업이 되는 오픈소스이기 때문에 한국어로 된 자료가 많지 않습니다. 오라클이나 MySQL 만큼의 레퍼런스 문서가 없고, 실제 운영에 있어 가이드 부분에서 어려운 부분이 있습니다. 또, 클라우드 환경에서 Scale-out하기 어렵습니다.
MariaDB는 단순한 트랜잭션 처리를 위한 OLTP/OLAP 환경에 유용하며, 윕 기반의 서비스 용도, 서비스가 중지되지 않도록 갈레라 클러스터를 이용한 Master-Master 구조가 필요한 환경에서 이점이 있으며, 플러그인 방식의 엔진 사용으로 사용자가 원하는 타입의 엔진을 사용할 수 있습니다. 기존에 MySQL 엔터프라이즈에서 플러그인으로 제공한 쓰레드풀 기능이 내장됐으며, 스토리지 엔진을 활용한 샤딩 기술을 제공합니다. 즉, MySQL의 오픈소스 버전을 넘어 모든 버전을 대체할 수 있는 특징들을 갖추고 있습니다. 물론 MySQL 8버전이 출시된 시점에 MariaDB도 10.4 버전부터는 MySQL과 완전 독립을 선언했습니다. 따라서 MySQL 8 이상의 버전과의 호환성은 앞으로 장담 할 수 없습니다. 또한 MariaDB의 InnoDB엔진에서 MySQL의 Fork 엔진인 percona의 xtradb 엔진을 사용하지 않습니다. 대용량 데이터베이스로 운용한다면 장애시 복구에 시간이 오래 걸린 다는 단점도 있습니다.
둘다 오픈소스 DB로 많은 선택을 받습니다. 하지만 아직까지 인식은 PostgreSQL가 좀 더 오라클을 대체하는데 있어서 성능과 안정성 면에서 뛰어나다는 평이 있습니다. 반면, 샤딩이나 고가용성 부분에서는 MariaDB가 나은점도 있습니다. 뿐만 아니라 요즘은 NoSQL 방식의 DB의 선택지도 많이 늘어났습니다. 로그성 데이터 수집이나 모니터링 용 DB에는 시계열 DB인 InfluxDB나 TimescaleDB도 많이 사용되고 있습니다. 용도와 규모에 맞게 선택하고 설계하는것이 중요하다고 생각합니다.
최신 댓글