Z výsledků je patrné, že replikace změn pomocí extenze Slony-I je velmi rychlá i v případě, že se najednou replikuje velký objem změn. Ovšem i díky testování lze konstatovat, že rychlost závisí na přenosové rychlosti. Dá se konstatovat, že u tohoto způsobu replikace je možné provádět synchronizace mezi servery méně často. Interval se odvíjí od počtu změn, které se v datech provádí. Pokud se jedná o data, která se mění zřídka a jejich aktuálnost není podmínkou, lze synchronizovat po delší době. Aby ale byla replikační rychlost únosná, je potřeba promyslet, kolik dotazujících serverů může v jeden moment být. Byla zjištěna lineární závislost replikačního času na počtu změněných lomových bodů. Aby replikační čas nepřekročil 1 s, lze relativně provést řádově desetitisíce změn v lomových bodech prostorových dat. Konkrétní hodnotu nelze určit, hlavním faktorem je, kolik lomových bodů je obsaženo v každém záznamu. Rychleji se replikuje velká změna v jednom záznamu než několik změn ve velkém množství záznamů. Není reálné, aby se najednou provedly změny v tisíce lomových bodech, většina uživatelů provede pár změn a následně změny uloží. Dále je nutné do replikační doby zahrnout počet uživatelů. Je logické, že při větším množství dotazování se hodnota replikovaných změn razantně sníží.
Co se využití procesoru týče, je vhodné, aby master server představoval zařízení, které bude sloužit pouze jako databázový server. Již z předchozích kapitol bylo možné z grafů odečíst, že využití procesoru může při náročných operacích vystoupat až na třetinu celého možného zatížení. Pokud by tedy na pozadí běžely náročné procesy, mohly by způsobit přetížení procesoru a celkové zpomalení přenosu.
Vzhledem k výsledkům při prohození rolí (PC jako slave server) došlo k zjištění, že rychlost přenosu je značně rychlejší. Důvodem je výkonnější slave server, který zvládá mnohonásobně rychleji zapisovat změny ve vrstvě. Dá se říci, že při replikaci pomocí Slony-I nemusí být master server výkonným zařízením. Záleží pouze na slave serveru, jak rychle je schopen zapisovat změny k sobě na disk.
Při omezení rychlosti se celková doba replikace prodloužila. Lze vyvodit další doporučení, kterým je připojení. Při vyšších přenosových rychlostech se změna bude replikovat rychleji, při nižších rychlostech tomu bude naopak.
Při použití Slony-I hraje důležitou roli typ připojení. Záleží na šířce a propustnosti pásma zvoleného připojení. Server běžně mívá 1 Gbps a router bývá alespoň 10 Gbps, aby se do sítě dalo připojit více serverů. Takovéto využití replikace slouží spíše pro vytvoření kopie hlavního serveru. Je jasné, že při přímém připojení bude přenos replikovaných změn nejrychlejší. Ve většině případech se replikace používá pro replikování změn na konkrétní vzdálenost, je tedy potřeba započítat vliv routeru, vždy je přenosová rychlost snížena.
Podle použití je v neposlední řadě výhodou, ale zároveň i nevýhodou, že pomocí Slony-I se replikují pouze vybrané tabulky. V případě, že se klient ve formě webového serveru dotazuje k slave serveru, má možnost zvolit, jaké tabulky, resp. data chce k sobě zreplikovat.
U MySQL velký objem změn najednou, především v geometrii prostorových dat, je příliš náročný. Je náročný z pohledu celkového trvání operace, která může trvat i desítky min. Doporučuje se replikovat častěji po malých částech. Zaprvé se častější replikací zajistí aktuálnost dat, ale také se razantně sníží celkový čas potřebný pro replikaci změn.
Během měření bylo zjištěno, že aby replikace běžela 1 s, musely by se provést změny maximálně u desítky záznamů. Očekává se, že tolik změn se najednou neprovede, avšak je nutné vědět, kolik změn lze maximálně provést, aby doba replikace byla stále přijatelná. Opět se musí počítat s počtem dotazujících serverů, díky kterým se počet změn provedených najednou razantně sníží.
U MySQL replikace průměrné zatížení procesoru bez větších výkyvů nepřekročilo hodnotu 10 % celkového zatížení. Je tedy patrný rozdíl oproti Slony-I. V tomto případě lze říct, že teoreticky na pozadí mohou běže další procesy, které jistým způsobem zvyšují zátěž procesoru. Master server tedy nemusí být zařízením, na kterém běží pouze replikace. Lze teoreticky s ním dále pracovat, aniž by byl ovlivněn čas replikace.
Na základě prohození rolí master a slave serveru je doporučeno, aby master server byl tvořen výkonným zařízením. Od jeho výkonu se odvíjí celkový čas potřebný pro replikování změn. Čím výkonnější master server je, tím rychleji je schopen změny ukládat k sobě a zároveň rozesílat na další servery. V testování při prohozených rolích čas narostl o více jak 40 % oproti výchozímu nastavení rolí.
K replikaci i velkého objemu dat najednou není potřeba silného připojení k internetu. I při omezení přenosové rychlosti replikování změny trvalo prakticky stejnou dobu. Při replikaci atributových změn, které jsou časově méně náročné, se čas odvíjí od připojení k internetu. Během testování přenosová rychlost nepřesáhla 10 Mbps. Lze tedy říci, že stačí MySQL omezit šířku pásma na tuto hodnotu a zbytek pásma přenechat dalším procesům.
MySQL je streaming replikace, to znamená, že slave server je věrnou kopií master serveru. Replikace probíhá 1:1, takže celá databáze se všemi tabulkami se vždy kopíruje na slave server. Záleží opět jako u Slony I na použití. Replikace může v tomto případě sloužit jako vytvoření záložního serveru v případě pádu master serveru.
© Lenka TRNOVÁ | 2018 | Katedra geoinformatiky | Olomouc
Design by: © TEMPLATED. All rights reserved.