아래 신기배님의 MySQL 과 PostgreSQL의 기본적인 select, insert 비교를 하면서, PostgreSQL 성능에 대한 한계(?)를 이야기 하셨는데,

그 글을 읽으면서 개인적으로 '저런 수치가 나올 수가 없을 터인데....' 하면서 읽었지요.

그래서, 이곳에서 구할 수 있는 데이터를 가지고, 개인 서버에서 테스트를 해 보았습니다.

대용량 데이터에 조작에 대해 관심 있으신 분들께서는 한번 즈음 읽어 보시는 것도 괜찮을 것같네요.

테스팅 환경

CPU: 팬티엄 II 350MHz 듀얼

메모리: 1GB

HDD: 일반 5400RPM IDE 드라이브

OS: Linux 2.4.18-6

PostgreSQL: 7.3.3

MySQL: 4.0.12

자료: 이곳 재고 데이터 200만건 (더 이상의 자료를 구하질 못해서 -.-)

작업이야기

이곳은(제가 일하는 곳) 사용자 측 RDBMS로 PostgreSQL놈을 쓰고, 내부적으로 Oracle를 씁니다. 판매 누적 데이터는 Oracle에서 관리하는지라, 일단 Oracle 데이터를 PostgreSQL copy로 넣기 위해서 tab 구문 문자로 덤프를 받고, 먼저 PostgreSQL 쪽으로 집어 넣었습니다.

이때, 날짜, 상점, 상품 이 세가지를 Primay Key로 하는지라, 그대로 지정한 상태에서 데이터를 집어넣었지요.

작업시간은 9분 40초

다음, MySQL 쪽으로 보내기 위해, pg_dump -d 로 자료를 받고 mysql 쪽에 넣었지요.

작업시간은 14분 20초

다음 select count(*) from t 의 모든 레코드 갯수 구하기

PostgreSQL : 15초

Mysql: 0.00초

(이놈은 PostgreSQL의 테이블 전체 레코드 갯수 구하는 알고리즘이 아직까지 시스템 카타로그를 사용하지 않기 때문에 어쩔 수 없는 문제입니다. 이것은 조만간에 바뀔 듯)

다음 Primary key 인덱스를 사용하는 실무에서 사용하는 쿼리

특정달(월단위) 특정상점의 특정 상품 재고 구하기.

PostgreSQL: 58ms

MySQL: 300ms

위의 똑같은 쿼리에 대한 인덱스 full search, (날짜에서 like 에서 %로 시작 - 이렇게 하면, 인덱스를 사용하기는 하는데, 특정상점, 특정 재고에 대한 모든 자료를 검색해서 필터링하지요, - mysql 놈은 약간 다르게 처리하더군요.)

PostgreSQL: 7.6초

MySQL: 8초

-------

이런식으로 실질적으로 업무에 사용되는 쿼리로 조회할 경우, 단순 테이블에서 의외로 제가 테스트한 환경에서는 PostgreSQL 놈이 더 빠르게 작동했습니다.

개인적으로 의외의 결과였지만, 어느 정도 예상했던 결과였습니다.

왜냐하면, DSN 검색 자료도 이미 수백만건이 넘어가고 있거든요. 그럼에도 불구하고, 사용자의 체감 속도에서 '느리다'는 느낌을 받지 않으니까요.