DBA bot Joe. Anatoly Stansler (Postgres.ai)

Pêşvebirek paşverû çawa fam dike ku pirsek SQL dê li ser "prod"ek baş bixebite? Di pargîdaniyên mezin an ku bi lez mezin dibin, her kes bigihîje "hilberê". Û bi gihîştinê re, ne hemî daxwazî ​​​​ dikarin bê êş bêne kontrol kirin, û çêkirina kopiyek databasê bi gelemperî demjimêran digire. Ji bo çareserkirina van pirsgirêkan, me DBA çêkirî - Joe. Ew jixwe di gelek pargîdaniyan de bi serfirazî hate bicîh kirin û ji dehan zêdetir pêşdebiran dibe alîkar.

Video:

Silav hemû! Navê min Anatoly Stansler e. Ez ji bo şirketekê dixebitim postgres.ai. Em bi rakirina derengiyên ku bi xebata Postgres re ji pêşdebiran, DBA û QA-yê ve girêdayî ne, pêbawer in ku pêvajoya pêşkeftinê bilezînin.

Xerîdarên me yên mezin hene û îro beşek ji raporê dê ji dozên ku me dema ku bi wan re dixebitin re were veqetandin. Ez ê bipeyivim ka me çawa alîkariya wan kir ku pirsgirêkên pir giran çareser bikin.

Dema ku em koçberiyên tevlîhev ên bi bargiraniyê pêş dixin û dikin, em vê pirsê ji xwe dikin: "Gelo ev koçberî wê derkeve?". Em vekolînê bikar tînin, em zanîna hevkarên bi tecrube, pisporên DBA bikar tînin. Û ew dikarin bibêjin ka ew ê bifire an na.

Lê belkî çêtir be ku em bikarin wê xwe li ser kopiyên mezinahiyê biceribînin. Û îro em ê tenê bipeyivin ka nêzîkatiyên ceribandinê naha çi ne û ew çawa dikare çêtir û bi kîjan amûran were kirin. Em ê her weha li ser erênî û neyînîyên nêzîkatiyên weha bipeyivin, û tiştê ku em dikarin li vir rast bikin.

Kê çu carî rasterast li ser prod index çêkir an jî guhertinek çêkir? Pir hindik. Û ji bo kê ev bû sedema rastiya ku dane winda bûne an jî demdirêj hene? Wê demê hûn vê êşê dizanin. Şikir ji Xwedê re piştgir hene.

Rêbaza yekem ceribandina li prod. An jî, gava ku pêşdebirek li ser makîneyek herêmî rûdine, daneyên ceribandinê yên wî hene, celebek bijartek tixûbdar heye. Û em ji bo pêşkeftinê derdixin, û em vê rewşê digirin.

Diêşe, biha ye. Belkî çêtir e ku neyê.

Û awayê çêtirîn ku meriv wê bike çi ye?

Werin em li wê derê qonax bikin û hin beşek prod hilbijêrin. An jî ya herî baş, bila em hilberek rastîn, hemî daneyan bigirin. Û piştî ku me ew li herêmî pêşve xist, em ê ji bo qonaxkirinê jî kontrol bikin.

Ev ê bihêle ku em hin xeletiyan rakin, ango rê li ber girtina wan bigire.

Pirsgirêk çi ne?

• Pirsgirêk ev e ku em vê sehneyê bi hevalên xwe re parve dikin. Û pir caran ew diqewime ku hûn celebek guhartinê bikin, bam - û dane tune, kar li ser çolê ye. Staging pir-terabyte bû. Û divê hûn demek dirêj li bendê bimînin ku ew dîsa rabe. Û em biryar didin ku sibe wê bi dawî bikin. Ew e, pêşveçûnek me heye.
• Û, bê guman, gelek hevkarên me li wir dixebitin, gelek tîm hene. Û divê ew bi destan were kirin. Û ev nerehet e.

Û hêjayî gotinê ye ku tenê hewldanek me heye, yek guleyek, ger em bixwazin hin guhertinan li databasê bikin, daneyan bi dest bixin, strukturê biguherînin. Û heke tiştek xelet derket, heke di koçberiyê de xeletiyek hebû, wê hingê em ê zû paşde neçin.

Ev ji nêzîkatiya berê çêtir e, lê hîn jî îhtîmalek mezin heye ku celebek xeletî derkeve hilberînê.

Çi rê li me digire ku em ji her pêşdebiran re qonaxek ceribandinê, kopiyek tevahî mezinahî bidin? Ez difikirim ku ew eşkere ye ku çi di rê de dibe.

Kî xwedî databasek ji terabyte mezintir e? Zêdetir ji nîvê odeyê.

Û eşkere ye ku girtina makîneyên ji bo her pêşdebiran, dema ku hilberek wusa mezin hebe, pir biha ye, û ji bilî vê, ew demek dirêj digire.

Xerîdarên me hene ku fêm kirine ku ceribandina hemî guhertinan li ser kopiyên mezinahî pir girîng e, lê databasa wan ji terabyte kêmtir e, û çavkanî tune ku ji bo her pêşdebiran qonaxek ceribandinê bihêle. Ji ber vê yekê, ew neçar in ku topan li cîhê makîneya xwe dakêşin û bi vî rengî ceribandin. Gelek wext digire.

Ger hûn wiya di hundurê binesaziyê de bikin jî, wê hingê dakêşana yek terabyte daneyê di saetekê de jixwe pir baş e. Lê ew avêtinên mentiqî bikar tînin, ew herêmî ji ewr dakêşînin. Ji bo wan, leza nêzîkî 200 gigabytes di saetekê de ye. Û hîn jî dem hewce dike ku meriv ji qulika mentiqî bizivire, îndeksan hilde û hwd.

Lê ew vê nêzîkatiyê bikar tînin ji ber ku ew dihêle ku ew pêbawer bihêlin.

Em dikarin li vir çi bikin? Werin em bendên ceribandinê erzan bikin û her pêşdebiran bengeha ceribandinê ya xwe bidin.

Û ev gengaz e.

Û di vê nêzîkbûnê de, gava ku em ji bo her pêşdebirker klonên zirav çêdikin, em dikarin wê li ser yek makîneyê parve bikin. Mînakî, heke we danegehek 10TB heye û hûn dixwazin wê bidin 10 pêşdebiran, ne hewce ye ku hûn databasên XNUMX x XNUMXTB hebin. Ji we re tenê yek makîneyek hewce ye ku ji bo her pêşdebirek ku yek makîneyek bikar tîne kopiyên veqetandî yên tenik çêbikin. Ez ê ji we re bibêjim ka ew hinekî paşê çawa dixebite.

Mînakek rastîn:

• DB - 4,5 terabytes.

• Em dikarin di 30 çirkeyan de kopiyên serbixwe bistînin.

Hûn ne hewce ne ku li benda ceribandinek ceribandinê bisekinin û li ser çiqas mezin e ve girêdayî bin. Hûn dikarin wê di nav hûrdeman de bistînin. Ew ê derdorên bi tevahî veqetandî bin, lê yên ku daneyan di nav xwe de parve dikin.

Ev mezin e. Li vir em behsa sêrbaz û gerdûnek paralel dikin.

Di doza me de, ev bi karanîna pergala OpenZFS dixebite.

OpenZFS pergalek pelê kopî-li-nivîsandinê ye ku wêne û klonên ji qutiyê piştgirî dike. Ew pêbawer û pîvan e. Birêvebirina wê pir hêsan e. Ew bi rastî dikare di du tîman de were bicîh kirin.

Vebijarkên din hene:

• lvm,

• Storage (mînak, Pure Storage).

Labê Database ya ku ez behs dikim modular e. Bi karanîna van vebijarkan dikare were bicîh kirin. Lê aniha, me bala xwe daye OpenZFS, ji ber ku bi taybetî bi LVM re pirsgirêk hebûn.

Çawa dixebite? Li şûna ku em her carê ku daneyan diguhezînin ji nû ve binivîsin, em bi tenê nîşankirina ku ev daneya nû ji xalek nû ye, wêneyek nû ye, hildibijêrin.

Û di pêşerojê de, gava ku em dixwazin paşde vegerin an jî em dixwazin ji hin guhertoyek kevntir klonek nû çêbikin, em tenê dibêjin: "Temam, van blokên daneya ku bi vî rengî hatine nîşankirin bidin me."

Û ev bikarhêner dê bi komek daneya weha re bixebite. Ew ê hêdî hêdî wan biguherîne, dîmenên xwe çêbike.

Û em ê şax bikin. Di doza me de her pêşdebir dê xwedî fersendek be ku klona xwe ya ku ew diguherîne hebe, û daneyên ku têne parve kirin dê di navbera her kesî de bêne parve kirin.

Ji bo ku hûn pergalek wusa li malê bicîh bikin, hûn hewce ne ku du pirsgirêkan çareser bikin:

• Ya yekem çavkaniya daneyan e, ku hûn ê ji ku derê bigirin. Hûn dikarin bi hilberînê re dubarekirinê saz bikin. Hûn dikarin jixwe paşvekêşên ku we mîheng kirine bikar bînin, ez hêvî dikim. WAL-E, WAL-G an Barman. Tewra heke hûn cûreyek çareseriya Cloud-ê mîna RDS an Cloud SQL bikar tînin, wê hingê hûn dikarin dupên mentiqî bikar bînin. Lê em dîsa jî ji we re şîret dikin ku hûn paşvekêşan bikar bînin, ji ber ku bi vê nêzîkbûnê hûn ê di heman demê de strukturên laşî yên pelan jî biparêzin, ku dê bihêle hûn hê bêtir nêzikî metrîkên ku hûn ê di hilberînê de bibînin bin da ku hûn wan pirsgirêkên ku hene bigirin.

• Ya duyemîn ew e ku hûn dixwazin Lab Database mêvandar bikin. Dibe ku ew Cloud be, ew dikare bibe On-premise. Li vir girîng e ku meriv bêje ku ZFS berhevkirina daneyê piştgirî dike. Û ew pir baş dike.

Bifikirin ku ji bo her klonek wusa, li gorî operasyonên ku em bi bingehê re dikin, dê celebek dev mezin bibe. Ji bo vê, dev jî cîhê hewce dike. Lê ji ber ku me bingehek ji 4,5 terabyte girt, ZFS dê wê bi 3,5 terabyte ve bişewitîne. Ev dikare li gorî mîhengan diguhere. Û hê jî cîhê me ji bo dev heye.

Pergalek weha dikare ji bo rewşên cûda were bikar anîn.

• Van pêşdebiran, DBA-yên ji bo erêkirina pirsê, ji bo xweşbîniyê ne.

• Ev dikare di ceribandina QA-yê de were bikar anîn da ku koçberiyek taybetî biceribîne berî ku em wê ji bo hilberînê derxînin. Û em dikarin ji bo QA-yê jîngehên taybetî bi daneyên rastîn raber bikin, ku ew dikarin fonksiyonên nû ceribandin. Û ew ê li şûna demjimêrên li bendê saniyeyan bigire, û dibe ku di hin rewşên din de jî çend rojan bigire ku kopiyên zirav nayên bikar anîn.

• Û rewşeke din. Ger pargîdanî pergalek analîtîk saz neke, wê hingê em dikarin klonek zirav a bingeha hilberê veqetînin û wê bidin pirsên dirêj an navnîşên taybetî yên ku dikarin di analîtîk de werin bikar anîn.

Bi vê nêzîkatiyê:

1. Ihtimalek kêm a xeletiyên li ser "prod"ê, ji ber ku me hemî guheztin li ser daneyên tev-mezin ceriband.

2. Çandek me ya ceribandinê heye, ji ber ku naha hûn ne hewce ne ku hûn bi saetan li benda standina xwe bisekinin.

3. Û di navbera ceribandinan de astengî tune, bendewariyek tune. Hûn dikarin bi rastî biçin û kontrol bikin. Û ew ê bi vî rengî çêtir be gava ku em pêşveçûnê bilezînin.

• Dê refaktor kêm bibe. Kêmtir xeletî dê di prod bi dawî bibin. Em ê paşê wan kêm bikin.

• Em dikarin guhertinên bêveger berevajî bikin. Ev ne nêzîkatiya standard e.

1. Ev bikêr e ji ber ku em çavkaniyên beşên ceribandinê parve dikin.

Jixwe baş e, lê wekî din çi dikare were bilez kirin?

Bi saya pergalek wusa, em dikarin berdêla ketina ceribandinek wusa pir kêm bikin.

Naha dorhêlek xirab heye ku li wir pêşdebirek pêdivî ye ku bibe pispor da ku bigihîje daneyên rastîn ên mezin. Divê pêbaweriya wî bi gihîştinek weha were.

Lê heke ne li wir be meriv çawa mezin dibe. Lê heke hûn tenê komek daneya testê ya pir piçûk ji we re peyda bibin çi? Wê hingê hûn ê ezmûnek rastîn nestînin.

Meriv çawa ji vê çemberê derkeve? Wekî pêwendiya yekem, ji bo pêşdebirên her astê rehet, me bota Slack hilbijart. Lê ew dikare navberek din be.

Ew destûrê dide te ku hûn çi bikin? Hûn dikarin pirsek taybetî bistînin û wê ji kanalek taybetî ya databasê re bişînin. Em ê bixweber di nav çirkeyan de klonek tenik bi cih bikin. Werin em vê daxwazê ​​bimeşînin. Em pîvan û pêşniyaran berhev dikin. Werin em dîmenek nîşan bidin. Û wê hingê ev klone dê bimîne da ku ev pirs bi rengek xweş were xweş kirin, navnîşan lê zêde bike, hwd.

Û her weha Slack ji me re fersendên hevkariyê ji qutiyê re dide. Ji ber ku ev tenê kanalek e, hûn dikarin ji bo daxwazek wusa li wir dest bi nîqaşkirina vê daxwazê ​​bikin, hevkarên xwe, DBA-yên ku di hundurê pargîdaniyê de ne ping bikin.

Lê bê guman, pirsgirêk hene. Ji ber ku ev cîhana rastîn e, û em serverek ku bi yekcarî gelek klonan mêvandar dike bikar tînin, neçar in ku mîqdara bîr û hêza CPU ya ku ji klonan re peyda dibe teng bikin.

Lê ji bo ku ev ceribandin maqûl bin, hûn hewce ne ku bi rengekî vê pirsgirêkê çareser bikin.

Diyar e ku xala girîng heman dane ye. Lê jixwe me heye. Û em dixwazin heman veavakirinê bi dest bixin. Û em dikarin bi vî rengî veavakirina hema hema eynî bidin.

Dê xweş be ku meriv heman hardware wekî di hilberînê de hebe, lê dibe ku ew cûda be.

Werin em bînin bîra xwe ka Postgres çawa bi bîranînê re dixebite. Du kelûpelên me hene. Yek ji pergala pelan û yek Postgres ya xwecî, ango Keşeya Buffer a Parvekirî.

Girîng e ku bala xwe bidinê ku dema Postgres dest pê dike, Cache Buffer Shared tê veqetandin, li gorî ku hûn di veavakirinê de çi pîvanê diyar dikin.

Û cache duyemîn hemî cîhê berdest bikar tîne.

Û gava ku em li ser yek makîneyek çend klonan çêdikin, derdikeve holê ku em hêdî hêdî bîranînê tijî dikin. Û bi awayekî baş, Shared Buffer Cache 25% ji tevahiya bîranîna ku li ser makîneyê heye ye.

Û derket holê ku ger em vê parametreyê neguhezînin, wê hingê em ê karibin tenê 4 mînakan li ser yek makîneyek bimeşînin, ango 4 ji hemî klonên wusa nazik. Û ev, bê guman, xirab e, ji ber ku em dixwazin ji wan pir zêde hebin.

Lê ji aliyek din ve, Buffer Cache ji bo pêkanîna lêpirsînan ji bo indexan tê bikar anîn, ango, plan girêdayî ye ka kaşên me çiqasî mezin in. Û heger em tenê vê pîvanê bigirin û wê kêm bikin, wê hingê planên me dikarin pir biguhezînin.

Mînakî, heke me cacheyek mezin li ser prod hebe, wê hingê Postgres tercîh dike ku pêdekek bikar bîne. Û heke ne, wê hingê dê SeqScan hebe. Û eger planên me li hev nekin dê çi be?

Lê li vir em gihîştin wê encamê ku di rastiyê de plana li Postgres ne bi mezinahiya taybetî ya ku di planê de di Tampona Parvekirî de hatî destnîşan kirin ve girêdayî ye, ew bi bandor_cache_size ve girêdayî ye.

Effective_cache_size mîqdara texmînkirî ya cache ye ku ji me re peyda dibe, ango berhevoka Cacheya Buffer û cacheya pergala pelan. Ev ji hêla mîhengê ve hatî danîn. Û ev bîr nayê veqetandin.

Û ji ber vê parametreyê, em dikarin bi rengekî Postgres bixapînin, û bibêjin ku em bi rastî gelek daneyên berdest hene, hetta ku me ev dane tune be. Û bi vî awayî, plan dê bi tevahî bi hilberînê re hev bikin.

Lê ev dikare bandorê li demê bike. Û em pirsan ji hêla demê ve xweşbîn dikin, lê girîng e ku dem bi gelek faktoran ve girêdayî ye:

• Ew bi barkirina ku niha li ser prod ye ve girêdayî ye.

• Ew bi taybetmendiyên makîneyê bixwe ve girêdayî ye.

Û ev parametreyek nerasterast e, lê di rastiyê de em dikarin tam li gorî mêjera daneya ku dê ev pirs bixwîne xweşbîn bikin da ku encamê bistînin.

Û heke hûn dixwazin ku dem nêzik be ya ku em ê di hilberînê de bibînin, wê hingê pêdivî ye ku em hardware-ya herî dişibin hev bigirin û, belkî, hê bêtir jî ji bo ku hemî klon li hev bikin. Lê ev lihevkirinek e, ango hûn ê heman planan bistînin, hûn ê bibînin ka pirsek taybetî dê çend daneyan bixwîne û hûn ê karibin encam bidin ka ev pirs baş e (an koçberî) an xirab e, ew hîn jî pêdivî ye ku were xweş kirin .

Ka em binihêrin ka Joe çawa bi taybetî xweşbîn e.

Ka em daxwazek ji pergalek rastîn bigirin. Di vê rewşê de, databas 1 terabyte ye. Û em dixwazin hejmara postên nû yên ku ji 10 hezkiriyan zêdetir bûne bijmêrin.

Em ji kanalê re peyamek dinivîsin, ji bo me klonek hatiye danîn. Û em ê bibînin ku daxwazek wusa dê di 2,5 hûrdeman de biqede. Ev yekem tişt e ku em bala xwe didin.

B Joe dê li ser bingeha plan û pîvanan pêşniyarên otomatîkî nîşanî we bide.

Em ê bibînin ku pirs pir daneyê pêvajoyê dike da ku hejmareke piçûk a rêzan bigire. Û cûreyek pêdekek pispor hewce ye, ji ber ku me dît ku di pirsê de pir rêzikên parzûnkirî hene.

Werin em ji nêzîk ve li çi qewimî. Bi rastî, em dibînin ku me hema hema yek û nîv gigabayt daneya ji cache pelê an jî ji dîskê xwendiye. Û ev ne baş e, ji ber ku me tenê 142 rêz girtin.

Û, wusa dixuye, me li vir şanek îndeksê heye û diviyabû zû bihata xebitandin, lê ji ber ku me pir rêzik fîltre kir (diviya bû ku em wan bijmêrin), daxwaz hêdî hêdî pêk hat.

Û ev di planê de çêbû ji ber ku şert û mercên di lêpirsînê de û şert û mercên di îndeksê de bi qismî li hev nakin.

Werin em hewl bidin ku pêvekê rastirtir bikin û bibînin ka piştî wê çawa pêkanîna pirsê diguhere.

Afirandina îndeksê demek pir dirêj girt, lê naha em lêpirsînê kontrol dikin û dibînin ku dem li şûna 2,5 hûrdem tenê 156 milî çirkeyan e, ku têra xwe baş e. Û em tenê 6 megabytes daneyê dixwînin.

Û naha em tenê îskana îndeksê bikar tînin.

Çîrokek din a girîng jî ev e ku em dixwazin planê bi rengek têgihîştî pêşkêş bikin. Me dîtbarî bi karanîna Grafên Flame pêk aniye.

Ev daxwazeke cuda ye, tundtir e. Û em Grafên Flameyê li gorî du pîvanan ava dikin: ev mîqdara daneyê ye ku girêkek taybetî di plan û wextê de jimartin, ango dema pêkanîna girêkê.

Li vir em dikarin girêkên taybetî bi hevûdu re bidin ber hev. Û ew ê diyar bibe ka kîjan ji wan pirtir an hindiktir digire, ku bi gelemperî di awayên din ên vegotinê de dijwar e.

Bê guman, her kes dizane şirove.depesz.com. Taybetmendiyek baş a vê dîtbariyê ev e ku em plansaziya nivîsê hilînin û di heman demê de hin pîvanên bingehîn jî têxin tabloyekê da ku em bikarin rêz bikin.

Û pêşdebirên ku hîna di vê mijarê de derneketine jî şirove.depesz.com bikar tînin, ji ber ku ji wan re hêsantir e ku fêm bikin ka kîjan metrîk girîng in û kîjan ne.

Nêzîkatiyek nû ya dîtbariyê heye - ev e şirove.dalibo.com. Ew dîmenek darê dikin, lê pir dijwar e ku meriv girêkan bi hevûdu re bide berhev. Li vir hûn dikarin strukturê baş fam bikin, lêbelê, heke daxwazek mezin hebe, wê hingê hûn ê hewce bikin ku paş û paş ve bigerin, lê di heman demê de vebijarkek jî.

hevkarî

Û, wekî min got, Slack fersendê dide me ku em hevkariyê bikin. Mînakî, heke em rastî pirsek tevlihev a ku ne diyar e meriv çawa xweşbîn bike, werin, em dikarin vê pirsgirêkê bi hevkarên xwe re di mijarek di Slack de zelal bikin.

Ji me re xuya dike ku girîng e ku meriv li ser daneyên tevahî-mezin ceribandin. Ji bo vê yekê, me amûra Nûvekirina Database Lab çêkir, ku di çavkaniya vekirî de heye. Hûn dikarin botê Joe jî bikar bînin. Hûn dikarin wê niha bigirin û li cîhê xwe bicîh bikin. Hemû rêber li wir hene.

Di heman demê de girîng e ku were zanîn ku çareserî bixwe ne şoreşger e, ji ber ku Delphix heye, lê ew çareseriyek pargîdanî ye. Bi tevahî girtî ye, pir biha ye. Em bi taybetî di Postgres de pispor in. Ev hemî hilberên çavkaniya vekirî ne. Tevlî me bibin!

Li vir ez diqede. Sipas ji were!

Pirsên

Slav! Spas ji bo raporê! Pir balkêş e, nemaze ji min re, ji ber ku min demek berê heman pirsgirêk çareser kir. Û ji ber vê yekê çend pirsên min hene. Bi hêviya ku ez ê bi kêmanî beşek jê bistînim.

Ez meraq dikim hûn çawa cîhê vê jîngehê hesab dikin? Teknolojî tê vê wateyê ku di bin hin mercan de, klonên we dikarin bi mezinahiya herî zêde mezin bibin. Bi gelemperî, heke we databasek deh terabyte û 10 klon hene, wê hingê hêsan e ku meriv rewşek ku her klonek 10 daneyên bêhempa giran dike simule bike. Hûn vê cîhê, ango wê deltaya ku we qala wê kir, ku dê ev klonên tê de bijîn, çawa hesab dikin?

Pirsa baş. Girîng e ku meriv li vir klonên taybetî bişopîne. Û heke kloneek guheztinek pir mezin hebe, ew dest bi mezinbûnê dike, wê hingê em dikarin pêşî li ser vê yekê hişyariyek ji bikarhêner re bidin, an tavilê vê klonê rawestînin da ku em nebin rewşek têkçûyî.

Erê, pirsek min a hêlîn heye. Ango, hûn çerxa jiyanê ya van modulan çawa piştrast dikin? Me ev pirsgirêk û çîrokek tevahî cûda heye. Ev çawa dibe?

Ji bo her klonek hinek ttl heye. Di bingeh de, me ttlyek sabît heye.

Çi, eger ne veşartî?

1 saet, ango bêkar - 1 saet. Ger neyê bikaranîn, wê hingê em lê dixin. Lê li vir surprîz tune, ji ber ku em dikarin klonê di çirkeyan de bilind bikin. Û heke hûn dîsa hewce ne, hingê ji kerema xwe.

Ez di hilbijartina teknolojiyê de jî eleqedar im, ji ber ku, mînakî, em ji ber sedemek an yekê din çend rêbazan bi paralelî bikar tînin. Çima ZFS? Çima we LVM bikar neanî? We behs kir ku bi LVM re pirsgirêk hebûn. Pirsgirêk çi bûn? Bi dîtina min, di warê performansê de vebijarka herî çêtirîn bi hilanînê ye.

Pirsgirêka sereke ya ZFS çi ye? Rastiya ku divê hûn li ser heman mêvandar bixebitin, ango hemî mînak dê di heman OS-ê de bijîn. Û di mijara hilanînê de, hûn dikarin amûrên cihêreng ve girêdin. Û tengahî tenê ew blokên ku li ser pergala hilanînê ne. Û pirsa hilbijartina teknolojiyên balkêş e. Çima ne LVM?

Bi taybetî, em dikarin di civînê de LVM-ê nîqaş bikin. Di derbarê hilanînê de - ew tenê biha ye. Em dikarin pergala ZFS li her deverê bicîh bikin. Hûn dikarin wê li ser makîneya xwe bicîh bikin. Hûn dikarin bi tenê depoyê dakêşin û wê bicîh bikin. Heke em li ser Linux dipeyivin ZFS hema hema li her deverê tête saz kirin. Ango em çareseriyek pir nerm bi dest dixin. Û ZFS bi xwe gelek ji qutîkê dide. Hûn dikarin bi qasî ku hûn dixwazin daneyan bar bikin, hejmareke mezin dîskê girêdin, dîmen hene. Û, wek ku min got, ew hêsan e ku birêvebirin. Ango, karanîna wê pir xweş xuya dike. Ew tê ceribandin, ew gelek salî ye. Ew civakek pir mezin heye ku mezin dibe. ZFS çareseriyek pir pêbawer e.

Nikolai Samokhvalov: Ez dikarim bêtir şîrove bikim? Navê min Nikolay e, em bi Anatoly re dixebitin. Ez razî me ku hilanînê pir mezin e. Û hin xerîdarên me xwedî Storage Pure hwd.

Anatoly rast destnîşan kir ku em li ser modularîteyê disekinin. Û di pêşerojê de, hûn dikarin yek navberê bicîh bikin - wêneyek bikişîne, klonek çêbike, klonê hilweşîne. Hemî hêsan e. Û hilanînê cool e, eger ew.

Lê ZFS ji her kesî re heye. DelPhix jixwe bes e, 300 xerîdarên wan hene. Ji van, fortune 100 50 xerîdar hene, ango ew NASA-yê armanc dikin, hwd. Wext e ku her kes vê teknolojiyê bi dest bixe. Û ji ber vê yekê me çavkaniyek vekirî Core heye. Parçeyek pêwendiya me heye ku ne çavkaniyek vekirî ye. Ev platforma ku em ê nîşan bidin ev e. Lê em dixwazin ku ew bigihêje her kesî. Em dixwazin şoreşek çêkin da ku hemî ceribandinvan dev ji texmînkirina li ser laptopan berdin. Divê em SELECT binivîsin û tavilê bibînin ku ew hêdî ye. Li bendê nemînin ku DBA ji we re li ser wê bêje. Li vir armanca sereke ye. Û ez difikirim ku em ê hemî li ser vê yekê werin. Û em vê yekê ji bo her kesî dikin. Ji ber vê yekê ZFS, ji ber ku ew ê li her derê peyda bibe. Spas ji civakê re ji bo çareserkirina pirsgirêkan û ji bo ku destûrnameyek çavkaniyek vekirî heye, hwd.*

Silav! Spas ji bo raporê! Navê min Maxim e. Me bi heman pirsgirêkan re mijûl kir. Wan bi xwe biryar da. Hûn çavkaniyên di navbera van klonan de çawa parve dikin? Her klonek dikare di her kêliyê de tiştê xwe bike: yek tiştek diceribîne, yê din yekî din, kesek indexek çêdike, kesek xwedî karekî giran e. Û heger hûn hîn jî dikarin bi CPU-ê veqetînin, paşê bi IO-ê, hûn çawa çawa dabeş dikin? Ev pirsa yekem e.

Û pirsa duyem li ser cudabûna standan e. Ka em bibêjin min li vir ZFS heye û her tişt xweş e, lê xerîdar li ser prod ne ZFS, lê ext4, mînakî. Di vê rewşê de çawa?

Pirs pir baş in. Min ev pirsgirêk hinekî bi rastiya ku em çavkaniyan parve dikin vegot. Û çareserî ev e. Bifikirin ku hûn li ser sehneyê ceribandinê dikin. Hûn dikarin di heman demê de rewşek wusa jî hebe ku kesek barekî dide, yekî din. Û wekî encamek, hûn metrîkên nefêmkirî dibînin. Tewra heman pirsgirêk dikare bi prod re be. Gava ku hûn dixwazin hin daxwazek kontrol bikin û bibînin ku bi wê re pirsgirêkek heye - ew hêdî dixebite, wê hingê di rastiyê de pirsgirêk ne di daxwazê ​​de bû, lê di rastiyê de ku celebek barkirina paralel heye.

Û ji ber vê yekê, li vir girîng e ku meriv balê bikişîne ser ka dê plan çi be, em ê di plansaziyê de çi gavan bavêjin û ji bo vê yekê em ê çiqas daneyan berhev bikin. Rastiya ku dîskên me, mînakî, dê bi tiştek re bêne barkirin, ew ê bi taybetî bandorê li demê bike. Lê em dikarin texmîn bikin ka ev daxwaz bi hêjmara daneyê çiqas barkirî ye. Ew qas ne girîng e ku di heman demê de celebek darvekirinê jî hebe.

Du pirsên min hene. Ev tişt pir xweş e. Ma rewş hene ku daneyên hilberînê krîtîk e, wekî hejmarên qerta krediyê? Jixwe tiştek amade ye an ew karekî cuda ye? Û pirsa duyemîn - ji bo MySQL tiştek wusa heye?

Der barê daneyan. Heta ku em nebin em ê talankirinê bikin. Lê heke hûn tam Joe bicîh bikin, heke hûn gihêştina pêşdebiran nedin, wê hingê gihîştina daneyê tune. Çima? Ji ber ku Joe daneyan nîşan nade. Ew tenê metrîkan, planan nîşan dide û ew e. Ev bi mebest hate kirin, ji ber ku ev yek ji daxwazên muwekîlê me ye. Wan dixwest ku bêyî ku herkesî bigihînin hev optîmîze bikin.

Der barê MySQL. Ev pergal dikare ji bo her tiştê ku dewletê li ser dîskê hilîne were bikar anîn. Û ji ber ku em Postgres dikin, em naha yekem ji bo Postgres hemî otomasyonê dikin. Em dixwazin wergirtina daneyan ji hilanînê otomatîk bikin. Em Postgres rast mîheng dikin. Em dizanin ka meriv çawa planan li hev dikin, hwd.

Lê ji ber ku pergal berfirehtir e, ew dikare ji bo MySQL jî were bikar anîn. Û mînakên wiha hene. Yandex tiştek bi vî rengî heye, lê ew li cîhek belav nakin. Ew di hundurê Yandex.Metrica de bikar tînin. Û tenê çîrokek li ser MySQL heye. Lê teknolojî yek in, ZFS.

Spas ji bo raporê! Çend pirsên min jî hene. We behs kir ku klonkirin dikare ji bo analîtîkan were bikar anîn, mînakî ji bo avakirina pêvekên din li wir. Hûn dikarin hinekî bêtir li ser ka ew çawa dixebite vebêjin?

Û ez ê tavilê pirsa duyemîn li ser wekheviya standan, wekheviya planan bikim. Plan jî bi statîstîkên ku ji hêla Postgres ve hatî berhev kirin ve girêdayî ye. Hûn vê pirsgirêkê çawa çareser dikin?

Li gorî analîtîkan tu rewşên taybetî tune, ji ber ku me heta niha bikar neaniye, lê derfetek wiha heye. Ger em li ser indexan dipeyivin, wê hingê bifikire ku pirsek li tabloyek bi sed mîlyon tomar û stûnek ku bi gelemperî di prod-ê de nayê navnîş kirin dişopîne. Û em dixwazin li wir hin daneyan hesab bikin. Ger ev daxwaz ji prod re were şandin, wê hingê îhtîmalek heye ku ew ê li ser prod sade be, ji ber ku daxwaz dê deqeyek li wir were xebitandin.

Ok, werin em klonek zirav çêbikin ku ne tirsnak e ku meriv çend hûrdem rawestîne. Û ji bo ku em xwendina analîtîk rehettir bikin, em ê ji bo wan stûnên ku em tê de daneyan eleqedar in nîşanan lê zêde bikin.

Indeks dê her carê were afirandin?

Hûn dikarin wiya bikin ku em daneyan bi dest bixin, wêneyan çêkin, wê hingê em ê ji vê wêneyê xelas bikin û daxwazên nû bişopînin. Ango, hûn dikarin wiya bikin ku hûn dikarin klonên nû bi nîşaneyên ku ji berê ve hatine pêvekirin bilind bikin.

Di derbarê pirsa di derbarê statîstîkê de, heke em ji paşvekişandinê vegerînin, ger em dubare bikin, wê hingê statîstîkên me dê tam eynî bin. Ji ber ku tevahiya avahiya daneya laşî ya me heye, ango, em ê bi hemî pîvanên statîstîkî re jî daneyan wekî ku ne bînin.

Li vir pirsgirêkek din heye. Ger hûn çareseriyek ewr bikar bînin, wê hingê tenê avêtinên mentiqî li wir hene, ji ber ku Google, Amazon nahêlin hûn kopiyek laşî bistînin. Dê pirsgirêk derkeve.

Spas ji bo raporê. Li vir du pirsên baş di derbarê MySQL û parvekirina çavkaniyê de hebûn. Lê, bi rastî, ew hemî tê vê rastiyê ku ev ne mijarek DBMS-ya taybetî ye, lê pergala pelê bi tevahî ye. Û, li gorî vê yekê, pirsgirêkên parvekirina çavkaniyê jî divê ji wir were çareser kirin, ne di dawiyê de ku ew Postgres e, lê di pergala pelan de, di serverê de, mînakî.

Pirsa min hinekî cuda ye. Ew nêzîkî databasa pir-qatî ye, ku li wir çend qat hene. Mînakî, me nûvekirinek wêneyek deh-terabyte saz kir, em dubare dikin. Û em bi taybetî vê çareseriyê ji bo databases bikar tînin. Replicasyon di pêş de ye, dane têne nûve kirin. Li vir 100 xebatkarên paralel dixebitin û her tim van fîşekên cuda didin destpêkirin. Çi bikim? Meriv çawa pê ewle dibe ku nakokî tune, ku wan yek dest pê kir, û dûv re pergala pelan guherî, û ev wêne hemî çûn?

Ew ê neçin ji ber ku ZFS bi vî rengî dixebite. Em dikarin guhertinên pergala pelan ên ku ji ber dubarekirinê têne veqetandin di yek mijarê de bihêlin. Û klonên ku pêşdebiran li ser guhertoyên kevntir ên daneyê bikar tînin biparêzin. Û ew ji bo me dixebite, her tişt bi vê yekê re ye.

Derket holê ku nûvekirin dê wekî qatek pêvek pêk were, û hemî wêneyên nû dê berê xwe bidin, li ser bingeha vê qatê, rast?

Ji qatên berê yên ku ji dubareyên berê bûn.

Dê qatên berê hilweşin, lê ew ê behsa qata kevn bikin, û gelo ew ê ji qata paşîn a ku di nûvekirinê de hatî wergirtin wêneyên nû bistînin?

Bi gelemperî, erê.

Dûv re di encamê de em ê heya hejîrek qatan hebin. Û bi demê re ew ê hewce bibin ku bêne çewisandin?

Erê her tişt rast e. Hin pencereyek heye. Em hefteyî dîmenên wêneyan digirin. Ew bi kîjan çavkaniya we ve girêdayî ye. Ger we şiyana hilanîna gelek daneyan hebe, hûn dikarin wêneyan ji bo demek dirêj hilînin. Ew ê bi serê xwe neçin. Dê xirabiya daneyan tune be. Ger wêneyan kevnar bin, wekî ku ji me re xuya dike, ango ew bi polîtîkaya pargîdaniyê ve girêdayî ye, wê hingê em dikarin bi hêsanî wan jêbirin û cîh azad bikin.

Silav, spas ji bo raporê! Pirs li ser Joe. We got ku xerîdar nexwest ku her kes bigihîje daneyan. Bi hişkî dipeyivin, ger kesek encama Explain Analyze hebe, wê hingê ew dikare daneyan bişopîne.

Wisa ye. Mînakî, em dikarin binivîsin: "E-name JI KU JI KU BIJÎN = wê". Ango em ê daneyan bixwe nebînin, lê em dikarin hin nîşanên nerasterast bibînin. Divê ev bê fêmkirin. Lê ji aliyê din ve, her tişt li wir e. Kontrola me ya têketinê heye, kontrola me ya hevkarên din heye ku ew jî dibînin ku pêşdebir çi dikin. Û eger kesek hewl bide vê yekê bike, wê demê dezgeha ewlehiyê dê were cem wan û li ser vê mijarê bixebite.

Paş nîvro Spas ji bo raporê! Pirseke min a kurt heye. Ger pargîdanî Slack bikar neyîne, gelo naha pêwendiyek bi wê re heye, an ma gengaz e ku pêşdebiran mînakan bicîh bikin da ku serîlêdanek ceribandinê bi databasan ve girêdin?

Naha girêdanek bi Slack re heye, ango peyamnêrek din tune, lê ez bi rastî dixwazim ji bo peyamnêrên din jî piştgirî bikim. Tu dikarî çi bikî? Hûn dikarin DB Lab bêyî Joe bicîh bikin, bi alîkariya REST API an bi alîkariya platforma me biçin û klonan biafirînin û bi PSQL-ê ve girêbidin. Lê ev dikare were kirin heke hûn amade ne ku pêşdebirên xwe bigihînin daneyan, ji ber ku êdî dê ekranek tune be.

Hewcedariya min bi vê qatê nîne, lê ji min re derfetek wiha heye.

Wê hingê erê, ew dikare were kirin.

Source: www.habr.com