Dar visai neseniai, kai pirkote į duomenų bazę, turėjote pasirinkti: mastelio mastas ar nuoseklumas? SQL duomenų bazės, tokios kaip „MySQL“, garantuoja tvirtą nuoseklumą, tačiau horizontaliai nesikeičia. (Neautomatinis dalijimasis dėl mastelio nėra niekieno idėja.) „NoSQL“ duomenų bazės, pvz., „MongoDB“, gražiai masto, tačiau siūlo tik galiausiai nuoseklumą. („Palaukite pakankamai ilgai ir galėsite perskaityti teisingą atsakymą“ - tai nėra būdas atlikti finansines operacijas.)
„Google Cloud Spanner“ - visiškai valdoma reliacinių duomenų bazių paslauga, veikianti „Google Compute Engine“ (GCE), išleistoje 2017 m. Vasario mėn., Turi „NoSQL“ duomenų bazių mastelį, išlaikydama SQL suderinamumą, reliacines schemas, ACID operacijas ir tvirtą išorinį nuoseklumą. Veržliaraktis yra suskaidyta, visame pasaulyje paskirstyta ir pakartota reliacinė duomenų bazė, kuri naudoja „Paxos“ algoritmą, kad pasiektų konsensusą tarp savo mazgų.
Viena iš „Spanner“ alternatyvų ir šios apžvalgos tema yra „CockroachDB“, atviro kodo, horizontaliai keičiama paskirstyta SQL duomenų bazė, kurią sukūrė buvę „Google“ darbuotojai, kurie buvo susipažinę su „Spanner“. „CockroachDB“ skolinasi iš „Google“ veržliarakčio, kad sukurtų duomenų saugojimo sistemą, ir jis naudoja „Raft“ algoritmą, kad pasiektų bendrą sutarimą tarp savo mazgų.
Kaip ir „Cloud Spanner“, „CockroachDB“ yra paskirstyta SQL duomenų bazė, sukurta ant operacinės ir nuoseklios raktų vertės saugyklos, CockroachDB atveju „RocksDB“. Pagrindiniai „CockroachDB“ projektavimo tikslai yra parama ACID operacijoms, horizontalusis mastelis ir (labiausiai) išgyvenamumas, taigi ir pavadinimas.
„CockroachDB“ yra skirtas išgyventi disko, įrenginio, stovo ir net duomenų centro gedimams, su minimaliu delsos sutrikimu ir be rankinio įsikišimo. Žinoma, norint tai pasiekti, reikia paleisti a klasteris daugelio simetriškų „CockroachDB“ mazgų atvejų, naudojant kelis diskus, mašinas, lentynas ir duomenų centrus.
Skirtingai nuo „Cloud Spanner“, kuris naudoja „TrueTime“ API, kurią galima sinchronizuoti „Google“ duomenų centruose, „CockroachDB“ negali tikėtis, kad atominiai laikrodžiai ir GPS palydoviniai laikrodžiai tiksliai sinchronizuos laiką mazguose ir duomenų centruose. Tai turi daugybę pasekmių. Pirmiausia „Google TrueTime“ suteikia viršutinę laikrodžio poslinkio ribą tarp mazgų septynių milisekundžių grupėje. Tai pakankamai maža, kad „Spanner“ mazgas laukia septynių milisekundžių po rašymo prieš pranešdamas, kad įvyko sandoris, kad būtų užtikrintas išorinis nuoseklumas.
Be „TrueTime“ ar panašios priemonės „CockroachDB“ turi grįžti į NTP, kuris suteikia viršutines ribas laikrodžio sinchronizavimui tarp 100 milisekundžių ir 250 milisekundžių. Atsižvelgiant į tą didesnį laiko langą, CockroachDB nelaukia po rašymo. Vietoj to kartais laukia, kol nuskaito, iš esmės iš naujo paleisdamas operaciją, jei ji nuskaito vertę, kurios laiko žyma yra didesnė už operacijos pradžią, ir vėl garantuoja nuoseklumą.
Kai visi „CockroachDB“ grupės mazgai turi mažas viršutines laikrodžio poslinkio ribas, kurias galite gauti iš GPS ar atominių laikrodžių, o tai tiesiog tampa prieinama didžiuosiuose viešuosiuose debesyse, gali būti prasminga juos paleisti su - linijinis vėliava. Tai verčia juos laukti maksimalaus laikrodžio poslinkio prieš grąžinant sėkmingą įsipareigojimą, kaip ir „Spanner“.
Kaip veikia tarakonasDB
Kiekvienas tarakonoDB mazgas susideda iš penkių sluoksnių:
- SQL, kuris kliento SQL užklausas paverčia raktų vertės operacijomis
- Operacija, leidžianti atomiškai keisti kelis pagrindinės vertės įrašus
- Paskirstymas, kuris pateikia pakartotus pagrindinės vertės diapazonus kaip vieną objektą
- Replikacija, kuri nuosekliai ir sinchroniškai atkartoja raktinių verčių diapazonus daugelyje mazgų ir leidžia nuosekliai skaityti nuomos būdu
- „Storage“, kuri rašo ir skaito pagrindinės vertės duomenis diske
SQL sluoksnis analizuoja užklausas pagal „Yacc“ failą ir paverčia jas abstrakčiu sintaksės medžiu. Iš abstrakčios sintaksės medžio CockroachDB sukuria plano mazgų medį, kuriame yra rakto vertės kodas. Tada plano mazgai vykdomi bendraujant su operacijų sluoksniu.
Operacijų sluoksnis įgyvendina ACID operacijų semantiką su dviejų fazių įsipareigojimais visame klasteryje, įskaitant tarpvalstybines ir kryžmines lentelių operacijas, pavienius teiginius traktuodamas kaip operacijas (dar vadinamas automatinio įsipareigojimo režimu). Dviejų fazių įsipareigojimas įvykdomas paskelbiant operacijų įrašus ir rašymo ketinimus, vykdant skaitymo operacijas ir visus susidariusius rašymo ketinimus traktuojant kaip sandorių konfliktus.
Paskirstymo sluoksnis gauna užklausas iš operacijų sluoksnio tame pačiame mazge. Tada jis nustato, kurie mazgai turėtų gauti užklausą, ir išsiunčia užklausą tinkamo mazgo replikacijos sluoksniui.
Replikacijos sluoksnis kopijuoja duomenis tarp mazgų ir užtikrina šių kopijų nuoseklumą įgyvendindamas „Raft Consensus“ algoritmą. Naudodami replikacijos zonas, galite valdyti replikacijos koeficientą sankaupos, duomenų bazės ir lentelės lygiu. Konsensuso algoritmas naudojamas tik rašant ir reikalauja, kad replikų kvorumas sutiktų dėl bet kokio diapazono pakeitimo prieš įvykdant šiuos pakeitimus.
Saugojimo sluoksnyje duomenys saugomi kaip raktų ir vertės poros diske, naudojant „RocksDB“. „CockroachDB“ labai priklauso nuo kelių versijų lygiagretumo valdymo (MVCC), kad apdorotų vienu metu vykstančias užklausas ir užtikrintų nuoseklumą. Didžioji šio darbo dalis atliekama naudojant hibridinio loginio laikrodžio (HLC) laiko žymes.
Kaip ir „Spanner“, „CockroachDB“ palaiko kelionių laiku užklausas (įgalintas MVCC). Tai gali būti paskutinis duomenų bazės šiukšlių surinkimas, atliekamas pagal numatytuosius nustatymus kasdien.
TarakonųDB diegimas ir naudojimas
„CockroachDB“ veikia „Mac“, „Linux“ ir „Windows“ operacinėse sistemose, bent jau kuriant ir išbandant. Produkcijos tarakonų duomenų bazės paprastai veikia naudojant „Linux“ VM ar orkestruotus konteinerius, kurie dažnai laikomi viešuose debesyse keliuose duomenų centruose. „CockroachDB“ „Windows“ dvejetainis kompiuteris vis dar yra beta fazėje ir nerekomenduojamas gamybai, o „Apple“ nebegamina serverio aparatinės įrangos.
Tarakonų laboratorijos Kaip matote aukščiau pateiktoje ekrano kopijoje, yra keturios galimybės įdiegti „CockroachDB“ „Mac“. Aš pasirinkau „Homebrew“ kaip greičiausiai lengviausią iš keturių.
Beje, „Cockroach Labs“ svetainėje paskelbia įspėjimą, kuriame teigiama, kad „Docker“ programoje paleisti valstybinę programą, pvz., „CockroachDB“, yra keblu, nerekomenduojama diegti gamyboje, o vietoj klasterio naudoti orkestravimo įrankį, pvz., „Kubernetes“ ar „Docker Swarm“. Kitame skyriuje aptarsiu konteinerių orkestravimo galimybes.
Diegimas „Mac“ yra toks pat lengvas kaip ir užvirinti įdėti tarakoną kaip parodyta aukščiau. Mano atveju automatinis „Homebrew“ atnaujinimas užtruko daug ilgiau (užteko laiko arbatai išvirti) nei tikrasis „CockroachDB“ diegimas, kuris užtruko tik kelias sekundes.
Įdiegus „CockroachDB“, gana lengva sukurti vietinį klasterį, nors yra papildomas žingsnis kuriant saugos sertifikatus naudojant tarakonų sertas komandą, jei norite, kad klasteris būtų saugus. Kai jau veikia klasteris (naudodami tarakonų pradžia komandą vieną kartą kiekvienam mazgui, nustatydami vėlesnius mazgus prisijungti prie pirmojo mazgo klasterio), galite prisijungti prie bet kurio mazgo žiniatinklio administravimo puslapio naudodami naršyklę ir naudoti įdėtąjį tarakonas kv klientui siųsti SQL užklausas į bet kurį mazgą. Dauguma naršyklių skundžiasi svetainėmis, kuriose yra „CockroachDB“ sugeneruoti sertifikatai, tačiau turėtumėte sugebėti spustelėti tą baisų įspėjimą ir toliau eiti į svetainę.
Rekomenduojami „CockroachDB“ gamybos parametrai skiriasi nuo numatytųjų, kurie buvo nustatyti kūrimo ir bandymo egzemplioriams. Jei norite, galite sukurti vieno mazgo klasterį. Jei norite gaminti, turėtumėte turėti bent tris mazgus, paleisti kiekvieną mazgą atskiroje mašinoje, VM ar talpykloje ir suteikti kiekvienam egzemplioriui papildomą talpyklą ir SQL atmintį. Numatytieji nustatymai yra po 128 MB talpykloje ir SQL atmintyje; rekomenduojami gamybos parametrai yra suteikti kiekvienam 25 procentams RAM:
tarakono pradžia - talpykla = 25% - max-sql-memory = 25%
Kuo daugiau mazgų paleidžiate, tuo geresnis bus atsparumas. Kuo didesni ir greitesni mazgai, tuo geresnis našumas. Jei norite turėti mazgų, kurių našumas apytiksliai palyginamas su „Google Cloud Spanner“ mazgais, kurie teikia 2 000 įrašų per sekundę ir 10 000 skaitymų per sekundę, norėtumėte kažko panašaus į GCE „n1-highcpu-8“ egzempliorius, turinčius aštuonis procesorius ir 8 GB RAM , su vietiniais SSD diskais (o ne sukamaisiais diskais).
Kuo daugiau paskirstysite savo mazgus skirtingiems duomenų centrams, tuo geriau galėsite užtikrinti imunitetą nuo duomenų centro lygio gedimų. Tačiau tai kainuoja: pirmyn ir atgalinis vėlavimas tarp duomenų centrų turės tiesioginę įtaką jūsų duomenų bazės našumui - tarpžemyniniai klasteriai veikia pastebimai prasčiau nei klasteriai, kuriuose visi mazgai yra geografiškai arti vienas kito.
Tarakonų laboratorijos pateikia išsamias instrukcijas, kaip diegti AWS, „Digital Ocean“, GCE ir „Azure“. Rekomenduojamose konfigūracijose naudojami apkrovos balansatoriai - vietinės valdomos apkrovos balansavimo paslaugos arba atvirojo kodo apkrovos balansatoriai, pvz., HAProxy.
Orkestravimas gali beveik nieko sumažinti „CockroachDB“ grupės veikiančią viršutinę dalį. Tarakonų laboratorijos dokumentai, kaip tai padaryti naudojant „Kubernetes“ ir „Docker Swarm“. „GitHub“ „CockroachDB-CloudFormation“ saugykloje parodyta, kaip naudoti „AWS CloudFormation“ ir „Kubernetes“ vienoje prieinamumo zonoje kuriant ir testuojant. Tai pritaikius gamybai, reikės modifikuoti „CloudFormation“ šabloną, kad būtų naudojamos kelios prieinamumo zonos.
TarakonųDB programavimas ir testavimas
„CockroachDB“ palaiko „PostgreSQL“ laido protokolą, todėl kodą rašote taip, lyg programuotumėte naudodami „Postgres“ arba bent jau „Postgres“ pogrupį. Šiame puslapyje pateikiamos išbandytos tvarkyklės, skirtos įvairiems programavimo kalbų susiejimams, įskaitant populiariausias serverio kalbas. Šiame puslapyje pateikiami pavyzdžiai 10 programavimo kalbų ir penki ORM. Skaitydamas kodą nesusidūriau su dideliais netikėtumais, nors dokumentacijos sąrašuose pastebėjau keletą galimų nedidelių klaidų. Taip pat galite paleisti SQL naudodami interaktyvų klientą, integruotą į tarakonas vykdomas.
Nors „CockroachDB“ apkrovos generatoriams yra skirtas atpirkimo įrankis, o kitas - našumo testams, „CockroachDB“ grupių palyginimas nėra lengvas, ypač jei bandote prasmingai palyginti „CockroachDB“ su kitomis duomenų bazėmis. Viena problema yra ta, kad mazgų tinklas gali būti greičio ribojimo žingsnis „CockroachDB“ grupėse.
Kitas faktas, į kurį reikia atsižvelgti, yra tai, kad dauguma įprastų SQL duomenų bazių pagal numatytuosius nustatymus neveikia SERIALIZABLE izoliavimo režimu; vietoj to jie naudoja mažiau griežtą režimą ir geresnį našumą. Pagal numatytuosius nustatymus „CockroachDB“ naudoja serijinį izoliavimo režimą. Be to, būtų šiek tiek nesąžininga išbandyti „CockroachDB“ SQL prisijungimo našumą, kuris vis dar vykdomas, su „TPC-C“ rinkiniu.
Ir vis tiek galite lengvai pamatyti „CockroachDB“ veikimo galią. Pavyzdžiui, norint išplėsti jų skaičių, reikia sustabdyti ir paleisti iš naujo daug duomenų bazių. Mazgų pridėjimas esant apkrovai „CockroachDB“ yra vėjelis, ypač jei naudojate orkestravimo įrankį. Pvz., Aukščiau pateiktoje ekrano kopijoje rodomos komandos pakeisti ir rodyti „Kubernetes“ sankaupos mazgus, o žemiau esančiame ekrane rodomas stebimas klasteris, kai mazgai pridedami. Krovinio generavimo įrankis veikė nuolat viso proceso metu.
Dar įspūdingesnė demonstracija rodo automatinę kryžminių debesų migraciją „CockroachDB“ grupėje. Tam tikrai reikia vaizdo, kad tai būtų teisinga; vaizdo įrašas talpinamas susietame tinklaraščio įraše.
TarakonasDB SQL
SQL „CockroachDB“ yra daugiau ar mažiau standartinė, skirtingai nei „Cloud Spanner“, kurioje manipuliuojant duomenimis naudojama nestandartinė sintaksė. Tačiau „CockroachDB SQL“ vis dar trūksta daugybės funkcijų.
Pavyzdžiui, V1.1 trūksta JSON palaikymo, kuris planuojamas V1.2. Taip pat trūksta XML analizavimo, kuris nėra gairėse. Jame trūksta eilių lygio kaskadų, numatytų V1.2 versijoje, ir žymeklių bei aktyviklių, kurie nėra gairėse. Geoerdviniai rodikliai yra „potencialūs“ papildymai, kurie ateityje gali patekti į gaires.
Visų pirma, pradinis „CockroachDB“ SQL prisijungimų diegimas 2016 m. Buvo sąmoningai supaprastintas ir parodė kvadratinį mastelį, todėl jis buvo nenaudingas užklausiant didelius duomenų rinkinius. V1.0 versija, kurią padarė kooperatyvo studentas, įdiegė maišos sujungimus, todėl daugelis prisijungimo operacijų skalės buvo linijinės; kad TarakonasDB pasiekė SQLite lygį. Kažkada 2018 m., Atsižvelgiant į pastarąjį finansavimo etapą, „CockroachDB“ turėtų turėti prisijungimo našumą, kuris būtų panašesnis į „PostgreSQL“ prisijungimą, taip pat SQL prisijungimo apdorojimas, paskirstytas per klasterį.
