Vēl pavisam nesen, iepērkoties datu bāzē, jums bija jāizvēlas: mērogojamība vai konsekvence? SQL datu bāzes, piemēram, MySQL, garantē stingru konsekvenci, taču tās horizontāli netiek mērogotas. (Manuāla sadalīšana mērogojamībai nav ideja par jautrību.) NoSQL datu bāzes, piemēram, MongoDB, skaisti mērogojas, taču piedāvā tikai konsekvenci. (“Gaidiet pietiekami ilgi, un jūs varat izlasīt pareizo atbildi” - tas nekādā veidā nav iespējams veikt finanšu darījumus.)
Google Cloud Spanner, pilnībā pārvaldīts relāciju datu bāzes pakalpojums, kas darbojas Google Compute Engine (GCE), kas izlaists 2017. gada februārī, nodrošina NoSQL datu bāzu mērogojamību, vienlaikus saglabājot SQL saderību, relāciju shēmas, ACID darījumus un spēcīgu ārēju konsekvenci. Spanner ir sadalīta, globāli izplatīta un atkārtota relāciju datu bāze, kas izmanto Paxos algoritmu, lai panāktu vienprātību starp mezgliem.
Viena no Spanner alternatīvām un šī pārskata tēma ir CockroachDB, atvērtā koda, horizontāli mērogojama sadalīta SQL datu bāze, ko izstrādājuši bijušie Google darbinieki, kuri bija pazīstami ar Spanner. CockroachDB aizņemas no Google’s Spanner datu glabāšanas sistēmas projektēšanai, un, lai panāktu vienprātību starp mezgliem, tā izmanto Raft algoritmu.
Tāpat kā Cloud Spanner, arī CockroachDB ir izplatīta SQL datu bāze, kas izveidota virs darījumu un konsekventa atslēgas vērtību krātuves, CockroachDB gadījumā ar RocksDB. CockroachDB galvenie dizaina mērķi ir atbalsts ACID darījumiem, horizontāla mērogojamība un (galvenokārt) izdzīvojamība, līdz ar to arī nosaukums.
CockroachDB ir paredzēts, lai izdzīvotu diska, mašīnas, plaukta un pat datacentra kļūmes ar minimāliem latentuma traucējumiem un bez manuālas iejaukšanās. Protams, lai to paveiktu, jums jāpalaiž a kopa no daudziem CockroachDB simetrisko mezglu gadījumiem, izmantojot vairākus diskus, mašīnas, statīvus un datu centrus.
Atšķirībā no Cloud Spanner, kas izmanto laika sinhronizēšanai pieejamo TrueTime API Google datu centros, CockroachDB nevar rēķināties ar atomu pulksteņu un GPS satelīta pulksteņu klātbūtni, lai precīzi sinhronizētu laiku starp mezgliem un datu centriem. Tam ir vairākas sekas. Vispirms Google TrueTime piešķir augšējo robežu pulksteņa nobīdēm starp mezgliem septiņu milisekunžu kopā. Tas ir pietiekami mazs, lai Spanner mezgls tikai pēc rakstīšanas gaida septiņas milisekundes, pirms ziņo par darījuma izdarīšanu, lai garantētu ārēju konsekvenci.
Bez TrueTime vai līdzīgas iespējas CockroachDB jāatgriežas pie NTP, kas nodrošina augšējo robežu pulksteņa sinhronizācijā no 100 milisekundēm līdz 250 milisekundēm. Ņemot vērā šo lielāko laika periodu, CockroachDB negaida pēc rakstīšanas. Tā vietā dažreiz gaida pirms nolasa, būtībā restartējot darījumu, ja tas nolasa vērtību ar laika zīmogu, kas ir lielāks par darījuma sākumu, atkal, lai garantētu konsekvenci.
Kad visiem CockroachDB klastera mezgliem ir mazas augšējās robežas pulksteņa nobīdēm, kuras varat iegūt no GPS vai atomu pulksteņiem, kas ir kaut kas pieejams tikai lielākajos publiskajos mākoņos, var būt jēga tos palaist ar --linearizējams karogu. Tas viņiem liek gaidīt maksimālo pulksteņa nobīdi, pirms atgriež veiksmīgu apņemšanos, tāpat kā Spanner.
Kā darbojas CockroachDB
Katrs CockroachDB mezgls sastāv no pieciem slāņiem:
- SQL, kas klienta SQL vaicājumus tulko atslēgas vērtību operācijās
- Darījums, kas ļauj veikt atomu izmaiņas vairākos atslēgas vērtības ierakstos
- Sadalījums, kas kopē atslēgu vērtību diapazonus kā vienu vienību
- Replikācija, kas konsekventi un sinhroni atkārto atslēgas vērtību diapazonus daudzos mezglos un ļauj konsekventi lasīt, izmantojot nomu
- Krātuve, kas uz diska raksta un nolasa galvenās vērtības datus
SQL slānis parsē vaicājumus pret Yacc failu un pārvērš tos par abstraktu sintakses koku. No abstraktā sintakses koka CockroachDB ģenerē plānu mezglu koku, kurā ir atslēgas vērtības kods. Pēc tam tiek izpildīti plāna mezgli, sazinoties ar darījumu slāni.
Darījumu slānis īsteno ACID darījumu semantiku ar divfāzu saistībām visā klasterī, ieskaitot darījumus starp diapazoniem un starp tabulām, atsevišķus paziņojumus uzskatot par darījumiem (sauktu arī par automātiskās saistības režīmu). Divfāžu saistības tiek izpildītas, grāmatojot darījumu ierakstus un rakstīšanas nodomus, izpildot lasīšanas operācijas un visus sastādītos rakstīšanas nodomus uzskatot par darījumu konfliktiem.
Izplatīšanas slānis saņem pieprasījumus no darījumu slāņa tajā pašā mezglā. Pēc tam tā identificē, kuriem mezgliem jāsaņem pieprasījums, un nosūta pieprasījumu pareizā mezgla replikācijas slānim.
Replikācijas slānis kopē datus starp mezgliem un nodrošina konsekvenci starp šīm kopijām, ieviešot Raft Consensus algoritmu. Replikācijas koeficientu var kontrolēt klastera, datu bāzes un tabulas līmenī, izmantojot replikācijas zonas. Saskaņas algoritms tiek izmantots tikai rakstīšanai, un tas prasa, lai kopiju kvorums vienotos par visām diapazona izmaiņām pirms šo izmaiņu izdarīšanas.
Uzglabāšanas slānis datus saglabā kā atslēgas vērtību pārus diskā, izmantojot RocksDB. CockroachDB lielā mērā paļaujas uz vairāku versiju vienlaicīguma kontroli (MVCC), lai apstrādātu vienlaicīgus pieprasījumus un garantētu konsekvenci. Liela daļa šī darba tiek veikta, izmantojot hibrīda loģiskā pulksteņa (HLC) laika zīmogus.
Tāpat kā Spanner, arī CockroachDB atbalsta vaicājumus laikā (tos iespējoja MVCC). Tās var atgriezties līdz jūsu jaunākajai datu bāzes atkritumu savākšanai, kas ikdienā tiek veikta pēc noklusējuma.
CockroachDB uzstādīšana un izmantošana
CockroachDB darbojas vismaz Mac, Linux un Windows operētājsistēmās, vismaz izstrādei un testēšanai. Produkcijas tarakānu datu bāzes parasti darbojas Linux virtuālajās mašīnās vai orķestrētos konteineros, kas bieži tiek mitināti uz publiskiem mākoņiem vairākos datu centros. CockroachDB Windows binārā versija joprojām ir beta fāzē un nav ieteicama ražošanai, un Apple vairs neveido servera aparatūru.
Tarakānu laboratorijas Kā redzat iepriekš redzamajā ekrānuzņēmumā, CockroachDB instalēšanai Mac ir četras iespējas. Es izvēlējos Homebrew kā visvienkāršāko no četriem.
Starp citu, Cockroach Labs vietnē ievieto brīdinājumu, kurā teikts, ka tādas valstiskas lietojumprogrammas kā CockroachDB palaišana Docker ir sarežģīta, nav ieteicama ražošanas izvietošanai, un tā vietā klastera darbināšanai jāizmanto tāds orķestrēšanas rīks kā Kubernetes vai Docker Swarm. Konteineru orķestrēšanas iespējas es apspriedīšu nākamajā sadaļā.
Instalēšana Mac datorā ir tikpat vienkārša kā brūvēt instalēt prusaku kā parādīts iepriekš. Manā gadījumā Homebrew automātiskā atjaunināšana prasīja daudz ilgāku laiku (pietiekami daudz laika tējas pagatavošanai) nekā faktiskā CockroachDB instalēšana, kas prasīja tikai dažas sekundes.
Kad esat instalējis programmu CockroachDB, ir diezgan viegli izveidot vietējo kopu, lai gan ir papildu solis drošības sertifikātu ģenerēšanai ar prusaku sert komandu, ja vēlaties, lai kopa būtu droša. Kad klasteris darbojas (izmantojot prusaku sākums vienreiz katram mezglam ar nākamajiem mezgliem, kas pievienoti pirmā mezgla kopai), varat izveidot savienojumu ar tīmekļa administrēšanas lapu jebkurā mezglā ar pārlūku un izmantot iegulto prusaku kvl klientam nosūtīt SQL vaicājumus uz jebkuru mezglu. Lielākā daļa pārlūkprogrammu sūdzēsies par vietnēm ar CockroachDB ģenerētiem sertifikātiem, taču jums vajadzētu būt iespējai noklikšķināt uz šī drausmīgā brīdinājuma un doties uz vietni.
Ieteicamie CockroachDB ražošanas iestatījumi atšķiras no noklusējuma iestatījumiem, kas tika iestatīti izstrādes un testa gadījumiem. Ja vēlaties, varat izveidot viena mezgla kopu. Ražošanai jums ir jābūt vismaz trim mezgliem, palaidiet katru mezglu atsevišķā mašīnā, VM vai konteinerā un piešķiriet katram gadījumam papildu kešatmiņu un SQL atmiņu. Kešatmiņai un SQL atmiņai noklusējuma iestatījumi ir 128 MB; Ieteicamajiem ražošanas iestatījumiem katram 25% RAM jāpiegādā:
prusaku sākums - kešatmiņa = 25% - max-sql-memory = 25%
Jo vairāk mezglu jūs vadāt, jo labāka būs noturība. Jo lielāki un ātrāki mezgli, jo labāks sniegums. Ja vēlaties, lai mezgli būtu aptuveni salīdzināmi ar Google Cloud Spanner mezgliem, kas nodrošina 2000 rakstīšanas sekundē un 10 000 lasījumu sekundē, tad vēlaties kaut ko līdzīgu GCE n1-highcpu-8 gadījumiem, kuriem ir astoņi procesori un 8 GB RAM , ar vietējiem SSD diskiem (nevis vērpšanas diskiem).
Jo vairāk jūs izplatāt savus mezglus dažādiem datu centriem, jo labāk jūs varat nodrošināt imunitāti pret datu centra līmeņa kļūmēm. Tomēr tam ir izmaksas: turp un atpakaļ latentumam starp datu centriem būs tieša ietekme uz jūsu datu bāzes veiktspēju, jo starpkontinentu kopas darbojas ievērojami sliktāk nekā kopas, kurās visi mezgli atrodas ģeogrāfiski tuvu viens otram.
Cockroach Labs nodrošina detalizētas instrukcijas izvietošanai AWS, Digital Ocean, GCE un Azure. Ieteicamajās konfigurācijās tiek izmantoti slodzes līdzsvarotāji, vai nu vietējie pārvaldītie slodzes līdzsvarošanas pakalpojumi, vai atvērtā koda slodzes līdzsvarotāji, piemēram, HAProxy.
Orķestrēšana var gandrīz neko samazināt CockroachDB kopas darbības virs galvas. Cockroach Labs dokumentē, kā to izdarīt ražošanai kopā ar Kubernetes un Docker Swarm. GitHub krātuve CockroachDB-CloudFormation parāda, kā izstrādāt un testēt AWS CloudFormation un Kubernetes vienā pieejamības zonā. Pielāgojot to ražošanai, būtu jāmaina CloudFormation veidne, lai izmantotu vairākas pieejamības zonas.
PrusakuDB programmēšana un testēšana
CockroachDB atbalsta PostgreSQL vadu protokolu, tāpēc jūs rakstāt kodu tā, it kā jūs programmētu pret Postgres vai vismaz Postgres apakškopu. Šajā lapā ir uzskaitīti pārbaudīti draiveri dažādām programmēšanas valodu sasaistēm, ieskaitot populārākās servera puses valodas. Šajā lapā ir uzskaitīti paraugi 10 programmēšanas valodās un piecās ORM. Izlasot kodu, es nesaskāros ar lieliem pārsteigumiem, lai gan dokumentācijas sarakstos pamanīju dažas iespējamās nelielās kļūdas. Varat arī palaist SQL, izmantojot iekšējo interaktīvo klientu tarakāns izpildāms.
Kaut arī pastāv repo, kas paredzēts CockroachDB slodzes ģeneratoriem, un vēl viens veiktspējas testiem, CockroachDB klasteru salīdzinošā novērtēšana nav viegli, it īpaši, ja mēģināt jēgpilni salīdzināt CockroachDB ar citām datu bāzēm. Viens jautājums ir tāds, ka tīkls starp mezgliem var būt ātruma ierobežošanas solis CockroachDB kopās.
Vēl viens fakts, kas jāņem vērā, ir tas, ka lielākā daļa parasto SQL datu bāzu pēc noklusējuma nedarbojas SERIALIZABLE izolācijas režīmā; tā vietā viņi izmanto mazāk stingru režīmu ar labāku sniegumu. CockroachDB pēc noklusējuma izmanto sērijveida izolācijas režīmu. Turklāt būtu nedaudz negodīgi pārbaudīt CockroachDB SQL pievienošanās veiktspēju, kas joprojām ir procesā, ar TPC-C komplektu.
Un tomēr jūs varat viegli redzēt CockroachDB darbības spēku. Piemēram, daudzas datu bāzes ir jāpārtrauc un jāpārstartē, lai tās palielinātu. Mezglu pievienošana zem slodzes CockroachDB ir brīze, it īpaši, ja izmantojat orķestrēšanas rīku. Piemēram, iepriekš redzamajā ekrānuzņēmumā ir redzamas komandas, lai mainītu un parādītu mezglus Kubernetes klasterī, un zemāk redzamajā ekrānuzņēmumā tiek parādīta uzraudzītā kopa, pievienojot mezglus. Slodzes ģenerēšanas rīks nepārtraukti darbojās visā procesā.
Vēl iespaidīgāka demonstrācija parāda automātisku savstarpēju mākoņu migrāciju CockroachDB kopas ietvaros. Tas tiešām prasa video, lai to izdarītu taisnīgi; videoklips tiek mitināts saistītajā emuāra ziņā.
TarakānsDB SQL
SQL CockroachDB ir vairāk vai mazāk standarta, atšķirībā no SQL Cloud Spanner, kas datu apstrādei izmanto nestandarta sintaksi. CockroachDB SQL joprojām trūkst daudz funkciju.
Piemēram, V1.1 trūkst JSON atbalsta, kas paredzēts V1.2. Tam trūkst arī XML parsēšanas, kas nav iekļauta ceļvedī. Tam trūkst rindu līmeņa kaskādes, kas plānotas V1.2 versijā, un trūkst kursoru un palaidēju, kas nav ceļa kartē. Ģeotelpiskie rādītāji ir “potenciālie” papildinājumi, kas nākotnē var iekļūt ceļvedī.
Vissvarīgākais ir tas, ka sākotnējā CockroachDB SQL pievienošanās ieviešana 2016. gadā bija apzināti vienkāršota un parādīja kvadrātisku mērogošanu, padarot to bezjēdzīgu vaicājot lielām datu kopām. V1.0 versija, ko veica kooperatīva students, ieviesa hash savienojumus, liekot daudzām pievienošanās operācijām mērogot lineāri; kas CockroachDB nonāca līdz SQLite līmenim. Kaut kad 2018. gadā, ņemot vērā neseno finansēšanas kārtu, CockroachDB vajadzētu būt pievienošanās veiktspējai, kas būtu vairāk līdzīga PostgreSQL pievienošanai, kā arī SQL pievienošanās apstrādei, kas sadalīta pa kopu.
