KR20190069229A - 분산 인메모리 이동 객체 관리 시스템 및 방법 - Google Patents

Abstract

스파크(Spark)에 기반한 이동객체 인덱싱을 포함하는 분산 인메모리(in-memory) 이동 객체 관리 시스템 및 방법이 개시된다. 이동객체 관리 시스템은, 차량을 포함하는 이동 객체로부터 위치 데이터를 수집하고 차량과 관련된 사용자 단말의 질의를 수신하는 데이터 및 쿼리 수집기, 데이터 및 쿼리 수집기로부터의 데이터에 대하여 그리드 기반의 시공간 인덱스 구조를 생성하고 시간에 따라 여러 버전의 서브 색인들을 만들고 미리 설정된 최근 시간 범위의 서브 색인들을 메모리에 유지하는 인덱스 관리자, 및 시간에 따라 생성된 상기 여러 버전의 서브 색인들 중 미리 설정된 시간 이전의 오래된 서브 색인들을 데이터베이스에 저장하고 데이터 및 쿼리 수집기로부터의 신호에 따라 데이터베이스에 저장된 오래된 서브 색인들을 메모리에 로드하는 데이터 관리자를 포함한다.

Description

분산 인메모리 이동 객체 관리 시스템 및 방법{METHOD AND SYSTEM FOR MANAGING MOVING OBJECTS IN DISTRIBUTED MEMORY}

본 발명의 실시예는 스파크(Spark)에 기반한 이동객체 인덱싱을 포함하는 분산 인메모리(in-memory) 이동 객체 관리 시스템 및 방법에 관한 것이다.

스마트폰, 스마트 블랙박스 및 태블릿 PC와 같은 GPS(global positioning system) 가능 모바일 장치의 사용이 확산되면서 시공간 데이터의 양이 폭발적으로 증가하고 있다. 이동 객체(Moving Objects)의 위치 및 시간 쌍은 중요한 시공간 데이터의 한 유형이다.

일반적으로 이동 객체는 이동하면서 주기적으로 자신의 위치와 시간을 서버로 전송한다. 이동 객체의 수가 많아지고 위치 및 시간을 전송하는 주기가 짧아지면 이동 객체의 위치를 처리하는 오버 헤드는 증가하여 이동객체 응용의 병목 현상이 된다.

객체의 응용이 보다 정확한 위치를 필요로 한다면, 전송 기간은 더 짧아져야 한다. 예를 들면, 이동 객체의 수가 6백만이고 전송 주기가 1분일 때 서버는 초당 100,000 회의 업데이트를 수행해야 한다고 알려져 있다. 이 경우 서버는 10 마이크로 초마다 하나의 업데이트를 처리해야 하는 워크로드를 갖는다.

객체 처리를 위한 디스크 기반 데이터 구조 및 알고리즘으로 발생하는 병목 현상을 줄이기 위해 여러 인메모리 인덱싱(In-Memory Indexing) 방법이 제안되었다. 이러한 종래 기술은 고속의 CPU(central processing unit) 캐시 사용을 최적화하는 캐시를 고려한 R-tree를 제안하고 있다. 또한, 종래 기술에서 제안하는 다른 방법에서는 질의 결과의 정확성과 이동 객체의 위치 업데이트 및 질의 효율성 간의 트레이드 오프를 고려하여 짧은 수명의 색인을 빈번하게 구축한다.

또한, 또 다른 종래 방법에서는 멀티 코어 프로세서의 병렬 처리를 활용할 수 있는 메모리 인덱스를 제안한다. 이 방법은 일관된 데이터베이스 상태를 유지하고 정확한 질의 결과를 반환하기 위해서 일반적으로 잠금 기술에서 사용하는 쿼리와 업데이트 간의 충돌을 피하도록 구성되어 있다.

또한, 종래의 다른 일부 연구에서는 이동 객체의 위치 데이터를 처리하기 위한 병렬 및 분산 인덱싱 방법이 제안되었다. 관련 연구로는 MDHbase, Hadoop GIS, Spatial Hadoop, Parallel Secondo, Tornado 등이 있다. 이 방법들에서는 비공유(Shared Nothing) 서버 클러스터를 기반으로 많은 양의 위치 데이터를 저장하고 질의처를 수행한다. 그러나 여전히 디스크 액세스로 인한 병목 현상이 존재한다.

한편, 메인 메모리 비용이 현저하게 감소하면서 메인 메모리 기반 분산 처리 시스템에 대한 연구가 활발해지고 있다. Apache Spark는 대규모 데이터 처리 시스템을 위한 오픈 소스 범용 엔진이다. 이 엔진은 하둡 맴리듀스(Hadoop MapReduce)에서 작업에 대한 계산을 반복적으로 수행할 때 발생하는 I/O 병목 현상을 피하기 위해 인메모리(in-memory) 클러스터 컴퓨팅을 환경을 제공한다.

Apache Spark는 MapReduce의 내결함성, 지역성 및 확장성을 유지하면서 높은 성능을 제공하기 위해 RDD(Resilient Distributed Dataset)라고 하는 모델을 제안했다. RDD는 동일한 작업을 많은 데이터 항목(예컨대, 지도, 필터 또는 조인)에 적용하는 대용량 업데이트만 허용한다. 또한, Apache Spark는 현재 RDD를 만들어 내는데 사용된 작업 내역을 유지하고 특정 노드가 가지고 있던 데이터를 유실할 경우 작업 내역을 재수행하여 내결함성을 제공할 수 있다.

아파치 스파크 스트리밍(Apache Spark Streaming)은 실시간 데이터를 처리하기 위해 Apache Spark를 확장한 것이다. 실시간 데이터 스트림을 초 단위로 나누어 마이크로 배치 RDD를 만들고 Spark에서 제공하는 RDD 처리 방법을 이용하여 데이터를 처리한다. 아파치 스파크 스트리밍의 이러한 접근 방식을 불연속된 스트림(Discretized Stream 또는 D-Stream)이라고 한다.

전술한 종래 기술은 Spark를 기반으로 하는 이동객체 인덱싱 방법을 제안하여 분산된 컴퓨터의 주 메모리에 위치 데이터 및 이에 대한 색인을 저장하고 처리한다. 그러나 이 방법에서는 메모리가 가득 찬 경우를 고려하지 않고 있으며, 메모리가 가득 차면 메모리에 분산 저장된 인덱스 구조와 위치 데이터는 Spark의 처리 절차에 따라서 처리된다.

본 발명은 스파크(Spark)에 기반한 이동객체의 인메모리(in-memory) 분산 색인을 포함하는 분산 인메모리 이동 객체 관리 시스템을 제공하는데 그 목적이 있다.

본 발명의 다른 목적은 이동객체의 위치데이터를 효과적으로 처리할 수 있는, 스파크에 기반한 분산 인메모리 이동 객체 관리 방법을 제공하는데 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 측면에 따른 분산 인메모리 이동 객체 관리 시스템은, 데이터 및 쿼리 수집기(Data & Query Collector), 인덱스 관리자(Index Manager), 질의 관리자(Query Manager) 및 데이터 관리자(Data Manager)를 포함하여 이루어진다.

일실시예에서, 데이터 및 쿼리 수집기는 아파치 카프카(Apache Kafka)를 기반으로 설계되는 것이 바람직하고, 사용자의 차량으로부터 위치 데이터를 수집하고 또한 사용자의 질의도 수신할 수 있다.

일실시예에서, 인덱스 관리자는 그리드 기반의 시공간 인덱스 구조를 생성하며, 스파크(Spark)에서 발생하던 메모리가 가득 찰 때의 문제를 고려하기 위하여 시간에 따라 여러 버전의 색인을 만들고 최근의 색인을 메모리에 유지할 수 있다.

일실시예에서, 시스템은 인덱싱 과정에서 아파치 스파크(Apache Spark)의 RDD(Resilient Distributed Datasets)를 기반으로 하는 다중 버전 동시성 제어 기법을 통해 트랜잭션 처리의 스냅 샷 격리 수준(Snapshot Isolation)을 제공할 수 있다.

일실시예에서, 질의 관리자는 수신된 사용자 질의를 처리하고, 처리된 질의 결과를 사용자 단말 측으로 전달할 수 있다.

일실시예에서, 데이터 관리자는 시간에 따라 생성된 여러 버전의 색인들 중 오래된 것들을 HBase 등의 데이터베이스에 저장하고 필요시 메모리로 로드할 수 있다.

상기 기술적 과제를 해결하기 위한 본 발명의 다른 측면에 따른 분산 인메모리 이동 객체 관리 방법은, 차량을 포함하는 이동 객체로부터 위치 데이터를 수집하고, 상기 차량과 관련된 사용자 단말의 질의를 수신하는 단계; 상기 데이터 및 쿼리 수집기로부터의 데이터에 대하여 그리드 기반의 시공간 인덱스 구조를 생성하고 시간에 따라 여러 버전의 서브 색인들을 만들고 미리 설정된 최근 시간 범위의 서브 색인들을 메모리에 유지하는 단계; 및 시간에 따라 생성된 상기 여러 버전의 서브 색인들 중 미리 설정된 시간 이전의 오래된 서브 색인들을 데이터베이스에 저장하고 상기 데이터 및 쿼리 수집기로부터의 신호에 따라 상기 데이터베이스에 저장된 오래된 서브 색인들을 메모리에 로드하는 단계를 포함한다.

상술한 스파크(Sprark)에 기반한 분산 인메모리 이동 객체 관리 시스템 및 방법을 사용하는 경우에는, 이동 객체의 위치 데이터를 효과적으로 관리할 수 있다. 특히, 이동 객체의 빅데이터를 신속하고 정확하게 처리하면서 장치의 내결함성, 지역성 및 확정성을 유지할 수 있다.

도 1은 본 발명의 일실시예에 따른 분산 인메모리 이동 객체 관리 시스템에 채용할 수 있는 아파치 스파크 스트리밍(Apache Spark Streaming)을 기반으로 한 인메모리 그리드 인덱스 구조를 예시한 도면이다.
도 2는 본 발명의 일실시예에 따른 분산 인메모리 이동 객체 관리 시스템을 설명하기 위한 블록도이다.
도 3은 도 2의 시스템의 인덱스 관리자의 작동 원리를 설명하기 위한 블록도이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 아니하는 것으로 이해되어야 할 것이다.

본 명세서에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함한다", "가진다" 등과 관련된 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

본 명세서에서 다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 포함한다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 의미와 일치하는 의미로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

관련 연구

Parallel Secondo는 컴퓨터 클러스터에 기반한 SECONDO 데이터베이스 시스템의 병렬 및 분산 버전이다. 하둡(Hadoop)을 Secondo 데이터베이스와 통합하고 거의 모든 기존 Secondo 데이터 유형 및 연산자를 제공한다. Parallel Secondo의 기반이 되는 시스템인 Secondo는 공간 및 시공간 데이터 관리를 지원하는 데이터베이스 관리 시스템이다. Secondo는 차량, 동물의 궤적과 같은 이동 객체의 쿼리를 표현하고 처리하기 위한 데이터 타입 및 연산자를 제공한다. Parallel Secondo는 대용량의 이동 객체 데이터와 궤적 데이터 집합에 대한 시공간 질의 및 분석을 처리할 수 있다.

Hadoop은 MapReduce 프로그래밍 모델에 따라 HDFS(Hadoop Distributed File System)에 많은 양의 키와 값(key & value)의 쌍 데이터를 저장하고 병렬로 관련 작업을 수행할 수 있다.

Parallel Secondo는 Hadoop 기반 하이브리드 시스템인 Hadoop GIS처럼 데이터와 작업(Job) 간의 통신 방식으로 HDFS를 사용한다. 이러한 종류의 시스템은 시공간 데이터가 기존 데이터보다 훨씬 큰 다차원 데이터이기 때문에 HDFS를 통해 데이터를 이전하고 셔플하는 데 상당한 오버 헤드를 유발한다.

Parallel Secondo는 HDFS를 통한 통신으로 인한 오버 헤드를 줄이기 위해 자신들의 파일 시스템인 PSFS(Parallel Secondo File System)를 제안한다. HDFS에는 Hadoop으로 MapReduce 작업을 예약하기 위해 작은 크기의 메타 데이터만 저장하여 불필요한 데이터 마이그레이션 오버 헤드를 피한다.

그러나 Parallel Secondo는 일반적으로 기존 데이터보다 훨씬 큰 시공간 데이터를 하드 디스크에 저장하므로 대용량의 위치 스트림을 실시간으로 처리하기가 어렵다. Parallel Secondo는 배치 모드에서 대규모 궤적을 분석하고 쿼리하는 응용 프로그램에 적합하다.

반면, 토네이도(Tornado)는 데이터 스트림에 대한 공간 텍스트(Spatio-Text) 쿼리의 실시간 처리를 위한 분산 시스템이다. 토네이도는 내결함성을 갖는 분산 스트림 처리 시스템인 스톰(Storm)을 기반으로 한다. 토네이도에서는 공간 텍스트 쿼리(Query)의 성능을 향상시키는 적응형 색인 계층으로 Storm을 확장한다.

토네이도(Tornado)의 주요 기능은 기존의 키워드 기반 검색을 넘어서는 의미 검색 기능이다. 식별된 개념이 어떻게 공간 텍스트 질의 토네이도와 의미적으로 관련되는지를 결정하기 위해 온라인 방식으로 데이터 스트리밍에 대한 개념을 식별하고 사용한다. 토네이도는 방대한 양의 데이터 스트림에 대해 공간적 텍스트 큐를 고려하지만 이동 객체에 대한 시공간 쿼리를 지원하지 않는다.

스파크(Spark)는 아파치 스파크(Apache Spark)에 기반한 이동 객체를 위한 인메모리(in-memory) 분산 색인 방법을 제안한다. 스파크의 기본 기술은 단순한 그리드 인덱스이다. 스파크는 bulkLoad, bulkInsert, splitIndex와 같은 새로운 변환 연산자와 출력 연산자를 Spark에 추가하여 실시간으로 이동 객체를 인덱싱하고 쿼리한다. 입력 스트림은 차량에서 주기적으로 전송되는 이동 객체의 위치 데이터이다. 스파크 스트리밍(Spark Streaming)은 입력 스트림을 디스트림(D-Stream)으로 변환한다.

이하, 본 발명의 실시예에 따른 분산 인메모리 이동 객체 관리 시스템 및 방법을 첨부 도면을 참조로 상세히 설명한다.

도 1은 본 발명의 일실시예에 따른 분산 인메모리 이동 객체 관리 시스템에 채용할 수 있는 아파치 스파크 스트리밍(Apache Spark Streaming)을 기반으로 한 인메모리 그리드 인덱스 구조를 예시한 도면이다.

도 1에 도시한 바와 같이, 아파치 스파크 스트리밍을 이용하는 시스템에서 입력 스트림(Stream)은 스파크 스트림(Spark Stream)에 의해 DSt, DSt+1, DSt+2 및 DSt+3으로 연속적으로 변환된다. 그리고 각각의 불연속된 스트림(Discretized Stream, D-Stream 또는 DS)에서 bulkLoad 및 bulkInsert 연산자를 수행한다. bulkLoad는 DSt의 위치 데이터와 함께 그리드 색인(Grid Index, GI)을 구성한다. 간단한 그리드 기술을 사용하여 색인을 생성하고 업데이트하는 시간을 줄이다. 인덱싱 방법은 잠금 기반 동시성 제어 방법을 사용하지 않는다.

상술한 입력 스트림은 이동 객체의 위치(Positions of moving objects) 데이터를 포함하고, 이 위치 데이터는 경도(longitude, lon), 위도(latitude, lat), 시간(time), 이동객체 식별자(obj_id) 등을 포함할 수 있다. 위도 및 경도에 의한 위치 정보는 다른 대체가능한 위치 정보로 대체될 수 있다.

Spark Stream의 D-Stream 모델은 변경 불가능하므로 업데이트 작업과 검색 작업은 인덱스에서 동시에 수행되지 않는다. 즉, 도 1에서와 같이 인덱스는 블럭로드(bulkLoad) 및 블럭인서트(bulkInsert) 연산자로 업데이트되며 사용자가 액세스할 수 있는 시간 t, t+1, t+2 및 t+3에 있는 인덱스의 여러 버전이 메인 메모리에 존재하도록 이루어진다. 따라서 블럭로드 GIt, GIt+1, GIt+2, GIt+3가 생성완료되었거나 생성중일 때, 사용자는 GIt+2에 액세스할 수 있으며 동시에 GIt+3은 생성 중일 수 있다.

도 2는 본 발명의 일실시예에 따른 분산 인메모리 이동객체 관리 시스템을 설명하기 위한 블록도이다.

도 2를 참조하면, 본 실시예에 따른 스파크(Sprak)에 기반한 분산 인메모리 이동 객체 관리 시스템(이하, 간략히 이동객체 관리 시스템)은, 카프카(Kafka, 20)를 통해 차량(Vehicle, 10) 및 사용자(2)로부터 전달되는 데이터와 질의를 처리한다.

이동객체 관리 시스템은, 데이터 및 쿼리 수집기(Data & Query Collector, 31), 인덱스 관리자(Index Manager, 32), 질의 관리자(Query Manager, 33) 및 데이터 관리자(Data Manager, 34)를 구비한다. 데이터 및 쿼리 수집기(31), 인덱스 관리자(32), 질의 관리자(33) 및 데이터 관리자(34)는 적어도 하나의 컴퓨팅 장치(30)에 의해 구현될 수 있다.

또한, 데이터 및 쿼리 수집기(31), 인덱스 관리자(32), 질의 관리자(33) 및 데이터 관리자(34)는 컴퓨팅 장치에 구비된 메모리에 각각의 기능을 수행하거나 복수의 기능들을 조합한 적어도 하나 이상의 소프트웨어 모듈로 저장될 수 있다. 컴퓨팅 장치(30)는 프로세서에 의해 메모리에 저장된 소프트웨어 모듈을 실행하여 분산 인메모리 이동 객체 관리 방법을 구현할 수 있다.

또한, 이동객체 관리 시스템은 구현에 따라서 카프카(20)를 포함할 수 있으며, 그 경우 카프카(20)는 데이터 및 쿼리 수집기(31)에 연결되거나 단일 기능 블록 형태로 결합될 수 있다.

데이터 및 쿼리 수집기(30)(이하, 간략히 수집기)는 아파치 카프카(Apache Kafka) 및 스파크 스트리밍(Spark Streaming)을 기반으로 설계될 수 있다. 수집기(31)는 사용자의 차량(10) 및 사용자 단말(2)의 쿼리로부터 위치 데이터 및 시간을 수신한다. 수집기(31)는 카프카의 컨슈머(Consumer)이다. 카프카(Kafka)는 차량의 위치 데이터와 사용자의 쿼리를 수집기(31)에 전달하는 브로커이다. 수집기(31)는 카프카에서 위치 데이터 및 쿼리를 지속적으로 검색한다. 이동 객체의 위치 데이터를 받으면 그리드(grid)의 셀 식별자(Cell ID)에 따라 위치 데이터의 D-Stream을 분할한다.

인덱스 관리자(32)는, 그리드 기반의 시공간 인덱스 구조를 생성하고 새로 수신된 위치 데이터를 인덱스 구조에 삽입한다. 본 실시예에서 제안하는 시스템의 인덱스 구조는 시간 간격에 따라 여러 개의 서브 인덱스로 나눠진다. 인덱스 관리자(32)는 실시간으로 분산 메인 메모리의 사용을 모니터링하고 LRU(Least Recently Used) 정책에 따라 일부 서브 인덱스 구조를 HBase로 플러시(flush)한다.

질의 관리자(Query Manager, 33)는 사용자의 시공간(spatio-temporal) 쿼리를 처리한다. 인-메모리와 HBase에 저장된 서브 인덱스 구조를 사용하여 쿼리를 처리한다.

데이터 관리자(Data Manager, 34)는 플러시 된 서브 인덱스 구조를 저장하거나 서브 인덱스 구조를 메모리에 로드한다.

앞서 언급했듯이, 본 실시예의 인덱스 관리자(32)는 스파크의 분산 그리드 인덱싱 기술을 기반으로 한다.

도 3은 도 2의 시스템의 인덱스 관리자의 작동 원리를 설명하기 위한 블록도이다. 즉, 도 3은 본 실시예에 따른 이동 객체 관리 시스템의 인덱스 관리자의 작동 원리를 보여준다.

도 3에서 볼 수 있듯이, 인덱스 관리자(Index Manager)는 하나의 인덱스를 글로벌 그리드 인덱스(Global Grid Index)와 여러 개의 서브 그리드 인덱스(Sub Grid Index)로 구성하여 관리한다. 인덱스 관리자는 시간 간격에 따라 그리드 색인을 여러 개의 서브 그리드 색인 구조로 분할한다.

글로벌 인덱스 구조는 특정 서브 그리드 인덱스에 액세스하기 위해 여러 개의 서브 그리드 인덱스를 관리한다. 예를 들어 위치 데이터를 새로 수신하면, 인덱스 관리자는 가장 최근의 서브 그리드 색인에 새로 수신된 위치 데이터를 삽입한다. 또한, 쿼리가 수신되면, 인덱스 관리자는 쿼리의 시간 술어(Predicates)에 따라 하나 이상의 서브 그리드 인덱스들에 접근할 수 있다.

각 서브 그리드 인덱스는 각 셀에 포함되는 위치 데이터를 관리한다. 각 셀에 포함되는 위치 데이터는 RDD로 관리된다. 도 3에서, 1_C0_1은 시간 간격 t1 ~ t4에서 셀 0에 대한 위치 데이터를 저장하는 RDD이다. 새로 수신된 DStream에 Cell 0에 대한 위치 데이터가 포함되어 있으면, 인덱스 관리자는 새 위치 데이터에 대해 새로운 RDD 1_C0_2를 작성한다. 새로운 RDD 1_C0_2가 생성될 때, 시간 간격 t1-t4에서 서브 그리드 인덱스 SGI_RDD1_0은 SGI_RDD1_1로 변경된다.

1_C0_1과 같은 셀의 각 RDD는 위치 데이터를 저장하는 RDD의 RDD이름(RName)을 포함한다. 위의 도 3에서, DStream의 MO_RDD1 및 MO_RDD2에 저장된 위치 데이터는 t1과 t2 사이의 위치 데이터와 t3과 t4 사이의 위치 데이터를 각각 포함한다.

인덱스 관리자(Index Manager)는 새로운 위치 데이터를 인덱스에 업데이트 하는 동시에 시공간 쿼리를 처리한다. Spark가 변경중인 RDD에 액세스될 수 없기 때문에 인덱스 관리자는 항상 일관된 인덱스 데이터를 보장한다. 또한 Spark는 자체 장애극복(failover) 방법으로 한 번 생성 된 RDD를 항상 복구하므로 인덱스 관리자가 인덱스 구조에 대한 RDD에 액세스하면 RDD가 사라지지 않다.

전술한 실시예에 의하면, 이동 객체의 대용량 데이터 또는 빅데이터를 효율적으로 신속하고 정확하게 처리하면서 장치의 내결함성, 지역성 및 확정성을 유지할 수 있고, 이러한 분산 메모리 처리 시스템에서 이동 객체의 위치 데이터를 효과적으로 관리할 수 있다.

이상과 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 본 명세서의 기재로부터 다양한 수정 및 변형이 가능하다. 그러므로, 본 발명의 범위는 위에서 설명된 실시예에 국한되어 정해져서는 아니되며, 후술하는 청구범위뿐 아니라 이 청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (5)

1. 차량을 포함하는 이동 객체로부터 위치 데이터를 수집하고, 상기 차량과 관련된 사용자 단말의 질의를 수신하는 데이터 및 쿼리 수집기;
   상기 데이터 및 쿼리 수집기로부터의 데이터에 대하여 그리드 기반의 시공간 인덱스 구조를 생성하고 시간에 따라 여러 버전의 서브 색인들을 만들고 미리 설정된 최근 시간 범위의 서브 색인들을 메모리에 유지하는 인덱스 관리자; 및
   시간에 따라 생성된 상기 여러 버전의 서브 색인들 중 미리 설정된 시간 이전의 오래된 서브 색인들을 데이터베이스에 저장하고 상기 데이터 및 쿼리 수집기로부터의 신호에 따라 상기 데이터베이스에 저장된 오래된 서브 색인들을 메모리에 로드하는 데이터 관리자를 포함하는, 분산 인메모리 이동 객체 관리 시스템.
2. 청구항 1에 있어서,
   상기 인덱스 관리자는 아파치 스파크(Apache Spark)의 RDD(Resilient Distributed Datasets)를 기반으로 하는 다중 버전 동시성 제어 기법을 통해 트랜잭션 처리의 스냅 샷 격리 수준(Snapshot Isolation)을 제공하는, 분산 인메모리 이동 객체 관리 시스템.
3. 청구항 1에 있어서,
   상기 데이터 및 쿼리 수집기는 아파치 카프카(Apache Kafka) 및 스파크 스트리밍(Spark Streaming)을 기반으로 설계되며, 상기 아파치 카프카의 컨슈머로서 아파치 카프카로부터 이동객체의 위치 데이터와 사용자 단말의 쿼리를 획득하며, 획득한 위치 데이터를 그리드의 셀 식별자에 따라 위치 데이터의 불연속된 스트림을 분할하는, 분산 인메모리 이동 객체 관리 시스템.
4. 청구항 1에 있어서,
   상기 인덱스 관리자는 실시간으로 분산 메인 메모리의 사용을 모니터링하고, LRU(Least Recently Used) 정책에 따라 일부 서브 인덱스 구조를 HBase로 플러시(flush)하는, 분산 인메모리 이동 객체 관리 시스템.
5. 청구항 4에 있어서,
   상기 데이터 관리자는 플리시된 서브 인덱스 구조를 저장하거나 서브 인덱스 구조를 메모리에 로드하는, 분산 인메모리 이동 객체 관리 시스템.

Images