DBA bot Joe. Anatoly Stansler (Postgres.ai)

Nola ulertzen du backend garatzaile batek SQL kontsulta batek ondo funtzionatuko duela "prod" batean? Enpresa handietan edo azkar hazten direnetan, denek ez dute "produktua" sarbidea. Eta sarbidearekin, eskaera guztiak ezin dira minik gabe egiaztatu, eta datu-basearen kopia bat sortzeak askotan orduak behar ditu. Arazo hauek konpontzeko, DBA artifizial bat sortu dugu - Joe. Dagoeneko hainbat enpresatan arrakastaz inplementatu da eta dozena bat garatzaile baino gehiago laguntzen ditu.

Video:

Kaixo guztioi! Nire izena Anatoly Stansler da. Enpresa batean lan egiten dut postgres.ai. Garapen-prozesua bizkortzeko konpromisoa hartu dugu Postgresen lanarekin lotutako atzerapenak garatzaileei, DBAei eta QAei kenduta.

Bezero bikainak ditugu eta gaur txostenaren zati bat beraiekin lan egitean ezagutu ditugun kasuei eskainiko zaie. Nahiko arazo larriak konpontzen nola lagundu genien hitz egingo dut.

Karga handiko migrazio konplexuak garatzen eta egiten ari garenean, galdera hau egiten diogu geure buruari: "Migrazio hau aireratuko al da?". Berrikuspena erabiltzen dugu, esperientziadun lankideen ezagutza erabiltzen dugu, DBA adituak. Eta hegan egingo duen ala ez esan dezakete.

Baina agian hobe litzateke guk geuk probatu ahal izango bagenu tamaina osoko kopietan. Eta gaur probak egiteko planteamenduak zein diren eta nola egin daitekeen hobeto eta zein tresnarekin hitz egingo dugu. Horrelako planteamenduen alde onak eta txarrak ere hitz egingo dugu, eta hemen konpondu dezakeguna.

Nork egin ditu indizeak zuzenean produktuan edo aldaketarik egin? Nahiko. Eta horrek nori ekarri zion datuak galtzea edo geldialdi-denbora egotea? Orduan ezagutzen duzu min hau. Jainkoari eskerrak babeskopiak daude.

Lehenengo ikuspegia prod-en probatzea da. Edo, garatzaile bat tokiko makina batean esertzen denean, proba-datuak baditu, aukeraketa mugatu bat dago. Eta bultzatzera ateratzen gara, eta egoera hau lortzen dugu.

Min egiten du, garestia da. Seguruenik hobe da ez egitea.

Eta zein da egiteko modurik onena?

Har dezagun eszenaratzea eta hauta dezagun hor produktuaren zatiren bat. Edo, onenean, har ditzagun benetako prod bat, datu guztiak. Eta lokalean garatu ondoren, eszenaratzea ere egiaztatuko dugu.

Horrek akats batzuk kentzeko aukera emango digu, hau da, prod-ean egotea saihestuko dugu.

Zeintzuk dira arazoak?

• Arazoa da eszenaratze hori lankideekin partekatzen dugula. Eta askotan gertatzen da aldaketaren bat egiten duzula, bam - eta ez dago daturik, lana hondoan dago. Eszenaratzea terabyte anitzekoa zen. Eta denbora luzez itxaron behar duzu berriro igotzeko. Eta bihar amaitzea erabakitzen dugu. Hori da, garapen bat dugu.
• Eta, noski, lankide asko ditugu bertan lanean, talde asko. Eta eskuz egin behar da. Eta hau deserosoa da.

Eta esan beharra dago saiakera bakarra dugula, jaurtiketa bakarra, datu-basean aldaketa batzuk egin nahi baditugu, datuak ukitu, egitura aldatu. Eta zerbait gaizki joan bada, migrazioan akats bat egon bada, ez dugu azkar atzera egingo.

Hau aurreko ikuspegia baino hobea da, baina oraindik ere probabilitate handia dago akatsen bat produkziora joateko.

Zerk eragozten digu garatzaile bakoitzari proba-banku bat, tamaina osoko kopia bat ematea? Uste dut argi dagoela zer oztopatzen duen.

Nork du datu-base bat terabyte bat baino handiagoa? Gelaren erdia baino gehiago.

Eta argi dago garatzaile bakoitzarentzako makinak mantentzea, hain produkzio handia dagoenean, oso garestia dela, eta gainera, denbora asko behar dela.

Tamaina osoko kopietan aldaketa guztiak probatzea oso garrantzitsua dela konturatu diren bezeroak ditugu, baina haien datu-basea terabyte bat baino txikiagoa da, eta ez dago baliabiderik garatzaile bakoitzarentzat proba-banku bat mantentzeko. Hori dela eta, zabortegiak lokalean deskargatu behar dituzte euren makinan eta modu honetan probatu. Denbora asko behar da.

Nahiz eta azpiegituraren barruan egin, orduan terabyte bat orduko datu deskargatzea oso ona da dagoeneko. Baina zabortegi logikoak erabiltzen dituzte, hodeitik lokalean deskargatzen dute. Haientzat, abiadura orduko 200 gigabyte ingurukoa da. Eta oraindik denbora behar da zabortegi logikotik buelta emateko, indizeak biltzeko, etab.

Baina ikuspegi hori erabiltzen dute produktua fidagarria mantentzeko aukera ematen duelako.

Zer egin dezakegu hemen? Egin ditzagun proba-bankuak merkeak eta eman diezaiogun garatzaile bakoitzari bere proba-bankua.

Eta hau posible da.

Eta ikuspegi honetan, garatzaile bakoitzarentzat klon meheak egiten ditugunean, makina batean parteka ditzakegu. Adibidez, 10TBko datu-base bat baduzu eta 10 garatzaileri eman nahi badiozu, ez duzu XNUMX x XNUMXTB datu-baserik izan behar. Makina bakarra behar duzu garatzaile bakoitzeko kopia mehe isolatuak egiteko makina bat erabiliz. Geroxeago esango dizut nola funtzionatzen duen.

Benetako adibidea:

• DB - 4,5 terabyte.

• 30 segundotan kopia independenteak lor ditzakegu.

Ez duzu proba-postu baten zain egon beharrik eta zenbaterainokoa den araberakoa. segundotan lor dezakezu. Ingurune guztiz isolatuak izango dira, baina euren artean datuak partekatzen dituztenak.

Hau ona da. Hemen magiaz eta unibertso paraleloaz ari gara.

Gure kasuan, honek OpenZFS sistema erabiliz funtzionatzen du.

OpenZFS kopia-idazketako fitxategi-sistema bat da, instantáneak eta klonak kutxatik kanpo onartzen dituena. Fidagarria eta eskalagarria da. Kudeatzeko oso erraza da. Literalki bi taldetan zabaldu daiteke.

Beste aukera batzuk daude:

• lvm,

• Biltegiratzea (adibidez, Pure Storage).

Hitz egiten ari naizen Database Lab modularra da. Aukera hauek erabiliz inplementa daiteke. Baina oraingoz, OpenZFS-en zentratu gara, LVMrekin bereziki arazoak izan zirelako.

Nola dabil? Aldatzen ditugun bakoitzean datuak gainidatzi beharrean, datu berri hauek denbora-puntu berri batekoak direla markatuz gordetzen ditugu, argazki berri bat.

Eta etorkizunean, atzera egin nahi dugunean edo bertsio zaharrago batetik klon berri bat egin nahi dugunean, besterik ez dugu esaten: "Ados, eman iezaguzu honela markatuta dauden datu-bloke hauek".

Eta erabiltzaile honek horrelako datu multzo batekin lan egingo du. Pixkanaka aldatuko ditu, bere argazkiak egingo ditu.

Eta adarkatu egingo dugu. Gure kasuan garatzaile bakoitzak editatzen duen bere klona izateko aukera izango du, eta partekatzen diren datuak guztion artean partekatuko dira.

Horrelako sistema bat etxean zabaltzeko, bi arazo konpondu behar dituzu:

• Lehenengoa datuen iturria da, nondik hartuko duzun. Erreplikazioa ekoizpenarekin konfigura dezakezu. Konfiguratu dituzun babeskopiak dagoeneko erabil ditzakezu, espero dut. WAL-E, WAL-G edo Barman. Eta RDS edo Cloud SQL bezalako Hodei irtenbideren bat erabiltzen ari bazara ere, iraulketa logikoak erabil ditzakezu. Baina hala ere, babeskopiak erabiltzea gomendatzen dizugu, ikuspegi honekin fitxategien egitura fisikoa ere mantenduko duzulako, eta horrek produkzioan ikusiko zenituzkeen metriketatik are gertuago egotea ahalbidetuko dizu, dauden arazo horiek harrapatzeko.

• Bigarrena Datu-basearen laborategia ostatu hartu nahi duzun tokia da. Hodeia izan daiteke, On-premisea izan daiteke. Garrantzitsua da hemen esatea ZFS-k datuen konpresioa onartzen duela. Eta nahiko ondo egiten du.

Imajinatu horrelako klon bakoitzeko, oinarriarekin egiten ditugun eragiketen arabera, garapen motaren bat haziko dela. Horretarako, garatzaileak lekua ere beharko du. Baina 4,5 terabyte-ko oinarria hartu dugulako, ZFS-k 3,5 terabyte-ra konprimituko du. Hau alda daiteke ezarpenen arabera. Eta garatzaileentzako lekua dugu oraindik.

Horrelako sistema bat kasu desberdinetarako erabil daiteke.

• Hauek garatzaileak dira, kontsultak baliozkotzeko DBAak, optimizatzeko.

• Hau QA probetan erabil daiteke migrazio jakin bat probatzeko, produktura zabaldu aurretik. Eta QA-rako ingurune bereziak ere sor ditzakegu datu errealekin, non funtzionaltasun berriak probatu ditzaketen. Eta itxaron orduen ordez segundoak beharko dira, eta agian egunak beharko dira kopia meheak erabiltzen ez diren beste kasu batzuetan.

• Eta beste kasu bat. Konpainiak ez badu sistema analitikorik konfiguratuta, produktuaren oinarriaren klon fin bat isolatu eta analitikan erabil daitezkeen kontsulta luzeei edo indize bereziei eman diezaiekegu.

Planteamendu honekin:

1. "Prod"-an erroreak izateko probabilitate txikia, aldaketa guztiak tamaina osoko datuetan probatu ditugulako.

2. Probak egiteko kultura dugu, orain ez duzulako ordurik itxaron behar zure standerako.

3. Eta ez dago oztoporik, ez dago proben artean itxaroterik. Egia esan, joan eta egiaztatu dezakezu. Eta hobe izango da horrela garapena bizkortu ahala.

• Refactoring gutxiago izango da. Akats gutxiago prod amaituko da. Gutxiago birfaktorizatuko ditugu geroago.

• Atzeraezinak diren aldaketak itzul ditzakegu. Hau ez da ikuspegi estandarra.

1. Hau onuragarria da proba-bankuen baliabideak partekatzen ditugulako.

Dagoeneko ondo, baina zer gehiago bizkortu liteke?

Horrelako sistema bati esker, proba horietan sartzeko atalasea asko murriztu dezakegu.

Orain gurpil zoro bat dago non garatzaile batek aditua izan behar duen tamaina osoko datu errealetarako sarbidea izateko. Sarbide hori fidatu behar da.

Baina nola hazi ez badago. Baina zer gertatzen da proba-datu multzo txiki bat besterik ez baduzu eskura? Orduan ez duzu benetako esperientziarik lortuko.

Nola atera zirkulu honetatik? Lehen interfaze gisa, edozein mailatako garatzaileentzako erosoa, Slack bot aukeratu genuen. Baina beste edozein interfaze izan daiteke.

Zer egiteko aukera ematen dizu? Kontsulta zehatz bat hartu eta datu-baserako kanal berezi batera bidali dezakezu. Klon mehe bat automatikoki zabalduko dugu segundotan. Egin dezagun eskaera hau. Neurri eta gomendioak biltzen ditugu. Erakutsi dezagun bistaratze bat. Eta gero klon hau geratuko da, kontsulta hau nolabait optimizatu ahal izateko, indizeak gehitzeko, etab.

Eta, gainera, Slack-ek elkarlanerako aukerak ematen dizkigu. Hau kanal bat besterik ez denez, eskaera hau eztabaidatzen has zaitezke eskaera horren harian bertan, egin ping zure lankideei, enpresa barruan dauden DBAei.

Baina badira, noski, arazoak. Hau mundu erreala denez, eta zerbitzari bat erabiltzen ari garenez aldi berean klon asko biltzen dituena, klonek eskuragarri duten memoria eta CPU potentzia kopurua konprimitu behar dugu.

Baina proba hauek sinesgarriak izan daitezen, arazo hau nolabait konpondu behar duzu.

Garrantzitsuena datu bera dela argi dago. Baina dagoeneko badugu. Eta konfigurazio bera lortu nahi dugu. Eta halako konfigurazio ia berdina eman dezakegu.

Ederra litzateke ekoizpenean dagoen hardware bera izatea, baina desberdina izan daiteke.

Gogora dezagun nola funtzionatzen duen Postgresek memoriarekin. Bi cache ditugu. Fitxategi-sistemako bat eta Postgres jatorrizko bat, hau da, Buffer Cache partekatua.

Garrantzitsua da ohartzea Buffer partekatua Postgres abiaraztean esleitzen dela, konfigurazioan zehazten duzun tamainaren arabera.

Eta bigarren cacheak erabilgarri dagoen espazio guztia erabiltzen du.

Eta makina batean hainbat klon egiten ditugunean, apurka-apurka memoria betetzen ari garela gertatzen da. Eta modu onean, Shared Buffer Cache makinan eskuragarri dagoen memoria-kopuru osoaren % 25 da.

Eta ematen du parametro hau aldatzen ez badugu, 4 instantzia bakarrik exekutatu ahal izango ditugula makina batean, hau da, klon mehe horietako 4 guztira. Eta hori, noski, txarra da, askoz gehiago eduki nahi ditugulako.

Baina, bestalde, Buffer Cache indizeen kontsultak exekutatzeko erabiltzen da, hau da, plana gure cacheak zenbaterainokoak diren araberakoa da. Eta parametro hau hartu eta murrizten badugu, gure planak asko alda daitezke.

Adibidez, prod-en cache handia badugu, Postgres-ek nahiago izango du indize bat erabiltzea. Eta ez bada, SeqScan egongo da. Eta zertarako balioko luke gure planak bat etorriko ez balira?

Baina hemen ondorioztatzen dugu Postgres-en plana ez dela planeko Buffer Partekatuan zehaztutako tamaina espezifikoaren araberakoa, effective_cache_size-aren araberakoa dela.

Effective_cache_size eskuragarri dugun cache-kopuru estimatua da, hau da, Buffer Cache-ren eta fitxategi-sistemaren cachearen batura. Hau konfigurazioak ezartzen du. Eta memoria hori ez dago esleituta.

Eta parametro hau dela eta, Postgres-ek engainatu egin dezakegu, benetan datu asko ditugula eskuragarri esanez, nahiz eta datu horiek ez izan. Eta horrela, planak guztiz bat egingo dute ekoizpenarekin.

Baina horrek denboran eragina izan dezake. Kontsultak denboraren arabera optimizatzen ditugu, baina garrantzitsua da denbora faktore askoren araberakoa izatea:

• Gaur egun produktuan dagoen kargaren araberakoa da.

• Makinaren beraren ezaugarrien araberakoa da.

Eta zeharkako parametro bat da, baina egia esan kontsulta honek irakurriko duen datu kopuruaren arabera optimizatu dezakegu emaitza lortzeko.

Eta denborak prod-en ikusiko dugunetik hurbil egotea nahi baduzu, orduan hardware antzekoena hartu behar dugu eta, beharbada, are gehiago klon guztiak egoki daitezen. Baina hau konpromisoa da, hau da, plan berdinak lortuko dituzu, kontsulta jakin batek zenbat datu irakurriko duen ikusiko duzu eta kontsulta hau ona (edo migrazioa) edo txarra den ondorioztatu ahal izango duzu, oraindik optimizatu behar da. .

Ikus dezagun Joe zehazki nola optimizatu den.

Har dezagun eskaera bat benetako sistema batetik. Kasu honetan, datu-basea terabyte-koa da. Eta 1 atsegin baino gehiago izan dituzten argitalpen freskoen kopurua zenbatu nahi dugu.

Mezu bat idazten ari gara kanalari, klon bat zabaldu zaigu. Eta ikusiko dugu eskaera hori 2,5 minututan osatuko dela. Hau da nabaritzen dugun lehenengo gauza.

B Joe-k gomendio automatikoak erakutsiko dizkizu planean eta metriketan oinarrituta.

Ikusiko dugu kontsultak datu gehiegi prozesatzen dituela errenkada kopuru nahiko txikia lortzeko. Eta nolabaiteko indize espezializatu bat behar da, kontsultan iragazitako errenkada gehiegi daudela ohartu baikara.

Ikus dezagun gertutik zer gertatu den. Izan ere, ikusten dugu ia gigabyte eta erdiko datu irakurri ditugula fitxategien cachetik edo baita diskotik ere. Eta hau ez da ona, 142 lerro bakarrik lortu ditugulako.

Eta, badirudi, hemen indize-eskaneatze bat daukagu ​​eta azkar funtzionatu beharko genuke, baina lerro gehiegi iragazi genituenez (kontatu behar izan genituen), eskaera poliki-poliki funtzionatu zuen.

Eta hori planean gertatu zen, kontsultako baldintzak eta indizeko baldintzak partzialki bat ez datozelako.

Saia gaitezen indizea zehatzagoa egiten eta ikus dezagun nola aldatzen den kontsultaren exekuzioa horren ondoren.

Indizea sortzeak denbora nahiko luzea izan du, baina orain kontsulta egiaztatu eta 2,5 minuturen ordez denbora 156 milisegundo baino ez dela ikusten dugu, eta hori nahikoa da. Eta 6 megabyteko datuak soilik irakurtzen ditugu.

Eta orain indizea soilik eskaneatzea erabiltzen dugu.

Beste istorio garrantzitsu bat da plana modu ulergarriago batean aurkeztu nahi dugula. Flame Graphs erabiliz bistaratzea ezarri dugu.

Beste eskaera bat da hau, biziagoa. Eta Flame Graphs bi parametroren arabera eraikitzen ditugu: nodo jakin batek planoan eta denboran zenbatu dituen datu kopurua da, hau da, nodoaren exekuzio denbora.

Hemen nodo zehatzak elkarren artean aldera ditzakegu. Eta argi geratuko da horietako zeinek hartzen duen gehiago edo gutxiago, eta hori normalean zaila da beste errendatze metodo batzuetan egitea.

Jakina, denek daki explica.depesz.com. Bistaratze honen ezaugarri ona da testu-plana gordetzen dugula eta oinarrizko parametro batzuk taula batean jartzen ditugula ordenatu ahal izateko.

Eta gai honetan oraindik sakondu ez duten garatzaileek ere explain.depesz.com erabiltzen dute, errazagoa zaielako zein neurketa diren garrantzitsuak eta zein ez.

Ikuspegi berri bat dago bistaratzeko - hau explic.dalibo.com da. Zuhaitz bistaratzea egiten dute, baina oso zaila da nodoak elkarren artean alderatzea. Hemen egitura ondo uler dezakezu, hala ere, eskaera handi bat badago, atzera eta aurrera joan beharko duzu, baina baita aukera bat ere.

lankidetza

Eta, esan bezala, Slack-ek elkarlanean aritzeko aukera ematen digu. Esaterako, nola optimizatu argi ez duen kontsulta konplexu batekin topo egiten badugu, gure lankideekin arazo hau argitu dezakegu Slack-eko hari batean.

Tamaina osoko datuetan probatzea garrantzitsua dela iruditzen zaigu. Horretarako, Update Database Lab tresna egin dugu, kode irekian eskuragarri dagoena. Joe bot-a ere erabil dezakezu. Oraintxe bertan hartu eta zure lekuan ezar dezakezu. Gida guztiak eskuragarri daude bertan.

Garrantzitsua da, gainera, konponbidea bera ez dela iraultzailea, Delphix dagoelako, baina enpresa irtenbide bat da. Erabat itxita dago, oso garestia da. Postgres-en bereziki espezializatuta gaude. Hauek guztiak kode irekiko produktuak dira. Batu zaitez!

Hemen amaitzen naiz. Eskerrik asko!

Zure galderak

Kaixo! Eskerrik asko erreportajeagatik! Oso interesgarria, batez ere niretzat, duela denbora pixka bat arazo bera konpondu nuelako. Eta, beraz, galdera ugari ditut. Zorionez, zati bat behintzat lortuko dudala.

Galdetzen dut nola kalkulatzen duzu ingurune honen lekua? Teknologiak esan nahi du egoera jakin batzuetan zure klonak tamaina maximoraino hazi daitezkeela. Gutxi gorabehera, hamar terabyte datu-base bat eta 10 klon badituzu, orduan erraza da klon bakoitzak 10 datu bakar pisatzen dituen egoera simulatzea. Nola kalkulatzen duzu klon hauek biziko diren leku hori, hau da, hitz egin zenuen delta hori?

Galdera ona. Garrantzitsua da hemen klon zehatzen jarraipena egitea. Eta kloni batek aldaketa handiegia badu, hazten hasten da, orduan erabiltzaileari abisua eman diezaiokegu honi buruz, edo berehala gelditu klona hori, huts-egoerarik izan ez dezagun.

Bai, galdera habiaratu bat daukat. Hau da, nola ziurtatzen duzu modulu horien bizi-zikloa? Arazo hau eta istorio oso bat dugu. Nola gertatzen da hau?

Klon bakoitzeko ttl batzuk daude. Funtsean, ttl finkoa dugu.

Zer, sekretua ez bada?

Ordu 1, hau da, inaktibo - ordu 1. Erabiltzen ez bada, jotzen dugu. Baina hemen ez dago harritzekoa, segundotan klona igo dezakegulako. Eta berriro behar baduzu, mesedez.

Teknologien aukeraketa ere interesatzen zait, zeren, adibidez, hainbat metodo paralelo erabiltzen ditugu arrazoi bategatik edo besteagatik. Zergatik ZFS? Zergatik ez duzu LVM erabili? LVMrekin arazoak izan zirela aipatu duzu. Zeintzuk izan ziren arazoak? Nire ustez, aukerarik egokiena biltegiratzea da, errendimenduari dagokionez.

Zein da ZFS-ren arazo nagusia? Ostalari berean exekutatu behar duzula, hau da, instantzia guztiak OS berean biziko dira. Eta biltegiratzeko kasuan, ekipamendu desberdinak konekta ditzakezu. Eta botila-lepoa biltegiratze sisteman dauden blokeak baino ez dira. Eta teknologien aukeraketaren galdera interesgarria da. Zergatik ez LVM?

Zehazki, LVMri buruz hitz egin dezakegu topaketan. Biltegiratzeari buruz - garestia da. ZFS sistema edozein lekutan inplementa dezakegu. Zure makinan zabaldu dezakezu. Biltegia deskargatu eta zabaldu besterik ez duzu egin. ZFS ia nonahi instalatuta dago Linuxaz ari bagara. Hau da, oso irtenbide malgua lortzen dugu. Eta ZFSk berak asko ematen du kutxatik kanpo. Nahi adina datu igo ditzakezu, disko kopuru handia konektatu, argazkiak daude. Eta, esan bezala, erraza da administratzea. Hau da, erabiltzeko oso atsegina dirudi. Probatua dago, urte asko ditu. Hazten ari den komunitate oso handia du. ZFS irtenbide oso fidagarria da.

Nikolai Samokhvalov: Gehiago komenta dezaket? Nire izena Nikolay da, Anatolyrekin batera lan egiten dugu. Ados nago biltegiratzea bikaina dela. Eta gure bezero batzuek Pure Storage eta abar dituzte.

Anatolyk zuzen adierazi zuen modularitatean zentratuta gaudela. Eta etorkizunean, interfaze bat inplementatu dezakezu: argazki bat atera, klon bat egin, klona suntsitu. Erraza da dena. Eta biltegiratzea freskoa da, hala bada.

Baina ZFS guztion eskura dago. DelPhix nahikoa da dagoeneko, 300 bezero dituzte. Horietatik, fortune 100-k 50 bezero ditu, hau da, NASAri zuzenduta daude, etab. Bada garaia guztiontzat teknologia hori lortzeko. Eta horregatik dugu kode irekiko Core. Kode irekia ez den interfazearen zati bat dugu. Hau da erakutsiko dugun plataforma. Baina guztion eskura egotea nahi dugu. Iraultza bat egin nahi dugu probalari guztiek ordenagailu eramangarrietan asmatzeari utzi diezaioten. SELECT idatzi eta berehala motela dela ikusi behar dugu. Utzi DBAk horren berri emateko itxarotea. Hona hemen helburu nagusia. Eta denok horretara helduko garela uste dut. Eta gauza hau denek izan dezaten egiten dugu. Beraz, ZFS, nonahi egongo baita eskuragarri. Eskerrak komunitateari arazoak konpontzeagatik eta kode irekiko lizentzia izateagatik, etab.*

Zorionak! Eskerrik asko erreportajeagatik! Nire izena Maxim da. Gai berdinak landu ditugu. Euren kabuz erabaki zuten. Nola partekatzen dituzu baliabideak klon horien artean? Klon bakoitzak bere gauza egin dezake une bakoitzean: batek gauza bat probatzen du, beste batek beste bat, norbaitek indize bat eraikitzen du, norbaitek lan astuna du. Eta oraindik CPU bidez zati dezakezu, orduan IO bidez, nola banatu? Hau da lehen galdera.

Eta bigarren galdera harmailen desberdintasunari buruzkoa da. Demagun ZFS hemen daukadala eta dena polita dagoela, baina prod-eko bezeroak ez dauka ZFS, ext4 baizik, adibidez. Nola kasu honetan?

Galderak oso onak dira. Arazo hau pixka bat aipatu dut baliabideak partekatzen ditugulako. Eta irtenbidea hau da. Imajinatu eszenaratzean probatzen ari zarela. Halako egoera bat ere izan dezakezu aldi berean norbaitek karga bat ematen duela, beste norbaitek. Eta, ondorioz, neurgailu ulergaitzak ikusten dituzu. Arazo bera ere izan daiteke prod-ekin. Eskaera bat egiaztatu nahi duzunean eta arazoren bat dagoela ikusten duzunean - poliki-poliki funtzionatzen du, orduan arazoa ez zegoen eskaeran, karga paraleloren bat dagoela baizik.

Eta, beraz, hemen garrantzitsua da plana zein izango den, planean zein pauso emango ditugun eta horretarako zenbat datu bilduko ditugun aztertzea. Izan ere, gure diskoak, adibidez, zerbait kargatu izango da, zehazki denbora eragingo du. Baina eskaera hau zenbat kargatu den kalkula dezakegu datu kopuruaren arabera. Ez da hain garrantzitsua aldi berean nolabaiteko exekuzioa izango denik.

Bi galdera ditut. Hau oso gauza polita da. Ekoizpen-datuak kritikoak diren kasuak egon al dira, hala nola kreditu-txartelen zenbakiak? Dagoeneko zerbait prest dago edo aparteko zeregina da? Eta bigarren galdera - ba al dago horrelako zerbait MySQLrako?

Datuei buruz. Ofuskazioa egingo dugu egin arte. Baina Joe zehatz-mehatz zabaltzen baduzu, garatzaileei sarbidea ematen ez badiezu, orduan ez dago datuetarako sarbiderik. Zergatik? Joek ez duelako daturik erakusten. Neurri, planak eta kitto bakarrik erakusten ditu. Hori nahita egin zen, hori baita gure bezeroaren eskakizunetako bat. Guztiei sarbidea eman gabe optimizatu ahal izan nahi zuten.

MySQLri buruz. Sistema hau diskoan egoera gordetzen duen edozertarako erabil daiteke. Eta Postgres egiten ari garenez, orain Postgres-en automatizazio guztia egiten ari gara lehenik. Babeskopia batetik datuak lortzea automatizatu nahi dugu. Postgres behar bezala konfiguratzen ari gara. Badakigu planak bat egiten, etab.

Baina sistema hedagarria denez, MySQLrako ere erabil daiteke. Eta badira horrelako adibideak. Yandex-ek antzeko gauza bat du, baina ez dute inon argitaratzen. Yandex.Metrica barruan erabiltzen dute. Eta MySQLri buruzko istorio bat besterik ez dago. Baina teknologiak berdinak dira, ZFS.

Eskerrik asko erreportajeagatik! Galdera pare bat ere baditut. Klonazioa analitiketarako erabil daitekeela aipatu duzu, adibidez bertan indize osagarriak eraikitzeko. Esan al dezakezu pixka bat gehiago nola funtzionatzen duen?

Eta berehala egingo dut bigarren galdera harmailen antzekotasunari buruz, planoen antzekotasunari buruz. Plana Postgresek bildutako estatistiken araberakoa da ere. Nola konpontzen duzu arazo hau?

Analitiken arabera, ez dago kasu zehatzik, oraindik ez dugulako erabili, baina badago aukera hori. Indizeez ari bagara, imajina ezazu kontsulta bat ehunka milioi erregistro dituen taula eta normalean prod-en indexatzen ez den zutabe baten atzetik ari dela. Eta han datu batzuk kalkulatu nahi ditugu. Eskaera hau prod-era bidaltzen bada, aukera dago prod-en sinplea izatea, eskaera han prozesatu egingo baita minutu batez.

Ados, egin dezagun minutu batzuetan gelditzeko izugarria ez den klon mehe bat. Eta analitikoak irakurtzea erosoagoa izan dadin, datuak interesatzen zaizkigun zutabeetarako indizeak gehituko ditugu.

Indizea sortuko da bakoitzean?

Datuak ukitu, argazkiak egin ditzakezu, eta, ondoren, argazki honetatik berreskuratu eta eskaera berriak bultzatuko ditugu. Hau da, egin dezakezu dagoeneko finkatutako indizeekin klon berriak igotzeko.

Estatistikei buruzko galderari dagokionez, babeskopia batetik leheneratzen badugu, erreplikazioa egiten badugu, gure estatistikak berdinak izango dira. Datu fisikoen egitura osoa dugulako, hau da, datuak dauden bezala ekarriko ditugu estatistika metrika guztiekin ere.

Hona hemen beste arazo bat. Hodeiko irtenbide bat erabiltzen baduzu, irauli logikoak baino ez daude eskuragarri, Google-k, Amazonek ez baitute kopia fisikorik hartzen uzten. Arazo bat egongo da.

Eskerrik asko erreportajeagatik. Hemen bi galdera on zeuden MySQLri eta baliabideen partekatzeari buruz. Baina, hain zuzen ere, hori guztia DBMS espezifikoen gaia ez dela, fitxategi sistema osoarena baizik. Eta, horren arabera, baliabideak partekatzeko arazoak ere hortik konpondu behar dira, ez Postgres den amaieran, baizik eta fitxategi sisteman, zerbitzarian, kasu.

Nire galdera apur bat ezberdina da. Geruza anitzeko datu-basetik hurbilago dago, non hainbat geruza dauden. Adibidez, hamar terabyte-ko irudiaren eguneraketa konfiguratzen dugu, erreplikatzen ari gara. Eta irtenbide hau bereziki erabiltzen dugu datu-baseetarako. Erreplikazioa abian da, datuak eguneratzen ari dira. Hemen 100 langile daude paraleloan lanean, plano ezberdin hauek etengabe abiarazten dituztenak. Zer egin? Nola ziurtatu gatazkarik ez dagoela, bat abiarazi dutela, eta gero fitxategi-sistema aldatu dela eta argazki hauek guztiak joan dira?

Ez dira joango ZFS-k horrela funtzionatzen duelako. Hari batean bereizita gorde ditzakegu erreplikaren ondorioz sortzen diren fitxategi-sistemaren aldaketak. Eta mantendu garatzaileek datuen bertsio zaharretan erabiltzen dituzten klonak. Eta guretzat funtzionatzen du, dena ondo dago honekin.

Ematen du eguneraketa geruza gehigarri gisa egingo dela, eta argazki berri guztiak dagoeneko joango dira, geruza honetan oinarrituta, ezta?

Aurreko errepliketako aurreko geruzetatik.

Aurreko geruzak eroriko dira, baina geruza zaharrari erreferentzia egingo diote, eta eguneratzean jasotako azken geruzaren irudi berriak hartuko al dituzte?

Oro har, bai.

Ondorioz, geruza piku bat izango dugu. Eta denborarekin konprimitu beharko dira?

Bai dena zuzena da. Leiho bat dago. Asteroko argazkiak gordetzen ditugu. Zein baliabide duzun araberakoa da. Datu asko gordetzeko gaitasuna baduzu, argazkiak denbora luzez gorde ditzakezu. Ez dira euren kabuz joango. Ez da datuen ustelkeriarik izango. Argazkiak zaharkituta badaude, iruditzen zaigun bezala, hau da, enpresaren politikaren araberakoa da, orduan ezabatu eta lekua askatu besterik ez dugu egin.

Kaixo, eskerrik asko erreportajeagatik! Joeri buruzko galdera. Esan duzu bezeroak ez diola datu guztiei sarbidea eman nahi. Zorrotz esanda, pertsona batek Azaldu Azterketaren emaitza badu, orduan datuak ikus ditzake.

Horrelakoa da. Adibidez, idatz dezakegu: "HAUTATU NONDIK posta elektronikoa = horretara". Hau da, ez ditugu datuak berak ikusiko, baina zeharkako seinale batzuk ikus ditzakegu. Hau ulertu behar da. Baina, bestetik, dena dago. Log auditoria dugu, garatzaileek zer egiten duten ikusten duten beste lankide batzuen kontrola dugu. Eta norbait hori egiten saiatzen bada, segurtasun-zerbitzua bertaratuko da eta gai honetan lan egingo du.

Arratsalde on Eskerrik asko erreportajeagatik! Galdera labur bat daukat. Konpainiak ez badu Slack erabiltzen, ba al dago loturarik orain, ala posible al da garatzaileek instantziak zabaltzea probako aplikazio bat datu-baseetara konektatzeko?

Orain Slack-erako esteka dago, hau da, ez dago beste mezularirik, baina benetan beste mezularientzako laguntza ere egin nahi dut. Zer egin dezakezu? DB Lab inplementatu dezakezu Joe gabe, REST APIaren laguntzarekin edo gure plataformaren laguntzarekin joan eta klonak sortu eta PSQLrekin konektatu. Baina hori egin daiteke zure garatzaileei datuetarako sarbidea emateko prest bazaude, ez baita pantailarik egongo.

Ez dut geruza hau behar, baina halako aukera bat behar dut.

Orduan bai, egin daiteke.

Iturria: www.habr.com