KR102571783B1 - 대용량 검색 처리를 수행하는 검색 처리 시스템 및 그 제어방법 - Google Patents

Abstract

본 발명은 대용량 검색 처리를 수행하는 검색 처리 시스템 및 그 제어방법에 관한 것이다. 본 발명에 따른 검색 처리 시스템의 제어방법은, 검색 서버가 검색 결과 데이터와 프라이머리 키 필드값을 매칭시켜서 임시 저장함과 아울러, 상기 매칭된 프라이머리 키 필드값과 검색 결과 데이터를 동기화 데이터베이스 서버에 지속적으로 전송하여 상호 실시간 동기화를 수행하는 단계와; 검색 노드가 상기 검색 서버로부터 검색 결과 데이터 중 프라이머리 키 필드값을 수신하여 저장하는 단계와; 상기 검색 노드가 상기 저장된 프라이머리 키 필드값을 상기 동기화 데이터베이스 서버에 전송하여 각 프라이머리 키 필드값에 매칭된 검색 결과 데이터를 수신하는 단계를 포함하는 것을 특징으로 한다.

Description

대용량 검색 처리를 수행하는 검색 처리 시스템 및 그 제어방법{SEARCH PROCESSING SYSTEM PERFORMING HIGH-VOLUME SEARCH PROCESSING AND CONTROL METHOD THEREOF}

본 발명은 대용량 검색 처리를 수행하는 검색 처리 시스템 및 그 제어방법에 관한 것으로, 보다 상세하게는 전체 처리 건수에 제한이 있는 검색 서버를 포함하여 검색 데이터를 처리하는 검색 처리 시스템 및 그 제어방법에 관한 것이다.

클라우드 컴퓨팅 기술은 다양한 분야에서 이루어지고 있는데 대표적인 것이 대용량 데이터 검색 서비스 분야이다.

일반적으로 클라우드 기반 대용량 데이터를 조회하는 경우 빠른 검색속도를 위하여 Elasticsearch 등과 같은 검색엔진(검색 서버)을 사용하는데 이러한 검색 서버는 검색 결과 데이터의 양에 제한이 있기 마련이다.

예를 들어 Elasticsearch 검색 서버의 경우 검색 조회 결과 데이터가 기본 10,000건만 가져 올 수 있고, 그 이상의 데이터가 존재하는 경우 에러를 발생시키도록 되어 있다.

즉, Elasticsearch 검색 서버의 경우에는 효율성을 위해 데이터들을 하나의 데이터베이스가 아닌 여러 데이터베이스들에 샤딩(Sharding) 기법 등을 이용하여 분산해서 저장하고 데이터들을 모을 때 마찬가지로 샤딩(Sharding) 기법을 이용하여 데이터를 모아 정렬한 뒤 반환하는 과정을 거치기 때문에, 최대 검색 결과 데이터(즉, document) 개수를 10,000개로 제한하고 있는 것이다.

물론, 가장 근본적인 해결 방법은 Elasticsearch 검색 서버의 설정 내 max_result_window 크기의 default 값을 10,000보다 크게 설정하는 방법이지만, 디폴트 값을 변경한다면 과도한 리소스 사용으로 인해 성능 문제가 발생한다.

등록특허 제10-1932655호

본 발명은 상기한 종래의 문제점을 해결하기 위해 안출된 것으로서, 그 목적은 Elasticsearch 검색 서버만을 이용하여 검색을 수행할 때 데이터 제한으로 인해 대용량 데이터를 처리하는 못하는 문제를 해결하기 위한 데이터 시스템 및 그 제어방법을 제공하는 것이다.

상기한 목적을 달성하기 위해 본 발명에 따른 검색 처리 시스템의 제어방법, 검색 서버가 검색 결과 데이터와 프라이머리 키 필드값을 매칭시켜서 임시 저장함과 아울러, 상기 매칭된 프라이머리 키 필드값과 검색 결과 데이터를 동기화 데이터베이스 서버에 지속적으로 전송하여 상호 실시간 동기화를 수행하는 단계와; 검색 노드가 상기 검색 서버로부터 검색 결과 데이터 중 프라이머리 키 필드값을 수신하여 저장하는 단계와; 상기 검색 노드가 상기 저장된 프라이머리 키 필드값을 상기 동기화 데이터베이스 서버에 전송하여 각 프라이머리 키 필드값에 매칭된 검색 결과 데이터를 수신하는 단계를 포함할 수 있다.

또, 상기한 목적을 달성하기 위해 본 발명에 따른 검색 처리 시스템은, 동기화 데이터베이스 서버와; 검색 결과 데이터와 프라이머리 키 필드값을 매칭시켜서 임시 저장함과 아울러, 상기 매칭된 프라이머리 키 필드값과 검색 결과 데이터를 상기 동기화 데이터베이스 서버에 지속적으로 전송하여 상호 실시간 동기화를 수행하는 검색 서버와; 상기 검색 서버로부터 검색 결과 데이터 중 프라이머리 키 필드값을 수신하여 저장하는 검색 노드를 포함하여 구성되고, 상기 검색 노드는 상기 저장된 프라이머리 키 필드값을 상기 동기화 데이터베이스 서버에 전송하여 각 프라이머리 키 필드값에 매칭된 검색 결과 데이터를 수신할 수 있다.

여기서, 상기 검색 노드는 상기 검색 서버에 상기 검색 결과 데이터 전체 카운트 값을 조회하고, 그 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우 상기 프라이머리 키 필드값을 수신하여 저장한 후 상기 동기화 데이터베이스 서버로부터 검색 결과 데이터를 수신하고, 그 조회된 전체 카운트 값이 기 설정된 값 이하인 경우에는 상기 검색 서버에 상기 검색 결과 데이터를 요청하여 수신할 수 있다.

여기서, 상기 검색 노드는 상기 검색 서버에 검색 요청을 한 후에 상기 검색 서버로부터 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우, 상기 검색 서버에 분할 검색을 요청할 수 있다.

여기서, 상기 검색 노드는 자체적인 IT 자원 양에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단하고, 그 판단된 개별 쓰레드 처리 양과 상기 조회된 전체 카운트 값을 기초로 데이터 처리를 위해 생성할 쓰레드 개수를 결정하며, 그 결정된 쓰레드 개수만큼 쓰레드를 생성하여 각각의 쓰레드에 각각의 프라이머리 키 필드값을 분배하여 할당한 후, 각각의 쓰레드가 해당 프라이머리 키 필드값에 기초하여 상기 동기화 데이터베이스 서버로부터 검색 결과 데이터를 수신하도록 제어할 수 있다.

여기서, 상기 검색 노드는 상기 자체적인 IT 자원 양에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단할 때, 검색 요청에 대한 전체 처리 시간을 기초로 판단한 통계값에 기반하여 가중치를 적용할 수 있다.

이상 설명한 바와 같이 본 발명에 따르면, 대용량 데이터를 Elasticsearch 검색엔진에서 조회하는 경우 10,000건이 넘는 경우 Primary Key 필드만 조회하여 mongoDB의 Primary Key와 Mapping 으로 대용량 데이터를 mongoDB 에서 조회 할 수 있게 하여 효율적인 자원 관리와 리소스 제한 문제로 인한 서비스 다운되는 상황을 예방할 수 있다.

도 1은 본 발명의 일 실시예에 따른 검색 처리 시스템의 주요 구성도이고,
도 2 및 도 3은 본 발명의 일 실시예에 따른 검색 처리 시스템의 전체적인 제어흐름도이다.

이하에서는 첨부도면을 참조하여 본 발명에 대해 상세히 설명한다.

이하 본 발명에 따른 각 실시예는 본 발명의 이해를 돕기 위한 하나의 예에 불과하고, 본 발명이 이러한 실시예에 한정되는 것은 아니다. 특히 본 발명은 각 실시예에 포함되는 개별 구성, 개별 기능, 또는 개별 단계 중 적어도 어느 하나 이상의 조합으로 구성될 수 있다.

특히, 편의상 청구 범위의 일부 청구항에는 '(a)'와 같은 알파벳을 포함시켰으나, 이러한 알파벳이 각 단계의 순서를 규정하는 것은 아니다.

또한 이하 본 발명에 따른 각 실시예에서 언급하는 각 신호는 한 번의 연결 등에 의해 전송되는 하나의 신호를 의미할 수도 있지만, 후술하는 특정 기능 수행을 목적으로 전송되는 일련의 신호 그룹을 의미할 수도 있다. 즉, 각 실시예에서는 소정의 시간 간격을 두고 전송되거나 상대 장치로부터의 응답 신호를 수신한 이후에 전송되는 복수 개의 신호들이 편의상 하나의 신호명으로 표현될 수 있는 것이다.

본 발명의 일 실시예에 따른 검색 처리 시스템의 주요 구성은 도 1에 도시된 바와 같다.

동 도면에 도시된 바와 같이 검색 처리 시스템은 검색 노드(100), 검색 서버(200), 동기화 데이터베이스 서버(300)를 포함하여 구성될 수 있다.

여기서 동기화 데이터베이스 서버(300)는 검색 서버(200)와 데이터를 실시간 공유하여 저장 및 관리하고, 또한 검색 노드(100)로부터 요청이 있는 경우 저장된 데이터를 제공하는 기능을 수행한다.

예를 들어 동기화 데이터베이스 서버(300)는 mongoDB에 해당할 수 있다.

외부로부터 데이터를 실시간 동기화하여 저장하고 그 중 적어도 일부를 외부에 제공하는 기능 자체는 공지된 기술에 해당하므로 보다 상세한 설명을 생략한다.

검색 서버(200)는 외부의 검색 요청에 따라 검색 처리를 수행하는 것으로서, 예를 들어 루씬 기반의 검색 엔진에 해당하는 elasticsearch(일래스틱서치) 서버일 수 있다.

특히, 검색 서버(200)는 검색 결과 데이터와 프라이머리 키 필드값을 매칭시켜서 임시 저장함과 아울러, 그 서로 매칭된 프라이머리 키 필드값과 검색 결과 데이터를 동기화 데이터베이스 서버(300)에 지속적으로 전송하여 상호 실시간 동기화를 수행한다.

예를 들어 검색 서버(200)는 검색 요청이 올 때 새로 발생되는 검색 결과 데이터를 상술한 방법으로 동기화 데이터베이스 서버(300)와 동기화할 수 있는데, 이때 동기화 데이터베이스 서버(300)에는 오래된 검색 결과 데이터는 물론 새로 동기화되는 검색 결과 데이터도 모두 저장될 수 있고, 이에 반해 검색 서버(200)에서는 기 설정된 시간 동안 발생한 검색 결과 데이터만 저장할 수 있다.

즉, 저장되는 데이터의 전체 양은 동기화 데이터베이스 서버(300)가 검색 서버(200)보다 더 클 수는 있지만, 적어도 검색 서버(200)에 저장된 검색 결과 데이터는 모두 동기화 데이터베이스 서버(300)에 저장되어 있고, 이때 프라이머리 키 필드값도 함께 서로 동일하게 저장된다.

따라서 특정 프라이머리 키 필드값에 기초하여 검색 서버(200)에 요청하든 또는 동기화 데이터베이스 서버(300)에 요청하든, 동일한 검색 결과 데이터를 얻을 수 있는 것이다.

이러한 검색 서버(200)는 동기화 데이터베이스 서버(300)와 비교할 때 데이터를 저장하는 용량이나, 저장 시간, 또는 대용량 처리 성능 중 적어도 어느 하나가 떨어지거나 제한되어 있다고 가정한다.

검색 노드(100)는 검색 서버(200)에 검색을 요청하고, 그에 따른 결과를 수신하는 것으로서,

특히 사용자 등의 요청에 따라 검색 서버(200)에 검색 처리를 요청하고, 그러한 요청에 따라 검색 서버(200)로부터 수신되는 정보를 이용한 검색 결과 데이터를 사용자 등에 제공하는 기능을 수행할 수 있다.

검색 서버(200)에 검색 처리 요청을 함에 있어서 검색 노드(100)는 검색 결과 데이터 전체 카운트 값을 먼저 조회할 수도 있다.

예를 들어 검색 노드(100)는 검색 쿼리를 검색 서버(200)에 전송하면서 해당 검색 쿼리에 따른 검색 결과 데이터의 전체 카운트 값을 요청하여 수신할 수 있고, 그 수신된 전체 카운트 값에 따라 각기 다른 처리를 수행할 수 있다.

구체적으로 조회된 전체 카운트 값이 기 설정된 값을 이하인 경우에는 검색 노드(100)는 검색 서버(200)에 직접 검색 결과 데이터를 요청하여 수신할 수 있다.

반면에 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우 검색 노드(100)는 검색 서버(200)에 프라이머리 키 필드값을 요청 및 수신하여 저장한 후, 그 저장된 프라이머리 키 필드값을 이용하여 동기화 데이터베이스 서버(300)로부터 검색 결과 데이터를 수신할 수 있다.

즉, 앞서 설명한 바와 같이 검색 서버(200)에 저장된 데이터들은 동기화 데이터베이스 서버(300)에 동기화가 되어 있는 상태이므로 검색 노드(100)는 필요한 검색 결과 데이터를 동기화 데이터베이스 서버(300)에 요청하여 수신할 수 있는데, 이때 검색 서버(200)로부터 수신한 프라이머리 키 필드값을 이용하는 것이다.

일 예로 검색 서버(200)는 각 프라이머리 키 필드값에 매칭된 검색 결과 데이터를 순차적으로 동기화 데이터베이스 서버(300)에 요청하여 수신할 수 있는 것이다.

한편, 검색 노드(100)는 앞서 설명한 바와 같이 검색 서버(200)로부터 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우, 검색 서버(200)에 분할 검색을 요청할 수도 있다.

일반적인 검색 요청이 하나의 결과를 리턴하도록 하는 것이라면, 상술한 분할 검색 요청은 많은 수의 결과를 리턴하도록 하는 것이다.

검색 서버(200)가 Elasticsearch 서버라고 가정한다면 상술한 분할 검색 요청은 일명 Scroll API 요청일 수 있다.

이러한 Scroll API 요청과 관련한 기술 그 자체는 공지된 기술에 해당하므로 보다 상세한 설명을 생략한다.

특히, 검색 노드(100)는 동기화 데이터베이스 서버(300)에 접속하여 검색 결과 데이터를 수신하는 경우 복수 개의 쓰레드를 이용하여 처리할 수 있다.

이를 위해 검색 노드(100)는 자체적인 IT 자원 양(예를 들어 cpu 코어 개수, 메모리 크기 등)에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단할 수 있다.

여기서 현재 가용한 IT 자원 양에 기초하여 각각의 쓰레드들이 처리할 수 있는 양을 계산하는 알고리즘은 기 공지된 방식을 이용할 수 있다.

일 예로 cpu 코어 개수가 4 개인 경우, 검색 노드(100)는 각 개별 쓰레드가 처리할 수 있는 양을 600 개라고 판단할 수 있고, 다른 예로써, cpu 코어 개수가 8개인 경우, 검색 노드(100)는 각 개별 쓰레드가 처리할 수 있는 양을 1,000 개라고 판단할 수 있다.

또한 검색 노드(100)는 그 판단된 개별 쓰레드 처리 양과 앞서 조회된 전체 카운트 값을 기초로 데이터 처리를 위해 생성할 쓰레드 개수를 결정할 수 있다.

예를 들어 개별 쓰레드 처리 양이 1,000이고, 검색 서버(200)로부터 조회된 전체 카운트 값이 10,000 개인 경우, 검색 노드(100)는 10,000/1,000 으로 산술하여 10개의 쓰레드가 필요하다고 결정할 수 있는 것이다.

이어서 검색 노드(100)는 결정된 쓰레드 개수만큼 쓰레드를 생성하여 각각의 쓰레드에 각각의 프라이머리 키 필드값을 분배하여 할당한 후, 각각의 쓰레드가 해당 프라이머리 키 필드값에 기초하여 동기화 데이터베이스 서버(300)로부터 검색 결과 데이터를 수신하도록 제어할 수 있다.

예를 들어 제1 쓰레드는 프라이머리 키 필드값 1부터 1000까지에 해당하는 검색 결과 데이터를 동기화 데이터베이스 서버(300)에 요청하여 수신하고, 제2 쓰레드는 프라이머리 키 필드값 1001부터 2000까지에 해당하는 검색 결과 데이터를 동기화 데이터베이스 서버(300)에 요청하여 수신하며, 제3 쓰레드는 프라이머리 키 필드값 2001부터 3000까지에 해당하는 검색 결과 데이터를 동기화 데이터베이스 서버(300)에 요청하는 것이다.

이는 나머지 제4 쓰레드 내지 제10 쓰레드의 경우에도 마찬가지 방식에 의한 처리가 수행될 수 있다.

한편, 검색 노드(100)는 자체적인 IT 자원 양에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단할 때, 검색 요청에 대한 전체 처리 시간을 기초로 판단한 통계값에 기반하여 가중치를 적용할 수 있다.

예를 들어 검색 노드(100)는 복수 개의 쓰레드를 이용한 전체 처리 시간을 매번 저장하는데, 이때 전체 카운트 값 및 개별 쓰레드 처리량, IT 자원 양 등을 서로 매칭시켜 저장할 수 있다.

예를 들어 IT 자원 양에 따라 쓰레드 처리 양이 우선일 수도 있고, 또는 쓰레드 개수가 우선일 수도 있는데, 상술한 처리 과정은 쓰레드 처리 양이 우선하여 적용되는 것을 일 예로 하였으나, 매 검색 요청에 대한 처리시마다 저장된 전체 처리 시간을 누적 저장한 후, 추후 이를 통계적으로 분석하게 되면 특정 패턴이 도출될 수 있으므로, 검색 노드(100)는 이러한 특정 패턴에 기반하여 쓰레드 개수를 우선하는 가중치를 부여하여 처리할 수도 있는 것이다.

다른 예로써, 동일한 IT 자원을 가진 상태에서 전체 카운트 값이 기 설정된 범위 이내에 있는 다양한 검색에 대해 쓰레드를 이용한 처리 시간을 각각 확인한 결과, 처리 시간이 빠른 상위 20%에서의 개별 쓰레드 처리 양을 평균을 내어 추후 유사한 범위의 전체 카운트 값을 갖는 검색 처리에 대해서는 그 평균값을 개별 쓰레드 처리 양으로 선택할 수 있다.

이때 이러한 통계에 기반한 평균값을 이용하는 비율과 기 설정된 알고리즘을 그대로 이용하는 비율에 각각 가중치를 적용할 수 있는데, 예를 들어 처리 시간이 빠른 상위 20%의 평균과 전체 평균의 차이 값이 기초하여 가중치를 적용하여, 그 차이가 크다면 상술한 상위의 평균값을 이용하는 빈도수를 높일 수 있는 것이다.

이하에서는 도 2 내지 도 3을 참조하여 본 발명의 일 실시예에 따른 검색 처리 시스템의 전체적인 제어 흐름을 설명한다.

우선, 도 2를 참조하여 설명하면 다음과 같다.

검색 노드(100)는 검색 서버(200)에 검색 요청을 한다(단계 S1).

이러한 검색 요청에 따라 검색 서버(200)는 검색 처리를 수행한 후, 그 검색 결과 데이터의 전체 크기, 즉, 개수('전체 카운트 값'이라 함)를 검색 노드(100)에 전송한다(단계 S3).

검색 노드(100)는 검색 서버(200)로부터 수신된 전체 카운트 값이 기 설정된 값보다 크지 않은 경우(이하인 경우)에는(단계 S5) 검색 서버(200)에 검색 결과 데이터의 전송을 요청한다(단계 S7).

검색 서버(200)는 이러한 검색 노드(100)의 검색 결과 데이터 전송 요청에 따라 검색 결과 데이터를 추출하여 검색 노드(100)에 전송한다(단계 S9).

검색 노드(100)는 검색 서버(200)로부터 수신되는 검색 결과 데이터를 자체적인 필요에 따른 처리를 수행하거나 또는 애초에 검색을 요청한 사용자(미 도시함) 등에게 전송할 수 있다.

다음으로, 도 3을 참조하여 설명하면 다음과 같다.

본 실시예를 설명함에 있어서 검색 서버(200)는 Elasticsearch 서버인 것을 일 예로 한다.

도 3에서 단계 S1 내지 단계 S5는 도 2와 동일하므로 중복 설명은 생략한다.

검색 노드(100)는 검색 서버(200)로부터 수신된 전체 카운트 값이 기 설정된 값보다 큰 경우에는(단계 S5) 검색 서버(200)에 분할 검색 요청을 전달하는데(단계 S11), 예를 들어 Elasticsearch Scroll API 검색을 요청한다.

여기서 검색 노드(100)는 Elasticsearch Scroll API 검색 요청시 size, scroll timeout 등을 설정하여 요청한 후 scroll_id 값을 저장하고, 그 저장된 scroll_id 값을 이용하여 연이은 검색 요청을 수행할 수 있다.

검색 서버(200)는 분할 검색 결과를 검색 노드(100)에 전송하는데(단계 S13), 이렇게 Scroll API 통신하여 받아올 문서가 존재하면 검색 노드(100)는 지속적으로 프라이머리 키 필드값을 요청하여 수신하는데(단계 S15), 이때 수신된 프라이머리 키 필드값은 일시 저장할 수 있다(단계 S17).

일 예로 검색 노드(100)는 검색 서버(200)로부터 수신한 프라이머리 키 필드값을 Kafka 메시징 큐 등에 저장할 수 있다.

도시하지는 않았지만, 검색 서버(200)와 Scroll API 통신을 통해 전체 문서(즉, 전체 프라이머리 키 필드값)를 다 받은 경우 해당 검색 노드(100)는 Scroll_id 가 살아 있는 경우 검색 서버(200)에 관련 검색 내용들 즉, context의 제거를 요청하여 제거되도록 할 수도 있다.

한편, 검색 노드(100)는 멀티 쓰레드를 생성하는데(단계 S19), 이때 그 처리 양과 개수는 소정의 알고리즘에 따라 산출할 수 있다.

예를 들어 검색 노드(100)는 자체적인 여유 자원으로 갖고 있는 물리적 core, memory 값을 계산하여 각 쓰레드별 최적의 Range Fetch Size 값을 자동 계산한다.

또한, 검색 노드(100)는 전체 문서 기준 Range Fetch Size를 계산하여 Thread Task 을 생성할 수 있다.

검색 노드(100)는 이러한 쓰레드들에게 전체 프라이머리 키 필드값을 분배한 후, 각 쓰레드별로 동기화 데이터베이스 서버(300)에 검색 결과 데이터를 요청(단계 S21) 및 수신하도록(단계 S23) 제어한다.

이때 한 개의 Thread Task가 완료되면 검색 결과를 사용자에게 실시간 전달(응답)할 수 있고, 전체 Thread Task 작업이 완료 되면 사용자에게 검색 결과 완료 API 통신할 수 있다.

더 나아가 검색 노드(100)는 해당 Kafka 메시징 큐 Topic을 제거할 수 있다.

한편, 상술한 각 실시예를 수행하는 과정은 소정의 기록 매체(예를 들어 컴퓨터로 판독 가능한)에 저장된 프로그램 또는 애플리케이션에 의해 이루어질 수 있음은 물론이다. 여기서 기록 매체는 RAM(Random Access Memory)과 같은 전자적 기록 매체, 하드 디스크와 같은 자기적 기록 매체, CD(Compact Disk)와 같은 광학적 기록 매체 등을 모두 포함한다.

이때, 기록 매체에 저장된 프로그램은 컴퓨터나 스마트폰 등과 같은 하드웨어 상에서 실행되어 상술한 각 실시예를 수행할 수 있다.

또한, 본 발명은 상기한 특정 실시예에 한정되는 것이 아니라 본 발명의 요지를 벗어나지 않는 범위 내에서 여러 가지로 변형 및 수정하여 실시할 수 있는 것이다. 이러한 변형 및 수정이 첨부되는 청구범위에 속한다면 본 발명에 포함된다는 것은 자명할 것이다.

100 : 검색 노드 200 : 검색 서버
300 : 동기화 데이터베이스 서버

Claims (8)

1. 삭제
2. 삭제
3. 삭제
4. 동기화 데이터베이스 서버와;
   검색 결과 데이터와 프라이머리 키 필드값을 매칭시켜서 임시 저장함과 아울러, 상기 매칭된 프라이머리 키 필드값과 검색 결과 데이터를 상기 동기화 데이터베이스 서버에 지속적으로 전송하여 상호 실시간 동기화를 수행하는 검색 서버와;
   상기 검색 서버로부터 검색 결과 데이터 중 프라이머리 키 필드값을 수신하여 저장하는 검색 노드를 포함하여 구성되고,
   상기 검색 노드는 상기 검색 서버에 상기 검색 결과 데이터 전체 카운트 값을 조회하고, 그 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우 상기 프라이머리 키 필드값을 수신하여 저장한 후, 저장된 프라이머리 키 필드값을 상기 동기화 데이터베이스 서버에 전송하여 상기 동기화 데이터베이스 서버로부터 각 프라이머리 키 필드값에 매칭된 검색 결과 데이터를 수신하고, 그 조회된 전체 카운트 값이 기 설정된 값 이하인 경우에는 상기 검색 서버에 상기 검색 결과 데이터를 요청하여 수신하고,
   상기 검색 노드는 상기 검색 서버에 검색 요청을 한 후에 상기 검색 서버로부터 조회된 전체 카운트 값이 기 설정된 값을 초과하는 경우, 상기 검색 서버에 분할 검색을 요청하는 것을 특징으로 하는 검색 처리 시스템.
5. 제4항에 있어서,
   상기 검색 노드는 자체적인 IT 자원 양에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단하고, 그 판단된 개별 쓰레드 처리 양과 상기 조회된 전체 카운트 값을 기초로 데이터 처리를 위해 생성할 쓰레드 개수를 결정하며, 그 결정된 쓰레드 개수만큼 쓰레드를 생성하여 각각의 쓰레드에 각각의 프라이머리 키 필드값을 분배하여 할당한 후, 각각의 쓰레드가 해당 프라이머리 키 필드값에 기초하여 상기 동기화 데이터베이스 서버로부터 검색 결과 데이터를 수신하도록 제어하는 것을 특징으로 하는 검색 처리 시스템.
6. 제5항에 있어서,
   상기 검색 노드는 상기 자체적인 IT 자원 양에 기초하여 데이터 처리를 위한 개별 쓰레드 처리 양을 판단할 때, 검색 요청에 대한 전체 처리 시간을 기초로 판단한 통계값에 기반하여 가중치를 적용하는 것을 특징으로 하는 검색 처리 시스템.
7. 제4항 내지 제6항 중 어느 한 항의 시스템의 기능을 수행하기 위한 프로그램을 기록한 컴퓨터 판독 가능 기록 매체.
8. 하드웨어와 결합되어 제4항 내지 제6항 중 어느 한 항의 시스템의 기능을 수행하기 위하여 컴퓨터 판독 가능 기록 매체에 저장된 응용 프로그램.