Tarantool DBMS의 높은 수준의 복제

안녕하세요 DBMS용 애플리케이션을 만들고 있습니다. 타란툴 고성능 DBMS와 애플리케이션 서버를 Lua 언어로 결합한 Mail.ru Group에서 개발한 플랫폼입니다. Tarantool 기반 솔루션의 빠른 속도는 특히 DBMS의 인메모리 모드 지원과 데이터가 있는 단일 주소 공간에서 애플리케이션 비즈니스 로직을 실행할 수 있는 능력으로 인해 달성됩니다. 동시에 ACID 트랜잭션을 사용하여 데이터 지속성이 보장됩니다(WAL 로그가 디스크에 유지됨). Tarantool에는 복제 및 샤딩 지원 기능이 내장되어 있습니다. 버전 2.1부터 SQL 언어 쿼리가 지원됩니다. Tarantool은 오픈 소스이며 Simplified BSD 라이센스에 따라 라이센스가 부여됩니다. 상용 Enterprise 버전도 있습니다.

힘을 느껴라! (…일명 공연을 즐기세요)

위의 모든 사항 덕분에 Tarantool은 데이터베이스와 함께 작동하는 고부하 애플리케이션을 생성하기 위한 매력적인 플랫폼이 되었습니다. 이러한 애플리케이션에서는 데이터 복제가 필요한 경우가 많습니다.

위에서 언급했듯이 Tarantool에는 데이터 복제 기능이 내장되어 있습니다. 작동 원리는 마스터 로그(WAL)에 포함된 모든 트랜잭션을 복제본에서 순차적으로 실행하는 것입니다. 일반적으로 이러한 복제(우리는 이를 추가로 호출합니다. 낮은 수준의)은 애플리케이션 내결함성을 보장하거나 클러스터 노드 간에 읽기 로드를 분산하는 데 사용됩니다.

쌀. 1. 클러스터 내 복제

대체 시나리오의 예로는 처리/모니터링을 위해 한 데이터베이스에서 생성된 데이터를 다른 데이터베이스로 전송하는 것입니다. 후자의 경우에는 다음을 사용하는 것이 더 편리한 솔루션이 될 수 있습니다. 높은 레벨 복제 - 애플리케이션 비즈니스 로직 수준의 데이터 복제입니다. 저것들. DBMS에 내장된 기성 솔루션을 사용하지 않고, 개발 중인 애플리케이션 내에서 자체적으로 복제를 구현합니다. 이 접근 방식에는 장점과 단점이 모두 있습니다. 장점을 나열해보자.

1. 트래픽 절감:

• 모든 데이터를 전송할 수는 없고 일부만 전송할 수 있습니다(예를 들어 특정 기준을 충족하는 일부 테이블, 해당 열 또는 레코드 중 일부만 전송할 수 있음).
• 비동기(현재 버전의 Tarantool - 1.10에서 구현) 또는 동기(향후 버전의 Tarantool에서 구현 예정) 모드에서 지속적으로 수행되는 하위 수준 복제와 달리 상위 수준 복제는 세션(예: 애플리케이션은 먼저 데이터를 동기화합니다(교환 세션 데이터, 그런 다음 복제가 일시 중지된 후 다음 교환 세션이 발생하는 등).
• 레코드가 여러 번 변경된 경우 최신 버전만 전송할 수 있습니다(마스터에 대한 모든 변경 사항이 복제본에서 순차적으로 재생되는 하위 수준 복제와는 다름).

2. 원격 데이터베이스를 동기화할 수 있는 HTTP 교환을 구현하는 데 어려움이 없습니다.

쌀. 2. HTTP를 통한 복제

3. 데이터가 전송되는 데이터베이스 구조는 동일할 필요가 없습니다(게다가 일반적인 경우에는 서로 다른 DBMS, 프로그래밍 언어, 플랫폼 등을 사용하는 것도 가능합니다).

쌀. 3. 이기종 시스템에서의 복제

단점은 평균적으로 프로그래밍이 구성보다 더 어렵고 비용이 많이 들고, 내장된 기능을 사용자 정의하는 대신 직접 구현해야 한다는 것입니다.

귀하의 상황에서 위의 이점이 중요하거나 필수 조건인 경우 상위 수준 복제를 사용하는 것이 합리적입니다. Tarantool DBMS에서 높은 수준의 데이터 복제를 구현하는 여러 가지 방법을 살펴보겠습니다.

트래픽 최소화

따라서 상위 수준 복제의 장점 중 하나는 트래픽 절감입니다. 이러한 이점을 완전히 실현하려면 각 교환 세션 동안 전송되는 데이터의 양을 최소화해야 합니다. 물론 세션이 끝나면 데이터 수신기가 소스(적어도 복제와 관련된 데이터 부분)와 동기화되어야 한다는 점을 잊어서는 안 됩니다.

상위 수준 복제 중에 전송되는 데이터 양을 최소화하는 방법은 무엇입니까? 간단한 해결책은 날짜와 시간별로 데이터를 선택하는 것입니다. 이를 수행하려면 테이블에 이미 존재하는 날짜-시간 필드(있는 경우)를 사용할 수 있습니다. 예를 들어, "주문" 문서에는 "필요한 주문 실행 시간" 필드가 있을 수 있습니다. delivery_time. 이 솔루션의 문제점은 이 필드의 값이 주문 생성에 해당하는 순서에 있을 필요가 없다는 것입니다. 따라서 최대 필드 값을 기억할 수 없습니다. delivery_time, 이전 교환 세션 동안 전송되고 다음 교환 세션 동안 더 높은 필드 값을 가진 모든 레코드를 선택합니다. delivery_time. 교환 세션 사이에 필드 값이 더 낮은 레코드가 추가되었을 수 있습니다. delivery_time. 또한 순서가 변경되었을 수도 있지만 그럼에도 불구하고 필드에는 영향을 미치지 않습니다. delivery_time. 두 경우 모두 변경 사항이 원본에서 대상으로 전송되지 않습니다. 이러한 문제를 해결하려면 데이터를 "겹쳐" 전송해야 합니다. 저것들. 각 교환 세션에서 필드 값이 포함된 모든 데이터를 전송합니다. delivery_time, 과거의 특정 시점(예: 현재 순간부터 N시간)을 초과합니다. 그러나 대규모 시스템의 경우 이 접근 방식은 중복성이 매우 높으며 우리가 추구하는 트래픽 절감 효과를 전혀 줄일 수 없다는 것은 분명합니다. 또한 전송되는 테이블에는 날짜-시간과 관련된 필드가 없을 수도 있습니다.

구현 측면에서 더 복잡한 또 다른 솔루션은 데이터 수신을 승인하는 것입니다. 이 경우 각 교환 세션 동안 모든 데이터가 전송되며 수신자가 수신을 확인하지 않았습니다. 이를 구현하려면 소스 테이블에 부울 열을 추가해야 합니다(예: is_transferred). 수신자가 레코드 수신을 확인하면 해당 필드는 값을 갖습니다. true, 그 후에는 해당 항목이 더 이상 교환에 포함되지 않습니다. 이 구현 옵션에는 다음과 같은 단점이 있습니다. 먼저, 전송된 각 레코드에 대해 승인을 생성하여 보내야 합니다. 대략적으로 말하면 이는 전송되는 데이터 양이 두 배로 늘어나 왕복 횟수가 두 배로 늘어나는 것과 비슷할 수 있습니다. 둘째, 동일한 레코드를 여러 수신자에게 보낼 가능성이 없습니다(수신한 첫 번째 수신자는 자신과 다른 모든 수신자에 대한 수신을 확인합니다).

위에 주어진 단점이 없는 방법은 전송된 테이블에 열을 추가하여 해당 행의 변경 사항을 추적하는 것입니다. 이러한 열은 날짜-시간 유형일 수 있으며 레코드가 추가/변경될 때마다(원자적으로 추가/변경) 애플리케이션에서 현재 시간으로 설정/업데이트해야 합니다. 예를 들어, 열을 호출해 보겠습니다. update_time. 전송된 레코드에 대해 이 열의 최대 필드 값을 저장하면 이 값으로 다음 교환 세션을 시작할 수 있습니다(필드 값이 있는 레코드 선택). update_time, 이전에 저장된 값을 초과함). 후자 접근 방식의 문제점은 데이터 변경이 일괄적으로 발생할 수 있다는 것입니다. 해당 열의 필드 값에 따라 update_time 고유하지 않을 수 있습니다. 따라서 이 열은 분할된(페이지별) 데이터 출력에 사용할 수 없습니다. 데이터를 페이지별로 표시하려면 효율성이 매우 낮은 추가 메커니즘을 개발해야 합니다(예: 데이터베이스에서 값이 있는 모든 레코드 검색). update_time 주어진 것보다 높고 샘플 시작 부분의 특정 오프셋부터 시작하여 특정 수의 레코드를 생성합니다.

이전 접근 방식을 약간 개선하여 데이터 전송 효율성을 향상시킬 수 있습니다. 이를 위해 변경 사항 추적을 위한 열 필드 값으로 정수 유형(긴 정수)을 사용합니다. 열 이름을 지정해 보겠습니다. row_ver. 이 열의 필드 값은 레코드가 생성/수정될 때마다 계속 설정/업데이트되어야 합니다. 그러나 이 경우 필드에는 현재 날짜-시간이 할당되지 않고 일부 카운터의 값이 XNUMX씩 증가합니다. 그 결과 칼럼은 row_ver 고유한 값을 포함하며 "델타" 데이터(이전 교환 세션 종료 이후 추가/변경된 데이터)를 표시하는 데 사용할 수 있을 뿐만 아니라 간단하고 효과적으로 페이지로 분할하는 데에도 사용할 수 있습니다.

상위 수준 복제 프레임워크 내에서 전송되는 데이터 양을 최소화하기 위해 마지막으로 제안된 방법이 가장 최적이고 보편적인 방법인 것 같습니다. 좀 더 자세히 살펴보겠습니다.

행 버전 카운터를 사용하여 데이터 전달

서버/마스터 부분 구현

MS SQL Server에는 이 접근 방식을 구현하는 특별한 열 유형이 있습니다. rowversion. 각 데이터베이스에는 다음과 같은 열이 있는 테이블에 레코드가 추가/변경될 때마다 XNUMX씩 증가하는 카운터가 있습니다. rowversion. 이 카운터의 값은 추가/변경된 레코드에서 이 열의 필드에 자동으로 할당됩니다. Tarantool DBMS에는 유사한 내장 메커니즘이 없습니다. 그러나 Tarantool에서는 수동으로 구현하는 것이 어렵지 않습니다. 이것이 어떻게 수행되는지 살펴 보겠습니다.

첫째, 약간의 용어입니다. Tarantool의 테이블은 공백이라고 하며 레코드는 튜플이라고 합니다. Tarantool에서는 시퀀스를 생성할 수 있습니다. 시퀀스는 순서가 지정된 정수 값의 명명된 생성자에 지나지 않습니다. 저것들. 이것이 바로 우리의 목적에 필요한 것입니다. 아래에서는 이러한 시퀀스를 만듭니다.

Tarantool에서 데이터베이스 작업을 수행하기 전에 다음 명령을 실행해야 합니다:

box.cfg{}

결과적으로 Tarantool은 데이터베이스 스냅샷과 트랜잭션 로그를 현재 디렉터리에 쓰기 시작합니다.

시퀀스를 만들어보자 row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

옵션 if_not_exists 생성 스크립트를 여러 번 실행할 수 있습니다. 객체가 존재하면 Tarantool은 객체를 다시 생성하려고 시도하지 않습니다. 이 옵션은 모든 후속 DDL 명령에서 사용됩니다.

예시로 공간을 만들어 보겠습니다.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

여기서는 공간의 이름을 설정합니다(goods), 필드 이름 및 해당 유형.

Tarantool의 자동 증가 필드도 시퀀스를 사용하여 생성됩니다. 필드별로 자동 증가하는 기본 키를 만들어 보겠습니다. id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

Tarantool은 여러 유형의 인덱스를 지원합니다. 가장 일반적으로 사용되는 인덱스는 이름에 해당하는 구조를 기반으로 하는 TREE 및 HASH 유형입니다. TREE는 가장 다양한 인덱스 유형입니다. 이를 통해 체계적인 방식으로 데이터를 검색할 수 있습니다. 그러나 평등 선택에는 HASH가 더 적합합니다. 따라서 기본 키로 HASH를 사용하는 것이 좋습니다(우리는 그렇게 했습니다).

컬럼을 사용하려면 row_ver 변경된 데이터를 전송하려면 시퀀스 값을 이 열의 필드에 바인딩해야 합니다. row_ver. 그러나 기본 키와 달리 열 필드 값은 row_ver 새로운 레코드를 추가할 때뿐만 아니라 기존 레코드를 변경할 때도 XNUMX씩 증가해야 합니다. 이를 위해 트리거를 사용할 수 있습니다. Tarantool에는 두 가지 유형의 공간 트리거가 있습니다. before_replace и on_replace. 트리거는 공간의 데이터가 변경될 때마다 실행됩니다(변경 사항의 영향을 받는 각 튜플에 대해 트리거 기능이 시작됨). 같지 않은 on_replace, before_replace-triggers를 사용하면 트리거가 실행되는 튜플의 데이터를 수정할 수 있습니다. 따라서 마지막 유형의 트리거가 우리에게 적합합니다.

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

다음 트리거는 필드 값을 대체합니다. row_ver 시퀀스의 다음 값에 튜플을 저장했습니다. row_version.

우주에서 데이터를 추출할 수 있도록 goods 열별 row_ver, 색인을 생성해 보겠습니다.

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

인덱스 유형 - 트리(TREE), 왜냐하면 열에 있는 값의 오름차순으로 데이터를 추출해야 합니다. row_ver.

공간에 몇 가지 데이터를 추가해 보겠습니다.

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

왜냐하면 첫 번째 필드는 자동 증가 카운터이므로 대신 nil을 전달합니다. Tarantool은 자동으로 다음 값을 대체합니다. 마찬가지로 열 필드의 값으로 row_ver nil을 전달하거나 값을 전혀 지정하지 않을 수 있습니다. 이 열은 공간의 마지막 위치를 차지합니다.

삽입 결과를 확인해 보겠습니다.

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

보시다시피 첫 번째 필드와 마지막 필드는 자동으로 채워집니다. 이제 공간 변경 사항을 페이지별로 업로드하는 기능을 쉽게 작성할 수 있습니다. goods:

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

함수는 매개변수로 값을 취합니다. row_ver, 변경 사항을 언로드해야 하는 경우부터 시작하여 변경된 데이터의 일부를 반환합니다.

Tarantool의 데이터 샘플링은 인덱스를 통해 수행됩니다. 기능 get_goods 인덱스별로 반복자를 사용합니다. row_ver 변경된 데이터를 수신합니다. 반복자 유형은 GT(보다 큼, 보다 큼)입니다. 이는 반복자가 전달된 키(필드 값)부터 시작하여 인덱스 값을 순차적으로 순회한다는 의미입니다. row_ver).

반복자는 튜플을 반환합니다. 이후에 HTTP를 통해 데이터를 전송할 수 있으려면 튜플을 후속 직렬화에 편리한 구조로 변환해야 합니다. 예제에서는 이를 위해 표준 함수를 사용합니다. tomap. 사용하는 대신 tomap 자신만의 기능을 작성할 수 있습니다. 예를 들어 필드 이름을 바꾸고 싶을 수도 있습니다. name, 필드를 통과하지 마십시오 code 필드를 추가하고 comment:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

출력 데이터의 페이지 크기(한 부분의 레코드 수)는 변수에 의해 결정됩니다. page_size. 예에서 값은 page_size 5입니다. 실제 프로그램에서는 일반적으로 페이지 크기가 더 중요합니다. 이는 공간 튜플의 평균 크기에 따라 다릅니다. 최적의 페이지 크기는 데이터 전송 시간을 측정하여 경험적으로 결정할 수 있습니다. 페이지 크기가 클수록 송신측과 수신측 간의 왕복 횟수가 줄어듭니다. 이렇게 하면 변경 사항을 다운로드하는 데 소요되는 전체 시간을 줄일 수 있습니다. 그러나 페이지 크기가 너무 크면 샘플을 직렬화하는 서버에 너무 많은 시간을 소비하게 됩니다. 결과적으로 서버로 들어오는 다른 요청을 처리하는 데 지연이 발생할 수 있습니다. 매개변수 page_size 구성 파일에서 로드할 수 있습니다. 전송된 각 공간에 대해 고유한 값을 설정할 수 있습니다. 그러나 대부분의 공간에서는 기본값(예: 100)이 적합할 수 있습니다.

함수를 실행해보자 get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

필드 값을 사용하자 row_ver 마지막 줄부터 함수를 다시 호출합니다.

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

그리고 다시 한번 :

tarantool> get_goods(8)
---
- []
...

보시다시피, 이 방법을 사용하면 함수는 모든 공간 레코드를 페이지별로 반환합니다. goods. 마지막 페이지 뒤에는 빈 선택 항목이 나옵니다.

공간을 변경해 보겠습니다.

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

필드 값을 변경했습니다 name 하나의 항목에 대해 두 개의 새 항목을 추가했습니다.

마지막 함수 호출을 반복해 보겠습니다.

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

이 함수는 변경 및 추가된 레코드를 반환했습니다. 그래서 기능은 get_goods 고려 중인 복제 방법의 기초가 되는 마지막 호출 이후 변경된 데이터를 수신할 수 있습니다.

JSON 형식으로 HTTP를 통해 결과를 발행하는 것은 이 기사의 범위를 벗어나도록 하겠습니다. 이에 대한 내용은 여기에서 읽을 수 있습니다. https://habr.com/ru/company/mailru/blog/272141/

클라이언트/슬레이브 부분 구현

수신 측의 구현이 어떻게 보이는지 살펴보겠습니다. 다운로드한 데이터를 저장하기 위해 수신 측에 공간을 만들어 보겠습니다.

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

공간의 구조는 소스의 공간 구조와 유사합니다. 하지만 수신된 데이터를 다른 곳으로 전달하지 않을 것이므로 해당 열은 row_ver 수신자의 공간에 없습니다. 현장에서 id 소스 식별자가 기록됩니다. 따라서 수신자 측에서는 자동 증가를 만들 필요가 없습니다.

또한, 가치를 저장하는 공간이 필요합니다. row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

로드된 공간마다(필드 space_name) 여기에 마지막으로 로드된 값을 저장하겠습니다. row_ver (필드 value). 열이 기본 키 역할을 합니다. space_name.

공간 데이터를 불러오는 함수를 만들어 보겠습니다. goods HTTP를 통해. 이를 위해서는 HTTP 클라이언트를 구현하는 라이브러리가 필요합니다. 다음 줄은 라이브러리를 로드하고 HTTP 클라이언트를 인스턴스화합니다.

local http_client = require('http.client').new()

json 역직렬화를 위한 라이브러리도 필요합니다.

local json = require('json')

이는 데이터 로딩 함수를 생성하기에 충분합니다.

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

이 함수는 URL 주소에 대한 HTTP 요청을 실행하고 이를 보냅니다. row_ver 매개변수로 요청의 역직렬화된 결과를 반환합니다.

수신된 데이터를 저장하는 기능은 다음과 같습니다.

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

데이터를 공간에 저장하는 주기 goods 트랜잭션에 배치됨(이 기능은 이 작업에 사용됨) box.atomic) 디스크 작업 수를 줄입니다.

마지막으로 로컬 공간 동기화 기능 goods 소스를 사용하면 다음과 같이 구현할 수 있습니다.

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

먼저 이전에 저장된 값을 읽습니다. row_ver 공간을 위해 goods. 누락된 경우(첫 번째 교환 세션) 다음과 같이 간주합니다. row_ver 영. 다음 주기에서는 지정된 URL의 소스에서 변경된 데이터를 페이지별로 다운로드합니다. 각 반복마다 수신된 데이터를 적절한 로컬 공간에 저장하고 값을 업데이트합니다. row_ver (우주에서 row_ver 그리고 변수에 row_ver) - 가치를 취하다 row_ver 로드된 데이터의 마지막 줄부터

우발적인 루프(프로그램에 오류가 있는 경우)를 방지하기 위해 루프는 while 로 교체 가능 for:

for _ = 1, max_req do ...

함수를 실행한 결과 sync_goods 공간 goods 수신기에는 모든 우주 기록의 최신 버전이 포함됩니다. goods 소스에서.

분명히 데이터 삭제는 이런 방식으로 브로드캐스트될 수 없습니다. 그러한 필요가 있는 경우 삭제 표시를 사용할 수 있습니다. 공간에 추가 goods 부울 필드 is_deleted 레코드를 물리적으로 삭제하는 대신 논리적 삭제를 사용합니다. 필드 값을 설정합니다. is_deleted 의미상 true. 때로는 부울 필드 대신 is_deleted 현장을 이용하는 것이 더 편리합니다. deleted, 레코드의 논리적 삭제 날짜-시간을 저장합니다. 논리적 삭제를 수행한 후 삭제 표시된 레코드는 위에서 설명한 논리에 따라 원본에서 대상으로 전송됩니다.

순서 row_ver 다른 공간에서 데이터를 전송하는 데 사용할 수 있습니다. 전송된 각 공간에 대해 별도의 시퀀스를 만들 필요가 없습니다.

우리는 Tarantool DBMS를 사용하여 애플리케이션에서 높은 수준의 데이터 복제를 수행하는 효과적인 방법을 살펴보았습니다.

조사 결과

1. Tarantool DBMS는 고부하 애플리케이션을 생성하는 데 있어 매력적이고 유망한 제품입니다.
2. 높은 수준의 데이터 복제는 낮은 수준의 복제에 비해 여러 가지 장점이 있습니다.
3. 기사에서 설명한 높은 수준의 복제 방법을 사용하면 마지막 교환 세션 이후 변경된 레코드만 전송하여 전송되는 데이터의 양을 최소화할 수 있습니다.

출처 : habr.com