Hei Khabrovites. Perinteisesti jatkamme mielenkiintoisen materiaalin jakamista uusien kurssien alkamisen kynnyksellä. Olemme tänään erityisesti sinulle kääntäneet artikkelin Google Cloud Spannerista, joka on ajoitettu samaan aikaan kurssin julkaisun kanssa .
Alunperin julkaistu v .
Yrityksenä, joka tarjoaa erilaisia pilvipohjaisia POS-ratkaisuja vähittäiskauppiaille, ravintoloitsijoille ja verkkokauppiaille ympäri maailmaa, Lightspeed käyttää useita erilaisia tietokantaalustoja erilaisiin transaktio-, analytiikka- ja hakukäyttötapauksiin. Jokaisella näistä tietokanta-alustoista on omat vahvuutensa ja heikkoutensa. Siksi, kun Google esitteli Cloud Spannerin markkinoille – lupaavia ominaisuuksia, joita relaatiotietokantojen maailmassa ei ole nähty, kuten käytännössä rajoittamaton horisontaalinen skaalautuvuus ja 99,999 %:n palvelutasosopimus (SLA) , Emme voineet jättää käyttämättä tilaisuutta saada hänet käsiimme!
Antaaksemme kattavan yleiskatsauksen kokemuksistamme Cloud Spannerista sekä käyttämistämme arviointikriteereistä käsittelemme seuraavat aiheet:
- Arviointikriteerimme
- Cloud Spanner pähkinänkuoressa
- Meidän arviomme
- Tuloksemme
1. Arviointikriteerimme
Ennen kuin sukeltaa Cloud Spannerin erityispiirteisiin, sen yhtäläisyyksiin ja eroihin muiden markkinoiden ratkaisujen kanssa, puhutaan ensin tärkeimmistä käyttötapauksista, jotka meillä oli mielessä pohdittaessa, missä Cloud Spanner otetaan käyttöön infrastruktuurissamme:
- Korvaamaan (vallitsevan) perinteisen SQL-tietokantaratkaisun
- OLAP-yhteensopivana OLTP-ratkaisuna
Huom: Vertailun helpottamiseksi tässä artikkelissa verrataan Cloud Spanneria GCP Cloud SQL- ja Amazon AWS RDS -ratkaisuperheiden MySQL-muunnelmiin.
Cloud Spannerin käyttäminen perinteisen SQL-tietokantaratkaisun korvaajana
Ympäristössä perinteinen tietokantoja, kun tietokantakyselyn vasteaika lähestyy tai jopa ylittää ennalta määritettyjä sovelluskynnyksiä (johtuen ensisijaisesti käyttäjien ja/tai pyyntöjen määrän kasvusta), on useita tapoja lyhentää vastausaikaa hyväksyttävälle tasolle. Useimmat näistä ratkaisuista sisältävät kuitenkin manuaalisen toiminnan.
Esimerkiksi ensimmäinen askel on tarkastella erilaisia suorituskykyyn liittyviä tietokantaasetuksia ja virittää ne vastaamaan parhaiten sovellusten käyttömalleja. Jos tämä ei riitä, voit skaalata tietokantaa pysty- tai vaakasuunnassa.
Sovelluksen skaalaaminen edellyttää palvelimen ilmentymän päivittämistä, tyypillisesti lisäämällä prosessoreita/ytimiä, enemmän RAM-muistia, nopeampaa tallennustilaa jne. Laitteiston resurssien lisääminen parantaa tietokannan suorituskykyä, mitattuna ensisijaisesti tapahtumissa sekunnissa, ja tapahtumaviiveet OLTP-järjestelmissä. Relaatiotietokantajärjestelmät (jotka käyttävät monisäikeistä lähestymistapaa), kuten MySQL, skaalautuvat hyvin pystysuunnassa.
Tällä lähestymistavalla on useita haittoja, mutta ilmeisin on markkinoiden suurin palvelimen koko. Kun suurin palvelininstanssiraja on saavutettu, jäljellä on vain yksi polku: skaalata.
Scale-out on lähestymistapa, joka lisää palvelimia klusteriin, mikä parantaa suorituskykyä ihanteellisesti lineaarisesti, kun palvelimia lisätään. Suurin osa perinteinen tietokantajärjestelmät eivät skaalaudu hyvin tai eivät skaalaudu ollenkaan. Esimerkiksi MySQL voi skaalata lukuja lisäämällä orjalukijoita, mutta se ei voi skaalata kirjoituksia varten.
Toisaalta Cloud Spanner voi luonteensa vuoksi skaalata vaakasuunnassa helposti minimaalisella toimenpiteellä.
Täysin varusteltu DBMS palveluna on arvioitava eri näkökulmista. Otimme pohjaksi pilven suosituimman DBMS:n – Googlelle GCP Cloud SQL:n ja Amazonille AWS RDS:n. Keskityimme arvioinnissamme seuraaviin luokkiin:
- Ominaisuuskartoitus: SQL-laajuus, DDL, DML; yhteyskirjastot/liittimet, tapahtumatuki ja niin edelleen.
- Kehitystuki: Kehittämisen ja testauksen helppous.
- Järjestelmänvalvontatuki: Ilmentymien hallinta, kuten ilmentymien skaalaus ylös/alas ja päivitys; Palvelusopimus, varmuuskopiointi ja palautus; turvallisuus/kulunvalvonta.
Cloud Spannerin käyttäminen OLAP-yhteensopivana OLTP-ratkaisuna
Vaikka Google ei nimenomaisesti ilmoita, että Cloud Spanner on tarkoitettu analytiikkaan, se jakaa joitakin määritteitä muiden moottoreiden, kuten Apache Impala & Kudun ja YugaByten kanssa, jotka on suunniteltu OLAP-työkuormille.
Vaikka olisi vain pieni mahdollisuus, että Cloud Spanner sisälsi johdonmukaisen skaalautuvan HTAP-moottorin (hybriditransaktioiden/analyyttinen käsittely) ja (enemmän tai vähemmän) käyttökelpoisen OLAP-ominaisuusjoukon, uskomme, että se ansaitsisi huomiomme.
Tätä silmällä pitäen tarkastelimme seuraavia luokkia:
- Tietojen lataus, indeksit ja osiointituki
- Kyselyn suorituskyky ja DML
2. Pilviavain pähkinänkuoressa
Google Spanner on klusteroitu relaatiotietokannan hallintajärjestelmä (RDBMS), jota Google käyttää useissa omissa palveluissaan. Google asetti sen julkisesti Google Cloud Platform -käyttäjien saataville vuoden 2017 alussa.
Tässä on joitain Cloud Spanner -määritteistä:
- Erittäin johdonmukainen, skaalautuva RDBMS-klusteri: Käyttää laitteiston aikasynkronointia tietojen johdonmukaisuuden varmistamiseksi.
- Taulukoiden välinen tapahtumatuki: Tapahtumat voivat kattaa useita taulukoita - ei välttämättä rajoitettu yhteen taulukkoon (toisin kuin Apache HBase tai Apache Kudu).
- Primary Key -pohjaiset taulukot: Kaikilla taulukoilla on oltava ilmoitettu ensisijainen avain (PC), joka voi koostua useista taulukon sarakkeista. Taulukkotiedot tallennetaan PC-järjestyksessä, mikä tekee siitä erittäin tehokkaan ja nopean PC-hauissa. Kuten muissakin PC-pohjaisissa järjestelmissä, toteutus on mallinnettava ennalta suunniteltujen käyttötapausten mukaan, jotta se saavutettaisiin .
- Raidalliset taulukot: Taulukoilla voi olla fyysisiä riippuvuuksia toisistaan. Alitaulukon rivit voidaan sovittaa ylätason taulukon riveihin. Tämä lähestymistapa nopeuttaa sellaisten suhteiden etsimistä, jotka voidaan määrittää tiedon mallinnusvaiheessa, esimerkiksi sijoitettaessa asiakkaita ja heidän laskujaan yhteen.
- Indeksit: Cloud Spanner tukee toissijaisia indeksejä. Hakemisto koostuu indeksoiduista sarakkeista ja kaikista PC-sarakkeista. Valinnaisesti hakemisto voi sisältää myös muita indeksoimattomia sarakkeita. Hakemisto voidaan lomittaa päätaulukon kanssa kyselyjen nopeuttamiseksi. Indekseihin sovelletaan useita rajoituksia, kuten hakemistoon tallennettavien lisäsarakkeiden enimmäismäärä. Myöskään indeksien kautta tehtävät kyselyt eivät välttämättä ole yhtä yksinkertaisia kuin muissa RDBMS-järjestelmissä.
"Cloud Spanner valitsee indeksin automaattisesti vain harvoissa tapauksissa. Erityisesti Cloud Spanner ei valitse automaattisesti toissijaista indeksiä, jos kysely pyytää sarakkeita, joita ei ole tallennettu '.
- Palvelutasosopimus (SLA): yhden alueen käyttöönotto ja 99,99 % SLA; usean alueen käyttöönotot 99,999 %:n SLA:lla. Vaikka palvelusopimus itsessään on vain sopimus eikä minkäänlainen takuu, uskon, että Googlen ihmisillä on kovaa tietoa esittääkseen näin vahvan väitteen. (Viite: 99,999 % tarkoittaa 26,3 sekuntia palvelukatkoksia kuukaudessa.)
- lisää:
Huom: Apache Tephra -projekti lisää edistyneen tapahtumatuen Apache HBaseen (myös nyt toteutettu Apache Phoenixissa betaversiona).
3. Arviomme
Olemme siis kaikki lukeneet Googlen lausunnot Cloud Spannerin eduista – käytännössä rajattomasta vaakasuuntaisesta skaalauksesta säilyttäen samalla korkean johdonmukaisuuden ja erittäin korkean SLA:n. Vaikka näitä väitteitä on joka tapauksessa erittäin vaikea saavuttaa, tavoitteemme ei ollut kumota niitä. Sen sijaan keskitytään muihin asioihin, joista useimmat tietokannan käyttäjät välittävät: pariteetti ja käytettävyys.
Arvioimme Cloud Spannerin Sharded MySQL:n korvikkeena
Google Cloud SQL ja Amazon AWS RDS, kaksi pilvimarkkinoiden suosituimmista OLTP-tietokannoista, sisältävät erittäin laajan ominaisuusjoukon. Kuitenkin, jotta voit skaalata nämä tietokannat yhden solmun koon yli, sinun on suoritettava sovellusten jakaminen. Tämä lähestymistapa lisää monimutkaisuutta sekä sovelluksille että hallinnolle. Tarkastelimme, kuinka Spanner sopii useiden sirpaleiden yhdistämiseen yhdeksi esiintymäksi ja mitkä ominaisuudet (jos sellaisia on) joudutaan uhraamaan.
SQL-, DML- ja DDL-tuki sekä liitin ja kirjastot?
Ensinnäkin, kun aloitat minkä tahansa tietokannan kanssa, sinun on luotava tietomalli. Jos luulet voivasi yhdistää JDBC Spannerin suosikki SQL-työkaluihisi, huomaat, että voit tiedustella tietojasi sen avulla, mutta et voi käyttää sitä taulukon tai päivityksen (DDL) tai lisäyksen/päivityksen/poiston luomiseen. operaatiot (DML). Googlen virallinen JDBC ei tue kumpaakaan.
"Ajurit eivät tällä hetkellä tue DML- tai DDL-lauseita."
Avaimen dokumentaatio
Tilanne ei ole parempi GCP-konsolin kanssa - voit lähettää vain SELECT-kyselyitä. Onneksi yhteisössä on JDBC-ohjain, jossa on DML- ja DDL-tuki, mukaan lukien tapahtumat . Vaikka tämä ohjain on erittäin hyödyllinen, Googlen oman JDBC-ohjaimen puuttuminen on yllättävää. Onneksi Google tarjoaa melko laajan asiakaskirjastotuen (perustuu gRPC:hen): C#, Go, Java, node.js, PHP, Python ja Ruby.
Cloud Spannerin mukautettujen sovellusliittymien lähes pakollinen käyttö (johtuen JDBC:n DDL:n ja DML:n puutteesta) aiheuttaa joitain rajoituksia asiaan liittyville koodialueille, kuten yhteyden yhdistämiseen tai tietokannan sitomiskehyksiin (kuten Spring MVC). Yleensä JDBC:tä käytettäessä voit vapaasti valita suosikkiyhteyspooli (esim. HikariCP, DBCP, C3PO jne.), joka on testattu ja toimii hyvin. Mukautettujen Spanner-sovellusliittymien tapauksessa meidän on luotettava kehyksiin/sidos-/istuntopooleihin, jotka olemme itse luoneet.
Ensisijaisen avaimen (PC) suunnittelu mahdollistaa sen, että Cloud Spanner on erittäin nopea, kun se käyttää tietoja PC:n kautta, mutta tuo mukanaan myös joitain kyselyongelmia.
- Et voi päivittää ensisijaisen avaimen arvoa. Sinun on ensin poistettava alkuperäinen PC-merkintä ja lisättävä se uudelleen uudella arvolla. (Tämä on samanlainen kuin muut PC-suuntaiset tietokanta-/tallennuskoneet.)
- Kaikkien UPDATE- ja DELETE-käskyjen on määritettävä PC WHERE-kohdassa, joten DELETE kaikki -käskyt eivät voi olla tyhjiä - siellä on aina oltava alikysely, esimerkiksi: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Automaattisen lisäyksen puuttuminen tai jotain vastaavaa, joka määrittää PC-kentän järjestyksen. Jotta tämä toimisi, vastaava arvo on luotava sovelluspuolelle.
Toissijaiset indeksit?
Google Cloud Spannerissa on sisäänrakennettu tuki toissijaisille indekseille. Tämä on erittäin mukava ominaisuus, jota ei aina ole muissa teknologioissa. Apache Kudu ei tällä hetkellä tue toissijaisia indeksejä ollenkaan, eikä Apache HBase tue indeksejä suoraan, mutta voi lisätä ne Apache Phoenixin kautta.
Kudun ja HBasen indeksit voidaan mallintaa erilliseksi taulukoksi, jossa on erilainen ensisijaisten avainten koostumus, mutta emotaulukossa ja siihen liittyvissä indeksitaulukoissa suoritettavien toimintojen atomiteetti on suoritettava sovellustasolla, eikä se ole triviaalia toteuttaa oikein.
Kuten Cloud Spanner -katsauksessa mainittiin, sen indeksit voivat poiketa MySQL-hakemistoista. Siksi kyselyn rakentamisessa ja profiloinnissa on oltava erityisen huolellinen, jotta oikeaa indeksiä käytetään siellä, missä sitä tarvitaan.
Edustus?
Erittäin suosittu ja hyödyllinen kohde tietokannassa on näkymät. Ne voivat olla hyödyllisiä useissa käyttötapauksissa; kaksi suosikkiani ovat looginen abstraktiokerros ja suojauskerros. Valitettavasti Cloud Spanner EI tue näkymiä. Tämä kuitenkin rajoittaa meitä vain osittain, koska käyttöoikeuksilla ei ole saraketason tarkkuutta, jossa näkymät voivat olla hyväksyttävä ratkaisu.
Katso Cloud Spanner -dokumentaatiosta kiintiöt ja rajoitukset (), on erityisesti yksi, joka voi olla ongelmallinen joillekin sovelluksille: Cloud Spanner valmiina sisältää enintään 100 tietokantaa esiintymää kohden. Ilmeisesti tämä voi olla suuri este tietokannalle, joka on suunniteltu skaalautumaan yli 100 tietokantaan. Onneksi keskustellessamme Googlen teknisen edustajamme kanssa huomasimme, että tätä rajaa voidaan nostaa lähes mihin tahansa arvoon Google-tuen kautta.
Kehitystuki?
Cloud Spanner tarjoaa melko kunnollisen ohjelmointikielen tuen API-työskentelyyn. Virallisesti tuetut kirjastot ovat C#, Go, Java, node.js, PHP, Python ja Ruby alueella. Dokumentaatio on melko yksityiskohtainen, mutta kuten muissakin huipputeknologioissa, yhteisö on melko pieni verrattuna suosituimpiin tietokantatekniikoihin, mikä voi johtaa enemmän aikaa käytettyyn harvempiin käyttötapauksiin tai ongelmiin.
Entä paikallinen kehitystuki?
Emme ole löytäneet tapaa luoda Cloud Spanner -esiintymää paikan päällä. Lähin meillä on Docker-kuva joka on periaatteessa samanlainen, mutta käytännössä hyvin erilainen. Esimerkiksi CockroachDB voi käyttää PostgreSQL JDBC:tä. Koska kehitysympäristön tulisi olla mahdollisimman lähellä tuotantoympäristöä, Cloud Spanner ei ole ihanteellinen, koska sinun täytyy luottaa täydelliseen Spanner-instanssiin. Voit säästää kustannuksia valitsemalla yhden alueen esiintymän.
Hallintotuki?
Cloud Spanner -esiintymän luominen on hyvin yksinkertaista. Sinun tarvitsee vain valita, luodaanko usean alueen vai yhden alueen ilmentymä, määritä alue (alueet) ja solmujen lukumäärä. Alle minuutissa instanssi on valmis ja käynnissä.
Useat perustiedot ovat suoraan saatavilla Google-konsolin jakoavainsivulla. Tarkemmat näkymät ovat saatavilla Stackdriverin kautta, jossa voit myös asettaa mittarien kynnysarvoja ja hälytyskäytäntöjä.
Pääsy resursseihin?
MySQL tarjoaa laajat ja erittäin yksityiskohtaiset käyttöoikeus-/rooliasetukset. Voit helposti mukauttaa pääsyä tiettyyn taulukkoon tai jopa vain osaan sen sarakkeista. Cloud Spanner käyttää Google Identity & Access Management (IAM) -työkalua, jonka avulla voit asettaa käytäntöjä ja käyttöoikeuksia vain erittäin korkealle tasolle. Tarkin vaihtoehto on tietokantatason käyttöoikeus, joka ei sovi useimpiin tuotantotapauksiin. Tämä rajoitus pakottaa sinut lisäämään suojaustoimenpiteitä koodiisi, infrastruktuuriisi tai molempiin estääksesi Spnner-resurssien luvattoman käytön.
Varmuuskopiot?
Yksinkertaisesti sanottuna Cloud Spannerissa ei ole varmuuskopioita. Vaikka Googlen korkeat SLA-vaatimukset voivat varmistaa, että et menetä tietoja laitteisto- tai tietokantavikojen, inhimillisten virheiden, sovellusvirheiden jne. vuoksi. Tiedämme kaikki säännön: korkea saatavuus ei korvaa älykästä varmuuskopiointistrategiaa. Tällä hetkellä ainoa tapa varmuuskopioida tiedot on suoratoistaa ne ohjelmallisesti tietokannasta erilliseen tallennusympäristöön.
Kysyn suorituskykyä?
Käytimme Yahoo!a tietojen lataamiseen ja testipyyntöjen lataamiseen. Pilvipalveluvertailu. Alla olevassa taulukossa näkyy B YCSB:n työkuormitus 95 % lukusuhteella 5 % kirjoitussuhteeseen.
* Kuormitustesti suoritettiin n1-standard-32 Compute Engine (CE) -koneella (32 vCPU:ta, 120 Gt muistia), eikä testiinstanssi koskaan ollut testien pullonkaula.
** Yhdessä YCSB-ilmentymässä säikeiden enimmäismäärä on 400. Yhteensä kuusi rinnakkaista YCSB-testien esiintymää piti ajaa, jotta saatiin yhteensä 2400 säiettä.
Tarkasteltaessa benchmark-tuloksia, erityisesti suorittimen kuormituksen ja TPS:n yhdistelmää, voimme selvästi nähdä, että Cloud Spanner skaalautuu melko hyvin. Suuren säikemäärän aiheuttaman suuren kuormituksen kompensoi suuri määrä solmuja Cloud Spanner -klusterissa. Vaikka latenssi näyttää melko korkealta, varsinkin kun ajetaan 2400 säikeellä, saattaa olla tarpeen testata uudelleen kuudella pienemmällä laskentakoneen esiintymällä tarkempien lukujen saamiseksi. Kukin esiintymä suorittaa yhden YCSB-testin yhden suuren CE-ilmentymän sijasta, jossa on 6 rinnakkaista testiä. Tämä helpottaa Cloud Spannerin pyyntöviiveiden ja Cloud Spannerin ja testiä suorittavan CE-esiintymän välisen verkkoyhteyden lisäämien viiveiden erottamista.
Kuinka Cloud Spanner toimii OLAPina?
Osiointi?
Tietojen jakaminen fyysisesti ja/tai loogisesti itsenäisiin segmentteihin, joita kutsutaan osioksi, on erittäin suosittu käsite, joka löytyy useimmista OLAP-koneista. Osiot voivat parantaa huomattavasti kyselyn suorituskykyä ja tietokannan ylläpidettävyyttä. Osiointiin syventäminen olisi erilliset artikkelit, joten mainitaan vain osiointijärjestelmän ja aliosioinnin tärkeys. Mahdollisuus jakaa tiedot osioihin ja vielä edelleen aliosioihin on avainasemassa analyyttisten kyselyiden suorituskyvyn kannalta.
Cloud Spanner ei tue osioita sinänsä. Se erottaa tiedot sisäisesti ns jakaa-s perustuvat ensisijaisen avaimen alueisiin. Osiointi tapahtuu automaattisesti Cloud Spanner -klusterin kuormituksen tasapainottamiseksi. Cloud Spannerin erittäin kätevä ominaisuus on päätaulukon (taulukon, jota ei ole lomitettu toiseen) peruskuorman jakaminen. Kiintoavain havaitsee automaattisesti, sisältääkö se jakaa dataa, jota luetaan useammin kuin muiden jakaa-ah, ja voi päättää uudesta erosta. Siten pyyntöön voi liittyä useampia solmuja, mikä myös tehokkaasti lisää suorituskykyä.
Ladataanko tietoja?
Cloud Spanner -menetelmä joukkotiedoille on sama kuin tavalliselle lataukselle. Parhaan suorituskyvyn saavuttamiseksi sinun on noudatettava joitain ohjeita, mukaan lukien:
- Lajittele tiedot ensisijaisen avaimen mukaan.
- jaa ne 10*solmujen määrä yksittäisiä osia.
- Luo joukko työntekijöiden tehtäviä, jotka lataavat tietoja rinnakkain.
Tämä datalataus käyttää kaikkia Cloud Spanner -solmuja.
Käytimme A YCSB -työkuormaa 10 miljoonan rivin tietojoukon luomiseen.
* Kuormitustesti suoritettiin n1-standard-32 laskentakoneella (32 vCPU:ta, 120 Gt muistia), eikä testiinstanssi koskaan ollut pullonkaula testeissä.
** 1 solmun asennusta ei suositella tuotantotyökuormitukseen.
Kuten edellä mainittiin, Cloud Spanner käsittelee jaot automaattisesti niiden kuormituksesta riippuen, joten tulokset paranevat useiden peräkkäisten testin iteraatioiden jälkeen. Tässä esitetyt tulokset ovat parhaita saamiamme tuloksia. Katsomalla yllä olevia lukuja voimme nähdä, kuinka Cloud Spanner skaalautuu (hyvin) klusterin solmujen määrän kasvaessa. Luvut, jotka erottuvat, ovat erittäin alhaiset keskimääräiset latenssit, mikä on ristiriidassa yllä olevassa osiossa kuvattujen sekatyökuormien (95 % luku ja 5 % kirjoitus) tuloksista.
Skaalaus?
Cloud Spanner -solmujen määrän lisääminen ja vähentäminen on yhden napsautuksen tehtävä. Jos haluat ladata tiedot nopeasti, kannattaa harkita ilmentymän tehostamista maksimiin (meissä tapauksessa se oli 25 solmua US-EAST-alueella) ja sitten vähentää normaaliin kuormituksellesi sopivien solmujen määrää kaikkien tietojen jälkeen. tietokannassa pitäen mielessä 2 TB/solmuraja.
Meitä muistutettiin tästä rajasta jopa paljon pienemmällä tietokannalla. Useiden kuormitustestiajojen jälkeen tietokantamme oli kooltaan noin 155 Gt, ja kun se skaalattiin 1 solmun esiintymään, saimme seuraavan virheilmoituksen:
Pystyimme pienentämään tapausta 25:stä kahteen, mutta olemme jumissa kahdessa solmussa.
Cloud Spanner -klusterin solmujen määrän lisääminen ja vähentäminen voidaan automatisoida REST API:n avulla. Tämä voi olla erityisen hyödyllistä järjestelmän lisääntyneen kuormituksen vähentämiseksi ruuhka-aikoina.
OLAP-kyselyn suorituskyky?
Alun perin suunnittelimme käyttävämme paljon aikaa Spannerin arvioimiseen tältä osin. Muutaman SELECT COUNT -laskun jälkeen tajusimme heti, että testi olisi lyhyt ja että Spanner EI olisi sopiva moottori OLAPille. Riippumatta klusterin solmujen määrästä, yksinkertaisesti rivien lukumäärän valitseminen 10 miljoonan rivin taulukosta kesti 55-60 sekuntia. Myös kaikki kyselyt, jotka vaativat enemmän muistia välitulosten tallentamiseen, epäonnistuivat OOM-virheen vuoksi.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Joitakin numeroita TPC-H-kyselyille löytyy Todd Lipconin artikkelista , diat 42 ja 43. Nämä luvut vastaavat omia tuloksiamme (valitettavasti).
4. Havaintomme
Ottaen huomioon Cloud Spannerin ominaisuuksien nykyinen tila, on vaikea nähdä sitä yksinkertaisena korvaavana olemassa olevalle OLTP-ratkaisulle, varsinkin kun tarpeesi ylittävät sen. Huomattava määrä aikaa joutuisi käyttämään ratkaisun rakentamiseen Cloud Spannerin puutteiden ympärille.
Kun aloitimme Cloud Spannerin arvioinnin, odotimme sen hallintaominaisuuksien olevan samat tai ainakin lähellä muita Google SQL -ratkaisuja. Mutta olimme yllättyneitä varmuuskopioiden täydellisestä puutteesta ja resurssien erittäin rajallisesta kulunvalvonnasta. Puhumattakaan ei näkymistä, ei paikallista kehitysympäristöä, ei-tuettuja sekvenssejä, JDBC:tä ilman DML- ja DDL-tukea ja niin edelleen.
Joten minne mennä henkilölle, joka tarvitsee skaalata tapahtumatietokantaa? Markkinoilla ei näytä vielä olevan yhtä ratkaisua, joka sopisi kaikkiin käyttötapauksiin. On olemassa monia suljetun ja avoimen lähdekoodin ratkaisuja (joista osa on mainittu tässä artikkelissa), jokaisella on omat vahvuutensa ja heikkoutensa, mutta mikään niistä ei tarjoa SaaS-palvelua 99,999 %:n SLA:lla ja korkealla yhdenmukaisuudella. Jos korkea SLA on ensisijainen tavoitteesi etkä ole taipuvainen rakentamaan omaa ratkaisuasi useille pilville, Cloud Spanner saattaa olla etsimäsi ratkaisu. Mutta sinun tulee olla tietoinen kaikista sen rajoituksista.
Ollakseni rehellinen, Cloud Spanner julkaistiin yleisölle vasta keväällä 2017, joten on kohtuullista odottaa, että jotkin sen nykyisistä puutteista saattavat lopulta poistua (toivottavasti), ja kun se poistuu, se voi muuttaa pelin. Loppujen lopuksi Cloud Spanner ei ole vain sivuprojekti Googlelle. Google käyttää sitä muiden Google-tuotteiden perustana. Ja kun Google korvasi äskettäin Google Cloud Storagen Megastoren Cloud Spannerilla, se antoi Google Cloud Storagen tulla erittäin yhdenmukaiseksi globaalissa mittakaavassa oleville objektiluetteloille (mikä ei edelleenkään päde ).
Eli toivoa on vielä... toivomme.
Siinä kaikki. Kuten artikkelin kirjoittaja, myös me edelleen toivomme, mutta mitä mieltä olet tästä? Kirjoita kommentteihin
Kutsumme kaikki käymään meillä jossa kerromme sinulle yksityiskohtaisesti kurssista OTUS:lta.
Lähde: will.com