Database Benchmarking과 HammerDB를 사용할 때의 기준

문제의 시작

Database benchmark는 숫자만 비교하면 쉽게 잘못 읽힌다. TPS가 높다는 사실보다 중요한 것은 어떤 schema와 어떤 workload에서 나온 숫자인지다. 이 글은 HammerDB를 사용하며 benchmark 조건을 어떻게 잡아야 결과가 의미를 갖는지 정리한 기록이다.

데이터베이스 시스템 선택은 장기적인 결과를 초래한다.

선택 이후 운영 과정에서 데이터베이스를 교체할 경우 마이그레이션이 쉽지 않기에 개발 초기에 문제를 예상하고 감지할 수 있어야 한다.

선택 과정에서 생각해야 하는 것들에는 다음이 있다.

스키마와 레코드 크기
클라이언트 수
쿼리 형식과 접근 패턴
읽기와 쓰기 쿼리 비율
위 변수들의 변동폭

이후 테스트 클러스터를 구성하고 워크로드를 시뮬레이팅 하는 과정이 있는데, 이는 YCSB(서빙 벤치마크), hammerDB 등의 툴로 가능하다.

다음은 hammerDB configuration이다.

원하는 directory에 hammerDB Dockerfile을 생성한다.

구현하면서 확인한 흐름

cd <directory>
touch Dockerfile
vi Dockerfile

FROM  docker.io/tpcorg/hammerdb:oracle as oracle

FROM  docker.io/tpcorg/hammerdb:mssqls

# Install and configure IBM Db2 client libraries,
# You will need to pre-download IDB Db2 client libraries and place in the local folder
# RUN mkdir -p db2_cli_odbc_driver/odbc_cli
# ADD odbc_cli db2_cli_odbc_driver/odbc_cli/
# RUN apt update && \
#    echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections && \
#    apt -y install libxml2 && \
#    echo 'export DB2_CLI_DRIVER_INSTALL_PATH="/home/db2_cli_odbc_driver/odbc_cli/clidriver"' >> ~/.bashrc && \
#    echo 'export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/home/db2_cli_odbc_driver/odbc_cli/clidriver/lib"' >> ~/.bashrc && \
#    echo 'export LIBPATH="/home/db2_cli_odbc_driver/odbc_cli/clidriver/lib"' >> ~/.bashrc && \
#    echo 'export PATH="$PATH:/home/db2_cli_odbc_driver/odbc_cli/clidriver/bin"' >> ~/.bashrc && \
#    echo 'export PATH="$PATH:/home/db2_cli_odbc_driver/odbc_cli/clidriver/adm"' >>  ~/.bashrc

COPY --from=oracle /home/instantclient_21_5 /home/instantclient_21_5
ENV ORACLE_LIBRARY=/home/instantclient_21_5/libclntsh.so
RUN echo 'export LD_LIBRARY_PATH=/home/instantclient_21_5/:$LD_LIBRARY_PATH'  >> ~/.bashrc

RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -y libmariadb3 libpq-dev libmysqlclient21 && \
    rm -rf /var/lib/apt/lists/*

image를 build 한다.

docker build -t hammerdb .

container를 만들고 싶다면,

docker run -it --name <container name> hammerdb bash

이제 데이터베이스 테스트를 하는데, hammerDB cli 로 들어간다. 먼저 hammerDB CLI path를 찾아야 하는데,

docker exec -it hammerdb /bin/bash

들어가서 path를 찾고,

docker exec -it <container name> <path name>

하면 cli로 들어가진다.

이제 데이터베이스 종류를 선택하는데,

ora mssqls db2 mysql pg maria

oracle, MsSQL, IBM Db2, MySQL, PostgreSQL, MariaDB가 있다.

mysql 을 해보자.

이제 performance test 의 benchmark type을 골라야 하는데, Use-Case에 따라 다르다. https://www.hammerdb.com/benchmarks.html 참고

일단 TCP-C 타입으로 테스트해본다.

hammerdb> dbset bm TPC-C

dict(dictionary)를 확인해야 한다. HammerDB version, database type, benchmark type에 따라 설정 방식이 달라질 수 있다. 예를 들어 set keyword로 host 등을 설정할 수 있는 경우도 있고, diset으로 dictionary 자체를 수정해야 하는 경우도 있다.

hammerdb>print dict
Dictionary Settings for MySQL
connection {
 mysql_host               = 127.0.0.1
 mysql_port               = 3306
 mysql_socket             = /tmp/mysql.sock
 mysql_ssl                = false
 mysql_ssl_two_way        = false
 mysql_ssl_linux_capath   = /etc/mysql/certs
 mysql_ssl_windows_capath = C:\mysql\certs
 mysql_ssl_ca             = ca-cert.pem
 mysql_ssl_cert           = client-cert.pem
 mysql_ssl_key            = client-key.pem
 mysql_ssl_cipher         = server
}
tpcc       {
 mysql_count_ware       = 1
 mysql_num_vu           = 1
 mysql_user             = root
 mysql_pass             = mysql
 mysql_dbase            = tpcc
 mysql_storage_engine   = innodb
 mysql_partition        = false
 mysql_prepared         = false
 mysql_total_iterations = 10000000
 mysql_raiseerror       = false
 mysql_keyandthink      = false
 mysql_driver           = timed
 mysql_rampup           = 2
 mysql_duration         = 5
 mysql_allwarehouse     = false
 mysql_timeprofile      = false
 mysql_async_scale      = false
 mysql_async_client     = 10
 mysql_async_verbose    = false
 mysql_async_delay      = 1000
 mysql_connect_pool     = false
}

현재 dict 구조인데, 여기에서 host, port, user, pass 등을 변경하고 싶으면

diset connection mysql_port <your port>
diset connection mysql_host <your host>
diset tpcc mysql_user <your user>
diset tpcc mysql_pass <your pass>

를 하면 된다.

만약 AWS RDS 의 데이터베이스를 로딩하려 한다면, Security Group에서 ip 를 열여줘야한다.

이제 스키마를 로딩할 차례인데,

vudestroy

기존 VU 상태를 정리하는 단계로 이해하면 된다.

buildschema

스키마를 로딩하는 명령어인데, 설정을 잘 완료했다면 호스트와 포트 등이 뜨면서 대기시간이 좀 있다.

Vuser 1 created - WAIT IDLE
Vuser 1:RUNNING
Vuser 1:CREATING TPCC SCHEMA
Vuser 1:Ssl_cipher
Vuser 1:CREATING DATABASE tpcc
Vuser 1:CREATING TPCC TABLES
Vuser 1:Loading Item

https://stackoverflow.com/questions/73624954/how-long-it-takes-to-build-schema-or-my-hammerdb-not-working 참고

Vuser 1:Orders Done
Vuser 1:End:Tue Oct 24 17:43:06 UTC 2023
Vuser 1:CREATING TPCC STORED PROCEDURES
Vuser 1:GATHERING SCHEMA STATISTICS
Vuser 1:TPCC SCHEMA COMPLETE
Vuser 1:FINISHED SUCCESS
ALL VIRTUAL USERS COMPLETE
Schema Build jobid=6537FC1D608703E253535343

다 끝났으면 이런식으로 뜬다.

이제 run을 돌려서 performance metrics를 확인할 수 있는데, RDS를 사용중이라면 CloudWatch에서 추가 모니터링을 할 수 있다. 그 전 virtual user 수도 설정 가능하다.

vurun

벤치마크 기준

Benchmark는 제품 환경을 완전히 재현하지 못한다. 그래도 schema, client 수, query mix, read/write 비율을 명확히 두면 최소한 비교 가능한 실험이 된다. 숫자를 얻는 것보다 중요한 것은 그 숫자가 어떤 조건에서 나온 것인지 끝까지 설명할 수 있는 상태다.