database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 5149 게시물 읽기
No. 5149
postgresql 에 대한 간단한 궁금증.
작성자
이창훈(mushim)
작성일
2004-01-09 05:15
조회수
1,970

postgresql 게시판에는 처음 글을 쓰는 군요.

 

예전에 mysql 과 postrgresql 중에서 선택을 하게 될 기회가 있었습니다.

 

웹서비스용으로 어느쪽이 성능이 좋은가 테스트를 해보니, mysql 쪽이 조금 우세한 것으로 결과가 나와서 mysql 쪽으로 가게 되었습니다.

 

그뒤로 점점 mysql 에 조금씩 익숙해지다 보니, postgresql 쪽으로 눈이 잘 안가지더라구요.

 

그러던중 database.sarang.net 개편되고, 검색했을때의 그 엄청난 빠르기에 감탄을 하게 되어서 postgresql 도 배워봐야 되겠다는 생각이 들게 되었습니다.

 

예전에 테스트를 할때 mysql에 비해서 postgresql 이 느린 가장 큰 이유가, 커넥션 요청에 대해서 fork 방식으로 새로운 프로세스를 생성하는것이 성능저하의 가장 큰 이유였던 것 같습니다.

 

중간에 커넥션풀을 만들어서 핸들링을 해주는 프로그램을 찾아 보았었는데 적당한게 없어서 포기했었던 적이 있었습니다.

 

요새는 그 문제에 대해서 어떤 식으로 개선책을 찾았나 궁금하군요.

이 글에 대한 댓글이 총 3건 있습니다.

fork()로 커넥션을 만드는 것은 예나 지금이나 다르지 않는데요.

만약 사용해 보시고자 한다면, 꼼꼼한 테스를 한번 해보세요.

DSN의 커넥션은 커넥션 풀도 사용하지도 않고, 그렇다고, p_connect()을 사용하고 있지도 않습니다. 거기다가 DB서버와 웹서버가 물리적으로 다른 호스트에 있는지라, 매번 페이지가 호출 될 때마다 db 서버에 연결을 시도하고, 페이지가 다 호출되면 db 서버와의 연결을 끊습니다. - 이 방식이 정말 무식한 방법이 아닌가? 라고 생각할지 모르겠으나, DSN 웹 서비스를 사용해 보시면 아시겠지요.

 

'하위 프로세스를 만들기 때문에 느려서 못쓰겠다'는 생각은 뭔가 잘못된 듯합니다.

 

계산상으로는 웹서버가 한 페이지를 보여주기 위해서 DB서버를 사용하는 시간은 커넥션까지 모두 포함해서 평균 0.04초 정도, 검색 기능을 사용하게 되면 평균 0.2초 정도입니다. 즉, 그렇다면, 하나의 프로세스가 초당 처리해 낼 수 있는 웹페이지가 5-25개 정도 됩니다.

이런식이라면, 웬만한 웹서버스에서 두개의 하위 프로세스가 동시에 돌아가는 경우(이를 동시 커넥션수라고 하지요)도 극히 드문상황이 됩니다. 즉, db 서버가 돌아가고 있는 호스트에서 현재 실행중인 프로세스가 너무 많아서 새로운 프로세스를 만드는데 필요한 비용이 너무 많이 드는 사태가 있을 수 없는 것이지요.

 

늘 이야기 하는 것이지만, DB 작업에서 가장 중요한 것은 어떤 DB를 쓸 것인가? 이게 아니라, 그 작업 안에서 사용되는 쿼리들이 얼마나 퍼팩트한가? 인것 같습니다.

 

DB를 선택하는 이유는 그 DB가 가지는 고유한 기능들이 다른 DB에서 구현할 수 없기 때문에 그 기능을 쓰기위해서 DB를 선택하는 것이 아닐까싶습니다.

 

DSN에서 PostgreSQL 놈을 사용한 이유는 다음과 같습니다.

  • 이곳 정신적 지주 - 흔히 대빵이라고 표현하는 정재익님의 처음부터 DSN을 PostgreSQL놈으로 운영해 왔기 때문 - 정통성을 따르기 위해서 -.-
  • 개인적으로 open source DB 가운데, 가장 마음에 드는 개발 방식을 택하고 있기 때문에 - 잘못된 길로 가고 있었다면, 옛 버전의 호환성과 상관없이 과감하게 바뀝니다.
  • 테이블 상속 기능을 쓰기에 좋은 사이트이기 때문에.
  • 그리고 마지막으로 많이 쓰지 않는 DB이지만 꽤 멋진놈이다는 것을 보여주고 싶어서.

여기에는 속도가 빠르기 때문에 이 DB를 선택했다는 것은 빠져있습니다. 디비 선택에서 속도 문제는 일반 사이트에서 그리 큰 문제가 되지 않는다고 봅니다. 이 사이트를 보시면 아시겠지요 :)

 

김상기(ioseph)님이 2004-01-09 09:53에 작성한 댓글입니다.

>>즉, db 서버가 돌아가고 있는 호스트에서 현재 실행중인 프로세스가 너무 많아서 새로운 프로세스를 만드는데 필요한 비용이 너무 많이 드는 사태가 있을 수 없는 것이지요.

 

프로세스가 많아서가 아니라, 프로세스를 생성하는데 드는 오버헤드가 크다는 뜻으로 말씀드린것입니다.

 

제가 예전에 테스트했을때는, 쿼리자체가 간단한거라서 전체부하중에서 커넥션할때의 부하가 과대계상된면도 있을것입니다. 단순쿼리가 많은 경우에는 이런면이 좀 문제가 될 수 있겠죠.

 

>>그리고 마지막으로 많이 쓰지 않는 DB이지만 꽤 멋진놈이다는 것을 보여주고 싶어서.

 

꽤 멋진것 같네요. ^^

이창훈(mushim)님이 2004-01-09 11:55에 작성한 댓글입니다.

어느 OS에서 테스팅을 해보셨는지는 모르시겠지만, 유닉스 계열쪽에서는 한 세션을 쓰레드로 만들든, 하위 프로세스로 만들든 속도와 퍼포먼스가 PostgreSQL 놈을 선택하는데, 저해요소가 되지 않는다고 봅니다.

물론 당연히 MySQL 놈보다 한 세션을 활성화 시키는데, 걸리는 시간이 많이 걸리고, 퍼포먼스도 많습니다. 하지만, 이 차이는 fork() 문제가 아니라, 세션을 열때 벌어지는 작업이 MySQL 하고는 차원이 틀리니 당연한 결과라고 봅니다. 또한 이 단점이 서비스에 치명적인 영향을 줄만큼 큰 차이가 나는 것도 아니라고 생각합니다.

 

문제는 M$ 동네 쪽인데, 이놈은 당연히 차이가 날 수 밖에 없습니다. cygwin 기반에서 fork() 기능을 결국 시물레이션 하는 꼴이니.

현재 진행중인 native win32 port 프로젝트도 이문제를 해결하지는 못할 것 같습니다.

이문제가 근본적으로 해결되려면, PostgreSQL의 커넥션 시나리오가 쓰레드 개념으로 가야지 풀릴 수 있을 것같네요.

 

아무튼 M$ 동네쪽에서의 해답은 asp, aspx 를 쓰든, jsp를 쓰든 웹서버단에서 커넥션풀을 가지고 있어야한다는 것이 저의 테스트의 잠정적 결론이었습니다.

 

이곳 게시판 뒤져보면, M$ 동네쪽에서 돌리는 PostgreSQL 이야기가 있는데, 그 글을 참조 하셔도 좋을 것같네요.

http://database.sarang.net/?criteria=pgsql&subcrit=qna&inc=read&aid=4946

김상기(ioseph)님이 2004-01-10 01:47에 작성한 댓글입니다.
이 댓글은 2004-01-10 01:50에 마지막으로 수정되었습니다.
[Top]
No.
제목
작성자
작성일
조회
5153postgresql 한글 지원에 관하여 [4]
김동훈
2004-01-12
2040
5152[질문] 나이 계산하는 pl-pg-sql 좀 갈켜주세요. [1]
PGsql조아
2004-01-12
1841
5150PostgreSQL Replicator for 7.3.4 and 7.4 released
이상호
2004-01-11
1332
5149postgresql 에 대한 간단한 궁금증. [3]
이창훈
2004-01-09
1970
5148그놈의 DB 베이스 파일시스템 ㅎㅎ [1]
신기배
2004-01-08
1674
5147책을 쓸려고 하는데.. [5]
이상호
2004-01-08
2847
5146윈도우에서 native 접속을 위해 libpq.dll을 컴파일 하려고 하는데... [2]
이민철
2004-01-07
2057
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.022초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다