리눅스 + CUBRID vs 리눅스 + MySQL
성능 비교 자료입니다
참고하세요....
===== 내용중 일부 =================================
인터넷 쇼핑몰에서의 DBMS 벤치마크 테스트
- 리눅스 기반의 CUBRID, 대표 상용 DB, MySQL 성능 비교
요약
본 문서는 연세대학교 산학협력단 박상현 교수팀이 수행한 “LINUX 상에서 운영되는 관계형 DBMS 성능 분석 소프트웨어 개발” 과제의 산출물인 “DBBench” 프로그램을 이용하여 작성되었으며, BMT 결과인 “공개 S/W 산학 협력 프로젝트 벤치마크 결과 보고서”를 정리한 것이다.
DBBench는 TPC-W 기반의 데이터베이스 트랜잭션 테스트만을 수행하는 도구로서 인터넷 쇼핑을 모델링 하였으며, TPC-W 테스트의 데이터베이스 스키마와 질의 목록을 이용하고 있다. 아울러, TPC-W의 모든 질의는 미리 저장된 저장 프로시저(stored procedure)를 사용하여 질의 내부에서 복잡한 처리를 하는데 비해, DBBench는 저장 프로시저를 지원하지 않는다. 따라서, TPC-W의 질의를 단순화하여 벤치마크 예제를 작성하였다.
연세대에서 수행한 이번 벤치마크 테스트는 CUBRID, 최상으로 알려진 대표 상용 DB, MySQL을 대상으로 하였으며, A~F까지의 6개 테스트 셋으로 되어 있다. A~C set은 10 user로 사용자를 고정하고, A set는 1,000 item, B set는 10,000 item, C set는 100,000 item을 대상으로 테스트를 진행하였으며, D~F set는 item을 10,000으로 고정하고 D set는 1 user, E set는 10 user, F set는 100 user을 대상으로 테스트가 수행되었다.
A~C set에 대한 테스트는 10 User를 대상으로 DB 사이즈별 DBMS 처리속도를 나타내고 있으며, 아래의 그림에서와 같이 CUBRID와 대표 상용 DB는 DB 사이즈의 증가에 크게 영향을 받지 않지만, MySQL은 DB 사이즈가 증가하면서 처리속도가 급격하게 감소하는 것을 볼 수 있다. 특히, 10,000 item을 대상으로 하는 middle DB 사이즈(B set) 에 대한 테스트의 경우에는 CUBRID가 초당 51.87개의 트랜잭션을 처리해, 대표 상용 DB의 50.22개를 근소하게 앞서고 있다.
D~F set에 대한 테스트는 DB 사이즈를 10,000 item으로 고정하고 동시 사용자 수를 증가시킬 때의 DBMS 성능을 측정하였다. 아래의 그림에서와 같이 CUBRID와 대표 상용 DB는 동시 사용자 수의 증가에 크게 영향을 받지 않지만, MySQL은 동시 사용자 수가 증가하면서 DBMS의 성능이 급격히 감소하는 것을 볼 수 있다. 특히, 100 user의 경우에는 CUBRID가 user별 초(Sec)당 처리 트랜잭션 수가 4.09개로 대표 상용 DB의 3.42개 보다 성능이 우수함을 알 수 있다.
DBBench를 이용한 DBMS의 벤치마크 테스트를 통해 CUBRID와 대표 상용 DB는 DB 크기의 증가와 동시 사용자 수의 증가에 크게 영향을 받지 않지만, MySQL은 DB 크기의 증가와 동시 사용자 수의 증가가 성능에 많은 영향을 주고 있음을 확인할 수 있다.<div class='small'>[이 게시물은 관리자님에 의해 2011-10-31 17:27:00 MySQL에서 이동 됨]</div>
성능 비교 자료입니다
참고하세요....
===== 내용중 일부 =================================
인터넷 쇼핑몰에서의 DBMS 벤치마크 테스트
- 리눅스 기반의 CUBRID, 대표 상용 DB, MySQL 성능 비교
요약
본 문서는 연세대학교 산학협력단 박상현 교수팀이 수행한 “LINUX 상에서 운영되는 관계형 DBMS 성능 분석 소프트웨어 개발” 과제의 산출물인 “DBBench” 프로그램을 이용하여 작성되었으며, BMT 결과인 “공개 S/W 산학 협력 프로젝트 벤치마크 결과 보고서”를 정리한 것이다.
DBBench는 TPC-W 기반의 데이터베이스 트랜잭션 테스트만을 수행하는 도구로서 인터넷 쇼핑을 모델링 하였으며, TPC-W 테스트의 데이터베이스 스키마와 질의 목록을 이용하고 있다. 아울러, TPC-W의 모든 질의는 미리 저장된 저장 프로시저(stored procedure)를 사용하여 질의 내부에서 복잡한 처리를 하는데 비해, DBBench는 저장 프로시저를 지원하지 않는다. 따라서, TPC-W의 질의를 단순화하여 벤치마크 예제를 작성하였다.
연세대에서 수행한 이번 벤치마크 테스트는 CUBRID, 최상으로 알려진 대표 상용 DB, MySQL을 대상으로 하였으며, A~F까지의 6개 테스트 셋으로 되어 있다. A~C set은 10 user로 사용자를 고정하고, A set는 1,000 item, B set는 10,000 item, C set는 100,000 item을 대상으로 테스트를 진행하였으며, D~F set는 item을 10,000으로 고정하고 D set는 1 user, E set는 10 user, F set는 100 user을 대상으로 테스트가 수행되었다.
A~C set에 대한 테스트는 10 User를 대상으로 DB 사이즈별 DBMS 처리속도를 나타내고 있으며, 아래의 그림에서와 같이 CUBRID와 대표 상용 DB는 DB 사이즈의 증가에 크게 영향을 받지 않지만, MySQL은 DB 사이즈가 증가하면서 처리속도가 급격하게 감소하는 것을 볼 수 있다. 특히, 10,000 item을 대상으로 하는 middle DB 사이즈(B set) 에 대한 테스트의 경우에는 CUBRID가 초당 51.87개의 트랜잭션을 처리해, 대표 상용 DB의 50.22개를 근소하게 앞서고 있다.
D~F set에 대한 테스트는 DB 사이즈를 10,000 item으로 고정하고 동시 사용자 수를 증가시킬 때의 DBMS 성능을 측정하였다. 아래의 그림에서와 같이 CUBRID와 대표 상용 DB는 동시 사용자 수의 증가에 크게 영향을 받지 않지만, MySQL은 동시 사용자 수가 증가하면서 DBMS의 성능이 급격히 감소하는 것을 볼 수 있다. 특히, 100 user의 경우에는 CUBRID가 user별 초(Sec)당 처리 트랜잭션 수가 4.09개로 대표 상용 DB의 3.42개 보다 성능이 우수함을 알 수 있다.
DBBench를 이용한 DBMS의 벤치마크 테스트를 통해 CUBRID와 대표 상용 DB는 DB 크기의 증가와 동시 사용자 수의 증가에 크게 영향을 받지 않지만, MySQL은 DB 크기의 증가와 동시 사용자 수의 증가가 성능에 많은 영향을 주고 있음을 확인할 수 있다.<div class='small'>[이 게시물은 관리자님에 의해 2011-10-31 17:27:00 MySQL에서 이동 됨]</div>
첨부파일
|
댓글을 작성하시려면 로그인이 필요합니다.
댓글 3개
왜 mysql에서만 그 느린 LIKE를 많이 썼을까요?
트랜잭션을 지원하지 않는다면 그에 맞게 성능을 비교해야 할 텐데 아쉽군요.
항목이 가로축과 세로축이 같은 항목으로 비교된것이고
님께서 말한 비율을 그렇게 해서 결과로 나온 수행시간비율인
더걸린 셈이네요. 즉, mysql이 like에서 시간이 더 걸리는 거네요
그에 맞게 성능비교가 제대로 되었던 것 같네요.
결과자료를 다시 확인해 보시져