KR20180044696A

KR20180044696A - 쿼리 결과 분산 저장 방법 및 그 시스템

Info

Publication number: KR20180044696A
Application number: KR1020160138516A
Authority: KR
Inventors: 정재부
Original assignee: 삼성에스디에스 주식회사
Priority date: 2016-10-24
Filing date: 2016-10-24
Publication date: 2018-05-03
Also published as: EP3312743A1; EP3312743B1; US20180113912A1

Abstract

본 발명의 일 태양에 따른 쿼리 결과 분산 저장 방법은, 마스터 서버가, 데이터를 조회하기 위한 쿼리(query)를 데이터베이스(database)에서 실행하는 단계와 상기 마스터 서버가, 상기 실행의 결과로 상기 데이터에 관한 메타 데이터(meta data) 및 상기 데이터를 구성하는 제1 일부 데이터를 상기 데이터베이스로부터 직렬화(serialization) 된 상태로 제공 받는 단계와 상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계 및 상기 제1 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 포함할 수 있다.

Description

쿼리 결과 분산 저장 방법 및 그 시스템 {Method and system for storing query result in distributed server}

본 발명은 쿼리 결과를 분산 서버에 저장하는 방법 및 그 시스템에 관한 것이다. 보다 자세하게는 데이터베이스에 저장된 대용량의 데이터를 조회하고, 복수의 분산 서버에 조회된 데이터의 일부를 나누어서 저장하는 방법 및 그 방법을 수행하는 시스템에 관한 것이다.

대용량의 데이터, 이른바 빅데이터(big data)가 관계형 데이터베이스 관리 시스템(RDBMS; Relational Database Management System)에 저장되어 있는 경우를 생각해보자. 예를 들면, 반도체 제조 공장에 설치된 수만개의 센서(sensor)는 일정한 주기마다 데이터를 측정하고, 측정한 데이터를 데이터베이스에 저장한다.

이러한 빅데이터를 하나의 서버에서 처리하기에는 서버의 성능을 아무리 끌어올리더라도 물리적인 한계가 있기 때문에 쉽지가 않다. 그래서 최근에는 빅데이터를 하나의 서버에서 처리하는 것이 아니라, 복수의 서버에서 데이터를 나누어서 병렬 처리하는 경우가 많다. 문제는 복수의 서버에서 데이터를 나누어서 병렬 처리를 하기 위해서는 먼저, 데이터베이스에 저장된 대용량의 데이터를 로드(load)해서 여러 조각으로 나누고 각각의 서버에 저장해야 한다는 점이다.

데이터베이스에 저장된 대용량의 데이터를 각각의 분산 서버에 저장하기 위해서 주로 사용하는 방법은 다중 쿼리 방식이다. 다중 쿼리 방식이란 복수의 분산 서버가 데이터베이스에 각각 연결(connection)을 맺고, 분산 조건절이 포함된 쿼리(query)를 각각 실행해서 자신이 저장해야 할 데이터들을 조회하고, 조회된 결과를 분산 서버에 각각 저장하는 방식이다.

그러나 다중 쿼리 방식은 분산 서버의 입장에서는 하나의 쿼리를 각각 실행하는 것이나, 데이터베이스의 입장에서는 여러 개의 쿼리가 동시에 실행되는 것이기 때문에, 데이터베이스의 리소스를 많이 소모한다는 단점이 있다. 또한, 분산 서버의 수만큼 데이터베이스에 연결(connection)이 생성되기 때문에 데이터베이스의 최대 연결 허용 수를 넘어 다른 사용자의 접속을 방해할 가능성이 높다는 단점도 있다.

이에 데이터베이스에 저장된 대용량의 데이터를 복수의 서버에 분산해서 저장하고 이를 분석하는 과정에 있어서, 그 준비 단계에 해당하는 데이터의 로딩 방법과 분산 저장 방법을 개선할 필요가 있다. 즉, 데이터베이스의 리소스의 적게 소모하면서, 데이터베이스와의 연결도 줄이고, 실행시간도 단축시킬 수 있는 분산 저장 방법이 필요하다.

US 2012-0197864 A1 "TRUSTED QUERY SYSTEM AND METHOD" (2012.08.02) US 2015-0095308 A1 "BACKGROUND FORMAT OPTIMIZATION FOR ENHANCED SQL-LIKE QUERIES IN HADOOP" (2015.04.02) KR 2015-0132472 A "인 플레이스 스냅샷들" (2015.11.25)

이진용, 전순미 "CORBA 분산 객체 환경을 위한 JDBC 하위 프로토콜의 설계 및 구현" (논문 1997.10) 차상환, 황병곤 "JDBC를 이용한 분산 환경에서의 이미지 검색 웹 에이전트" (논문 2004.05)

본 발명이 해결하고자 하는 기술적 과제는 쿼리 결과를 분산 서버에 저장하는 방법 및 그 시스템을 제공하는 것이다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 태양에 따른 쿼리 결과 분산 저장 방법은, 마스터 서버가, 데이터를 조회하기 위한 쿼리(query)를 데이터베이스(database)에서 실행하는 단계와 상기 마스터 서버가, 상기 실행의 결과로 상기 데이터에 관한 메타 데이터(meta data) 및 상기 데이터를 구성하는 제1 일부 데이터를 상기 데이터베이스로부터 직렬화(serialization) 된 상태로 제공 받는 단계와 상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계 및 상기 제1 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 포함할 수 있다.

일 실시 예에서, 상기 마스터 서버가, 상기 데이터가 병렬 처리가 필요한 대용량 데이터인지 판단하고, 상기 마스터 서버가, 상기 데이터가 병렬 처리가 필요한 것으로 판단한 경우에, 상기 실행하는 단계와 상기 제공 받는 단계와 상기 분배하는 단계를 수행하는 것이다.

다른 실시 예에서, 상기 데이터를 조회하기 위한 쿼리(query)를 데이터베이스(database)에서 실행하는 단계는, 상기 마스터 서버가, 상기 데이터를 패치 사이즈(fetch size)에 따라 일부 데이터로 나누어서 조회하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 데이터를 패치 사이즈(fetch size)에 따라 일부 데이터로 나누어서 조회하는 단계는, 상기 마스터 서버가, 상기 데이터의 총 로우(row) 수를 슬레이브 서버의 총 개수로 나눈 값보다 작거나 같은 값으로 상기 패치 사이즈를 설정하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 실행의 결과로 상기 데이터에 관한 메타 데이터(meta data) 및 상기 데이터를 구성하는 제1 일부 데이터를 상기 데이터베이스로부터 직렬화(serialization) 된 상태로 제공 받는 단계는, 상기 마스터 서버가, 상기 데이터베이스로부터 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 임시 저장 공간(temporary space)에 저장하는 단계를 포함하고, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계는, 상기 마스터 서버가, 상기 제1 슬레이브 서버에 분배한 상기 제1 일부 데이터를 상기 임시 저장 공간에서 삭제하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계는, 상기 마스터 서버가, 상기 분배하는 단계 이전에 상기 제1 일부 데이터를 압축(compress)하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는, 상기 제1 슬레이브 서버가, 상기 반직렬화하는 단계 이전에 상기 제1 일부 데이터의 압축을 해제(decompress)하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는, 상기 제1 슬레이브 서버가, 상기 마스터 서버를 가상의 데이터베이스(virtual database)로 하는 가상 연결(virtual connection)을 생성하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는, 상기 제1 슬레이브 서버가, 상기 반직렬화의 결과로 상기 일부 데이터에 대응되는 객체(object)를 생성하는 단계 및 상기 제1 슬레이브 서버가, 상기 생성된 객체를 상기 제1 슬레이브 서버의 로컬 디스크에 저장하는 단계를 포함할 수 있다.

또 다른 실시 예에서, 상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제2 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계와 상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제2 일부 데이터를 그대로 제2 슬레이브 서버에 분배하는 단계 및 상기 제2 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제2 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함할 수 있다.

또 다른 실시 예에서, 상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제m 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계와 상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제m 일부 데이터를 그대로 제m 슬레이브 서버에 분배하는 단계 및 상기 제m 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제m 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함하되, 상기 m은 슬레이브 서버의 총 개수이다.

또 다른 실시 예에서, 상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제k 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계와 상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제k 일부 데이터를 그대로 제k' 슬레이브 서버에 분배하는 단계 및 상기 제k' 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제k 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함하되, 상기 k'는 상기 k의 값을 m으로 나눈 나머지이되, 상기 나머지가 0인 경우에는 상기 k'는 상기 m의 값과 동일한 값을 가지고, 상기 m은 슬레이브 서버의 총 개수이다.

또 다른 실시 예에서, 상기 마스터 서버가, 상기 실행하는 단계와 상기 제공 받는 단계와 상기 분배하는 단계를 JDBC(Java Database Connectivity)를 이용하여 수행하고, 상기 제1 슬레이브 서버가, 상기 반직렬화(deserialization)하는 단계를 상기 JDBC(Java Database Connectivity)를 이용하여 수행하고, 상기 JDBC는 기존의 type 1 내지 type 4의 JDBC를 수정한 JDBC이다.

본 발명의 실시 예에 따른 효과는 다음과 같다.

본 발명은 사용자가 쿼리 실행을 통해 데이터베이스로부터 얻고자 하는 대용량의 데이터를 여러 개의 병렬 처리 서버에 분산 저장하여 빅데이터 분석(=병렬 처리)을 준비하는 단계의 방법을 개선한 것이다. 본 발명에 의하면 기존의 방법에 비해 총 실행 시간을 대폭 감소시킬 수 있고, 데이터베이스와의 연결을 최소화하여 안정적인 운영을 할 수 있다. 또한, 서버의 CPU와 메모리 사용량을 최소화할 수 있다. 이를 통해 동시 사용자를 고려한 서비스 형태의 빅데이터 어플리케이션에도 적용이 가능하다.

본 발명은 데이터베이스와 한 개의 연결만 사용하므로 데이터베이스의 가용성을 보장할 수 있다. 또한, 기존의 JDBC(Java Database Connectivity)와 같은 데이터베이스 커넥터가 원본 바이트 배열을 객체화하고, 어플리케이션에서 객체를 다시 직렬화(Serialization) 하여 저장하는데 비해서, 본 발명에 따른 JDBC는 이 과정 없이 바이트 배열 상태의 데이터를 직접 저장하고, 복수의 서버에 분산하여 객체화 할 수 있다. 이를 통해 속도 향상 및 저장용량 감소 효과를 얻을 수 있다.

본 발명의 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해 될 수 있을 것이다.

도 1은 종래의 분산 쿼리 방식에 의한 데이터 저장 방법을 설명하기 위한 예시도이다.
도 2는 종래의 단일 연결 방식에 의한 데이터 저장 방법을 설명하기 위한 예시도이다.
도 3은 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법을 설명하기 위한 예시도이다.
도 4는 종래의 분산 쿼리 방식에 의한 JDBC(Java Database Connectivity)의 작동을 설명하기 위한 예시도이다.
도 5는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 작동을 설명하기 위한 예시도이다.
도 6은 종래의 단일 연결 방식에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 개념도이다.
도 7은 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 개념도이다.
도 8은 종래의 단일 연결 방식에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 순서도이다.
도 9는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 순서도이다.
도 10 및 도 11a 내지 도 11b는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법의 효과를 설명하기 위한 예시도이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 게시되는 실시예에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 게시가 완전하도록 하고, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다.

명세서에서 사용되는 "포함한다 (comprises)" 및/또는 "포함하는 (comprising)"은 언급된 구성 요소, 단계, 동작 및/또는 소자는 하나 이상의 다른 구성 요소, 단계, 동작 및/또는 소자의 존재 또는 추가를 배제하지 않는다.

이하, 본 발명에 대하여 첨부된 도면에 따라 보다 상세히 설명한다.

도 1은 종래의 분산 쿼리 방식에 의한 데이터 저장 방법을 설명하기 위한 예시도이다.

도 1을 참고하면, 병렬 처리를 위하여 마스터 서버(110)와 슬레이브 서버(111-1, …, 111-N)가 구성되어 있는 것을 볼 수 있다. 마스터 서버(110) 하나에서 대용량의 데이터를 처리하기 것보다 복수의 슬레이브 서버(111-1, ..., 111-N)에서 대용량의 데이터를 분산하여 병렬 처리(parallel processing)하는 것이 연산의 속도를 더 높일 수 있다.

종래의 분산 쿼리 방식에서는 마스터 서버(110)가 분석이 필요한 대용량 데이터를 로딩하기 위한 쿼리(query)를 슬레이브 서버(111-1, ..., 111-N)로 전달한다. 그러면, 슬레이브 서버(111-1, ..., 111-N)에서는 데이터의 중복이 없도록 분산 쿼리를 작성한다. 즉, 쿼리에 분산 조건절(where)을 추가하여 데이터를 나누어서 조회하고 저장하는 방식이다.

슬레이브 서버 1(111-1)부터 슬레이브 서버 N(111-N)까지, 각각 조건절이 상이한 쿼리를 데이터베이스(120)에서 실행하면 데이터베이스(120)에서는 대용량의 데이터가 나뉘어서 조회된다. 그리고, 데이터베이스(120)에서는 조회된 데이터를 바이트(byte) 스트림으로 슬레이브 서버(111-1, ..., 111-N)에 전송한다. 슬레이브 서버(111-1, ..., 111-N)에서는 전송 받은 바이트를 객체(object)로 변환하여, 필요한 연산 작업을 수행한다.

이처럼 종래의 분산 쿼리 방식에서는 슬레이브 서버(111-1, ..., 111-N)에서 각각의 쿼리를 각각 실행하는 방식으로 병렬 처리를 구현하였다. 그러나, 데이터베이스(120)에 슬레이브 서버의 수인 N개만큼의 연결(connection)이 필요하기 때문에, 여러가지 문제점이 있다.

첫째로 데이터베이스(120)에 연결된 연결(connection)의 수가 많고, 여러 개의 쿼리를 동시에 실행하기 때문에 데이터베이스(120)의 리소스를 많이 소모한다는 단점이 있다. 특히 복수의 슬레이브 서버(111-1, ..., 111-N)에서 실행하는 쿼리의 분산 조건절에 인덱스(index)가 걸려있지 않거나, 인덱스가 걸려있더라도 실행 계획(execution plan)이 제대로 최적화 되어 있지 않은 경우에는 데이터베이스(120)의 리소스를 많이 소모하게 된다.

둘째로 복수의 슬레이브 서버(111-1, ..., 111-N)에서 여러 개의 쿼리를 실행하기 때문에 슬레이브 서버의 수만큼의 연결(connection)이 필요하다는 단점이 있다. 이로 인해 다른 사용자의 접속을 방해할 가능성이 많다. 데이터베이스(120)의 물리적인 성능에는 한계가 있어서 동시에 처리가 가능한 연결의 수는 제한적이기 때문이다.

물론 대용량의 데이터를 가공하고 분석하기 위한 데이터 웨어하우스(Data Warehouse)와 같은 시스템에서는 일반 사용자의 접속이 발생하지 않을 것이나, 그렇지 않은 경우에는 일반 사용자의 접속이 발생할 수 있다. 이때, 슬레이브 서버(111-1, ..., 111-N)의 연결로 인해 데이터베이스(120)의 최대 연결 허용 수를 넘게 되면, 일반 사용자의 원활한 이용이 어려울 수 있다.

셋째로 실행 시간이 오래 걸리는 쿼리의 경우, 다중으로 실행한 쿼리 전체를 실행 완료하는데 많은 시간이 소모된다는 단점이 있다. 즉 분산 쿼리의 실행 계획(execution plan)이 인덱스를 잘 이용하더라도, 각각의 슬레이브 서버(111-1, ..., 111-N)에서 실행한 쿼리를 모두 완료하는데 소모되는 시간이, 하나의 쿼리로 테이블(table) 전체를 한번에 풀 스캔(full scan)하는 경우보다 성능이 떨어지는 경우가 생길 수 있다.

넷째로 분산 정도를 조절하는데 한계가 있다는 단점이 있다. 분산 쿼리의 조건절(where)에 따라 각 슬레이브 서버(111-1, ..., 111-N)에 분산되는 데이터의 양이 결정되는데, 조건절을 잘 못 설정하는 경우 어느 한 슬레이브 서버로 데이터가 편중될 수 있다.

물론 슬레이브 서버(111-1, ..., 111-N)에 데이터를 균등하게 분산하기 위해서 로우넘(rownum)과 같은 함수를 이용해 범위를 지정하여 데이터를 분산해서 조회할 수도 있다. 그러나, 데이터베이스(120)에서 로우넘 함수를 지원하지 않을 수도 있고, 로우넘 함수를 정렬(order by)와 함께 사용하는 경우 성능에 문제가 생길 수도 있다.

복수의 슬레이브 서버(111-1, ..., 111-N)에 데이터가 균등하게 분배되지 않는 경우, 즉 특정 슬레이브 서버에만 데이터가 편중되는 경우에는 특정 슬레이브 서버에만 부담이 집중되기 때문에 병렬 처리를 수행하는 효과가 상쇄되어 전체적인 성능(performance)의 저하가 발생할 수 있다.

지금까지 도 1을 통해서 복수의 병렬 처리 서버에 데이터를 로딩하기 위한 종래의 분산 쿼리 방식을 살펴보았다. 종래의 방식에서는 데이터베이스(120)에 집중되는 부하, 최대 연결 허용 수의 제한, 전체적인 성능의 문제, 데이터의 편중 현상 등의 문제가 있었다.

도 1의 예시도에서 색상이 어둡게 표시된 부분이 이러한 문제점이 발생할 수 있는 구간들이다. 즉, 데이터베이스(120)와 슬레이브 서버(111-1, ..., 111-N) 사이에서 생성한 연결(connection) 및 분산 쿼리의 조건절이 어두운 색상으로 표시가 된 부분으로, 위에 언급한 문제점들이 발생할 수 있는 구간이다.

물론, 종래에도 분산 쿼리 방식의 문제점을 해결하기 위한 노력들이 있었다. 그 한 예로 단일 연결 방식이 있다. 복수의 슬레이브 서버(111-1, ..., 111-N)에서 데이터베이스(120)에 각각 연결해서 데이터를 로딩(loading)하는 방식이 아닌, 마스터 서버(110)에서 데이터베이스(120)에 연결해서 데이터를 로딩(loading)하고, 로딩된 데이터를 복수의 슬레이브 서버(111-1, ..., 111-N)로 분배하는 방식이다.

도 2는 종래의 단일 연결 방식에 의한 데이터 저장 방법을 설명하기 위한 예시도이다.

도 2를 참고하면, 도 1의 분산 쿼리 방식과는 다르게 마스터 서버(110)에서 데이터베이스(120)에 연결(connection)을 하나만 생성한 것을 볼 수 있다. 즉 마스터 서버(110)에서 데이터 전체를 조회하기 위한 쿼리를 데이터베이스(120)에 접속하여 직접 실행하고 그 결과를 바이트로 수신한 다음, 이를 복수의 슬레이브 서버(111-1, ..., 111-N)로 분배한다.

단일 연결 방식에서, 마스터 서버(110)가 복수의 슬레이브 서버(111-1, ..., 111-N)에 데이터를 분배하기 위해서는, 데이터베이스(120)에서 바이트 형태로 수신한 데이터를 객체로 변환하는 과정(Convert Bytes to Object)과, 변환된 객체를 직렬화 하는 과정(Serialization) 및, 직렬화 된 데이터를 리파티셔닝(Repartitioning) 하는 과정이 필요하다.

리파티셔닝(Repartitioning) 작업은 맵리듀스(MapReduce)나 스파크(Spark) 등에서 파일을 분산시키기 위해서 사용하는 기능이다. 마스터 서버(110)에서 리파티셔닝(Repartitioning) 작업을 실행하기 위해서는 일단 모든 데이터가 마스터 서버(110)에 저장되어야 하므로, 대용량 데이터의 경우 마스터 서버(110)의 디스크 용량 부족을 초래할 수 있다.

또한, 일단 마스터 서버(110)에 대용량의 데이터를 저장하기 위해서는 마스터 서버(110)에서 직렬화(serialization)와 반직렬화(deserialization)가 수행되어야 하므로, 마스터 서버(110)에 많은 리소스를 요구하게 된다. 즉 CPU와 메모리(memory)를 많이 필요로 하게 된다.

또한, 일시적으로 대용량의 데이터가 마스터 서버(110)에 로딩되었다가 슬레이브 서버(111-1, ..., 111-N)로 분배되는 과정에서 병목 현상으로 인한 속도 저하나 불안정 현상이 발생할 수 있다. 즉 단일 연결을 사용함에도 동시 사용자가 사용하기 힘든 구조가 될 수 있다.

또한, 리파티셔닝(Repartitioning) 작업은 셔플(shuffle)이 일어나기 때문에 상대적으로 느리며, 해쉬키(Hash Key) 또는 레인지(Range) 등을 기준으로 재정렬을 수행하기 때문에 기존의 쿼리 결과의 순서가 뒤바뀌는 상황을 초래할 수도 있다.

도 2를 참고하면, 마스터 서버(110)에서 조회한 데이터를 객체로 변환하고, 이를 직렬화하고, 마스터 서버(110)의 로컬 디스크에 저장하고, 이를 리파티셔닝(Repartitioning) 하고, 복수의 슬레이브 서버(111-1, ..., 111-N)로 전송하여 각 슬레이브 서버(111-1, ..., 111-N)에서 조각(fraction)을 저장하고, 마스터 서버(110)에서 전체 데이터를 삭제하는 과정을 수행하게 된다.

이 과정에서 데이터베이스(120)로부터 수신한 바이트를 객체화 하는 과정에 많은 CPU와 메모리를 소모하게 된다. 특히 자바 계열의 JDBC(Java Database Connectivity)는 마스터 서버(110)의 JVM(Java Virtual Machine) 위에서 객체화가 수행되는데 대용량의 메모리의 사용으로 인해, GC(Garbage Collection)가 빈번하게 일어나게 된다.

그리고 마스터 서버(110)가 대용량의 데이터를 로컬 디스크에 저장하고 리파티셔닝 하는 과정에서 마스터 서버(110)에 부하가 집중된다. 즉 단일 연결 방식은, 분산 쿼리 방식에서 데이터베이스(120)와 특정 슬레이브 서버에 부하가 집중될 수 있는 문제점은 해결하였지만, 대신에 마스터 서버(110)에 부하가 집중되는 문제점을 초래하게 된다.

도 2의 예시도에서 색상이 어둡게 표시된 부분이 이러한 문제점이 발생할 수 있는 구간들이다. 즉, 데이터베이스(120)로부터 조회한 결과를 객체화 하는 과정과 리파티셔닝 하는 과정이 어두운 색상으로 표시가 된 부분으로, 위에 언급한 문제점들이 발생할 수 있는 구간이다.

본 발명에서는 종래의 분산 쿼리 방식과 단일 연결 방식에서 발생할 수 있는 문제점을 모두 해결하고자 한다. 즉 분산 쿼리 방식에서 데이터베이스(120)에 부하가 집중되는 문제점 및 복수의 슬레이브 서버(111-1, ..., 111-N) 사이에서 발생할 수 있는 데이터 편중되는 문제점을 해결하고자 한다. 또한, 단일 연결 방식에서 데이터를 분배하기 위해 마스터 서버(110)의 리소스를 많이 소모하는 문제점 및 리파티셔닝(Repartitioning) 작업의 문제점을 해결하고자 한다.

도 3은 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법을 설명하기 위한 예시도이다.

도 3을 참고하면, 도 2의 단일 연결 방식과 유사하게 마스터 서버(110)에서 데이터베이스(120)에 하나의 연결을 생성한 것을 볼 수 있다. 본 발명의 데이터 분산 저장 방법을 이용하면, 분산 쿼리 방식처럼 분산을 위한 조건절을 생성할 필요 없이 요청 쿼리를 그대로 실행할 수 있다. 또한, 단일 연결 방식처럼 데이터베이스(120)에서 전송된 대용량의 데이터를 객체화 할 필요 없이, 원본 바이트 배열 데이터를 중간에 가로채 그대로 복수의 슬레이브 서버(111-1, ..., 111-N)로 전송할 수 있다.

그리고, 복수의 슬레이브 서버(111-1, ..., 111-N)에서는 분산 쿼리 방식처럼 데이터베이스(120)에 직접 연결하는 대신 마스터 서버(110)를 가상의 데이터 베이스로 취급하여 연결할 수 있다. 즉, 데이터베이스(120)에서 조회된 데이터의 바이트와 메타 데이터(meta data)를 마스터 서버(110)에서 그대로 각 슬레이브 서버(111-1, ..., 111-N)로 전송하면, 각 슬레이브 서버(111-1, ..., 111-N)는 이를 전송 받아 객체화 하고 로컬 디스크에 저장할 수 있다.

정리하면, 도 3의 쿼리 결과 분산 저장 방법은 도 1에서 설명한 분산 쿼리 방식과 도 2에서 설명한 단일 연결 방식의 장점을 흡수한 형태의 방법이다. 이를 통해 데이터베이스(120)의 부하나 마스터 서버(110)의 부하를 줄이고, 대용량 데이터를 각각의 슬레이브 서버에서 병렬 처리할 수 있다.

도 3의 쿼리 결과 분산 저장 방식과 도 2의 단일 연결 방식을 비교할 때, 가장 큰 차이점은 도 3에서는 데이터베이스(120)에서 조회한 결과를 바이트로 수신하고, 이를 객체화 과정 없이 그대로 슬레이브 서버로 전송한다는 점이다. 물론 이 과정에서 전송의 효율을 높이기 위해서 바이트 데이터를 압축(compress)하는 과정이 선택적으로 적용될 수 있다.

도 3을 참고하면, 마스터 서버(110)가 데이터베이스(120)에서 대용량의 데이터를 조회하면, 한번에 대용량의 데이터를 다 로딩(loading)하는 것이 아니라, 패치 사이즈(fetch size)에 따라 대용량의 데이터를 분할해서 로딩(loading)한다. 마스터 서버(110)에서는 패치 사이즈(fetch size)에 따라 분할된 바이트 블록(bytes block)을 순서대로 각 슬레이브 서버에 전송한다.

이때, 선택적으로 바이트 블록을 압축해서 전송할 수 있다. 만약 마스터 서버(110)에서 바이트 블록을 압축해서 전송하면, 이를 수신한 슬레이브 서버에서는 수신한 바이트 블록의 압축을 해제하고 이를 객체화 하여 슬레이브 서버의 로컬 디스크에 저장한다. 즉, 슬레이브 서버에는 데이터 블록 단위로 대용량의 데이터가 나뉘어서 저장된다.

또한, 마스터 서버(110)에서는 특정 슬레이브 서버로 특정 바이트 블록을 전송한 후에는, 마스터 서버(110)의 로컬 디스크에 저장된 해당 바이트 블록을 삭제한다. 그리고 다음 패치(fetch)를 실행하여 다음 바이트 블록을 마스터 서버(110)의 로컬 디스크에 저장하고, 다음 슬레이브 서버로 새로 저장된 바이트 블록을 전송한다. 이렇게 바이트 블록 단위로 대용량의 데이터를 바로바로 슬레이브 서버로 분산시키므로, 마스터 서버(110)의 리소스를 적게 사용할 수 있다.

도 3을 참고하면, 본 발명의 쿼리 결과 분산 저장 방법에서는 마스터 서버(110)에서 네트워크(network)를 통해 복수의 슬레이브 서버로 바이트 블록을 전송하는 과정에서 효율을 높이기 위해 수행한 압축(compress)과 각 슬레이브 서버에서 압축을 해제(decompress)하는 과정에서 부하가 발생할 수 있다. 다만, 이는 전송의 효율을 높이기 위한 선택적인 과정으로 생략할 수도 있다.

도 1의 다중 쿼리 방식이나 도 2의 단일 연결 방식에 비하면 데이터베이스(120)에도 마스터 서버(110)에도 부하가 집중되지 않는 점을 확인할 수 있다. 또한, 각 슬레이브 서버에 대용량의 데이터가 균등하게 분산되어 있어, 맵리듀스(MapReduce)나 스파크(Spark) 등의 분산 처리 어플리케이션에서 바로 활용이 가능하다.

본 발명의 쿼리 결과 분산 저장 방법을 이용하면, 마스터 서버(110)가 한 개의 연결만 사용하므로 데이터베이스(120)의 가용성을 보장할 수 있다. 또한 마스터 서버(110)가 데이터베이스(120)로부터 수신한 바이트를 객체화 하고 리파티셔닝 하는 과정 없이 바이트 배열 상태의 데이터를 직접 각각의 슬레이브 서버에 전송하므로 데이터 조각을 균일하게 분배할 수 있으며, 조각(partition)의 수를 조절할 수 있다.

정리하면 본 발명의 쿼리 결과 분산 저장 방법을 이용하면, 데이터베이스(120)에서 전송한 바이트를 네트워크를 전송하기 위해 직렬화 할 필요 없이 바이트 상태 그대로 전송하므로 마스터 서버(110)의 부하(overhead)가 없으며, 패치 사이즈로 나누어진 바이트 블록을 그대로 활용하여 데이터를 전송하므로 데이터의 편중 현상을 해결할 수 있으며, 조각의 순서대로 번호를 부여하고 이를 활용하므로, 쿼리 결과의 순서가 뒤바뀌는 것을 예방할 수 있다.

또한, 마스터 서버(110)에서는 슬레이브 서버로 데이터를 전송한 후에 이를 즉시 삭제하므로 디스크나 메모리 소모량을 줄일 수 있다. 또한, 마스터 서버(110)에서 수행하던 객체화는 각 슬레이브 서버가 담당하므로 객체화에 따른 부담도 분산시킬 수 있다.

도 4는 종래의 분산 쿼리 방식에 의한 JDBC(Java Database Connectivity)의 작동을 설명하기 위한 예시도이다.

도 4를 참고하면, 직원(employee)에 관한 정보가 저장된 emp 테이블에서 이름(name) 순서대로 정렬한 결과를 조회하는 과정을 볼 수 있다. 이때, 세 개의 슬레이브 서버(111-1, 111-2, 111-3)에 데이터를 분산하기 위해서 별도의 조건절(where)에 사용할 컬럼(column)으로 split 컬럼이 추가된다. 예를 들어서 오라클(oracle)에서 제공하는 rownum이나 MySql에서 제공하는 @ROWNUM과 같은 기능들이 split 컬럼이 될 수 있다. 물론 로우넘(rownum) 외에도 emp 테이블의 사번과 같은 고유키(unique key)가 split 컬럼이 될 수도 있다.

즉, 사용자는 [select * from emp order by name]와 같은 쿼리를 입력하더라도 마스터 서버(110)에서 각 슬레이브 서버(111-1, 111-2, 111-3)로 쿼리를 전송하는 과정에서, 데이터 분산을 위해 [select * from (select * from emp order by name) a where a.split >= ? and a.split < ?]와 같은 형태로 쿼리를 변환하게 된다. 각 슬레이브 서버(111-1, 111-2, 111-3)에서는 두 개의 물음표에 각각 데이터 분산을 위한 상한값과 하한값을 파라미터로 넘겨서 분산 쿼리를 실행하는 방식이다. 이하 쿼리를 표시할 때는 []로 표시하기로 한다.

각 슬레이브 서버(111-1, 111-2, 111-3)에서 파라미터로 넘겨야 할 split 컬럼의 상한값과 하한값을 구하기 위해서 마스터 서버(110)에서는 [select min(split), max(split) from (select * from emp order by name)]의 쿼리를 실행한다. 만약, split 컬럼이 rownum이라면 [select * from emp order by name]를 실행할 경우 조회되는 결과의 전체 row 수가 1부터 사원수만큼 나올 것이며, split 컬럼이 사번이라면 가장 낮은 사번부터 가장 높은 사번까지 조회될 수 있다.

이렇게 해서 얻은 split 컬럼의 최소값과 최대값 사이의 차이를 전체 슬레이브 서버의 노드 수로 나누게 되면 각 슬레이브 서버에 분산 저장되어야 할 데이터의 수가 나온다. 도 4의 예에서는 split 컬럼은 rownum이고, rownum의 최소값은 1이고 최대값은 300,000이다. 이때, 슬레이브 서버의 수는 3개 이므로 각 슬레이브 서버에 100,000개의 row가 분배되어야 한다.

즉 슬레이브 서버 1(111-1)에서는 rownum 1부터 100,000까지의 데이터가, 슬레이브 서버 2(111-2)에서는 rownum 100,001부터 200,000까지의 데이터가, 슬레이브 서버 3(111-3)에서는 rownum 200,001부터 300,000까지의 데이터가 분산 저장 되어야 한다. 각 슬레이브 서버(111-1, 111-2, 111-3)에서 기존의 JDBC(Java Database Connectivity)를 통해서 실행되는 자바 코드(JAVA code)의 예제를 살펴보면 아래의 표 1과 같은 방식으로 실행될 것이다.

// slave server 1
String sql = "select * from (select * from emp order by name) a where a.split >= ? and a.split < ?";
pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 1);
pstmt.setInt(2, 1000000);
pstmt.executeQuery();

// slave server 2
String sql = "select * from (select * from emp order by name) a where a.split >= ? and a.split < ?";
pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 1000001);
pstmt.setInt(2, 2000000);
pstmt.executeQuery();

// slave server 3
String sql = "select * from (select * from emp order by name) a where a.split >= ? and a.split < ?";
pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 2000001);
pstmt.setInt(2, 3000000);
pstmt.executeQuery();

슬레이브 서버 1(111-1)부터 슬레이브 서버 3(111-3)까지 데이터 분할을 위한 파라미터를 설정하는 부분을 자바 코드로 살펴보면, 각 슬레이브 서버(111-1, 111-2, 111-3)가 조회하여야 할 데이터의 split 컬럼의 상한값과 하한값이 파라미터로 전달되는 것을 볼 수 있다. 각 슬레이브 서버(111-1, 111-2, 111-3)는 데이터베이스(120)에서 자신이 저장해야 할 데이터를 조회한 후 이를 객체화 하고, 병렬 처리를 위한 준비를 수행하게 된다.

도 4를 참고하면, 데이터의 분할을 위해서 마스터 서버(110)에서 split 컬럼의 최대값과 최소값을 조회하고, 최대값과 최소값의 차이를 슬레이브 서버의 수로 나누는 과정이 필요하다. 또한, 각 슬레이브 서버(111-1, 111-2, 111-3)에서 자신이 저장해야 할 데이터를 데이터베이스(120)에서 조회하는 과정이 필요하다. 즉, 마스터 서버(110)가 데이터를 조회하는 과정, 슬레이브 서버(111-1, 111-2, 111-3)가 데이터를 조회하는 과정에서 데이터베이스(120)에 부하(overhead)가 집중될 수 있다.

도 5는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 작동을 설명하기 위한 예시도이다.

도 5를 참고하면, 도 4의 분산 쿼리 방식과는 다르게 각 슬레이브 서버(111-1, 111-2, 111-3)에서는 마스터 서버(110)에 접속해서 데이터를 전송 받는다. 대신 마스터 서버(110)에서 데이터베이스(120)에 접속하여 데이터를 한번만 조회한다. 이를 통해 분산 쿼리 방식에서 데이터베이스(120)에 집중되던 부하를 줄일 수 있다.

도 5를 참고하면, 마스터 서버(110)는 사용자가 입력한 쿼리 [select * from emp order by name]를 그대로 데이터베이스(120)에 실행한다. 이 경우 패치 사이즈(fetch size)가 50,000개로 설정되어 있으며, 데이터베이스(120)에서는 조회된 결과를 패치 사이즈(fetch size)만큼 나누어서 마스터 서버(110)로 전송한다.

여기서 패치 사이즈는 다음의 표 2와 같은 자바 코드를 통해서 설정이 가능하다. 본 발명에서는 각 슬레이브 서버에 한 개 이상의 바이트 블록이 분산되는 것이 바람직하므로 패치 사이즈는 전체 데이터의 수 / 슬레이브 서버의 수보다 작거나 같은 값이면 충분하다. 즉, 필요한 경우 아래의 자바 코드처럼 패치 사이즈를 전체 데이터의 수 / 슬레이브 서버의 수로 설정하는 과정이 추가될 수 있다.

ResultSet rs = stmt.executeQuery();
rs.setFetchSize(50000);

도 5를 참고하면, 총 300,000개의 데이터가 패치 사이즈만큼 바이트 블록으로 데이터베이스(120)에서 마스터 서버(110)로 전송되며, 마스터 서버(110)에서는 전송 받은 데이터 블록을 차례대로 순번을 부여한다. 즉 첫번째 바이트 블록부터 마지막 바이트 블록까지 순차적으로 1, 2, 3, 4, ... 등으로 순번을 부여한다.

우선 1번 바이트 블록을 데이터베이스(120)로부터 수신하면 이를 임시 저장 공간(Temporary Space)에 저장한 후, 슬레이브 서버 1(111-1)에 압축하여 전송한다. 다음으로 임시 저장 공간에 저장된 1번 바이트 블록을 삭제하고 커서(cursor)에서 다음 데이터를 패치(fetch)한다.

다음으로 마스터 서버(110)는 2번 바이트 블록을 임시 저장 공간에 저장한 후, 이를 압축하여 슬레이브 서버 2(111-2)에 전송하고 삭제한다. 마찬가지로 커서에서 다음 데이터를 패치(fetch)하여, 3번 바이트 블록을 임시 저장 공간에 저장한 후, 이를 압축하여 슬레이브 서버 3(111-3)에 전송하고 삭제한다.

바이트 블록에 순차적으로 번호를 부여하였으므로, 4번 바이트 블록은 다시 슬레이브 서버 1(111-1)에 전송하고, 5번 바이트 블록은 슬레이브 서버 2(111-2)에 전송하고, 6번 바이트 블록은 슬레이브 서버 3(111-3)에 전송하는 방식으로 계속해서 데이터를 분배한다.

도 5에서 볼 수 있듯이, 데이터 블록을 균등하게 분배하기 위하여 각 데이터 블록에 부여한 순번을 슬레이브 서버의 수로 나눈 나머지를 활용할 수 있다. 나머지가 1인 바이트 블록은 슬레이브 서버 1(111-1)에, 나머지가 2인 바이트 블록은 슬레이브 서버 2(111-2)에, 나머지가 0인 바이트 블록은 슬레이브 서버 3(111-3)에 순차적으로 분배할 수 있다.

물론, 이렇게 나머지를 이용하여 순차적으로 분배하는 방법 외에도 다양한 방식으로 바이트 블록을 분배할 수 있다. 예를 들면 특정 슬레이브 서버는 성능이 더 우수한 경우, 해당 슬레이브 서버에만 성능에 비례하는 가중치를 두어 더 많은 바이트 블록을 분배 받을 수 있도록 설정할 수 있다.

데이터 블록을 순차적으로 슬레이브 서버(111-1, 111-2, 111-3)에 분배하므로 전체 데이터의 양이 어느 정도인지 마스터 서버(110)에서 사전에 조회할 필요가 없다. 또한, 마스터 서버(110)에서 데이터베이스(120)에 접속해서 한 번의 쿼리의 실행으로 전체 데이터를 거의 풀 스캔(full scan) 방식으로 조회하므로, 슬레이브 서버(111-1, 111-2, 111-3)에서 각각의 쿼리를 각각 실행함으로써 발생하는 부하도 줄일 수 있다.

마스터 서버(110)는 데이터 블록을 각각의 슬레이브 서버(111-1, 111-2, 111-3)에 전송하면서, 메타 데이터(meta data)를 함께 슬레이브 서버(111-1, 111-2, 111-3)로 전송한다. 여기서 마스터 서버(110)가 슬레이브 서버(111-1, 111-2, 111-3)로 전송하는 메타 데이터는 데이터베이스(120)가 마스터 서버(110)에 전송한 것이다.

메타 데이터는 데이터베이스(120)가 전송하는 바이트에 대한 정보가 저장되어 있다. 즉 몇 번째 바이트부터 몇 번째 바이트가 하나의 로우(row)에 해당하며, 다시 하나의 로우 내에서 몇 번째 바이트부터 몇 번째 바이트가 하나의 컬럼(column)에 해당하는지에 대한 정보가 저장되어 있다. 또한 해당 컬럼의 데이터 타입(type)에 관한 정보가 저장되어 있다. 예를 들면 데이터 타입이 문자형(char, varchar, text 등)인지 숫자형(integer, float, double 등)인지에 대한 정보가 저장되어 있다.

마스터 서버(110)는 데이터 블록과 메타 데이터를 데이터베이스(120)에서 전송 받은 그대로 순차적으로 슬레이브 서버(111-1, 111-2, 111-3)에 전송하기 때문에, 슬레이브 서버(111-1, 111-2, 111-3)에서는 데이터베이스(120)에 접속해서 데이터를 조회하는 과정과 동일하게 마스터 서버(110)에 접속하여 바이트 블록을 수신하고 메타 데이터에 따라 로우를 나누고 컬럼을 나누고 데이터의 형변환을 수행하는 객체화 과정을 수행하게 된다. 즉 슬레이브 서버(111-1, 111-2, 111-3) 입장에서는 마스터 서버(110)가 가상의 데이터베이스 같은 역할을 수행하게 된다.

그러므로, 슬레이브 서버(111-1, 111-2, 111-3)에서는 마스터 서버(110)로부터 데이터 블록을 전송 받는 대로 바로 데이터 병렬 처리를 위한 객체화 과정을 수행할 수 있다. 즉 복수의 슬레이브 서버(111-1, 111-2, 111-3)에서 각각 자신이 수신한 데이터 블록을 객체화 하는 과정이 병렬적으로 수행될 수 있다. 그리고 모든 슬레이브 서버(111-1, 111-2, 111-3)에서 객체화 과정이 끝나면 맵리듀스(MapReduce)나 스파크(Spark) 등에서 분산된 데이터를 활용할 수 있다.

도 6은 종래의 단일 연결 방식에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 개념도이다.

도 6에서 좌측의 클라이언트 사이드(client side)는 데이터베이스(120)에 접속하는 마스터 서버(110)에서의 JDBC의 동작이고, 우측의 서버 사이드(server side)는 데이터베이스(120)에서의 JDBC의 동작이다. 도 6에 대한 이해를 돕기 위해 마스터 서버(110)에서의 자바 코드(JAVA code)의 예제를 살펴보면, 아래의 표 3과 같다.

// master server
String sql = " select * from emp order by name";
pstmt = conn.prepareStatement(sql);
ResultSet rs = pstmt.executeQuery();

while (rs.next()) {
String name = rs.getString(1);
...
}

도 6을 참고하면, 마스터 서버(110)가 자바의 Statement 클래스를 이용해서 쿼리를 실행하는 과정(S111)은 표 3의 예제 코드에서 "pstmt = conn.prepareStatement(sql);"에 해당한다. 쿼리를 실행하면 이에 대응해서 데이터베이스(120)에서는 커서(cursor)를 생성하고, 패치 사이즈(fetch size)만큼 데이터를 조회하여 응답을 한다(S112).

도 6을 참고하면, 마스터 서버(110)가 자바의 ResultSet 클래스를 이용해서 데이터를 가져오는 과정(S113)은 표 3의 예제 코드에서 "String name = rs.getString(1);"에 해당한다.

그리고 마스터 서버(110)에서는 "rs.next()"를 통해 계속해서 데이터를 패치(fetch) 한다(S115). 데이터베이스(120)에서는 마스터 서버(110)로 바이트와 메타 데이터를 전송(S116)하고, 마스터 서버(110)에서는 메타 데이터를 이용하여 바이트를 해석하고(S117), 이를 객체로 변환한다(S119).

다음으로 변환된 객체 데이터를 일정한 크기로 나누어 복수의 슬레이브 서버(111-1, …, 111-N)로 전송하기 위해 다시 직렬화 과정을 수행한다(S121). 마스터 서버(110)에서 복수의 슬레이브 서버로 직렬화 한 데이터를 네트워크를 통해 전송하고(S123), 전송한 후에는 전송한 데이터를 마스터 서버(110)에서 삭제한다. 슬레이브 서버에서는 데이터를 수신하고, 이를 다시 자바 객체로 변환하고 저장한다(S125).

도 6에서 살펴본 것처럼, 종래의 단일 연결 방식에서 JDBC 내부 동작에서는, 마스터 서버(110)에서 불필요한 객체화 과정(S119)과 직렬화 과정(S121) 및 반직렬화 과정(S117)을 수행한다. 이는 마스터 서버(110)가 대용량의 데이터를 각각의 슬레이브 서버에 균등하게 배분하기 위해서 필요한 과정이다.

이에 비해 본 발명에서는 마스터 서버(110)의 JDBC 내부에서 이와 같은 과정을 수행하지 않고서도 각각의 슬레이브 서버에 대용량의 데이터를 균등하게 분배하고자 한다. 이를 위해서는 종래의 JDBC의 수정이 필요하다.

즉, 본 발명의 쿼리 결과 분산 저장 방법을 수행하기 위해서는 종래의 JDBC와 다른 방식으로 작동하는 자바 커넥터(JAVA Connector)가 필요하다. 종래에는 type 1부터 type 4까지 총 4종류의 자바 커넥터가 정의되어 있다. 위키 페이지 https://en.wikipedia.org/wiki/JDBC_driver에서 자바 커넥터의 종류에 관한 자세한 정보를 확인할 수 있다.

종래의 type 1부터 type 4까지의 JDBC 드라이버는 병렬 처리가 널리 퍼지기 전에 설계된 규약이기 때문에, 병렬 처리에서는 필요하지 않은 과정들도 포함되어 있다. 이에 본 발명에서는 이러한 종래의 JDBC 드라이버를 수정하여 병렬 처리에 특화된 JDBC 드라이버를 제공하고자 한다.

도 7은 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 개념도이다.

도 7을 참고하면, 마스터 서버(110)에서 데이터베이스(120)에 대용량의 데이터를 조회하는 초기 과정(S111, S112, S113, S115, S116)은 도 6의 과정과 동일하다. 대신 마스터 서버(110)에서 데이터베이스(120)가 전송한 데이터를 수신한 후, 이를 반직렬화(deserialization) 하는 과정(S117)과 객체화 하는 과정(S119)이 변경되었다.

본 발명의 JDBC 드라이버에서는, 데이터베이스(120)가 전송한 바이트를 마스터 서버(110)가 그대로 슬레이브 서버로 전송하므로, 도 7에서는 도 6의 반직렬화(deserialization) 과정(S117)이 아예 생략된 것을 확인할 수 있다.

또한, 도 6에서 반직렬화(deserialization) 과정을 수행한 후에 이를 객체로 변환하고, 슬레이브 서버의 수에 맞추어서 데이터를 나누는 과정(S119) 대신에 도 7에서는 데이터베이스(120)에서 전송한 바이트 블록, 즉 직렬화 된 데이터를 그대로 슬레이브 서버로 전송한다.

즉, 도 6에서 데이터베이스(120)에서 전송한 바이트를 객체로 변환하고(S119), 변환된 객체를 나누고, 다시 객체를 직렬화해서 전송하는 과정(S121) 대신에 도 7에서는 데이터베이스(120)가 전송한 바이트를 그대로 슬레이브 서버로 전송하는 과정(S119a)으로 변경하였다.

그리고 도 6에서는 객체로 변환된 데이터를 네트워크를 통해 마스터 서버(110)가 슬레이브 서버로 전송했기 때문에(S123), 별도로 메타 데이터를 전송하지 않았다. 슬레이브 서버에서는 네트워크를 통해 전송 받은 직렬화 된 데이터를 네트워크 인터페이스에 따라 반직렬화 하면 바로 객체로 사용할 수 있었다(S125).

대신 도 7에서는 마스터 서버(110)가 각 슬레이브 서버로 전송하는 직렬화 된 데이터는 데이터베이스(120)가 전송한 바이트 블록 그 자체이므로, 이를 반직렬화 하기 위해서는 데이터베이스가(120)가 데이터를 바이트로 변환한 기준인 메타 데이터가 필요하다.

그러므로, 마스터 서버(110)에서는 직렬화 된 데이터를 슬레이브 서버로 전송하면서 추가로 메타 데이터를 함께 전송한다(S123a). 그리고 슬레이브 서버에서는 수신한 바이트 블록과 메타 데이터를 이용하여, 마스터 서버(110)가 전송한 직렬화 된 바이트 블록을 객체화 한다(S125).

도 6과 도 7을 비교하면, 도 6의 마스터 서버(110)에서 수행하던 객체화 과정(S119)과 반직렬화 과정(S117)을 도 7에서는 생략하여, 마스터 서버(110)에 집중되던 부하를 줄이는 것을 볼 수 있다. 즉, 본 발명의 마스터 서버(110)는 대용량의 데이터를 바로 슬레이브 서버로 전달하도록 변경된 JDBC 드라이버를 사용한다.

이상으로 종래의 대용량 데이터 분산 저장 방식과 본 발명에 따른 대용량 데이터 분산 저장 방식의 차이점을 살펴보았다. 도 6과 도 7에서 살펴본 JDBC의 내부 동작을 순서도로 살펴보면 도 8 내지 도 9와 같다.

도 8은 종래의 단일 연결 방식에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 순서도이다.

도 8에 대한 설명에 앞서, 표준 JDBC 인터페이스는 Row를 의미하는 객체가 별도로 없기 때문에, 쿼리 결과를 네트워크를 통해 전송하기 위해서는 DTO(data-transfer-object)를 정의해 주어야 한다. 도 8의 순서도에서는 List를 DTO로 사용하였다. 여기서 List1은 하나의 row에 대응하는 객체이며, List2는 여러 개의 row가 모인 table에 대응하는 객체이다.

JDBC 인터페이스(interface)에서 쿼리 결과인 ResultSet 클래스는 Iterator 방식으로 다음 결과(row)가 있을 때가지 next() 함수를 실행하여 다음 row를 가져오고, getXXX() 함수를 실행하여 특정 컬럼(column)의 데이터를 가져올 수 있다. 이는 앞서 표 3에서 살펴 본 자바 코드의 "while (rs.next()) { ... }"와 "String name = rs.getString(1);"에 해당한다.

도 8을 참고하면, 마스터 서버(110)는 데이터베이스(120)의 커서로부터 컬럼의 메타 데이터를 전송 받고, 메타 데이터를 가지는 ResultSet 클래스를 생성한다. 다음으로 패치 사이즈(fetch size)만큼 특정 row 수를 바이트 데이터로 전송 받는다. 전송된 바이트 어레이를 버퍼에 채우고, 하나씩 데이터를 패치(fetch)한다.

즉, 바이트 버퍼로부터 하나의 로우(row)를 읽은 다음 각 컬럼에 해당하는 값을 메타 데이터에 맞게 반직렬화 하여 List1에 추가하고 다음 컬럼을 읽어 나간다. 만약 모든 컬럼을 다 읽었다면 List1를 List2에 추가하고, 다음 로우(row)를 읽어서 다시 읽은 다음 로우의 컬럼의 값을 가져오는 과정을 반복해서 수행한다.

만약 모든 로우를 다 읽었다면, 다시 말해서 데이터베이스(120)로부터 수신한 바이트 버퍼가 남아있지 않다면, List2를 직렬화 하여 마스터 서버(110)의 로컬 디스크에 저장하고, 다음 패치 사이즈만큼 커서에서 데이터를 가져온다.

만약 커서에서 모든 데이터를 다 가져왔다면, 커서는 닫힌 상태이고, 이는 모든 데이터를 다 읽어서 객체화 하여 마스터 서버(110)의 로컬 디스크에 저장했다는 뜻이 된다. 디스크에 저장된 전체 데이터를 슬레이브 서버의 수만큼 균등하게 나눈 후 각 슬레이브 서버로 전송하고, 각 슬레이브 서버에서는 마스터 서버(110)가 전송한 직렬화 된 데이터를 수신하여 반직렬화 하여 List2의 객체로 복원한다.

도 8에서 볼 수 있듯이, 데이터베이스(120)에 생성된 커서(cursor)에서 패치 사이즈만큼 데이터를 읽는 과정과, 읽은 바이트를 로우로 나누는 과정과, 로우로 나눈 바이트를 컬럼으로 나누는 과정을 모든 데이터에 대해서 반복 수행하게 된다. 이로 인해 마스터 서버(110)에 부하가 집중되며, 리소스의 소모가 발생하게 된다.

도 9는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법에 의한 JDBC(Java Database Connectivity)의 내부 동작을 설명하기 위한 순서도이다.

본 발명에서는 병렬 처리에 사용할 수 있는 별도의 JDBC를 생성하여 이를 사용한다. 만약 들어온 요청이 병렬 처리를 필요로 하지 않는 경우에는 종래의 type 1 내지 type 4의 표준 JDBC 드라이버를 이용하여 데이터를 가져올 수 있고, 병렬 처리를 필요로 하는 경우에는 본 발명에서 제공하는 별도의 JDBC 드라이버를 사용할 수 있다.

본 발명이 제공하는 별도의 JDBCD 드라이버는 마스터 서버(110) 입장에서는 단일 연결 방식과 유사하게 마스터 서버(110)가 데이터베이스(120)에 직접 연결하여 데이터를 가져오되 이를 바로 슬레이브 서버로 전달한다. 대신 마스터 서버(110)에서는 전체 슬레이브 서버의 수를 이용하여 바이트 블록을 분배한다.

도 5에서 살펴본 것처럼 슬레이브 서버 1(111-1)에는 1, 4, 7처럼 전체 슬레이브 서버의 수인 3으로 나누었을 때 나머지가 1인 바이트 블록만 전송되고, 슬레이브 서버 2(111-2)에는 2, 5처럼 전체 슬레이브 서버의 수인 3으로 나누었을 때 나머지가 2인 바이트 블록만 전송되고, 슬레이브 서버 3(111-3)에는 3, 6처럼 전체 슬레이브 서버의 수인 3으로 나누었을 때 나머지가 0인 바이트 블록만 전송된다.

즉 마스터 서버(110)는 A + n * B 의 수식으로 바이트 블록을 분배한다. 여기서 B는 전체 슬레이브 서버의 수이며, A는 현재 바이트 블록을 분배하여야 할 랜덤 순번에 해당한다. 즉, 앞서 도 5의 예와 같이 전체 슬레이브 수 B로 나눈 나머지에 해당한다.

그리고, 슬레이브 서버 입장에서는 분산 쿼리 방식과 유사하게 슬레이브 서버가 각각 자신이 처리해야 할 데이터를 가져와서 객체화 하는 과정을 수행한다.

대신 슬레이브 서버가 직접 데이터베이스(120)에 연결하는 대신 마스터 서버(110)를 가상의 데이터베이스처럼 취급하여 마스터 서버(110)에 접속한다. 이를 통해 데이터베이스(120)가 마스터 서버(110)로 전송한 바이트 블록과 메타 데이터를 다시 마스터 서버(110)가 슬레이브 서버롤 바로 전송한다.

슬레이브 서버는 종래의 분산 쿼리 방식처럼 가상의 데이터베이스(=마스터 서버)에 접속하여 자신이 처리하여야 할 데이터의 바이트 블록을 수신하므로, 종래의 분산 쿼리 방식으로 구성된 소스에 약간의 수정만 적용하면 본 발명의 쿼리 결과 분산 저장 방법을 이용하도록 재사용 할 수 있다.

즉, 분산 쿼리 방식에서 슬레이브 서버가 사용하는 JDBC를 본 발명에서 개선한 JDBC로 교체하는 것만으로도, 슬레이브 서버는 전송 받은 바이트 블록을 메타 데이터를 이용하여 객체화 할 수 있다. 이 과정은 복수의 슬레이브 서버에서 병렬적으로 수행할 수 있다.

도 9에서 살펴본 것처럼 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법은 마스터 서버(110)의 입장에서는 단일 연결 방식의 장점을, 슬레이브 서버의 입장에서는 분산 쿼리 방식의 장점을 각각 흡수하여 만든 방법이다. 이를 통해 데이터베이스(120)나 마스터 서버(110)에 집중되는 부하를 줄이고, 슬레이브 서버로 부하를 분산시킬 수 있다.

도 10 및 도 11a 내지 도 11b는 본 발명의 일 실시 예에 따른 쿼리 결과 분산 저장 방법의 효과를 설명하기 위한 예시도이다.

도 10을 참고하면 본 발명에서 제한하는 쿼리 결과 분산 저장 방법이 어느 단계에서 적용될 수 있는 방법인지 확인할 수 있다.

대용량의 데이터가 저장된 관계형 데이터베이스 관리 시스템(RDBMS; Relational Database Management System), 즉 레가시(Legacy) 영역에서 데이터를 추출하고 이를 복수의 분산 서버에 저장하는 단계에서 본 발명을 적용할 수 있다.

Brightics 영역은 자사의 대용량 데이터 분석 솔루션이다. 분산 서버에 데이터를 나누어서 저장한 후에는, Brightics 영역에서 빅데이터 머신 러닝, 통계 분석 등을 수행하여 대용량의 데이터를 분석할 수 있다. 분석 결과는 다시 데이터베이스에 저장할 수도 있고, Brightics 영역의 자체 BI 툴을 통하여 사용자에게 시각적으로 제공될 수도 있다.

본 발명의 쿼리 결과 분산 저장 방식은 도 10에서 어두운 색상으로 표시된 과정인 데이터베이스에 저장된 대용량의 데이터를 로드하고 복수의 분산 서버에 나누어서 저장하는 과정에서 활용될 수 있는 발명이다. 종래의 JDBC 드라이버에 대신 본 발명의 개선된 JDBC 드라이버를 이용할 경우 상당한 성능 향상을 꾀할 수 있다.

도 11a를 참고하면, 총 5백만 건의 대용량의 데이터를 10개의 분산 서버에 나누어서 저장하는 과정에서 소모된 시간을 종래의 JDBC 드라이버를 이용한 경우와 본 발명의 개선된 JDBC 드라이버를 이용한 경우를 비교한 그래프를 확인할 수 있다.

도 11a를 참고하면 총 5번의 시도동안 종래의 JDBC 드라이버를 이용하는 경우에는 9645ms, 9630ms, 9225ms, 9440ms, 9950ms의 시간이 소모되어, 평균 9570ms 만큼의 시간이 걸렸다. 이에 비해 본 발명의 개선된 JDBC 드라이버를 이용하는 경우에는 960ms, 965ms, 940ms, 930ms, 985ms의 시간이 소모되어, 평균 956ms 만큼의 시간이 걸렸다. 대략 총 수행 시간이 90% 가까이 비약적으로 감소한 것을 확인할 수 있다.

다음으로 도 11b를 참고하면, 총 5백만 건의 대용량의 데이터를 10개의 분산 서버에 나누어서 저장하는 과정에서 마스터 서버에 필요한 저장 용량을 종래의 JDBC 드라이버를 이용한 경우와 본 발명의 개선된 JDBC 드라이버를 이용한 경우를 비교한 그래프를 확인할 수 있다.

도 11b를 참고하면, 종래의 JDBC 드라이버를 이용하는 경우 마스터 서버는 약 240,235KB의 저장 공간을 필요로 한다. 즉 약 240MB의 저장 공간이 마스터 서버에 필요하다. 이에 비해 본 발명의 개선된 JDBC 드라이버를 이용하는 경우에는 약 140,625KB의 저장 공간, 즉 약 141MB의 저장 공간으로도 충분하다. 필요로 하는 저장 공간이 40% 가량 감소한 것을 확인할 수 있다. 이는 네트워크 트래픽의 감소로 이어질 수 있다.

다음으로 도 11c를 참고하면, 총 5백만 건의 대용량의 데이터를 10개의 분산 서버에 나누어서 저장하는 과정에서 마스터 서버에 필요한 메모리 용량을 종래의 JDBC 드라이버를 이용한 경우와 본 발명의 개선된 JDBC 드라이버를 이용한 경우를 비교한 그래프를 확인할 수 있다.

도 11c를 참고하면, 종래의 JDBC 드라이버를 이용하는 경우 마스터 서버는 약 172,673,232B의 메모리 용량을 읽기 과정에서 필요로 한다. 즉 약 173MB의 메모리 용량이 읽기 과정에서 마스터 서버에 필요하다. 이에 비해 본 발명의 개선된 JDBC 드라이버를 이용하는 경우에는 약 34,001,360B의 메모리 용량, 즉 약 34MB의 메모리 용량으로도 읽기 과정이 충분하다. 읽기 과정에서 필요로 하는 메모리 용량이 90% 가량 감소한 것을 확인할 수 있다.

또한, 도 11c를 참고하면, 종래의 JDBC 드라이버를 이용하는 경우 마스터 서버는 약 353,557,496B의 메모리 용량을 쓰기 과정에서 필요로 한다. 즉 약 354MB의 메모리 용량이 쓰기 과정에서 마스터 서버에 필요하다. 이에 비해 본 발명의 개선된 JDBC 드라이버를 이용하는 경우에는 약 30,507,520B의 메모리 용량, 즉 약 31MB의 메모리 용량으로도 쓰기 과정이 충분하다. 쓰기 과정에서 필요로 하는 메모리 용량이 80% 가량 감소한 것을 확인할 수 있다.

도 11a 내지 도 11c에서 살펴본 것처럼, 본 발명의 개선된 JDBC 드라이버를 이용할 경우 마스터 서버에 필요로 하는 리소스의 양도 종래의 JDBC 방법에 비해 줄고, 총 수행 시간도 단축시킬 수 있는 효과가 있다. 이를 통해 동시 사용자를 고려한 서비스 형태의 빅데이터 어플리케이션에도 적용이 가능하다.

이상 첨부된 도면을 참조하여 본 발명의 실시예들을 설명하였지만, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.

Claims

마스터 서버가, 데이터를 조회하기 위한 쿼리(query)를 데이터베이스(database)에서 실행하는 단계;
상기 마스터 서버가, 상기 실행의 결과로 상기 데이터에 관한 메타 데이터(meta data) 및 상기 데이터를 구성하는 제1 일부 데이터를 상기 데이터베이스로부터 직렬화(serialization) 된 상태로 제공 받는 단계;
상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계; 및
상기 제1 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항에 있어서,
상기 마스터 서버가, 상기 데이터가 병렬 처리가 필요한 대용량 데이터인지 판단하고,
상기 마스터 서버가, 상기 데이터가 병렬 처리가 필요한 것으로 판단한 경우에, 상기 실행하는 단계와 상기 제공 받는 단계와 상기 분배하는 단계를 수행하는 것인,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항에 있어서,
상기 데이터를 조회하기 위한 쿼리(query)를 데이터베이스(database)에서 실행하는 단계는,
상기 마스터 서버가, 상기 데이터를 패치 사이즈(fetch size)에 따라 일부 데이터로 나누어서 조회하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 실행의 결과로 상기 데이터에 관한 메타 데이터(meta data) 및 상기 데이터를 구성하는 제1 일부 데이터를 상기 데이터베이스로부터 직렬화(serialization) 된 상태로 제공 받는 단계는,
상기 마스터 서버가, 상기 데이터베이스로부터 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 임시 저장 공간(temporary space)에 저장하는 단계를 포함하고,
상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계는,
상기 마스터 서버가, 상기 제1 슬레이브 서버에 분배한 상기 제1 일부 데이터를 상기 임시 저장 공간에서 삭제하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제1 일부 데이터를 그대로 제1 슬레이브 서버에 분배(distribution)하는 단계는,
상기 마스터 서버가, 상기 분배하는 단계 이전에 상기 제1 일부 데이터를 압축(compress)하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는,
상기 제1 슬레이브 서버가, 상기 마스터 서버를 가상의 데이터베이스(virtual database)로 하는 가상 연결(virtual connection)을 생성하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는,
상기 제1 슬레이브 서버가, 상기 반직렬화의 결과로 상기 일부 데이터에 대응되는 객체(object)를 생성하는 단계 및;
상기 제1 슬레이브 서버가, 상기 생성된 객체를 상기 제1 슬레이브 서버의 로컬 디스크에 저장하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제2 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계;
상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제2 일부 데이터를 그대로 제2 슬레이브 서버에 분배하는 단계; 및
상기 제2 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제2 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함하는,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제m 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계;
상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제m 일부 데이터를 그대로 제m 슬레이브 서버에 분배하는 단계; 및
상기 제m 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제m 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함하되,
상기 m은 슬레이브 서버의 총 개수인,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버가, 상기 실행의 결과로 상기 메타 데이터 및 상기 데이터를 구성하는 제k 일부 데이터를 상기 데이터베이스로부터 직렬화 된 상태로 제공 받는 단계;
상기 마스터 서버가, 상기 메타 데이터 및 직렬화 된 상태로 제공 받은 상기 제k 일부 데이터를 그대로 제k' 슬레이브 서버에 분배하는 단계; 및
상기 제k' 슬레이브 서버가, 상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제k 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계를 더 포함하되,
상기 k'는 상기 k의 값을 m으로 나눈 나머지이되, 상기 나머지가 0인 경우에는 상기 k'는 상기 m의 값과 동일한 값을 가지고,
상기 m은 슬레이브 서버의 총 개수인,
쿼리 결과 분산 저장 방법.
제1항 또는 제2항 에 있어서,
상기 마스터 서버가, 상기 실행하는 단계와 상기 제공 받는 단계와 상기 분배하는 단계를 JDBC(Java Database Connectivity)를 이용하여 수행하고,
상기 제1 슬레이브 서버가, 상기 반직렬화(deserialization)하는 단계를 상기 JDBC(Java Database Connectivity)를 이용하여 수행하고,
상기 JDBC는 기존의 type 1 내지 type 4의 JDBC를 수정한 JDBC인,
쿼리 결과 분산 저장 방법.
제3항에 있어서,
상기 데이터를 패치 사이즈(fetch size)에 따라 일부 데이터로 나누어서 조회하는 단계는,
상기 마스터 서버가, 상기 데이터의 총 로우(row) 수를 슬레이브 서버의 총 개수로 나눈 값보다 작거나 같은 값으로 상기 패치 사이즈를 설정하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.
제6항에 있어서,
상기 마스터 서버로부터 직렬화 된 상태로 분배 받은 상기 제1 일부 데이터를 상기 메타 데이터를 이용하여, 반직렬화(deserialization)하는 단계는,
상기 제1 슬레이브 서버가, 상기 반직렬화하는 단계 이전에 상기 제1 일부 데이터의 압축을 해제(decompress)하는 단계를 포함하는,
쿼리 결과 분산 저장 방법.