Репликација високог нивоа у Тарантоол ДБМС

Здраво, правим апликације за ДБМС Тарантоол је платформа коју је развила Маил.ру Гроуп која комбинује ДБМС високих перформанси и сервер апликација на језику Луа. Велика брзина решења заснованих на Тарантоол-у је постигнута, посебно, захваљујући подршци ин-мемори режиму ДБМС-а и могућности извршавања пословне логике апликације у једном адресном простору са подацима. У исто време, постојаност података је обезбеђена коришћењем АЦИД трансакција (ВАЛ дневник се одржава на диску). Тарантоол има уграђену подршку за репликацију и дељење. Почевши од верзије 2.1, подржани су упити у СКЛ језику. Тарантоол је отвореног кода и лиценциран под Симплифиед БСД лиценцом. Постоји и комерцијална Ентерприсе верзија.

Осетити снагу! (... такође уживајте у наступу)

Све наведено чини Тарантоол атрактивном платформом за креирање апликација са великим оптерећењем које раде са базама података. У таквим апликацијама често постоји потреба за репликацијом података.

Као што је горе поменуто, Тарантоол има уграђену репликацију података. Принцип његовог рада је да узастопно извршава на репликама све трансакције садржане у главном дневнику (ВАЛ). Обично таква репликација (даље ћемо је назвати низак ниво) се користи да би се обезбедила толеранција на грешке апликације и/или за расподелу оптерећења читања између чворова кластера.

Пиринач. 1. Репликација унутар кластера

Пример алтернативног сценарија би био пренос података креираних у једној бази података у другу базу података ради обраде/надгледања. У последњем случају, погодније решење може бити употреба висок ниво репликација – репликација података на нивоу пословне логике апликације. Оне. Не користимо готово решење уграђено у ДБМС, већ сами имплементирамо репликацију у оквиру апликације коју развијамо. Овај приступ има и предности и недостатке. Хајде да наведемо предности.

1. Уштеде у саобраћају:

• Не можете пренети све податке, већ само њихов део (на пример, можете пренети само неке табеле, неке њихове колоне или записе који испуњавају одређени критеријум);
• За разлику од репликације ниског нивоа, која се обавља континуирано у асинхроном (примењеном у тренутној верзији Тарантоол-а - 1.10) или синхроном (који ће се применити у наредним верзијама Тарантоол-а) режиму, репликација високог нивоа може да се изводи у сесијама (тј. апликација прво синхронизује податке - податке о сесији размене, затим следи пауза у репликацији, након чега долази до следеће сесије размене итд.);
• ако се запис променио неколико пута, можете пренети само његову најновију верзију (за разлику од репликације ниског нивоа, у којој ће се све промене направљене на мастеру репродуковати узастопно на репликама).

2. Нема потешкоћа са имплементацијом ХТТП размене, која вам омогућава да синхронизујете удаљене базе података.

Пиринач. 2. Репликација преко ХТТП-а

3. Структуре базе података између којих се преносе подаци не морају да буду исте (штавише, у општем случају је чак могуће користити различите ДБМС, програмске језике, платформе итд.).

Пиринач. 3. Репликација у хетерогеним системима

Лоша страна је у томе што је, у просеку, програмирање теже/скупље од конфигурисања, и уместо прилагођавања уграђене функционалности, мораћете да имплементирате сопствену.

Ако су у вашој ситуацији горе наведене предности кључне (или су неопходан услов), онда има смисла користити репликацију високог нивоа. Хајде да погледамо неколико начина за имплементацију репликације података високог нивоа у Тарантоол ДБМС.

Минимизација саобраћаја

Дакле, једна од предности репликације на високом нивоу је уштеда саобраћаја. Да би ова предност била у потпуности реализована, потребно је минимизирати количину података који се преносе током сваке сесије размене. Наравно, не треба заборавити да на крају сесије пријемник података мора бити синхронизован са извором (бар за онај део података који је укључен у репликацију).

Како минимизирати количину података пренетих током репликације високог нивоа? Једноставно решење би могло бити одабир података према датуму и времену. Да бисте то урадили, можете користити поље датум-време које већ постоји у табели (ако постоји). На пример, документ „поруџбина“ може имати поље „потребно време извршења налога“ - delivery_time. Проблем са овим решењем је што вредности у овом пољу не морају да буду у редоследу који одговара креирању налога. Дакле, не можемо да се сетимо максималне вредности поља delivery_time, пренет током претходне сесије размене, а током следеће сесије размене изаберите све записе са вишом вредношћу поља delivery_time. Записи са нижом вредношћу поља можда су додати између сесија размене delivery_time. Такође, поредак је могао да претрпи промене, које ипак нису утицале на терен delivery_time. У оба случаја, промене се неће пренети са извора на одредиште. Да бисмо решили ове проблеме, мораћемо да пренесемо податке који се "преклапају". Оне. у свакој сесији размене преносићемо све податке са вредношћу поља delivery_time, прелазећи неку тачку у прошлости (на пример, Н сати од тренутног тренутка). Међутим, очигледно је да је за велике системе овај приступ веома сувишан и може смањити уштеде у саобраћају којима тежимо на ништа. Поред тога, табела која се преноси можда нема поље повезано са датумом и временом.

Друго решење, сложеније у смислу имплементације, је потврда пријема података. У овом случају, током сваке сесије размене, преносе се сви подаци, чији пријем није потврдио прималац. Да бисте ово применили, мораћете да додате Булову колону у изворну табелу (на пример, is_transferred). Ако прималац потврди пријем записа, одговарајуће поље узима вредност true, након чега унос више није укључен у размене. Ова опција имплементације има следеће недостатке. Прво, за сваки пренети запис, мора се генерисати и послати потврда. Грубо говорећи, ово би се могло упоредити са удвостручавањем количине пренетих података и довести до удвостручавања броја повратних путовања. Друго, не постоји могућност слања истог записа на више прималаца (први прималац ће потврдити пријем за себе и за све остале).

Метода која нема горе наведене недостатке је додавање колоне пренесеној табели да би се пратиле промене у њеним редовима. Таква колона може бити типа датум-време и апликација мора да је подеси/ажурира на тренутно време сваки пут када се записи додају/промене (атомски са додавањем/променом). Као пример, назовимо колону update_time. Чувањем максималне вредности поља ове колоне за пренете записе, можемо започети следећу сесију размене са овом вредношћу (изаберите записе са вредношћу поља update_time, премашује претходно сачувану вредност). Проблем са последњим приступом је у томе што се промене података могу десити у групама. Као резултат вредности поља у колони update_time можда није јединствен. Дакле, ова колона се не може користити за порционисане (страницу по страницу) излаз података. Да бисте приказали податке страницу по страницу, мораћете да измислите додатне механизме који ће највероватније имати веома ниску ефикасност (на пример, преузимање из базе података свих записа са вредношћу update_time већи од специфицираних и излазе одређени број записа, почевши од одређеног помака од почетка узорка).

Ефикасност преноса података можете побољшати благим побољшањем претходног приступа. Да бисмо то урадили, користићемо тип целог броја (дуги цео број) као вредности поља колоне за праћење промена. Назовимо колону row_ver. Вредност поља ове колоне и даље мора бити подешена/ажурирана сваки пут када се запис креира/моди. Али у овом случају пољу неће бити додељен тренутни датум-време, већ вредност неког бројача, увећана за један. Као резултат тога, колона row_ver ће садржати јединствене вредности и може се користити не само за приказ „делта“ података (подаци додати/промењени од краја претходне сесије размене), већ и да их једноставно и ефикасно раздвоје на странице.

Последњи предложени метод минимизирања количине података пренетих у оквиру репликације високог нивоа ми се чини најоптималнијим и универзалним. Погледајмо то детаљније.

Преношење података помоћу бројача верзија реда

Имплементација серверског/мастер дела

У МС СКЛ Серверу постоји посебан тип колоне за имплементацију овог приступа - rowversion. Свака база података има бројач који се повећава за један сваки пут када се запис дода/промени у табели која има колону попут rowversion. Вредност овог бројача се аутоматски додељује пољу ове колоне у додатом/промењеном запису. Тарантоол ДБМС нема сличан уграђени механизам. Међутим, у Тарантоолу није тешко имплементирати га ручно. Погледајмо како се то ради.

Прво, мало терминологије: табеле у Тарантоолу се зову размаци, а записи се зову торке. У Тарантоол-у можете креирати секвенце. Секвенце нису ништа друго до именовани генератори уређених целобројних вредности. Оне. то је управо оно што нам је потребно за наше сврхе. У наставку ћемо креирати такав низ.

Пре него што извршите било коју операцију базе података у Тарантоол-у, потребно је да покренете следећу команду:

box.cfg{}

Као резултат тога, Тарантоол ће почети да пише снимке базе података и евиденције трансакција у тренутни директоријум.

Хајде да направимо секвенцу row_version:

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

Опција if_not_exists дозвољава да се скрипта за креирање извршава више пута: ако објекат постоји, Тарантоол неће покушати да га поново креира. Ова опција ће се користити у свим наредним ДДЛ командама.

Хајде да направимо простор као пример.

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), називи поља и њихови типови.

Поља са аутоматским повећањем у Тарантоол-у се такође креирају помоћу секвенци. Хајде да креирамо примарни кључ који се аутоматски повећава по пољу 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
})

Тарантоол подржава неколико типова индекса. Најчешће коришћени индекси су типови ТРЕЕ и ХАСХ, који се заснивају на структурама које одговарају имену. ТРЕЕ је најсвестранији тип индекса. Омогућава вам да прикупљате податке на организован начин. Али за селекцију једнакости, ХАСХ је погоднији. Сходно томе, препоручљиво је користити ХАСХ за примарни кључ (што смо и урадили).

Да бисте користили колону row_ver да бисте пренели измењене податке, потребно је да повежете вредности секвенце за поља ове колоне row_ver. Али за разлику од примарног кључа, вредност поља колоне row_ver треба повећати за један не само при додавању нових записа, већ и при промени постојећих. За ово можете користити окидаче. Тарантоол има две врсте окидача простора: before_replace и on_replace. Окидачи се покрећу кад год се подаци у простору промене (за сваки тупле на који промене утичу, покреће се функција окидача). за разлику од on_replace, before_replace-окидачи вам омогућавају да модификујете податке торке за коју се окидач извршава. Сходно томе, последња врста окидача нам одговара.

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}

Јер Прво поље је бројач који се аутоматски повећава; уместо тога преносимо нулу. Тарантоол ће аутоматски заменити следећу вредност. Слично, као вредност поља колоне row_ver можете проследити нил - или уопште не навести вредност, јер ова колона заузима последњу позицију у простору.

Хајде да проверимо резултат уметања:

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, почевши од чега је потребно да се испразне промене, и враћа део измењених података.

Узорковање података у Тарантоол-у се врши преко индекса. Функција get_goods користи итератор по индексу row_ver да примите измењене податке. Тип итератора је ГТ (Греатер Тхан, ларгер тхан). То значи да ће итератор узастопно прелазити вредности индекса почевши од прослеђеног кључа (вредност поља row_ver).

Итератор враћа тупле. Да би се накнадно могли преносити подаци путем ХТТП-а, потребно је конвертовати торке у структуру погодну за накнадну серијализацију. Пример користи стандардну функцију за ово 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 омогућава вам да примите податке који су се променили од његовог последњег позива, што је основа методе репликације која се разматра.

Издавање резултата путем ХТТП-а у облику ЈСОН-а оставићемо ван оквира овог чланка. О овоме можете прочитати овде: 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 преко ХТТП-а. Да бисмо то урадили, потребна нам је библиотека која имплементира ХТТП клијента. Следећи ред учитава библиотеку и инстанцира ХТТП клијента:

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

Такође нам је потребна библиотека за јсон десериализацију:

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

Функција извршава ХТТП захтев на урл адресу и шаље га 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 нула. Следеће у циклусу вршимо преузимање измењених података од странице до странице са извора на наведеном УРЛ-у. На свакој итерацији примљене податке чувамо у одговарајући локални простор и ажурирамо вредност 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 може се користити за пренос података из других простора: нема потребе да се креира посебна секвенца за сваки пренет простор.

Размотрили смо ефикасан начин репликације података високог нивоа у апликацијама које користе Тарантоол ДБМС.

Налази

1. Тарантоол ДБМС је атрактиван, обећавајући производ за креирање апликација са великим оптерећењем.
2. Репликација података високог нивоа има бројне предности у односу на репликацију ниског нивоа.
3. Метода репликације високог нивоа о којој се говори у чланку омогућава вам да минимизирате количину пренетих података преносом само оних записа који су се променили од последње сесије размене.

Извор: ввв.хабр.цом