1. RDBMS의 엔진 순위
- DB 엔진 순위는 매 달 업데이트 되며, 2015년 05월 전체 4위를 하고 있습니다.
(DB-Engines : http://db-engines.com/en/ranking/relational+dbms)
2. PostgreSQL의 기본적인 시스템 속성
- PostgreSQL은 BSD License를 사용하고 있으며, BSD License는 자유 소프트웨어 저작권의 한 가지입니다. 즉, BSD License를 갖는 프로그램은 공개하지 않아도 되는 상용 소프트웨어에서도 사용할 수 있습니다. GNU GPL과 다른 점은 파생된 결과물에 대해서 소스 코드가 반드시 배포되도록 하는 것인데요. GPL을 만들어 낸 리쳐드 스톨먼의 의지에 따른 결과물이라고 합니다.
(위키백과 : http://ko.wikipedia.org/wiki/BSD_%ED%97%88%EA%B0%80%EC%84%9C)
- Server Operation System은 리눅스, 유닉스, 윈도우 대표적으로 많이 사용하는 OS는 모두 가능하다고 되어있지만, 보편적으로 윈도우에서 운영하는 건 아직 불안정 하다고 합니다. 예전보다 많이 개선 되었지만, 기술적인 부분이 좋아진다면, 윈도우에서도 PostgreSQL을 사용할 수 있지 않을까 조심스럽게 추측해봅니다.
- PostgreSQL에서 SQL을 사용할 때 T-SQL(Oracle에서 사용하는 SQL문법)은 불가능하며, ANSI-SQL을 표준으로 사용하고 있습니다.
3. PostgreSQL 9.0 Architecture
- Oracle Architecture 구성과 비교하면 큰 영역에서는 비슷한 점이 많습니다. 오라클의 경우 클라이언트, 오라넷(리스너), SGA(메모리), 프로세스(PMON, SMON, LGWR, CKPT, DBWR, SERVER Process 등), 데이터베이스(컨트롤 파일, 리두 로그 파일, 데이터 파일, 패스워드 파일, 아카이브 파일) 전체적인 모습은 유사하다는 것을 알 수 있습니다. 그런데 특이한 점은 Postmaster인데요. 오라클로 재 해석하면 리스너와 같은 형태를 지니고 있습니다. 클라이언트는 인터페이스 라이브러리(libpg, jdbc, odbc 등의 다양한 인터페이스)를 통해 서버와의 연결을 요청하면, Postmaster 프로세스가 서버와의 연결을 중계합니다. 이후 클라이언트는 할당된 서버와의 연결을 통해서 질의(SQL)를 수행 할 수 있습니다.
(한눈에 살펴보는 PostgreSQL : http://helloworld.naver.com/helloworld/textyle/227936)
4. PostgreSQL 장점
- 라이선스에 대한 비용 문제가 전혀 없습니다.
- 일반 DB 벤더에 비해서 지원을 통하지 않고, 커뮤니티에서 전문가가 남겨 놓은 자료로 충분히 자료를 얻을 수 있습니다.
- 상용DB보다 유지보수 비용을 감소할 수 있고, 성능 튜닝에 대한 비용이 낮습니다.
- 전설적인 신뢰성과 안정성을 가지고 있습니다.
- 오픈 소스 코드이기 때문에 확장할 때 무료로 쉽게 사용할 수 있습니다.
- 원래 유닉스 기반이지만, 8.0부터 윈도우도 지원하고 있고, 크로스 플랫폼 지원이 가능 합니다.(윈도우는 현재까지 개선을 하고 있는 중입니다.)
- 여러 행 데이터에 대한 저장 전략이 높은 볼륨 환경을 위해 설계되어 있습니다.
- GUI 인터페이스를 통해 DB 설계 및 관리 할 수 있습니다.
5. PostgreSQL 단점
- 수많은 사용자를 동시에 서버에 접속 할 때 불안합니다.
- 기술지원에 대한 안정성 확보가 부족하며, PostgreSQL 매뉴얼을 확인 해보면, 대부분 에러에 대한 내용을 사용자에게 맡기고 있습니다.
- H/A 구성은 가능하나, A/A 구성은 지원 하지 않습니다.
- 풍부한 데이터 사전이 존재하지 않습니다.
- 정기적인 Vacuum 작업을 해야 합니다.
6. PostgreSQL 이중화 구성
- Shared Disk Failover
- Disk 를 share 하여 multiple server 로 사용한다. (NAS)
- 구성이 쉽지만, NAS 가 장애날 경우 Primary/Standby 서버 모두 사용할 수 없다는게 단점
- Standby 서버는 평소에 놀고 있다는 단점
- File System (Block-Device) Replication
- Disk 복제로 replication 하는 방식
- DRBD 라는 disk block 복제 솔루션을 많이 사용한다
- Write 시에 locking 이 되어, Active-Active 구조가 되는지는 모르겠다
- Active(1)-Standby(N) 구조로 많이 사용하며, PostgreSQL 8.x 버전까지 많이 사용하던 방식임
- Transaction Log Shipping
- Warm/Hot Standby 서버 가능
- PostgreSQL 9.x 버전부터 Streaming replication 을 공식 지원
- Master 에서 WAL log 를 보내고, Standby 에서 WAL 을 receive 하여 복제하는 방식
- Standby 가 read-only DB 로 활용할 수 있다는게 장점임
- Active(1) : Standby(N) 구조 가능
- Trigger-Based Master-Standby Replication
- Slony 가 대표적인 솔루션
- Trigger 방식으로, Master 의 변경사항을 Standby 가 받아서 동기화 하는 방식
- Standby 가 read-only DB 로 활용 가능
- Trigger 방식으로 DDL replication 은 지원하지 않음
- Statement-Based Replication Middleware
- 대표적인 솔루션은 pgpool-II
- 모든 Query 액션을 중간 middleware 에서 DB 서버로 전달하는 방식
- write 시에는 모든 서버에 쓰기를 하며, read 시에는 한 서버에서만 읽어옴
- Write Overhead 가 발생함 ( 보통 30% 정도라고 함 )
- random(), CURRENT_TIMESTAMP, sequences 를 사용할때 서버에 따라서 다른값이 될 수 있어, 이런 기능을 사용할때는 특정 한 서버만 지정하여 사용하는식의 방법이 필요
- 위와 같은 방법이 힘들 경우, 그냥 Master-Standby 구조로 사용하면 문제 없음
- Asynchronous Multimaster Replication
- Bucardo 가 대표적인 솔루션
- 각각의 서버는 독립적으로 DB 역할을 하며, 주기적으로 비 동기방식으로 서버 동기화를 함
- 멀티 마스터 서버 구축이 가능
- Synchronous Multimaster Replication
- 동기식 멀티-마스터 방식을 사용하면, 데이터를 write 하고/수정할 때마다 모든 서버에 request 를 날려야 함
- 따라서 성능이 저하되고, 과도한 locking 이 발생함
- single 서버를 사용할 때보다도 write 성능이 저하 될 수 있음
- PosgreSQL 은 이 방식은 지원하지 않음
(PostgreSQL H.A Solution : https://geeluck0131.wordpress.com/2014/04/24/postgresql-h-a-solution/)
7. 마치며…
- 오라클 데이터베이스 사용자가 PostgreSQL을 접하게 된다면 어색하지 않을 수 있도록 되어있고, PPAS 상용버전을 설치 할 경우 오라클에서 사용하는 모든 것을 제공하도록 되어있습니다. 만약 운영할 수 있는 기술력만 갖춰진다면 정말 좋은 데이터베이스 입니다. 국내에 KT, KOSCOM, SK텔레콤 많은 사이트에서 PostgreSQL을 운영하거나, 변경 작업을 시작 하고 있을 정도로 트랜젝션, 성능, 트래픽, 가용성 모두 좋은 평가를 받고 있습니다.
JOB 서치로 유명한 Indeed에서 Job Trend를 확인해본 결과 오라클보다 월등히 많은 사람을 채용하려고 합니다. 국내에는 반대로 오라클에 대한 채용이 더 많지만 현재 전 세계 트랜드는 오픈 소스 DBMS로 전환하기 위해서 노력 하는 것은 아닌가 예측 해봅니다. 지표에는 나오지 않았지만, MariaDB는 Job Trend에서 가장 높은 평가를 받고 있습니다. 비용에 대한 장점이 강력한 PostgreSQL을 검토해볼만한 가치는 충분하다고 보여집니다.
