4가지 래벨의 리플리케이션 기술들

요즘 NoSQL부분을 살펴보는 중이라 관련된 데이터도 참고 하고 있는 중 리플리케이션의 정의에 대해 잘나와 있길래 번역 해보았습니다.좀예전꺼인거 같긴한데 개념은 잘잡혀 있네요.. 번역본이 잘이해안가시면 재목을 클릭하시면 원문으로 이동 합니다.번역이 세련되지 못하고 미비한점 양해부탁 드립니다.

4 levels of replication technologies

(http://blog.griddynamics.com/2010/02/4-levels-of-replication-technologies.html)

Replication 은, 퍼포먼스 향상, 장애복구, 백업, 등 다양한 목적으로 정보시스템에 폭넓게 사용 된다. 4가지 형태의 Replication 기술들이 이용 가능 하며, 어떠한 기술을 사용할지에 대한 결정은 복제하고자 시도중인 데이터의 논리적 표현에 달려 있다.

1. Storage-level replication
storage level에서, replication은 바이너리 데이터의 블록에 초점을 맞추고 있다. Replication은 block devices 혹은 file-system 레벨에서 수행될 것이다. 양쪽다, replication은 비정형 바이너리 데이터로 처리된다. storage-level replication의 기술적인 범위는 매우 넓으며, 상품형 레이드 어레이부터 NAS와 같은 네트워크 파일시스템까지 다양하다.

2. Database-level replication
보통 어플리케이션들은 파일을 직접 저장하지 않으며, 대신 Databases를 사용한다, Databases는 정형화 데이터를 기반으로 동작하며, Database-level replication 기술들 역시 정형화된 데이터를 처리한다(RDBMS를 위한 레코드들이나, 객체 형 데이터 베이스를 위한 객체).데이터베이스 replication을 위한 주요 기술은 두 가지가 존재 한다.

2.1 Record-based replication(Database-level)

데이터 베이스는 기능적 적합성을 위해 일부 식별 가능한 데이터조각을 활용한다.(데이터 베이스안의 레코드). 레코드 기반 replication 에서는, 각 시간별로(동일시간의미) 하나의 레코드가 정의 되며, 하나의 변경(a logical change record (LCR)) 이벤트는 싱크 상태를 유지하기 위해 replication 파트너에게 전달 된다.

2.2 Statement-based replication (Database-level)

일반적으로 하나의 Statement은 여러개의 레코드로 정리 될 수 있으며, 이와 같은 경우, 문Statement단위로 전달은 레코드단위로(all modified records) 전달할 때 보다는 replication partner에게 좀더 효율적으로 전달 가능하다. 이것이 statement-based 접근 이다.

모든 주류의 DBMS는 built-in 형태의 replication 을 제공한다. 때로는 replication 타입도 조차도.(레코드 또는 statement 기반) 데이터 베이스 컨트롤을 통해 가능하다. MySQL은 이러한 기능이 가능한 제품중의 하나이다.

3.Message-centric replication

흔히 replication 사용 목적은 데이터를 복제가 아니라, 어플리케이션 상태를 복제 이다. 예를 들어, statement-based replication 을 지원하는 데이터 베이스에서, 어플리케이션 상태가 변경될 때, 변경된 데이터를 복제하는 것 대신 비즈니스의 이벤트들의 흐름을 복제할 수 있다. 이벤트들의 동일한 처리는 같은 상태의 어플리케이션을 만든다 (적어도 동등한 상태의 비즈니스를)

Message-centric replication은 몇 가지 실용적인 이득이 있다. 첫째로, replication 은 항상 서로 다른 데이터베이스간 하나의 비즈니스 트랜잭션 단위로 수행된다. 둘째, replication 은 데이터베이스에서 데이터 구조와 관계없이, 지속적으로 데이터 스키마를 업데이트 할 때 매우 도움이 될 것이다 –스키마들의 차이는 replication 토플리지 안에서 공존 가능 하다.
Message-centric replication은 어플리케이션 로직과 강한 연관성이 있다. 이러한 종류의 replication 을 위한 일반적은 솔루션은 존재하지 않으나, 일반적으로 메시지 큐 미들웨어는 replication 파트너간 메시지 전송을 위해 사용 된다.

4.Application-state replication (grid technologies)
메모리 (프레젠테이션 안으로)부터 데이터베이스로 데이터 변경 (작업)은 매우 비효율적이며, 확실히 주요 병목구간이 될 가능성이 있다. Application-state replication은 어플리케이션 프로세스(그리고 서버)간 메모리 안의 데이터 스트럭처 복제가 이와 같은 문제가 발생된다. 이기술에는 두개로 나누어 분류 할수 있다.

4.1 In-memory data grid
In-memory data grids는 스토리지와 같은 샤드 메모리 서비스를 제공한다(모든 그리드 구성원은 동일한 엑세스가 가능하고 스토리지에대한 보기에 영향을 가지고 있다.) 그리드는 API를 제공 하는데, 샤드 스토리지를 잘 조작하기 위해 어플리케이션이 사용한다. 스토리지는 어플리케이션 래벨의 객채증을 저장하고 한다.(직렬화 형태 안에서) . 후드 아래에서(?), 그리드 미들웨어는 프로세스와 서버를 넘어 저장 컨텐츠에 해당 분산 및 replication 에 대해 책임이 존재한다.

4.2 Transparent application clustering

이러한 접근은 replication 의 디테일한 부분을 가능한 숨기며, 어플리케이션 변경 코드를 최소화를 시도한다. 전형적인 기술적 분류를 위해, 프로세스는 워크 프로세스와 (어플리케이션에서 동작하는) 매니지먼트 프로세스로 분리되어 있다. 가장 간단한 경우는, 이들 두 개의 프로세스가 하나로 합쳐질 수 있는 것이며, 매니지먼트 프로세스는 어떠한 어플리케이션 코드도 동작 하지 않는 것이다. 그들은 워크 프로세스들의 인스턴트 상태의 replication 을 통합한다. 이러한 파라다임을 사용중인 상품을 예로들면, 자바 런타임을 위한 클러스트링 구현, 그리고 GemStone – 스몰톡을 위한 클러스터된 런타임(추후에는 루비와 함깨 지원)이 있다.

Advertisements

One thought on “4가지 래벨의 리플리케이션 기술들

  1. Thanks for one’s marvelous posting! I certainly enjoyed reading it, you happen to be a great author. I will be sure to bookmark your blog and will eventually come back someday. I want to encourage yourself to continue your great job, have a nice afternoon!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s