최고성능 DB 실체 밝힌다

eWEEK 랩·웹 사용자 테스트 병행 … 드라이버 튜닝 DB 설계가 성능의 핵심

벤치마크 결과를 드러내고 싶어하지 않는 데이터베이스 업체들에게는 미안한 일이지만 eWEEK 랩은 IBM DB2 7.2픽스팩 5, 마이크로소프트 SQL 서버 2000 엔터프라이즈 에디션 서비스 팩 2, MySQL 4.0.1 맥스, 오라클9i 엔터프라이즈 에디션 9.0.1.1.1, 사이베이스 ASE(Adaptive Server Enterprise) 12.5.0.1 등을 전격 테스트했다. 최고성능의 DB 왕좌를 두고 MySQL과 오라클9i가 접전을 벌였으나 간발의 차이로 오라클9i가 앞섰다. 그러나 오라클9i는 까다로운 메모리 튜닝의 문제점을 안고 있다.

이위크 한국판

2002/07/01

성능 데이터를 검토해 최고의 기술을 선택한다는 것은 데이터를 만들어내는 것만큼 어려운 일이다. 특히 데이터베이스 벤더들이 승인하지 않는 벤치마크 결과의 공개를 차단하기 위해 라이선스 계약에 벤치마크와 관련된 문구를 절대 삽입하지 않는 데이터베이스 분야에서는 더욱 그렇다.

그러나 고객들의 구매를 위해서는 정보가 필요하고 eWEEK 랩에서 이번에 다시 확인한 것과 같이 벤치마크 테스트는 프로젝트의 성패에 영향을 미칠 수 있는 예상하지 못한 기술적인 장점과 결점을 파악하는데 있어 필수불가결하다.

지난 1월부터 2월초까지 4주 동안 eWEEK/USA와 자매지인 PC매거진은 최근 발표된 5가지의 서버 데이터베이스 버전에 대한 종합적인 벤치마크를 실시했다. 이번 테스트 결과 자바 기반의 애플리케이션 서버와 함께 사용할 경우 최상의 성능을 보이는 데이터베이스를 알 수 있었다. 또, 제품 성능 개선을 위한 데이터베이스 서버 조정과 관련된 다양한 기법도 평가했다.

PC매거진에서 1993년 10월 이후 동일한 하드웨어에서 데이터베이스와 관련된 벤치마크 결과를 발표한 것은 컴퓨터 출판 업계에서 처음 있는 일이다.

이번에는 IBM의 DB2 7.2픽스팩 5, 마이크로소프트의 SQL 서버 2000 엔터프라이즈 에디션 서비스 팩 2, My SQL AB의 MySQL 4.0.1 맥스, 오라클의 오라클9i 엔터프라이즈 에디션 9.0.1.1.1, 사이베이스의 ASE(Adaptive Server Enterprise) 12.5.0.1 등을 테스트했다.

전반적으로 오라클9i와 MySQL이 뛰어난 성능과 확장성을 보였으며 이 중 오라클9i가 MySQL에 비해 다소 앞서는 것으로 밝혀졌다.

메모리 튜닝·DB 설계 집중 조명

ASE, DB2, 오라클9i, MySQL 등은 550여명의 웹 사용자를 대상으로 하는 테스트도 받았다. 여기서 ASE의 성능은 초 당 600페이지를 처리한 오라클9i와 MySQL보다 100페이지 정도 부족한 초 당 500페이지 수준이었다.

DB2의 성능은 부하가 높을 경우 초 당 200페이지 수준으로 상당히 낮았다. JDBC 드라이버의 심각한 문제로 인해 SQL 서버는 전체 테스트에서 초 당 200페이지의 처리 수준을 벗어나지 못했다.

드라이버, 메모리 튜닝, 데이터베이스 설계 문제 등이 이번 테스트에서 성능에 가장 큰 영향을 미친 세 가지 요인이었다. 수동 튜닝은 데이터베이스에 엄청난 차이를 일으켰으며 일반적으로 최종 측정된 처리량은 초기 설치 즉시 실시한 테스트에 비해 두 배나 빠른 성능을 보였다.

오라클과 MySQL 드라이버는 완전한 JDBC 기능과 안정성을 동시에 보여줬다(MySQL 관리자는 자체 JDBC 드라이버가 없어서 마크 매튜가 개발한 My SQL JDBC 드라이버를 사용했다).

각 데이터베이스에서 사용하는 다양한 시스템에 어느 정도의 메모리를 할당하는 것과 관련해 각 데이터베이스에 대한 최상의 성능을 제공하는 설정 환경을 찾는 것도 매우 어려웠으며 이 문제를 해결하기 위해 상당한 시간을 소요했다.

SQL 서버와 MySQL은 튜닝이 가장 쉬웠으며 오라클9i는 분리된 메모리 캐시를 갖고 있기 때문에 가장 어려웠다. 이 문제는 데이터베이스에 대한 동시 연결에서 많은 메모리(400KB의 RAM)를 요구하기 때문에 오라클9i에서 더욱 큰 문제가 됐다.

이에 비해 DB2는 커넥션당 177KB의 RAM을 요구했으며 SQL 서버, MySQL, ASE 등은 커넥션 당 50KB의 RAM을 요구했다.

웹페이지 처리량 낮은 DB2·ASE

결과적으로 오라클9i의 데이터와 질의 기획 캐시는 사용자 연결에서 사용되는 메모리 때문에 다른 데이터베이스의 캐시보다 작아야 한다.

MySQL의 탁월한 성능은 MySQL 4.0.1에서 새롭게 지원되는 내장 메모리 질의 결과 캐시 덕분이다. 캐시 없이 테스트한 경우 MySQL의 성능은 3분의 2 수준으로 떨어졌다. MySQL 관리자는 테이블 기반의 다양한 데이터베이스 엔진을 사용할 수 있는 독특한 기능을 활용할 수 있다.

요구 사양에 따라 트랜잭션을 지원해야 하는 북스토어(bookstore) 주문 테이블의 구성은 오라클9i에서도 사용되는 트랜잭션, 로우레벨 잠금, 멀티버저닝 동시 설계 등을 지원하는 MySQL의 이노 DB 데이터베이스 엔진을 사용했다.

카탈로그와 사용자 테이블에서는 트랜잭션 지원이 필요하지 않기 때문에 MySQL 관리자는 이 테이블을 구성해 MySQL의 간편한 논(non)트랜잭션형 MyISAM 엔진을 사용했다.

MySQL 4.0.1의 새롭고 빠른 질의 캐시도 주목할 만하다. 이 기능은 이번 테스트에 참여한 어떤 제품에서도 지원하지 않는다.

수신되는 질의의 텍스트에 캐시된 질의와 바이트 단위로 일치되는 것이 있는 경우 MySQL은 질의를 컴파일하지 않고 캐시에서 직접 결과를 검색할 수 있으며 잠금이나 색인 접속을 수행할 수 있다.

이와 같은 질의 캐시는 캐시를 정리해 정확한 결과를 보장하는 테이블이 생성되기 때문에 업데이트가 자주 이뤄지지 않는 테이블에 효율적이다.

마지막으로 색인을 추가하고 질의 세트를 위해 물리적 순서에 따라 테이블을 정렬해 데이터베이스 설계 자체를 조절하면 드라이버나 데이터베이스 메모리 조절에 비해서는 미약하지만 성능 향상에 도움을 줄 수 있다.

벤치마크의 주된 목표는 직접적인 기능 비교다. 모든 데이터베이스는 동일한 하드웨어 플랫폼(4개의 700MHz 제온 CPU, 2GB RAM, 1만rpm의 9.1GB 울트라3 SCSI 하드드라이브 24개가 장착된 HP 넷서버 LT 6000r 서버)과 동일한 운영체제(윈도우 2000 어드밴스드 서버 서비스 팩 2)에서 테스트했다.

웹 기반의 북스토어 애플리케이션인 나일(Nile)을 사용해 데이터베이스 로드를 생성하고 엠피릭스(Empirix)의 e테스트 스위트(e-Test Suite) 6.0 로드 테스트 툴을 사용해 50~1000명의 웹 동시 사용자 로드를 생성했다.

데이터베이스 성능을 위한 튜닝 전략

테이블이 너무 작거나 업데이트 레벨이 너무 높지만 않다면 서치나 소트시 발생하는 모든 칼럼이 색인에 올라와 있는지 체크할 것.

인덱스와 테이블 데이터 모두를 샅샅이 찾을 필요는 없지만 인덱스에 추가되는 모든 컬럼이 쿼리들을 자주 필요로 하는지 고려해라.

디스크에서 테이블의 물리적 순위는 그 순위가 해당 열 중 가장 큰 수를 검색한 쿼리를 필요로 하는지 반영해야 한다. 이는 프라이머리 키의 순위가 아닌 테이블 내에서의 결과일 수 있다.

칼럼의 순위는 인덱스를 만들 때 문제가 된다. 최종 결과의 사이즈를 요약하기 위한 대부분의 칼럼은 인덱스 내에서 첫 번째 존재가 돼야 한다.

테이블 데이터 배치 전략이 최신의 데이터를 유지하고 산정하고 있는지를 명확해 해라. 놓치거나 잘못된 전략은 낮은 쿼리를 생산하게 된다.

데이터의 최종 형태는 단 하나다. 중대한 문제가 발생하지 않도록 하기 위해서는 쿼리 실행 계획을 살피고 제공된 쿼리와 인덱스 분석 툴을 사용해라.

더 좋은 성능을 위해서는 서브셀렉트를 제거하는 SQL 쿼리를 재작성해라.

현재의 사용량을 지원하고 변화에 대한 튜닝 방법과 같은 성능 이슈들을(최상의 리소스 집약적인 쿼리를 트래킹하기 위해) 모니터링하는 것을 지속해라.

튜닝 어려운 오라클9i

BEA시스템즈의 웹로직 6.1 서비스팩 1을 애플리케이션 서버 플랫폼으로 선택, JSP(Java Server Pages)에서 나일 애플리케이션을 개발했다.

각 테스트는 한 시간 동안 진행됐고 5만건의 주문과 15만~20만 건에 달하는 관련 항목이 생성됐다. 4GB의 RAM과 기가비트 이더넷 네트워크 카드가 장착된 두 대의 6웨이 HP 넷서버 LT 6000r 서버에서 6개의 웹로직을 실행해 최상의 애플리케이션 서버 확장성을 얻었다. HTTP 트래픽은 6개의 웹로직 인스턴스에서 균등하게 로드가 조정됐다.

ASP .Net에서의 벤치마크도 이뤄졌는데 시간상 제약으로 인해 이 플랫폼에서는 SQL 서버만 테스트했다.

이 테스트의 결과는 ASP .Net 테스트가 다른 웹서버(IIS 5.0), 다른 애플리케이션 엔진(ASP .Net), 다른 데이터베이스 드라이버(OLE DB) 등을 사용했기 때문에 자바 벤치마크 결과와 비교할 수 없다는 사실에 유의해야 한다.

그러나 이 테스트에서는 마이크로소프트의 소프트웨어가 초 당 870 페이지를 넘는 탁월한 성능을 보였다는 사실이 밝혀졌다.

이번 벤치마크는 PC매거진의 뉴욕 랩에서 테스트를 실시하면서 각 데이터베이스 벤더의 담당 직원을 초대했다. MySQL과 사이베이스는 이를 받아들여 직원들이 직접 데이터베이스를 조정하도록 했다.

IBM은 직원을 보내지 않았지만 IBM의 엔지니어들과 조정 작업에 대한 전자우편을 여러 차례 주고받았다. 마이크로소프트와 오라클은 이번 테스트에 관련되는 것 자체를 거부했으며 이로 인해 이들의 도움 없이 직접 데이터베이스를 튜닝했다.

벤치마크 결과 데이터베이스 커넥티비티 드라이버가 문제의 핵심임이 입증됐다.

테스트를 거친 5개의 데이터베이스 중에서 오라클9i와 MySQL만이 나일 애플리케이션을 초기에 개발된 형태 그대로 8시간 동안 아무 문제없이 실행할 수 있었다.

DB2의 JDBC 드라이버는 업데이트 가능한 결과 세트(JDBC 2.0 기능)를 지원하지 않기 때문에 CONCUR_ READ_ONLY 속성을 사용해 결과를 도출해냈고 SQL 업데이트 명령을 사용해 업데이트를 수행했다. 이와 같은 변경을 통해 애플리케이션을 실행할 수 있었다. IBM의 드라이버는 8시간에 걸친 안정성 테스트를 통과했다.

사이베이스의 J커넥트 5.5 드라이버의 경우 애플리케이션에서 양방향 커서가 있는 결과를 요청할 경우 J커넥트는 전체 결과 세트를 클라이언트 메모리에 저장해 커서 위치 지정 명령을 신속하게 수행한다는 사실을 알게 됐다(양방향 커서를 사용해 사용자는 검색 기준에 맞는 책의 목록을 통해 페이지를 검색할 수 있다).

자바 성능 튜닝의 핵심 ‘자바 VM’

자바 애플리케이션 서버의 성능 튜닝에서 가장 중요한 부분은 애플리케이션 서버가 실행되는 자바 VM(Virtual Machine)의 조정이다.

일부 플랫폼의 경우 자바 VM을 선택할 수 있다. 썬, IBM은 여러 운영체제를 위해 자체적으로 VM을 개발하고 있으며 다른 플랫폼 벤더들도 자사의 플랫폼에 맞게 자바 VM을 조정하고 있다. 이 경우 기업들은 작업 부하를 효율적으로 처리하는 VM을 선택할 수 있다.

BEA시스템즈의 웹로직 6.1을 윈도우 2000 어드밴스드 서버에서 실행하도록 한 설정에서 썬과 IBM의 자바 1.3 VM을 사용해 테스트했다.

IBM 자바 VM이 더 안정적이었다. 3주의 테스트 기간 동안 썬 VM은 3회 다운됐지만 IBM VM은 다운되지 않았다. 그러나 IBM VM은 썬 VM과 동일한 작업 부하일 경우에도 CPU 점유율이 20% 더 높았다.

데이터베이스 CPU 처리량보다 애플리케이션 서버 CPU 처리량이 부족했기 때문에 썬 VM을 사용했다. 썬 VM의 설정을 여러 가지로 바꾸면서 최소 용량과 최대 용량을 512MB의 RAM으로 설정하고 핫스팟(HotSpot) 저스트 인 타임 컴파일러를 사용 가능하도록 설정하는 것이 최상의 성능을 보장하는 것임을 알게 됐다.

또 썬 VM을 통해 성능에 중대한 변화를 줄 설정 변화를 수행해 썬 VM이 최대 두 대의 CPU에서 사용되도록 제한했다.

이론적으로 썬 VM은 애플리케이션 서버로 사용했던 6개의 CPU가 장착된 시스템에서도 활용할 수 있지만 실제 상황은 다소 달랐다. 작업 관리자의 프로세스 탭에서 프로세스 이름을 오른쪽 마우스 버튼으로 클릭해 VM을 각기 다른 두 대의 CPU 세트에 결합, 전체 CPU 사용량의 30% 절감 효과를 얻었다.

이와 같은 작업은 로드가 적을 경우에는 문제가 없지만 사용자가 수백명에 달할 경우 애플리케이션 서버에서는 분 당 수백MB의 메모리를 소모한다는 사실을 알게 됐다.

결과적으로 6대의 애플리케이션 서버가 메모리 할당과 확보에 많은 시간을 소비했기 때문에 초 당 200페이지 이하의 처리 성능을 보였다. 또 이와 같은 메모리 처리 구성은 안정적이지 못하고 8시간 동안 진행되지 못해 모든 애플리케이션 서버의 작동이 중지됐다.

이 문제를 해결하기 위해 애플리케이션의 검색 로직을 새로 작성해 전면 스크롤 커서만 사용하도록 했다. 이 경우 J커텍트에서는 클라이언트 메모리에서 캐시하지 않는다.

오라클9i와 MySQL 전부문 우수

이 애플리케이션은 검색된 책을 제목 앞에 표시하도록 하기 때문에 동일한 질의를 두 번이나 실행해야 했다.

먼저 책의 수를 파악하고 책에 관련된 정보를 검색하는 것이다. 이는 자주 호출되는 페이지에는 비효율적인 설계 방식이며 ASE 성능을 저하시킬 수도 있다.

그래도 이를 통해 ASE의 성능이 두 배 정도 향상될 수 있다. 전면 스크롤 커서만 사용해 벤치마크를 성공적으로 실행했다. ASE의 클라이언트 사이드 기록 캐싱은 클라이언트/서버 애플리케이션에 유용하지만 애플리케이션 서버에서 사용하기에는 적절하지 못하다.

전면 스크롤 커서 변경을 제외하고 애플리케이션 코드를 변경할 때마다 모든 데이터베이스를 다시 테스트했다.

이번에 사용된 모든 드라이버 중에서 마이크로소프트의 새로운 JDBC 드라이버가 가장 문제가 많았다.

베타 드라이버로 마이크로소프트의 웹사이트에서 배포되고 있지만 지금까지 수 년 동안 서드파티 SQL 서버 JDBC 드라이버로 수위를 차지해 온 데이터디렉트 테크놀로지스에서 라이선스한 코드를 기반으로 하고 있기 때문에 신제품은 아니다.

자체적으로 JDBC 드라이버를 제공하고 지원하는 것은 매우 고무적이며 마이크로소프트 관계자들은 지난달 이 드라이버가 7만 회의 다운로드 횟수를 기록해 고객들의 관심을 끌고 있다고 전했다. 그러나 베타 1과 베타 2 단계인 이 드라이버는 성능과 안정성에서 상당한 문제가 있다.

이 드라이버를 사용해 초 당 200페이지 이상의 처리량은 달성할 수 없었고 이는 명백히 드라이버의 문제이며 데이터베이스는 이 경우 CPU 활용 비율이 15~20% 수준밖에 되지 못했다.

또 이 드라이버는 메모리 누수 현상이 있다. 웹로직의 관리 콘솔에서는 자바 가상 머신이 가비지 콜렉션(garbage collection)을 수행할 경우 여유 메모리 확보가 용이하지 못했다. 이와 같은 문제 때문에 마이크로소프트 JDBC 드라이버는 8시간 연속 실행이 불가능했다. @