The EDB Blog
December 20, 2010

Microsoft SQL Server와 pgsql-performance mailing list enquired as to the relative performance of PostgreSQL vs. SQL Server.  It's a reasonable question.  Switching databases can be a major project, and you certainly wouldn't want to do it and then find out at the end that you'd taken a huge performance hit and had to throw all your work away and switch back.  The good news is that this scenario is fairly unlikely.


최초 게시자는 초기 테스트에서 1000개 행으로 구성된 테이블을 만드는 데 Microsoft SQL Server로는 9.85초, PostgreSQL로는 0.65초가 걸린다는 사실을 발견했습니다.  그는 이어서 두 개 테이블스페이스를 결합하는 쿼리를 실행했으며 이 경우 Microsoft SQL Server로는 0.76초, PostgreSQL로는 7.5초가 걸렸습니다.  이 테스트에서는 어떤 결과를 추론할 수 있을까요?

아마 아무런 결과도 얻지 못할 것입니다. 이전 작업에서 본인은 34개 테이블스페이스를 결합한 PostgreSQL 쿼리를 프로덕션 단계에서 실행했으며 전반적인 경험으로는 PostgreSQL 쿼리 플래너가 매우 효과적이었습니다.  특정 테스트 사례에서 몇몇 다른 제품의 쿼리 플래너가 더 나은 해답을 도출할 수도 있겠지만 7.5초는 실제로 긴 시간입니다.  실제로 Microsoft SQL Server가 해당 쿼리를 실행하는 데 걸린 0.76초라는 시간은 단 1000개 행에 대한 결합 작업에는 매우 느린 속도입니다.  두 제품 모두가 더 좋은 성과를 제공할 수 있을 것으로 예상합니다.

Enterprise-ready Postgres tools for high availability, monitoring, and disaster recovery. Download Now.

다른 한편으로 PostgreSQL이 Microsoft SQL Server보다 10배 더 빠른 속도로 1000개 행을 테이블에 로드했다는 사실은 아무런 의미가 없을 수도 있습니다.  Microsoft SQL Server가 1000개 행의 데이터를 로드하는 데 10초가 걸린다는 것은 상상할 수도 없는 일입니다. Microsoft에 대한 개인적인 견해에 관계없이 Microsoft SQL Server의 성능이 그 정도로 나쁘다고 생각하기에는 Microsoft SQL Server를 사용하여 크고 복잡한 어플리케이션을 개발하는 사람들이 너무나 많습니다. 또한 PostgreSQL이 데이터를 로드하는 데 걸린 0.65초라는 시간은 그다지 매력적으로 보이지 않습니다. 이 측면에서도 더 나은 성능을 기대할 수 있습니다.

Just to be clear, I'm not denying that the poster accurately reported how long those tests took to run.  However, I don't believe that they represent the typical experience of users of either product.  Nor am I denying that there are real performance differences between PostgreSQL vs. SQL Server.  There certainly are.  But those differences are due to architecture, not inefficiency.  PostgreSQL has reached the point where it's worthwhile to think about optimizations that remove single machine instructions from inner loops, and that tells you that it's pretty well optimized.  I haven't seen the Microsoft SQL Server commit logs, but it wouldn't surprise me a bit to find that the situation there is similar.  I'm not sure what accounted for the observed differences in runtime on these tests, but it wasn't just that either product is "faster" than the other one.

여기서에서는 스레드에 대한 다음과 같은 몇 가지 다른 의견을 살펴볼 필요가 있는 것 같습니다.

- Kevin Grittner는 Windows Sybase에서 Linux PostgreSQL로 이동하면서 큰 성능 개선 효과를 경험했다고 언급했습니다. Microsoft SQL Server는 원래 Sybase를 기반으로 했습니다.

- Richard Broesma는 개인적으로 Microsoft SQL Server가 전반적으로 유사했지만 PostgreSQL에 (아직) 없는 병렬 쿼리 기능을 활용할 수 있는 경우 속도가 더 빨랐다는 의견을 말했습니다.

- Justin Pitts도 유사한 관찰 결과를 얻었지만 인덱스 전용 스캔이 부족하여 특정 워크로드에서 PostgreSQL의 성능이 낮을 수도 있다는 사실을 지적했습니다.

여기서 알아야 할 중요한 사실은 PostgreSQL과 Microsoft SQL Server 모두 다양한 기능과 함께 전반적으로 양호한 성능을 발휘하는 복잡하면서도 강력한 제품이라는 것입니다. 사용자는 두 제품을 사용하여 중요한 프로덕션 환경에서 많은 양의 데이터를 관리할 수 있으며 실제로 관리하고 있습니다.  더 빠른 시스템과 속도의 차이에 대한 단정적인 주장을 믿는 것은 중대한 실수일 수 있습니다. 두 시스템 모두 성능이 발휘되지 않는 경우가 있기 마련입니다. 특정 환경에서 심각한 문제를 일으켜 다른 제품을 사용해야 하는 경우가 있을 수 있습니다.

그러나 구성을 조정하거나 인덱스를 만들 수도 있고 문제 쿼리를 다시 작성하거나 문제 해결을 위한 다른 조치를 취할 확률이 더욱 높습니다. Steve Tibbett은 몇 년 전 이 문제를 SQL Server 측면에서 다룬 SQL Server이 느린 이유라는 블로그 게시물을 작성했습니다.  그는 Microsoft SQL Server 성능 개선을 위한 팁을 소개하지만, 요점은 낮은 성능의 원인을 데이터베이스에서 찾는 것은 옳지 않다는 것이었습니다. 데이터베이스가 느린 것은 아니지만 사용자 개입 없이 모든 쿼리를 완벽하게 처리할 수 있을 것이라 기대하기도 어렵습니다.  PostgreSQL의 경우도 마찬가지입니다.

 

robert.haas_enterprisedb.com's 사진

Robert is Chief Architect, Database Server, employed at EnterpriseDB as well as a PostgreSQL Committer. Robert is an expert in OLTP query tuning, schema design, triggers and stored procedures, and internals development, as well as an experienced UNIX/Linux system administrator. Additionally,...