Viime aikoihin asti, kun ostit tietokannasta, joudut valitsemaan: Skaalautuvuus vai johdonmukaisuus? SQL-tietokannat, kuten MySQL, takaavat vahvan yhtenäisyyden, mutta eivät skaalaa hyvin vaakasuunnassa. (Manuaalinen sirpaloituminen skaalautuvuudesta ei ole kenenkään ajatus hauskuudesta.) NoSQL-tietokannat, kuten MongoDB, skaalautuvat kauniisti, mutta tarjoavat vain mahdollisen yhtenäisyyden. ("Odota tarpeeksi kauan, niin voit lukea oikean vastauksen" - mikä ei ole mikään tapa tehdä rahoitustapahtumia.)
Google Cloud Spanner, täysin hallittu relaatiotietokantapalvelu, joka toimii Google Compute Engine (GCE) -palvelussa, julkaistiin helmikuussa 2017, sisältää NoSQL-tietokantojen skaalautuvuuden säilyttäen samalla SQL-yhteensopivuuden, relaatiomallit, ACID-tapahtumat ja vahvan ulkoisen johdonmukaisuuden. Spanner on sirpaleinen, globaalisti hajautettu ja kopioitu relaatiotietokanta, joka käyttää Paxos-algoritmia yksimielisyyden saavuttamiseksi solmujensa välillä.
Yksi vaihtoehto Spannerille ja tämän arvostelun aihe on CockroachDB, avoimen lähdekoodin, horisontaalisesti skaalautuva hajautettu SQL-tietokanta, jonka Spannerille tuntevat entiset Googlen työntekijät ovat kehittäneet. CockroachDB lainaa Googlen Spannerilta tietotallennusjärjestelmänsä suunnitteluun ja käyttää Raft-algoritmia yksimielisyyden saavuttamiseen solmujensa välillä.
Kuten Cloud Spanner, CockroachDB on hajautettu SQL-tietokanta, joka on rakennettu transaktioiden ja johdonmukaisen avainarvosäilön päälle, CockroachDB: n tapauksessa RocksDB: llä. CockroachDB: n ensisijaiset suunnittelutavoitteet ovat tuki ACID-tapahtumille, horisontaalinen skaalautuvuus ja (ennen kaikkea) selviytyvyys, joten nimi.
CockroachDB on suunniteltu selviytymään levyn, koneen, telineen ja jopa datakeskuksen vikoista minimaalisilla viivehäiriöillä ja ilman manuaalisia toimenpiteitä. Tietenkin, jotta voit saavuttaa sen, sinun on suoritettava a klusteri monista CockroachDB: n symmetrisistä solmuista, joissa käytetään useita levyjä, koneita, telineitä ja datakeskuksia.
Toisin kuin Cloud Spanner, joka käyttää TrueTime-sovellusliittymää, joka on käytettävissä ajan synkronointiin Google-datakeskuksissa, CockroachDB ei voi luottaa atomikellojen ja GPS-satelliittikellojen läsnäoloon synkronoidakseen ajan tarkasti solmujen ja palvelinkeskusten välillä. Tällä on useita vaikutuksia. Ensinnäkin Google TrueTime antaa ylärajan kellonsiirtymille solmujen välillä seitsemän millisekunnin ryhmässä. Se on tarpeeksi pieni, jotta Spanner-solmu odottaa vain seitsemän millisekuntia kirjoituksen jälkeen, ennen kuin se ilmoittaa tapahtumasta, ulkoisen johdonmukaisuuden takaamiseksi.
Ilman TrueTimeä tai vastaavaa laitetta CockroachDB: n on palattava takaisin NTP: hen, mikä antaa ylin rajan kellosynkronoinnissa 100 millisekunnin ja 250 millisekunnin välillä. Ottaen huomioon suuremman aikaikkunan CockroachDB ei odota kirjoituksen jälkeen. Sen sijaan joskus odottaa ennen lukemista, käynnistää tapahtuman pohjimmiltaan uudelleen, jos se lukee arvon, jonka aikaleima on suurempi kuin tapahtuman alku, jälleen taata johdonmukaisuus.
Kun kaikilla CockroachDB-klusterin solmuilla on pienet ylärajat kellonsiirtymille, jotka voit saada GPS: stä tai atomikelloista, mikä on jotain, joka on juuri saatavana suurimmissa julkisissa pilvissä, voi olla järkevää käyttää niitä - linearisoitavissa lippu. Se saa heidät odottamaan enimmäiskellonsiirtoa ennen kuin palauttavat onnistuneen sitoutumisen, aivan kuten Spanner.
Kuinka TorakkaDB toimii
Jokainen TorakkaDB-solmu koostuu viidestä kerroksesta:
- SQL, joka kääntää asiakkaan SQL-kyselyt avainarvo-operaatioiksi
- Transaktio, joka sallii atomimuutokset useisiin avainarvojen syötteisiin
- Jakelu, joka esittää replikoidut avainarvojen alueet yhtenä kokonaisuutena
- Replikointi, joka replikoi johdonmukaisesti ja synkronisesti avaimen arvoalueet useissa solmuissa ja mahdollistaa johdonmukaisen lukemisen vuokrasopimusten kautta
- Tallennus, joka kirjoittaa ja lukee avainarvotiedot levylle
SQL-kerros jäsentää kyselyt Yacc-tiedostoa vastaan ja muuttaa niistä abstraktin syntaksipuun. Abstraktista syntaksipuusta CockroachDB luo puun suunnitelmasolmuista, jotka sisältävät avainarvokoodin. Suunnitelmasolmut suoritetaan sitten kommunikoiden tapahtumakerroksen kanssa.
Tapahtumakerros toteuttaa ACID-tapahtumasemantiikan kaksivaiheisilla sitoumuksilla koko klusterissa, mukaan lukien alueiden väliset ja taulukoiden väliset tapahtumat, käsittelemällä yksittäisiä lauseita tapahtumina (kutsutaan myös automaattiseksi sitoutumistilaksi). Kaksivaiheinen sitoutuminen suoritetaan lähettämällä tapahtumarekisterit ja kirjoitustavat, suorittamalla lukutoiminnot ja käsittelemällä kaikki kohdatut kirjoitustavat tapahtumaristiriidoina.
Jakelukerros vastaanottaa pyyntöjä tapahtumakerrokselta samalla solmulla. Sen jälkeen se tunnistaa, minkä solmujen tulisi vastaanottaa pyyntö, ja lähettää pyynnön oikean solmun replikointikerrokselle.
Replikointikerros kopioi tietoja solmujen välillä ja varmistaa näiden kopioiden välisen yhdenmukaisuuden toteuttamalla Raft-konsensusalgoritmin. Voit hallita replikointikerrointa klusterin, tietokannan ja taulukon tasolla käyttämällä replikointialueita. Konsensusalgoritmia käytetään vain kirjoituksiin, ja se edellyttää, että jäljennösten koorumi hyväksyy kaikki alueen muutokset ennen näiden muutosten tekemistä.
Tallennuskerros tallentaa tiedot avainarvopareina levylle RocksDB: n avulla. CockroachDB luottaa vahvasti moniversioiseen samanaikaisuuden hallintaan (MVCC) samanaikaisten pyyntöjen käsittelemiseksi ja yhdenmukaisuuden takaamiseksi. Suuri osa tästä työstä tehdään käyttämällä hybridiloogisen kellon (HLC) aikaleimoja.
Kuten Spanner, CockroachDB tukee aikamatkakyselyjä (MVCC: n sallima). Nämä voivat palata viimeisimpään tietokantasi roskakoriin, joka tehdään oletuksena päivittäin.
TorakkaDB: n asennus ja käyttö
CockroachDB toimii Mac-, Linux- ja Windows-käyttöjärjestelmissä, ainakin kehitystä ja testausta varten. Tuotanto Torakka-tietokannat toimivat yleensä Linux-virtuaalikoneilla tai orkesteroiduilla säiliöillä, joita isännöidään usein julkisissa pilvissä useissa datakeskuksissa. CockroachDB: n Windows-binaari on edelleen beeta-vaiheessa, eikä sitä suositella tuotantoon, eikä Apple enää valmista palvelinlaitteistoa.
Torakka Labs Kuten yllä olevasta kuvakaappauksesta näet, CockroachDB: n asentamiseen Maciin on neljä vaihtoehtoa. Valitsin Homebrew'n todennäköisesti helpoimmaksi neljästä.
Cockroach Labs lähettää muuten varoituksen sivustolle, jonka mukaan tilallisen sovelluksen, kuten CockroachDB: n, suorittaminen Dockerissa on hankalaa, sitä ei suositella tuotantokäyttöön, ja käyttää sen sijaan orkesterityökalua, kuten Kubernetes tai Docker Swarm. Keskustelen konttien orkestrointivaihtoehdoista seuraavassa osiossa.
Asennus Maciin on yhtä helppoa kuin hautua asentaa torakka kuten yllä on esitetty. Minun tapauksessani Homebrew'n automaattinen päivitys kesti paljon kauemmin (tarpeeksi aikaa teen keittämiseen) kuin varsinainen CockroachDB -asennus, joka kesti vain muutaman sekunnin.
Kun olet asentanut CockroachDB: n, paikallisen klusterin luominen on melko helppoa, vaikka tietoturvavarmenteiden luominen on ylimääräinen vaihe torakka sertti -komento, jos haluat klusterin olevan turvallinen. Kun klusteri on käynnissä (käyttämällä torakka alkaa komento kerran jokaiselle solmulle, ja seuraavat solmut on asetettu liittymään ensimmäisen solmun klusteriin), voit muodostaa yhteyden minkä tahansa solmun web-hallinnointisivulle selaimella ja käyttää upotettua torakka sql asiakas lähettää SQL-kyselyitä mihin tahansa solmuun. Suurin osa selaimista valittaa sivustoista, joilla on CockroachDB: n luomia varmenteita, mutta sinun pitäisi pystyä napsauttamaan tätä kovaa varoitusta ja jatkamaan sivustoa.
Suositellut CockroachDB-tuotantoasetukset poikkeavat oletusasetuksista, jotka on määritetty kehitys- ja testausilmentymille. Voit kehittyä yhden solmun klusterissa, jos haluat. Tuotantoa varten sinulla on oltava vähintään kolme solmua, suorita kukin solmu erillisessä koneessa, virtuaalikoneessa tai säilössä ja anna jokaiselle esiintymälle ylimääräinen välimuisti ja SQL-muisti. Oletusasetukset ovat 128 Mt välimuistille ja SQL-muistille; suositeltavien tuotantoasetusten on antaa jokaiselle 25 prosenttia RAM-muistista:
torakan alku --välimuisti = 25% --max-sql-muisti = 25%
Mitä enemmän solmuja suoritat, sitä parempi joustavuus tulee olemaan. Mitä isommat ja nopeammat solmut, sitä parempi suorituskyky. Jos haluat, että solmut ovat suunnilleen verrattavissa Google Cloud Spanner -solmuihin, jotka tuottavat 2000 kirjoitusta sekunnissa ja 10000 lukua sekunnissa, haluaisit jotain GCE: n n1-highcpu-8-ilmentymiä, joissa on kahdeksan prosessoria ja 8 Gt RAM-muistia , paikallisilla SSD-levyillä (eikä pyörivillä levyillä).
Mitä enemmän jaat solmujasi eri datakeskuksiin, sitä paremmin voit varmistaa immuniteetin datakeskuksen tason vikoille. Siitä on kuitenkin kustannuksia: Tietokeskusten välisellä edestakaisella viiveellä on suora vaikutus tietokannan suorituskykyyn, sillä mantereiden väliset klusterit toimivat huomattavasti huonommin kuin klusterit, joissa kaikki solmut ovat maantieteellisesti lähellä toisiaan.
Cockroach Labs tarjoaa yksityiskohtaiset ohjeet käyttöönottoon AWS: ssä, Digital Oceanissa, GCE: ssä ja Azuressa. Suositelluissa kokoonpanoissa käytetään kuormituksen tasapainotimia, joko alkuperäisiä hallittuja kuormituksen tasauspalveluita tai avoimen lähdekoodin kuormituksen tasauslaitteita, kuten HAProxy.
Orkestrointi voi laskea CockroachDB-klusterin toiminnan yläpuolella olevan melkein mitään. Cockroach Labs dokumentoi, miten tämä tehdään tuotannolle Kubernetesin ja Docker Swarmin kanssa. GitHubin CockroachDB-CloudFormation-arkisto näyttää, kuinka AWS CloudFormationia ja Kubernetesia voidaan käyttää yhdessä käytettävyysvyöhykkeessä kehitykseen ja testaukseen. Tämän mukauttaminen tuotantoon edellyttäisi CloudFormation-mallin muokkaamista useiden käytettävyysalueiden käyttämiseksi.
TorakkaDB-ohjelmointi ja testaus
CockroachDB tukee PostgreSQL-johdinprotokollaa, joten kirjoitat koodisi ikään kuin ohjelmoit Postgresiä tai ainakin Postgres-osajoukkoa vastaan. Tällä sivulla on lueteltu testatut ohjaimet erilaisille ohjelmointikielen sidoksille, mukaan lukien suosituimmat palvelinpuolen kielet. Tällä sivulla on luettelo näytteistä 10 ohjelmointikielellä ja viidellä ORM: llä. En törmännyt suuriin yllätyksiin, kun luin koodin läpi, vaikka havaitsin muutaman todennäköisen pienen virheen asiakirjojen luetteloissa. Voit myös suorittaa SQL: n käyttämällä torakka suoritettava.
Vaikka CockroachDB-kuormageneraattoreille on omistettu repo ja toinen suorituskykytesteille, CockroachDB-klustereiden vertailu ei ole helppoa, varsinkin jos yrität verrata CockroachDB: tä muihin tietokantoihin mielekkäällä tavalla. Yksi asia on, että solmujen välinen verkko voi olla nopeutta rajoittava vaihe CockroachDB-klustereissa.
Toinen huomioitava tosiasia on, että useimmat perinteiset SQL-tietokannat eivät ole oletusarvoisesti SERIALIZABLE-eristystilassa; sen sijaan he käyttävät vähemmän tiukkaa tilaa paremmalla suorituskyvyllä. CockroachDB käyttää oletusarvoisesti sarjoitettavaa eristystilaa. Lisäksi olisi hieman epäreilua testata CockroachDB: n SQL-liittymissuorituskykyä, joka on vielä kesken, TPC-C-paketin kanssa.
Ja silti voit helposti nähdä CockroachDB: n käyttövoiman. Esimerkiksi monet tietokannat on lopetettava ja käynnistettävä uudelleen niiden laajentamiseksi. Solmujen lisääminen kuormitettuna CockroachDB: ssä on helppoa, varsinkin jos käytät orkestrointityökalua. Esimerkiksi yllä olevassa kuvakaappauksessa näytetään komennot, joilla vaihdetaan ja näytetään solmut Kubernetes-klusterissa, ja alla oleva kuvakaappaus näyttää valvotun klusterin, kun solmut lisätään. Kuormanmuodostustyökalu toimi jatkuvasti koko prosessin ajan.
Vielä vaikuttavampi esittely osoittaa automaattisen pilvipalvelujen siirron CockroachDB-klusterissa. Se vaatii todella videota, jotta se toimisi oikeudenmukaisesti; video isännöi linkitetyssä blogikirjoituksessa.
TorakkaDB SQL
CockroachDB: n SQL on enemmän tai vähemmän vakio, toisin kuin Cloud Spanner, joka käyttää epätyypillistä syntaksia tietojen manipulointiin. CockroachDB SQL: stä puuttuu kuitenkin vielä monia ominaisuuksia.
Esimerkiksi V1.1: stä puuttuu JSON-tuki, joka on suunniteltu versiolle V1.2. Siinä ei myöskään ole XML-jäsentelyä, mikä ei ole etenemissuunnitelmassa. Siinä ei ole rivitason kaskadeja, jotka on suunniteltu versiolle V1.2, eikä kursoreita ja liipaisimia, jotka eivät ole tiekartassa. Paikkatietohakemistot ovat "potentiaalisia" lisäyksiä, jotka saattavat päästä etenemissuunnitelmaan tulevaisuudessa.
Erityisesti SQL-liittymien CockroachDB: n alkuperäinen toteutus vuonna 2016 oli tarkoituksellisesti yksinkertainen ja siinä oli neliöllinen skaalaus, joten se oli hyödytön suurten tietojoukkojen kyselyssä. Osuusopiskelijan tekemä versio V1.0: ssa, toteutettu hash-liitokset, jolloin monet liittymistoiminnot ovat lineaarisia; joka sai CockroachDB: n suunnilleen SQLiten tasolle. Joskus vuonna 2018, kun otetaan huomioon äskettäinen rahoituskierros, CockroachDB: llä pitäisi olla liittymissuorituskyky, joka on enemmän kuin PostgreSQL-liittyminen, sekä SQL-liittymän käsittely klusterin yli.
