단일 노드 인스턴스에서 키-값 저장소 기반 분산 NoSQL 데이터베이스 성능 비교

Ⅰ. 서 론

최근 소셜 네트워킹 및 스트리밍 서비스의 확산으로 구조화되지 않은 쿼리 언어(NoSQL) 데이터베이스의 사용이 증가하는 추세를 보이고 있다. 주요 장점 중 하나는 관계형 데이터베이스 관리 시스템(RDBMS)보다 빠르고 효율적인 성능을 보장하기 때문이다[1]. NoSQL 데이터베이스는 빠르게 성장하는 클라우드 컴퓨팅 환경에 맞게 조정되어 탄력적으로 응용 프로그램 개발 단순화에 대한 대규모 확장을 가능하게 하고 있다[2]. 그림 1은 오스트리아 컨설팅 회사인 Solid IT에서 발표한 데이터베이스 인기 순위로 10위 내의 현황을 보여주고 있다. RDBMS에서는 Oracle, MySQL, Microsoft SQL Server, PostgreSQL이 상위권에 위치해 있으며 NoSQL에서는 MongoDB, Redis, Cassandra가 상위권으로 가파른 성장세를 보여주고 있다.

Fig. 1.

Database Engines Ranking

Big Data 및 웹 응용 프로그램 개발에서 모든 NoSQL 데이터베이스가 비슷한 성능을 나타내는 것이 아니기 때문에 데이터베이스 선택에 있어 많은 주의가 필요하다[3]. NoSQL 데이터베이스는 아직까지 성숙 단계에 있으며 각기 서로 다른 성장 속도로 진행되기 때문에 관리자는 데이터베이스의 일관성, 성능, 보완, 확장성, 비용 및 기타 기능적 기준과 관련하여 많은 부분을 고려하여 NoSQL 데이터베이스를 신중하게 선택해야 할 필요가 있다[4].

상당수의 오픈 소스와 쉽게 사용할 수 있는 NoSQL 기반 시스템을 갖춘 웹 응용프로그램 개발자는 많은 NoSQL 데이터베이스 중에서 적절한 선택에 어려움을 경험하고 있다. 데이터베이스의 선택이 다양해진 만큼 개발자는 NoSQL 데이터베이스의 특성을 이해하고 유사한 NoSQL의 차이를 정확하게 이해해야 한다.

본 논문에서는 인 메모리(In-Memory) 기반 데이터베이스와 온 디스크(On-Disk) 기반 데이터베이스를 비교 설명하고 유사한 NoSQL 데이터베이스를 선택할 때 고려되어야 할 사항을 설명한다. 또한, 데이터베이스 성능 비교를 위해 NoSQL 데이터베이스 중 하나인 인 메모리 기반 데이터베이스인 Redis와 Redis의 새로운 대안으로 사용할 수 있는 온 디스크 기반 데이터베이스인 SSDB에 대해 성능 비교를 수행한다.

Ⅱ. 관련 연구

NoSQL의 데이터 모델의 유형은 Key-Value Store, Documents Store, Wide Column Store, Graph Store 네 가지 범주로 분류할 수 있다[4], [5].

키-값 저장소(Key-Value Store)는 키와 값으로 이루어진 심플한 구조의 데이터 모델 저장 스토어이며 수평적 확장이 용이하다[6]. 또한, 간단한 API를 제공하기 때문에 사용하기 쉬우며 질의 속도가 빠르다. 이러한 구조는 사용하는 이유는 속도가 빠르며 분산 저장 환경에 용이하기 때문이다. 주로 빠른 액세스를 위해 메모리를 기반으로 사용한다[7].

도큐먼트 저장소(Document Store)는 BSON(Binary JavaScript Object Notation) 또는 JSON(JavaScript Object Notation)의 형태로 문서 지향 데이터를 저장하는 데이터 모델이다[8], [9]. 키-값 데이터 모델에서 한층 진화한 데이터 모델로 데이터는 키와 도큐먼트의 형태로 저장된다. 키-값 데이터 모델과 다른 점은 값이 계층적인 형태인 도큐먼트로 저장된다는 것이다[10]. 주요 특징은 개체를 도큐먼트의 형태로 바로 저장 가능하기 때문에 검색에 최적화되어 있다.

컬럼-패밀리(Column-Family) 데이터 모델은 행(Row)인 키(Key) 값과 컬럼 패밀리(Column-family), 컬럼 네임(Column-name)을 가진다. Column-family 안에는 연관된 데이터들로 구성되어 있으며, 각자의 Column-name을 가진다[4]. 주요 특징으로 Column-family 데이터 모델은 클러스터링이 쉬우며, Time stamp가 존재해 값이 수정된 이력을 알 수 있다. 또한 값들은 바이너리 데이터로 저장되기 때문에 여러 형태의 데이터도 저장할 수 있다[11].

그래프(Graph Store) 데이터 모델은 관계를 데이터와 함께 저장한다[4]. 즉, 데이터의 연속적인 노드(node), 엣지(edge), 프로퍼티(property)를 그래프 형태로 저장한다[4]. 연관된 데이터를 검색해주는 검색 엔진이나 패턴 인식을 위한 데이터베이스로 적합하다[12].

[13]에서는 여러 NoSQL 데이터베이스에 대해 각 성능적인 측면을 상호 비교하였으나 차이의 원인을 자세히 다루진 않았다. 특히 Redis와 Redis의 새로운 대안인 SSDB와 성능을 비교 분석했다는 점이 다르다고 할 수 있다.

본 논문에서는 서버 메모리에 적합하지 않은 대량의 데이터가 있을 때 Redis 데이터베이스가 갖고 있는 한계와 Redis 데이터베이스의 새로운 대안으로 키-값 저장소의 디스크 기반 SSDB 데이터베이스를 NoSQL 벤치마크 도구인 YCSB(Yahoo! Cloud Serving Benchmarking)를 사용하여 주어진 워크로드를 처리하는 데 있어서 성능과 한계를 비교하고 분석하는 데 목적이 있다.

2-2 Redis

Redis 데이터베이스는 캐시(Cache) 및 메시지 브로커(Message Broker)로 사용되는 오픈 소스(BSD 라이센스) 인 메모리 데이터 구조인 저장소이다[15]. 문자열(Strings), 목록(Lists), 집합(Sets), 정렬된 집합(Sorted Sets), 해시(Hash), HyperLogLogs 및 비트맵(Bitmaps)과 같이 다양한 종류의 데이터 형식이 지원되지만, 키-값 구조의 데이터 모델이다[15].

Redis에는 복제 기능이 내장되어 있으며 마스터-슬레이브(Master-Slave) 모델을 사용하여 복제할 수 있으며 마스터는 여러 개의 종속을 가질 수 있다[3],[15]. Redis는 TCP 소켓과 간단한 프로토콜을 사용하는 클라이언트/서버 모델을 사용하여 전송되는 일련의 명령을 통해 변경 가능한 데이터 구조에 대한 액세스를 제공한다. Redis는 LRU (Least Recently Used) 캐시로 사용할 수 있으며, 근사치 LRU 알고리즘을 사용하여 새 데이터가 추가될 때 기존 데이터를 제거할 수 있다. 또한, C로 작성되었고 Redis에 내장된 강력하고 가벼운 스크립팅 언어인 Lua를 사용하여 스크립팅 기능을 제공한다.

Redis는 Redis Sentinel이라는 기능을 사용하여 마스터가 예상대로 작동하지 않는 경우 자동 장애 조치를 지원한다. 이 기능은 슬레이브가 마스터로 승격된 장애 조치 프로세스를 시작하고 추가 슬레이브도 새 마스터를 사용하도록 재구성된다. Sharding은 Redis 클러스터를 통해 실행된다. 플랫폼에서는 데이터가 여러 Redis 노드에 자동으로 분할된다.

Redis의 Architecture는 그림 2와 같이 크게 3가지 영역인 메모리, 파일, 프로세스 영역으로 구성되어 있다[17].

Fig. 2.

Redis Architecture

2-3 SSDB

SSDB는 Redis의 새로운 대안으로 개발되고 있는 데이터베이스로 수십억 개의 요소를 저장하는 빠른 NoSQL 데이터베이스이다. SSDB는 Redis와 같은 키-값 데이터 모델로 구성되어 있으며, 문자열, 목록, 집합, 정렬된 집합, 해시를 포함하고 있는 데이터 구조를 지원한다.

SSDB는 그림 3과 같이 C/C++로 개발된 Google의 LevelDB를 스토리지 엔진으로 사용하고 있으며 Redis의 네트워크 프로토콜과 오픈 소스 Redis 클라이언트를 지원하는 아키텍처로 구성되어 있다. 또한, Redis와 같은 복제(Master-Slave), 로드 밸런스 기능을 갖고 있으며 개발과 배포를 위한 사용하기 쉬운 클라이언트 API를 지원하고 있다[18].

Fig. 3.

SSDB Architecture

Ⅲ. 실험 및 결과

3-1 실험 환경

본 논문에서 진행하는 벤치마킹 프로세스는 단일 노드 인스턴스를 사용하여 Redis와 SSDB에 대한 NoSQL 데이터베이스의 성능을 비교하는 데 목적이 있다. 성능 분석 도구는 앞 장에서 말한 YCSB를 사용했으며 워크로드의 A타입부터 F 타입까지 실행하는 방식을 사용하였다. 실험을 위한 시스템 환경은 표 1과 같다.

Table 1.

Environment of Performance Evaluation System

3-2 성능 분석 방법

성능 비교의 결과는 제안한 것처럼 Redis의 대안으로 SSDB의 적합성을 입증하는 것이다. 성능 비교를 위해 선택한 벤치마크 도구는 YCSB이다. YCSB는 클라우드 서비스의 성능을 측정하기 위한 벤치마크 도구로써 쿼리 패턴이나 분포를 설정하여 분석할 수 있다. YCSB의 사용 목적은 NoSQL 도입을 검토하려 할 때 특정 상황에 맞는 벤치마킹 환경 및 측정 결과를 제공함으로써 해당 NoSQL이 선정에 적합한지 판단할 기준을 제공한다. YCSB는 플러그인 기반 아키텍처를 가지고 있으며 스크립트를 사용하여 쉽게 확장성을 제공하므로 Redis와 SSDB를 벤치마킹할 수 있는 NoSQL 벤치마크 프레임워크이다[2]. YCSB 아키텍처는 두가지로 구성이 되어있다. 첫 번째는 확장 워크로드를 생성하는 YCBS Client가 구성되어 있으며, 두 번째는 확장 워크로드 생성기에서 실행되는 워크로드 시나리오 세트를 제공해주는 Core workloads로 구성되어 있다. 따라서 YCBS를 사용하여 실제 서비스 요청과 같은 유사한 패턴 결과를 얻을 수 있다. 그림 4는 YCSB의 아키텍처를 나타내고 있다[3].

Fig. 4.

The YCSB Architecture

YCSB를 사용하여 CRUD의 연산 비중을 다르게 설정하여 요청 패턴을 실험할 수 있으며 제공되는 대표적인 YCSB의 워크로드는 표 2와 같다. 대표적인 워크로드는 A타입부터 F타입까지 있으며 성능 비교에 필요한 측정값을 얻을 수 있다[2]. 표 2에서 Operations는 실행하는 워크로드의 연산 비중을 뜻한다. 예를 들어 워크로드 A의 Update heavy를 전체 연산 중에서 50%로 Read 연산을 진행하며, 50%로 Update 연산을 진행하는 것을 뜻한다. 또한, Record selection은 어떤 방법으로 연산할 레코드를 검색할지를 뜻한다. 지프 분포를 적용해 레코드를 탐색하는 Zipfian가 있고, 최근 데이터를 기준으로 레코드를 탐색하는 Latest가 있으며, Continuous Uniform Distribution으로 연속 균등 분포를 통한 확률 분포로 레코드를 탐색하는 Uniform이 있다. 표 2의 설정값들은 기본 설정이 되어있으며, 변경이 필요하다면 Operation 비중과 Record Select 타입을 실험 환경에 맞게 변경할 수 있다. 각각 연산에서 사용되는 쿼리문의 경우, 임의 값을 삽입하여 데이터를 입력하고, 수정 및 삭제, 탐색은 기본 키값에 의해 진행한다.

Table 2.

Workloads in the core package[2]

본 연구에서 임의의 랜덤 값을 이용하여 CRUD를 각 워크로드별로 비교하였으며 스레드의 증가에 따른 데이터의 수를 1000, 5000, 10000개까지 늘리며 각 100회씩 실험을 진행하였으며 그 결과를 기본적으로 제공하는 각 워크로드를 기준으로 도식화했다.

Ⅳ. 비교 분석 결과

4-1 Workload A (Update heavy)

워크로드 A는 Update heavy로 작업한 결과를 나타내고 있다. SSDB는 스레드 수가 증가함에 따라 Redis 보다 성능이 우수하고 처리량이 크게 분산되고 있다. 그림 4와 같이 스레드의 수가 증가하면 SSDB의 성능이 향상된다는 것을 보여준다.

Fig. 4.

Performance comparison of Workload A

4-2 Workload B (Read mostly)

워크로드 B는 Read mostly로 작업한 결과를 나타내고 있다. 결과는 Update heavy 작업과 유사하다. 그림 5와 같이 SSDB는 Redis 보다 성능이 우수하다. 그러나 그림 5(c)와 같이 레코드 건수가 10000개에 이르면 Redis 보다 성능이 떨어지는 것을 확인할 수 있다.

Fig. 5.

Performance comparison of Workload B

4-3 Workload C (Read only)

워크로드 C는 Read only로 작업한 결과를 나타내고 있다. 그림 6과 같이 SSDB의 처리량은 배포된 스레드 수가 증가함에 따라 Redis의 처리량과 큰 차이를 나타내고 있다.

Fig. 6.

Performance comparison of Workload C

4-4 Workload D (Read latest)

워크로드 D는 Read latest로 작업한 결과를 나타내고 있다. 그림 7과 같이 SSDB 처리량 결과가 Redis의 처리량을 어떻게 초과하는지 보여준다. 또한, 스레드 수가 10으로 증가함에 따라 처리량이 크게 향상됨을 나타내고 있다.

Fig. 7.

Performance comparison of Workload D

4-5 Workload E (Short ranges)

워크로드 E는 Short ranges로 작업한 결과를 나타내고 있다. 그림 8과 같이 SCAN 작업에서는 Redis가 처리량 측면에서 SSDB보다 뛰어난 성능을 보여준다. 이는 SCAN 작업에서 SSDB는 스레드 수를 증가하더라도 성능 향상에 영향을 미치지 못함을 나타내고 있다.

Fig. 8.

Performance comparison of Workload E

4-6 Workload F (Read-modify-write)

워크로드 F는 Read-modify-write 작업한 결과를 나타내고 있다. 그림 9는 워크로드 D와 유사하다. SSDB는 스레드 수가 1에서 4까지 Redis와 유사한 성능을 나타낸다. 그러나 스레드의 수가 증가되면 성능의 격차가 커지는 현상을 보여주고 있다.

Fig. 9.

Performance comparison of Workload F

Ⅴ. 결 론

새로운 아키텍처를 가진 데이터베이스 솔루션들이 최근 많이 제안되어 개발되고 있는 추세다. 또한, 유사한 아키텍처를 가지는 NoSQL 데이터베이스도 있어 동일한 데이터 모델을 갖는 데이터베이스를 선택할 때 성능적인 요소들에 대한 충분한 검토가 선행되어야 한다.

본 논문에서는 NoSQL중 키-값 데이터 모델을 기반으로 하는 Redis와 SSDB를 비교하여 성능을 비교 분석하였다. 앞장의 비교 분석 결과와 같이 데이터베이스를 선택할 때 높은 성능을 보여주고 있는 해당 워크로드의 작업에 알맞은 솔루션 선택 시나리오에 중요한 지표를 제시하고 있다. 본 논문에서는 Redis의 새로운 대안인 SSDB는 실험 결과에서 대부분 높은 성능을 나타내고 있음을 입증하였으며 향후 SSDB가 소셜 네트워킹 및 스트리밍 서비스 처리에 적합하게 사용될 것으로 기대된다.

향후 진행할 연구 계획으로는 NoSQL 데이터베이스를 선택할 때 고려해야 할 사항으로 성능 문제뿐만 아니라 데이터의 보안 문제도 검토되어야 한다. NoSQL의 성격과 특성(데이터의 양, 처리 속도, 다양성 및 신뢰성)으로 인해 보안 문제가 발생한다. 고려 대상 중 하나는 응용프로그램의 성능을 저하시키지 않으면서 암호화된 데이터베이스 시스템을 쿼리하는 방법이다. 이 연구가 보안 문제를 다루지는 않았지만, 추가적인 성능과 보안에 대해 향후 추가적인 연구를 진행할 예정이다.

Acknowledgments

본 논문은 교육부와 한국연구재단의 재원으로 지원을 받아 수행된 사회맞춤형 산학협력 선도대학(LINC+) 육성사업의 연구결과입니다(과제번호: 201914087001).

참고문헌

• C. Kumarasinghe, K. Liyanage, W. Madushanka, and R. Mendis, Performance Comparison of NoSQL Databases in Pseudo Distributed Mode: Cassandra, MongoDB & Redis, 2016.
• B. F. Cooper, A. Silberstein, E. Tam, R. Ramakrishnan, and R. Sears, Benchmarking cloud serving systems with YCSB, Proceedings of the 1st ACM symposium on Cloud computing, pp. 143-154, 2010. [https://doi.org/10.1145/1807128.1807152]
• Y. Abubakar, T. S. Adeyi, and I. G. Auta, Performance evaluation of NoSQL systems using YCSB in a resource austere environment, Performance Evaluation, Vol.7, No.8, pp.23-27, 2014. [https://doi.org/10.5120/ijais14-451229]
• A. Oussous, F. Benjelloun, A. A. Lahcen, and S. Belfkih, Comparison and classification of nosql databases for big data, Proceedings of International Conference on Big Data, Cloud and Applications, Vol. 2, 2015.
• H. Khazaei, M. Fokaefs, S. Zareian, N. Beigi-Mohammadi, B. Ramprasad, M. Shtern, P. Gaikwad, and M. Litoiu, How do I choose the right NoSQL solution? A comprehensive theoretical and experimental survey, Big Data and Information Analytics (BDIA), Vol.2, pp.1, 2016. [https://doi.org/10.3934/bdia.2016004]
• E. Anderson, X. Li, M. A. Shah, J. Tucek, and J. J. Wylie, What consistency does your key-value store actually provide? HotDep, Vol. 10, pp. 1-16, 2010.
• B. Atikoglu, Y. Xu, E. Frachtenberg, S. Jiang, and M. Paleczny, Workload analysis of a large-scale key-value store, ACM SIGMETRICS Performance Evaluation Review, Vol. 40, No. 1, pp. 53-64, 2012. [https://doi.org/10.1145/2318857.2254766]
• K. Ma and A. Abraham, Toward lightweight transparent data middleware in support of document stores, 2013 Third World Congress on Information and Communication Technologies (WICT 2013), pp. 253-257, 2013.
• C. Chasseur, Y. Li, and J. M. Patel, Enabling JSON Document Stores in Relational Systems. WebDB, Vol. 13, pp. 14-15, 2013.
• R. Cattell, Scalable SQL and NoSQL data stores, Acm Sigmod Record, Vol.39, No.4, pp.12-27, 2011. [https://doi.org/10.1145/1978915.1978919]
• D. J. Abadi, Column Stores for Wide and Sparse Data. CIDR, Vol. 2007, pp. 292-297, 2007.
• V. Kacholia, S. Pandit, S. Chakrabarti, S. Sudarshan, R. Desai, and H. Karambelkar, Bidirectional expansion for keyword search on graph databases, Proceedings of the 31st international conference on Very large data bases, pp. 505-516, 2005.
• E. Tang and Y. Fan, Performance comparison between five NoSQL databases, 2016 7th International Conference on Cloud Computing and Big Data (CCBD), pp. 105-109, 2016. [https://doi.org/10.1109/CCBD.2016.030]
• J. Han, E. Haihong, G. Le, and J. Du, Survey on NoSQL database, 2011 6th international conference on pervasive computing and applications, pp. 363-366, 2011.
• About Redis[internet]. Available: http://redis.io, .
• K. Grolinger, W. A. Higashino, A. Tiwari, and M. A. Capretz, Data management in cloud environments: NoSQL and NewSQL data stores, Journal of Cloud Computing: Advances, Systems and Applications, Vol.2, No.1, pp.22, 2013. [https://doi.org/10.1186/2192-113X-2-22]
• About Redis Architecture[internet]. Available: https://sqlmvp.tistory.com/1321, .
• About SSDB[internet]. Available: http://ssdb.io, .