Silav, niştecîhên Khabrovsk. Wekî her car, em li pêşiya destpêkirina qursên nû parvekirina materyalên balkêş didomînin. Îro, bi taybetî ji bo we, me gotarek di derbarê Google Cloud Spanner de weşand ku bi destpêkirina qursê re hevaheng e. .
Di destpêkê de li .
Wekî pargîdaniyek ku cûrbecûr çareseriyên POS-ê yên ewr pêşkêşî firoşyar, xwaringeh, û firoşkarên serhêl li çaraliyê cîhanê dike, Lightspeed ji bo cûrbecûr dozên karanîna danûstendinê, analîtîk û lêgerînê gelek celeb platformên databasê bikar tîne. Her yek ji van platformên databasê xwedî hêz û qelsiyên xwe ne. Ji ber vê yekê, dema ku Google Cloud Spanner pêşkêşî bazarê kir - taybetmendiyên sozdar ên ku di cîhana databasên pêwendiyê de nayên dîtin, wek pîvazbûna horizontî ya hema hema bêsînor û peymanek asta karûbarê 99,999% (SLA), — me nikarîbû fersendê ji destê xwe berde!
Ji bo ku li ser ezmûna xwe ya bi Cloud Spanner re, û hem jî pîvanên nirxandinê yên ku me bikar anîn, nihêrînek berfireh peyda bikin, em ê mijarên jêrîn vebêjin:
- Pîvanên nirxandina me
- Cloud Spanner bi kurtî
- Nirxandina me
- Encamên me
1. Pîvanên nirxandina me
Berî ku em bikevin nav taybetmendiyên Cloud Spanner, wekhevî û cûdahiyên wê bi çareseriyên din ên li ser sûkê re, em pêşî li ser dozên karanîna sereke yên ku me di hişê xwe de dihesiband bipeyivin dema ku em difikirin ku Cloud Spanner di binesaziya xwe de li ku derê bicîh bikin:
- Wekî şûna çareseriya databasa SQL ya kevneşopî (serdest).
- Meriv çawa bi piştgiriya OLAP re çareseriya OLTP
Têbînî: Ji bo sadebûn û berhevdanê, ev gotar Cloud Spanner bi guhertoyên MySQL yên malbatên çareseriyê yên GCP Cloud SQL û Amazon AWS RDS re berhev dike.
Bikaranîna Cloud Spanner wekî şûna çareseriyek databasa SQL ya kevneşopî
Li hawîrdorê kevneşop databases, dema ku dema bersivê ya lêpirsîna databasê nêzîk dibe an jî ji bendên serîlêdanê yên ji berê diyarkirî derbas dibe (bi piranî ji ber zêdebûna hejmara bikarhêneran û/an daxwazan), çend away hene ku dema bersivê di astên pejirandî de kêm bikin. Lêbelê, piraniya van çareseriyan destwerdana desta pêk tîne.
Mînakî, gava yekem a ku meriv bavêje ev e ku meriv li pîvanên cihêreng ên databasê yên girêdayî performansê binêre û wan bişopîne da ku bi şêwazên doza karanîna serîlêdanê çêtirîn li hev bikin. Heke ev ne bes e, hûn dikarin hilbijêrin ku databasê bi vertîkal an horizontî ve pîvandin.
Pîvana vertîkal a serîlêdanek nûvekirina mînaka serverê vedihewîne, bi gelemperî bi lêzêdekirina bêtir pêvajoker / naverok, bêtir RAM, hilanîna zûtir, hwd. Zêdekirina çavkaniyên hardware dibe sedema zêdekirina performansa databasê, ku di serî de di danûstandinên duyemîn de tê pîvandin, û derengiya danûstendinê ji bo pergalên OLTP. Pergalên databasa pêwendiyê (yên ku nêzîkatiyek pir-mijal bikar tînin) wekî MySQL bi rengek berbi baş dipîve.
Gelek kêmasiyên vê nêzîkbûnê hene, lê ya herî eşkere mezinahiya servera herî zêde ya li sûkê ye. Gava ku sînorê mînaka servera herî mezin gihîştiye, tenê vebijarkek maye: pîvana horizontî.
Pîvana horizontî nêzîkbûnek e ku bêtir pêşkêşker li komekê têne zêdekirin, bi îdeal her ku hejmara serveran lê zêde dibe performansê bi rêzê zêde dike. Pirranî kevneşop Pergalên databasê bi horizontî baş pîva nakin an jî qet pîvan nakin. Mînakî, MySQL dikare bi lêzêdekirina xwendevanên koledar ji bo operasyonên xwendinê pîvaz bike, lê ji bo nivîsandinê nikare horîzontal bipîve.
Ji hêla din ve, ji ber cewhera xwe, Cloud Spanner dikare bi destwerdana hindiktirîn re bi asanî horîzontal bipîve.
Bi tevahî tê xuyang kirin DBMS wekî karûbarek divê ji aliyên cuda ve bên nirxandin. Wekî bingeh, me DBMS-ya herî populer di ewr de girt - ji bo Google, GCP Cloud SQL û ji bo Amazon, AWS RDS. Di nirxandina xwe de me bal kişand ser kategoriyên jêrîn:
- Nexşeya taybetmendiyê: berfirehiya SQL, DDL, DML; pirtûkxaneyên pêwendiyê / girêdan, piştgiriya danûstendinê, û hwd.
- Piştgiriya pêşveçûnê: pêşveçûn û ceribandina hêsan.
- Piştgiriya rêveberiyê: rêveberiya nimûne - mînakî, mezinkirin/kêmkirin û nûvekirina mînakan; SLA, hilanînê û hilanînê; ewlehî / kontrola gihîştinê.
Bikaranîna Cloud Spanner wekî çareseriyek OLTP-ê çalakkirî ya OLAP-ê bikar tîne
Gava ku Google bi eşkere îdîa nake ku Cloud Spanner ji bo pêvajoyek analîtîk hatî sêwirandin, ew hin taybetmendiyan bi motorên din ên wekî Apache Impala & Kudu û YugaByte re parve dike, ku ji bo barkêşên OLAP-ê hatine çêkirin.
Tewra tenê şansek piçûk hebû ku Cloud Spanner motorek HTAP-ê ya domdar (pêvajoya danûstendinê / analîtîkê ya hîbrid) bi komek taybetmendiya OLAP-ê (kêm-kêmtir) bikar bîne, tê de hebe, em difikirin ku ew ê hêjayî bala me be.
Bi vê hişê, me li kategoriyên jêrîn nihêrî:
- Barkirina daneyan, navnîşan û piştgirîya dabeşkirinê
- Performansa Query û DML
2. Cloud Spanner bi kurtî
Google Spanner pergalek rêveberiya databasa têkildar a komkirî ye (RDBMS) ku Google ji bo çend karûbarên xwe bikar tîne. Google di destpêka 2017 de ew bi gelemperî ji bikarhênerên Platforma Google Cloud re peyda kir.
Li vir hin taybetmendiyên Cloud Spanner hene:
- Cluster RDBMS Scalable Pir Lihevhatî: Hevdemkirina dema hardware bikar tîne da ku hevgirtina daneyan bicîh bîne.
- Piştgiriya danûstendina cross-table: Danûstandin dikarin gelek tabloyan bigirin - ne hewce ye ku bi tabloyek yekane sînordar be (berevajî Apache HBase an Apache Kudu).
- Tabloyên bingehîn ên mifteya seretayî: Pêdivî ye ku hemî tablo xwediyê mifteyek bingehîn (PC) be, ku dikare ji gelek stûnên tabloyê pêk were. Daneyên tabloyê di rêza PC-ê de têne hilanîn, ku ew ji bo lêgerîna PC-ê pir bikêr û bilez dike. Mîna pergalên din ên bingehîn ên PC-ê, pêdivî ye ku pêkanîn bi rewşên karanîna pêş-sêwirandî di hişê xwe de were model kirin da ku bigihîje .
- Tabloyên xerîdar: Tablo dikarin bi hevûdu ve girêdayîbûna laşî hebin. Rêzên di tabloya zarokan de dikarin li hember rêzikên di tabloya dêûbav de werin berhev kirin. Ev nêzîkatî lêgerîna têkiliyên ku di qonaxa modelkirina daneyê de têne nas kirin, wek hev-cihkirina xerîdar û fatûreyên wan bileztir dike.
- Indeks: Cloud Spanner indexên duyemîn piştgirî dike. Indeks ji stûnên pêvekirî û hemî stûnên PC-yê pêk tê. Ger bixwaze, index dikare stûnên din ên ne-indekskirî jî hebin. Indeks dikare bi tabloya dêûbav re were girêdan da ku pirsan bileztir bike. Çend sînorkirin li ser îndeksan têne sepandin, wek mînak hejmara herî zêde ya stûnên din ên ku di navnîşan de hatine hilanîn. Di heman demê de, pirsên bi navgîniya navnîşan dibe ku wekî di RDBMS-yên din de ne hêsan bin.
"Cloud Spanner tenê di rewşên kêm de îndekek bixweber hildibijêre. Bi taybetî, Cloud Spanner bixweber navnîşek duyemîn hilnabijêre heke pirsek stûnên ku di nav de nehatine hilanîn bixwaze. ".
- Peymana Asta Xizmetê (SLA): Dabeşkirina li yek herêmek bi SLA% 99,99; bicihkirina pir-herêmî bi 99,999% SLA. Dema ku SLA bi xwe tenê peymanek e û ne garantiyek ji her cûreyî ye, ez bawer dikim ku mirovên li Google hin daneyên dijwar hene ku îdîayek wusa xurt bikin. (Ji bo referansê, 99,999% tê wateya 26,3 çirke nebûna karûbarê mehê.)
- More:
Têbînî: Projeya Apache Tephra piştgiriya danûstendinê ya pêşkeftî li Apache HBase zêde dike (her weha naha di Apache Phoenix de wekî beta jî tête bicîh kirin).
3. Nirxandina me
Ji ber vê yekê, me hemî îdîayên Google-ê di derbarê feydeyên Cloud Spanner-ê de xwendiye - bi rastî pîvana horizontî ya bêsînor di heman demê de ku domdariya bilind û SLA-yek pir bilind diparêze. Her çend ev hewcedarî bi her awayî pir dijwar bin jî, armanca me ne redkirina wan bû. Di şûna wê de, bila em bala xwe bidin ser tiştên din ên ku pir bikarhênerên databasê jê re eleqedar dibin: wekhevî û bikêrhatî.
Me Cloud Spanner wekî şûna Sharded MySQL nirxand
Google Cloud SQL û Amazon AWS RDS, du ji OLTP DBMS-ên herî populer ên di sûkê ewr de, xwedan taybetmendiyên pir mezin in. Lêbelê, ji bo pîvandina van databasan ji mezinahiya yek nodê wêdetir, hûn hewce ne ku dabeşkirina serîlêdanê bikin. Ev nêzîkatî hem ji bo serîlêdan û hem jî ji bo rêveberiyê tevliheviyek din çêdike. Me nihêrî ka Spanner çawa di senaryoya berhevkirina pir şûşeyan de di yek mînakek de cih digire û kîjan taybetmendî (heke hebe) dibe ku hewce bike ku were qurban kirin.
Piştgiriya SQL, DML û DDL, û her weha girêdan û pirtûkxane?
Pêşîn, dema ku bi her databasê re dest pê dike, hûn hewce ne ku modelek daneyê biafirînin. Ger hûn difikirin ku hûn dikarin JDBC Spanner bi amûra xweya bijare ya SQL ve girêdin, hûn ê bibînin ku hûn dikarin daneyên xwe bi wê bipirsin, lê hûn nekarin wê bikar bînin da ku tabloyek biafirînin an biguhezînin (DDL) an jî têxin / nûvekirin / jêbirin. operasyonên (DML). JDBC-ya fermî ya Google-ê yek ji van piştgirî nake.
"Ajoker niha daxuyaniyên DML an DDL piştgirî nakin."
Belgekirina Spanner
Bi konsolê GCP re rewş ne çêtir e - hûn tenê dikarin pirsên SELECT bişînin. Xweşbextane ajokerek JDBC heye ku piştgirîya DML û DDL ji civatê re heye, tevî danûstandinan . Dema ku ev ajokar zehf bikêr e, nebûna ajokera JDBC ya Google-ê ecêb e. Xwezî, Google ji bo pirtûkxaneyên xerîdar (li ser bingeha gRPC) piştgirîyek pir berfireh pêşkêşî dike: C#, Go, Java, node.js, PHP, Python, û Ruby.
Bikaranîna hema hema mecbûrî ya API-yên xwerû yên Cloud Spanner (ji ber nebûna DDL û DML di JDBC de) ji bo qadên kodê yên têkildar ên wekî hewzên girêdanê an çarçoveyên girêdana databasê (mînak Spring MVC) dibe sedema hin sînorkirinan. Bi gelemperî, dema ku JDBC bikar tînin, hûn azad in ku hûn hewza girêdana xweya bijare hilbijêrin (mînak HikariCP, DBCP, C3PO, hwd.) ku tê ceribandin û baş dixebite. Di doza API-yên xwerû yên Spanner de, pêdivî ye ku em xwe bispêrin çarçoweyan / hewzên girêdanê / danişînên ku me xwe afirandine.
Sêwirana navendî ya mifteya bingehîn (PC) dihêle ku Cloud Spanner dema ku bi PC-ê ve digihîje daneyan pir bilez be, lê di heman demê de hin pirsgirêkên pirsê jî destnîşan dike.
- Hûn nikarin nirxa mifteya bingehîn nûve bikin; Pêdivî ye ku hûn pêşî têketinê ji PC-ya orîjînal jêbirin û wê ji nû ve bi nirxa nû ve bişînin. (Ev dişibihe databas/ motorên hilanînê yên din ên PC-yê.)
- Daxuyaniyên UPDATE û DELETE divê PC-ê di WHERE de diyar bikin, ji ber vê yekê nekare hemî daxuyaniyan vala DELETE bihêle - divê her gav pirsek jêrîn hebe, wek nimûne: NAVENDA NÛÇEYAN xxx WHERE id IN (Nasnameya JI tabloya1 Hilbijêre)
- Nebûna vebijarka zêdekirina otomatîkî an tiştek mîna ku rêzika qada PC-yê destnîşan dike. Ji bo ku ev bixebite, divê nirxa têkildar li aliyê serîlêdanê were afirandin.
Indeksên duyemîn?
Google Cloud Spanner ji bo navnîşên duyemîn piştgirî çêkiriye. Ev taybetmendiyek pir xweş e ku her gav di teknolojiyên din de nîn e. Apache Kudu aniha hîç pêdekekên duyemîn piştgirî nake, û Apache HBase rasterast indexan piştgirî nake, lê dikare wan bi navgîniya Apache Phoenix ve zêde bike.
Indeksên li Kudu û HBase dikarin wekî tabloyek veqetandî bi pêkhateyek cihêreng a bişkokên bingehîn ve werin model kirin, lê atomîbûna operasyonên ku li ser tabloya dêûbav û tabloyên pêvek ên têkildar têne kirin divê di asta serîlêdanê de bêne kirin û ne hindik e ku meriv rast bicîh bîne.
Wekî ku di lêkolîna Cloud Spanner de hatî destnîşan kirin, dibe ku navnîşên wê ji navnîşên MySQL cûda bibin. Ji ber vê yekê, dema ku pirs û profîl têne çêkirin, pêdivî ye ku baldariyek taybetî were girtin da ku pê ewle bibe ku li cîhê ku pêdivî ye pêveka rast tê bikar anîn.
Cîgirî?
Tiştek pir populer û bikêrhatî di databasekê de nêrîn e. Ew dikarin ji bo hejmareke mezin ji dozên karanîna kêrhatî bin; du bijareyên min qata abstraction mantiqî û qata ewlehiyê ne. Mixabin, Cloud Spanner piştgirî nade dîtinan. Lêbelê, ev tenê bi qismî me sînor dike ji ber ku di asta stûnê de ji bo destûrên gihîştinê hûrgulî tune ku dîtin dikarin çareseriyek guncan bin.
Ji bo beşa ku li ser kota û qedexeyan hûrgulî dike li belgeya Cloud Spanner binêre (), bi taybetî yek heye ku dikare ji bo hin serîlêdanan pirsgirêk be: Cloud Spanner ji qutikê xwedan sînorek herî zêde 100 databasên her nimûne heye. Eşkere ye, ev dikare ji bo databasek ku ji zêdetirî 100 databasan ve hatî çêkirin, bibe astengiyek mezin. Xwezî, piştî ku bi nûnerê xweya teknîkî ya Google-ê re axivîn, me fêr kir ku ev sînor hema hema hema hema hema hema bi her nirxek bi Piştgiriya Google re zêde dibe.
Piştgiriya pêşveçûnê?
Cloud Spanner ji bo xebata bi API-ya xwe re piştgirîya zimanê bernamenûsê pir maqûl pêşkêşî dike. Pirtûkxaneyên fermî yên piştgirî li deverên C#, Go, Java, node.js, PHP, Python û Ruby hene. Belgekirin pir hûrgulî ye, lê wekî teknolojiyên din ên pêşkeftî, civak li gorî teknolojiyên databasê yên herî populer pir piçûk e, ku dikare bibe sedema bêtir wextê ku ji bo çareserkirina doz an pirsgirêkên karanîna kêm gelemperî derbas dibe.
Ji ber vê yekê piştgiriya pêşveçûna herêmî çi ye?
Me rêyek nedît ku em mînakek Cloud Spanner li hundurê biafirînin. Tiştê herî nêzîk ku me girt wêneyek Docker bû. , ku di prensîbê de wekhev e, lê di pratîkê de pir cuda ye. Mînakî, CockroachDB dikare PostgreSQL JDBC bikar bîne. Ji ber ku hawîrdora pêşkeftinê divê bi qasî ku gengaz nêzikî hawîrdora hilberînê be, Cloud Spanner ne îdeal e ji ber ku pêdivî ye ku ew xwe bispêre mînakek Spanner a tevahî. Ji bo ku lêçûn xilas bikin, hûn dikarin mînakek yek-herêmê hilbijêrin.
Piştgiriya rêveberiyê?
Afirandina mînakek Cloud Spanner pir hêsan e. Hûn tenê hewce ne ku di navbera afirandina mînakek pir-herêm an yek-herêmê de hilbijêrin, herêm(ên) û hejmara girêkan diyar bikin. Di kêmtirî deqeyekê de, mînaka we dê bi rê ve bibe.
Gelek metrîkên bingehîn rasterast ji rûpela Spanner a di Google Console de têne gihîştin. Nêrînên berfirehtir bi navgîniya Stackdriver-ê ve têne peyda kirin, li wir hûn dikarin bendên metrîk û polîtîkayên hişyariyê jî destnîşan bikin.
Gihîştina çavkaniyan?
MySQL ji bo destûrên / rolên bikarhêner mîhengên berfireh û pir guncan pêşkêşî dike. Hûn dikarin bi hêsanî gihîştina tabloyek taybetî, an tewra tenê komek stûnên wê mîheng bikin. Cloud Spanner amûra Nasname û Rêvebiriya Gihîştinê ya Google (IAM) bikar tîne, ku tenê dihêle hûn polîtîka û destûran di astek pir bilind de bicîh bikin. Vebijarka herî gewre çareseriya asta databasê ye, ku di piraniya rewşên karanîna hilberînê de cih nagire. Vê tixûbdarkirinê we neçar dike ku hûn tedbîrên ewlehiyê yên din li kod, binesaziya xwe, an her duyan zêde bikin da ku pêşî li karanîna bêdestûr a çavkaniyên Spanner bigirin.
Backups?
Ji bo ku bi hêsanî were gotin, di Cloud Spanner de paşgir tune. Her çend hewcedariyên bilind ên SLA yên Google dikarin piştrast bikin ku hûn ji ber têkçûna hardware an databasê, xeletiyên mirovî, kêmasiyên serîlêdanê, hwd, tu daneyan winda nekin. Em hemî qaîdeyê dizanin: hebûna bilind ne şûna stratejiyek paşvekêşana deng e. Heya nuha, yekane awayê paşvekêşana daneyê ev e ku meriv wê bi bername ji databasek berbi jîngehek hilanînê veqetîne.
Performansa pirsîn?
Me Yahoo!-ê bikar anî da ku daneyan barkirin û lêpirsînan ceribandin. Cloud Serving Benchmark. Tabloya jêrîn bargiraniya xebata YCSB B bi rêjeya 95% xwendinê heya 5% nivîsandinê nîşan dide.
* Testa barkirinê li ser n1-standard-32 Engine Compute (CE) (32 vCPU, 120 GB bîra) hate xebitandin, û mînaka ceribandinê di ceribandinan de çu carî nebû asteng.
** Di yek nimûneyek YCSB de hejmara herî zêde ya têlan 400 e. Bi tevahî şeş nimûneyên paralel ên testên YCSB-ê diviyabû ku bihata meşandin da ku bi tevahî 2400 mijarên bidest bixin.
Li encamên pîvanê, nemaze tevhevkirina barkirina CPU û TPS-ê mêze dikin, em bi zelalî dikarin bibînin ku Cloud Spanner pir baş dipîve. Barkirina giran a ku ji hêla hejmarek mezin a têlan ve hatî afirandin, ji hêla hejmarek mezin a girêkên di koma Cloud Spanner de tê veqetandin. Digel ku dereng pir zêde xuya dike, nemaze dema ku bi 2400 mijaran tê xebitandin, ji nû ve ceribandina bi 6 mînakên piçûktir ên motora hesabkirinê re dibe ku ji bo bidestxistina hejmarên rastir hewce be. Her mînak dê li şûna yek mînakek mezin a CE bi 6 ceribandinên paralel yek ceribandinek YCSB bimeşîne. Bi vî rengî, ew ê hêsantir be ku meriv di navbera derengiya daxwaza Cloud Spanner û derengiya ku ji hêla pêwendiya torê ya di navbera Cloud Spanner û mînaka CE-ê de ceribandinê dimeşîne de cûda bike.
Cloud Spanner wekî OLAP çawa dixebite?
Parvekirin?
Dabeşkirina daneyan li beşên serbixwe yên fizîkî û/an mentiqî, ku jê re dabeş têne gotin, têgehek pir populer e ku di piraniya motorên OLAP de tê dîtin. Dabeş dikarin bi girîngî performansa pirsê û domandina databasê baştir bikin. Kûrtir çûna nav dabeşkirinê dê gotarek(ên) veqetandî be, ji ber vê yekê em tenê behsa girîngiya hebûna nexşeyek dabeşkirin û dabeşkirinê bikin. Kapasîteya dabeşkirina daneyan li dabeşan û hêj bêtir di binbeşan de ji bo performansa lêpirsîna analîtîk girîng e.
Cloud Spanner bi vî rengî dabeşan piştgirî nake. Ew daneyan di hundurê nav de dabeş dike qelişandin-yên li ser rêzikên sereke yên sereke. Dabeşkirin bixweber tê kirin da ku barkirinê di komek Cloud Spanner de hevseng bike. Taybetmendiyek pir bikêr a Cloud Spanner dabeşkirina barkirina bingehîn a tabloya dêûbav e (tabloyek ku bi yekî din re nayê girêdan). Spanner bixweber destnîşan dike ka ew tê de ye qelişandin daneyên ku ji daneyên din pirtir têne xwendin qelişandin-ah, û dibe ku biryarê li ser veqetandina bêtir bide. Bi vî rengî, bêtir girêk dikarin di daxwazek de beşdar bibin, ku ev jî bi bandor karûbar zêde dike.
Daneyên barkirin?
Rêbaza Cloud Spanner ji bo daneya girseyî wekî barkirina normal e. Ji bo ku hûn performansa herî zêde bigihîjin, hûn hewce ne ku hin rêbazan bişopînin, di nav de:
- Daneyên xwe li gorî mifteya bingehîn rêz bikin.
- Wan bi 10 dabeş bikin *hejmara girêkan beşên cuda.
- Komek peywirên xebatê yên ku daneyan paralel bar dikin biafirînin.
Vê barkirina daneyê hemî girêkên Cloud Spanner bikar tîne.
Me bargiraniya xebata YCSB A bikar anî da ku danûstendinek ji 10M rêzan çêbike.
* Testa barkirinê li ser motora hesabkirinê ya n1-standard-32 (32 vCPU, 120 GB bîra) hate xebitandin, û mînaka ceribandinê di ceribandinan de çu carî nebû asteng.
** Sazkirina girêkek yekane ji bo ti xebata hilberînê nayê pêşniyar kirin.
Wekî ku li jor hatî behs kirin, Cloud Spanner bixweber dabeşan li ser bingeha barkirina wan pêvajoyê dike, ji ber vê yekê encam piştî çend dubareyên ceribandinê yên li pey hev çêtir dibin. Encamên ku li vir têne pêşkêş kirin encamên çêtirîn ên ku me bi dest xistine. Dema ku li hejmarên li jor dinêrin, em dikarin bibînin ku Cloud Spanner çawa mezin dibe (baş) her ku hejmara girêkên di komê de zêde dibe. Hejmarên ku diyar dibin derengiya navînî ya pir kêm in, ku bi encamên ji bo barkêşên kar ên tevlihev (95% xwendin û 5% nivîsandin) ku di beşa li jor de hatî destnîşan kirin berevajî dikin.
Scaling?
Zêdekirin û kêmkirina hejmara girêkên Cloud Spanner karek yek-klîk e. Ger hûn dixwazin daneyan zû bar bikin, dibe ku hûn bifikirin ku mînaka xwe herî zêde zêde bikin (di rewşa me de ew li herêma DY-ROJHILATA 25 nod bû) û dûv re gava ku hemî dane tê de jimareya girêkên ku ji bo barkirina weya normal guncan in kêm bikin. databas, ku behsa sînorê 2TB/nodê dike.
Digel databasek pir piçûktir jî ev sînor hate bîra me. Piştî çend ceribandinên barkirinê, databasa me bi qasî 155 GB mezin bû, û dema ku bi mînakek 1 nodê hate pîvandin, me xeletiya jêrîn wergirt:
Me karî ku ji 25-an dakêşin 2 mînakan, lê em li du xalan asê man.
Zêdekirin û kêmkirina hejmara girêkan di komek Cloud Spanner de dikare bi karanîna API-ya REST-ê were otomatîk kirin. Ev dikare bi taybetî ji bo kêmkirina barkirina pergalê ya zêde di dema demjimêrên xebata mijûl de kêrhatî be.
Performansa pirsên OLAP?
Me di destpêkê de plan kir ku di nirxandina xwe ya Spanner de li ser vê beşê de demek girîng derbas bikin. Piştî çend HILBIJARTINAN, me tavilê fêhm kir ku ceribandin dê kurt be û ku Spanner dê ji bo OLAP-ê NE motorek guncan be. Tevî hejmara girêkên di komê de, bi tenê hilbijartina hejmara rêzan di tabloyek rêzek 10M de di navbera 55 û 60 saniyeyan de girt. Wekî din, her pirsek ku ji bo hilanîna encamên navîn bêtir bîranîn hewce dike bi xeletiyek OOM têk çû.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Hin hejmar ji bo pirsên TPC-H di gotara Todd Lipcon de têne dîtin , slaytên 42 û 43. Ev jimar bi encamên me re hevaheng in (mixabin).
4. Encamên me
Ji ber rewşa heyî ya taybetmendiyên Cloud Spanner, dijwar e ku meriv xeyal bike ku ew ji bo çareseriya weya OLTP-ya heyî veguhezek hêsan e, nemaze dema ku hewcedariyên we jê mezintir bibin. Pêdivî ye ku demek girîng ji bo avakirina çareseriyek li dora kêmasiyên Cloud Spanner were xerc kirin.
Dema ku me dest bi nirxandina Cloud Spanner kir, me li bendê bû ku taybetmendiyên rêveberiya wê bi çareseriyên din ên Google SQL re, an bi kêmanî ne pir dûr be. Lê em ji kêmbûna tevahî paşgiran û kontrola pir tixûbdar a li ser gihîştina çavkaniyan ecêbmayî man. Ne ku bê dîtin, ne hawîrdora pêşkeftina herêmî, rêzikên bê piştgirî, JDBC bêyî DML û DDL piştgirî, û hwd.
Ji ber vê yekê kesê ku hewce dike ku databasek danûstendinê pîvan bike, diçe ku derê? Wusa dixuye ku li sûkê çareseriyek yekane tune ku li gorî hemî rewşên karanîna guncan be. Gelek çareseriyên çavkaniya girtî û vekirî hene (hin ji wan di vê gotarê de têne behs kirin), her yek bi hêz û qelsiyên xwe hene, lê yek ji wan SaaS bi 99,999% SLA û domdariya bilind peyda nake. Ger SLA-ya bilind armanca weya sereke ye û hûn ne mêldar in ku çareseriyek pir-ewra xwerû ava bikin, dibe ku Cloud Spanner çareseriya ku hûn lê digerin be. Lê divê hûn ji hemî sînorên wê haydar bin.
Dadperwer be, Cloud Spanner tenê di bihara 2017-an de ji raya giştî re hate berdan, ji ber vê yekê maqûl e ku meriv li bendê be ku hin kêmasiyên wê yên heyî di dawiyê de ji holê rabin (hêvîdarim), û gava ku ew bikin, ew dikare bibe guhezkerek lîstikê. Beriya her tiştî, Cloud Spanner ji bo Google ne tenê projeyek alî ye. Google wê wekî bingehek ji bo hilberên din ên Google bikar tîne. Û dema ku Google di van demên dawî de Megastore di Google Cloud Storage de bi Cloud Spanner veguherand, wê hişt ku Google Cloud Storage ji bo navnîşên tiştan li ser asta gerdûnî pir lihevhatî bibe (ku hîn jî ji bo ).
Ji ber vê yekê hê jî hêviyek heye... em hêvî dikin.
Navê pêger. Mîna nivîskarê gotarê, em jî hêvî dikin, lê hûn li ser vê yekê çi difikirin? Di şîroveyan de binivîsin
Em bang li her kesî dikin ku biçin serdana me di nav de em ê di derheqê qursê de bi berfirehî ji we re vebêjin ji OTUS.
Source: www.habr.com