2.1 오픈소스 소프트웨어와 품질

오픈소스 소프트웨어(Open Source Software)는 소스코드에 대한 접근, 자유로운 재배포, 파생 저작물의 작성, 제한 없는 사용 등을 허용하는 라이선스와 함께 배포되는 소프트웨어이다(Androutsellis-Theotokis et al. 2011). 우리나라 공개 소프트웨어 포탈에서는 널리 사용되는 오픈소스 소프트웨어(OSS)를 OS, DBMS, WEB, WAS와 같은 서버용 OSS, 데스크탑 용 OSS, 비즈니스 용 OSS, 임베디드 OSS, 클라우드 OSS 등으로 분류하고 있다. 오픈소스 애플리케이션들은 운영체제와 데이터베이스 같은 시스템 인프라, 소프트웨어 개발 도구, 교육, 과학, 엔지니어링 등 개인용 소프트웨어에서 기업용 소프트웨어까지 거의 모든 분야에서 그 활용도가 높아지고 있다.

소프트웨어 품질 평가를 위한 국제표준인 ISO/IEC 9126, ISO/IEC 25010 에서는 소프트웨어 품질특성 및 메트릭을 정의하고 있다. 이 품질 모델은 소프트웨어 품질을 측정, 평가하기 위해 소프트웨어의 품질을 이루는 품질 특성을 정의하고 이 품질 특성을 다시 부특성들로 세분한다. 또한 소프트웨어 제품의 품질을 측정하거나 평가하는데 필요한 방법과 절차를 여섯 개 부분으로 나누어 정의하여 표준으로 제시하고 있다(ISO/IEC 2001, 2003, 2011). 국내에서는 NIPA와 TTA에서 표준 지침을 제공하고 있다(Lim et al. 2012).

ISO/IEC 9126의 품질 특성과 부특성은 다음과 같다.

이러한 국내외 표준을 바탕으로 다양한 응용분야의 소프트웨어에 대한 품질 평가 모델 연구가 이루어져 왔다. 빅데이터 분산처리시스템의 품질평가 모델(Choi et al. 2014), IoT 소프트웨어의 품질평가모델(Chung et al. 2016), 모바일 클라우드 소프트웨어의 품질평가모델(Lee et al. 2015) 등의 연구가 있다.

소프트웨어 제품 자체의 품질만이 고려되는 일반 소프트웨어와 다르게 오픈소스 소프트웨어는 제작, 배포과정과 커뮤니티, 라이선스 등이 중요한 요소로 작용한다. 따라서 별도의 품질 평가 방법이 필요하며, 오픈소스 소프트웨어의 품질평가에 관한 연구가 진행되어 왔다(Spinellis 2006, Spinellis et al. 2009, Samoladas et al. 2008). 이 중 Samoladas et al.(2008)에서는 소스코드가 개방되어 있는 오픈소스 소프트웨어들의 사례를 코드 수준에서 분석하였는데, 품질평가 특성 중에서는 오픈소스 소프트웨어에 적합한 신뢰성, 보안성, 효율성, 이식성, 유지보수성 특성을 선택하여 분석하였다. Spinellis(2006)과 Spinellis et al.(2009)에서는 ISO/IEC 9126 품질 모델을 오픈소스 소프트웨어에 맞게 변형한 모델을 제시하였으며, 이 모델을 기반으로 품질 평가를 자동화하는 프로그램을 개발하였다.

2.2 오픈소스 DBMS

DBMS(Database Management System)란 데이터베이스에 대한 모든 접근을 관리하는 소프트웨어이다. DBMS 가 필수적으로 갖추어야 할 기능에는 데이터 정의기능, 데이터 조작기능, 최적화, 데이터 보안 및 무결성 유지기능, 데이터 회복 및 동시성 제어 기능, 데이터 사전 유지 기능이 있다(Date 2004). DBMS의 주요 역할은 데이터베이스의 데이터에 대한 검색, 삽입, 삭제, 갱신의 연산이다. 이 중 가장 많이 사용되는 것은 검색 연산으로, DBMS의 가장 중요한 선택 기준은 데이터베이스에 대한 빠른 검색이다. 이에 관한 연구는 데이터베이스가 등장한 이래로 수십 년간 계속되어 왔다. 따라서 DBMS의 품질에서 가장 중요한 품질 특성은 시간 효율성, 즉 시간성능이며, 이는 상용 DBMS를 대체할 오픈소스 DBMS의 선택에서도 마찬가지로 가장 중요한 품질 기준이 된다.

가장 널리 사용되는 상용 DBMS에는 오라클사의 Oracle과 Microsoft사의 MS-SQL Server 등이 있다. 오픈소스 DBMS는 서버용 오픈소스 소프트웨어로서, 대표적인 오픈소스 DBMS에는 MySQL, PostgreSQL, MariaDB, CUBRID, SQLite, MongoDB 등이 있다.

이 중에서 MySQL은 세계에서 가장 많이 사용하는 오픈소스 DBMS이다. 다중 스레드, 다중 사용자 형식의 구조 질의어 형식의 관계형 데이터베이스 관리 시스템으로서 MySQL AB가 관리 및 지원하고 있다. MariaDB도 오픈소스 관계형 DBMS로서 MySQL과 동일한 소스 코드를 기반으로 한다. MariaDB는 현재 오라클 소유의 불확실한 MySQL 의 라이선스 상태에 반발하여 만들어졌으며, 배포자는 몬티 프로그램 AB(Monty Program AB)와 저작권을 공유하도록 되어있다. MariaDB는 MySQL과의 완벽한 호환성으로 인해 오픈소스 소프트웨어로서 그 위상이 매우 높다. 마이크로소프트사의 MS-SQL Server는 마이크로소프트가 1989년에 사이베이스(Sybase)를 기반으로 개발한 관계형 데이터베이스 관리시스템이며, 윈도우즈 운영체제 하의 상용 DBMS를 대표한다. 국내에서는 시장점유율 약 17%로 Oracle과 더불어 전 세계에서 가장 높은 비율로 DBMS 시장을 점유하고 있다.

3.1 실험 환경

본 논문에서 3개의 DBMS를 대상으로 성능을 측정하였다. 오픈소스 DBMS로는 가장 널리 사용되는 MySQL과 MariaDB를 택하였다. 윈도우즈 환경 하에서 성능을 측정하였으므로 상용 DBMS 중에는 윈도우즈 DBMS의 대표인 MS-SQL Server를 택하였다.

동일 환경, 동일 인터페이스 하에서 3개 DBMS의 성능을 측정하기 위해 HeidiSQL을 프론트엔드로 사용한다. HeidiSQL은 자유 소프트웨어이며 오픈 소스 클라이언트로서 MySQL 프론트엔드 제품이다. 윈도우즈 환경 하에서 MySQL, MariaDB, MS-SQL Server를 모두 지원한다.

성능을 측정한 실험 환경은 다음과 같다. CPU i7-4790 3.6GHz, 8GB RAM, Intel HD Graphics 4600을 장착한 PC를 사용하였으며, 운영체제는 64비트 Windows 10, HeidiSQL은 버전 9.4를 사용하였다. DBMS는 MariaDB- 10.2.9-winx64, MySQL Ver 14.14 Distrib 5.6.13 for win64, Microsoft SQL Server 2014를 사용하였다.

3.2 성능 측정 결과

DBMS의 성능을 측정하기 위해서 검색 쿼리 중에서 시간이 가장 많이 소요되는 조인 쿼리를 생성하였다. 2개의 릴레이션이 1개의 외래 키에 의해 연결된다고 가정하고 쿼리 Where 절의 조인 조건은 1개로 단순화하였다. 조인 선택율은 10%라고 가정하였다. 튜플은 무작위로 생성하였으며, 릴레이션에 포함된 튜플의 수를 변화시키면서 변화된 튜플 수에 따라 조인 쿼리를 수행하는 처리시간을 측정하였다. 튜플은 무작위로 생성하였다. 조인하는 튜플의 수를 2개의 릴레이션 모두에서 100개, 1000개, 2000개, 10,000개, 50,000개로 변화시키면서, 작업로드가 적은 100개부터 작업로드가 큰 5만개의 경우까지 DBMS의 조인 쿼리 처리시간을 보았다. 릴레이션의 튜플 수에 따라 각각의 경우에 3개의 DBMS에서의 처리시간을 각 70회씩 측정한 후 이들의 평균값을 데이터로 사용하였다.

조인 쿼리의 실험 결과 릴레이션의 튜플 수의 변화에 따른 조인 쿼리 처리시간의 평균과 표준편차는 Table 1과 같다.

Table 1.

Average processing time and STD for Join query

Table 1의 데이터에서 릴레이션의 튜플 수에 따른 조인 쿼리의 평균 처리시간을 그래프로 나타내면 Figure 1과 같다. 가로축은 튜플의 수이며, 세로축은 처리시간(초)이다. 좌측(LHS) 세로축의 눈금은 MariaDB와 MySQL을, 우측(RHS) 세로축의 눈금은 MS-SQL Server를 나타낸다. MS-SQL Server는 튜플의 수에 관계없이 항상 가장 좋은 성능을 보이며, 튜플 수에 따른 처리시간의 증가속도가 작다. 즉 튜플이 많아질수록 상용 DBMS인 MS-SQL Server 와 오픈소스 DBMS들 간에 큰 성능차이를 보이며, 1,000개 이상일 때부터 그 차이가 매우 커짐을 볼 수 있다. 또한 오픈소스 DBMS들 간에는 튜플의 수가 100개로 작을 때에는 MySQL과 MariaDB 간 성능의 차이가 잘 나타나지 않으나, 튜플의 수가 1,000개 일 때부터는 MariaDB의 성능이 MySQL보다 우수하다는 것을 알 수 있다.

Figure 1.

Graph of average processing time for Join query

3.3 성능품질 분석

DBMS의 성능품질은 조인 쿼리의 처리속도로 정의하였으므로, 3개 DBMS의 성능품질을 비교하기 위해서 각 DBMS 간에 튜플의 개수에 따른 처리시간 평균에 차이가 존재하는가를 분석하였다. 이를 위해 Ree(2013), Ryu(2014)에서와 같은 분산분석을 실시하였다. 분산분석 결과 모든 경우에 유의한 차이를 보였으며, 차이가 나는 그룹을 찾기 위해 Tukey의 HSD 검정을 실시하였다.

3.3.1 튜플의 개수가 100인 경우

튜플의 개수가 100인 두 릴레이션을 조인하는 경우 Table 1의 실험데이터의 분산분석을 실시한 결과는 Table 2와 같다. 분산분석 결과 유의확률이 <0.001 이므로 평균이 같다는 가설을 기각할 수 있다. 즉 평균이 동일하다는 가설을 99.999%의 확률로 기각할 수 있으므로 평균은 동일하지 않다고 말할 수 있다. 따라서 MariaDB, MySQL, MS-SQL Server 3개의 DBMS 간에는 처리시간의 평균들이 차이를 보이고 있다.

Table 2.

ANOVA of DBMS response time at number of tuples = 100

3개 DBMS의 처리시간에서 차이를 보이는 그룹을 찾기 위해 Tukey HSD 검정을 실시하였다. 결과는 Table 3과 같다. 튜플의 수가 100개인 경우에는 MariaDB와 MySQL은 서로 같은 그룹으로 유의한 차이가 없으며 MS-SQL Server와는 다른 성능품질을 가진 두 그룹으로 구분된다.

Table 3.

Tukey HSD at number of tuples = 100

3.3.2 튜플의 개수가 1,000인 경우

튜플의 개수가 1,000인 두 릴레이션을 조인하는 경우 Table 1의 실험데이터의 분산분석을 실시한 결과는 Table 4와 같다. 분산분석 결과 유의확률이 <0.001 이므로 평균이 같다는 가설을 기각할 수 있다. 즉 평균이 동일하다는 가설을 기각할 수 있으므로 평균은 동일하지 않다. 이 경우에서도 MariaDB, MySQL, MS-SQL Server 3개의 DBMS 간에는 처리시간에 있어서 차이를 보인다.

Table 4.

ANOVA of DBMS response time at number of tuples = 1,000

3개 DBMS의 성능품질에서 차이를 보이는 그룹을 찾기 위해 Tukey HSD 검정을 실시하였다. 결과는 Table 5와 같다. MariaDB, MySQL, MS-SQL Server는 서로 다른 성능품질을 가진 세 그룹으로 구분된다. 튜플이 100개인 경우와 달리 오픈소스인 MariaDB와 MySQL에서도 처리시간에서 차이가 나는 결과를 보였다. MySQL이 가장 느렸고, 다음이 MariaDB, MS-SQL server가 가장 빠른 처리시간을 보였다.

Table 5.

Tukey HSD at number of tuples = 1,000

3.3.3 튜플의 개수가 2,000인 경우

튜플의 개수가 2,000인 두 릴레이션을 조인하는 경우 Table 1의 실험데이터의 분산분석을 실시한 결과는 Table 6과 같다. 분산분석 결과 유의확률이 <0.001 이므로 평균이 같다는 가설을 기각할 수 있다. 즉 평균이 동일하다는 가설을 기각할 수 있으므로 평균은 동일하지 않다. 이 경우에서도 MariaDB, MySQL, MS-SQL Server 3개의 DBMS 간에는 처리시간에 있어서 차이를 보인다.

Table 6.

ANOVA of DBMS response time at number of tuples = 2,000

3개 DBMS의 성능품질에서 차이를 보이는 그룹을 찾기 위해 Tukey HSD 검정을 실시하였다. 결과는 Table 7과 같다. MariaDB, MySQL, MS-SQL Server는 서로 다른 성능품질을 가진 세 그룹으로 구분된다. 튜플이 1,000 개인 경우와 마찬가지로 2,000개인 경우에도 3개의 DBMS 간 처리시간에서 차이가 나는 결과를 보였다. MySQL이 가장 느렸고, 다음이 MariaDB, MS-SQL server가 가장 빠른 처리시간을 보였다.

Table 7.

Tukey HSD at number of tuples = 2,000

3.3.4 튜플의 개수가 10,000인 경우

튜플의 개수가 1만 개인 두 릴레이션을 조인하는 경우 Table 1의 실험데이터의 분산분석을 실시한 결과는 Table 8과 같다. 분산분석 결과 유의확률이 <0.001 이므로 평균이 같다는 가설을 기각할 수 있다. 즉 평균이 동일하다는 가설을 기각할 수 있으므로 평균은 동일하지 않다. 이 경우에서도 MariaDB, MySQL, MS-SQL Server 3개의 DBMS 간에는 처리시간에 있어서 차이를 보인다.

Table 8.

ANOVA of DBMS response time at number of tuples = 10,000

3개 DBMS의 성능품질에서 차이를 보이는 그룹을 찾기 위해 Tukey HSD 검정을 실시하였다. 결과는 Table 9와 같다. MariaDB, MySQL, MS-SQL Server는 서로 다른 성능품질을 가진 세 그룹으로 구분된다. 튜플이 1,000 개인 경우, 2,000개인 경우와 마찬가지로 3개의 DBMS 간 처리시간에서 차이가 나는 결과를 보였다. MySQL이 가장 느렸고, 다음이 MariaDB, MS-SQL server가 가장 빠른 처리시간을 보였다.

Table 9.

Tukey HSD at number of tuples = 10,000

3.3.5 튜플의 개수가 50,000인 경우

튜플의 개수가 5만 개인 두 릴레이션을 조인하는 경우 Table 1의 실험데이터의 분산분석을 실시한 결과는 Table 10과 같다. 분산분석 결과 유의확률이 <0.001 이므로 평균이 같다는 가설을 기각할 수 있다. 즉 평균이 동일하다는 가설을 기각할 수 있으므로 평균은 동일하지 않다. 이 경우에서도 MariaDB, MySQL, MS-SQL Server 3개의 DBMS 간에는 처리시간에 있어서 차이를 보인다.

Table 10.

ANOVA of DBMS response time at number of tuples = 50,000

3개 DBMS의 성능품질에서 차이를 보이는 그룹을 찾기 위해 Tukey HSD 검정을 실시하였다. 결과는 Table 11과 같다. MariaDB, MySQL, MS-SQL Server는 서로 다른 성능품질을 가진 세 그룹으로 구분된다. 튜플이 5만 개인 경우에도 3개의 DBMS 간 처리시간에서 차이가 나는 결과를 보였다. MySQL이 가장 느렸고, 다음이 MariaDB, MS-SQL server가 가장 빠른 처리시간을 보였다.

Table 11.

Tukey HSD at number of tuples = 50,000