PostgreSQL, 많이 쓰시나요?

권순선의 이미지

KLDP 서버 업그레이드와 관련해서 현재 사용중인 MySQL 대신 PostgreSQL로 교체하는 것이 어떻겠냐는 제안이 있었습니다.

사실 저 개인적으로는 둘 사이의 성능이나 기능에는 큰 차이가 없다고 생각했고, 사용하고 관리하는 사람에게 익숙한 것이 어느 것이냐, 그리고 문제가 생겼을 때 좀더 많은 사람들에게 좀더 쉽고 빠르게 조언을 얻을 수 있는 것이 어느 것이냐 하는 점에 좀더 신경을 써 왔는데 실제로 pgsql이 얼마나 널리 사용되고 있는지 궁금합니다. 데이터베이스를 요하는 FOSS 소프트웨어들 중에서도 거의 대부분이 MySQL만을 지원하는 경우가 대부분이고 pgsql을 기본으로 지원하는 소프트웨어들을 찾기가 쉽지 않았기에 이러한 선입견이 쉽게 해소되지 않네요.

pgsql, 많이 쓰시나요? 어디에 주로 쓰시나요? mysql이나 다른 데이터베이스에 비해서 어떤 점이 좋던가요?

세이군의 이미지

일단은 PHPBB와 drupal 모두 pgsql에서 사용이 가능한 프로그램이죠.
트랜잭션이라던가 MySQL 3.x에서는 지원이 안되는 기능을 써야 하는 경우에 pgsql을 사용한 것으로 기억합니다.
MySQL에 innodb가 들어가서 트랜잭션이라던가 안정성이 더 많이 확보되기 전까지는 꽤 많이 쓰는 것으로 보고 있습니다.

최근에 나오는 것은 어째 pgsql을 잘 쓰지 않는 것 같기도 하더라구요...
이유는 잘 모르겠지만 점차 사용이 줄어드는 것 같기도하고...

최근 추세는 잘 모르겠습니다.
--------------
한 걸음 더 가까이

dormael의 이미지

제 의견은 큰 차이가 없다. 어떻게 쓰느냐에 따라 다르다 입니다.

우선 drupal만 예로 들자면 잠깐 작업하면서 쿼리들을 봤을때 범용적으로 쓰이고 개인 용도를 위한 것이라는 느낌이 강하게 들었습니다. 그 이상의 용도라면 이용자가 적절히 수정해서 써야 겠지요.

최소한 제가 본 tracker모듈, 포럼(node, comment 등등의 테이블)의 스키마가 그랬습니다.
몰론 아직 PostgreSQL 에서 tracker모듈의 쿼리가 어떻게 돌지는 보지 못했지만 쿼리의 조건들이 인덱스도 타지 않고 도는것들이 대부분이고 비록 LIMIT가 있어서 이미 많은 수의 row를 가져와서 정렬한 후 LIMIT를 주는것, 이런경우 가져올 갯수를 비약적으로 줄이면 LIMIT 안줘도 더 빠릅니다. 물론 효용이 아예 없는건 아니지만 이미 테이블 조인후 정렬한 후에 준거는 앞의 부담에 비하면 새발의 피로 작용할 겁니다. 데이터가 많으면 많을수록 더 심해지겠죠.
이런 상황이라면 어떤 DBMS라도 장사가 없을거라 생각합니다.

정말 로드가 심한데서는 count나 sum도 함부로 못씁니다. 특정 row에다가 값을 update하게 되죠.
얼마전에 제가 글 올렸을때 atie님이 말씀해 주셨던거 같은데요. 조금 성격이 다른 얘기였나?
그리고 트랜젝션을 쓴다면 써야할 만한 곳에서 쓰는게 맞다고 봅니다. 그만큼의 비용(직업용어 ㅋㅋ)이 따르기 때문이죠.
drupal이 PostgreSQL의 트랜젝션을 지원하는지 확인해 봐야 합니다. 사실 innodb도 지원하긴 하는데. ㅋㅋ
저 mysql 영업사원 아닙니다.
만일 바꾼다면 PostgreSQL에 대해서 배울 수 있어서 좋긴 하겠네요. ^^

어떤 소프트웨어도 특별히 더 대단한게 있는건 아닌거 같습니다. 다만 어떻게 잘 이해하고 쓰느냐가 중요하겠지요. 용도에 맞게.
도구가 살인을 할수도 사람을 먹여 살릴수도 있으니까요.

그런데 혹시 디비서버 죽었었나요? 아까 퇴근시간쯤에 접속이 잠시 먹통이 되었던거 같던데..
그거라면 제가 설정한 캐시, 버퍼 값들이 너무 커서 그랬을 가능성도 있습니다.
혹시라도 로그가 남았으면 알려주세요. ^^

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

소타의 이미지

며칠전에 pgsql얘기를 꺼내기 전에 drupal사이트에 가서 이런저런 글들을 훑어 보았는데 pgsql에서 "well" 동작한다는 글을 많이 보았습니다. 어떤 DBMS로 돌리고 있냐는 투표에서도 pgsql이 2위를 차지했습니다. mssql이나 오라클로 돌린다는 사람들도 있더군요;;;

pgsql의 특성이라면 SQL표준을 잘 지키고 고유한 기능들을 많이 가지고 있습니다. 최초의 오픈소스 DBMS(77년생이죠?)인 만큼 지원하는 어플리케이션도 많고 여러 플랫폼에 이식되어 있습니다. 해외에서는 공공기관에서 메인 DBMS로 채택할 정도로 신뢰성과 성능을 인정받고 있습니다. 국내에서는 이상하게 좀 찬밥이죠;; 미국, 유럽, 일본에서 많이 쓰이고 있고 커미터도 대부분 이쪽 계열입니다.

라이센스가 BSD이다 보니 많은 기업들이 가져다 쓰고 많은 지원을 하고 있습니다. 가장 큰 스폰서는 후지쯔(http://www.fastware.com.au/index.html)이고 레드햇(RHDB: http://sources.redhat.com/rhdb/)도 있고요. 그 외에 썬 등이 참여하고 있습니다.

pgsql은 많은 실험들을 합니다. 많은 DB관련 논문이 pgsql을 기반으로 발표되고 그중에 많은 것들이 적용됩니다. DB관련 신기술 중 많은 것들이 pgsql에서 시작되어 왔습니다. 하지만 이것이 신뢰성을 낮추지는 않습니다. 지금도 많은 contrib들이 함께 배포됩니다. tsearch2 같은 풀텍스트 인덱스(단어의 빈도 및 연관성, 랭킹까지 지원), 공간 벡터 인덱스, fuzzy텍스트 인덱스, 배열 인덱스, ltree, 오라클 호환, crypt, xml 등의 다양한 외부 모듈들이 존재합니다. 충분히 안정화 되면 백엔드에 포함되게 됩니다.

프로시저 언어로는 pl/pgsql, pl/c, pl/perl, pl/python, pl/tcl을 기본 지원하며 확장 언어로는 pl/php, pl/java, pl/sh 등이 있습니다. 다양한 언어로 DB 서버 사이드 개발이 가능합니다.
그리고 ORDBMS의 특성을 가지고 테이블 상속, 사용자 정의 데이터 타입이 가능합니다.

이런 고유한 특성 외에도 기본적인 좋은 기능들도 많습니다. 일단 많은 데이터 타입이 지원됩니다. [big|small]int, [big]serial, bit, bytea, text, boolean, [var]char, time[stamp], date 같은 기본적인 타입 외에도 line, box, circle, path, point, polygon 같은 공간을 표현하는 데이터 타입이 지원됩니다. 이 공간 관련 데이터 타입들은 엽기적이라고 할 수 있는 인덱스를 지원합니다 -_-; 예를 들어 세계지도를 축적을 정해서 DB화 시켜놓으면 보통의 로컬 검색엔진들처럼 특정 영역과 관련된 데이터들을 인덱스 한다거나 하는게 가능합니다. 이보다 많은 데이터 타입이 기본적으로 존재합니다.
그리고 이 많은 데이터 타입을 조합하여 하나의 복합적인 타입(composite type)을 만들 수 있습니다. 일반적인 테이블의 한 ROW를 하나의 필드로 잡을 수 있다는 것입니다;
pgsql은 지원하는 모든 데이터 타입을 다차원 배열로 만들수 있습니다. 테이블을 만들 때 단지 데이터타입[][][] 해주면 3차원 배열로 해당 데이터를 사용할 수 있습니다. composite 타입 역시 배열화 할 수 있는데 이것들을 조합하면 테이블 하나로 모든 비즈니스 로직을 처리할 수 있게도 됩니다. 실제로는 테이블 하나로 끝내지 않지만 아주 유용하게 쓰일 수 있습니다.

기본적인 기능 중에서는 다양한 인덱스 지원이 있는데요. btree, hash, rtree, gist가 기본적으로 지원됩니다. 외부 contrib를 이용하여 이것들의 조합이나 새로운 데이터 타입에 대한 인덱스를 만들 수 있습니다. 함수의 결과를 인덱싱 하는 것도 가능하구요. Partial 인덱스라고 특정 영역만을 잘라서 인덱싱 할 수도 있습니다. 그리고 최근 버전부터는 자동으로 메모리에 비트맵 인덱스를 생성함으로써 큰 테이블끼리의 복잡한 쿼리의 성능이 향상되었습니다. 데이터의 타입과 자주 사용하는 연산자에 따라서 인덱스를 선택하여 성능을 극대화 할 수 있습니다.

그 외에 중첩 트랜젝션, 아카이브 로그를 이용한 증분백업, 저널링 파일시스템과 유사한 WAL, row level lock 등 고가의 상용 DBMS나 지원할만한 기능들이 포함되어 있습니다. 다국어 환경을 지원하고 server/client 인코딩 컨버전이 자동으로 이루어 지고요. LISTEN/NOTIFY라는 걸로 DBMS차원의 클라이언트 동기화도 지원합니다.

할말이 더 있을 것 같은데 이정도 밖에 생각이 안납니다! -.-;;

lacovnk의 이미지

ORDBMS를 써보지는 않았지만, 작은 어플리케이션의 스키마를 ORDBMS 답게 만드는 것은 배보다 배꼽이 커질 것 같다는 생각이 듭니다. 언급하신 여러 기능들이 특정 상황에서는 굉장히 유용한 기능이 될 것 같은데, 작은 어플리케이션엔 그닥 필요하지 않다보니 사용층이 얇은 것이 아닐까 추측해봅니다.

그러고보니, 그런 기능들을 잘 활용하는 케이스가 궁금합니다. 신기하군요!

소타의 이미지

저는 pgsql을 이용해서 개발한지가 꽤 되었습니다.
보통 pgsql에 대한 속설중엔 "느리다"라는 말을 많이 들었는데요; 써보면 mysql보다 느리지도 빠르지도 않습니다.
보통 단순 select 하는걸로 벤치마크를 하는데 이건 DBMS의 성능 문제가 아니라 btree라는 알고리즘을 어떻게 구현하느냐 싸움밖에 안됩니다;; 인덱스 스캔이 아닌 시퀀셜 스캔이라면 디스크 속도 싸움입니다.. 실제로 어떤 비즈니스 로직을 모델링하고 그 안에서 움직이는 쿼리를 가지고 벤치를 해야 하는데 여기서 문제가 생기는게 pgsql은 모델링 자체가 다릅니다..
요즘은 mysql도 좋아졌지만 예전에 이런말이 있었습니다. "오라클을 mysql처럼 쓴다"..
일반적인 DBMS에서의 모델링 기법으로 pgsql을 사용하면 C++로 C처럼 짜는것과 같습니다 -.-;
pgsql은 ORDBMS를 표방하고 있어서 테이블 상속이나 데이터 타입의 상속(일반 데이터 타입 - composite - 배열 같은..)등으로 모델링 자체가 달라지게 됩니다. 물론 일반적인 모델링도 가능합니다. 불가능하지는 않습니다 ^^;;

하지만 결과적으로 모델링이나 쿼리가 복잡해지면 질수록 pgsql이 뛰어난 결과를 보여줄 확률이 많습니다. pgsql은 데이터의 타입이나 연산자에 따라 인덱스를 선택할 수 있고 Partial 인덱스를 통해 인덱스의 크기를 상황에 따라 최소화 시킬 수도 있습니다. 큰 테이블이 작은 인덱스의 조합들을 가질 수 있게 되는데 작은 인덱스끼리의 join은 많은 성능 향상을 야기할 수 밖에 없습니다. 10000 X 10000 과 100 X 100 의 차이와 같다고 보시면 됩니다.

pgsql은 제가 아는한 가장 똑똑한 쿼리 옵티마이저를 가지고 있습니다. 지속적으로 데이터 분포의 통계를 뽑아내고 최적의 쿼리 플랜을 만듭니다. 많은 테이블들이 조인될 때에도 연산자와 데이터의 분포에 따라 인덱스 사용 여부와 사용할 인덱스들, 조인 방식, 정렬 방식을 결정합니다. 인덱스가 걸려있는 필드라고 무조건 인덱스를 써서 조인하는 바보같은 짓을 하지 않습니다. 하지만 인덱스 및 동작 방식을 사용자가 실시간으로 결정할 수 있게 하는 방법도 제공하고 있습니다.

죠커의 이미지

SQL-Server와 MySQL만 쓰고 있었는데 이제 부터 쓸려고 합니다. 앞으로 공개이며 기능이 강력한 PostgreSQL은 더 널리 쓰이지 않을까 생각합니다. 물론 오픈소스 프로젝트에서 큰 파이는 MySQL이 차지할 것 같습니다.

- CN의 낙서장 / HanIRC:#CN

1day1의 이미지

라이선스 면에서는 mysql 보다 pgsql 이 더 매력적인데, 왜 국내에서는 많이 쓰이지 않는 것일까요?
관련자료의 부족? 속도가 느려서?(지금은 많이 나아졌죠) 지원하는 호스팅이 적어서?

왜 그럴까요?

F/OSS 가 함께하길.. (F/OSS서포터즈,F/OSS서포터즈그룹)

F/OSS 가 함께하길..

dormael의 이미지

속도는 잘 모르겠지만 그 외에는 1day1님께서 말씀하시는게 다 해당사항이 아닐까요?
그리고 편한 툴도 부족한(mysql에 비해서)것 같습니다.

뭐 이런 복합적인 이유로 이미 따라잡기에는 쉽지 않은게 아닐까 싶네요. 이미 많은 사람들이 익숙해져 버려서요.

적절한 비교인지 모르겠지만 윈도우와 리눅스도 이런 비슷한 상황이라 생각합니다. 이미 많은 사람들이 윈도우에 익숙해져 버려서 이제 리눅스로 옮기기에는 쉽지 않을것 같습니다.

물론 pgsql이나 리눅스나 계속 분발하고 있으므로 앞으로 어떻게 될지는 더 두고 봐야겠지요. ^^

제 생각은 이렇습니다.

-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.

정태영의 이미지

라이센스 면에서나 다른 면에서나 제로보드보다 더 나은 게시판들이 많은데 그래도 제로보드를 많이 쓰는 것과 다르지 않다고 생각합니다 :)

또한 ORDBMS 의 특징들을 제대로 활용해야할만한 곳이 대다수가 아니었기 때문에 postgresql 의 장점이 그렇게 부각되지 못한게 아닐까 싶기도 하군요.

---
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

stypr의 이미지

꼭.꼭.pgsql을 사용할 처지가 아니라면, 익숙한 mysql을 사용하세요.

candinate의 이미지

지금 보면 pgsql은 사실 경쟁에 실패한 케이스로 죽은 상태와 같은거 같습니다.

mysql은 이미 국내외에서 성공하고 인정받고 있고요.

국내에서도 네이버같은 포탈이 mysql쓴다고 아는데 pgsql은 유명한 사이트는 쓰는곳을 알려진데가 업는거 같네요?

혹시 아시는 분 알려주세요.

정태영의 이미지

유명한 사이트는 모르겠고 http://database.sarang.net dsn 이 postgresql 기반인걸로 알고 있습니다 :)

dsn 에 질답 게시판 같은델 보고 있으면 죽었다고 보기엔 포럼이 활발하네요.

-----------------------
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

kimbeast의 이미지

지금 제가 담당하는 서비스의 디비가 Postgresql 입니다.
2년전에 M$를 버리고 무작정 이 DB로 뛰어들었는데. 그냥 포팅만 된다고
그리고 남들이 좋다고 해서 될일이 아니더군요.
대규모 트랜젝션에서는 장사가 없나봅니다.
지금 2년이나 지나서 그런지 나름대로 노하우가 쌓여서 그나마 잘 운영하고 있지만.
처음에 한 1년동안은 정말 욕도 많이 먹고 고생도 많이 했습니다.

지금 하고 있는 서비스의 트랜젝션은 왠만한 포탈 저리가라 할 정도로 엄청납니다.
(처음 구조가 잘못되어있어서 이렇게 많은 트랜젝션을 담당할꺼라 생각하지 못했죠.)
그러면서 IO 문제가 생기고 그리고 Postgresql 의 vacuum의 문제에 봉착하고.
아직도 Postgresql의 가장 골치거리는 이 vacuum과정입니다.
insert/update/delete로 생긴 데이터 overhead를 정리해주는 과정이 필요한데
Vacuum full로 작업해서 데이터 공간 반환하자니 서비스를 오랫동안 정지시켜야하고
그렇지 않으면 디비가 점점느려집니다.

또..대규모 프로젝트의 노하우가 적은듯 싶습니다.(Mysql에 비해서)

노하우가 많지않다면.. 그냥 mysql로 하심이 좋을듯 싶습니다.

----------------------------------------------------
난 프로그램 창조자이다. Coder가 아니다.
----------------------------------------------------

----------------------------------------------------
난 프로그램 창조자이다. Coder가 아니다.
----------------------------------------------------

익명 사용자의 이미지

라이센스를 구입하기 전에는, 상용으로 마음대로 쓸 수 없는 MySQL보다는,,,

별도의 라이센스 구입이 필요없이 상용으로 마음대로 쓸 수 "있는" ,,,,, FireBird(파이어버드)가 더 낫지않나요 ?

빠르고, 가볍고, 라이센스 걱정도 없고,,,

http://www.firebirdsql.org

송효진의 이미지

PostgreSQL 잘 쓰려면 책이 필요해요...
ORDBMS 로 멋지게 구성해볼 수 있는 한글로 된 책 하나 있었으면... :)
- 이모티콘 넣어주세요~ -

emerge money

익명 사용자의 이미지

과거에 3.x때의 MySQL은 물리적 구현에 있어서 몇몇부분들이 지원되지 않는 기능들이 있었고 개발자 입장에서는 애플리케이션의 역할이 커지다보니 PostgreSQL 쪽으로 눈이 갈수밖에 없었던것 같네요.

하지만 MS-SQL이나 오라클의 반에 반에 반만이라도-_-;; 책이 나온다면 아마 많은 사람들이 몰릴것 같습니다만..;;
그럴 확률보다 Microsoft사가 망할 확률이 더 높으므로 아예 다른 DBMS를 고려해보겠습니다.