Kõrgetasemeline replikatsioon andmebaasides Tarantool

Tere, ma teen rakendusi andmebaasihaldussüsteemide jaoks Tarantool — see on Mail.ru Group'i välja töötatud platvorm, mis ühendab endas kõrge jõudlusega andmebaasihaldussüsteemi ja rakenduste serveri Lua keeles. Tarantoolist põhinevate lahenduste kõrge töökiirus saavutatakse osaliselt tänu in-memory andmebaasi režiimi toele ja võimalusele täita rakenduse äriloogikat samaaegselt andmetega ühes aadressiruumi. Samuti tagatakse andmete püsivus ACID-tehingute abil (plaadil peetakse WAL-logi). Tarantool toetab sisseehitatud replikeerimist ja shardingut. Alates versioonist 2.1 toetatakse SQL-küsitlusi. Tarantoolil on avatud lähtekood ja see levib Simplified BSD litsentsi alusel. Samuti on olemas kommerts Enterprise-versioon.

Tunnetage jõudu! (…ehk nautige jõudlust)

Kõik eeltoodud teeb Tarantoolist atraktiivse platvormi kõrge koormusega andmebaasirakenduste loomiseks. Sellistes rakendustes tekib sageli vajadus andmete replikatsiooni järele.

Nagu juba varem öeldi, on Tarantoolis sisseehitatud andmete replikatsioon. Selle tööpõhimõte põhineb kõigi meistri (WAL) logis olevate tehingute järjestikusel täitmisel replikatsioonides. Tavaliselt kasutatakse seda replikatsiooni (nimetame seda edasi madaltasemeliseks) rakenduse tõrgeteta toimimise tagamiseks ja/või koormuse jaotamiseks klastrite vahel.

Joonis 1. Replikatsioon klastris

Alternatiivse stsenaariumi näiteks võib olla andmete edastamine, mis on loodud ühes andmebaasis, teise andmebaasi töötlemiseks/monitoreerimiseks. Viimasel juhul võib mugavam lahendus olla kõrgtasemeline replikatsioon — andmete replikatsioon äri loogika tasemel. See tähendab, et me ei kasuta valmis lahendust, mis on sisse ehitatud andmebaasihaldussüsteemi, vaid ellu viime replikatsiooni meie loodud rakenduses. Sellel lähenemisel on nii eelised kui ka puudused. Loetleme plusse.

1. Andmeside kokkuhoid:

• saab edastada mitte kõiki andmeid, vaid ainult nende osa (näiteks saab edastada ainult teatud tabeleid, nende teatud veerge või kirjeid, mis vastavad teatud kriteeriumile);
• erinevalt madala taseme replikatsioonist, mis toimub pidevalt asünkroonses (teostatud praeguses versioonis Tarantool — 1.10) või sünkroonses (mis tehakse tulevastes versioonides Tarantool) režiimis, saab kõrge taseme replikatsiooni teostada sessioonide kaupa (st rakendus esmalt sünkroniseerib andmeid — andmevahetuse sessioon, seejärel toimub replikatsiooni paus, pärast mida toimub järgmine andmevahetuse sessioon jne);
• kui salvestust on mitu korda muudetud, saab edastada ainult selle viimase versiooni (erinevalt madala taseme replikatsioonist, kus jäljendites järk-järgult esitletakse kõik muudatused, mis on tehtud meistris).

2. Puuduvad keerukused HTTP vahetuse rakendamisel, mis võimaldab kauge DB-de sünkroonimist.

Joonis 2. Replikatsioon HTTP kaudu

3. Andmebaasi struktuurid, mille vahel andmeid edastatakse, ei pea olema identsed (veelgi enam, enamasti on võimalik kasutada isegi erinevaid andmebaasesüsteeme, programmeerimiskeeli, platvorme jne).

Joonis 3. Replikatsioon heterogeensetes süsteemides

Miinus seisneb selles, et keskmiselt on programmeerimine keerulisem/kallim kui konfigureerimine, ja valmis funktsionaalsuse seadistamise asemel tuleb oma kujundada.

Kui teie olukorras mängivad nimetatud plussid otsustavat rolli (või on vajalik tingimus), siis on mõtet kasutada kõrge taseme replikatsiooni. Vaatame mitmeid viise kõrge taseme replikatsiooni rakendamiseks Tarantooli andmebaasides.

Liikluse minimeerimine

Seega on üks kõrge taseme replikatsiooni eelistest liikluse kokkuhoid. Selle eelise täielikuks väljendamiseks on oluline minimeerida andmete mahtu, mis edastatakse igas andmevahetuse sessioonis. Loomulikult ei tohi unustada, et sessiooni lõpus peab andmete vastuvõtja olema sünkroonitud allikaga (vähemalt nende andmete osas, mis on seotud replikatsiooniga).

Kuidas aga minimeerida andmete hulka, mis edastatakse kõrge taseme replikatsiooni käigus? Otsene lahendus võiks olla andmete valik kuupäeva ja aja põhjal. Selleks saab kasutada juba tabelis olevat kuupäeva-aja välja (kui see on olemas). Näiteks võib dokumendil "tellimus" olla välja "tellimuse täitmise nõutud aeg" — tarneaeg. Selle lahenduse probleem seisneb selles, et selle välja väärtused ei pruugi olla järjestatud tellimuste loomise järjekorras. Seega ei saa me meeles pidada välja maksimaalset väärtust tarneaeg, mis oli edastatud eprevious vahetuse seansi ajal, ja järgmise vahetuse seansi ajal filtreerida kõik kirjed, mille välja väärtus on kõrgem tarneaeg. Vahetuste vahel võivad olla lisandunud kirjed, mille välja väärtus on madalam tarneaeg. Samuti võis tellimus olla muutunud, kuigi see ei mõjutanud välja tarneaeg. Mõlemal juhul ei edastata muudatusi allikast vastuvõtjale. Nende probleemide lahendamiseks peame andmeid edastama "ülekattega". See tähendab, et iga vahetuse seansi ajal edastame kõik andmed, mille välja väärtus on tarneaeg, ületades mingi hetk minevikus (näiteks N tundi alates praegusest hetkest). Siiski on selge, et suurte süsteemide jaoks on selline lähenemine tugevalt ülemäärane ja võib kaotada liikluse kokkuhoiu, mille poole me püüdleme. Lisaks ei pruugi edastatavas tabelis olla välja, mis on seotud kuupäeva ja kellaajaga.

Teine lahendus, mis on rakendamise seisukohalt keerulisem, seisneb andmete vastuvõtmise kinnitamises. Sel juhul edastatakse igal vahetuse seansil kõik andmed, mille vastuvõtmist ei ole vastuvõtja kinnitanud. Selle rakendamiseks on vajalik lisada allika tabelisse bool kategooria (näiteks, is_transferred). Kui vastuvõtja kinnitab kirje saamist, saab vastav väli väärtuse true, pärast mida see kirje enam vahetustes ei osale. Selle rakendamise variandil on järgmised puudused. Esiteks on vajalik iga edastatud kirje jaoks genereerida ja saata kinnitus. Lihtsalt öeldes võib see olla võrreldav edastatavate andmete mahu kahekordistamisega ning viia ka kahepoolsete ringide arvu kahekordistumiseni. Teiseks puudub võimalus edastada sama kirjet mitmele vastuvõtjale (esimene vastuvõtja, kes on selle saanud, kinnitab saamise enda ja kõigi teiste eest).

Tõhus viis, mis ei sisalda eeltoodud puudusi, seisneb edastatavas tabelis muudatuste jälgimise veeru lisamises. See veerg võib olla kuupäev-aeg ja peab olema rakenduse poolt seadistatud/uuendatud praegustele aegadele iga kord, kui andmeid lisatakse/või muudetakse (aatomaarse lisamise/muutmisega). Näiteks nimetame veerg update_time. Salvestades selle veeru maksimaalse väärtuse edastatud ridade jaoks, saame alustada järgmisi andmevahetusseansse sellest väärtusest (valida kirjed, mille veeru väärtus update_time, ületab varem salvestatud väärtuse). Eelmise lähenemisega seotud probleem on see, et andmete muutused võivad toimuda pakettidena. Seetõttu võivad selle veeru väärtused update_time olla mitteunikaalsed. Seega ei saa seda veergu kasutada andmete osalise (lehe järgi) edastamise jaoks. Lehe järgi andmete edastamiseks tuleb välja mõelda täiendavad mehhanismid, mis tõenäoliselt on väga madala efektiivsusega (näiteks kõikide andmebaasist kirje väärtuse väljavõttmine update_time üle määratud ja teatud arvu kirje esitlemine, alustades teatavast nihkest alates valikust).

Andmete edastamise efektiivsust saab parandada, kui täiustada eelnevat lähenemist. Selleks kasutame muutuste jälgimise veergu väärtustena täisarvulist tüüpi (pikendatud täisarv). Nimetame veeru row_ver. Selle veeru väärtus peab jätkuvalt olema seadistatud/uuendatud iga kord, kui kirje on loodud/muutunud. Kuid sel juhul antakse väljal mitte hetke kuupäev-aeg, vaid mingi loenduri väärtus, mis on suurenenud ühiku jagu. Seetõttu sisaldab veerg row_ver unikaalseid väärtusi ja saab kasutada mitte ainult "delta" andmete edastamiseks (andmed, mis on lisandunud/muutunud pärast eelmise andmevahetusseansi lõppu), vaid ka andmete lihtsaks ja tõhusaks lehtedeks jagamiseks.

Viimane pakutud meetod edastatavate andmete vähendamiseks kõrgetasemelise replikatsiooni raames tundub mulle kõige optimaalsem ja universaalsem. Vaatame seda lähemalt.

Andmete edastamine, kasutades ridade versioonide loendurit

Serveri / master osa teostamine

MS SQL Serveris on sarnase lähenemise elluviimiseks olemas spetsiaalne veeru tüüp — rowversion. Igas andmebaasis on loendur, mis suureneb ühe võrra iga kord, kui andmeid lisatakse või muudetakse tabelis, millel on veerg tüübiga rowversion. Selle loenduri väärtus määratakse automaatselt selle veeru väljale uues või muudetud rekordis. Andmebaasisüsteem Tarantoolil puudub sarnane sisseehitatud mehhanism. Siiski ei ole Tarantoolis seda keeruline käsitsi rakendada. Vaatame, kuidas seda teha.

Esiteks natuke terminoloogiat: Tarantoolis nimetatakse tabeleid spaisideks (space) ja rekordeid - tupleiteks (tuple). Tarantoolis saab luua järjestusi (sequence). Järjestused on mitte midagi muud kui nimetatud täisarvude järjestatud väärtuste generaatorid. See on täpselt see, mida meie eesmärkide jaoks vajame. Allpool loome sellise järjestuse.

Enne andmebaasiga Tarantoolis mõne toimingu tegemist tuleb täita järgmine käsk:

box.cfg{}

Kuna Tarantool hakkab salvestama andmebaasi hetkeseisud (snapshot) ja tehingu žurnaalid praeguses kataloogis.

Loome järjestuse row_version:

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

Valik if_not_exists võimaldab skripti loomist teha mitmeid kordi: kui objekt eksisteerib, ei püüa Tarantool seda uuesti luua. Seda valikut kasutatakse kõigis järgmistes DDL-käskudes.

Loome näidiseks spaisi.

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
})

Siin määrasime spaisi nime (goods), väljade nimed ja nende tüübid.

Tarantoolis luuakse automaatselt suurenevad väljad samuti järjestuste abil. Loome automaatselt suureneva põhivõtme välja põhjal 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 toetab mitmeid indeksitüüpe. Kõige sagedamini kasutatakse tüüpide TREE ja HASH indeksite ning vastavatesse struktuuridesse. TREE on kõige universaalsem indeksitüüp. See võimaldab andmeid välja tõmmata järjekorras. Kuid võrdsuste alusel valimise jaoks sobib rohkem HASH. Seega on primaarse võtme jaoks mõistlik kasutada HASH (nagu me tegime).

Selleks, et kasutada veergu row_ver muudetud andmete edastamiseks, tuleb sellele veerule seostada järjestuse väärtused row_ver. Kuid erinevalt primaarsetest võtmetest peab veeru väärtus row_ver kasvama ühe võrra mitte ainult uute salvestuste lisamisel, vaid ka olemasolevate muutmisel. Selle jaoks saab kasutada trikke. Tarantoolis on ruumide jaoks kaks tüüpi trikke: before_replace ja on_replace. Trikid käivitatakse iga kord, kui andmed ruumis muutuvad (iga muudetud kanti jaoks käivitatakse triki funktsioon). Erinevalt on_replace, before_replace-trikkidest võimaldavad need muuta kanti andmeid, mille jaoks trikk käivitatakse. Seega sobib meile viimane tüüp trikke.

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

Antud trikk asendab veeru väärtuse row_ver salvestatud kanti järgmise järjestuse väärtusega. row_version.

Selleks, et saaksime andmeid ruumist välja tõmmata goods veeru row_ver, loome indeksi:

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

Indeksi tüüp on puu (TREE), kuna peame andmeid välja tõmbama veeru väärtuste kasvava järjekorra järgi. row_ver.

Lisame ruumi mõned andmed:

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}

Kuna esimene väli on automaatselt suurenev loendaja, edastame selle asemel nil. Tarantool asendab selle automaatselt järgmise väärtusega. Samuti võib veergude väärtuste jaoks edastada nil — või ei pea väärtust üldse määrama, kuna see veerg asub ruumis viimases positsioonis. row_ver Kontrollime sisestamise tulemust:

Kontrollime sisestuse tulemust:

tarantool> box.space.goods:select()
---
- - [1, 'plii', 123, 1]
  - [2, 'plii', 321, 2]
  - [3, 'harja', 100, 3]
  - [4, 'akvarell', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'märkmik', 800, 6]
  - [7, 'kumm', 531, 7]
  - [8, 'joonlaud', 135, 8]
...

Nagu näeme, täitus esimene ja viimane väli automaatselt. Nüüd on lihtne kirjutada funktsioon lehekülje kaupa muudatuste tõmbamiseks spais. 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

Funktsioon võtab parameetrina väärtuse, row_ver, millest alates tuleb muudatuste allalaadimine, ja tagastab portsjoni muudetud andmetest.

Andmete valimine Tarantoolis toimub indeksite kaudu. Funktsioon get_goods kasutab indeksil iteratsioonimeetodit row_ver muudetud andmete saamiseks. Iteraatori tüüp — GT (Greater Than, suurem kui). See tähendab, et iterator liigub järjestikku indeksiväärtuste juures alates edastatud võtme (välja väärtuse) row_ver).

Iteraator tagastab tuple'it. Et saaksime pikkade andmete edastamist HTTP kaudu, on vajalik tuple'ite konverteerimine struktkuuri, mis sobib edasiseks serializedamiseks. Näites kasutatakse selle jaoks tavapärast funktsiooni tomap. Selle asemel, et kasutada tomap , võime kirjutada oma funktsiooni. Näiteks võime soovida väli nimi, mitte edastada väli code ja lisada väli kommentaar:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'mõni kommentaar'
    obj.row_ver = tuple.row_ver
    return obj
end

Kuvatud andmete lehekülje suurus (registreid ühe portsjoni kohta) määratakse muutuja kaudu page_size. Näites on väärtus page_size võrdub 5. Reaalses programmis on lehe suurusel tavaliselt suurem tähtsus. See sõltub ruumikottide keskmisest suurusest. Optimaalne lehe suurus võib sõltumatult katsetamise teel leida, mõõtes andmete edastamise aega. Mida suurem on lehe suurus, seda vähem on ringreise edastava ja vastuvõtva osapoole vahel. Nii saab vähendada muutuste üleslaadimise koguaega. Siiski, kui lehe suurus on liiga suur, kulutame serveri soariku töötlusele liiga kaua aega. Selle tulemusena võivad tekkida viivitused teistele päringutele, mis serverisse jõuavad. Parameeter page_size saab laadida konfiguratsioonifailist. Iga edastatava ruumi jaoks võib määrata oma väärtuse. Samas võib enamiku ruumide jaoks sobida vaikimisi väärtus (nt 100).

Teeme funktsiooni get_goods:

tarantool> get_goods(0)

---
- - rida_versioon: 1
    kood: 123
    nimi: pliiats
    id: 1
  - rida_versioon: 2
    kood: 321
    nimi: pliiats
    id: 2
  - rida_versioon: 3
    kood: 100
    nimi: pintsel
    id: 3
  - rida_versioon: 4
    kood: 456
    nimi: akvarell
    id: 4
  - rida_versioon: 5
    kood: 101
    nimi: album
    id: 5
...

Võtame välja välja väärtuse row_ver viimasest reast ja kutsume funktsiooni uuesti üles:

tarantool> get_goods(5)

---
- - rida_versioon: 6
    kood: 800
    nimi: vihik
    id: 6
  - rida_versioon: 7
    kood: 531
    nimi: kumm
    id: 7
  - rida_versioon: 8
    kood: 135
    nimi: joonlaud
    id: 8
...

Ja veel kord:

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

Nagu näeme, tagastab funktsioon sellisel kasutamisel kõik ruumi kirjed lehekaupa. goodsViimase lehe taga järgneb tühi valik.

Teeme muudatusi ruumis:

box.space.goods:update(4, {{'=', 6, 'märkmik'}})
box.space.goods:insert{nil, 'klamber', 234}
box.space.goods:insert{nil, 'kaust', 432}

Muutsime välja väärtust nimi ühe kirje jaoks ja lisasime kaks uut kirjet.

Korratakse viimast funktsiooni kutset:

tarantool> get_goods(8)
---



- - rida_versioon: 9
    kood: 800
    nimi: märkmik
    id: 6
  - rida_versioon: 10
    kood: 234
    nimi: klamber
    id: 9
  - rida_versioon: 11
    kood: 432
    nimi: kaust
    id: 10
...

Funktsioon tagastas muudetud ja lisatud kirjed. Nii et funktsioon get_goods lubab saada andmeid, mis on muutunud alates selle viimase kutsumise hetkest, mis ongi käsitletava replikeerimismeetodi alus.

Jätame tulemuste edastamise HTTP kaudu JSON formaadis selle artikli raames välja. Selle kohta saab lugeda siit: https://habr.com/ru/company/mailru/blog/272141/

Kliendi/slave osa rakendamine

Vaadakem, kuidas näeb välja vastuvõtva poole rakendamine. Loome vastuvõtva poole ruumi laaditud andmete hoidmiseks:

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
})

Ruumide struktuur meenutab allika ruumi struktuuri. Kuid kuna me ei plaani edastada saadud andmeid kuskile mujale, puudub row_ver saaja ruumis veerg. Veerus id salvestatakse allika identifikaatorid. Seega pole vastuvõtja pooltel vajalik, et see oleks automaatselt suurenev.

Lisaks sellele vajame ruumi väärtuste talletamiseks. 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
})

Iga laaditava ruumi (väli space_name) salvestame siin viimase laetud väärtuse row_ver (väli value). Peamise võtmena toimib veerg space_name.

Loome funktsiooni ruumi andmete laadimiseks goods HTTP kaudu. Selleks vajame teeki, mis реализует HTTP-klienti. Järgmine rida laadib teegi ja loob HTTP-klientide eksemplari:

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

Samuti vajame teeki JSON-i deserialiseerimiseks:

local json = require('json')

Seda on piisavalt, et luua andmete laadimise funktsioon:

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

Funktsioon täidab HTTP-päringu aadressile url, edastab selle row_ver parameetrina ja tagastab deserialiseeritud päringu tulemuse.

Saadud andmete salvestamise funktsioon näeb välja järgmiselt:

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

Andmete salvestamise tsükkel ruumi goods on paigutatud tehingusse (selleks kasutatakse funktsiooni box.atomic) diskiga tehingute arvu vähendamiseks.

Lõpuks võib kohaliku ruumi goods allikaga sünkroonimise funktsiooni rakendada nii:

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

Esmalt loeme eelnevalt salvestatud väärtuse row_ver ruumi goods. Kui seda ei ole (esimene vahetuse seanss), siis võtame selle aluseks. row_ver null. See further, we perform page-by-page loading of modified data from the source at the specified url. On each iteration, we save the obtained data into the corresponding local space and update the value row_ver (in the space row_ver and in the variable row_ver) — we take the value row_ver from the last line of the loaded data.

To protect against accidental looping (in case of a program error), the loop while can be replaced with for:

for _ = 1, max_req do ...

As a result of the function execution sync_goods space goods in the receiver will contain the latest versions of all records from the space goods in the source.

Clearly, this method cannot be used to transmit data deletion. If such a need arises, a deletion flag can be used. We add to the space goods a boolean field is_deleted and instead of physically deleting the record, we use logical deletion — we set the value of the field is_deleted väärtuseks true. Sometimes, instead of a boolean field is_deleted it is more convenient to use a field deleted, which stores the date-time of logical deletion of the record. After performing logical deletion, the marked record will be transferred from the source to the receiver (according to the logic discussed above).

The sequence row_ver can be used for transferring data from other spaces: there is no need to create a separate sequence for each space being transferred.

We have discussed an efficient method of high-level data replication in applications using the Tarantool DBMS.

Järeldused

1. The Tarantool DBMS is an attractive, promising product for creating high-load applications.
2. High-level data replication has several advantages over low-level replication.
3. The high-level replication method discussed in the article allows minimizing the amount of data transferred by only sending those records that have changed since the last exchange session.

Allikas: habr.com