RDBMS의 떠오르는 초신성 PostgreSQL

요즘 여러 회사들의 장애대응 회고를 보면서 드는 생각은 '요즘 PostgreSQL많이쓰네...' 였습니다. 어떤 회사들은 AWS RDS를 PostgreSQL로 한 회사도 있더라구요. 

 

그걸 보면서 어떤 점이 다른 RDBMS를 대체할만큼 매력적이었을까 의문이 들어서 PostgreSQL에 대해서 간단한 개요수준으로 공부해봤습니다. 

 

이번 포스팅에선 PostgreSQL이 다른 RDBMS와 차별점을 가지는 점에 대해서 포스팅을 할 생각입니다. 

 

PostgreSQL이 기존 RDBMS와 뭐가 다를까?

제가 아는 PostgreSQL은 Postgres라는 프로젝트에서 시작해 QUEL ('큐엘'이라고 발음하는 것 같습니다) 이라는 언어를 지원한다는 의미에서 PostgreSQL이 되었다고 알고 있습니다. 

 

때문에 발음이 포스트-그레스-큐엘인 것이라고 까지만 알고있었습니다. 그리고 잠깐잠깐 들리는 말로 RDBMS인데 분산 데이터베이스의 특징을 가지고도 있다고 들었습니다. 

 

MySQL도 부분적으로 샤딩을 지원하는 것으로 알고 있지만 그것이 널리 사용되는 것은 아니라고 알고 있었죠. 

 

하지만 제 개인적인 의견으로는 RDBMS를 분산 데이터베이스처럼 사용한다는 것은 엄청나게 많은 데이터셋을 가지고 있는데 NoSQL로 넘어가기엔 ACID나 다양한 제약조건을 포기할 수 없었던가 RDBMS를 NoSQL로 마이그레이션 하는 것이 매우 힘들기 때문에 PostgreSQL에서 샤딩을 선택하는 것이라고 생각하고 있습니다. 

 

즉, 분산 데이터베이스처럼 PostgreSQL을 사용하는 회사들은 많지 않을 것이라는 것이 제 생각입니다. 그래서 저는 더더욱 궁금했습니다. PostgreSQL의 특징 중 기존 RDBMS와 눈에띄게 다른 점이라면 분산 데이터베이스를 쉽게 적용할 수 있다는 것인데 그런 회사는 많지 않음에도 왜 PostgreSQL을 선택할까? 

 

본격적으로 한번 파헤쳐봤습니다. 

 

 

오픈소스

PostgreSQL은 오픈소스입니다. 오잉? MySQL이랑 MariaDB도 오픈소스인데? 맞습니다. 하지만 PostgreSQL은PostgreSQL라이센스를 가지고 있습니다. 이는 이 오픈소스로 지지고 볶아도 전혀 문제가 없다는 얘기입니다. 

 

MySQL은 GNU산하의 GPL (General Public License) 를 가지고 있어서 PostgreSQL에 비해 더 제한조건이 있는 라이센스입니다. 

 

오픈소스라는 장점때문인지 PostgreSQL은 엄청나게 큰 커뮤니티를 가지고 있고 extension도 꽤나 잘 되어있습니다. 

 

• Citus : PostgreSQL을 분산 데이터베이스로 만들어주는 멋진 녀석입니다. multiple node를 이용해서 sharding을 지원해준다는 특징이 있고 쿼리를 병렬처리 해준다는 특징도 있습니다. 
• PostGIS : 기하학적인 데이터를 SQL로 관리할 수 있게 만들어주는 extension입니다. 
• Patroni : PostgreSQL의 장애회복과 레플리카를 관리해줌으로써 높은 가용성을 챙길 수 있게 도와주는 extension입니다. 

제가 봤을 때 괜찮아보이는 것들 세개정도만 추려봤는데 꽤나 괜찮은 extension이 많더군요. 

 

하지만 PostgreSQL이 다른 데이터베이스에 비해 남다른 커뮤니티 크기와 다양한 extension을 가지고 있지만 사실 이게 여타 RDBMS를 대신해 PostgreSQL을 선택할만한 이유는 되지 않는 것 같습니다. 

 

기하학적인 데이터를 RDBMS에서 관리할바엔 NoSQL로 관리하고 장애회복은 여타 데이터베이스에서도 기본적으로 가지고 있는 기능이기때문이죠. 

 

 

확장성

제가 생각했을 때 여타 RDBMS와 다른 PostgreSQL만의 장점 중 하나가 아닐까싶습니다. 

 

무엇보다 PostgreSQL은 레플리케이션을 동기방식과 비동기방식을 지원해줍니다. 이 방식을 스트리밍 레플리케이션이라고 하더군요. 이 방식은 데이터가 바뀌는 것을 실시간으로 다른 데이터베이스가 보고 즉시 자신의 테이블에 적용하는 방식으로서 다른 RDBMS에 비해 레플리카에서 발생하는 쓰기연산의 리소스 비용을 최대한 줄일 수 있다고합니다. 

 

MySQL은 비동기방식의 레플리케이션과 세미동기방식의 그룹 레플리케이션을 지원합니다. 때문에 동기방식의 레플리케이션을 지원하지 않기 때문에 PostgreSQL에 비해 조금 덜 유연하다고 볼 수 있습니다. 

 

하지만 확장성도 PostgreSQL이 MySQL보다 조금 더 우세하다 하여 MySQL대신 PostgreSQL을 선택할 이유는 아닌 것 같습니다. 

 

 

인덱스

저였으면 이것때문에 PostgreSQL을 선택했을 것입니다. RDBMS에서 읽기 연산, 그것도 복잡한 조인 연산이 들어간 읽기 연산의 성능을 높이는 것이 항상 RDBMS 진영에선 큰 고민거리였습니다. 

 

때문에 조인 연산에서 조건문에 자주 걸리는 FK나 일반적인 쿼리에서의 조건문인 where절에서 자주 걸리는 컬럼에 대해 인덱스를 설정하여 읽기 성능을 끌어올렸습니다. 

 

인덱스는 데이터베이스 엔진이 데이터를 더 잘 찾을 수 있도록 컬럼을 정렬해주는 것이기 때문에 잘 설정하면 성능적인 부분에서 큰 이점을 얻을 수 있었습니다. 

 

기본적으로 MySQL에서 제공해주던 인덱스 설정은 B- tree, 부분적으로 가능한 Hash Index, 일반 VARCHAR 컬럼에 걸었던 full-text Index가 있습니다. 

 

Hash Index는 MySQL의 기본 엔진인 InnoDB 스토리지 엔진이 아닌 Memory 스토리지 엔진에서만 부분적으로 적용되던 문제가 있었습니다. 

 

하지만 PostgreSQL은 인덱스의 측면에서 MySQL을 압도하는 능력을 가지고 있습니다. 

 

• B- tree : 보통 많은 RDBMS에서 사용하는 인덱스 설정으로 = 연산자로 가져오는 쿼리인 point query와 between으로 가져오는 쿼리인 range query에 범용적으로 사용할 수 있는 인덱스 설정입니다. 
• Hash Indexes : PostgreSQL은 기본적으로 Hash Index를 지원합니다. 이 Hash Index는 = 연산자로 가져오는 point query에 최적화 되어있다는 특징이 있습니다. 하지만 반대로 range query에는 적절하지 않습니다. 
• Full-Text Indexex : 일반 VARCHAR에 해당하는 컬럼에 걸면 좋은 인덱스 설정입니다. 
• GIN (Generalized Inverted Index) : GIN은 복잡한 JSONB같은 복잡한 타입의 데이터에 효과적인 인덱싱 방법입니다. 하지만 인덱스의 관리가 복잡해 UPDATE연산이 기존 인덱스보다 더 느려지는 경향이 있습니다. 
• GiST (Generalized Search Tree) : 표기법이 정말 이상한 GiST 인덱싱 방법은 기하학적인 데이터 타입이나 Full-Text에 적합한 인덱싱 방법입니다. 
• SP-GiST (Space-Partitioned Generalized Search Tree) : 이 인덱싱 방법은 봐도 이해가 안되더라구요... 잘 사용하지 않는 특정한 데이터 타입에 사용하는 것 같습니다. 
• BRIN (Block Range INdex) : 얘도 표기법이 이상한데 이친구는 time-series 데이터 들이 엄청나게 많은 테이블에 주로 사용하는 인덱싱 방법이라고합니다. 아마 로그나 그런 곳에 사용하는 것 같네요. 

 

정리하자면 다음과 같습니다. 

 

• point query에는 B- tree, Hash Index를 사용하자
• range query에는 B- tree, GiST를 사용하자
• 복잡한 데이터 타입 (배열, JSONB)는 GIN을 사용하자
• time-series 데이터들은 BRIN을 사용하자
• Full-Text는 GIN, GiST, Full-Text 인덱싱을 사용하자

 

 

마치며

PostgreSQL은 오픈소스이니만큼 다른 RDBMS에 비해 공부할게 더 많은 것 같습니다. 마치 Jenkins나 QueryDSL처럼 공부할게 좀 많네요...

 

나중에 시간이 난다면 PostgreSQL을 이용해서 분산 데이터베이스를 사용한 사례나 동작방식을 포스팅해보고싶네요. 

 

긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요~