Kõrgetasemeline replikatsioon andmebaasis Tarantool

Tere, ma loon rakendusi andmebaaside jaoks. Tarantool — see on Mail.ru Groupi loodud platvorm, mis ühendab endas kõrgotstarbelise andmebaasi ja rakenduste serveri Lua keeles. Tarantooli põhinevate lahenduste kõrge töökiirus saavutatakse osaliselt tänu in-memory andmebaasi režiimi toele ja rakenduse äriloogika täitmise võimalusele andmete ühes aadressiruumis. Samuti tagatakse andmete püsimälu ACID-tehingute abil (ketta peal hoitakse WAL-žurnaal). Tarantoo sisaldab sisseehitatud replikatsiooni ja šardimist. Alates versioonist 2.1 toetatakse SQL-keeles päringute täitmist. Tarantool on avatud lähtekoodiga ja levitatakse Simplified BSD litsentsi alusel. Samuti on olemas kaubanduslik Enterprise-variand.

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

Kõik eelnevalt mainitu muudab Tarantooli atraktiivseks platvormiks kõrge koormusega rakenduste loomiseks, mis töötavad andmebaasidega. Sellistes rakendustes tekib sageli vajadus andmete replikatsiooni järele.

Nagu eespool mainitud, sisaldab Tarantool sisseehitatud andmete replikatsiooni. Selle toimimise põhimõte seisneb kõigi meisterdokumentide (WAL) sisaldavate tehingute järjestikuses täitmises replikaates. Tüüpiliselt kasutatakse seda replikatsiooni (edaspidi nimetame seda madalaks tasemeks) rakenduse tõrkeasetuse tagamiseks ja/või koormuse jaotamiseks klastrinode vahel.

Joon. 1. Replikatsioon klastris

Alternatiivse stsenaariumi näiteks võib tuua andmete edastamise, mis on loodud ühes andmebaasis, teise andmebaasi töötlemiseks/monitoorimiseks. Viimases juhul võib mugav lahendus olla kõrge taseme replikatsioon — andmete replikatsioon rakenduse äri- ja loogika tasemel. See tähendab, et me ei kasuta valmislahendust, mis on sisse ehitatud andmebaasi, vaid teeme oma jõududega replikatsiooni oma rakenduses. Sellel lähenemisel on nii eeliseid kui ka puudusi. Tuletame meelde plusse.

1. Andmete edastamise vähendamine:

• võimalik on edastada mitte kõiki andmeid, vaid ainult osa neist (näiteks võib edastada ainult teatud tabeleid, mõned nende veerud või kirjed, mis vastavad teatud kriteeriumitele);
• erinevalt madala taseme replikatsioonist, mis toimub pidevalt asünkroonses (rakendatud praeguses versioonis Tarantool — 1.10) või sünkroonses (realiseeritakse Tarantooli järgnevatel versioonidel) režiimis, kõrgetasemelist replikatsiooni saab teha sessioonidena (st rakendus täidab esmalt andmete sünkroniseerimist — andmeedastus sessioon, seejärel järgneb replikatsioonist paus, pärast mida toimub järgmine andmeedastus sessioon jne.);
• kui kirje on mitu korda muutunud, saab edastada ainult viimase versiooni (erinevalt madalast tasemest replikatsioonist, mille käigus replikatsioonides järgis järk-järgult kõiki muudatusi, mis tehti meistris).

2. HTTP-poolsete vahetuste realiseerimise keerukuse puudumine, mis võimaldab sünkroniseerida kaugandmebaase.

Joon. 2. Replikatsioon HTTP kaudu

3. Andmebaasi struktuurid, mille vahel andmeid edastatakse, ei pea olema identsed (üldiselt on isegi võimalik kasutada erinevaid andmebaase, programmeerimiskeeli, platvorme jne.).

Joon. 3. Replikatsioon heterogeensetes süsteemides

Puuduseks on see, et keskmiselt on programmeerimine keerulisem/kallim kui konfigureerimine, ja sisseehitatud funktsionaalsuse seadistamise asemel tuleb realiseerida enda lahendused.

Kui teie olukorras on toodud eelised kriitilise tähtsusega (või vajalikud tingimused), siis on mõttekas kasutada kõrgetasemelist replikatsiooni. Vaatame mõningaid viise andmete kõrgetasemelise replikatsiooni elluviimiseks andmebaasis Tarantool.

Trahvi vähendamine

Nii et üheks kõrgetasemelise replikatsiooni eelisteks on andmeedastuse vähendamine. Selle eelise täielikuks väljendamiseks on oluline minimeerida andmete hulka, mis edastatakse iga andmeedastus sessiooni puhul. Loomulikult ei tohi unustada, et andmeedastus sessiooni lõpus peab saaja olema sünkroonitud allika andmetega (kui mitte vähem neid andmeid, mis osalevad replikatsioonis).

Kuidas siis minimeerida andmete hulka, mis edastatakse kõrgetasemelise replikatsiooni käigus? Üheks viisiks võib olla andmete valimine kuupäeva ja kellaaja järgi. Selleks võib kasutada tabelis juba olemasolevat kuupäeva ja kellaaja väljakut (kui see on olemas). Näiteks võib dokumendil 'tellimus' olla väli 'tellimuse täitmise nõutav aeg' — delivery_time. Selle lahenduse probleem seisneb selles, et sellel väljal ei pea väärtused olema tellimuste loomise järjekorras. Seetõttu ei saa me selle väli maksimaalset väärtust meeles pidada. delivery_time, mis edastati eelneva vahetusseansi ajal, ja järgmise vahetuse jooksul koguda kõik kirjed, millel on väljaväärtus suurem. delivery_time. Vahetuste vahel võisid lisanduda kirjed, mille väli on väiksem. delivery_time. Samuti võis tellimus muutuda, kuid see ei mõjutanud välja. delivery_time. Mõlemal juhul ei edastata muudatused allikast vastuvõtjale. Nende probleemide lahendamiseks peame andmeid edastama 'kattega'. See tähendab, et igas vahetuses edastame kõik andmed, mille väljaväärtus delivery_time, ületab mingi ajakohase hetke (näiteks N tundi alates praegusest hetkest). Selgelt on aga, et suurte süsteemide puhul on selline lähenemine liiga ülemäärane ja võib tühistada meie liikluse kokkuhoiu, mille poole me püüame. Lisaks võib edastatavas tabelis puududa kuupäeva-aega seonduv väli.

Teine variant, mis on keerukam teostusena, seisneb andmete vastuvõtmise kinnitamises. Sellisel juhul edastatakse igas vahetuses kõik andmed, mille vastuvõtmist vastuvõtja ei ole kinnitanud. Selle teostamiseks tuleb allika tabelisse lisada boolse veeru (nt is_transferred). Kui vastuvõtja kinnitab kirje vastuvõtu, võtab vastav väli väärtuse true, pärast mida see kirje enam vahetustes ei osale. Selle teostusvariandi miinused on järgmised. Esiteks peab iga edastatud kirje jaoks genereerima ja saatma kinnituse. Üldiselt võib see sarnaneda edastatavate andmete kahekordistumisega ja toob kaasa kahekordse ringreiside arvu. Teiseks puudub võimalus saata sama kirje mitmele vastuvõtjale (esimene saanud vastuvõtja kinnitab vastuvõttu enda ja kõikide teiste nimel).

Puuduvate miinuste kõrvaldamine seisneb selles, et edastatavas tabelis lisatakse veerg, et jälgida oma ridade muutumise. Sellel veerul võib olla kuupäeva-aeg ja see peab määrama / uuendama rakenduse poolt praegusele ajale iga kord, kui kirjeid lisatakse / muudetakse (aatomaarne koos lisamise / muutmisega). Näiteks nimetame veeru update_time. Säilitades selle veeru maksimaalse väärtuse edastatud kirgede korral, saame järgmist vahetust alustada sellest väärtusest (koguda kirjed, milleväljaväärtus update_time, ületab eelnevalt salvestatud väärtuse). Probleem, mis on seotud viimase lähenemisega, seisneb selles, et andmete muutused võivad toimuda partiide vahel. Seetõttu võivad selle veeru väärtused update_time olla mitteunikaalsed. Seega ei saa seda veergu kasutada andmete osalise (lehe kaupa) väljundi jaoks. Lehe kaupa andmete edastamiseks tuleb leiutada täiendavad mehhanismid, mis tõenäoliselt on väga madala efektiivsusega (näiteks andmebaasist kõikide kirgede saamine, milleväärtus on update_time ülalteatud ning valehinnanguga andmete edastamine, alustades teatud nihkest valiku algusest).

Saame andmete edastamise efektiivsust parandada, täiendades eelmist lähenemist. Selleks kasutame muutuste jälgimise veeru väärtustena täisarvulist tüüpi (pikad täisarvud). Nimetame veeru row_ver. Selle veeru väärtus peab endiselt olema määratud / uuendatud iga kord, kui kirjet luuakse / muudetakse. Kuid antud juhul määratakse väljal mitte praegune kuupäev-aeg, vaid mingi loenduri väärtus, suurendatud ühe võrra. Selle tulemusena sisaldab veerg row_ver unikaalseid väärtusi ja seda võib kasutada mitte ainult 'delta' andmete edastamiseks (andmete, mis on lisatud / muutunud pärast eelmise vahetusseansi lõppemist), vaid ka lihtsaks ja efektiivseks lehtede kaupa jagamiseks.

Viimane ettepanek andmeedastamise vähendamiseks kõrgetasemelise replikatsiooni raames tundub olevat kõige optimaalsem ja universaalsem. Vaatame seda lähemalt.

Andmete edastamine ridade versioonide loenduri kaudu.

Serveri / peamise osa teostamine.

MS SQL Serveris on sellise lähenemise rakendamiseks eriline veeru tüüp - rowversion. Iga andmebaas omab loenduri, mis suureneb ühe võrra iga kord, kui kirjed lisatakse / muudetakse tabelis, millel on sellise veeru tüüp. rowversion. Selle arvesti väärtus määratakse automaatselt selle veeru välja, mis on lisatud/muudetud kirjesse. Tarantooli andmebaas ei oma sarnast sisseehitatud mehhanismi. Siiski on seda Tarantoolis lihtne käsitsi rakendada. Vaatame, kuidas seda teha.

Alustame veidi terminoloogiaga: tabelid Tarantoolis nimetatakse spaasideks (space) ja kirjed korduudeks (tuple). Tarantoolis on võimalik luua järjestusi (sequence). Järjestused on nimelised generaatorid järjestatud täisarvude väärtustega. See on just see, mida meie eesmärkide jaoks vajame. Allpool loome sellise järjestuse.

Enne kui täidate mõnda tegevust Tarantooli andmebaasis, peate täitma järgmise käsu:

box.cfg{}

Tulemuseks hakkab Tarantool salvestama praegusesse katalooge andmebaasi (snapshot) ja tehingute päeviku.

Loome järjestuse row_version:

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

Valik if_not_exists lubab skripti loomist mitmeid kordi: kui objekt juba eksisteerib, ei ürita Tarantool seda uuesti luua. Seda võimalust kasutatakse kõigis järgnevatel DDL-käskudel.

Loome näidiseks spaa.

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 spaa nime (goods), väljade nimed ja nende tüübid.

Tarantoolis luuakse automaatselt suurenevaid välju ka järjestuste abil. Loome automaatselt suureneva põhivõtme välja 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üüpide. Kõige sagedamini kasutatakse TREE- ja HASH-tüüpi indekseid, mis põhinevad vastavatel struktuuridel. TREE on kõige universaalsem indeksitüüp. See võimaldab andmeid hankida järjestatud viisil. Kuid võrdsuse valimiseks sobib rohkem HASH. Seega on põhivõtme jaoks mõistlik kasutada HASH (nagu me ka tegin).

Kasutamaks veergu row_ver muudetud andmete edastamiseks, tuleb sellele veerule siduda järjestuse väärtused row_ver. Kuid erinevalt põhivõtme väärtusest, peab veeru väärtus row_ver kasvama üksuse võrra mitte ainult uute rekordite lisamisel, vaid ka olemasolevate muutmisel. Selleks saab kasutada triggereid. Tarantoolis on kaks tüüpi triggereid spaa jaoks: before_replace ja on_replace. Triggereid aktiveeritakse iga andme muutuse korral spaas (iga korduute puhul, mis tulevad muutustest, käivitatakse triggeri funktsioon). Erinevalt on_replace, before_replace-triggereid võimaldavad muutuda korduute andmeid, mille jaoks triggeri täitmine toimub. Seega sobib meile viimane triggereid tüüp.

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 trigger asendab välja väärtuse row_ver salvestatud korduudest järgmise järjestuse väärtusega. row_version.

Et andmeid saaks spaas välja võtta 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 andmed tuleks hankida väärtuste kasvava järjestuse järgi veerus. row_ver.

Lisame spaa 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 arvesti, edastame selle asemel nil. Tarantool asendab automaatselt järgmise väärtusega. Samuti saab välja väärtustena veeru row_ver edastada nil — või mitte määrata väärtust üldse, kuna see veerg on spaas viimasel positsioonil.

Kontrollime lisamise tulemust:

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]
...

Nagu näeme, täitusid esimene ja viimane väli automaatselt. Nüüd on lihtne kirjutada funktsioon lehe kaupa muudatuste välja tõmbamiseks spaas 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, alates millest tuleb muudatuste välja tõmbamine teha, ja tagastab osa muudetud andmetest.

Tarantoolis andmete valimine toimub indeksite kaudu. Funktsioon get_goods kasutab indeksil põhinevat iteratorkäiku row_ver muudetud andmete saamiseks. Iteraatori tüüp on GT (Greater Than). See tähendab, et iteraator läbib järjestikku indeksi väärtuseid alates antud võtmest (välja väärtusest row_ver).

Iteraator tagastab tupse. Et andmeid hiljem HTTP kaudu edastada, tuleb tupse konverteerida struktuuri, mis sobib järgnevale serialiseerimisele. Näites kasutatakse selleks standardset funktsiooni tomap. Selle asemel, et kasutada tomap võib kirjutada oma funktsiooni. Näiteks võime soovida välja nimetada name, mitte edastada välja code ja lisada välja 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

Lehe suurus, milles andmeid võetakse (kirjete arv ühes osas), määratakse muutuja kaudu page_size. Näites on väärtus page_size 5. Reaalses programmis on lehe suurus tavaliselt suurem. See sõltub tupse keskmisest suurusest. Optimaalset lehe suurust saab katsetades leida, mõõtes andmete edastamise aega. Mida suurem on lehe suurus, seda vähem on käe tagasi mõne eelneva ja järgnevate poolte vahel. See võib vähendada üldist muutuste edastamise aega. Kuid liiga suure lehe suurusega saame liiga kaua serverit hõivata tagastatava andmete serialiseerimisega. Selle tulemusena võivad tekkida viivitused teistele serverisse saabuvate päringute töötlemisel. Parameetrit page_size võib laadida konfiguratsioonifailist. Iga edastatava spetsiifika jaoks võib määrata oma väärtuse. Enamikule spetsiifikale sobib siiski vaikimisi väärtus (näiteks 100).

Käivitame funktsiooni 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
...

Võtame välja väärtuse row_ver viimases reaas ja kutsub uuesti funktsiooni:

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
...

Ja veel kord:

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

Nagu näeme, tagastab funktsioon sellisel viisil lehtede kaupa kõik spetsiifika kirjed. goodsViimase lehe järel on tühine valik.

Teeme spetsiifikasse muudatusi:

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

Olemegi muutnud välja väärtust name ühe kirje jaoks ning lisanud kaks uut kirjet.

Kutsume uuesti viimast funktsiooni:

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
...

Funktsioon tagastas muudetud ja lisatud kirjed. Seega võimaldab funktsioon get_goods saada andmeid, mis on muutunud alates selle viimase kõne tegemisest, mis ongi käsitletava replikatsiooni meetodi aluseks.

Jätame tulemuste edastamise HTTP kaudu JSONina selle artikli raames arutlemata. Selle kohta saate lugeda siit: https://habr.com/ru/company/mailru/blog/272141/

Kliendi/slave osa rakendamine

Vaatleme, milline näeb välja vastuvõtva poole rakendamine. Loome vastuvõtval poolel spetsiifika, kuhu salvestada laaditud andmed:

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

Spetsiifika struktuur sarnaneb allika spetsiifika struktuuriga. Kuid kuna me ei kavatse saadud andmeid kuhugi mujale edastada, puudub vastuvõtva spetsiifika veerg. row_ver Välja id salvestatakse allika identifikaatorid. Seega pole vastuvõtva poole jaoks vajalik, et see oleks automaatselt suurenev.

Lisaks on vajalik spetsiifika, et salvestada väärtused 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 edastatava spetsiifika kohta (välja space_name) salvestame siia viimase laadimise väärtuse row_ver (välja value). Peamise võtmena kasutatakse veergu space_name.

Loome funktsiooni, et laadida andmeid spetsiifikalt goods HTTP kaudu. Selleks vajame HTTP-kliendi rakendavalt teeki. Järgmine rida laadib teegi ja loob HTTP-kliendi eksemplari:

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

Samuti vajame teeki JSONi deserialiseerimiseks:

local json = require('json')

Sellega piisab funktsiooni loomiseks, et laadida andmeid:

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 sellele row_ver parameetrina ja tagastab deserialiseeritud päringu tulemuse.

Saadavate andmete salvestamise funktsioon näeb välja järgmine:

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 on paigutatud tehingusse (selleks kasutatakse funktsiooni goods box.atomic ) operatsioonide arvu vähendamiseks kettal.Lõpuks on kohaliku ruumi sünkroniseerimise funktsioon võimalik ellu viia järgmiselt:

Alustame varem salvestatud väärtuse lugemisest goods ruumile

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

. Kui seda pole (vahetussessioon on esimene), siis võtame väärtuseks row_ver null. Järgmistel kordadel teeme lehe kaupa muudatustega andmete laadimise allikast antud url-i kaudu. Igal iteratsioonil salvestame saadud andmed vastavasse kohalikku ruumi ja uuendame väärtust goods(ruumis row_ver ja muutuja row_ver ) — võtame väärtuse row_ver viimases laaditud andmete real. row_verJuhuks, et vältida juhuslikku lõksu sattumist (programmi vea korral), võib tsükli row_ver viimastest laaditud andmetest.

asendada samal ajal Funktsiooni täitmise tulemuseks on for:

sync_goods

ruum vastuvõtjas sisaldama kõiki salvestatud ruumi viimaseid versioone allikas. goods On ilmne, et sel viisil ei saa edastada andmete kustutamist. Kui selline vajadus on, saab kasutada kustutamise märgistamise meetodit. Lisame ruumi goods boolenväli

Ilmselgelt ei saa sellist meetodit kasutada andmete kustutamise edasiviimiseks. Kui selline vajadus tekib, saab kasutada kustutamismärgistust. Lisame ruumi. goods ja füüsilise kustutamise asemel kasutame loogilist kustutamist — seadistame välja selle väljade väärtuse. is_deleted , kuhu salvestatakse loogilise kustutamise kuupäeva ja aega. Pärast loogilise kustutamise teostamist saadetakse kustutamiseks märgitud rida allikast vastuvõtjasse (vastavalt varem käsitletud loogikale). is_deleted väärtuse trueJada is_deleted saab kasutada teiste ruumide andmete edastamiseks: ei ole vaja luua eraldi järjestust iga edastatava ruumi jaoks. kustutatudOleme käsitlenud tõhusat viisi kõrgetasemeliseks andmete replikeerimiseks rakendustes, mis kasutavad andmebaasi Tarantool.

Andmebaas Tarantool on atraktiivne, perspektiivikas toode, mis sobib kõrge koormusega rakenduste loomiseks. row_ver Kõrgetasemeline andmete replikeerimine on mitmeid eeliseid madalama taseme replikeerimise ees.

Artiklis käsitletud kõrgetasemeline replikeerimise meetod võimaldab minimeerida edastatavate andmete arvu, edastades ainult need kirjed, mis on muutunud alates viimati toimunud vahetusest.

Järeldused

1. Tere, ma arendan rakendusi andmebaasi Tarantool jaoks — see on Mail.ru Groupis välja töötatud platvorm, mis ühendab endas kõrge jõudlusega andmebaasi ja rakenduse serveri keeles Lua. Tarantooli põhjal loodud lahenduste kõrge töökiirus saavutatakse osaliselt andmebaasi mälu režiimi toetamise ja rakenduse äriloogika täitmise võimaluse tõttu ühes ja samas aadressiruumis andmetega. Samuti
2. 🥇Kõrgetasemeline replikeerimine andmebaasis Tarantool | ProHoster
3. Artiklis käsitletud meetod kõrgetasemeliseks replikatsiooniks võimaldab minimeerida edastatud andmete hulka, edastades ainult need kirjed, mis on muutunud pärast viimast vahetusseanssi.

Allikas: habr.com