우리는 벤치마크라는 말을 자주 듣고, 자주 사용합니다. 또한 데이터베이스과 관련이 없으신 분들도 IT 업종에 종사하신다면, 한번은 TPS 라는 단어를 들어 보셨을 것입니다. TPS는 Transaction Per Second의 약자로 초당 처리할 수 있는 트랜잭션의 수를 의미합니다. 더불어 TPC 벤치마크에 대해서도 들어보셨을 것입니다. (TPC-A, TPC-B, TPC-C, TPC-H, 등..)

인터넷에 Jim Gray의 Database Benchmark Handbook [1]이라는 자료가 있습니다. 책으로 된 자료도 있는데, 데이터베이스 벤치마크의 전반적인 흐름에 대해 이해할 수 있는 자료입니다.

오늘은 이 자료 및 다른 관련자료를 인용하여 DBMS 벤치마크에 대한 재밌는 이야기를 간단히 적고자 합니다.

이런 마크 많이 보셨죠?

자동차나 전자제품을 구입하면 에너지효율에 대한 등급이 적힌 스티커가 붙어있습니다. 이게 벤치마크의 대표적인 예입니다. 소비자가 제품을 직접 구매하지 않고도 제품의 특징을 알 수 있는 객관적인 수치를 제공하고자 하는 것입니다.

자, 이제 컴퓨터 시스템을 구입하시려고 합니다. 어떻게 결정하시나요? 아마도 벤치마크 결과를 참고하시겠지요? 벤치마크의 대해 Jim Gray는 [1]에서 다음과 같이 이야기 합니다.

각각의 벤치마크는 다음의 질문에 답하려 한다. “어떤 컴퓨터를 사야하는가?”. 그 답은 분명히 “원하는 작업을 수행하면서 비용이 최소인 시스템”일 것이다. 비용(cost-of-ownership)이란 프로젝트 리스크, 개발 비용, 운영 비용, 하드웨어 비용과 소프트웨어 비용을 포함한다. 프로젝트 리스크나 개발비용, 운영 비용 등은 측정하기 어렵다. 반면, 컴퓨터 성능은 측정하고 비교할 수 있다.

한번 이런 질문을 던져 보겠습니다. “벤치마크 결과를 어느 정도 신뢰하십니까?”

전문가들이 벤치마크 결과에 대해 흔히 말하는 재밌는 한마디는 소개하면 다음과 같습니다.

“업체가 발표한 벤치마크 결과는 그 제품의 성능이 절대로 그 결과는 넘지 않을 것을 보장한다.”

저는 이 이야기를 처음 들었을 때 한참을 웃었습니다. 참으로 예리한 표현입니다. ^^

다시 말해 벤치마크 결과를 비교용으로 활요하지 절대로 있는 그대로 믿지는 말라고도 이야기 합니다.

데이터베이스 성능이라는 것이 어떠한 데이터를 가지고, 어떠한 환경에서, 어떻게 측정했는지에 따라 천차만별입니다. 하드웨어, 운영체제, 네트워크등 많은 요인에 의해 달라질 수 있기 때문에 실제 환경에서 직접 돌려보기 전에는 성능을 미리 알기란 어려운게 사실입니다.

그렇다고 제품을 사기도 전에 실제 환경에서 운영해 보는 것은 쉽지 않습니다. 설령 DBMS 업체가 평가 버전을 제공한다고 하여도, DBMS의 선정은 응용 프로그램 개발과 완전히 독립적일 수 없기 때문입니다. 실제 환경에서 성능을 비교하기 위해서 응용 프로그램의 DBMS 의존적인 부분을 맞춰주어야 하는데, 이 자체가 추가의 개발 비용이지요.

이러한 비용까지 감수하며 제품을 선택할지는 고객의 몫인데, 가끔 업체가 이를 부담해야 해야하는 웃지 못한 일도 일어나는게 현실인 것 같습니다.

‘위스콘신 벤치마크’ 어디서 많이 들어보시지 않으셨나요? 1980년대 초 위스콘신의 David DeWitt교수가 고안한 벤치마크인데, 이 벤치마크가 소위 ‘벤치마크 전쟁’의 기폭제가 되었다고 합니다.

벤치마크에 전쟁이라 표현하는 이유는 다음과 같은 일이 일어났기 때문입니다. 벤치마크에서 진 업체는 실험이 잘 못 되었거나 벤치마크 자체가 의미가 없다고 주장했습니다. 또한 전문가를 동원하여 벤치마크에서 이기기 위해 다시 수행하고, 또 진 업체가 다시 하기를 반복하였습니다. 혹은 벤치마크를 이기기 위한 기능을 포함한 특별 버전을 이용하여 실험을 하고 이 기능이 다음 릴리즈에 포함될 것으로 약속하는 식으로도 진행되었습니다.

심지어 위스콘신 벤치마크가 발표된 이후에 오라클 CEO Larry Ellison이 벤치마크 결과에 매우 화가나서 위스콘신 대학의 학과장을 찾아가 David DeWitt 교수를 해고하도록 하려 했다는 일화가 있습니다. David DeWitt 교수의 2001년 인터뷰[2]에서 이 일을 이야기하며 다음과 같이 이야기 합니다.

DeWitt: “그는 테뉴어(교수의 정년보장)의 개념 – 내가 오라클에 대해 그다지 긍정적이지 않은 이야기를 했다고 해서 학과장이 날 해고하지 않는다는 것 – 을 이해하지 못하고 있었습니다.”
Interviewer: 교수들에게 테뉴어를 받기 전까지 벤치마크 작업을 하지 않을 것을 조언합니까?
DeWitt: (웃으며) 예, 확실히 그렇게 조언합니다.

이런 벤치마크 전쟁을 통해 벤치마크도 발전하고 DBMS도 발전했습니다. 결과적으로 1988년에 34개 소프트웨어 및 하드웨어 업체가 Transaction Processing Performance Council (TPC)을 공동으로 만들었고, 이후 여기서 만들어진 TPC-A, TPC-B 벤치마크(주1) 덕분에 벤치마크 전쟁이 급격이 감소했다고 합니다.

벤치마크가 신뢰할 만한 것이 되려면 어떻게 해야할까요?

일단 하나의 벤치마크로 DBMS를 평가할 수 없습니다. OLAP환경과 OLTP환경에서 필요로 하는 성능이 같을 수 없습니다. 따라서 특정한 도메인에 맞는 벤치마크를 개발하는 것이 더 합리적입니다.

Database Benchmark Handbook[1]에서 Jim Gray는 특정 도메인의 벤치마크가 아래의 4가지 기준을 만족해야 한다고 이야기합니다.

• 적절성(Relevant): 해당 도메인의 대표적인 연산을 수행하며 최대 성능과 성능 대비 가격을 측정해야 한다.
• 이식성(Portable): 서로 다른 시스템과 구조에 쉽게 벤치마크를 구현할 수 있어야 한다.
• 확장성(Scalable): 벤치마크가 작은 시스템에서 큰 시스템까지 적용할 수 있어야 한다. 이는 더 큰 시스템과 병렬 시스템에 확장할 수 있어야 한다.
• 단순함(Simple): 벤치마크는 이해할 수 있어야 한다. 그렇지 않으면 신빙성이 떨어질 것이다.

DBMS 혹은 다른 컴퓨터 시스템에서 많은 변수를 세밀하조 조절해가며 성능을 측정해보신 분은 성능이 얼마나 많은 변수로 인해 크게 달라질 수 있는지 아실 것 입니다. 따라서 벤치마크에 이러한 고려를 포함하고, 적절하면서도 이식성에 확장성도 있고, 단순하기까지한 벤치마크를 만드는 일이 얼마나 힘든일인지 상상하실 수 있을 것입니다. 그래서 인지 TPC-C 벤치마크의 스펙을 설명한 문서[4]가 130페이지에 달합니다.

저도 아직 이 문서를 완전히 읽어본 적이 없습니다. 아마 TPC-C 벤치마크의 요구사항을 만족하며 벤치마크를 구현하려면 이 내용을 제대로 파악하고 있어야 할 것 같네요. 직접 벤치마크를 개발하실 분이 아니고, 벤치마크가 어떤 테스트인지 대충 파악하고 싶으시다면 [5]을 읽어 보시길 추천합니다. 관심이 있으신 분은 TPC 홈페이지에서 다른 TPC 벤치마크에 대해서도 더 알아보실 수 있습니다.

참고로 Database Benchmark Handbook [1]를 보시면 TPC  이외에도 다른 벤치마크들이 소개되어 있으니 관심이 있으신 분은 참고하세요.

주석

(주1) 2009년 4월 현재, TPC를 참고하면, TPC-A, TPC-B를 비롯하여, TPC-D, TPC-R, TPC-W는 사용되지 않는다고 되어 있습니다. 현재 의미있는 TPC 벤치마크는 TPC-App, TPC-C, TPC-E, TPC-H이며, 각각에 대한 소개는 여기에서 확인하실 수 있습니다.

참고자료:

[1] Database Handbook:
http://research.microsoft.com/en-us/um/people/gray/benchmarkhandbook/toc.htm

[2] David DeWitt 2001년 인터뷰:
http://www.sigmod.org/interviews/mp3s/dewitt.mp3
http://www.sigmod.org/sigmod/record/issues/0206/dewitt-interview.pdf

[3] TPC-Benchmark 소개:
http://tpc.org/information/benchmarks.asp

[4] TPC-C 벤치마크 스펙:
http://tpc.org/tpcc/spec/tpcc_current.pdf

[5] TPC-C 벤치마크 개요:
http://tpc.org/information/sessions/sigmod/indexc.htm

덧붙이는 말: 필명을 flow에서 phlow로 바꾸었습니다.