독자적으로 진행했던 RDBMS 선택 과정 - 2. 벤치마킹과 나름의 분석.

벤치마킹을 진행했던 RDBMS는 MariaDB, PostgreSQL, Firebird, H2, MonetDB 였고, 설정에 손을 대진 않았던 것으로 기억한다.

각 데이터베이스를 설치했던 컴퓨터의 사양은 AMD Ryzen 7 1700 8코어 16쓰레드, 16G 메모리 였고, 운영체제는 Ubuntu 16.04 였다. 벤치마크를 위해 사용했던 프로그램은 JDBC(Java Database Connectivity) 이다.

시나리오는 1) 동시접속자가 많고, 모두 select 쿼리를 요청할 때.  2) 동시접속자가 많고, select 700명 + insert 300명 라는 두가지 시나리오로 진행했다. 시나리오에 필요한 데이터는 각 디비에 저장되어 있었다.

 

벤치마크 결과

시나리오 1. Select 100% - 3분동안 1000명의 사용자들이 영상 목록을 요청.

시나리오 2. Select 70%, Insert 30% - 3분동안 700명이 영상 목록을 요청, 300명이 게시물 작성.

 

결과의 특이점과 나름의 분석.

MariaDB

1. 시나리오1에서 MariaDB가 압도적으로 빨랐다.

->이유는 쿼리의 결과값을 메모리에 저장하는 쿼리 캐시라는 기능 때문이라고 생각한다.

 

2. 캐시 기능을 사용하는 MariaDB의 퍼포먼스가 시나리오 1에 비해 시나리오 2에서 나빠졌다

-> MariaDB는 쿼리 요청이 들어오면 쿼리캐시에 해당 값이 있는지부터 확인한다. 그런데 참조하는 테이블에 데이터 변화가 있으면 쿼리 캐시의 데이터가 삭제된다. 이때 쿼리 캐시 데이터를 삭제하기 위해 Global Lock이 사용되는데, 쿼리 캐시는 쓰레드의 동시 접근을 허용하지 않아서 다른 스레드들은 쿼리 캐시 삭제 작업이 완료될때까지 기다려야한다. 즉 insert 발생 시 다른 스레드들이 캐시 데이터 삭제 작업을 기다려야 하기 때문에 퍼포먼스에서 차이가 난 것이라고 판단했다.

 

3. 캐시를 사용하지 않을 때, 시나리오1에서 퍼포먼스가 저조했는데, 시나리오 2에서는 퍼포먼스가 좋았다. 

->ㅎㅎㅎ... 이건 정확한 근거를 찾지 못했다. 일단 시나리오 1에서 캐시를 사용하지 않으면 CPU 사용량이 100%가 나온다.  그리고 시나리오2에서 캐시를 사용하지 않을 때, 사용할 때보다 퍼포먼스가 더 좋았고 CPU, 메모리 사용량이 더 높았다. 

 

PostgreSQL

1. CPU 코어별 사용량이 균일했다.

2. CPU 사용량이 MariaDB보다 높았으나, 퍼포먼스는 오히려 떨어졌다.

 

MonetDB

1. Insert 시 에러율 95%

2. 두 시나리오에서 메모리 사용률 95%

-> MonetDB의 경우 Column-oriented Database 인데, 그 특징 때문인지 아니면 분석용 Database 라는 디자인 때문인지 insert 시 에러율이 높았다. Column-oriented vs Row-oriented Database는 추후에 다뤄보겠다.

 

Firebird, H2

MariaDB, PostgreSQL 보다 퍼포먼스가 현저히 낮았다. 그리고 오류율도 압도적으로 높았다. 이를 기반으로

1. 높은 부하를 견디는 디자인으로 설계되지 않았는가?

2. 적합한 설정을 해주어야 하는가?

정도의 생각이 들었다. '설정을 잘해주면 성능이 뛰어나다' 라는 내용을 본 것... 같다

 

공통적인 패턴 및 결론.

CPU, 메모리 사용량이 높을수록 퍼포먼스가 좋은 경향이 있다. 그리고 사용량이 높아도 오류가 많다면 요청의 대부분을 처리하지 못했다는 뜻이니 의미가 없다.

소프트웨어가 하드웨어를 어떻게 활용하느냐에 따라 그 결과가 달라질텐데, 내가 정한 시나리오 안에서 직접 테스트하면서 퍼포먼스의 차이를 확인할 수 있는 아주 좋은 기회였다.