KR102668905B1 - 서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치 - Google Patents

Abstract

본 발명은 서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치에 관한 것이다. 데이터 처리 시스템에서 서버 마이그레이션 방법은 데이터 처리 시스템이 기존 서버의 마이그레이션 데이터를 백업하고 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계와 데이터 처리 시스템이 마이그레이션 데이터를 기반으로 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계를 포함할 수 있다.

Description

서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치{Method for migration of workspace and apparatus for performing the method}

본 발명은 서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치에 관한 것이다. 보다 상세하게는 기존 서버를 다른 서버로 마이그레이션하기 위한 서버 마이그레이션 방법 및 이러한 방법을 수행하는 장치에 관한 것이다.

급속한 비대면 환경과 모바일 우선 전략에 따라 해마다 많은 정형 데이터 및 비정형 데이터의 폭발적인 증가와 생성은 모든 분야에서 빅데이터를 활용한 새로운 의사 결정과 서비스를 요구하고 있다.

이와 같이 데이터의 급격한 증가와 소비는 향후 더욱 가속화될 예정이며, 이러한 정형 데이터뿐만 아니라, 비정형 데이터에 포함되어 있는 다양한 패턴들을 수집하고 정제하고 분석하여 미래의 성장동력을 찾는 것이 기업들의 새로운 비즈니스 모델이 되고 있다.

기존 선행 기술로는 국내출원번호10-2014-0036626건이 있다.

본 발명은 상술한 문제점을 모두 해결하는 것을 그 목적으로 한다.

또한, 본 발명은, 비정형 데이터와 정형 데이터를 하나의 플랫폼 및 데이터베이스 상에서 처리하는 데이터 처리 시스템에서 기존 서버를 다른 서버로 마이그레이션하기 위한 방법을 제공하는 것을 목적으로 한다.

또한, 본 발명은, 사용자의 마이그레이션 요청 및 마이그레이션 명세(specification)에 따라 기존 서버를 다른 서버로 마이그레이션하기 위한 방법을 제공하는 것을 목적으로 한다.

상기 목적을 달성하기 위한 본 발명의 대표적인 구성은 다음과 같다.

본 발명의 일 실시예에 따르면, 데이터 처리 시스템에서 서버 마이그레이션 방법은, 데이터 처리 시스템이 기존 서버의 마이그레이션 데이터를 백업하고 상기 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계와 상기 데이터 처리 시스템이 상기 마이그레이션 데이터를 기반으로 상기 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계를 포함할 수 있다.

한편, 상기 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계는 서버 마이그레이션 센더가 상기 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성하는 단계, 상기 서버 마이그레이션 센더가 상기 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달하는 단계, 상기 스토리지 해시 인코더가 상기 서버 마이그레이션 데이터를 해시화하는 단계, 상기 스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송하는 단계와 상기 템포러리 마이그레이션 스토리지가 상기 마이그레이션 서버의 서버 마이그레이션 리시버로 상기 해시화된 마이그레이션 데이터를 전송하는 단계를 포함할 수 있다.

또한, 상기 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계는 스토리지 해시 디코더가 상기 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터로 변환하는 단계, 상기 스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터를 생성하는 단계와 워크스페이스 스포너가 상기 스토리지 및 상기 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 상기 마이그레이션 서버 상에 생성하는 단계를 포함할 수 있다.

본 발명의 다른 실시예에 따르면, 서버 마이그레이션을 수행하는 데이터 처리 시스템은 기존 서버의 마이그레이션 데이터를 백업하고 상기 마이그레이션 데이터를 마이그레이션 서버로 전송하고, 상기 마이그레이션 데이터를 기반으로 상기 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하도록 구현될 수 있다.

한편, 상기 데이터 처리 시스템은 서버 마이그레이션 센더가 상기 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성하고, 상기 서버 마이그레이션 센더가 상기 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달하고, 상기 스토리지 해시 인코더가 상기 서버 마이그레이션 데이터를 해시화하고, 상기 스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송하고, 상기 템포러리 마이그레이션 스토리지가 상기 마이그레이션 서버의 서버 마이그레이션 리시버로 상기 해시화된 마이그레이션 데이터를 전송하도록 구현될 수 있다.

또한, 상기 데이터 처리 시스템은 스토리지 해시 디코더가 상기 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터로 변환하고, 상기 스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터를 생성하고, 워크스페이스 스포너가 상기 스토리지 및 상기 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 상기 마이그레이션 서버 상에 생성하도록 구현될 수 있다.

본 발명에 의하면, 비정형 데이터와 정형 데이터를 하나의 플랫폼 및 데이터베이스 상에서 처리하는 데이터 처리 시스템에서 기존 서버를 다른 서버로 마이그레이션하기 위한 방법이 제공될 수 있다.

또한, 본 발명에 의하면, 서버 마이그레이션 요청 및 서버 마이그레이션 명세(specification)에 따라 기존 서버를 다른 서버로 마이그레이션하기 위한 방법이 제공될 수 있다.

도 1은 기존 데이터 처리 시스템을 나타낸 개념도이다.
도 2는 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 3은 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.
도 4는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 5는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.
도 6은 본 발명의 실시예에 따른 데이터 처리 시스템을 기반으로 한 데이터 처리 방법을 나타낸 개념도이다.
도 7은 본 발명의 실시예에 따른 데이터 처리 시스템에서 쿼리를 분석하여 데이터를 처리하는 방법을 나타낸 개념도이다.
도 8은 본 발명의 실시예에 따른 자원 분배 알고리즘을 나타낸 개념도이다.
도 9는 본 발명의 실시예에 따른 입력 멀티-쿼리(input multi-query)를 처리하는 데이터 처리 시스템을 나타낸 개념도이다.
도 10은 본 발명의 실시예에 따른 멀티-쿼리 스케줄러의 동작을 나타낸 개념도이다.
도 11은 본 발명의 실시예에 따른 입력 멀티-쿼리를 처리하는 방법을 나타낸 개념도이다.
도 12는 본 발명의 실시예에 따른 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하는 서버를 나타낸 개념도이다.
도 13은 본 발명의 실시예에 따른 공유 워크스페이스 허브의 쿼리 처리 방법을 나타낸 개념도이다.
도 14는 본 발명의 실시예에 따른 자원 분배 방법을 나타낸 개념도이다.
도 15는 본 발명의 실시예에 따른 비정형 데이터에 대한 비정형 임베딩 방법을 나타낸 개념도이다.
도 16은 본 발명의 실시예에 따른 비정형 데이터에 대한 비정형 임베딩 방법을 나타낸 개념도이다.
도 17은 본 발명의 실시예에 따른 컨버트 구문 및 서치 구문을 사용한 결과를 나타낸 개념도이다.
도 18은 본 발명의 실시예에 따른 임베딩값을 바이너리화하기 위한 방법을 나타낸 개념도이다.
도 19는 본 발명의 실시예에 따른 바이너리화에 대한 예시이다.
도 20은 본 발명의 실시예에 따른 임베딩값 또는 바이너리값으로 저장하기 위한 방법이 개시된다.
도 21은 본 발명의 실시예에 따른 워크스페이스 백업 방법을 나타낸 개념도이다.
도 22는 본 발명의 실시예에 따른 워크스페이스 백업 방법을 나타낸 순서도이다.
도 23은 본 발명의 실시예에 따른 서버 백업 방법을 나타낸 개념도이다.
도 24는 본 발명의 실시예에 따른 서버 백업 방법을 나타낸 순서도이다.
도 25는 본 발명의 실시예에 따른 워크스페이스 마이그레이션 방법을 나타낸 개념도이다.
도 26은 본 발명의 실시예에 따른 워크스페이스 마이그레이션 방법을 나타낸 순서도이다.
도 27은 본 발명의 실시예에 따른 서버 마이그레이션 방법을 나타낸 개념도이다.
도 28은 본 발명의 실시예에 따른 서버 마이그레이션 방법을 나타낸 순서도이다.
도 29는 본 발명의 실시예에 따른 비정형 모델 캐싱 방법을 나타낸 개념도이다.
도 30은 본 발명의 실시예에 따른 제1 캐싱 알고리즘을 나타낸 개념도이다.
도 31은 본 발명의 실시예에 따른 비정형 모델 캐싱 방법을 나타낸 개념도이다.

후술하는 본 발명에 대한 상세한 설명은, 본 발명이 실시될 수 있는 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이러한 실시예는 당업자가 본 발명을 실시할 수 있기에 충분하도록 상세히 설명된다. 본 발명의 다양한 실시예는 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 본 명세서에 기재되어 있는 특정 형상, 구조 및 특성은 본 발명의 정신과 범위를 벗어나지 않으면서 일 실시예로부터 다른 실시예로 변경되어 구현될 수 있다. 또한, 각각의 실시예 내의 개별 구성요소의 위치 또는 배치도 본 발명의 정신과 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 행하여 지는 것이 아니며, 본 발명의 범위는 특허청구범위의 청구항들이 청구하는 범위 및 그와 균등한 모든 범위를 포괄하는 것으로 받아들여져야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 구성요소를 나타낸다.

이하에서는, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 하기 위하여, 본 발명의 여러 바람직한 실시예에 관하여 첨부된 도면을 참조하여 상세히 설명하기로 한다.

도 1은 기존 데이터 처리 시스템을 나타낸 개념도이다.

도 1에서는 기존에 정형 데이터와 비정형 데이터를 처리하는 데이터 처리 시스템이 개시된다.

도 1을 참조하면, 기존 데이터 처리 시스템의 정형 데이터(100) 및 비정형 데이터(120)에 대한 데이터 처리 방식이 개시된다.

정형 데이터(100)는 스키마에 따라 테이블에 저장되고 관계를 통해 테이블 간에 연결이 가능한 데이터이다. 정형 데이터(100)는 보유하고 있는 정보에 대한 적절히 정의된 스키마를 가지고 행과 열로 표시될 수 있다. 각 열은 다른 속성을 나타내는 반면, 각 행에는 단일 인스턴스의 속성과 연결된 데이터가 있다. 행과 열은 쉽게 참조할 수 있는 테이블을 형성할 수 있고, 서로 다른 테이블들은 연결될 수 있고, 여러 테이블이 연속적으로 연결되어 있으면 관계형 데이터베이스(140)가 형성될 수 있다.

비정형 데이터(120)는 정형 데이터(100)와 반대되는 데이터이고, 정해진 규칙이 없어서 값의 의미를 쉽게 파악하기 힘든 데이터로서 음성, 이미지, 영상과 같은 데이터를 포함할 수 있다.

기존 데이터 처리 시스템은 SQL(structured query language)을 기반으로 정형 데이터(100)에 대한 쿼리만이 가능하였고, 비정형 데이터(120)에 대한 처리를 위해서는 특정 스키마가 없는 NoSQL 데이터베이스가 사용되었다.

또한, 기존의 데이터 처리 시스템은 정형 데이터(100)에 대한 실시간 쿼리가 가능하였으나, 비정형 데이터(120)에 대한 실시간 쿼리가 불가능하였다. 기존 데이터베이스 처리 시스템에서 비정형 데이터(120)는 실시간 처리(real time processing) 대신 배치 처리(batch processing)을 통해 처리되었다. 이로 인해, 기존의 데이터 처리 시스템에서 이미지, 영상, 음성에 대한 실시간 검색이 불가하였다. 보다 구체적으로 기존의 데이터 처리 시스템에서 비정형 데이터(120)는 대량의 데이터를 실시간으로 분석하기 어렵다. 따라서, 실시간으로 획득이 가능한 데이터 테이블과 정해진 시간에 계산을 미리 해놓은 배치(Batch) 테이블을 결합하는 람다 아키텍처(150) 기반의 처리가 수행되었고, 정형 데이터(100)와 비정형 데이터(120)가 별도의 DMBS(database management system)를 기반으로 처리되었다.

또한, 기존의 데이터 처리 시스템은 비정형 데이터(120)에 대한 배치 프로세싱을 위해 다양한 파이프라인, 다양한 프레임워크, 다양한 언어를 사용하였다. 따라서, 하나의 가버넌스를 기반으로 한 데이터의 처리가 불가능하였고, 개발 이후 유지 보수가 어려웠다.

또한, 기존의 데이터 처리 시스템에서 비정형 데이터(120)에 대한 학습을 위해서는 데이터베이스 내에서의 인공 지능 학습이 불가하였다. 기존의 데이터 처리 시스템은 정형 데이터(100)에 대한 학습을 데이터베이스에 구현된 AI 엔진을 기반으로 수행하였으나, 비정형 데이터(120)에 대한 학습은 데이터베이스 내에서 SQL 기반으로 처리되지 않았기 때문에 데이터베이스 안에서 비정형 데이터를 기반으로 한 AI 엔진 모델링은 불가능하였다.

또한, 기존의 데이터 처리 시스템은 AI 엔진에 대한 모델링을 수행시 운영계의 모수 테이블에서 샘플링을 통해 샘플 테이블(160)을 생성하여 모델링을 수행하게 되고, 모델링을 수행하는 모델링 플랫폼과 실제 운영을 수행하는 운영 플랫폼이 서로 상이하다. 이러한 경우, 모델링 플랫폼과 운영 플랫폼의 차이로 인해 모델링 결과가 정확하지 않은 문제점이 발생된다.

기존 데이터 처리 시스템에서는 샘플 데이터를 활용하여 AI 모델링 하는 데까지 정말 많은 시간이 소요된다.

기존 데이터 처리 시스템에서는 모수 테이블에서 샘플 데이터를 추출해오는 과정이 수행된다. 모수 데이터가 테이블 형태가 아닌 다양한 형태로 존재할 수 있기 때문에 데이터를 변형 및 추출해오는 과정에서 시간이 소요되고, 또 모델링 하기 위해 데이터를 전처리 하는 과정에서도 상당한 시간이 요구된다.

또한, 기존 데이터 처리 시스템의 AI 모델링 과정에서 샘플 데이터는 정형과 비정형 데이터를 모두 포함하고 있고 정형/비정형 AI모델링을 하기 위해 기존 데이터 처리 시스템에서는 람다 아키텍처를 필수로 적용해야 한다. 람다 아키텍처를 통해서 개발을 하게 된다면 다양한 플랫폼과 언어를 사용하게 되는데 플랫폼 간의 특성 차이, 연동 문제 등으로 접목시키는데 시간을 많이 허비하게 된다.

이뿐만 아니라, 모수 테이블에서 데이터를 추출하고 람다 아키텍처 상에서 AI 모델링을 하는 동안 모수 테이블/데이터에 실시간으로 새로운 데이터들이 쌓이게 되는데 그렇게 되면 기존 데이터 처리 시스템에서 만들어진 AI 모델을 적용했을 때 예측 결과(모델의 결과 값)가 정확하지 않다는 문제점이 있다. 그렇다면 다시 한번 모델링을 하기 위해서 1번 프로세스와 2번 프로세스를 거치는 등 많은 시간이 소요된다.

본 발명의 실시예에 따른 데이터 처리 시스템이 사용되는 경우, 모수 데이터가 하나의 형태(테이블)로 관리되고, 샘플 데이터를 추출해 오는 과정도 간단한 쿼리문을 통해 가능하고 람다 아키텍처를 필요로 하지 않기 때문에 정형 데이터 및 비정형 데이터에 대한 AI 모델링 또한 하나의 플랫폼과 하나의 언어를 사용하여 연동 문제없이 쉽게 프로세스 할 수 있다는 장점이 있다.

따라서, 본 발명의 실시예에 따른 데이터 처리 플랫폼은 하나의 플랫폼을 기반으로 하나의 언어를 기초로 정형 데이터(100)와 비정형 데이터(120)를 처리할 수 있다.

또한, 본 발명의 실시예에 따른 데이터 처리 플랫폼은 하나의 플랫폼 상에 운영 플랫폼과 모델링 플랫폼이 위치하여 보다 정확한 모델링이 가능할 뿐만 아니라, 별도의 배치 프로세싱 없이 정형 데이터(100) 및 비정형 데이터(120)를 기반으로 한 AI 모델링 기능을 제공할 수 있다.

이하, 보다 구체적인 본 발명의 실시예에 따른 데이터 처리 플랫폼의 기능이 개시된다.

도 2는 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.

도 2에서는 정형 데이터 및 비정형 데이터를 하나의 플랫폼 상에서 처리하기 위한 데이터 처리 시스템이 개시된다.

도 2를 참조하면, 데이터 처리 시스템은 비정형 데이터(220)와 정형 데이터(210)를 하나의 플랫폼 상에서 처리 가능하다. 본 발명에서는 비정형 데이터(220)를 정형 데이터(210)와 함께 하나의 플랫폼에서 처리하기 위한 데이터 처리 신택스(syntax)가 새롭게 정의되고, 새롭게 정의된 데이터 처리 신택스의 사용이 가능한 확장(extended) SQL(240)이 정의될 수 있다.

정형 데이터(210)에 대한 일반 쿼리는 PostgreSQL과 같은 기존의 SQL을 기반으로 처리되고 비정형 데이터에 대한 쿼리는 본 발명에서 새롭게 정의된 확장 SQL(240)을 기반으로 처리될 수 있다.

확장 SQL(240) 상에서 새롭게 정의된 데이터 처리 신택스를 처리하기 위한 확장 SQL 엔진(250)이 정의될 수 있다. 확장 SQL 엔진(250)은 새롭게 정의된 데이터 처리 신택스를 처리 가능하도록 하기 위한 엔진일 수 있다.

기존의 데이터 처리 시스템과 다르게 확장 SQL 엔진(250)을 기반으로 네스티드 쿼리(nested query)(230)가 가능하다. 네스티드 쿼리(230)는 정형 데이터(210) 및 비정형 데이터(220)에 대한 혼합적인 쿼리로서 데이터베이스에 저장된 정형 데이터(210)와 비정형 데이터(220)에 대한 순차적인 처리 또는 복합적인 처리를 가능하게 할 수 있다.

즉, 기존에 정형 데이터(210)와 비정형 데이터(220)가 별도의 DMBS(database management system)를 기반으로 처리되는 것과 다르게 본 발명에서는 정형 데이터(210)와 비정형 데이터(220)가 하나의 플랫폼 상에서 확장 SQL 엔진(250)을 기반으로 처리되고, 네스티드 쿼리(nested query)(230)를 기반으로 정형 데이터(210)와 비정형 데이터(220)에 대한 데이터 프로세싱이 하나의 데이터 베이스(260) 상에서 동시에 이루어질 수 있다. 이를 기반으로 정형 데이터(210)와 비정형 데이터(220)에 대한 AI 모델링도 데이터 처리 시스템의 AI 엔진(270) 상에서 이루어진다.

AI 엔진은 분류 모델, 회귀 모델, 추천 모델, 음성 인식 모델 등 다양한 AI 엔진이 미리 제공될 수도 있고, 사용자가 직접 생성한 모델, 오픈 소스로 제공되는 AI 엔진 등 제한 없이 사용될 수 있다.

본 발명의 데이터 처리 시스템은 비정형 데이터(220)에 대한 별도의 배치 프로세싱, 별도의 언어, 별도의 플랫폼 없이 하나의 플랫폼 내에서 처리 가능하다. 본 발명의 데이터 처리 시스템은 정형 데이터(210)와 비정형 데이터(220) 모두 SQL 만으로 쿼리 가능하고 정형 데이터(210)와 비정형 데이터(220)에 대한 AI 모델링을 가능하게 하는 통합 플랫폼이다. 따라서 모델링 플랫폼과 운영 플랫폼이 동일하므로 모수가 달라져서 모델링의 정확도가 떨어지는 문제도 줄어들 수 있다.

또한, 본 발명의 데이터 처리 시스템은 RDB(relational database), AI 그리고 빅데이터 플랫폼(big data platform)의 기능을 하나의 플랫폼에서 적용할 수 있으며 AI 기반의 디지털 전환시 발생하는 비효율성을 획기적으로 줄일 수 있고, 빅데이터 처리 및 분산 병렬 처리 기술을 기반으로 하여 기존 대비 2배 이상 빠른 데이터 처리를 가능하게 한다.

즉, 본 발명의 실시예에 따르면, 데이터베이스 상에서 정형 데이터와 비정형 데이터를 처리하는 방법은 데이터 처리 시스템이 네스티드 쿼리를 수신하는 단계와 데이터 처리 시스템이 네스티드 쿼리에 대한 처리를 수행하는 단계를 포함할 수 있다. 네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리일 수 있다.

네스티드 쿼리에 대한 처리를 수행하는 단계는, 데이터 처리 시스템이 확장된 SQL(extended structured query language)을 처리하는 확장 SQL 엔진을 기반으로 비정형 데이터에 대한 처리를 수행하는 단계와 데이터 처리 시스템이 PostgreSQL(extended structured query language)을 처리하는 일반 SQL 엔진을 기반으로 정형 데이터에 대한 처리를 수행하는 단계를 포함할 수 있다.

데이터 처리 시스템은 정형 데이터에 대한 데이터 테이블 및 비정형 데이터에 대한 데이터 테이블을 생성하여 하나의 데이터베이스 상에서 처리하고, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 엔진 모델링을 하나의 데이터베이스 상에서 지원할 수 있다.

또한, 본 발명의 실시예에 따르면, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터 각각에 대한 개별적인 처리를 수행할 수도 있다. 데이터 처리 시스템은 비정형 데이터 처리 쿼리 및 정형 데이터 처리 쿼리를 수신하고, 비정형 데이터 처리 쿼리 및 정형 데이터 처리 쿼리를 처리하도록 구현될 수 있다. 비정형 데이터 처리 쿼리는 비정형 데이터만을 처리하기 위한 쿼리이고, 정형 데이터 처리 쿼리는 정형 데이터만을 처리하기 위한 쿼리일 수 있다.

비정형 데이터 처리 쿼리는 확장 SQL 및 확장 SQL 엔진을 기반으로 처리 되고, 정형 데이터 처리 쿼리는 일반 SQL(PostgreSQL) 및 일반 SQL 엔진을 기반으로 처리될 수 있다.

도 3은 본 발명의 실시예에 따른 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 처리하기 위한 데이터 처리 시스템을 나타낸 개념도이다.

도 3에서는 기존에 정의된 일반 쿼리와 비정형 데이터를 위해 확장된 SQL을 기반으로 정의된 확장 쿼리가 네스티드 쿼리를 형성하고, 네스티드 쿼리가 데이터 처리 시스템에서 처리되는 방법이 개시된다.

도 3을 참조하면, 입력 쿼리(300)로서 비정형 데이터 및 정형 데이터에 대한 처리를 위한 네스티드 쿼리가 입력될 수 있다.

예를 들어, 네스티드 쿼리는 제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)를 포함할 수 있고, 제1 쿼리(310) 및 제3 쿼리(330)는 확장 쿼리(350)이고, 제2 쿼리(320)는 일반 쿼리(360)일 수 있다.

제1 쿼리(310)는 PRINT IMAGE, 제2 쿼리(320)는 SELECT, 제3 쿼리(330)는 SEARCH IMAGE일 수 있다. 제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)는 네스티드 구조로 입력 쿼리를 형성할 수 있다.

입력 쿼리(300)는 파서를 통해 파싱될 수 있다. 렉서(lexer)를 기반으로 네스티트 쿼리는 일반 쿼리(360)와 확장 쿼리(350)로 구분되고, 파서는 일반 쿼리(360)와 확장 쿼리(350)를 분할할 수 있다.

제1 쿼리(310), 제2 쿼리(320) 및 제3 쿼리(330)는 클라우즈 아날라이즈(clause analyze) 및 쿼리 트리(query tree)를 통해 해석되어 처리될 수 있다. 제3 쿼리(330), 제2 쿼리(320) 및 제1 쿼리(310)의 순서로 처리될 수 있다.

제1 쿼리(310) 및 제3 쿼리(330)는 확장 쿼리(350)로서 확장 SQL 엔진을 기반으로 처리될 수 있고, 제2 쿼리(320)는 일반 쿼리로서 일반 쿼리 처리를 위한 SQL 엔진인 PostgreSQL 엔진을 기반으로 처리될 수 있다.

표준화 SQL 엔진과 PostgreSQL 엔진은 하나의 데이터베이스와 연결되어 쿼리를 처리할 수 있다. 하나의 데이터베이스를 기반으로 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 학습이 가능하다.

도 4는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.

도 4에서는 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 동시에 처리하기 위한 확장된 SQL 중 쿼리 기능이 개시된다.

도 4를 참조하면, 비정형 데이터에 대한 쿼리 기능은 아래와 같은 확장된 SQL을 기반으로 수행될 수 있다.

(1) 저장 모델 확인(LIST)(410)

사용자는 "LIST" 구문을 사용하여 비정형 데이터를 프로세싱하기 위한 비정형 데이터 테이블을 위해 미리 생성된 모델(pre-built model)과 사용자가 생성한 사용자 생성 모델을 확인할 수 있다.

예를 들어, LIST MODEL 기능을 통해 사용자에 의해 생성된 사용자 생성 모델에 대한 확인이 가능하고, LIST PREBUILT MODEL 기능을 사용하여 미리 생성된 모델에 대한 확인이 가능하다.

(2) 비정형 특성 추가(CONVERT USING)(430)

사용자는 "CONVERT USING" 구문을 사용하여 이미지, 비디오, 음성 등 비정형 데이터의 정보를 이용해서 수치화 알고리즘을 사용하여 벡터 형식으로 변환하고 이값을 사용할 데이터 세트에 추가할 수 있다.

아래의 표 2는 CONVERT USING 구문의 예시이다

<표 2>

CONVERT USING [사용할 인공지능 모델]

OPTIONS (

table_name=[저장될 테이블명]

)

AS

[사용할 데이터 세트]

예를 들어, CONVERT USING 기능을 사용하여 특정 경로에 존재하는 이미지 파일을 추가적인 속성 추출 인공지능 모델을 사용하여 데이터 테이블로서 데이터베이스 상에 생성할 수 있다.

(3) 비정형 데이터 검색(SEARCH)(440)

SEARCH 구문은 비정형 데이터에서 내용이나 의미 또는 유사도 등을 검색하기 위해 사용될 수 있다.

아래의 표 3은 SEARCH 구문의 예시이다.

<표 3>

SEARCH [사용자 지정 데이터 테이블 이름]

USING [사용할 인공지능 모델]

AS [사용할 데이터 세트]

예를 들어, 이미지 수치화 인공 지능 모델을 기반으로 유사 이미지에 대한 검색을 진행하기 위해 SEARCH 구문이 활용될 수 있다.

(4) 결과 출력(PRINT)(450)

사용자는 "PRINT" 구문을 사용하여 이미지, 오디오 및 비디오 파일을 출력할 수 있다. 또한, 서브 쿼리를 사용하여 "PRINT" 구문을 통해 나온 결과를 바로 출력할 수 있다.

아래의 표 4는 "PRINT" 구문의 예시이다.

<표 4>

PRINT IMAGE, AUDIO, VIDEO

AS [출력할 데이터 세트]

예를 들어, PRINT 쿼리문을 사용하여 데이터 테이블에 있는 이미지 파일/비디오 파일/오디오파일들을 출력할 수 있다.

위의 쿼리 신택스(syntax)는 본 발명에서 확정된 SQL을 위해 새롭게 정의된 신택스이다.

위와 같은 쿼리 신텍스를 기반으로 만들어진 비정형 데이터 테이블을 기반으로 키워드 또는 텍스트를 기반으로 한 이미지 데이터, 오디오 데이터, 비디오 데이터의 검색이 가능하다. 또한, 이미지 데이터, 오디오 데이터, 비디오 데이터를 기반으로 한 이미지 데이터, 오디오 데이터, 비디오 데이터의 검색도 가능하다.

즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서는 기존의 정형 데이터에 대한 실시간 검색에 추가하여 위와 같은 비정형 데이터에 대한 실시간 검색이 가능하다. 또한, 위와 같은 확장된SQL을 기반으로 비정형 데이터 및 정형 데이터에 대한 쿼리의 조합인 네스티드 쿼리(nested query)도 가능하여 비정형 데이터 및 정형 데이터를 모두 활용한 모델링도 가능하다.

도 5는 본 발명의 실시예에 따른 데이터 처리 시스템의 동작을 나타낸 개념도이다.

도 5에서는 하나의 플랫폼 상에서 정형 데이터와 비정형 데이터를 동시에 처리하기 위한 확장된 SQL 중 ML(machine learning) 기능이 개시된다.

도 5를 참조하면, 비정형 데이터에 대한 ML 기능은 아래와 같은 확장된 SQL을 기반으로 수행될 수 있다.

(1) 모델 학습(BUILD MODEL)(510)

사용자는 "BUILD MODEL" 구문을 사용하여 인공지능모델을 생성할 수 있다.

아래의 표 5는 "BUILD MODEL" 구문의 예시이다.

<표 5>

BUILD MODEL [사용자 지정 모델 이름]

USING [사용할 인공지능모델]

OPTIONS([인공지능모델을 만들 때 필요한 옵션값])

AS [사용할 데이터 세트]

예를 들어, 사용자는 "BUILD MODEL" 구문을 사용하여 영화를 추천하는 영화추천모델을 생성할 수 있다.

(2) 모델 평가(EVALUATE)(520)

사용자는 "EVALUATE" 구문을 사용하여 인공지능모델에 대한 성능 평가를 수행할 수 있다.

아래의 표 6은 "EVALUATE" 구문의 예시이다.

<표 6>

EVALUATE

USING [기존 학습한 모델 이름]

OPTIONS ([모델별 평가시 필요한 옵션값])

AS

[사용할 데이터 세트]

예를 들어, "EVALUATE" 구문을 사용하여 사용자가 모델 학습하기에서 만들었던 분류 모델에 대한 평가가 수행될 수 있다.

(3) 모델 재학습(FIT MODEL)(530)

사용자는 "FIT MODEL" 구문을 사용하여 모델을 재학습시킬 수 있다.

아래의 표 7은 "FIT MODEL" 구문의 예시이다.

<표 7>

FIT MODEL [사용자 지정 모델 이름]

USING [기존 학습한 모델 이름 | 사전 학습된 인공지능모델 이름]

OPTIONS ([인공지능모델을 만들 때 필요한 옵션값])

AS

[사용할 데이터세트]

예를 들어, "FIT MODEL"을 사용하여 사용자가 이전에 만들었던 모델에 새롭게 추가된 데이터세트를 사용하여 모델을 재학습시킬 수 있다.

(4) 모델 업로드(UPLOAD MODEL)(540)

사용자는 "UPLOAD MODEL" 구문을 사용하여 파이썬 환경에서 직접/자체적으로 만든 모델을 확장SQL을 기반으로 작동할 수 있도록 사용자의 모델을 확장 SQL로 업로드할 수 있다.

UPLOAD MODEL [사용자 지정 모델 이름]

OPTIONS([모델 업로드 시 필요한 옵션갑])

FROM [업로드 할 모델의 경로]

(5) 모델 적용하기(PREDICT)(550)

사용자는 "PREDICT" 구문을 사용하여 테스트 데이터 세트에 인공지능 모델을 적용하여 예측, 분류, 추천 등의 작업을 수행할 수 있다.

아래의 표 9는 "PREDICT" 구문의 예시이다.

<표 9>

PREDICT

USING [기존 학습한 모델 이름]

OPTIONS ([모델별 추론시 필요한 옵션값])

AS

[사용할 테스트 데이터 세트]

예를 들어, "PREDICT USING" 구문을 사용하여 기존에 모델 학습하기에서 만들어었던 기존 추천 모델을 사용하여 사용자 ID 31인 사용자가 좋아할만한 영화 목록에 대한 추천이 가능할 수 있다.

(6) 모델 삭제하기(DELETE MODEL)(560)

사용자는 "DELETE MODEL" 구문을 사용하여 생성되거나 업로드된 모델을 삭제할 수 있다.

아래의 표 10은 "DELETE MODEL" 구문의 예시이다.

<표 10>

DELETE MODEL [삭제할 모델 이름]

예를 들어, "DELETE MODEL" 구문을 기반으로 사용자가 모델 학습하기에서 만들었던 영화추천모델이 데이터베이스에서 삭제될 수 있다.

위와 같은 확장된SQL을 기반으로 비정형 데이터 및 정형 데이터를 기반으로 한 AI 모델링이 별도의 배치 프로세스 없이 하나의 플랫폼인 데이터 처리 시스템 상에서 수행될 수 있다.

데이터 처리 시스템 상에서는 미리 생성된 AI 모델 및 사용자에 의해 생성된 AI 모델이 위치할 수 있다. 이러한 AI 모델 생성을 통해 분류 모델, 회귀 모델, 추천 시스템, 음성 인식 모델 등 다양한 AI 모델에 대한 생성이 이루어질 수 있다.

도 6은 본 발명의 실시예에 따른 데이터 처리 시스템을 기반으로 한 데이터 처리 방법을 나타낸 개념도이다.

도 6에서는 전술한 데이터 처리 시스템을 기반으로 한 별도의 데이터베이스 상의 데이터 처리 방법이 개시된다.

도 6를 참조하면, 도 1에서 도 5에서 전술한 바와 같이 데이터 처리 시스템 자체 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리가 수행될 수도 있다. 하지만, 사용자는 사용자의 데이터베이스를 사용하되, 데이터 처리 시스템에서 제공하는 확장 SQL 및 확장 SQL 엔진의 기능을 API를 기반으로 활용할 수 있다.

데이터 처리 시스템의 자체 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리는 내부 데이터 처리라는 용어로 표현될 수 있다. 데이터 처리 시스템의 자체 데이터베이스가 아닌 외부 데이터베이스를 기반으로 한 정형 데이터 및 비정형 데이터의 처리는 외부 데이터 처리라는 용어로 표현될 수 있다.

내부 데이터 처리의 경우 전술한 도 1 내지 도 5에서 개시된 프로세스를 기반으로 처리될 수 있다.

외부 데이터 처리를 위해 외부에서 본 발명의 실시예에 따른 데이터 처리 시스템을 사용하기 위해서는 제공된 'API' 또는 '데이터 이전 방법'을 사용하여 외부 데이터를 본 발명의 데이터 처리 시스템에 저장 및 변환시켜줘야 한다. 저장 및 변환이 완료된 데이터들에 대해서는 API를 사용하여 본 발명의 데이터 처리 시스템을 활용할 수 있다. 즉, 자체 엔진과 PostgreSQL 엔진 모두 외부 데이터베이스가 아닌 본 발명의 실시예에 따른 데이터베이스를 액세스하여 데이터 처리를 수행할 수 있다.

외부 데이터 처리의 경우, 사용자는 사용자의 데이터베이스에 저장된 별도의 비정형 데이터를 기반으로 한 학습을 API를 통해 확장된 SQL 및 확장 SQL 엔진의 기능을 기반으로 수행할 수 있다.

예를 들어, 특정 사용자는 보안 업체로서 CCTV 영상을 저장하는 사용자 데이터베이스를 운영할 수 있다. 사용자는 본 발명의 데이터 처리 시스템의 확장된 SQL을 기반으로 CCTV 영상에 대한 인공지능학습을 사용자 데이터베이스에 저장된 데이터를 기반으로 수행할 수 있다. 외부 데이터베이스에서 본 발명의 데이터 처리 시스템의 데이터베이스로 정형 데이터 및 본 발명에서 정의된 비정형 데이터를 처리하기 위한 비정형 데이터에 대한 쿼리문을 기반으로 정형 데이터와 비정형 데이터가 삽입될 수 있다. 본 발명의 실시예에 따른 데이터 처리 시스템에 입력된 정형 데이터와 비정형 데이터에 대한 AI 모델링이 본 발명의 실시예에 따른 데이터 처리 시스템의 AI 엔진을 기반으로 수행될 수 있다.

즉, 복수의 서로 다른 데이터베이스 상의 정형 데이터와 비정형 데이터를 처리하는 방법은 데이터 처리 시스템이 외부 데이터베이스로부터 외부 데이터를 수신하는 단계, 상기 데이터 처리 시스템이 상기 외부 데이터를 변환하는 단계와 데이터 처리 시스템이 변환된 상기 외부 데이터를 처리하는 단계를 포함할 수 있다.

이때, 외부 데이터는 정형 데이터와 비정형 데이터를 포함하고, 데이터 처리 시스템은 네스티드 쿼리를 기반으로 정형 데이터 및 비정형 데이터를 처리하고, 네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리일 수 있다.

데이터 처리 시스템은 비정형 데이터 처리 쿼리를 기반으로 비정형 데이터를 처리하고, 데이터 처리 시스템은 정형 데이터 처리 쿼리를 기반으로 정형 데이터를 처리할 수 있다.

네스티드 쿼리는 비정형 데이터에 대한 제1 쿼리 및 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리이고, 비정형 데이터 처리 쿼리는 상기 비정형 데이터만을 처리하기 위한 쿼리이고, 정형 데이터 처리 쿼리는 정형 데이터만을 처리하기 위한 쿼리일 수 있다.

데이터 처리 시스템은 정형 데이터에 대한 데이터 테이블 및 비정형 데이터에 대한 데이터 테이블을 생성하여 하나의 데이터베이스 상에서 처리하고, 데이터 처리 시스템은 정형 데이터 및 비정형 데이터를 기반으로 한 인공 지능 엔진 모델링을 하나의 데이터베이스 상에서 지원할 수 있다.

도 7은 본 발명의 실시예에 따른 데이터 처리 시스템에서 쿼리를 분석하여 데이터를 처리하는 방법을 나타낸 개념도이다.

도 7에서는 입력된 쿼리를 분석하여 비정형 데이터 및 정형 데이터를 하나의 데이터 처리 시스템에서 처리를 수행하되 쿼리를 처리함에 있어 서로 다른 프로세싱 자원을 활용하는 방법이 개시된다.

도 7을 참조하면, 입력 쿼리로서 비정형 데이터 및/또는 정형 데이터에 대한 처리를 위한 쿼리가 입력될 수 있다. 입력된 쿼리는 비정형 데이터 또는 정형 데이터에 대한 일반 쿼리일 수도 있고, 비정형 데이터 및 정형 데이터에 대한 혼합적인 처리를 위한 네스티드 쿼리일 수도 있다.

입력 쿼리는 파서부(700)를 통해 파싱될 수 있다. 네스티트 쿼리는 일반 쿼리와 확장 쿼리로 구분되고, 파서부(700)는 일반 쿼리와 확장 쿼리를 분할할 수 있다.

입력 쿼리에 포함되는 복수의 쿼리는 클라우즈 아날라이즈부(clause analyze) (710) 및 쿼리 트리부(query tree)(720)를 통해 해석되어 처리될 수 있다.

본 발명에서는 설명의 편의상 입력 쿼리로서 네스티드 쿼리가 입력되고, 네스티드 쿼리는 제1 쿼리(715), 제2 쿼리(725) 및 제3 쿼리(735)를 포함할 수 있다. 클라우즈 아날라이즈부(710)는 제1 쿼리(715), 제2 쿼리(725) 및 제3 쿼리(735)에 대하여 어떠한 컴퓨팅 자원을 사용하여 프로세싱되어야 할지를 결정할 수 있다. 보다 구체적으로 클라우즈 아날라이즈부(710)는 네스티드 쿼리에 포함되는 복수의 쿼리에 대한 분석을 통해 쿼리가 CPU(770)에서 실행되어야 할지 GPU(780)에서 실행되어야 할지를 결정할 수 있다. 클라우즈 아날라이즈부(710)는 본 발명의 실시예에 따른 자원 분배 알고리즘을 기반으로 복수의 쿼리 각각의 실행 예상 능률 및 실행 예상 속도를 판단하고 실행 예상 능률 및 실행 예상 속도를 기반으로 복수의 쿼리 각각을 CPU(770) 또는 GPU(780)에 할당할 수 있다.

제1 쿼리(715) 및 제3 쿼리(735)는 확장 쿼리이고, 제2 쿼리(725)는 일반 쿼리인 경우가 가정될 수 있다. 제1 쿼리(715) 및 제3 쿼리(735)는 확장 SQL 엔진(760)을 기반으로 처리될 수 있고, 제2 쿼리(725)는 일반 쿼리로서 일반 쿼리 처리를 위한 SQL 엔진인 PostgreSQL 엔진(750)을 기반으로 처리될 수 있다.

이때, 자원 분배 알고리즘을 기반으로 제1 쿼리(715)는 GPU(780), 제3 쿼리(735)는 CPU(770), 제2 쿼리(725)는 GPU(780)를 기반으로 처리될 수 있다. 자원 분배 알고리즘을 기반으로 네스티드 쿼리의 처리 속도는 향상되고 컴퓨팅 자원은 보다 효율적으로 활용될 수 있다.

이러한 자원 분배 알고리즘은 일반 쿼리를 위한 SQL 엔진인 PostgreSQL 엔진(750)과 확장 쿼리를 위한 확장 SQL 엔진(760)에 모두 적용되어 활용될 수 있고, 모델링 역시 GPU를 사용하여 진행하기 때문에 빠른 모델링 결과가 도출될 수 있다.

도 8은 본 발명의 실시예에 따른 자원 분배 알고리즘을 나타낸 개념도이다.

도 8에서는 자원 분배 알고리즘을 기반으로 쿼리를 처리시 CPU 또는 GPU를 선택하기 위한 방법이 개시된다.

도 8을 참조하면, 확장 쿼리(800)와 일반 쿼리(820)를 처리시 CPU(860) 또는 GPU(850)를 사용할지 여부를 결정하는 방법이 개시된다.

(1) 확장 쿼리(800)

1) 확장 쿼리(800) 중 확장 엔진 상에서 GPU(850)를 필수적으로 사용해야 하는 모델을 기반으로 처리되어야 하는 제1 타입 확장 쿼리(803)는 GPU(850)를 기반으로 처리될 수 있다.

2) 확장 쿼리(800) 중 확장 엔진 상에서 GPU(850)를 필수적으로 사용하지 않아도 처리 가능한 제2 타입 확장 쿼리(806)는 컴퓨팅 리소스 중 CPU 실행 능력과 GPU 실행 능력을 고려하여 CPU(860) 또는 GPU(850)를 기반으로 처리될 수 있다.

CPU 실행 능력은 CPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. GPU 실행 능력은 GPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. CPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), CPU 연산 비용을 기반으로 결정되고, GPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), GPU 연산 비용을 기반으로 결정될 수 있다. 쿼리 처리 속도가 상대적으로 빠르고 리소스 사용량이 상대적으로 작고, 쿼리 비용이 상대적으로 작을 수록 실행 능력은 높게 판단될 수 있다.

(2) 일반 쿼리

일반 쿼리는 컴퓨팅 리소스 중 CPU 실행 능력과 GPU 실행 능력을 고려하여 CPU 또는 GPU를 기반으로 처리될 수 있다.

보다 구체적으로 확장 쿼리 및 일반 쿼리에 대한 CPU 실행 능력과 GPU 실행 능력은 전체 비용을 고려하여 결정될 수 있다. 전체 비용이 작을수록 더 유리한 자원일 수 있다.

전체 비용(total cost)은 스타트업 코스트(star-up cost)와 런 코스트(run cost)의 합일 수 있다.

스타트업 코스트는 첫번째 튜플(tuple)이 페치(fetch)되기 전에 발생되는 비용일 수 있다. 튜플은 데이터베이스 내의 주어진 목록과 관계있는 속성값의 모음이다.　예를 들어, 인덱스 스캔 노드(index scan node)의 스타트업 코스트는 타겟 테이블의 첫번째 튜플에 액세스하기 위해 인덱스 페이지를 읽기 위한 코스트이다.

런 코스트는 모든 튜플에 액세스하기 위한 비용일 수 있다.

보다 구체적으로 CPU 런 코스트와 GPU 런 코스트는 아래의 수학식과 같이 결정될 수 있다.

<수학식>

GPU run cost = (gpu_tuple_cost + gpu_operator_cost) x N_tuple + seq_page cost x N_page

CPU run cost = (cpu_tuple_cost + cpu_operator_cost) x N_tuple + seq_page cost x N_page

gpu_tuple_cost는 GPU가 연산시 테이블 행들을 프로세스하는 비용이다.

gpu_operator_cost는 GPU가 테이블 튜플을 오퍼레이터나 함수로 프로세스하는 비용이다.

cpu_tuple_cost는 CPU가 연산시 테이블 행들을 프로세스하는 비용이다

cpu_operator_cost는 CPU가 테이블 튜플을 오퍼레이터나 함수로 프로세스하는 비용이다.

N_tuple은 테이블 튜플의 개수이다.

seq_page cost는 페이지를 가지고 오는 비용이다.

N_page는 인덱스 페이지의 개수이다.

도 9는 본 발명의 실시예에 따른 입력 멀티-쿼리(input multi-query)를 처리하는 데이터 처리 시스템을 나타낸 개념도이다.

도 9에서는 입력 멀티-쿼리를 수신시 멀티-쿼리 스케줄러를 기반으로 입력 멀티-쿼리에 포함된 복수의 쿼리에 대한 처리를 스케줄링하는 방법이 개시된다.

도 9를 참조하면, 입력 멀티-쿼리(900)는 복수의 쿼리를 포함하는 쿼리일 수 있다. 예를 들어, 입력 멀티-쿼리(900)는 제1 쿼리, 제2 쿼리, 제3 쿼리 및 제4 쿼리를 포함할 수 있다. 제1 쿼리는 SELECT, 제2 쿼리, 제3 쿼리는 BUILD, 제4 쿼리는 PRINT일 수 있다.

멀티-쿼리 스케줄러(920)는 멀티-쿼리 분석부(multi-query analyzer)(940) 및 쿼리 큐(query queue)(960)를 포함할 수 있다.

멀티-쿼리 분석부(920)는 입력 멀티-쿼리(900)에 포함된 복수의 쿼리를 분석하여 복수의 쿼리의 처리 순서를 결정할 수 있다.

쿼리 큐(960)는 멀티-쿼리 분석부(920)에 의해 결정된 복수의 쿼리의 처리 순서를 고려하여 큐 상에 복수의 쿼리를 스케줄링할 수 있다.

큐 상에 스케줄링된 쿼리는 파서부로 전달될 수 있다. 이후 전술한 절차와 같이 쿼리는 파서부에서 파싱되어 일반 쿼리와 확장 쿼리로 분할되고, 클라우즈 아날라이즈부 및 쿼리 트리부를 통해 해석되어 처리될 수 있다.

클라우즈 아날라이즈부는 쿼리를 처리할 엔진 및 쿼리를 처리할 컴퓨팅 자원(CPU 또는 GPU)를 결정하여 결정된 엔진(PostgreSQL 엔진 또는 확장 엔진)으로 전달하여 처리할 수 있다.

도 10은 본 발명의 실시예에 따른 멀티-쿼리 스케줄러의 동작을 나타낸 개념도이다.

도 10에서는 멀티-쿼리 스케줄러의 복수의 쿼리를 스케줄링하기 위한 방법이 개시된다.

도 10을 참조하면, 멀티-쿼리 스케줄러(1000)는 멀티-쿼리 형태로 들어오는 입력 쿼리에 대한 종속성 스코어(1020) 및 컴퓨팅 자원 할당 데이터(1040)를 분석하고, 종속성 스코어(1020) 및 컴퓨팅 자원 할당 데이터(1040)를 기반으로 입력 멀티-쿼리에 포함되는 복수의 쿼리의 처리 순서를 결정할 수 있다.

종속성 스코어(1020)는 입력 멀티-쿼리에 포함되는 복수의 쿼리 간에 상호 상관 관계를 통해 결정될 수 있다. 예를 들어, 제3 쿼리가 제1 쿼리 및 제2 쿼리를 기반으로 처리된 결과에 종속적인 경우, 제3 쿼리는 제1 쿼리와 제2 쿼리에 대한 종속성을 가지는 쿼리일 수 있다. 제4 쿼리가 독립적으로 처리되는 경우, 제4 쿼리는 다른 쿼리에 대한 종속성을 가지지 않는 쿼리일 수 있다.

종속성 스코어(1020)는 다른 쿼리의 처리 이후에 수행될 수 있는 쿼리에 대하여 판단될 수 있고, 다른 쿼리에 대한 종속성이 높을수록 상대적으로 높은 값을 가질 수 있다.

컴퓨팅 자원 할당 데이터(1040)는 쿼리가 CPU와 GPU 어떠한 프로세싱 유닛을 기반으로 처리될지 및 쿼리가 CPU 또는 GPU를 기반으로 처리될 경우, 할당되는 컴퓨팅 자원에 대한 데이터일 수 있다.

예를 들어, 멀티-쿼리 스케줄러(1000)는 전술한 자원 분배 알고리즘을 기반으로 쿼리가 CPU와 GPU 어떠한 프로세싱 유닛을 기반으로 처리될지를 결정할 수 있다. 또한, 멀티-쿼리 스케줄러(1000)는 전술한 CPU 실행 능력 및 GPU 실행 능력을 판단하는 방법을 기반으로 쿼리가 CPU 또는 GPU를 기반으로 처리될 경우, 할당되는 컴퓨팅 자원에 대한 데이터를 획득할 수 있다.

CPU 실행 능력은 CPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. GPU 실행 능력은 GPU를 기반으로 쿼리를 처리시 쿼리 처리 속도, 리소스 사용량, 쿼리 비용을 기반으로 결정될 수 있다. CPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), CPU 연산 비용을 기반으로 결정되고, GPU 실행 능력을 결정하기 위한 쿼리 비용은 데이터 처리량(row processed), GPU 연산 비용을 기반으로 결정될 수 있다.

또한, 종속성 스코어(1020)는 쿼리의 타입에 따라 서로 다른 우선 순위를 기반으로 처리되도록 결정될 수 있다.

쿼리 중 CREATE, COPY, BUILD 등과 같은 테이블이나 모델을 생성하는 특별한 구문(clause)을 인식하고 이러한 타입의 쿼리가 먼저 실행되도록 스코어가 할당될 수 있다. 테이블이나 모델을 생성하기 위한 쿼리는 우선 처리 쿼리로 정의될 수 있고, 우선 처리 쿼리 내에서도 별도의 우선 순위가 스코어를 기반으로 부여될 수 있다.

예를 들어, 입력 멀티-쿼리에 포함되는 복수의 쿼리가 CREATE, SELECT_1, COPY, SELECT_2, PREDICT, BUILD인 경우, COPY, CREATE, BUILD는 우선 처리 쿼리로서 우선적으로 처리될 수 있다.

예를 들어, 종속성 스코어(1020)를 기반으로 COPY > CREATE > BUILD > PREDICT > SELECT_1 > SELECT_2 순서로 처리 우선 순위가 결정되고, 쿼리 큐는 쿼리를 수행하기 위한 큐(queue)를 재구성할 수 있다.

보다 구체적으로 멀티-쿼리 분석부는 1차적으로 입력 멀티-쿼리에 포함되는 복수의 쿼리의 종속성을 체크한 후 복수의 쿼리 각각의 실행 순서를 결정할 수 있다.

이후, 2차적으로 전술한 전체 비용을 고려하여 복수의 쿼리 각각에 대한 GPU 실행 능력 및 CPU 실행 능력이 결정될 수 있다. GPU 실행 능력 및 CPU 실행 능력을 기반으로 쿼리 그룹에 포함된 복수의 쿼리 각각이 CPU에 할당될지 GPU에 할당될지가 결정되고, 전체 비용이 낮을수록 빠르게 실행되도록 실행 순서가 결정될 수 있다.

보다 구체적으로 멀티-쿼리 분석부의 클라우즈 아날라이저는 입력 멀티 쿼리에 포함되는 복수의 쿼리의 상관 관계를 분석하고, 복수의 쿼리의 상관 관계(종속성)를 기초로 복수의 쿼리 중 특정 쿼리를 우선적으로 실행하도록 결정할 수 있다.

이후, 복수의 쿼리 각각에 대한 전체 비용(스타트업 코스트(start-up cost)와 런 코스트(run cost)의 합)이 결정될 수 있다. 또한, 복수의 쿼리 각각의 전체 비용 정보를 기초로 메이저 자원이 CPU 또는 GPU로 결정될 수 있다. 전체 코스트가 낮을수록 높은 우선 순위로서 처리되도록 큐에 쌓이되, 실행 능력에 따라 메이저 자원으로서 CPU, GPU를 선택적으로 사용되도록 복수의 쿼리 그룹이 큐에 쌓일 수 있다.

마지막으로 복수의 쿼리에 포함되는 쿼리의 위치를 추가적으로 고려하여 입력 멀티 쿼리의 앞단에 위치한 쿼리일수록 높은 우선 순위로서 처리되도록 큐에 쌓일 수 있다.

예를 들어, 쿼리 1 내지 쿼리4가 존재하는 경우가 가정될 수 있다.

쿼리 1은 1순위로 작은 전체 비용을 가지고, GPU를 메이저 자원으로 사용하고, 입력 멀티-쿼리에 가장 앞부분에 작성된 쿼리를 포함할 수 있다.

쿼리 2는 3순위로 작은 전체 비용을 가지고 GPU를 메이저 자원으로 사용할 수 있다.

쿼리 3은 2순위의 작은 전체 비용을 가지고 CPU를 메이저 자원으로 사용할 수 있다.

쿼리 4은 4순위로 작은 전체 비용을 가지고 CPU를 메이저 자원으로 사용하고, 입력 멀티-쿼리에 가장 뒷부분에 작성된 쿼리를 포함할 수 있다. 이러한 경우, 쿼리 1, 쿼리 3, 쿼리 2, 쿼리 4의 순서로 처리되도록 큐에 쿼리 그룹이 쌓일 수 있다.

도 11은 본 발명의 실시예에 따른 입력 멀티-쿼리를 처리하는 방법을 나타낸 개념도이다.

도 11에서는 입력 멀티 쿼리에 포함되는 쿼리 그룹의 실행 순서를 결정하는 알고리즘이 개시된다.

도 11을 참조하면, 멀티-쿼리 분석부의 클라우즈 아날라이저에 의해 복수의 쿼리 그룹의 메이저 자원과 전체 비용이 결정된 이후, 종속성, 전체 비용, 쿼리의 위치를 고려하여 쿼리 그룹의 실행 순서가 결정될 수 있다.

예를 들어, 쿼리1(1110)은 전체 비용 3, 쿼리문으로 PREDICT USING(my_model)을 포함한다. 쿼리2(1120)은 전체 비용 2, 쿼리문으로 CREATE TABLE(my_model)을 포함한다. 쿼리3(1130)은 전체 비용 5, 쿼리문으로 BUILD MODEL(my_model)을 포함할 수 있다.

이러한 경우, 쿼리1(1110)과 쿼리2(1120)에서 사용되는 my_model은 쿼리3(1130)에서 먼저 생성되고 사용 가능하므로 쿼리1(1110)과 쿼리2(1120)은 쿼리3(1130)에 대하여 종속성을 가진다. 따라서, 쿼리3(1130)의 전체 코스트가 높고 위치가 가장 뒤임에도 불구하고 가장 먼저 실행될 수 있다.

쿼리3(1130)의 다음으로 전체 비용을 고려하여 전체 비용 1인 쿼리2(1120)가 실행되고, 마지막으로 전체 비용 3인 쿼리1(1110)이 실행될 수 있다.

만약 쿼리1(1110)과 쿼리2(1120)의 전체 비용이 동일하다면, 쿼리문의 위치를 고려하여, 쿼리 3(1130)의 실행 이후, 쿼리1(1110), 쿼리2(1120)의 순서로 쿼리가 실행될 수 있다.

도 12는 본 발명의 실시예에 따른 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하는 서버를 나타낸 개념도이다.

도 12에서는 서로 다른 아키텍쳐를 기반으로 사용자 장치로 정형 데이터 및 비정형 데이터에 대한 처리 서비스를 제공하기 위한 서버가 개시된다.

도 12를 참조하면, 서버(1200)는 인스턴스(instance)(1210)와 리소스(resource)를 포함할 수 있다. 인스턴스는 워크스페이스 허브(1270, 1280)와 데이터 처리 엔진(1220)을 포함하고, 리소스는 프로세싱 자원(1240)과 스토리지(1230), 메모리(미도시)를 포함할 수 있다. 워크스페이스 허브(1270, 1280)는 적어도 하나의 워크스페이스(1250)를 포함할 수 있다.

워크스페이스(1250)는 직접적으로 워크스페이스(1250)에 대응되는 스토리지(1230)에만 연결될 수 있고, 데이터 처리 엔진(1220)은 모든 스토리지(1230)에 연결될 수 있다. 인스턴스는 리소스와 직접적으로 연결된 구조를 가질 수 있다.

이하에서는 보다 구체적으로 서버(1200)를 구성하는 인스턴스 및 리소스에 대해 개시한다.

워크스페이스 허브(1270, 1280)는 공유 아키텍쳐(shared architecture)를 기반으로 구현되는 공유 워크스페이스 허브(1270), 전용 아키텍쳐(dedicated architecture)를 기반으로 구현되는 전용 워크스페이스 허브(1280)를 포함할 수 있다.

공유 워크스페이스 허브(1270)와 전용 워크스페이스 허브(1280)는 워크스페이스(1250)를 포함할 수 있다. 워크스페이스(1250)는 사용자에 의한 정형 데이터 및 비정형 데이터를 기반으로 한 서비스를 구현하기 위한 공간일 수 있다. 예를 들어, 하나의 워크스페이스(1250)는 하나의 사용자 식별자를 기반으로 부여될 수 있다. 워크스페이스(1250)는 랩(lab)과 데이터베이스(database)를 포함할 수 있다. 랩은 사용자에 의해 구현되는 서비스를 위한 쿼리를 생성하는 공간이고, 데이터베이스는 조직화된 데이터를 저장하는 논리적 저장소이다. 다른 표현으로 랩은 워크스페이스(1250)에 액세스하기 위한 사용자 인터페이스일 수 있다.

공유 워크스페이스 허브(1270)는 복수의 사용자들의 복수의 워크스페이스(1250)를 포함할 수 있다. 공유 워크스페이스 허브(1270)는 할당된 데이터 처리 엔진(1220), 할당된 프로세싱 자원(1240)을 공유할 수 있다. 전용 워크스페이스 허브(1280)는 하나의 사용자에 대한 워크스페이스(1250)를 포함할 수 있다. 전용 워크스페이스 허브(1280)에는 하나의 사용자가 전용으로 사용할 데이터 처리 엔진(1220) 및 프로세싱 자원(1240)이 할당될 수 있다.

설명의 편의상 공유 워크스페이스 허브(1270)와 전용 워크스페이스 허브(1280)는 하나씩만 표현되었으나, 공유 워크스페이스 허브(1270)와 전용 워크스페이스 허브(1280)는 복수개 존재할 수 있고, 이러한 아키텍쳐 구조도 본 발명의 권리 범위에 포함될 수 있다.

보다 구체적으로 공유 워크스페이스 허브(1270)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 사용할 수 있다. 공유 워크스페이스 허브(1270)는 복수의 워크스페이스(1250)를 포함할 수 있다. 복수의 워크스페이스(1250)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 공유할 수 있다.

전용 워크스페이스 허브(1280)는 하나의 워크스페이스(1250)만을 포함하고, 하나의 워크스페이스(1250)는 할당된 데이터 처리 엔진(1220)과 할당된 프로세싱 자원(1240)을 전용으로 사용할 수 있다.

따라서, 사용자는 처리할 정형 데이터, 비정형 데이터의 양, 정형 데이터 및 비정형 데이터를 기반으로 구현될 서비스를 기반으로 공유 워크스페이스(1270) 또는 전용 워크스페이스(1280)를 선택적으로 선택하여 워크스페이스(1250)를 생성할 수 있다.

데이터 처리 엔진(1220)은 도 2 내지 도 11에서 전술한 데이터 처리 시스템으로서 비정형 데이터와 정형 데이터에 대한 쿼리를 PostgreSQL와 확장 SQL를 기반으로 처리할 수 있다. 즉, 데이터 처리 엔진(1220)은 도 2 내지 도 11에서 전술한 데이터 처리 시스템의 동작을 수행할 수 있다.

데이터 처리 엔진(1220)은 워크스페이스(1250)를 기반으로 한 사용자 요청을 통해 사용자를 위한 모델을 생성할 수 있고, 사용자를 위한 모델은 생성되어 스토리지(1230) 상에 저장될 수 있다.

사용자는 API(application programming interface) 및 사용자 고유 식별 정보를 기반으로 외부에서 데이터 처리 엔진(1220)을 통해 사용자의 스토리지(1230)에 저장된 모델을 기반으로 한 출력값을 요청하기 위한 쿼리를 전달할 수 있다. 데이터 처리 엔진(1220)은 사용자 고유 식별 정보를 기반으로 사용자의 워크스페이스(1250)를 확인하고, 스토리지(1230)에 저장된 모델을 기반으로 출력값을 사용자에게 전달할 수 있다.

데이터 처리 엔진(1220)은 모든 스토리지(1230)에 액세스 가능하게 구현되고 사용자의 요청에 따라 사용자 고유 식별 정보를 기반으로 스토리지(1230)에 접근하여 스토리지(1230)에 저장된 데이터를 활용할 수 있다.

스토리지(1230)는 파일, 모델 등에 대한 물리적인 저장소일 수 있고, 하나의 워크스페이스(1250)는 하나의 스토리지(1230)에 연결되어 사용자 고유 식별 정보를 인증받은 경우에만 액세스 가능할 수 있다.

프로세싱 자원(1240)은 GPU, CPU, 메모리를 포함할 수 있다. 전술한 바와 같이 CPU와 GPU는 자원 분배 알고리즘을 기반으로 쿼리를 처리시 선택될 수 있다. 또한, CPU와 GPU는 멀티-쿼리 스케줄러를 기반으로 선택되어 멀티-쿼리를 처리하기 위해 선택적으로 사용될 수 있다.

전용 워크스페이스 허브(1280)의 워크스페이스(1250)는 할당된 자원을 독점적으로 사용할 수 있다. 공유 워크스페이스 허브(1270)의 복수의 워크스페이스(1250)는 할당된 자원을 공유한다. 따라서, 복수의 워크스페이스(1250) 각각에 의해 요청된 쿼리는 순차적으로 처리될 수 있다.

도 13은 본 발명의 실시예에 따른 공유 워크스페이스 허브의 쿼리 처리 방법을 나타낸 개념도이다.

도 13에서는 공유 워크스페이스 허브에 포함되는 복수의 워크스페이스 각각에 의한 쿼리를 처리하기 위한 방법이 개시된다.

도 13을 참조하면, 공유 워크스페이스 허브에 포함되는 개별 워크스페이스에 대한 쿼리 처리는 전술한 자원 배분 알고리즘을 기반으로 처리될 수 있다.

하지만, 복수의 워크스페이스에 의해 생성된 쿼리는 큐(queue)(1300)/스택(stack)을 기반으로 순차적으로 처리될 수 있다. 즉, 개별 워크스페이스의 쿼리에 대한 처리는 자원 배분 알고리즘을 기반으로 수행되고, 복수의 워크스페이스의 쿼리에 대한 처리는 시퀀셜(sequential)하게 쿼리 생성 시간을 고려하여 순차적으로 처리될 수 있다.

도 14는 본 발명의 실시예에 따른 자원 분배 방법을 나타낸 개념도이다.

도 14에서는 워크스페이스의 특성을 고려하여 프로세싱 자원을 할당하기 위한 방법이 개시된다.

도 14를 참조하면, 워크스페이스 허브(전용 워크스페이스 허브, 공유 워크스페이스 허브)의 특성을 고려하여 프로세싱 자원(CPU, GPU, 메모리)을 할당하기 위한 방법이 개시된다.

프로세싱 자원을 할당하기 위한 워크스페이스 허브의 특성은 정형 데이터에 대한 쿼리의 볼륨(1400), 비정형 데이터에 대한 쿼리의 볼륨(1410), 쿼리의 처리를 위해 필요한 데이터 처리량(1420)을 포함할 수 있다.

워크스페이스가 비정형 데이터에 대한 쿼리(이하, 비정형 쿼리)를 상대적으로 많이 사용할수록 GPU를 상대적으로 많이 사용하게 된다.

워크스페이스가 정형 데이터에 대한 쿼리(이하, 정형 쿼리)를 상대적으로 많이 사용할수록 또한, 쿼리 요청수가 상대적으로 많을수록 CPU를 상대적으로 많이 사용하게 된다.

워크스페이스가 쿼리를 처리함에 있어서 많은 데이터양의 처리가 필요할수록 상대적으로 메모리가 많이 할당될 수 있다.

본 발명의 실시예에 따르면, 워크스페이스 허브 별로 사용되는 정형 데이터에 대한 정형 쿼리의 볼륨, 비정형 데이터에 대한 비정형 쿼리의 볼륨, 쿼리의 처리를 위해 필요한 데이터 처리량을 고려하여 워크스페이스 허브에 대한 자원이 적응적으로 할당될 수 있다.

본 발명의 실시예에 따르면, 전용 워크스페이스 허브에 포함되는 워크스페이스(이하, 워크스페이스(전용)의 경우, 설정된 한도 내의 프로세싱 자원을 공유하지 않고 사용한다. 본 발명의 실시예에 따르면, 워크스페이스(전용)은 발생된 정형 쿼리 데이터, 비정형 쿼리 데이터, 데이터 처리량에 대한 통계 정보인 프로세싱 자원 사용 통계 데이터를 기반으로 워크스페이스(전용)에 대한 CPU, GPU, 메모리의 제공 한도를 적응적으로 조절할 수 있다. 예를 들어, 워크스페이스1(전용)은 CPU가 상대적으로 많이 필요할 수 있고, 이러한 경우, 제한 한도 내에서 사용하지 않는 GPU 자원 할당량이 치환되어 CPU 자원으로 전환되어 사용될 수 있다. 워크스페이스2(전용)은 GPU가 상대적으로 많이 필요할 수 있고, 이러한 경우, 제한 한도 내에서 사용하지 않는 CPU 자원 할당량이 치환되어 GPU 자원으로 전환되어 사용될 수 있다.

공유 워크스페이스 허브에 포함되는 워크스페이스(이하, 워크스페이스(공유)의 경우, 프로세싱 자원을 공유하여 사용하게 된다.

따라서, 프로세싱 자원의 공유를 위해 공유 워크스페이스 허브에 포함되는 복수의 워크스페이스(공유)의 프로세싱 자원 사용 통계 데이터를 기반으로 프로세싱 자원이 할당될 수 있다. 공유 워크스페이스 허브에 프로세싱 자원을 할당하는 방식은 고정 방식과 변동 방식이 존재할 수 있다.

고정 방식은 하나의 공유 워크스페이스 허브에 할당되는 프로세싱 자원을 포함되는 워크스페이스(공유)의 개수에 따라 설정하는 방식이다.

고정 방식이 사용되는 경우, 공유 워크스페이스 허브에 포함되는 복수의 워크스페이스는 복수의 워크스페이스 각각에서 사용되는 프로세싱 자원 사용 통계 각각을 고려하여 공유 워크스페이스 허브에 할당되는 워크스페이스가 결정될 수 있다. 예를 들어, 상대적으로 CPU를 GPU보다 많이 사용하는 워크스페이스와 상대적으로 GPU를 CPU보다 많이 사용하는 워크스페이스가 그룹핑되어 전체적으로 균형있는 프로세싱 자원이 이루어지도록 워크스페이스가 공유 워크스페이스 허브에 할당될 수 있다.

변동 방식은 하나의 공유 워크스페이스 허브에 할당되는 프로세싱 자원을 복수의 공유 워크스페이스 허브에서 사용되는 프로세싱 자원을 고려하여 할당하는 방식이다. 변동 방식에서는 복수의 공유 워크스페이스 허브에서 사용되는 프로세싱 자원이 결정되고, 복수의 공유 워크스페이스 허브 각각의 프로세싱 자원 사용 통계를 고려하여 복수의 공유 워크스페이스 허브 각각으로 서로 다른 CPU 자원, GPU 자원, 메모리가 할당될 수 있다.

고정 방식과 변동 방식은 전체 프로세싱 자원의 사용량을 고려하여 안정적인 프로세싱 자원의 공급이 필요한 경우, 고정 방식이 사용되고, 보다 효율적인 프로세싱 자원의 공급이 필요한 경우, 변동 방식이 사용될 수 있다. 예를 들어, 특정 시간대(업무 시간)의 경우, 고정 방식으로 프로세싱 자원을 제공하고, 예를 들어, 특정 시간대(비업무 시간)의 경우, 변동 방식으로 프로세싱 자원을 제공하여 사용하지 않는 프로세싱 자원이 최대한 효율적으로 활용하도록 할 수 있다.

더 큰 단위로는 서버 단위로 프로세싱 자원 사용 통계를 기반으로 복수의 서버 상에 워크스페이스 허브 및 워크스페이스가 할당될 수 있다.

이하, 개시되는 비정형 데이터의 임베딩 방법, 비정형 데이터의 바이너리화법, 서버/워크스페이브 백업 방법, 서버/워크스페이스 마이그레이션 방법, 캐시화 방법은 데이터 처리 시스템에서 수행될 수 있고, 데이터 처리 시스템은 전술한 서버와 외부 장치(외부 처리 서버)를 포함하는 개념일 수 있다.

도 15는 본 발명의 실시예에 따른 비정형 데이터에 대한 비정형 임베딩 방법을 나타낸 개념도이다.

도 15에서는 비정형 데이터에 대한 임베딩을 수행하는 비정형 임베딩 방법이 개시된다.

도 15를 참조하면, 비정형 데이터(이미지, 비디오, 오디오, 등)은 차원이 크고, 파일 자체로(픽셀 단위 등)으로 저장하게 되면 사이즈가 크다. 따라서, 본 발명의 데이터 처리 시스템은 비정형 데이터를 임베딩으로 변환하여 처리할 수 있다. 임베딩은 이미지, 텍스트, 비디오와 같은 비정형 데이터의 특성을 파악하여 벡터 형태로 변환하는 것으로서 파일 자체를 저장하기 보다는 파일의 특성을 저장함으로써 데이터 사이즈를 축소할 수 있고 이는 데이터 처리 시스템 상에서 확장 SQL을 기반으로 빠른 결과를 도출해 내는데 큰 도움을 줄 수 있다.

비정형 데이터는 인공지능모델 상에서 임베딩 값으로서 추출될 수 있다.

비정형 데이터의 임베딩 값을 추출하는 인공지능모델은 다양하다. 예를 들어 이미지의 색감이라는 특성을 추출해 내는 인공지능모델이 있는 반면 이미지에서 사람이 하고 있는 행동을 추출해 내는 인공지능모델이 있을 수 있고 형태 자체를 추출해 내는 모델이 있을 수도 있다.

본 발명의 실시예에 따르면, 컨버트(CONVERT) 함수가 비정형 데이터를 임베딩시켜줄 수 있다. 컨버트 함수에 모델명(또는 인공지능모델명)을 달리하여 원하는 특성이 임베딩값으로서 추출될 수 있으며, 임베딩값을 결정하는 인공지능모델은 새로운 모델이 개발되고 상용화시 데이터 처리 시스템에 추가될 수 있다.

본 발명의 실시예에 따르면, 컨버트(CONVERT) 함수를 사용하여 나온 임베딩값은 서치(SEARCH) 함수와 함께 비정형 검색시 사용될 수 있다. 서치(SEARCH) 함수는 임베딩과 데이터 처리 시스템에서 자체적으로 제공되는 인공지능 모델과 함께 사용되어 비정형 데이터에 대한 검색이 빠르게 수행될 수 있다.

즉, 본 발명의 실시예에 따른 데이터 처리 시스템은 컨버트(CONVERT) 및 서치(SEARCH) 구문 사용시 비정형 데이터를 임베딩화시키는 과정 그리고 임베딩을 사용하여 비정형 검색을 하는 과정을 GPU를 사용하여 프로세스 가속화할 수 있다.

따라서, 비정형 데이터 및 정형 데이터에 대한 처리가 하나의 시스템/운영 플랫폼 및 하나의 데이터베이스로 수행할 뿐만 아니라, 기존의 시스템 대비하여 쿼리에 대한 보다 빠른 결과를 도출해 낼 수 있다.

도 16은 본 발명의 실시예에 따른 비정형 데이터에 대한 비정형 임베딩 방법을 나타낸 개념도이다.

도 16에서는 본 발명의 실시예에 따른 데이터 처리 시스템에서 컨버트(CONVERT) 및 서치(SEARCH) 구문 사용시 비정형 데이터를 임베딩화시키는 과정 그리고 임베딩을 사용하여 비정형 검색을 하는 과정이 개시된다.

도 16을 참조하면, 비정형 데이터(1600)는 컨버트 기능을 사용하여 인공지능모델1(1610) 내지 인공지능모델n를 통해 임베딩값으로 변환될 수 있다. 예를 들어, 비정형 데이터(1600)는 이미지이고, 임베딩값은 인공지능모델1(1610) 내지 인공지능모델n 각각의 이미지에 대한 특징맵을 기반으로 추출된 값일 수 있다.

예를 들어, 비정형 데이터(1600)는 특정 이미지일 수 있고, 인공지능모델1(1610)은 이미지 내의 사람의 수에 대한 정보를 제1 임베딩값(1615)으로 변환하고, 인공지능모델2(1620)는 이미지를 구성하는 장소에 대한 정보를 제2 임베딩값(1625)으로 변환하고, 인공지능모델3(1630)은 이미지의 색체에 대한 정보를 제3 임베딩값(1635)으로 변환할 수 있다.

위와 같은 방식으로 이미지에 대한 제1 임베딩값(1615) 내지 제n 임베딩값이 데이터베이스(1650) 상에 저장될 수 있다.

다음으로, 사용자는 사용자 장치를 기반으로 서치 구문을 사용하여 이미지 내에 포함된 사람의 수를 문의하는 쿼리를 데이터 처리 시스템으로 전송할 수 있고, 데이터 처리 시스템은 제1 임베딩값(1615)을 기초로 쿼리에 대한 응답을 사용자에게 전달할 수 있다.

비정형 데이터를 임베딩값으로 변화시키는 적어도 하나의 인공지능모델을 포함하는 그룹은 임베딩 인공지능모델 그룹이라는 용어로 표현될 수 있고, 임베딩 인공지능모델 그룹은 하나의 비정형 데이터를 목적에 따라 다양한 임베딩값으로 변화시킬 수 있다.

도 17은 본 발명의 실시예에 따른 컨버트 구문 및 서치 구문을 사용한 결과를 나타낸 개념도이다.

도 17의 (a)는 컨버트 구문을 사용하여 임베딩한 결과가 개시된다.

도 17의 (a)를 참조하면, 영화 리뷰에 대한 텍스트를 임베딩한 결과가 개시된다. 영화에 대한 복수의 리뷰가 존재하고, 복수의 리뷰 각각이 인공지능모델의 특징맵(feature map)을 기반으로 임베딩되어 벡터값으로 변화될 수 있다.

도 17의 (b)는 서치 구문을 사용하여 서치를 수행한 결과가 개시된다.

도 17의 (b)를 참조하면, 영화 리뷰('This movie was my favorite movie of all time')와 가장 유사도가 높은 다른 영화 리뷰를 10개를 우선순위로 찾는 것이다. 영화 리뷰('This movie was my favorite movie of all time')는 임베딩값으로 변화되고, 영화 리뷰와 가장 유사한 임베딩값을 가지는 우선 순위를 10개가 유사도 스코어값을 기준으로 제공될 수 있다.

즉, 본 발명의 실시예에 따르면 데이터 처리 시스템에서 비정형 데이터의 임베딩 방법은 데이터 처리 시스템의 임베딩 인공지능모델 그룹이 비정형 데이터를 임베딩값으로 변화시키는 단계와 데이터 처리 시스템의 데이터베이스가 임베딩값을 저장하는 단계를 포함할 수 있다.

임베딩 인공지능모델 그룹은 필요한 임베딩값을 생성하는 적어도 하나의 서로 다른 인공지능모델을 포함하고, 임베딩값은 적어도 하나의 서로 다른 인공지능모델의 특징맵을 기반으로 결정될 수 있다. 또한, 임베딩값은 확장 SQL 엔진을 기반으로 한 컨버트 구문에 의해 생성되고, 임베딩값은 확장 SQL 엔진을 기반으로 한 서치 구문에 의해 탐색될 수 있다.

도 18은 본 발명의 실시예에 따른 임베딩값을 바이너리화하기 위한 방법을 나타낸 개념도이다.

도 18에서는 추가적인 임베딩값에 대한 바이너리화를 통해 추가적으로 처리 속도를 높이기 위한 방법이 개시된다.

도 18을 참조하면, 데이터 처리 시스템에서 컨버트 과정은 적지 않은 시간과 컴퓨팅 자원이 들어가는 만큼 재사용을 위해 데이터베이스에 저장할 필요가 있다.

임베딩 자체는 고밀도 실수 배열 또는 실수의 리스트의 리스트 (dense array of real numbers or list of lists of floats)이기 때문에 데이터베이스에 저장을 하게 된다면 많은 시간과 자원이 소요되어 추가적인 옵션으로 임베딩값을 바이트 배열 형식으로 저장할 수 있다.

임베딩값이 바이트 배열로 저장함으로써 데이터 테이블을 데이터베이스로 저장하는데 소요되는 시간 및 자원이 감소될 수 있다.

즉, 컨버트되어 생성된 임베딩값은 바이트 배열인 바이너리값으로 다시 한번 변환되고, 데이터베이스에 저장될 수 있다. 서치시 데이터베이스에 불러온 바이트 배열인 바이너리값은 다시 임베딩값으로 변한되어 서치 동작이 이루어질 수 있다.

도 18에서는 본 발명의 실시예에 따른 데이터 처리 시스템에서 비정형 데이터를 임베딩화하는 과정, 임베딩값을 바이너리화하여 바이너리값을 생성하는 과정, 바이너리값을 저장하는 과정, 바이너리된 값을 임베딩값으로 변환하는 과정, 변환된 임베딩값을 기반으로 결과값을 출력하는 과정이 개시된다.

도 18을 참조하면, 비정형 데이터는 컨버트 기능을 사용하여 인공지능모델1 내지 인공지능모델n를 통해 임베딩값으로 변환될 수 있다. 예를 들어, 비정형 데이터는 이미지이고, 임베딩값은 인공지능모델1 내지 인공지능모델n 각각의 이미지에 대한 특징맵에 대한 정보일 수 있다.

예를 들어, 비정형 데이터는 특정 이미지일 수 있고, 인공지능모델1은 이미지 내의 사람의 수에 대한 정보를 제1 임베딩값으로 변환하고, 인공지능모델2는 이미지를 구성하는 장소에 대한 정보를 제2 임베딩값으로 변환하고, 인공지능모델3은 이미지의 색체에 대한 정보를 제3 임베딩값으로 변환할 수 있다.

바이너리 모듈은 제1 임베딩값을 제1 바이너리값으로 변환시키고, 제2 임베딩값을 제2 바이너리값으로 변환시키고, 제3 임베딩값을 제3 바이너리값으로 변환시킬 수 있다.

위와 같은 방식으로 변환된 제1 바이너리값 내지 제n 바이너리값이 데이터베이스 상에 저장될 수 있다.

다음으로, 사용자는 사용자 장치를 통해 서치 구문을 통해 이미지 내에 포함된 사람의 수를 문의하는 쿼리를 데이터 처리 시스템으로 전송할 수 있고, 데이터 처리 시스템의 바이너리 모듈은 제1 바이너리값을 제1 임베딩값으로 변환시키고, 제1 임베딩값을 기초로 쿼리에 대한 응답이 사용자에게 전달할 수 있다.

도 19는 본 발명의 실시예에 따른 바이너리화에 대한 예시이다.

도 19를 참조하면, 바이너리 모듈은 임베딩값을 바이너리값으로 변화시킬 수 있다.

바이너리 모듈은 영화 리뷰 텍스트를 임베딩값으로 변화시키고, 임베딩값을 다시 바이너리값으로 변화시킬 수 있다.

즉, 본 발명의 실시예에 따르면, 데이터 처리 시스템에서 비정형 데이터의 바이너리화 방법은 데이터 처리 시스템의 바이너리 모듈이 비정형 데이터에 대한 임베딩값을 바이너리값으로 변화시키는 단계와 데이터 처리 시스템의 데이터베이스가 바이너리값을 저장하는 단계를 포함할 수 있다.

데이터 처리 시스템의 임베딩 인공지능모델 그룹이 비정형 데이터를 임베딩값으로 변화시키는 단계를 더 포함할 수 있다. 임베딩 인공지능모델 그룹은 필요한 임베딩값을 생성하는 적어도 하나의 서로 다른 인공지능모델을 포함하고, 임베딩값은 적어도 하나의 서로 다른 인공지능모델의 특징맵을 기반으로 결정될 수 있다.

도 20은 본 발명의 실시예에 따른 임베딩값 또는 바이너리값으로 저장하기 위한 방법이 개시된다.

도 20에서는 데이터 처리 시스템이 비정형 데이터를 임베딩값 또는 바이너리값으로 처리하기 위한 방법이 개시된다.

도 20을 참조하면, 데이터 처리 시스템은 1차적으로 비정형 데이터를 바이너리값으로 저장하고, 비정형 데이터의 바이너리값의 활용 빈도를 고려하여 비정형 데이터를 제1 타입 비정형 데이터(2010)와 제2 타입 비정형 데이터(2020)로 구분하여 서로 다른 포맷으로서 데이터베이스 상에 저장할 수 있다.

초기에 바이너리값으로 저장된 비정형 데이터는 디폴트 비정형 데이터(2000)라는 용어로 표현될 수 있다.

디폴트 비정형 데이터(2000)는 제1 타입 비정형 데이터(2010) 또는 제2 타입 비정형 데이터(2020)로 변환 전의 데이터로서 임계 시간 동안 바이너리 값에 대한 사용 빈도수의 통계를 누적하기 전의 데이터일 수 있다. 임계 시간 동안 바이너리 값에 대한 사용 빈도수를 기반으로 디폴트 비정형 데이터(2000)는 제1 타입 비정형 데이터(2010) 또는 제2 타입 비정형 데이터(2020)로 변환될 수 있다.

제1 타입 비정형 데이터(2010)는 임베딩값으로 저장되고, 제2 타입 비정형 데이터(2020)는 바이너리값으로 저장될 수 있다.

제1 타입 비정형 데이터(2010)는 데이터의 사용 빈도가 상대적으로 높은 데이터일 수 있다. 제1 타입 비정형 데이터(2010)는 학습, 예측, 서치 등 다양한 이유로 설정된 시간 내에서 바이너리값에서 임베딩값으로 임계 시간 내에 임계 횟수 이상 변화된 비정형 데이터일 수 있다.

제2 타입 비정형 데이터(2020)는 사용 빈도가 상대적으로 낮은 데이터일 수 있다. 제1 타입 비정형 데이터(2010)는 학습, 예측, 서치 등 다양한 이유로 설정된 시간 내에서 바이너리값에서 임베딩값으로 임계 시간 내에 임계 횟수 미만 변화된 비정형 데이터일 수 있다.

특정 주기별로 제1 타입 비정형 데이터(2010), 제2 타입 비정형 데이터(2020)에 대한 주기별 사용 빈도가 다시 측정될 수 있다. 주기별 사용 빈도를 고려하여 제1 타입 비정형 데이터(2010)는 제1 타입 비정형 데이터(2010)를 유지하거나, 제2 타입 비정형 데이터(2020)로 변화될 수 있다. 마찬가지로 주기별 사용 빈도를 고려하여 제2 타입 비정형 데이터(2020)도 제2 타입 비정형 데이터(2020)를 유지하거나, 제1 타입 비정형 데이터(2010)로 변화될 수 있다.

특정 주기는 사용자들의 제1 타입 비정형 데이터(2010)와 제2 타입 비정형 데이터(2020) 간의 전환이 일어나는 빈도를 고려하여 전환 빈도가 가장 높은 시점을 기준으로 설정되고, 주기의 설정에 따라 변화를 결정하기 위한 임계 사용 빈도는 변화될 수 있다. 특정 주기는 사용자의 워크스페이스 상에서 데이터 활용 빈도를 추가적으로 고려하여 조정될 수도 있다.

도 21은 본 발명의 실시예에 따른 워크스페이스 백업 방법을 나타낸 개념도이다.

도 21에서는 사용자가 데이터 처리 시스템 상에서 본인 소유의 워크스페이스를 백업하기 위한 방법이 개시된다.

도 21을 참조하면, 사용자는 워크스페이스(2160)의 백업을 수행할 수 있다. 워크스페이스(2160)의 백업은 백업 당시의 사용자의 사용자 데이터와 사용자의 워크스페이스 정보에 대한 사용자 메타데이터를 모두 저장하는 것을 말하며 사용자가 실수로 본인의 데이터를 삭제하거나 잃었을 시 백업해 뒀던 백업 파일을 사용하여 복원이 가능하다.

본 발명의 실시예에 따르면, 마스터 서버(2100) 내의 마스터 컨트롤러(2110) 내에 워크스페이스 백업 컨트롤러(2120)가 존재할 수 있다. 워크스페이스 백업 컨트롤러(2120)는 사용자의 요청을 기초로 사용자에 대응되는 워크스페이스(2160)를 제어하는 서버 컨트롤러(2130)로 백업 요청을 전달할 수 있다.

서버 컨트롤러(2130)는 워크스페이스 스토리지 체커(workspace storage checker)(2140), 스토리지 디퍼런스 해셔(storage difference hasher)(2150)를 포함할 수 있다.

워크스페이스 스토리지 체커(2140)는 워크스페이스 백업 스토리지(2170)에 워크스페이스 백업 데이터의 존재를 확인할 수 있다. 워크스페이스 백업 스토리지(2170)에 기존 워크스페이스 백업 데이터가 존재하는 경우, 사용자의 워크스페이스(2160)에 대응되는 스토리지 상의 사용자 데이터 및 사용자 메타데이터와 기존 워크스페이스 백업 데이터를 비교할 수 있다. 현재 스토리지 상의 사용자 데이터 및 사용자 메타데이터는 타겟 워크스페이스 백업 데이터라는 용어로 표현될 수 있다. 즉, 워크스페이스 스토리지 체커(2140)는 기존 워크스페이스 백업 데이터와 타겟 워크스페이스 백업 데이터 간의 비교를 수행할 수 있다. 만약, 워크스페이스 백업 스토리지(2170)에 기존 워크스페이스 백업 데이터가 존재하지 않는 경우, 타겟 워크스페이스 백업 데이터는 워크스페이스 백업 스토리지(2170)로 백업될 수 있다.

스토리지 디퍼런스 해셔(2150)는 변경된 데이터에 대한 해시화를 수행하기 위해 구현될 수 있다. 스토리지 디퍼런스 해셔(2150)는 기존 워크스페이스 백업 데이터와 타겟 워크스페이스 백업 데이터 간의 변경된 데이터가 있다면 그 부분만 해시화 시키고 워크스페이스 백업 스토리지(2170)는 해시 값을 기반으로 기존 워크스페이스 백업 데이터를 업데이트 시킬 수 있다.

이러한 방식으로 사용자 데이터 및 사용자 메타데이터가 백업되어 워크스페이스 백업 스토리지(2170)에 저장될 수 있다.

도 22는 본 발명의 실시예에 따른 워크스페이스 백업 방법을 나타낸 순서도이다.

도 22에서는 사용자가 데이터 처리 시스템 상에서 본인 소유의 워크스페이스를 백업하기 위한 방법이 개시된다.

데이터 처리 시스템의 마스터 서버 내의 마스터 컨트롤러 내에 워크스페이스 백업 컨트롤러가 사용자 백업 요청을 수신할 수 있다(단계 S2200).

워크스페이스 백업 컨트롤러는 사용자 백업 요청을 기반으로 서버 컨트롤러로 사용자 백업 요청을 전달할 수 있다(단계 S2210).

서버 컨트롤러의 워크스페이스 스토리지 체커는 워크스페이스 백업 스토리지에 기존 워크스페이스 백업 데이터의 존재를 확인할 수 있다(단계 S2220).

워크스페이스 백업 스토리지에 기존 워크스페이스 백업 데이터가 존재하는 경우, 사용자의 워크스페이스의 타겟 워크스페이스 백업 데이터와 사용자의 워크스페이스의 기존 워크스페이스 백업 데이터를 비교할 수 있다(단계 S2230).

워크스페이스 백업 스토리지에 기존 워크스페이스 백업 데이터가 존재하지 않는 경우, 타겟 워크스페이스 백업 데이터는 워크스페이스 백업 스토리지로 백업될 수 있다(단계 S2240).

스토리지 디퍼런스 해셔는 기존 워크스페이스 백업 데이터와 타겟 워크스페이스 백업 데이터 간의 변경된 데이터를 기반으로 해시값을 생성한다(단계 S2250).

워크스페이스 백업 스토리지는 해시값을 기반으로 기존 워크스페이스 백업 데이터를 업데이트시킬 수 있다(단계 S2260).

즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서 워크스페이스 백업 방법은 데이터 처리 시스템이 타겟 워크스페이스 백업 데이터와 기존 워크스페이스 백업 데이터를 결정하는 단계, 데이터 처리 시스템이 타겟 워크스페이스 백업 데이터와 기존 워크스페이스 백업 데이터를 비교를 기반으로 해시값을 생성하는 단계와 데이터 처리 시스템이 해시값을 기반으로 기존 워크스페이스를 타겟 워크스페이스로 백업하는 단계를 포함할 수 있다. 기존 워크스페이스는 사용자가 기존에 생성한 워크스페이스이고, 타겟 워크스페이스는 사용자가 기존 워크스페이스를 백업할 대상 워크스페이스이다.

데이터 처리 시스템의 서버 컨트롤러의 워크스페이스 스토리지 체커는 워크스페이스 백업 스토리지에 기존 워크스페이스 백업 데이터의 존재를 확인하고, 워크스페이스 백업 스토리지에 기존 워크스페이스 백업 데이터가 존재하는 경우, 타겟 워크스페이스 백업 데이터와 기존 워크스페이스 백업 데이터를 비교할 수 있다.

도 23은 본 발명의 실시예에 따른 서버 백업 방법을 나타낸 개념도이다.

도 23에서는 사용자가 데이터 처리 시스템 상에서 서버를 백업하기 위한 방법이 개시된다.

도 23을 참조하면, 서버 백업은 자동 백업으로서 모든 서버 관련 데이터를 백업하는 것이다. 서버 백업은 서비스 운영 차원에서 하는 백업으로서 주기적으로 실시될 수 있고, 워크스페이스 단위의 사용자 데이터뿐만 아니라 서버에서 관련되는 전체 워크스페이스에 관련된 서버 데이터 및 서버 메타 데이터에 대한 백업을 수행할 수 있다. 서버 백업은 서버 자체에 문제가 있거나 특정 문제로 인해 서버가 작동을 안 하는 경우를 위한 것이다.

마스터 서버(2300)의 마스터 컨트롤러(2310) 내에 서버 백업 컨트롤러(2320)가 존재할 수 있다. 서버 백업 컨트롤러(2320)는 주기적으로 서버에 대한 백업 요청을 수신하고, 서버의 서버 컨트롤러(2330)에게 백업 요청을 전송할 수 있다.

서버 컨트롤러(2330)는 서버 스토리지 체커(2340)와 스토리지 디퍼런스 해셔(2350)를 포함할 수 있다.

서버 스토리지 체커(2340)는 서버 백업 스토리지(2360)에 기존 서버 백업 데이터가 있는지 확인하고 현재 서버의 서버 데이터, 서버 메타데이터와 비교해 추가/변경/삭제된 데이터가 있는지 확인한다. 변경된 서버 데이터, 변경된 서버 메타데이터가 있다면 변경된 데이터를 기반으로 한 해시값을 생성하여 서버 백업 스토리지(2360)의 기존 서버 백업 데이터를 업데이트할 수 있다.

현재 서버 상의 서버 데이터 및 서버 메타데이터는 타겟 서버 백업 데이터라는 용어로 표현될 수 있다. 즉, 서버 스토리지 체커(2340)는 기존 서버 백업 데이터와 타겟 서버 백업 데이터 간의 비교를 수행할 수 있다. 만약, 서버 백업 스토리지(2360)에 기존 서버 백업 데이터가 존재하지 않는 경우, 타겟 서버 백업 데이터는 서버 백업 스토리지(2360)로 백업될 수 있다.

스토리지 디퍼런스 해셔(2350)는 변경된 데이터에 대한 해시화를 수행하기 위해 구현될 수 있다. 스토리지 디퍼런스 해셔(2350)는 기존 서버 백업 데이터와 타겟 서버 백업 데이터 간의 변경된 데이터가 있다면 변경된 데이터 기반의 해시화를 수행하여 해시값을 생성하고, 서버 백업 스토리지(2360)는 해시값을 기반으로 기존 서버 백업 데이터를 업데이트시킬 수 있다.

이러한 방식으로 서버 데이터 및 서버 메타데이터가 백업되어 서버 백업 스토리지(2360)에 저장될 수 있다.

도 24는 본 발명의 실시예에 따른 서버 백업 방법을 나타낸 순서도이다.

도 24에서는 데이터 처리 시스템 상에서 서버 백업을 수행하기 위한 방법이 개시된다.

데이터 처리 시스템의 마스터 서버 내의 마스터 컨트롤러 내에 서버 백업 컨트롤러가 서버 백업 요청을 수신할 수 있다(단계 S2400).

서버 백업 컨트롤러는 서버 백업 요청을 기반으로 서버 컨트롤러로 서버 백업 요청을 전달할 수 있다(단계 S2410).

서버 컨트롤러의 서버 스토리지 체커는 서버 백업 스토리지에 기존 서버 백업 데이터의 존재를 확인할 수 있다(단계 S2420).

서버 백업 스토리지에 기존 서버 백업 데이터가 존재하는 경우, 서버의 타겟 서버 백업 데이터와 사용자의 워크스페이스의 기존 서버 백업 데이터를 비교할 수 있다(단계 S2430).

서버 백업 스토리지에 기존 서버 백업 데이터가 존재하지 않는 경우, 타겟 서버 백업 데이터는 서버 백업 스토리지로 백업될 수 있다(단계 S2440).

스토리지 디퍼런스 해셔가 기존 서버 백업 데이터와 타겟 서버 백업 데이터 간의 변경된 데이터를 기반으로 결정된 해시값을 생성할 수 있다(단계 S2450).

서버 백업 스토리지는 해시값을 기반으로 기존 서버 백업 데이터를 업데이트시킬 수 있다(단계 S2460).

즉, 본 발명의 실시예에 따른 서버 백업 방법은 데이터 처리 시스템이 타겟 서버 백업 데이터와 기존 서버 백업 데이터를 결정하는 단계, 데이터 처리 시스템이 타겟 서버 백업 데이터와 기존 서버 백업 데이터를 비교를 기반으로 해시값을 생성하는 단계와 데이터 처리 시스템이 해시값을 기반으로 기존 서버를 타겟 서버로 백업하는 단계를 포함할 수 있다.

데이터 처리 시스템의 서버 컨트롤러의 서버 스토리지 체커는 서버 백업 스토리지에 기존 서버 백업 데이터의 존재를 확인하고, 서버 백업 스토리지에 기존 서버 백업 데이터가 존재하는 경우, 타겟 서버 백업 데이터와 기존 서버 백업 데이터를 비교할 수 있다. 해시값은 스토리지 디퍼런스 해셔에 의해 기존 서버 백업 데이터와 타겟 서버 백업 데이터 간의 변경된 데이터를 기반으로 결정될 수 있다.

도 25는 본 발명의 실시예에 따른 워크스페이스 마이그레이션 방법을 나타낸 개념도이다.

도 25에서는 워크스페이스에 대한 마이그레이션을 수행하는 방법이 개시된다.

도 25를 참조하면, 마이그레이션은 기존 서버에 있던 워크스페이스를 새로운 서버로 옮기는 행위를 의미한다.

마이그레이션시에 사용자 마이그레이션 사양(user migration specification)에 따라 사용자에게 배분된 스토리지나 사용자에게 배분된 컴퓨팅 리소스(CPU, GPU, 메모리)가 업데이트 될 수 있다.

사용자는 마이그레이션시 사용자 마이그레이션 사양으로서 스토리지 사이즈 업그레이드, 컴퓨팅 리소스 업그레이드 등을 요청하고, 이러한 사용자 마이그레이션 사양을 고려하여 사용자의 새로운 워크스페이스가 정의될 수 있다.

이하, 기존 사용자의 워크스페이스가 포함된 서버는 기존 서버(2503)라는 이름으로 표현되고, 워크스페이스가 마이그레이션될 서버는 마이그레이션 서버(2506)라는 이름으로 표현될 수 있다.

마스터 서버(2500)의 마스터 컨트롤러(2510)의 워크스페이스 마이그레이션 컨트롤러(2520)는 사용자로부터 마이그레이션 요청을 수신할 수 있다.

워크스페이스 마이그레이션 컨트롤러(2520)는 사용자의 마이그레이션 요청을 받고 마이그레이션 요청을 기반으로 사용자의 워크스페이스의 이전이 가능한 마이그레이션 서버(2506)를 조회할 수 있다. 워크스페이스 마이그레이션 컨트롤러(2520)는 마이그레이션 서버(2506)를 결정하고, 기존 서버(2503)와 마이그레이션 서버(2506)로 마이그레이션 요청을 전달할 수 있다. 마이그레이션 요청은 사용자 마이그레이션 사양에 대한 정보를 포함할 수 있다.

워크스페이스 마이그레이션 컨트롤러(2520)는 마이그레이션 서버(2506)로 마이그레이션을 수행할 것을 요청하는 제1 마이그레이션 요청을 기존 서버(2503)로 전달하고, 기존 서버(2503)로부터 마이그레이션에 따른 데이터를 수신할 것을 요청하는 제2 마이그레이션 요청을 마이그레이션 서버(2506)로 전송할 수 있다.

기존 서버(2503)의 서버 컨트롤러(2530)는 워크스페이스 마이그레이션 센더(workspace migration sender)(2540), 스토리지 해셔 인코더(storage hasher encoder)(2550)를 포함할 수 있다. 워크스페이스 마이그레이션 센더(2540)는 사용자 마이그레이션 데이터(사용자 데이터, 사용자 메타데이터 등)의 백업 데이터를 전송하기 위해 구현될 수 있다.

워크스페이스 마이그레이션 센더(2540)는 기존 서버의 마이그레이션 데이터를 백업하고 스토리지 해셔 인코더(2550)에게 전달할 수 있다.

스토리지 해셔 인코더(2550)는 마이그레이션 데이터를 해시화하고 템포러리 마이그레이션 스토리지(temporary migration storage)에 해시화된 마이그레이션 데이터를 전송할 수 있다.

템포러리 마이그레이션 스토리지(2560)는 기존 서버(2503)의 해시화된 마이그레이션 데이터를 저장하는 스토리지이고, 마이그레이션 서버(2506)로는 해시화된 마이그레이션 데이터를 전달할 수 있다. 템포러리 마이그레이션 스토리지(2560)에 저장된 마이그레이션 데이터는 마이그레이션 프로세스가 끝나는 동시에 삭제될 수 있다.

마이그레이션 서버(2506)의 서버 컨트롤러(2530)는 워크스페이스 마이그레이션 리시버(workspace migration receiver)(2570), 스토리지 해셔 디코더(storage hasher decoder)(2580), 워크스페이스 스포너(workspace spawner)(2590)를 포함할 수 있다.

워크스페이스 마이그레이션 리시버(2570)는 템포러리 마이그레이션 스토리지(2560)로부터 해시화된 마이그레이션 데이터를 수신하고, 해시화된 마이그레이션 데이터는 스토리지 해셔 디코더(2580)로 전달될 수 있다.

스토리지 해셔 디코더(2580)는 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터를 생성할 수 있다. 또한, 스토리지 해셔 디코더(2580)는 사용자 마이그레이션 사양을 고려하여 마이그레이션 서버(2506) 상에 워크스페이스에 관련된 스토리지 및 메타데이터를 생성할 수 있다.

워크스페이스 스포너(workspace spawner)(2590)는 생성된 워크스페이스에 관련된 스토리지 및 메타데이터를 기반으로 마이그레이션 서버(2506) 상에 새로운 워크스페이스를 생성할 수 있다.

마이그레이션 서버(2506) 상에 새로운 워크스페이스가 생성되는 경우, 템포러리 마이그레이션 스토리지(2560)에 저장된 마이그레이션 데이터는 삭제될 수 있다.

도 26은 본 발명의 실시예에 따른 워크스페이스 마이그레이션 방법을 나타낸 순서도이다.

도 26에서는 워크스페이스에 대한 마이그레이션을 수행하는 방법이 개시된다.

도 26을 참조하면, 마스터 서버의 마스터 컨트롤러의 워크스페이스 마이그레이션 컨트롤러가 사용자 장치로부터 마이그레이션 요청을 수신한다(단계 S2600).

워크스페이스 마이그레이션 컨트롤러는 사용자의 마이그레이션 요청을 받고 마이그레이션 요청을 기반으로 사용자의 워크스페이스의 이전이 가능한 마이그레이션 서버를 결정한다(단계 S2610).

워크스페이스 마이그레이션 컨트롤러가 기존 서버와 마이그레이션 서버로 마이그레이션 요청을 전달할 수 있다(단계 S2620).

마이그레이션 요청은 사용자 마이그레이션 사양에 대한 정보를 포함할 수 있다. 워크스페이스 마이그레이션 컨트롤러는 마이그레이션 서버로 마이그레이션을 수행할 것을 요청하는 제1 마이그레이션 요청을 기존 서버로 전달하고, 기존 서버로부터 마이그레이션에 따른 데이터를 수신할 것을 요청하는 제2 마이그레이션 요청을 마이그레이션 서버로 전송할 수 있다.

워크스페이스 마이그레이션 센더는 기존 서버의 마이그레이션 데이터를 백업하고 스토리지 해셔 인코더에게 전달한다(단계 S2630).

스토리지 해셔 인코더는 마이그레이션 데이터를 해시화하고 템포러리 마이그레이션 스토리지에 해시화된 마이그레이션 데이터를 전송한다(단계 S2640).

워크스페이스 마이그레이션 리시버는 템포러리 마이그레이션 스토리지로부터 해시화된 마이그레이션 데이터를 수신하고, 해시화된 마이그레이션 데이터를 스토리지 해셔 디코더로 전달한다(단계 S2650).

스토리지 해셔 디코더는 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터를 생성하고, 사용자 마이그레이션 사양을 고려하여 마이그레이션 서버 상에 워크스페이스에 관련된 스토리지 및 메타데이터를 생성한다(단계 S2660).

워크스페이스 스포너(workspace spawner)는 생성된 워크스페이스에 관련된 스토리지 및 메타데이터를 기반으로 마이그레이션 서버 상에 새로운 워크스페이스를 생성한다(단계 S2670).

즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서 워크스페이스 마이그레이션 방법은 데이터 처리 시스템이 기존 서버에 위치한 제1 워크스페이스의 마이그레이션 데이터를 백업하고 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계, 데이터 처리 시스템이 마이그레이션 데이터를 기반으로 마이그레이션 서버 상에 제2 워크스페이스를 생성하는 단계를 포함할 수 있다.

마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계는 워크스페이스 마이그레이션 센더가 기존 서버의 마이그레이션 데이터를 백업하고 스토리지 해셔 인코더에게 전달하는 단계, 스토리지 해셔 인코더가 마이그레이션 데이터를 해시화하고 템포러리 마이그레이션 스토리지에 해시화된 마이그레이션 데이터를 전송하는 단계와 템포러리 마이그레이션 스토리지가 기존 서버의 해시화된 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계를 포함할 수 있다.

제2 워크스페이스를 생성하는 단계는 워크스페이스 마이그레이션 리시버가 템포러리 마이그레이션 스토리지로부터 해시화된 마이그레이션 데이터를 수신하고, 해시화된 마이그레이션 데이터를 스토리지 해셔 디코더로 전달하는 단계, 스토리지 해셔 디코더가 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터를 생성하는 단계, 스토리지 해셔 디코더가 사용자 마이그레이션 사양을 고려하여 마이그레이션 서버 상에 워크스페이스에 관련된 스토리지 및 메타데이터를 생성하는 단계, 워크스페이스 스포너가 워크스페이스에 관련된 스토리지 및 메타데이터를 기반으로 마이그레이션 서버 상에 제2 워크스페이스를 생성하는 단계를 포함할 수 있다.

도 27은 본 발명의 실시예에 따른 서버 마이그레이션 방법을 나타낸 개념도이다.

도 27에서는 서버 자체를 마이그레이션하는 서버 마이그레이션 방법이 개시된다.

도 27을 참조하면, 서버 마이그레이션은 기존 서버(2703)를 새로운 마이그레이션 서버(2706)로 옮기는 행위이다. 예를 들어, 기존 서버(2703)의 스토리지, 컴퓨팅 리소스의 사이즈를 변화시킨 새로운 서버로 서버 자체의 이동이 필요할 수 있다. 이러한 경우, 서버 마이그레이션이 수행될 수 있다. 이하, 설명의 편의상 마이그레이션된 새로운 서버는 마이그레이션 서버(2706)라는 용어로 표현될 수 있다.

마스터 서버(2700)의 마스터 컨트롤러(2710)는 서버 상태 모니터(server status monitor)(2720)와 서버 마이그레이션 컨트롤러(2730)를 포함할 수 있다.

서버 상태 모니터(2720)는 서버 상태를 모니터링하기 위해 구현될 수 있다. 서버 상태 모니터(2720)는 스케줄링을 기반으로 서버 컨트롤러(2740)에 위치한 상태 체커(status checker)(2750)와 통신할 수 있다. 상태 체커(2750)는 기존 서버(2703)의 스토리지 및/또는 리소스에 대한 상태를 체크할 수 있다. 서버 상태 모니터(2720)는 스토리지 상태 정보 및 리소스 상태 정보를 수신할 수 있다. 서버 상태 모니터(2720)는 스토리지 및/또는 리소스가 부족한 경우, 서버 마이그레이션 컨트롤러(2730)로 서버 마이그레이션 요청을 전송할 수 있다.

서버 마이그레이션 요청은 서버 마이그레이션 사양(server migration specification)을 포함할 수 있고, 서버 마이그레이션 사양은 마이그레이션 서버(2706)에 요청되는 스펙(예를 들어, 스토리지, 컴퓨팅 자원)에 대한 정보를 포함할 수 있다.

서버 마이그레이션 컨트롤러(2730)는 서버 마이그레이션 요청을 기반으로 기존 서버를 마이그레이션할 마이그레이션 서버(2706)를 결정할 수 있다. 서버 마이그레이션 컨트롤러(2730)는 서버 마이그레이션 요청을 기반으로 이전 가능한 새로운 마이그레이션 서버(2706)를 조회하고 요청을 전달할 수 있다.

서버 마이그레이션 컨트롤러(2730)는 서버 컨트롤러(2740)로 서버 마이그레이션 요청을 전송할 수 있다.

서버 컨트롤러(2740)는 상태 체커(2750), 서버 마이그레이션 센더(server migration sender)(2760), 스토리지 해시 인코더(storage hash encoder)(2770)를 포함할 수 있다.

서버 마이그레이션 센더(2760)는 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성할 수 있다. 서버 마이그레이션 센더(2760)는 서버 마이그레이션 데이터를 스토리지 해시 인코더(2770)로 전달할 수 있다.

스토리지 해시 인코더(2770)는 서버 마이그레이션 데이터를 해시화하고 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지(temporary migration storage)(2780)로 전송할 수 있다.

템포러리 마이그레이션 스토리지(2780)는 해시화된 서버 마이그레이션 데이터를 저장할 수 있다.

템포러리 마이그레이션 스토리지(2780)는 마이그레이션 서버(2706)의 서버 마이그레이션 리시버(2765)로 해시화된 마이그레이션 데이터를 전송할 수 있다.

해시화된 마이그레이션 데이터는 스토리지 해시 디코더(2775)를 통해 디코딩되어 마이그레이션 데이터로 변환될 수 있다.

스토리지 해시 디코더(2775)는 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터(또는 기존 서버의 모든 워크스페이스에 관련된 스토리지 및 메타데이터)를 생성할 수 있다.

워크스페이스 스포너(2780)는 서버에 관련된 스토리지 및 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 마이그레이션 서버(2706) 상에 생성할 수 있다.

템포러리 마이그레이션 스토리지(temporary migration storage)(2780)는 해시화된 서버 마이그레이션 데이터를 삭제할 수 있다.

도 28은 본 발명의 실시예에 따른 서버 마이그레이션 방법을 나타낸 순서도이다.

도 28에서는 서버에 대한 마이그레이션을 수행하는 방법이 개시된다.

도 28을 참조하면, 서버 상태 모니터가 스토리지 및/또는 리소스가 부족한 경우, 서버 마이그레이션 컨트롤러로 서버 마이그레이션 요청을 전송할 수 있다(단계 S2800)

서버 마이그레이션 컨트롤러가 서버 마이그레이션 요청을 기반으로 기존 서버를 마이그레이션할 마이그레이션 서버를 결정할 수 있다(단계 S2810).

서버 마이그레이션 컨트롤러가 서버 컨트롤러로 서버 마이그레이션 요청을 전송할 수 있다(단계 S2820).

서버 마이그레이션 센더가 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성한다(단계 S2830).

서버 마이그레이션 센더는 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달한다(단계 S2840).

스토리지 해시 인코더가 서버 마이그레이션 데이터를 해시화한다(단계 S2850).

스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송한다(단계 S2855).

템포러리 마이그레이션 스토리지가 해시화된 서버 마이그레이션 데이터를 저장한다(단계 S2860).

템포러리 마이그레이션 스토리지가 마이그레이션 서버의 서버 마이그레이션 리시버로 해시화된 마이그레이션 데이터를 전송한다(단계 S2865).

해시화된 마이그레이션 데이터는 스토리지 해시 디코더를 통해 디코딩되어 마이그레이션 데이터로 변환된다(단계 S2870).

스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터(또는 기존 서버의 모든 워크스페이스에 관련된 스토리지 및 메타데이터)를 생성한다(단계 S2875).

워크스페이스 스포너가 서버에 관련된 스토리지 및 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 마이그레이션 서버 상에 생성한다(단계 S2880).

템포러리 마이그레이션 스토리지(temporary migration storage)(2780)는 해시화된 서버 마이그레이션 데이터를 삭제할 수 있다.

즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서 서버 마이그레이션 방법은 데이터 처리 시스템이 기존 서버의 마이그레이션 데이터를 백업하고 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계와 데이터 처리 시스템이 마이그레이션 데이터를 기반으로 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계를 포함할 수 있다.

마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계는 서버 마이그레이션 센더가 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성하는 단계, 서버 마이그레이션 센더가 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달하는 단계, 스토리지 해시 인코더가 서버 마이그레이션 데이터를 해시화하는 단계, 스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송하는 단계와 템포러리 마이그레이션 스토리지가 마이그레이션 서버의 서버 마이그레이션 리시버로 해시화된 마이그레이션 데이터를 전송하는 단계를 포함할 수 있다.

또한, 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계는 스토리지 해시 디코더가 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터로 변환하는 단계, 스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터를 생성하는 단계와 워크스페이스 스포너가 스토리지 및 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 마이그레이션 서버 상에 생성하는 단계를 포함할 수 있다.

도 29는 본 발명의 실시예에 따른 비정형 모델 캐싱 방법을 나타낸 개념도이다.

도 29에서는 비정형 모델의 캐싱을 위한 방법이 개시된다.

도 29를 참조하면, 캐시(cache)(2950)는 일반적으로 일시적인 특징이 있는 데이터 하위 집합을 저장하는 고속 데이터 스토리지 계층이다. 따라서, 캐시(2950) 상에 데이터가 존재할 경우, 데이터의 기본 스토리지 위치에 액세스할 때보다 더 빠르게 요청이 처리될 수 있다.

캐싱(caching)은 캐시(2950) 상에 데이터를 업로드하고 데이터를 처리하는 것이다. 캐싱이 사용되는 경우, 이전에 검색하거나 계산한 캐시(2950) 상의 데이터가 효율적으로 재사용될 수 있다. 캐싱은 통상적으로 계산 비용이 높거나 자주 호출되는 함수나 데이터를 더 빠르게 요청하고 처리하는 데 사용될 수 있다.

본 발명의 데이터 처리 시스템은 인공지능모델을 캐싱하는 기술 및 어떠한 인공지능모델을 캐싱할지에 대한 캐싱 알고리즘을 통해 인공지능모델을 캐시(2950) 상에 업로드하여 사용할 수 있다.

인공지능모델의 캐싱은 아래와 같은 효과를 가질 수 있다. 예를 들어, 인공지능모델을 로드하는데 필요한 컴퓨팅 자원과 시간이 감소될 수 있다. 또한, 인공지능모델의 캐싱을 통해 보다 빠르게 인공지능모델의 결과값이 출력될 수 있다.

본 발명의 실시예에 따르면, 인공지능모델의 캐싱은 SQL 엔진(예를 들어, 확장 SQL 엔진) 내부의 구문(clause)(2900)(예를 들어, SEARCH, CONVERT, PREDICT, EVALUATE, etc.) 등에 내장된다. 따라서, 사용자가 따로 트리거(trigger) 및 캐싱을 하기 위한 별도의 절차없이도 알고리즘 기반의 인공지능모델의 캐싱이 수행될 수 있다.

인공지능엔진의 캐싱은 아래와 같은 알고리즘이 사용될 수 있다.

예를 들어, 디폴트 캐싱 알고리즘으로 제1 캐싱 알고리즘이 사용될 수 있다. 제1 캐싱 알고리즘은 최근에 사용되지 않은 인공지능모델 순서로 캐시 상에 제공하는 알고리즘이다. 캐시가 꽉 차면 가장 오래된 인공지능모델이 제거되고, 새로운 인공지능모델을 로딩할 공간이 생성될 수 있다. 즉, 제1 캐싱 알고리즘은 많이 사용되는 인공지능모델을 자주 접근할 수 있도록 하여서 데이터를 자주 입력하거나 출력하는 인공지능모델이 특정될수록 성능이 향상될 수 있다.

본 발명의 실시예에서는 제1 캐싱 알고리즘이 사용되어 인공지능모델이 캐시 상에 업로드되어 최근에 사용한 인공지능모델이 캐시 상에 로드될 수 있도록 할 수 있고, 최근에 사용되지 않은 인공지능 모델일수록 추가적인 인공지능모델의 캐시 상의 로드가 필요시 캐시 상에서 삭제될 수 있다.

본 발명의 실시예에 따른 인공지능모델의 캐싱을 위해서는 자원이 사용되고, 자원의 효율적인 관리를 위해서는 전술한 워크스페이스 생성 및 워크스페이스 구조를 기반으로 분배된 컴퓨팅 자원(CPU, GPU, 메모리)을 고려하여 가장 효율적인 인공지능모델의 캐싱 알고리즘이 선택될 수 있다.

인공지능모델의 캐싱을 위해 캐시 상에 캐싱되는 인공지능모델의 개수, 캐싱시 사용되는 캐싱 알고리즘이 다양하게 고려될 수 있다. 또한, 사용자에게 할당된 컴퓨팅 자원에 따라 캐시에 저장 가능한 인공지능모델의 수는 달라질 수 밖에 없다. 따라서, 사용자별로 제1 캐싱 알고리즘 외에 다른 다양한 캐싱 알고리즘이 사용되어 캐시 상에 인공지능모델이 로딩될 수 있다.

본 발명에서 사용될 수 있는 다른 캐싱 알고리즘으로 아래와 같은 캐싱 알고리즘이 사용될 수 있다.

제2 캐싱 알고리즘은 타임 스탬프를 추가적으로 캐시 상에 로드된 인공지능모델에 할당하고, 캐시 상에 인공지능모델이 로드된 시간을 추가적으로 고려하여 인공지능모델을 캐시 상에서 삭제할 수 있다. 제2 캐싱 알고리즘은 특정 기간 동안 사용되지 않은 인공지능 모델 중 가장 최근에 사용되지 않은 인공지능모델을 삭제하는 방식으로 캐시를 관리할 수 있다. 제2 캐싱 알고리즘은 오래된 항목을 더 적극적으로 제거하여 캐시 공간을 최대한 활용하기 위해 사용될 수 있다. 즉, 제2 캐싱 알고리즘에서 설정된 임계 시간 후에 가장 마지막에 엑세스 된 인공지능 모델이 삭제되는 반면, 제1 캐싱 알고리즘에서는 시간이 아닌 지정된 숫자까지의 인공지능모델을 캐시 상에 로드하는 알고리즘이기 때문에 다음 모델이 캐시에 로드될 때까지 마지막에 엑세스된 인공지능모델이 캐시 상에 존재할 수 있다.

제3 캐싱 알고리즘은 비트마스크를 기반으로 인공지능모델의 액세스 상태를 추적하고, 가장 오래전에 액세스된 인공지능모델은 삭제될 수 있다. 비트 마스크는 캐시 라인에 저장된 모든 모델의 액세스 상태를 추적하는 데 사용되는 데이터 구조이다. 비트 마스크는 각 인공지능모델에 대해 하나 이상의 비트를 가지며, 비트의 위치는 각 인공지능모델의 위치에 대응된다. 각 비트는 모델의 액세스 상태를 나타내며, 0 또는 1로 설정된다. 즉, 캐시 라인의 각 인공지능모델에 대해 비트마스크를 사용하여 모델의 액세스 상태가 추적되고, 최근에 액세스된 모델을 찾을 때 사용될 수 있다.

제4 캐싱 알고리즘은 사용된 인공지능모델을 캐시 상에 유지하고 캐시가 가득 차서 새로운 인공지능모델을 추가할 때 가장 최근에 캐시로 추가된 인공지능모델이 대체되거나 삭제되는 알고리즘이다. 지정한 숫자의 인공지능모델이 캐시 상에 로드될 때까지는 캐시 상에서 인공지능모델이 삭제되지 않지만 지정된 숫자를 넘어간다면 가장 최근에 추가된 인공지능모델이 캐시 상에서 삭제될 수 있다.

즉, 본 발명의 실시예에 따른 데이터 처리 시스템에서 비정형 모델 캐싱 방법은 데이터 처리 시스템이 캐시 상에 복수의 인공지능모델을 캐싱하는 단계, 데이터 처리 시스템이 캐싱 알고리즘을 기반으로 복수의 인공지능 모델 중 적어도 하나의 인공지능모델을 교체하는 단계를 포함할 수 있다.

도 30은 본 발명의 실시예에 따른 제1 캐싱 알고리즘을 나타낸 개념도이다.

도 30에서는 제1 캐싱 알고리즘을 기반으로 인공지능엔진의 교체가 개시된다.

도 30을 참조하면, 제1 캐싱 알고리즘은 캐시 상에 사용자가 사용하는 인공지능모델을 고려하여 인공지능모델A, 인공지능모델B, 인공지능모델C, 인공지능모델D를 순차적으로 로드할 수 있다.

캐시에 추가적으로 인공지능모델E가 추가되어야 하고, 캐시 상에 로딩된 인공지능모델들 중 가장 최근에 사용되지 않은 인공지능모델이 인공지능모델A인 경우, 인공지능모델A가 캐시 상에서 삭제되고, 해당 자리에 인공지능모델E가 추가될 수 있다.

이후 추가적으로 인공지능모델F가 캐시 상에 로딩될 필요가 있고, 캐시 상에 로딩된 인공지능모델들 중 가장 최근에 사용되지 않은 인공지능모델이 인공지능모델이 인공지능모델D인 경우, 인공지능모델D는 삭제되고, 인공지능모델 F가 캐시 상에 로딩될 수 있다.

도 31은 본 발명의 실시예에 따른 비정형 모델 캐싱 방법을 나타낸 개념도이다.

도 31에서는 비정형 모델의 캐싱을 위한 방법이 개시된다.

도 31을 참조하면, 전술한 바와 같이 워크스페이스 허브는 공유 아키텍쳐(shared architecture)를 기반으로 구현되는 공유 워크스페이스 허브와 전용 아키텍쳐(dedicated architecture)를 기반으로 구현되는 전용 워크스페이스 허브를 포함할 수 있다. 공유 워크스페이스 허브와 전용 워크스페이스 허브는 워크스페이스를 포함할 수 있다. 공유 워크스페이스 허브는 복수의 사용자들의 복수의 워크스페이스를 포함할 수 있고, 공유 워크스페이스 허브는 할당된 데이터 처리 엔진, 할당된 프로세싱 자원을 공유할 수 있다. 전용 워크스페이스 허브는 하나의 사용자에 대한 워크스페이스를 포함하고, 전용 워크스페이스 허브에는 하나의 사용자가 전용으로 사용할 데이터 처리 엔진 및 프로세싱 자원이 할당될 수 있다.

본 발명의 실시예에서는 워크스페이스의 특성에 따라 디폴트 캐시 알고리즘이 서로 다르게 설정될 수 있다.

공유 워크스페이스 허브(또는 공유 워크스페이스)에서는 TLRU 캐시 알고리즘이 사용될 수 있다.

TLRU 캐시 알고리즘은 캐시 상에 로딩되는 캐시 오브젝트(cache object)인 인공지능 모델에 대해 타임스탬프(time-stamp)를 할당할 수 있다. 타임 스탬프를 할당함으로써 가장 많이 사용되지 않은 인공지능모델이 캐시 상에서 삭제될 뿐만 아니라, 할당된 시간이 많이 지난 모델도 캐시 상에서 삭제될 수 있다.

즉, 공유 워크스페이스에서는 복수의 유저가 동일한 컴퓨팅 자원을 공유할 수 있으므로, 이러한 TLRU 캐시 알고리즘을 통해 보다 효율적으로 캐시 상의 인공지능모델을 삭제할 수 있다.

전용 워크스페이스 허브(또는 전용 워크스페이스)에서는 LRU 캐시 알고리즘이 디폴트 캐시 알고리즘으로서 사용될 수 있다. 전용 워크스페이스에서는 LRU 캐시 알고리즘이 디폴트 캐시 알고리즘으로서 사용될 수 있다. 전용 워크스페이스에서는 사용자의 모델 사용 데이터, 모델 사용 로그를 기반으로 캐시 알고리즘이 변화되어 적용될 수 있다.

이상 설명된 본 발명에 따른 실시예는 다양한 컴퓨터 구성요소를 통하여 실행될 수 있는 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능한 기록 매체는 프로그램 명령어, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 컴퓨터 판독 가능한 기록 매체에 기록되는 프로그램 명령어는 본 발명을 위하여 특별히 설계되고 구성된 것이거나 컴퓨터 소프트웨어 분야의 당업자에게 공지되어 사용 가능한 것일 수 있다. 컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등과 같은, 프로그램 명령어를 저장하고 실행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령어의 예에는, 컴파일러에 의하여 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용하여 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위하여 하나 이상의 소프트웨어 모듈로 변경될 수 있으며, 그 역도 마찬가지이다.

이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항과 한정된 실시예 및 도면에 의하여 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위하여 제공된 것일 뿐, 본 발명이 상기 실시예에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정과 변경을 꾀할 수 있다.

따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 또는 이로부터 등가적으로 변경된 모든 범위는 본 발명의 사상의 범주에 속한다고 할 것이다.

Claims (6)

1. 데이터 처리 시스템에서 서버 마이그레이션 방법은,
   데이터 처리 시스템이 기존 서버의 마이그레이션 데이터를 백업하고 상기 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계; 및
   상기 데이터 처리 시스템이 상기 마이그레이션 데이터를 기반으로 상기 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계를 포함하되,
   상기 데이터 처리 시스템은 워크 스페이스를 포함하고,
   상기 워크 스페이스는 네스티드 쿼리를 기반으로 정형 데이터 및 비정형 데이터를 처리하고,
   상기 비정형 데이터는 비정형 데이터 처리 쿼리를 기반으로 처리되고,
   상기 정형 데이터는 정형 데이터 처리 쿼리를 기반으로 처리되고,
   상기 네스티드 쿼리는 상기 비정형 데이터에 대한 제1 쿼리 및 상기 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리이고,
   상기 비정형 데이터 처리 쿼리는 상기 비정형 데이터만을 처리하기 위한 쿼리이고,
   상기 정형 데이터 처리 쿼리는 상기 정형 데이터만을 처리하기 위한 쿼리이고,
   상기 데이터 처리 시스템은 확장된 SQL(extended structured query language)을 기반으로 상기 비정형 데이터 및 상기 정형 데이터를 사용한 인공지능엔진 모델링을 별도의 배치 프로세스 없이 하나의 플랫폼 상에서 수행하도록 하고,
   상기 네스티드 쿼리에 대한 처리는,
   상기 데이터 처리 시스템이 상기 확장된 SQL을 처리하는 확장 SQL 엔진을 기반으로 상기 비정형 데이터에 대한 처리를 수행하는 단계; 및
   상기 데이터 처리 시스템이 Postgre SQL(structured query language)을 처리하는 일반 SQL 엔진을 기반으로 상기 정형 데이터에 대한 처리를 수행하는 단계를 기반으로 수행되고,
   상기 확장된 SQL은 상기 비정형 데이터를 처리하기 위해 정의된 쿼리 언어이고,
   상기 Postgre SQL은 상기 정형 데이터를 처리하기 위해 정의된 쿼리 언어인 것을 특징으로 하는 방법.
2. 삭제
3. 제1항에 있어서,
   상기 마이그레이션 데이터를 마이그레이션 서버로 전송하는 단계는,
   서버 마이그레이션 센더가 상기 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성하는 단계;
   상기 서버 마이그레이션 센더가 상기 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달하는 단계;
   상기 스토리지 해시 인코더가 상기 서버 마이그레이션 데이터를 해시화하는 단계;
   상기 스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송하는 단계; 및
   상기 템포러리 마이그레이션 스토리지가 상기 마이그레이션 서버의 서버 마이그레이션 리시버로 상기 해시화된 마이그레이션 데이터를 전송하는 단계를 포함하고,
   상기 기존 서버에 존재하는 모든 워크스페이스를 생성하는 단계는,
   스토리지 해시 디코더가 상기 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터로 변환하는 단계;
   상기 스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터를 생성하는 단계; 및
   워크스페이스 스포너가 상기 스토리지 및 상기 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 상기 마이그레이션 서버 상에 생성하는 단계를 포함하는 것을 특징으로 하는 방법.
4. 서버 마이그레이션을 수행하는 데이터 처리 시스템은,
   기존 서버의 마이그레이션 데이터를 백업하고 상기 마이그레이션 데이터를 마이그레이션 서버로 전송하고,
   상기 마이그레이션 데이터를 기반으로 상기 마이그레이션 서버 상에 기존 서버에 존재하는 모든 워크스페이스를 생성하도록 구현되되,
   상기 데이터 처리 시스템은 워크 스페이스를 포함하고,
   상기 워크 스페이스는 네스티드 쿼리를 기반으로 정형 데이터 및 비정형 데이터를 처리하고,
   상기 비정형 데이터는 비정형 데이터 처리 쿼리를 기반으로 처리되고,
   상기 정형 데이터는 정형 데이터 처리 쿼리를 기반으로 처리되고,
   상기 네스티드 쿼리는 상기 비정형 데이터에 대한 제1 쿼리 및 상기 정형 데이터에 대한 제2 쿼리를 혼합한 쿼리이고,
   상기 비정형 데이터 처리 쿼리는 상기 비정형 데이터만을 처리하기 위한 쿼리이고,
   상기 정형 데이터 처리 쿼리는 상기 정형 데이터만을 처리하기 위한 쿼리이고,
   상기 데이터 처리 시스템은 확장된 SQL(extended structured query language)을 기반으로 상기 비정형 데이터 및 상기 정형 데이터를 사용한 인공지능엔진 모델링을 별도의 배치 프로세스 없이 하나의 플랫폼 상에서 수행하도록 하고,
   상기 네스티드 쿼리에 대한 처리는,
   상기 데이터 처리 시스템이 상기 확장된 SQL을 처리하는 확장 SQL 엔진을 기반으로 상기 비 정형 데이터에 대한 처리를 수행하는 단계; 및
   상기 데이터 처리 시스템이 Postgre SQL(structured query language)을 처리하는 일반 SQL 엔진을 기반으로 상기 정형 데이터에 대한 처리를 수행하는 단계를 기반으로 수행되고,
   상기 확장된 SQL은 상기 비정형 데이터를 처리하기 위해 정의된 쿼리 랭귀지이고,
   상기 Postgre SQL은 상기 정형 데이터를 처리하기 위해 정의된 쿼리 랭귀지 인 것을 특징으로 하는 데이터 처리 시스템.
5. 삭제
6. 제4항에 있어서,
   상기 데이터 처리 시스템은 서버 마이그레이션 센더가 상기 기존 서버에 대한 백업을 통해 서버 마이그레이션 데이터를 생성하고,
   상기 서버 마이그레이션 센더가 상기 서버 마이그레이션 데이터를 스토리지 해시 인코더로 전달하고,
   상기 스토리지 해시 인코더가 상기 서버 마이그레이션 데이터를 해시화하고,
   상기 스토리지 해시 인코더가 해시화된 서버 마이그레이션 데이터를 템포러리 마이그레이션 스토리지로 전송하고,
   상기 템포러리 마이그레이션 스토리지가 상기 마이그레이션 서버의 서버 마이그레이션 리시버로 상기 해시화된 마이그레이션 데이터를 전송하도록 구현되고,
   상기 데이터 처리 시스템은 스토리지 해시 디코더가 상기 해시화된 마이그레이션 데이터를 디코딩하여 마이그레이션 데이터로 변환하고,
   상기 스토리지 해시 디코더가 서버 마이그레이션 사양을 기반으로 마이그레이션 서버에 적용될 스토리지 및 메타데이터를 생성하고,
   워크스페이스 스포너가 상기 스토리지 및 상기 메타데이터를 기반으로 기존 서버에 존재하는 모든 워크스페이스를 상기 마이그레이션 서버 상에 생성하도록 구현되는 것을 특징으로 하는 데이터 처리 시스템.

Images