DBA bot Joe. Anatoly Stansler (Postgres.ai)

Paano nauunawaan ng isang backend developer na ang isang SQL query ay gagana nang maayos sa isang "prod"? Sa malaki o mabilis na lumalagong mga kumpanya, hindi lahat ay may access sa "produkto". At sa pag-access, hindi lahat ng mga kahilingan ay maaaring masuri nang walang sakit, at ang paglikha ng isang kopya ng database ay madalas na tumatagal ng mga oras. Upang malutas ang mga problemang ito, lumikha kami ng isang artipisyal na DBA - Joe. Matagumpay na itong naipatupad sa ilang kumpanya at nakakatulong sa higit sa isang dosenang developer.

Video:

Kamusta kayong lahat! Ang pangalan ko ay Anatoly Stansler. Nagtatrabaho ako sa isang kumpanya postgres.ai. Nakatuon kami na pabilisin ang proseso ng pagbuo sa pamamagitan ng pag-alis sa mga pagkaantala na nauugnay sa gawain ng Postgres mula sa mga developer, DBA at QA.

Mayroon kaming mahusay na mga kliyente at ngayon bahagi ng ulat ay nakatuon sa mga kaso na nakilala namin habang nagtatrabaho sa kanila. Pag-uusapan ko kung paano namin sila tinulungang malutas ang mga mabibigat na problema.

Kapag tayo ay bumubuo at gumagawa ng mga kumplikadong paglilipat na may mataas na karga, tinatanong natin ang ating sarili sa tanong na: "Aalis ba ang paglipat na ito?". Gumagamit kami ng pagsusuri, ginagamit namin ang kaalaman ng mas maraming karanasan na mga kasamahan, mga eksperto sa DBA. At masasabi nila kung ito ay lilipad o hindi.

Ngunit marahil ay mas mabuti kung maaari nating subukan ito sa ating sarili sa buong laki ng mga kopya. At ngayon ay pag-uusapan lang natin kung ano ang mga diskarte sa pagsubok ngayon at kung paano ito magagawa nang mas mahusay at gamit ang mga tool. Pag-uusapan din natin ang tungkol sa mga kalamangan at kahinaan ng gayong mga diskarte, at kung ano ang maaari nating ayusin dito.

Sino ang nakagawa ng mga index nang direkta sa prod o gumawa ng anumang mga pagbabago? Medyo ng. At para kanino ito humantong sa katotohanang nawala ang data o may downtime? Saka alam mo ang sakit na ito. Salamat sa Diyos may mga backup.

Ang unang diskarte ay pagsubok sa prod. O, kapag ang isang developer ay nakaupo sa isang lokal na makina, mayroon siyang data ng pagsubok, mayroong ilang uri ng limitadong pagpili. At gumulong kami upang magsulong, at nakuha namin ang sitwasyong ito.

Masakit, mahal. Ito ay marahil pinakamahusay na hindi.

At ano ang pinakamahusay na paraan upang gawin ito?

Halina't kunin ang pagtatanghal at pumili ng ilang bahagi ng prod doon. O sa pinakamahusay, kumuha tayo ng isang tunay na prod, ang lahat ng data. At pagkatapos nating mabuo ito nang lokal, titingnan din natin ang pagtatanghal.

Magbibigay-daan ito sa amin na alisin ang ilan sa mga error, ibig sabihin, pigilan ang mga ito sa prod.

Ano ang mga problema?

• Ang problema ay ibinabahagi namin ang pagtatanghal na ito sa mga kasamahan. At napakadalas na nangyayari na gumawa ka ng ilang uri ng pagbabago, bam - at walang data, ang trabaho ay nasa alisan ng tubig. Ang pagtatanghal ay multi-terabyte. At kailangan mong maghintay ng mahabang panahon para ito ay bumangon muli. At nagpasya kaming tapusin ito bukas. Yun nga lang, may development na tayo.
• At, siyempre, marami kaming mga kasamahan na nagtatrabaho doon, maraming mga koponan. At kailangan itong gawin nang manu-mano. At ito ay hindi maginhawa.

At ito ay nagkakahalaga na sabihin na mayroon lamang kaming isang pagtatangka, isang pagbaril, kung gusto naming gumawa ng ilang mga pagbabago sa database, pindutin ang data, baguhin ang istraktura. At kung may nangyaring mali, kung nagkaroon ng error sa paglipat, hindi tayo mabilis na babalik.

Ito ay mas mahusay kaysa sa nakaraang diskarte, ngunit mayroon pa ring mataas na posibilidad na ang ilang uri ng error ay mapupunta sa produksyon.

Ano ang pumipigil sa amin na bigyan ang bawat developer ng test bench, isang buong laki na kopya? Sa tingin ko ay malinaw kung ano ang humahadlang.

Sino ang may database na mas malaki kaysa sa terabyte? Mahigit kalahati ng kwarto.

At malinaw na ang pag-iingat ng mga makina para sa bawat developer, kapag may ganoong kalaking produksyon, ay napakamahal, at bukod pa, ito ay tumatagal ng mahabang panahon.

Mayroon kaming mga kliyente na napagtanto na napakahalagang subukan ang lahat ng mga pagbabago sa buong laki ng mga kopya, ngunit ang kanilang database ay mas mababa sa isang terabyte, at walang mga mapagkukunan upang mapanatili ang isang test bench para sa bawat developer. Samakatuwid, kailangan nilang i-download ang mga dump nang lokal sa kanilang makina at subukan sa ganitong paraan. Ito ay tumatagal ng maraming oras.

Kahit na gawin mo ito sa loob ng imprastraktura, ang pag-download ng isang terabyte ng data kada oras ay napakahusay na. Ngunit gumagamit sila ng mga lohikal na dump, nagda-download sila nang lokal mula sa cloud. Para sa kanila, ang bilis ay halos 200 gigabytes kada oras. At nangangailangan pa rin ng oras upang lumiko mula sa lohikal na dump, i-roll up ang mga index, atbp.

Ngunit ginagamit nila ang pamamaraang ito dahil pinapayagan silang panatilihing maaasahan ang prod.

Ano ang magagawa natin dito? Gawin nating mura ang mga test bench at bigyan ang bawat developer ng sarili nilang test bench.

At ito ay posible.

At sa diskarteng ito, kapag gumawa kami ng mga manipis na clone para sa bawat developer, maibabahagi namin ito sa isang makina. Halimbawa, kung mayroon kang 10TB database at gusto mong ibigay ito sa 10 developer, hindi mo kailangang magkaroon ng XNUMX x XNUMXTB database. Kailangan mo lang ng isang makina para makagawa ng mga manipis na nakahiwalay na kopya para sa bawat developer gamit ang isang makina. Sasabihin ko sa iyo kung paano ito gumagana sa ibang pagkakataon.

Tunay na halimbawa:

• DB - 4,5 terabytes.

• Makakakuha tayo ng mga independiyenteng kopya sa loob ng 30 segundo.

Hindi mo kailangang maghintay para sa isang test stand at depende sa kung gaano ito kalaki. Makukuha mo ito sa ilang segundo. Ito ay magiging ganap na nakahiwalay na mga kapaligiran, ngunit nagbabahagi ng data sa kanilang mga sarili.

Ito ay kahanga-hanga. Dito pinag-uusapan natin ang magic at isang parallel universe.

Sa aming kaso, ito ay gumagana gamit ang OpenZFS system.

Ang OpenZFS ay isang copy-on-write file system na sumusuporta sa mga snapshot at clone sa labas ng kahon. Ito ay maaasahan at nasusukat. Napakadali niyang pamahalaan. Maaari itong literal na i-deploy sa dalawang koponan.

Mayroong iba pang mga pagpipilian:

• lvm,

• Imbakan (halimbawa, Purong Imbakan).

Ang Database Lab na pinag-uusapan ko ay modular. Maaaring ipatupad gamit ang mga opsyong ito. Ngunit sa ngayon, nakatuon kami sa OpenZFS, dahil partikular na may mga problema sa LVM.

Paano ito gumagana? Sa halip na i-overwrite ang data sa tuwing babaguhin namin ito, sine-save namin ito sa pamamagitan lamang ng pagmamarka na ang bagong data na ito ay mula sa isang bagong punto ng oras, isang bagong snapshot.

At sa hinaharap, kapag gusto naming i-rollback o gusto naming gumawa ng bagong clone mula sa ilang mas lumang bersyon, sasabihin lang namin: "OK, ibigay sa amin ang mga bloke ng data na ito na minarkahan ng ganito."

At gagana ang user na ito sa naturang set ng data. Unti-unti niyang babaguhin ang mga ito, gagawa ng sarili niyang mga snapshot.

At magsasanga tayo. Ang bawat developer sa aming kaso ay magkakaroon ng pagkakataong magkaroon ng sarili niyang clone na kanyang ine-edit, at ang data na ibinabahagi ay ibabahagi sa pagitan ng lahat.

Upang i-deploy ang gayong sistema sa bahay, kailangan mong lutasin ang dalawang problema:

• Ang una ay ang pinagmulan ng data, kung saan mo ito kukunin. Maaari kang mag-set up ng pagtitiklop sa produksyon. Magagamit mo na ang mga backup na na-configure mo, sana. WAL-E, WAL-G o Barman. At kahit na gumagamit ka ng ilang uri ng solusyon sa Cloud tulad ng RDS o Cloud SQL, maaari kang gumamit ng mga lohikal na dump. Ngunit ipinapayo pa rin namin sa iyo na gumamit ng mga backup, dahil sa diskarteng ito ay mapapanatili mo rin ang pisikal na istraktura ng mga file, na magbibigay-daan sa iyo na maging mas malapit sa mga sukatan na makikita mo sa produksyon upang mahuli ang mga problemang umiiral.

• Ang pangalawa ay kung saan mo gustong i-host ang Database Lab. Maaaring si Cloud, maaaring nasa Nasa lugar. Mahalagang sabihin dito na sinusuportahan ng ZFS ang data compression. At ginagawa ito nang maayos.

Isipin na para sa bawat naturang clone, depende sa mga operasyon na ginagawa namin sa base, ang ilang uri ng dev ay lalago. Para dito, kakailanganin din ng dev ng espasyo. Ngunit dahil sa katotohanan na kumuha kami ng base na 4,5 terabytes, i-compress ito ng ZFS sa 3,5 terabytes. Ito ay maaaring mag-iba depende sa mga setting. At mayroon pa kaming puwang para sa dev.

Ang ganitong sistema ay maaaring gamitin para sa iba't ibang mga kaso.

• Ito ay mga developer, mga DBA para sa pagpapatunay ng query, para sa pag-optimize.

• Magagamit ito sa QA testing para subukan ang isang partikular na paglipat bago namin ito ilunsad sa prod. At maaari rin kaming magtaas ng mga espesyal na kapaligiran para sa QA na may totoong data, kung saan maaari nilang subukan ang bagong functionality. At aabutin ng ilang segundo sa halip na mga oras ng paghihintay, at maaaring mga araw sa ilang iba pang mga kaso kung saan hindi ginagamit ang mga manipis na kopya.

• At isa pang kaso. Kung ang kumpanya ay walang sistema ng analytics na naka-set up, maaari naming ihiwalay ang isang manipis na clone ng base ng produkto at ibigay ito sa mahabang query o mga espesyal na index na maaaring magamit sa analytics.

Sa ganitong paraan:

1. Mababang posibilidad ng mga error sa "prod", dahil sinubukan namin ang lahat ng mga pagbabago sa buong laki ng data.

2. Mayroon tayong kultura ng pagsubok, dahil ngayon ay hindi mo na kailangang maghintay ng maraming oras para sa iyong sariling paninindigan.

3. At walang hadlang, walang paghihintay sa pagitan ng mga pagsubok. Maaari ka talagang pumunta at suriin. At ito ay magiging mas mahusay sa ganitong paraan habang pinapabilis natin ang pag-unlad.

• Magkakaroon ng mas kaunting refactoring. Mas kaunting mga bug ang mapupunta sa prod. Ire-refactor namin sila nang mas kaunti mamaya.

• Maaari nating baligtarin ang mga hindi maibabalik na pagbabago. Hindi ito ang karaniwang diskarte.

1. Ito ay kapaki-pakinabang dahil ibinabahagi namin ang mga mapagkukunan ng mga pagsubok na bangko.

Mabuti na, ngunit ano pa ang maaaring mapabilis?

Salamat sa naturang sistema, maaari naming lubos na bawasan ang threshold para sa pagpasok sa naturang pagsubok.

Ngayon ay mayroong isang mabisyo na bilog, kapag ang isang developer, upang makakuha ng access sa totoong buong laki ng data, ay dapat maging isang dalubhasa. Dapat siyang mapagkakatiwalaan sa ganoong pag-access.

Ngunit paano palaguin kung wala ito. Ngunit paano kung mayroon ka lamang isang napakaliit na set ng data ng pagsubok na magagamit mo? Pagkatapos ay hindi ka makakakuha ng anumang tunay na karanasan.

Paano makaalis sa bilog na ito? Bilang unang interface, na maginhawa para sa mga developer ng anumang antas, pinili namin ang Slack bot. Ngunit maaari itong maging anumang iba pang interface.

Ano ang pinapayagan nitong gawin mo? Maaari kang kumuha ng isang partikular na query at ipadala ito sa isang espesyal na channel para sa database. Awtomatiko kaming magde-deploy ng manipis na clone sa ilang segundo. Gawin natin ang kahilingang ito. Kinokolekta namin ang mga sukatan at rekomendasyon. Magpakita tayo ng visualization. At pagkatapos ay mananatili ang clone na ito upang ang query na ito ay ma-optimize, magdagdag ng mga index, atbp.

At binibigyan din kami ng Slack ng mga pagkakataon para sa pakikipagtulungan sa labas ng kahon. Dahil channel lang ito, maaari mong simulan ang pagtalakay sa kahilingang ito doon mismo sa thread para sa naturang kahilingan, i-ping ang iyong mga kasamahan, mga DBA na nasa loob ng kumpanya.

Ngunit may mga, siyempre, mga problema. Dahil ito ang totoong mundo, at gumagamit kami ng server na nagho-host ng maraming clone nang sabay-sabay, kailangan naming i-compress ang dami ng memory at CPU power na available sa mga clone.

Ngunit para maging makatwiran ang mga pagsubok na ito, kailangan mong lutasin ang problemang ito kahit papaano.

Ito ay malinaw na ang mahalagang punto ay ang parehong data. Pero meron na tayo. At gusto naming makamit ang parehong configuration. At maaari tayong magbigay ng halos magkaparehong pagsasaayos.

Magiging cool na magkaroon ng parehong hardware tulad ng sa produksyon, ngunit maaaring magkaiba ito.

Tandaan natin kung paano gumagana ang Postgres sa memorya. Mayroon kaming dalawang cache. Isa mula sa file system at isang katutubong Postgres, i.e. Shared Buffer Cache.

Mahalagang tandaan na ang Shared Buffer Cache ay inilalaan kapag nagsimula ang Postgres, depende sa kung anong laki ang iyong tinukoy sa configuration.

At ang pangalawang cache ay gumagamit ng lahat ng magagamit na espasyo.

At kapag gumawa kami ng ilang mga clone sa isang makina, lumalabas na unti-unti naming pinupuno ang memorya. At sa mabuting paraan, ang Shared Buffer Cache ay 25% ng kabuuang dami ng memory na magagamit sa makina.

At lumalabas na kung hindi namin babaguhin ang parameter na ito, 4 na pagkakataon lamang ang magagawa namin sa isang makina, iyon ay, 4 sa mga manipis na clone na ito sa kabuuan. At ito, siyempre, ay masama, dahil gusto nating magkaroon ng higit pa sa kanila.

Ngunit sa kabilang banda, ang Buffer Cache ay ginagamit upang magsagawa ng mga query para sa mga index, ibig sabihin, ang plano ay depende sa kung gaano kalaki ang aming mga cache. At kung kukunin lang natin ang parameter na ito at bawasan ito, kung gayon ang ating mga plano ay maaaring magbago nang malaki.

Halimbawa, kung mayroon kaming malaking cache sa prod, mas gugustuhin ng Postgres na gumamit ng index. At kung hindi, magkakaroon ng SeqScan. At ano ang magiging punto kung ang aming mga plano ay hindi nagtutugma?

Ngunit narito kami sa konklusyon na sa katunayan ang plano sa Postgres ay hindi nakasalalay sa tiyak na laki na tinukoy sa Shared Buffer sa plano, ito ay nakasalalay sa effective_cache_size.

Ang Effective_cache_size ay ang tinantyang halaga ng cache na available sa amin, ibig sabihin, ang kabuuan ng Buffer Cache at file system cache. Ito ay itinakda ng config. At ang memoryang ito ay hindi inilalaan.

At dahil sa parameter na ito, maaari naming linlangin ang mga Postgres, na nagsasabi na marami talaga kaming magagamit na data, kahit na wala kaming data na ito. At sa gayon, ang mga plano ay ganap na magkakasabay sa produksyon.

Ngunit ito ay maaaring makaapekto sa timing. At ino-optimize namin ang mga query ayon sa timing, ngunit mahalagang nakadepende ang timing sa maraming salik:

• Depende sa load na kasalukuyang nasa prod.

• Depende ito sa mga katangian ng makina mismo.

At ito ay isang hindi direktang parameter, ngunit sa katunayan maaari naming i-optimize nang eksakto sa dami ng data na babasahin ng query na ito upang makuha ang resulta.

At kung gusto mong maging malapit ang timing sa makikita natin sa prod, kailangan nating kunin ang pinakakatulad na hardware at, posibleng, higit pa para magkasya ang lahat ng clone. Ngunit ito ay isang kompromiso, ibig sabihin, makakakuha ka ng parehong mga plano, makikita mo kung gaano karaming data ang babasahin ng isang partikular na query at magagawa mong tapusin kung ang query na ito ay mabuti (o migration) o masama, kailangan pa rin itong i-optimize .

Tingnan natin kung paano partikular na na-optimize si Joe.

Kumuha tayo ng kahilingan mula sa isang tunay na sistema. Sa kasong ito, ang database ay 1 terabyte. At gusto naming bilangin ang bilang ng mga bagong post na mayroong higit sa 10 likes.

Nagsusulat kami ng mensahe sa channel, isang clone ang na-deploy para sa amin. At makikita natin na matatapos ang naturang kahilingan sa loob ng 2,5 minuto. Ito ang una nating napapansin.

B Joe ay magpapakita sa iyo ng mga awtomatikong rekomendasyon batay sa plano at mga sukatan.

Makikita natin na ang query ay nagpoproseso ng masyadong maraming data upang makakuha ng medyo maliit na bilang ng mga row. At kailangan ang ilang uri ng espesyal na index, dahil napansin namin na napakaraming naka-filter na row sa query.

Tingnan natin ang mga nangyari. Sa katunayan, nakita namin na nabasa namin ang halos isa at kalahating gigabytes ng data mula sa cache ng file o kahit na mula sa disk. At hindi ito maganda, dahil 142 lines lang ang nakuha namin.

At, tila, mayroon kaming isang index scan dito at dapat na gumana nang mabilis, ngunit dahil na-filter namin ang napakaraming linya (kailangan naming bilangin ang mga ito), dahan-dahang gumana ang kahilingan.

At nangyari ito sa plano dahil sa ang katunayan na ang mga kundisyon sa query at ang mga kundisyon sa index ay bahagyang hindi tumutugma.

Subukan nating gawing mas tumpak ang index at tingnan kung paano nagbabago ang pagpapatupad ng query pagkatapos noon.

Medyo matagal ang paggawa ng index, ngunit ngayon ay sinusuri namin ang query at nakita namin na ang oras sa halip na 2,5 minuto ay 156 milliseconds lamang, na sapat na. At 6 megabytes lang ng data ang nabasa namin.

At ngayon ginagamit namin ang pag-scan lamang ng index.

Ang isa pang mahalagang kuwento ay gusto naming ipakita ang plano sa ilang mas naiintindihan na paraan. Ipinatupad namin ang visualization gamit ang Flame Graph.

Ibang hiling ito, mas matindi. At bumuo kami ng Flame Graph ayon sa dalawang parameter: ito ang dami ng data na binibilang ng isang partikular na node sa plano at timing, ibig sabihin, ang oras ng pagpapatupad ng node.

Dito maaari nating ihambing ang mga tiyak na node sa bawat isa. At magiging malinaw kung alin sa mga ito ang tumatagal ng higit pa o mas kaunti, na kadalasang mahirap gawin sa ibang mga paraan ng pag-render.

Siyempre, alam ng lahat ang explain.depesz.com. Ang isang magandang feature ng visualization na ito ay ang pag-save namin ng text plan at naglalagay din kami ng ilang pangunahing parameter sa isang table para mapag-uri-uriin namin.

At ang mga developer na hindi pa nakakaalam sa paksang ito ay gumagamit din ng explain.depesz.com, dahil mas madali para sa kanila na malaman kung aling mga sukatan ang mahalaga at alin ang hindi.

May bagong diskarte sa visualization - ito ay explain.dalibo.com. Gumagawa sila ng tree visualization, ngunit napakahirap ihambing ang mga node sa isa't isa. Dito maaari mong maunawaan nang mabuti ang istraktura, gayunpaman, kung mayroong isang malaking kahilingan, pagkatapos ay kailangan mong mag-scroll pabalik-balik, ngunit din ng isang pagpipilian.

pakikipagtulungan

At, gaya ng sinabi ko, binibigyan tayo ng Slack ng pagkakataong mag-collaborate. Halimbawa, kung makatagpo kami ng isang kumplikadong query na hindi malinaw kung paano mag-optimize, maaari naming linawin ang isyung ito sa aming mga kasamahan sa isang thread sa Slack.

Para sa amin, mahalagang subukan ang buong laki ng data. Para magawa ito, ginawa namin ang tool na Update Database Lab, na available sa open source. Maaari mo ring gamitin ang Joe bot. Maaari mo itong kunin ngayon at ipatupad ito sa iyong lugar. Ang lahat ng mga gabay ay magagamit doon.

Mahalaga rin na tandaan na ang solusyon mismo ay hindi rebolusyonaryo, dahil mayroong Delphix, ngunit ito ay isang solusyon sa negosyo. Ito ay ganap na sarado, ito ay napakamahal. Partikular kaming nagdadalubhasa sa Postgres. Lahat ito ay mga open source na produkto. Sumali ka!

Dito ako nagtatapos. Salamat!

mga katanungan

Kamusta! Salamat sa ulat! Napaka-interesante, lalo na sa akin, dahil nalutas ko ang tungkol sa parehong problema noong nakaraan. At kaya marami akong katanungan. Sana ay makakuha ako ng kahit na bahagi nito.

Nagtataka ako kung paano mo kinakalkula ang lugar para sa kapaligirang ito? Nangangahulugan ang teknolohiya na sa ilalim ng ilang partikular na sitwasyon, ang iyong mga clone ay maaaring lumaki sa pinakamataas na laki. Sa halos pagsasalita, kung mayroon kang sampung terabyte database at 10 clone, kung gayon ay madaling gayahin ang isang sitwasyon kung saan ang bawat clone ay tumitimbang ng 10 natatanging data. Paano mo kinakalkula ang lugar na ito, iyon ay, ang delta na iyong sinabi, kung saan mabubuhay ang mga clone na ito?

Magandang tanong. Mahalagang subaybayan ang mga partikular na clone dito. At kung ang isang clone ay may napakalaking pagbabago, nagsisimula itong lumaki, pagkatapos ay maaari muna kaming mag-isyu ng babala sa gumagamit tungkol dito, o agad na ihinto ang clone na ito upang hindi tayo magkaroon ng sitwasyong mabibigo.

Oo, may nested question ako. Ibig sabihin, paano mo matitiyak ang siklo ng buhay ng mga modyul na ito? Mayroon kaming problemang ito at isang buong hiwalay na kuwento. Paano ito nangyayari?

Mayroong ilang ttl para sa bawat clone. Talaga, mayroon kaming isang nakapirming ttl.

Paano, kung hindi sikreto?

1 oras, ibig sabihin, idle - 1 oras. Kung hindi ito ginagamit, pagkatapos ay i-bang namin ito. Ngunit walang sorpresa dito, dahil maaari nating itaas ang clone sa ilang segundo. At kung kailangan mo ulit, pakiusap.

Interesado din ako sa pagpili ng mga teknolohiya, dahil, halimbawa, gumagamit kami ng ilang mga pamamaraan nang magkatulad para sa isang kadahilanan o iba pa. Bakit ZFS? Bakit hindi mo ginamit ang LVM? Nabanggit mo na may mga problema sa LVM. Ano ang mga problema? Sa palagay ko, ang pinakamainam na opsyon ay may imbakan, sa mga tuntunin ng pagganap.

Ano ang pangunahing problema sa ZFS? Ang katotohanan na dapat kang tumakbo sa parehong host, ibig sabihin, lahat ng mga pagkakataon ay mabubuhay sa loob ng parehong OS. At sa kaso ng imbakan, maaari mong ikonekta ang iba't ibang kagamitan. At ang bottleneck ay ang mga bloke lamang na nasa storage system. At ang tanong ng pagpili ng mga teknolohiya ay kawili-wili. Bakit hindi LVM?

Sa partikular, maaari nating talakayin ang LVM sa meetup. Tungkol sa imbakan - mahal lang. Maaari naming ipatupad ang ZFS system kahit saan. Maaari mong i-deploy ito sa iyong makina. Maaari mo lamang i-download ang repositoryo at i-deploy ito. Ang ZFS ay naka-install halos lahat ng dako kung pinag-uusapan natin ang Linux. Ibig sabihin, nakakakuha tayo ng napaka-flexible na solusyon. At ang ZFS mismo ay nagbibigay ng maraming out of the box. Maaari kang mag-upload ng maraming data hangga't gusto mo, ikonekta ang isang malaking bilang ng mga disk, mayroong mga snapshot. At, gaya ng sinabi ko, madali itong pangasiwaan. Ibig sabihin, parang napakasarap gamitin. Siya ay nasubok, siya ay maraming taong gulang. Mayroon siyang napakalaking komunidad na lumalaki. Ang ZFS ay isang napaka-maaasahang solusyon.

Nikolai Samokhvalov: Maaari ba akong magkomento pa? Ang pangalan ko ay Nikolay, nagtutulungan kami ni Anatoly. Sumasang-ayon ako na mahusay ang storage. At ang ilan sa aming mga customer ay may Pure Storage atbp.

Tamang nabanggit ni Anatoly na kami ay nakatuon sa modularity. At sa hinaharap, maaari mong ipatupad ang isang interface - kumuha ng snapshot, gumawa ng clone, sirain ang clone. Madali lang lahat. At ang imbakan ay cool, kung ito ay.

Ngunit ang ZFS ay magagamit sa lahat. Ang DelPhix ay sapat na, mayroon silang 300 mga kliyente. Sa mga ito, ang fortune 100 ay mayroong 50 kliyente, ibig sabihin, ang mga ito ay nakatutok sa NASA, atbp. Panahon na para makuha ng lahat ang teknolohiyang ito. At iyon ang dahilan kung bakit mayroon kaming isang open source na Core. Mayroon kaming bahagi ng interface na hindi open source. Ito ang platform na ipapakita namin. Ngunit nais naming ito ay ma-access sa lahat. Gusto naming gumawa ng rebolusyon upang ang lahat ng mga tester ay tumigil sa paghula sa mga laptop. Kailangan nating isulat ang SELECT at agad na makita na ito ay mabagal. Itigil ang paghihintay para sa DBA na sabihin sa iyo ang tungkol dito. Narito ang pangunahing layunin. At sa tingin ko lahat tayo ay darating sa ganito. At ginagawa namin ang bagay na ito para magkaroon ng lahat. Samakatuwid ZFS, dahil ito ay magagamit sa lahat ng dako. Salamat sa komunidad para sa paglutas ng mga problema at sa pagkakaroon ng open source na lisensya, atbp.*

Pagbati! Salamat sa ulat! Maxim ang pangalan ko. Pareho kaming nakipag-usap sa mga isyu. Sila ay nagpasya sa kanilang sarili. Paano mo ibinabahagi ang mga mapagkukunan sa pagitan ng mga clone na ito? Ang bawat clone ay maaaring gumawa ng sarili nitong bagay sa anumang naibigay na oras: ang isa ay sumusubok sa isang bagay, isa pa, may gumagawa ng index, may isang mabigat na trabaho. At kung maaari mo pa ring hatiin sa CPU, pagkatapos ay sa IO, paano mo hahatiin? Ito ang unang tanong.

At ang pangalawang tanong ay tungkol sa dissimilarity ng mga stand. Sabihin nating mayroon akong ZFS dito at lahat ay cool, ngunit ang kliyente sa prod ay walang ZFS, ngunit ext4, halimbawa. Paano sa kasong ito?

Napakaganda ng mga tanong. Binanggit ko ang problemang ito nang kaunti sa katotohanan na nagbabahagi kami ng mga mapagkukunan. At ang solusyon ay ito. Isipin na ikaw ay sumusubok sa pagtatanghal. Maaari ka ring magkaroon ng ganoong sitwasyon sa parehong oras na may nagbibigay ng isang load, sa ibang tao. At bilang resulta, nakakakita ka ng mga hindi maintindihang sukatan. Kahit na ang parehong problema ay maaaring sa prod. Kapag nais mong suriin ang ilang kahilingan at nakita mo na mayroong ilang problema dito - ito ay gumagana nang dahan-dahan, kung gayon sa katunayan ang problema ay wala sa kahilingan, ngunit sa katotohanan na mayroong ilang uri ng parallel load.

At samakatuwid, mahalaga dito na tumuon sa kung ano ang magiging plano, kung anong mga hakbang ang gagawin namin sa plano at kung gaano karaming data ang aming itataas para dito. Ang katotohanan na ang aming mga disk, halimbawa, ay mai-load ng isang bagay, ito ay partikular na makakaapekto sa tiyempo. Ngunit maaari naming tantiyahin kung gaano na-load ang kahilingang ito sa pamamagitan ng dami ng data. Ito ay hindi napakahalaga na sa parehong oras ay magkakaroon ng ilang uri ng pagpapatupad.

Mayroon akong dalawang tanong. Ito ay napaka-cool na bagay. Nagkaroon ba ng mga kaso kung saan kritikal ang data ng produksyon, gaya ng mga numero ng credit card? Mayroon na bang handa o ito ay isang hiwalay na gawain? At ang pangalawang tanong - mayroon bang ganito para sa MySQL?

Tungkol sa data. Gagawa kami ng obfuscation hanggang magawa namin. Ngunit kung eksaktong i-deploy mo si Joe, kung hindi ka magbibigay ng access sa mga developer, walang access sa data. Bakit? Dahil hindi nagpapakita ng data si Joe. Ipinapakita lamang nito ang mga sukatan, mga plano at iyon lang. Ito ay ginawa ng kusa, dahil ito ay isa sa mga kinakailangan ng aming kliyente. Nais nilang makapag-optimize nang hindi nagbibigay ng access sa lahat.

Tungkol sa MySQL. Maaaring gamitin ang system na ito para sa anumang bagay na nag-iimbak ng estado sa disk. At dahil ginagawa namin ang Postgres, ginagawa muna namin ang lahat ng automation para sa Postgres. Gusto naming i-automate ang pagkuha ng data mula sa isang backup. Kino-configure namin nang tama ang mga Postgres. Alam namin kung paano magtugma ng mga plano, atbp.

Ngunit dahil extensible ang system, maaari rin itong gamitin para sa MySQL. At may mga ganyang halimbawa. Ang Yandex ay may katulad na bagay, ngunit hindi nila ito inilalathala kahit saan. Ginagamit nila ito sa loob ng Yandex.Metrica. At mayroon lamang isang kuwento tungkol sa MySQL. Ngunit ang mga teknolohiya ay pareho, ZFS.

Salamat sa ulat! Mayroon din akong ilang katanungan. Nabanggit mo na ang pag-clone ay maaaring gamitin para sa analytics, halimbawa upang bumuo ng mga karagdagang index doon. Maaari mo bang sabihin ng kaunti pa tungkol sa kung paano ito gumagana?

At agad kong itatanong ang pangalawang tanong tungkol sa pagkakapareho ng mga stand, ang pagkakapareho ng mga plano. Ang plano ay nakasalalay din sa mga istatistika na nakolekta ng Postgres. Paano mo malulutas ang problemang ito?

Ayon sa analytics, walang mga partikular na kaso, dahil hindi pa namin ito ginagamit, ngunit mayroong ganoong pagkakataon. Kung pinag-uusapan natin ang tungkol sa mga index, isipin na ang isang query ay humahabol sa isang talahanayan na may daan-daang milyong mga tala at isang column na karaniwang hindi na-index sa prod. At gusto naming kalkulahin ang ilang data doon. Kung ang kahilingang ito ay ipinadala sa prod, may posibilidad na ito ay magiging simple sa prod, dahil ang kahilingan ay ipoproseso doon nang isang minuto.

Ok, gumawa tayo ng manipis na clone na hindi nakakatakot na huminto sa loob ng ilang minuto. At upang gawing mas kumportable ang pagbabasa ng analytics, magdaragdag kami ng mga indeks para sa mga column kung saan kami interesado sa data.

Ang index ay gagawin sa bawat oras?

Magagawa mo ito upang mahawakan namin ang data, gumawa ng mga snapshot, pagkatapos ay makakabawi kami mula sa snapshot na ito at humimok ng mga bagong kahilingan. Ibig sabihin, magagawa mo ito para makapagtaas ka ng mga bagong clone na may nakakabit na mga indeks.

Tulad ng para sa tanong tungkol sa mga istatistika, kung ibabalik namin mula sa isang backup, kung gagawin namin ang pagtitiklop, kung gayon ang aming mga istatistika ay magiging eksaktong pareho. Dahil nasa amin ang buong istraktura ng pisikal na data, ibig sabihin, dadalhin namin ang data tulad din ng lahat ng sukatan ng istatistika.

Narito ang isa pang problema. Kung gumagamit ka ng isang solusyon sa ulap, kung gayon ang mga lohikal na dump lamang ang magagamit doon, dahil hindi ka pinapayagan ng Google, Amazon na kumuha ng pisikal na kopya. Magkakaroon ng problema.

Salamat sa ulat. Mayroong dalawang magagandang katanungan dito tungkol sa MySQL at pagbabahagi ng mapagkukunan. Ngunit, sa katunayan, ang lahat ay bumaba sa katotohanan na ito ay hindi isang paksa ng tiyak na DBMS, ngunit ng file system sa kabuuan. At, nang naaayon, ang mga isyu sa pagbabahagi ng mapagkukunan ay dapat ding malutas mula doon, hindi sa dulo na ito ay Postgres, ngunit sa file system, sa server, halimbawa.

Medyo iba ang tanong ko. Ito ay mas malapit sa multi-layered database, kung saan mayroong ilang mga layer. Halimbawa, nag-set up kami ng sampung terabyte na pag-update ng imahe, kami ay kinokopya. At partikular na ginagamit namin ang solusyon na ito para sa mga database. Ang pagkopya ay isinasagawa, ang data ay ina-update. Mayroong 100 empleyado na nagtatrabaho nang magkatulad dito, na patuloy na naglulunsad ng iba't ibang mga kuha na ito. Anong gagawin? Paano matiyak na walang salungatan, na naglunsad sila ng isa, at pagkatapos ay nagbago ang file system, at ang mga larawang ito ay napunta lahat?

Hindi sila pupunta dahil ganyan ang ZFS. Maaari naming panatilihing hiwalay sa isang thread ang mga pagbabago sa file system na dumating dahil sa pagtitiklop. At panatilihin ang mga clone na ginagamit ng mga developer sa mga mas lumang bersyon ng data. At ito ay gumagana para sa amin, ang lahat ay maayos dito.

Lumalabas na ang pag-update ay magaganap bilang isang karagdagang layer, at lahat ng mga bagong larawan ay pupunta na, batay sa layer na ito, tama ba?

Mula sa mga nakaraang layer na mula sa mga nakaraang replikasyon.

Ang mga nakaraang layer ay mahuhulog, ngunit sila ay tumutukoy sa lumang layer, at sila ba ay kukuha ng mga bagong larawan mula sa huling layer na natanggap sa pag-update?

Sa pangkalahatan, oo.

Pagkatapos bilang kinahinatnan ay magkakaroon tayo ng hanggang isang igos ng mga layer. At sa paglipas ng panahon kakailanganin nilang i-compress?

Oo tama lahat. May ilang bintana. Nagpapanatili kami ng mga lingguhang snapshot. Depende ito sa kung anong mapagkukunan ang mayroon ka. Kung mayroon kang kakayahang mag-imbak ng maraming data, maaari kang mag-imbak ng mga snapshot nang mahabang panahon. Hindi sila aalis ng mag-isa. Hindi magkakaroon ng data corruption. Kung ang mga snapshot ay luma na, gaya ng sa tingin natin, ibig sabihin, depende ito sa patakaran sa kumpanya, pagkatapos ay maaari nating tanggalin ang mga ito at magbakante ng espasyo.

Hello, salamat sa ulat! Tanong ni Joe. Sinabi mo na ang customer ay hindi nais na bigyan ang lahat ng access sa data. Sa mahigpit na pagsasalita, kung ang isang tao ay may resulta ng Explain Analyze, maaari niyang silipin ang data.

Parang ganun. Halimbawa, maaari naming isulat: "PUMILI MULA SA SAAN ang email = doon". Iyon ay, hindi namin makikita ang data mismo, ngunit maaari naming makita ang ilang mga hindi direktang palatandaan. Dapat itong maunawaan. Pero sa kabilang banda, nandoon na ang lahat. Mayroon kaming log audit, mayroon kaming kontrol sa iba pang mga kasamahan na nakikita din kung ano ang ginagawa ng mga developer. At kung ang isang tao ay sumusubok na gawin ito, pagkatapos ay ang serbisyo ng seguridad ay darating sa kanila at gagana sa isyung ito.

Magandang hapon Salamat sa ulat! May maikling tanong ako. Kung ang kumpanya ay hindi gumagamit ng Slack, mayroon bang anumang umiiral dito ngayon, o posible ba para sa mga developer na mag-deploy ng mga pagkakataon upang maikonekta ang isang pagsubok na application sa mga database?

Ngayon ay may isang link sa Slack, ibig sabihin, walang ibang messenger, ngunit gusto ko rin talagang gumawa ng suporta para sa iba pang mga messenger. Ano ang kaya mong gawin? Maaari kang mag-deploy ng DB Lab nang walang Joe, pumunta sa tulong ng REST API o sa tulong ng aming platform at lumikha ng mga clone at kumonekta sa PSQL. Ngunit magagawa ito kung handa ka nang bigyan ang iyong mga developer ng access sa data, dahil wala nang anumang screen.

Hindi ko kailangan ang layer na ito, ngunit kailangan ko ng ganitong pagkakataon.

Pagkatapos ay oo, maaari itong gawin.

Pinagmulan: www.habr.com