KR100913196B1 - 파일 갱신 시스템 및 방법 - Google Patents

Abstract

본 발명은 파일 갱신 시스템에 관한 것으로, 더욱 상세하게는 동일한 이미지를 가지는 다수의 파일들을 일관성있게 갱신할 수 있도록 한 파일 갱신 시스템 및 방법에 관한 것이다. 이를 위하여 본 발명은 파이프 라인 형태의 네트워크로 구성되어 원본 파일과 그 원본 파일의 복제본 파일을 각각 저장하고, 갱신 요청에 의해 상기 원본 파일과 상기 복제본 파일을 갱신하는 복수의 데이터 서버로 이루어진 파일 갱신 시스템에 있어서, 상기 원본 파일 또는 상기 복제본 파일을 저장 및 관리하는 제1, 제2 데이터 서버를 포함하며, 상기 제1, 제2 데이터 서버는 파일 갱신 정보를 상호 교환하며, 동일 파일에 대한 복수의 갱신 요청에 의해 중복 갱신이 발생하지 않도록 상기 파일 갱신정보를 보정한후, 상기 파일 갱신정보에 따라 상기 원본 파일 또는 상기 복제본 파일을 갱신하는 파일 갱신 시스템 및 파일 갱신방법을 제공함에 있다.

파일 갱신, 데이터 베이스, 메타 데이터 서버, 원본 파일

Description

파일 갱신 시스템 및 방법{SYSTEM AND METHOD FOR UPDATING FILE}

본 발명은 파일 갱신 시스템에 관한 것으로서, 구체적으로는 동일한 이미지를 가지는 다수의 파일들을 일관성있게 갱신할 수 있도록 한 파일 갱신 시스템 및 방법에 관한 것이다.

본 발명은 정보통신부 및 정보통신연구진흥원의 IT신성장동력핵심기술개발사업의 일환으로 수행한 연구로부터 도출된 것이다[과제관리번호: 2005-S-016-01, 과제명: 저비용 대규모 글로벌 인터넷 서비스 솔루션 개발].

다수의 컴퓨터들을 네트워크를 이용하여 연결함으로써 사용자에게 통합된 저장공간을 제공해주는 저장 시스템은 웹 검색 처리, 슈퍼 컴퓨팅 등 다양한 분야에서 사용되고 있다. 이러한 저장 시스템 중 일부는 사용자가 저장한 파일에 오류가 생겼을 경우를 대비하여 동일한 파일을 여러 개 만들어 서로 다른 저장 장치에 별개로 저장시킴으로써 복구 가능성을 높이고 다수 클라이언트가 동일한 파일을 읽고자 할 때의 성능 향상도 의도하고 있다.

이와 같은 저장 시스템 내에는 동일한 이미지를 가진 파일이 여러 개 존재하기 때문에 어떤 파일을 갱신하고자 하는 연산이 제기되었을 때는 동일한 모든 파일들을 똑같이 갱신해 주어야 한다.

만일, A라는 파일이 데이터 서버 D1, D2, D3에 저장되어 있고, A를 갱신하고자 하는 연산들인 O1, O2, O3가 동시에 존재한다면 D1에도 O1, O2, O3가 실행되어야 하고, D2에도 O1, O2, O3가 실행되어야 하며, D3에도 O1, O2, O3가 실행되어야 한다. 그러나, D1, D2, D3는 서로 다른 서버이기 때문에 D1이 O1->O3->O2의 순서로 실행 순서를 스케쥴하고, D2는 O3->O2->O1의 순서로 스케쥴하고, D3는 O2->O1->O3의 순서로 스케쥴할 수 있기 때문에 최종적으로 D1, D2, D3가 가지고 있는 A라는 파일은 서로 다른 내용을 가질 수 있다.

Ghemawat가 발명하고 구글(Google)이 2003년 6월 30일자로 출원하여 2006년 6월 20일에 등록된 미국특허 US7065618B1에서는 여러 개의 컴퓨터에 복제 저장된 파일의 갱신 연산들을 관리하기 위한 방법이 제시되어 있다. 이 특허에서는 메타 데이터를 관리하는 마스터(master) 서버가 파일을 저장하고 있는 청크 서버(chunk server)들 중에서 하나의 청크 서버를 선택하고, 그 청크 서버에 리스(lease)를 발급하여 주(primary) 청크 서버 역할을 맡기고 나머지 청크 서버들은 부(secondary) 청크 서버로서 어떤 파일에 대한 갱신을 할 때는 항상 그 파일에 대한 주 청크 서버의 통제를 받도록 하고 있다.

그러나, 이 특허에서는 클라이언트가 청크 서버들에게 보내는 갱신 데이터와 갱신 메시지의 전달 사이에 시간 간격이 존재하며, 마스터 서버가 주 청크 서버에 게 리스를 발급하고 관리하는 비용, 주 청크 서버에 장애가 생겼을 때의 회복 처리 등에 따르는 비용 부담에 문제점이 있다.

Beckhardt가 발명하고 IBM이 1998년 6월 9일자로 출원하여 2000년 10월 24일에 등록된 미국특허 6138124에서는 분산 컴퓨팅 시스템에서 하나의 문서(document)가 여러 개로 복제 저장되어 있을 때 그 문서를 변경시키고자 하는 경우의 처리 방법이 제시되어 있다. 이 특허에서는 하나의 문서를 여러 개의 필드(field)로 구분하고, 문서를 대표하는 문서 일련 번호(document sequence number)와 문서상의 각 필드마다 필드 일련 번호(field sequence number)를 유지하며, 문서의 특정 부분이 수정되면 그 수정된 부분에 해당되는 필드에 대해서만 모든 복제본 들에 대해 동일하게 갱신을 해주고, 그에 따라 문서 일련 번호 및 필드 일련 번호를 조정해 준다.

그러나, 이 특허에서는 정형화된 필드를 가진 문서를 대상으로 하기 때문에 이진 파일 등과 같이 특정한 필드로 나눌 수 없는 파일 혹은 용량이 큰 파일 등에는 적용하기가 어려운 문제점이 있다.

따라서 본 발명은 상기와 같은 문제점을 감안하여 창출한 것으로, 동일한 파일을 갱신하고자 하는 요청들을 전달받은 데이터 서버가 중앙의 통제를 받지 않고 여러 데이터 서버들에 분산된 파일 복제본들이 동일한 이미지를 유지할 수 있도록 한 파일 갱신 시스템 및 방법을 제공함에 그 목적이 있다.

본 발명의 다른 목적은 갱신 연산을 적용하기까지 필요한 컨트롤 메시지의 전송량을 최소화하면서, 각 데이터 서버들의 갱신 연산 적용 순서를 전체적으로 통제할 주(primay) 데이터 서버의 필요성을 제거함으로써 파일 시스템의 전체 성능을 향상시킬 수 있도록 한 파일 갱신 시스템 및 방법을 제공함에 있다.

상기와 같은 목적을 달성하기 위한 본 발명의 일면에 따른 데이터 베이스는 파이프 라인 형태의 네트워크로 구성되어 원본 파일과 그 원본 파일의 복제본 파일을 각각 저장하고, 갱신 요청에 의해 상기 원본 파일과 상기 복제본 파일을 갱신하는 복수의 데이터 서버로 이루어진 파일 갱신 시스템에 있어서, 상기 원본 파일 또는 상기 복제본 파일을 저장 및 관리하는 제1, 제2 데이터 서버를 포함하며, 상기 제1, 제2 데이터 서버는 파일 갱신 정보를 상호 교환하며, 동일 파일에 대한 복수의 갱신 요청에 의해 중복 갱신이 발생하지 않도록 상기 파일 갱신정보를 보정한후, 상기 파일 갱신정보에 따라 상기 원본 파일 또는 상기 복제본 파일을 갱신하는 것을 특징으로 한다.

본 발명의 다른 면에 따른 파일 갱신 방법은 파이프 라인 형태의 네트워크로 연결된 복수의 데이터 서버에서 원본 파일과 그 원본 파일의 복제본 파일을 각각 저장하고, 갱신 요청에 의해 상기 원본 파일과 상기 복제본 파일이 동일한 이미지를 갖도록 갱신하기 위한 파일 갱신 방법에 있어서, 상기 원본 파일에 대한 복수개의 갱신 요청에 따른 파일 갱신 정보를 수신하는 단계; 상기 갱신 요청에 따라 파일 갱신 순서를 결정하고, 동일 파일에 대한 복수의 갱신 요청에 의해 중복 갱신이 발생하지 않도록 상기 파일 갱신 순서에 따라 상기 파일 갱신 정보를 보정한 후, 보정된 파일 갱신 정보에 따라 상기 원본 파일 또는 복제본 파일을 갱신하는 단계를 포함하는 것을 특징으로 한다.

삭제

상기와 같은 과제 해결 수단에 의해 본 발명은 동일한 파일에 대한 다수의 갱신 요청들을 데이터 서버의 주도로 처리함으로써 어떤 파일에 대한 복제본들이 모두 동일한 이미지를 가질 수 있게 된다. 특히, 일반적인 저장 시스템에서는 이러한 갱신 작업을 메타 데이터 서버 주도로 처리하였으나 본 발명에서는 메타 데이터 서버 위주의 통제를 완전히 제거함으로써 메타 데이터 서버에 걸리는 부하를 제거 하는 효과가 있다.

또한, 리스(lease)를 할당한 주(primary) 데이터 서버가 특정 파일에 대한 모든 갱신 연산을 통제하는 방법을 배제함으로써 갱신하고자 하는 파일을 가지고 있는 데이터 서버들 중에서 특정한 데이터 서버로부터 항상 갱신 연산을 시작하는 것이 아니라 어떤 데이터 서버를 선택하더라도 갱신 연산을 진행할 수 있으며, 갱신 연산을 적용하기까지 필요한 컨트롤 메시지가 전달 지연되는 현상을 최소화시키고 저장 시스템의 전체 성능을 향상시키는 효과를 얻을 수 있다.

본 발명의 파일 갱신 시스템 및 방법은 다수의 저장장치들이 네트워크로 연결되어 있는 환경에서 백업이나 복구 목적으로 동일한 파일들이 여러 개 존재할 때 그 파일들이 모두 동일한 이미지를 유지할 수 있도록 갱신하는 기술적 요지를 가진다.

이하, 본 발명에 따른 바람직한 실시 예를 첨부된 도면을 참조하여 상세히 설명하되, 본 발명에 따른 동작 및 작용을 이해하는데 필요한 부분을 중심으로 설명한다.

하기의 설명에서 본 발명의 파일 갱신 시스템 및 방법의 특정 상세들이 본 발명의 보다 전반적인 이해를 제공하기 위해 나타나 있는데, 이들 특정 상세들 없이 또한 이들의 변형에 의해서도 본 발명이 용이하게 실시될 수 있다는 것은 이 기술분야에서 통상의 지식을 가진 자에게 자명할 것이다.

도 1은 본 발명의 파일 갱신 시스템의 구성을 보인 구성도이다. 도 1을 통해 제1 파일(106)이 복제되어 제1~제3 데이터 서버(101, 103, 105)에 저장되는 동작에 대해서 설명한다.

우선, 파일 갱신 시스템(100)은 제1~제3 데이터 서버(101, 103, 105)로 구성된다.

제1~제4 파일(106, 107a, 108a, 109a)은 동일한 것으로, 제1 파일(106)이 복제되어 제1~제3 데이터 서버(101, 103, 105)의 제2~제4 파일(107a~109a)로 저장된다.

즉, 클라이언트가 원본 파일인 제1 파일(106)을 저장하려고 했을 때, 제1 파일(106)이 제1~제3 데이터 서버(101, 103, 105)에 복제되어 저장되며, 제1~제3 데이터 서버(101, 103, 105)에 저장된 제2~제4 파일(107a~108a)은 모두 동일한 이미지를 가진다.

이러한 방식으로 하나의 파일을 여러 개로 복제 저장하는 이유는 파일이 손상되었을 때의 복구 확률을 높이고, 다수의 클라이언트에서 동일한 파일을 읽고자 할 때 읽기 성능을 높이기 위한 것이다.

이러한 파일 갱신 시스템(100)의 파일 내용이 실제 저장되는 과정에 대해서 설명하도록 한다.

클라이언트가 복제하고자 하는 제1 파일(106)의 내용을 제1 데이터 서버(101)에 전송하면, 제1 데이터 서버(101)는 클라이언트로부터 전달받은 제1 파일(106)의 내용을 로컬 저장 수단(107)에 제2 파일(107a)로서 기록한다. 이후, 제1 데이터 서버(101)는 제2 데이터 서버(103)에 동일한 내용을 파이프라인(pipeline) 형태로 전송한다.

제2 데이터 서버(103)는 제2 파일(107a)의 내용을 수신하여 로컬 저장 수단(108)에 제3 파일(108a)을 기록하며, 파이프라인 경로 상에서 다음 위치에 있는 제3 데이터 서버(105)에게 동일한 내용을 전달한다. 파이프라인의 최종 위치에 있는 제3 데이터 서버(105)는 자신의 로컬 저장 수단(109)에 제4 파일(109a)을 기록 완료한 후, 파이프라인의 역순으로 제4 파일(109a)의 기록이 완료되었음을 통보하는 메시지를 전송한다.

그러면 제2 데이터 서버(103)는 파이프라인 순서에서 이전 위치에 있는 제1 데이터 서버(101)로 제3 파일(108a)이 기록되었다는 메시지를 전송하고, 메시지를 수신하는 제1 데이터 서버(101)는 클라이언트에게 제2 파일(107a)이 기록되었음을 통보한다.

이러한 파일 갱신 시스템에 파이프라인 메커니즘을 적용하면 동일한 파일을 여러 개의 데이터 서버에 복제하는 효율을 상당히 높일 수 있다.

한편, 클라이언트가 파일의 기록을 의뢰할 때 파일이 저장되는 데이터 서버들의 파이프라인 순서를 결정하는 것은 일반적으로 메타 데이터 서버에서 수행하지만, 클라이언트 혹은 데이터 서버가 파이프라인 순서를 결정할 수도 있다. 여기서 파이프 라인 순서를 결정하는 방법은 특정 순서를 설정하는 과정과 같이 일반적인 사항이므로, 이에 대한 상세한 설명은 생략하도록 한다.

전술한 제1~제3 데이터 서버(101, 103, 105)는 도 2와 같이 메모리(107)와, 제어부(117)로 구성된다.

우선 메모리(107)는 프로그램 메모리 및 데이터 메모리로 구성될 수 있다. 프로그램 메모리에는 동일 파일에 대한 복수의 갱신 요청에 따른 파일 갱신순서를 결정하는 프로그램이 저장된다. 또한 프로그램 메모리에는 복수의 갱신 요청에 의해 파일 갱신정보를 보정할 수 있도록 하는 프로그램이 저장된다. 또한 데이터 메모리에는 상기 프로그램들을 수행하는 중에 발생되는 데이터들을 일시 저장하는 기능을 수행한다. 또한 데이터 메모리에는 하나 이상의 갱신 요청에 의해 갱신되는 파일이 저장된다. 또한 데이터 메모리에는 임시파일이 저장된다.

제어부(117)는 데이터 서버의 전반적인 동작을 제어한다. 또한 제어부(117)는 파일 갱신요청에 따라 미리 임시파일을 생성한다. 또한 제어부(117)는 파일 갱신순서에 따라 임시파일을 이용하여 해당 파일을 갱신한다. 또한 제어부(117)는 동일한 파일에 대해 복수의 갱신 요청시, 갱신 요청간에 정렬을 수행하며, 충돌되지 않도록 갱신하고자 하는 파일 갱신정보를 미리 보정하여 해당 파일을 갱신하도록 제어한다. 여기서 파일 갱신정보는 오프셋과 길이 정보를 미리 보정하여 해당 파일을 갱신하도록 제어한다.

도 3은 도 1에 있어, 데이터 서버의 파일 갱신동작을 설명하기 위한 예시도이다.

우선 도 3에서는 데이터 서버(101)가 파일(201)을 보유하고 있을 때, 파일(201)의 50번 오프셋(offset)에서 50 바이트 만큼의 공간을 갱신하고자 하는 제1 요청과, 파일(201)의 80번 오프셋에서 50 바이트 만큼의 공간을 갱신하고자 하는 제2 요청이 동시에 데이터 서버(101)에 도착하였을 때 이들 요청을 표현하고 처리하는 예를 보이고 있다. 여기서 제1 요청에 의해 갱신하고자 하는 영역의 데이터를 제1 임시파일(301), 제2 요청에 의해 갱신하고자 하는 영역의 데이터를 제2 임시파일(302)이라고 가정한다.

데이터 서버(101)의 제어부(117)가 제1, 제2 요청이 공존하는 것을 인식하고, 제1 요청을 제2 요청보다 먼저 처리하는 것으로 결정하면, 제1, 제2 요청에 의해 동시에 갱신되어야 하는 영역을 고려하여 갱신할 수 있도록 제어한다.

이에, 제어부(117)는 파일 식별자(ID)가 500인 파일(201)의 갱신 요구에 따른 제1, 제2 요청에 의해 중첩되는 오프셋 80부터 100까지의 영역에 대해 한번만 갱신되도록, 제1 요청에 대한 길이정보를 50에서 30으로 변경한다. 여기서 길이정보를 변경하는 동작에 대해서는 하기에서 상세히 설명하도록 한다. 이후, 제어부(117)는 제1 요청에 따라 제1 임시파일(301)을 통해 파일(201)에 해당하는 오프셋 50부터 80까지의 영역을 갱신하고, 제2 임시파일(302)을 통해 파일(201)에 해당하는 오프셋 80부터 130까지의 영역을 갱신한다. 여기서 제어부(117)는 제1, 제2 요청에 따라 갱신하고자 하는 제1, 제2 임시파일을 메모리(107)에 임시 저장한후, 파일(201)이 갱신된 이후에 삭제한다.

도 4a 및 도 4b는 도 3에 있어, 제1, 제2 임시파일에 대한 파일 갱신정보가 변경됨을 설명하기 위한 예시도이다. 즉, 도 4a 및 도 4b는 제1, 제2 임시파일에 대한 데이터 구조가 변경됨을 설명하기 위한 도면이다.

제어부(117)는 파일 ID가 500인 파일(201)에 대하여 동시에 갱신하고자 하는 제1, 제2 요청이 2개 이상 있다는 사실을 인식한 후, 그 요청들을 제1, 제2 임시파일(301, 302)의 형태로 메모리(107)에 저장하고, 우선 처리할 순서를 결정한다.

이때, 제어부(117)는 갱신에 따른 제1, 제2 요청에 따라 제1 임시파일(301)이 제2 임시파일(302)보다 우선적으로 처리되는 것으로 결정되면, 제1, 제2 임시파일(301, 302)이 나타내는 오프셋과 길이정보를 비교함으로써 나중에 처리할 갱신 연산에 의하여 앞서 처리한 갱신 연산이 적용된 영역이 또다시 덮어 써지는 경우가 발생하지 않도록 갱신 요청에 따른 오프셋과 길이 정보를 제3 임시파일(311)과 같이 변경한다(오프셋: 50, 길이: 30).

즉, 제어부(117)는 제1 임시파일(301)에 대한 영역에 해당하는 파일(201)을 갱신하는 것이 아니라, 제3 임시파일(311)로 보정된 영역을 갱신한후, 제2 임시파일(302)에 해당하는 영역에 대해 파일(201)을 갱신한다. 이러한 임시파일들은 해시 테이블 등 다양한 방법으로 구현할 수 있다.

도 5는 본 발명의 파일 갱신 시스템의 파일 갱신 동작을 설명하기 위한 예시도이다. 도 5에서는 제1 클라이언트가 원본 파일(404~406)의 특정영역을 갱신하고자 하는 제1 파일(410)과, 제2 클라이언트가 원본 파일(404~406)의 특정영역을 갱신하고자 하는 제2 파일(411)에 대한 갱신 과정에 대해서 설명한다. 또한, 도 5에서 제1~제3 데이터 구조(407~409)는 각 제1~제3 데이터 서버(401~403)의 제1~제3 메모리(413~415)에 저장될 수 있다.

제1 클라이언트는 제1~제3 데이터 서버(401~403)에 저장되어 있는 동일한 원본 파일(404, 405, 406)에 대해 제1 파일(410)을 통해 갱신요청한다. 이에, 제1 파 일(410)은 특정한 파이프라인 순서(401->402->403)로 전송된다. 이후, 제2 클라이언트는 제1 클라이언트가 갱신하고자 하는 동일한 원본 파일에 대해 제2 파일(411)을 통해 갱신요청한다. 이에, 제2 파일(411)은 특정한 파이프라인 순서(403->402->401)로 전송된다.

제1~제3 데이터 서버(401~403)는 갱신을 요청한 제1, 제2 파일(410, 411)을 수신하면, 원본 파일(404~406)과 무관한 제1, 제2 임시 파일(410a~410c, 411a~411c)을 별도 저장한다.

예컨대, 제1 데이터 서버(401)는 갱신하고자 하는 제1 파일(410)을 수신하면, 갱신할 오프셋과 길이정보 등을 도 4a 및 도 4b에서 살펴본 형태로 데이터 구조(407)에 보관하고, 임시 파일(410a)를 생성한다.

또한, 제1 데이터 서버(401)는 파이프 라인 순서에 따라 제2 파일(411)을 제3, 제2 데이터 서버(403, 402)를 경유하여 전달받으면, 갱신할 제2 파일(411)의 오프셋과 길이정보 등을 데이터 구조(407)에 보관하고, 제2 임시 파일(411c)을 생성한다.

이후, 제1~제3 데이터 서버(401~403)는 데이터 구조(407~409)에 따라 갱신해야 하는 영역이 중첩되지 않도록 오프셋과 길이정보를 보정한후, 원본파일(404~406)의 특정영역을 제1, 제2 임시파일(410a~410c, 411a~411c)로 갱신한다.

실제 갱신 연산은 특정 정렬 순서에 따라 보정된 오프셋과 길이정보에 맞추어 진행되기 때문에 제어부(미도시)의 스케쥴링 등의 원인에 의하여 각 데이터 서버의 실제 갱신 연산들이 시작되는 물리적 순서가 제1~제3 데이터 서버(401~403)마 다 상이할지라도 동일한 파일에 적용되는 갱신 연산은 일관성 있는 결과를 산출하게 된다.

예컨대, 도 5의 제1 데이터 서버(401)에서는 CPU가 410a -> 411c의 순서대로 쓰레드(프로세스)를 스케쥴하였고, 제3 데이터 서버(402)에서는 CPU가 410c -> 411a의 순서대로 스케쥴하더라도, 제1~제3 데이터 서버(401~403)는 특정 기준에 의거하여 410 -> 411의 순서대로 갱신을 진행할 것이라고 결정하였고 갱신할 영역의 오프셋과 길이정보는 그러한 순서에 맞춰 미리 보정되었기 때문에 실제 연산이 스케쥴되는 순서와 무방하게 갱신은 일관성 있게 진행된다.

도 6a 내지 도 6c는 본 발명의 파일 갱신 방법을 보인 흐름도이다. 여기서 도 6a는 클라이언트 측면에서 갱신 연산을 요청하는 과정을 보인 도면이고, 도 6b는 데이터 서버 측면에서 파일을 갱신하는 과정을 보인 도면이다.

우선 클라이언트는 갱신할 파일이 저장되어 있는 데이터 서버들의 목록을 메타 데이터 서버에게 문의한다(S610).

그러면, 클라이언트는 메타 데이터 서버로부터 갱신할 파일이 저장되어 있는 데이터 서버들의 목록을 제공받는다(S620). 이때 제공되는 데이터 서버 목록에 내재된 데이터 서버들의 순서는 클라이언트가 데이터 서버들에게 파이프라인 형태로 메시지 및 데이터를 전달하는 순서로서 활용되며, 이러한 순서는 메타 데이터 서버가 결정하여 클라이언트에게 반환하거나, 메타 데이터 서버로부터 목록을 전달받은 클라이언트가 결정할 수 있다.

이후, 클라이언트는 파이프라인 순서에서 첫번째에 위치한 데이터 서버에게 갱신을 의뢰하는 갱신 메시지와 갱신할 파일을 저장하고 있는 데이터 서버들이 파이프라인 순서로 정렬된 리스트를 전송한다(S630). 여기서 갱신 요청 메시지는 갱신 요청 메시지임을 나타내는 갱신 요청정보, 갱신할 파일 ID, 클라이언트의 주소, 갱신할 영역의 오프셋, 갱신할 영역의 길이, 일련 번호(serial#)로 이루어져 있다. 이 과정에서 갱신 요청 메시지에 클라이언트의 주소와 일련번호는 동일한 파일을 갱신하는 연산들이 여러 개 있을 수 있기 때문에 그러한 연산들을 데이터 서버에서 관리하는 데이터 구조에서 식별하기 위함이다.

예컨대, 데이터 서버에 파일 ID가 500인 파일을 갱신하고자 하는 연산 3개가 동시에 도착하여 첫번째 연산의 출처는 <클라이언트 A, 일련 번호 100>이며, 두번째 연산은 <클라이언트 A, 일련 번호 101>, 세번째 연산은 <클라이언트 B, 일련 번호 100>이라고 하면, 데이터 서버는 향후 관리할 데이터 구조에 이들 연산들을 식별할 수 있게 된다. 일련 번호는 클라이언트가 생성할 수도 있고, 메타 데이터 서버가 최초 생성하여 클라이언트에게 전달하도록 할 수도 있다.

이후, 클라이언트는 첫번째 데이터 서버에게 갱신할 파일을 전송하고(S640), 데이터 서버로부터 갱신이 완료되었다는 메시지를 수신한다(S650).

전술한 도 6a의 클라이언트의 파일 갱신요청에 따라 데이터 서버는 도 6b와 같은 과정을 수행하여 갱신하고자 하는 파일의 특정 영역을 갱신한다.

데이터 서버는 자신이 존재하고 있는 파이프라인 상의 위치에 따라 갱신 요청 메시지를 클라이언트 혹은 다른 데이터 서버로부터 전달받고(S710), <갱신할 파일 식별자+클라이언트의 주소+일련 번호>를 키(key)로 하고, <갱신할 영역의 첫번 째 오프셋, 갱신할 영역의 길이, 임시 파일의 생성 위치>를 값(value)으로 하는 엔트리를 데이터 구조에 삽입한다(S720). 여기서 <갱신할 파일 식별자+클라이언트의 주소+일련 번호> 대신 다른 값을 키로 사용할 수 있으며, 이러한 키를 찾을 수 있도록 갱신할 파일 식별자 등을 이용하는 또 다른 데이터 구조를 유지할 수도 있다. 또한 파이프라인 순서에서 첫번째에 위치한 데이터 서버는 이러한 갱신 요청 메시지를 클라이언트로부터 전달받으며, 파이프라인 순서에서 첫번째가 아닌 데이터 서버는 이러한 메시지를 자신의 직전에 위치한 데이터 서버로부터 전달받는다. 단, 관련된 모든 데이터 서버들이 동일한 시점에서 이러한 메시지를 받는 것은 아니며, 파이프라인 순서에서 첫번째가 아닌 데이터 서버들은 자신의 직전에 위치한 데이터 서버가 자신에게 그러한 메시지를 보낼 때 수신하게 된다

이후, 데이터 서버는 데이터 구조를 조회한 결과 동일한 파일에 대한 갱신 요청이 복수개 존재하는지를 판단한다(S730).

판단결과, 갱신 요청이 복수개 존재하면, 데이터 서버는 해당 갱신 요청들을 특정한 기준으로 정렬한 후(S740), 갱신 요청들에 대한 오프셋과 길이 정보에 따라 중첩되는 오프셋과 길이정보에 대해서는 중첩되지 않도록 오프셋과 길이정보를 보정한다(S750). 여기서 오프셋과 길이정보를 수정하는 것은 향후 스케쥴된 프로세스 혹은 쓰레드가 어떤 순서로 실행되더라도 동일한 갱신 결과를 만들어내기 위함이다. 또한, 갱신 요청들에 대해 정렬한 결과는 데이터 서버마다 동일하여야 한다.

예컨대, 제1 데이터 서버에 동일 파일을 갱신하고자 하는 요청들이 A -> C -> B의 순서로 도착하였고, 제2 데이터 서버에는 갱신 요청이 B -> A - >C의 순서 로 도착하였다고 가정했을 때, 제1 데이터 서버에서 그러한 갱신 요청들을 정렬한 결과가 A -> B -> C라고 하면, 제2 데이터 서버에서도 A -> B -> C의 순서로 정렬 결과가 산출되어야 한다. 정렬 기준 및 방법은 다양한 방식으로 구현될 수 있다.

예컨대, 갱신 연산을 관리하는 자료 구조에서 키로 사용한 <파일 식별자+클라이언트 주소+일련 번호>를 기준으로 오름차순 혹은 내림차순으로 정렬하는 것도 가능한 방법이다.

이후, 데이터 서버는 파이프 라인 순서에 따라 다음 위치의 데이터 서버가 존재하는지를 판단한다(S760).

판단결과, 다음 위치에 데이터 서버가 존재하면, 데이터 서버는 다음 데이터 서버에게 갱신 요청 메시지와 파이프 라인 순서에 따른 잔여 데이터 서버 리스트를 전송한다(S770). 특히, 다음 데이터 서버에게 전달할 <갱신할 영역의 오프셋, 갱신할 영역의 길이> 항목이 S750 과정을 거치면서 데이터 서버 자신이 최초 수신 받은 값으로부터 변경되었다면 그 보정된 <오프셋, 길이> 값을 다음 데이터 서버에게 보낸다. 만일, S750에서 수정되지 않았다면 최초 수신받았던 원래의 <오프셋, 길이> 값을 다음 데이터 서버에게 그대로 보낸다.

이후, 데이터 서버는 자신이 존재하고 있는 파이프라인 상의 위치에 따라 갱신할 실제 데이터를 클라이언트 혹은 다른 데이터 서버로부터 전달받은 후, <갱신할 파일 ID, 클라이언트의 주소, 일련 번호>를 이름으로 가지는 임시 파일을 생성한다(S780). 여기서, 파이프라인 순서의 첫번째에 위치한 데이터 서버는 이러한 갱신 데이터를 클라이언트로부터 전달받으며, 파이프라인 순서에서 첫번째가 아닌 데 이터 서버는 이러한 데이터를 자신의 직전에 위치한 데이터 서버로부터 전달받는다. 단, 관련된 모든 데이터 서버들이 동일한 시점에서 이러한 데이터를 받는 것은 아니며, 파이프라인 순서에서 첫번째가 아닌 데이터 서버들은 자신의 직전에 위치한 데이터 서버가 자신에게 그러한 데이터를 보낼 때 수신하게 된다(S800).

이후, 데이터 서버는 파이프라인 순서에서 자신의 다음 위치에 다른 데이터 서버가 존재할 경우(S790), 그 데이터 서버에게 갱신할 실제 데이터를 전송한다(S800). S800을 수행한 데이터 서버는 파이프라인 순서에서 자신의 다음에 위치한 데이터 서버가 자신에게 <갱신 연산 완료+ (변경된) 오프셋 + (변경된) 길이> 메시지를 보내올 때까지 대기한다(S801). 그러나, 파이프 라인 순서에서 자신의 다음 위치에 다른 데이터 서버가 존재하지 않거나(S790), 자신의 다음에 위치한 데이터 서버가 자신에게 <갱신 연산 완료 + (변경된) 오프셋 + (변경된) 길이> 메시지를 보내왔다면(S801), 데이터 서버는 데이터 구조를 조회한 결과 동일한 파일에 대한 갱신 요청이 복수개 존재하는지를 판단한다.(S802).

판단 결과, 갱신 요청이 복수개 존재하면, 데이터 서버는 해당 갱신 요청들을 특정한 기준으로 정렬한 후(S803), 갱신 요청들에 대한 오프셋과 길이 정보에 따라 중첩되는 오프셋과 길이정보에 대해서는 중첩되지 않도록 오프셋과 길이정보를 보정한다(S804).

이후, 데이터 구조상의 해당 엔트리의 오프셋과 길이정보에 부합하도록 임시 파일에 기록된 내용을 이용하여 원본 파일을 갱신한후(S805), 데이터 구조에서 해당 엔트리를 삭제한다(S806).

이후, 데이터 서버는 파이프라인 순서에서 자신의 이전 위치에 다른 데이터 서버가 존재하는지 판단한다(S807).

판단 결과, 자신의 이전 위치에 다른 데이터 서버가 존재하면 그 데이터 서버에게 <갱신 연산 완료 + (변경된) 오프셋 + (변경된) 길이> 메시지를 전송한다(S808). 그러나, 자신의 이전 위치에 다른 데이터 서버가 존재하지 않는다면 클라이언트에게 갱신 연산 완료 메시지를 전달한다(S809). 여기서, 자신의 이전 위치에 다른 데이터 서버가 존재할 때 보내는 <갱신 연산 완료 + (변경된) 오프셋 + (변경된) 길이> 메시지는 다른 데이터 서버 입장에서는 S801단계에서 수신받게 된다.

한편 본 발명의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 발명의 범위에서 벗어나지 않는 한도내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

도 1은 본 발명의 파일 갱신 시스템의 구성을 보인 구성도.

도 2는 도 1에 있어, 데이터 서버의 내부구성을 보인 구성도.

도 3은 도 1에 있어, 데이터 서버의 파일 갱신동작을 설명하기 위한 예시도.

도 4a 및 도 4b는 도 3에 있어, 제1, 제2 임시파일에 대한 파일 갱신정보가 변경됨을 설명하기 위한 예시도.

도 5는 본 발명의 파일 갱신 시스템의 파일 갱신 동작을 설명하기 위한 예시도.

도 6a 내지 도 6c는 본 발명의 파일 갱신 방법을 보인 흐름도.

Claims (11)

1. 파이프 라인 형태의 네트워크로 구성되어 원본 파일과 그 원본 파일의 복제본 파일을 각각 저장하고, 갱신 요청에 의해 상기 원본 파일과 상기 복제본 파일을 갱신하는 복수의 데이터 서버로 이루어진 파일 갱신 시스템에 있어서,

   상기 원본 파일 또는 상기 복제본 파일을 저장 및 관리하는 제1, 제2 데이터 서버를 포함하며,

   상기 제1, 제2 데이터 서버는 파일 갱신 정보를 상호 교환하며, 동일 파일에 대한 복수의 갱신 요청에 의해 중복 갱신이 발생하지 않도록 상기 파일 갱신정보를 보정한후, 상기 파일 갱신정보에 따라 상기 원본 파일 또는 상기 복제본 파일을 갱신하는 것을 특징으로 하는 파일 갱신 시스템.
2. 제1 항에 있어서, 상기 제1, 제2 데이터 서버는,

   상기 원본 파일 또는 상기 복제본 파일이 저장되는 메모리;

   상기 파일 갱신 요청시, 동일 파일에 대한 복수의 갱신 데이터에 따라 파일 갱신 정보를 보정하여 상기 동일 파일에 해당하는 원본 파일 또는 복제본 파일의 파일 갱신 정보를 갱신하도록 제어하는 제어부를 포함하는 것을 특징으로 하는 파일 갱신 시스템.
3. 제2 항에 있어서, 상기 제어부는,

   상기 파이프 라인 순서에 따라 다음 위치의 데이터 서버가 존재하면, 다음 위치의 데이터 서버에게 갱신할 실제 데이터를 전송하고, 이전 위치의 데이터 서버에게 갱신 연산 완료 메시지와 보정된 파일 갱신정보를 전송하는 것을 특징으로 하는 파일 갱신 시스템.
4. 제2 항에 있어서, 상기 제어부는,

   상기 복수의 갱신 요청에 따른 파일 갱신순서와 파일 갱신정보를 고려하여 파일의 갱신 영역이 중첩되지 않도록 오프셋과 길이정보를 보정하여 해당 원본 파일 또는 복제본 파일을 갱신하는 것을 특징으로 하는 파일 갱신 시스템.
5. 제2 항에 있어서, 상기 제어부는,

   갱신하고자 하는 동일 파일을 저장하고 있는 다른 데이터 서버들에게 상기 파이프라인 형식으로 갱신 요청 메시지와 갱신할 데이터를 전송하는 것을 특징으로 하는 파일 갱신 시스템.
6. 제1 항에 있어서, 상기 파일 갱신정보는,

   갱신하고자 하는 해당 파일의 식별자(ID)에 대한 오프셋과 길이정보로 이루어진 것을 특징으로 하는 파일 갱신 시스템.
7. 파이프 라인 형태의 네트워크로 연결된 복수의 데이터 서버에서 원본 파일과 그 원본 파일의 복제본 파일을 각각 저장하고, 갱신 요청에 의해 상기 원본 파일과 상기 복제본 파일이 동일한 이미지를 갖도록 갱신하기 위한 파일 갱신 방법에 있어서,

   상기 원본 파일에 대한 복수개의 갱신 요청에 따른 파일 갱신 정보를 수신하는 단계;

   상기 갱신 요청에 따라 파일 갱신 순서를 결정하고, 동일 파일에 대한 복수의 갱신 요청에 의해 중복 갱신이 발생하지 않도록 상기 파일 갱신 순서에 따라 상기 파일 갱신 정보를 보정한 후, 보정된 파일 갱신 정보에 따라 상기 원본 파일 또는 복제본 파일을 갱신하는 단계

   를 포함하는 것을 특징으로 하는 파일 갱신 방법.
8. 제7 항에 있어서, 파이프 라인 순서에 따라 다음 위치의 데이터 서버가 존재하는지를 판단하는 단계;

   상기 판단결과에 근거하여, 상기 다음 위치의 데이터 서버에게 파일 갱신 메시지와 갱신 데이터를 전송하는 단계; 및

   상기 파일 갱신 메시지와 파일 갱신순서에 따라 상기 다음 위치의 데이터 서버가 해당 파일을 갱신하는 단계

   를 더 포함하는 것을 특징으로 하는 파일 갱신 방법.
9. 제7 항에 있어서, 상기 원본 파일을 갱신하는 단계는,

   상기 갱신 요청에 따라 중첩되는 원본 파일의 갱신 영역을 확인하는 단계와;

   상기 확인된 갱신 영역이 중첩되지 않도록 오프셋과 길이정보를 보정하는 단계;

   상기 갱신요청에 따른 임시파일을 생성하는 단계;

   파이프라인 순서에 따라 상기 보정된 오프셋과 길이 정보를 상호 교환하는 단계; 및

   상기 보정된 오프셋과 길이정보에 따라 상기 임시파일을 이용하여 상기 원본 파일을 갱신하는 단계

   를 포함하는 것을 특징으로 하는 파일 갱신 방법.
10. 제7 항에 있어서, 상기 파일 갱신정보는,

    갱신하고자 하는 원본 파일의 식별자(ID)에 대한 오프셋과 길이정보로 이루어진 것을 특징으로 하는 파일 갱신 방법.
11. 삭제

Images