DBA bot Joe. Anatoly Stansler (Postgres.ai)

Kumaha pamekar backend ngartos yén query SQL bakal dianggo saé dina "prod"? Dina pausahaan badag atawa ngembang pesat, teu sadaya jelema boga aksés ka "produk". Sareng kalayan aksés, henteu sadayana pamundut tiasa dipariksa tanpa nyeri, sareng nyiptakeun salinan pangkalan data sering peryogi sababaraha jam. Pikeun ngajawab masalah ieu, urang nyieun hiji DBA jieunan - Joe. Éta parantos suksés dilaksanakeun di sababaraha perusahaan sareng ngabantosan langkung ti belasan pamekar.

video:

Halo sadayana! Ngaran abdi Anatoly Stansler. Abdi damel di hiji perusahaan postgres.ai. Kami komitmen pikeun ngagancangkeun prosés pamekaran ku ngaleungitkeun telat anu aya hubunganana sareng karya Postgres ti pamekar, DBA sareng QA.

Kami ngagaduhan klien anu saé sareng dinten ayeuna bagian tina laporan bakal dikhususkeun pikeun kasus anu urang tepang nalika damel sareng aranjeunna. Kuring bakal ngobrol ngeunaan kumaha urang mantuan aranjeunna ngajawab masalah rada serius.

Nalika urang ngembang sareng ngalaksanakeun migrasi beban tinggi anu kompleks, urang naroskeun patarosan ka diri urang sorangan: "Naha migrasi ieu bakal angkat?". Kami nganggo ulasan, kami nganggo pangaweruh kolega anu langkung berpengalaman, ahli DBA. Sareng aranjeunna tiasa terang naha éta bakal ngapung atanapi henteu.

Tapi panginten langkung saé upami urang tiasa nguji éta sorangan dina salinan ukuran pinuh. Sareng ayeuna urang bakal ngobrol ngeunaan naon pendekatan pikeun nguji ayeuna sareng kumaha éta tiasa dilakukeun langkung saé sareng alat naon. Urang ogé bakal ngobrol ngeunaan pro sareng kontra ngeunaan pendekatan sapertos kitu, sareng naon anu urang tiasa ngalereskeun di dieu.

Saha anu kantos ngadamel indéks langsung dina prod atanapi ngadamel parobihan? Rada saeutik. Sareng pikeun saha ieu nyababkeun kanyataan yén data leungit atanapi aya downtime? Teras anjeun terang nyeri ieu. Alhamdulillah aya cadanganna.

Pendekatan kahiji nyaéta nguji dina prod. Atawa, lamun pamekar sits dina mesin lokal, anjeunna boga data test, aya sababaraha jenis Pilihan kawates. Sarta kami gulung kaluar prod, sarta kami meunang kaayaan ieu.

Nyeri, mahal. Ieu meureun pangalusna henteu.

Sareng naon cara anu pangsaéna pikeun ngalakukeunana?

Hayu urang nyandak pementasan tur pilih sababaraha bagian tina prod dinya. Atanapi anu pangsaéna, hayu urang nyandak prod nyata, sadaya data. Sarta sanggeus kami geus ngembangkeun éta lokal, urang Sajaba bakal pariksa keur pementasan.

Ieu bakal ngamungkinkeun urang pikeun ngahapus sababaraha kasalahan, nyaéta nyegah aranjeunna tina prod.

Naon masalahna?

• Masalahna nyaéta urang bagikeun pementasan ieu sareng kolega. Sarta sering pisan kajadian nu nyieun sababaraha jenis parobahan, bam - na euweuh data, karya handap solokan nu. Pementasan éta multi-terabyte. Jeung anjeun kudu ngadagoan lila pikeun eta naek deui. Sarta kami mutuskeun pikeun finalize eta isukan. Éta éta, urang gaduh pamekaran.
• Sareng, tangtosna, urang gaduh seueur kolega anu damel di dinya, seueur tim. Sareng éta kedah dilakukeun sacara manual. Jeung ieu teu merenah.

Sarta eta sia nyebutkeun yen urang boga ngan hiji usaha , hiji shot, lamun urang hayang nyieun sababaraha parobahan database, toél data, ngarobah struktur. Sareng upami aya anu salah, upami aya kasalahan dina migrasi, maka urang moal gancang ngagulung deui.

Ieu leuwih hade tinimbang pendekatan saméméhna, tapi masih aya kamungkinan luhur yén sababaraha jenis kasalahan bakal balik ka produksi.

Naon anu nyegah urang masihan unggal pamekar bangku tés, salinan ukuran pinuh? Jigana éta jelas naon meunang di jalan.

Saha anu gaduh database langkung ageung tibatan terabyte? Leuwih ti satengah kamar.

Sarta eta jelas yén ngajaga mesin pikeun tiap pamekar, lamun aya produksi badag misalna, pisan mahal, jeung sajaba ti, waktu nu diperlukeun lila.

Simkuring gaduh klien nu geus sadar yén éta pohara penting pikeun nguji sagala parobahan dina salinan full-ukuran, tapi database maranéhanana nyaéta kirang ti terabyte a, tur euweuh sumberdaya pikeun nyimpen hiji bangku test pikeun tiap pamekar. Ku alatan éta, maranéhna kudu ngundeur dumps lokal ka mesin maranéhanana sarta nguji ku cara ieu. Butuh loba waktu.

Sanaos anjeun ngalakukeun éta di jero infrastruktur, teras ngunduh hiji terabyte data per jam parantos saé pisan. Tapi aranjeunna nganggo dumps logis, aranjeunna unduh sacara lokal tina méga. Pikeun aranjeunna, lajuna sakitar 200 gigabyte per jam. Sareng masih peryogi waktos kanggo ngabalikan tina dump logis, gulungkeun indéks, jsb.

Tapi aranjeunna nganggo pendekatan ieu sabab ngamungkinkeun aranjeunna tetep prod dipercaya.

Naon anu bisa urang pigawé di dieu? Hayu urang ngadamel bangku tés murah sareng masihan unggal pamekar bangku tés sorangan.

Sarta ieu mungkin.

Sareng dina pendekatan ieu, nalika urang ngadamel klon ipis pikeun unggal pamekar, urang tiasa ngabagi kana hiji mesin. Contona, upami anjeun gaduh database 10TB tur hoyong masihan ka 10 pamekar, anjeun teu kudu boga XNUMX x XNUMXTB database. Anjeun ngan butuh hiji mesin pikeun nyieun salinan ipis terasing pikeun tiap pamekar ngagunakeun hiji mesin. Kuring gé ngabejaan Anjeun kumaha gawéna saeutik engké.

conto nyata:

• DB - 4,5 terabytes.

• Urang bisa meunangkeun salinan bebas dina 30 detik.

Anjeun teu kudu ngadagoan test stand sarta gumantung kana sabaraha badag éta. Anjeun tiasa meunang dina detik. Éta bakal janten lingkungan anu terasing, tapi anu ngabagi data diantara aranjeunna.

Ieu hébat. Di dieu urang ngobrol ngeunaan magic jeung alam semesta paralel.

Dina kasus urang, ieu jalan ngagunakeun sistem OpenZFS.

OpenZFS nyaéta sistem file copy-on-write anu ngadukung snapshots sareng clones out of the box. Ieu bisa dipercaya jeung scalable. Manehna pisan gampang pikeun ngatur. Éta sacara harfiah tiasa disebarkeun dina dua tim.

Aya pilihan séjén:

• lvm,

• Panyimpenan (contona, Panyimpenan Murni).

Database Lab anu kuring nyarioskeun nyaéta modular. Bisa dilaksanakeun ngagunakeun pilihan ieu. Tapi pikeun ayeuna, kami geus fokus kana OpenZFS, sabab aya masalah sareng LVM husus.

Kumaha gawéna? Gantina nulis ulang data unggal waktos urang ngarobah éta, urang simpen ku saukur nyirian yén data anyar ieu ti titik anyar dina jangka waktu, snapshot anyar.

Sarta dina mangsa nu bakal datang, nalika urang rék rollback atawa urang rék nyieun clone anyar tina sababaraha versi heubeul, urang ngan nyebutkeun: "OKÉ, masihan kami blok data ieu anu ditandaan kawas kieu."

Sareng pangguna ieu bakal tiasa dianggo sareng set data sapertos kitu. Anjeunna laun bakal ngarobah aranjeunna, nyieun snapshots sorangan.

Sarta kami bakal cabang. Masing-masing pamekar dina hal urang bakal ngagaduhan kasempetan pikeun gaduh klon sorangan anu diédit, sareng data anu dibagikeun bakal dibagi antara sadayana.

Pikeun nyebarkeun sistem sapertos di bumi, anjeun kedah ngabéréskeun dua masalah:

• Anu kahiji nyaéta sumber data, dimana anjeun bakal nyandak éta. Anjeun tiasa nyetél réplikasi sareng produksi. Anjeun parantos tiasa nganggo cadangan anu tos dikonpigurasikeun, mugia. WAL-E, WAL-G atanapi Barman. Sareng upami anjeun nganggo sababaraha jinis solusi Cloud sapertos RDS atanapi Cloud SQL, maka anjeun tiasa nganggo dumps logis. Tapi kami masih mamatahan anjeun nganggo cadangan, sabab ku pendekatan ieu anjeun ogé bakal nahan struktur fisik file, anu bakal ngidinan Anjeun pikeun jadi malah ngadeukeutan ka metrics nu bakal Anjeun tingali dina produksi guna nyekel eta masalah anu aya.

• Anu kadua nyaéta dimana anjeun badé janten host Lab Database. Bisa jadi Awan, bisa jadi On-premise. Kadé disebutkeun yen ZFS ngarojong komprési data. Sarta eta ngalakukeun eta cukup ogé.

Bayangkeun yén pikeun tiap klon sapertos kitu, gumantung kana operasi anu urang lakukeun sareng dasarna, sababaraha jinis dev bakal tumbuh. Pikeun ieu, dev ogé peryogi rohangan. Tapi kusabab kanyataan yén kami nyandak dasar 4,5 terabyte, ZFS bakal niiskeun kana 3,5 terabyte. Ieu bisa rupa-rupa gumantung kana setelan. Sareng urang masih gaduh rohangan pikeun dev.

Sistem sapertos kitu tiasa dianggo pikeun sababaraha kasus.

• Ieu mangrupikeun pamekar, DBA pikeun validasi pamundut, pikeun optimasi.

• Ieu tiasa dianggo dina uji QA pikeun nguji migrasi khusus sateuacan urang gulung ka prod. Sarta kami ogé bisa ngangkat lingkungan husus pikeun QA kalawan data nyata, dimana maranéhna bisa nguji fungsionalitas anyar. Sarta eta bakal butuh sababaraha detik tinimbang jam ngantosan, sarta meureun poé dina sababaraha kasus séjén dimana salinan ipis teu dipaké.

• Jeung kasus séjén. Upami perusahaan henteu gaduh sistem analitik anu nyetél, maka urang tiasa ngasingkeun klon ipis tina dasar produk sareng masihan ka patarosan panjang atanapi indéks khusus anu tiasa dianggo dina analitik.

Kalayan pendekatan ieu:

1. Kamungkinan low kasalahan dina "prod", sabab urang diuji sagala parobahan dina data full-ukuran.

2. Urang boga budaya nguji, sabab ayeuna anjeun teu kudu ngadagoan sababaraha jam pikeun nangtung sorangan.

3. Sareng teu aya halangan, henteu ngantosan antara tés. Anjeun sabenerna bisa balik sarta pariksa. Sareng bakal langkung saé ku cara ieu nalika urang nyepetkeun pangwangunan.

• Bakal aya kirang refactoring. Pangsaeutikna bug bakal mungkas dina prod. Urang bakal refactor aranjeunna kirang engké.

• Urang tiasa ngabalikeun parobahan anu teu tiasa dibalikkeun. Ieu sanés pendekatan standar.

1. Ieu mangpaatna sabab urang babagi sumberdaya bangku test.

Geus alus, tapi naon deui nu bisa gancangan?

Hatur nuhun kana sistem sapertos kitu, urang tiasa ngirangan ambang pikeun nguji sapertos kitu.

Ayeuna aya lingkaran setan dimana pamekar kedah janten ahli pikeun kéngingkeun aksés kana data ukuran pinuh. Anjeunna kedah dipercanten kalayan aksés sapertos kitu.

Tapi kumaha tumuwuh lamun teu aya. Tapi kumaha upami anjeun ngan ukur gaduh set data tés anu alit anu sayogi pikeun anjeun? Teras anjeun moal nampi pangalaman nyata.

Kumaha carana kaluar tina bunderan ieu? Salaku antarbeungeut anu munggaran, cocog pikeun pamekar tingkat naon waé, kami milih bot Slack. Tapi tiasa waé antarmuka anu sanés.

Naon eta ngidinan Anjeun pikeun ngalakukeun? Anjeun tiasa nyandak pamundut khusus sareng ngirimkeunana ka saluran khusus pikeun pangkalan data. Urang bakal otomatis nyebarkeun clone ipis dina sababaraha detik. Hayu urang ngajalankeun pamundut ieu. Kami ngumpulkeun métrik sareng saran. Hayu urang nunjukkeun visualisasi. Teras clone ieu bakal tetep supados pamundut ieu tiasa kumaha waé dioptimalkeun, tambahkeun indéks, jsb.

Sareng ogé Slack masihan kami kasempetan pikeun kolaborasi out of the box. Kusabab ieu ngan saluran, Anjeun bisa ngamimitian ngabahas pamundut ieu langsung aya dina thread pikeun pamundut kitu, ping kolega Anjeun, DBAs nu aya di jero pausahaan.

Tapi aya, tangtosna, masalah. Kusabab ieu dunya nyata, sarta kami nuju ngagunakeun server hosting loba clones sakaligus, urang kudu niiskeun jumlah memori jeung kakuatan CPU sadia pikeun clones.

Tapi pikeun tés ieu janten masuk akal, anjeun kedah kumaha waé ngabéréskeun masalah ieu.

Ieu jelas yén titik penting nyaéta data sarua. Tapi urang geus boga eta. Sareng urang hoyong ngahontal konfigurasi anu sami. Sareng urang tiasa masihan konfigurasi anu ampir sami.

Éta langkung saé upami gaduh hardware anu sami sareng produksi, tapi tiasa bénten.

Hayu urang apal kumaha Postgres jalan kalawan memori. Simkuring gaduh dua caches. Hiji ti sistem file sareng hiji Postgres asli, nyaéta Shared Buffer Cache.

Kadé dicatet yén Shared panyangga Cache disadiakeun nalika Postgres dimimitian, gumantung kana ukuran naon anjeun tangtukeun dina konfigurasi nu.

Jeung cache kadua ngagunakeun sakabeh spasi sadia.

Sareng nalika urang ngadamel sababaraha klon dina hiji mesin, tétéla urang laun-laun ngeusian mémori. Sarta dina cara alus, dibagikeun panyangga Cache 25% tina jumlah total memori anu sadia dina mesin.

Sareng tétéla yén upami urang henteu ngarobih parameter ieu, maka urang ngan ukur tiasa ngajalankeun 4 instansi dina hiji mesin, nyaéta 4 sadaya klon ipis sapertos kitu. Sareng ieu, tangtosna, goréng, sabab urang hoyong gaduh seueur deui.

Tapi di sisi séjén, panyangga Cache dipaké pikeun ngaéksekusi queries pikeun indexes, nyaeta, rencana gumantung kana sabaraha badag caches urang. Sareng upami urang ngan ukur nyandak parameter ieu sareng ngirangan, maka rencana urang tiasa robih pisan.

Contona, upami urang boga cache badag dina prod, lajeng Postgres bakal resep ngagunakeun indéks. Sareng upami henteu, maka bakal aya SeqScan. Jeung naon nu bakal jadi titik lamun rencana urang teu coincide?

Tapi di dieu urang datang ka kacindekan yen kanyataanna rencana di Postgres henteu gumantung kana ukuran husus dieusian dina Shared panyangga dina rencana, eta gumantung kana effective_cache_size.

Effective_cache_size mangrupikeun perkiraan jumlah cache anu sayogi pikeun urang, nyaéta jumlah panyangga Cache sareng cache sistem file. Ieu diatur ku config. Jeung memori ieu teu disadiakeun.

Sarta alatan parameter ieu, urang tiasa jenis trik Postgres, nyebutkeun yen urang sabenerna boga loba data sadia, sanajan urang teu boga data ieu. Ku kituna, rencana bakal sagemblengna coincide jeung produksi.

Tapi ieu tiasa mangaruhan waktosna. Sareng urang ngaoptimalkeun patarosan ku waktos, tapi penting yén waktosna gumantung kana sababaraha faktor:

• Eta gumantung kana beban anu ayeuna on prod.

• Eta gumantung kana karakteristik mesin sorangan.

Sareng ieu mangrupikeun parameter henteu langsung, tapi nyatana urang tiasa ngaoptimalkeun persis ku jumlah data anu bakal dibaca ku pamundut ieu pikeun kéngingkeun hasilna.

Sareng upami anjeun hoyong waktosna caket sareng anu bakal urang tingali dina prod, maka urang kedah nyandak hardware anu paling mirip sareng, sigana, bahkan langkung-langkung supados sadayana klon pas. Tapi ieu mangrupikeun kompromi, nyaéta anjeun bakal nampi rencana anu sami, anjeun bakal ningali sabaraha data anu bakal dibaca ku pamundut khusus sareng anjeun bakal tiasa nyimpulkeun naha pamundut ieu saé (atanapi migrasi) atanapi goréng, éta masih kedah dioptimalkeun. .

Hayu urang tingali kumaha Joe dioptimalkeun sacara khusus.

Hayu urang nyandak pamundut ti sistem nyata. Dina hal ieu, pangkalan data nyaéta 1 terabyte. Sareng urang hoyong ngitung jumlah tulisan seger anu ngagaduhan langkung ti 10 likes.

Kami nyerat pesen ka saluran, clone parantos dipasang pikeun kami. Sareng urang bakal ningali yén pamundut sapertos kitu bakal réngsé dina 2,5 menit. Ieu hal kahiji urang perhatikeun.

B Joe bakal nunjukkeun anjeun rekomendasi otomatis dumasar kana rencana sareng métrik.

Urang bakal nempo yén query ngolah teuing data pikeun meunangkeun jumlah rélatif leutik baris. Sareng sababaraha jinis indéks khusus diperyogikeun, sabab kami perhatikeun yén aya seueur teuing barisan anu disaring dina pamundut.

Hayu urang nempo leuwih deukeut naon kajadian. Mémang, urang tingali yén kami parantos maca ampir hiji satengah gigabytes data tina cache file atanapi bahkan tina disk. Sareng ieu henteu saé, sabab kami ngan ukur ngagaduhan 142 garis.

Sareng, sigana, urang gaduh panyeken indéks di dieu sareng kedahna gancang-gancang, tapi saprak urang nyaring seueur teuing garis (urang kedah ngitung aranjeunna), pamundutna lalaunan.

Sareng ieu kajantenan dina rencana kusabab kanyataan yén kaayaan dina pamundut sareng kaayaan dina indéks sawaréh henteu cocog.

Hayu urang coba nyieun indéks leuwih tepat tur tingal kumaha palaksanaan query robah sanggeus éta.

Nyiptakeun indéks nyandak waktos anu lami, tapi ayeuna urang pariksa pamundut sareng ningali yén waktosna tibatan 2,5 menit ngan ukur 156 milliseconds, anu cukup saé. Sareng kami ngan ukur maca 6 megabytes data.

Sareng ayeuna urang nganggo indéks ukur scan.

Carita penting séjén nyaéta yén urang badé nampilkeun rencana éta dina sababaraha cara anu langkung kaharti. Kami parantos ngalaksanakeun visualisasi nganggo Flame Graphs.

Ieu paménta béda, leuwih sengit. Sareng urang ngawangun Grafik Seuneu dumasar kana dua parameter: ieu mangrupikeun jumlah data anu diitung titik tinangtu dina rencana sareng waktos, nyaéta waktos palaksanaan titik.

Di dieu urang bisa ngabandingkeun titik husus saling. Sarta eta bakal écés nu di antarana nyokot leuwih atawa kurang, nu biasana hésé ngalakukeun dina métode Rendering séjén.

Tangtosna, sadayana terang terang.depesz.com. Fitur anu hadé tina visualisasi ieu nyaéta urang nyimpen rencana téks sareng nempatkeun sababaraha parameter dasar kana méja supados urang tiasa nyortir.

Jeung pamekar anu teu acan delved kana topik ieu ogé ngagunakeun explain.depesz.com, sabab eta leuwih gampang pikeun manggihan nu metrics penting jeung nu henteu.

Aya pendekatan anyar pikeun visualisasi - ieu explain.dalibo.com. Aranjeunna ngalakukeun visualisasi tangkal, tapi sesah pisan pikeun ngabandingkeun titik-titik saling. Di dieu anjeun bisa ngarti struktur ogé, kumaha oge, lamun aya paménta badag, mangka anjeun kudu ngagulung deui mudik, tapi ogé hiji pilihan.

gawé bareng

Sareng, sakumaha anu kuring nyarios, Slack masihan kami kasempetan pikeun kolaborasi. Salaku conto, upami urang mendakan patarosan kompleks anu henteu jelas kumaha ngaoptimalkeun, urang tiasa netelakeun masalah ieu sareng kolega urang dina benang di Slack.

Sigana urang yén hal anu penting pikeun nguji dina data full-ukuran. Jang ngalampahkeun ieu, kami ngadamel alat Update Database Lab, anu sayogi dina open source. Anjeun tiasa nganggo bot Joe ogé. Anjeun tiasa nyandak éta ayeuna sareng nerapkeunana di tempat anjeun. Sadaya pituduh sayogi di dinya.

Éta ogé penting pikeun dicatet yén solusi sorangan teu revolusioner, sabab aya Delphix, tapi mangrupa solusi perusahaan. Ieu sagemblengna ditutup, éta pisan mahal. Urang husus husus dina Postgres. Ieu kabeh produk open source. Ngahiji sareng Kami!

Ieu dimana kuring mungkas. Hatur nuhun!

patarosan

Halo! Hatur nuhun laporan! Pisan metot, hususna keur kuring, sabab kuring direngsekeun ngeunaan masalah anu sarua sababaraha waktu ka tukang. Janten kuring gaduh sababaraha patarosan. Muga kuring bakal meunang sahenteuna bagian tina eta.

Kuring heran kumaha anjeun ngitung tempat pikeun lingkungan ieu? Téknologi ngandung harti yén dina kaayaan nu tangtu, klon Anjeun bisa tumuwuh nepi ka ukuran maksimum. Sacara kasar, upami anjeun gaduh database sapuluh terabyte sareng 10 klon, maka gampang pikeun simulasi kaayaan dimana unggal klon beuratna 10 data unik. Kumaha anjeun ngitung tempat ieu, nyaéta, délta anu anjeun nyarioskeun, dimana klon ieu bakal hirup?

Patarosan alus. Penting pikeun ngalacak klon khusus di dieu. Sareng upami clone ngagaduhan parobihan anu ageung, éta mimiti tumbuh, maka urang tiasa mimiti ngaluarkeun peringatan ka pangguna ngeunaan ieu, atanapi langsung ngeureunkeun clone ieu supados urang henteu ngagaduhan kaayaan anu gagal.

Sumuhun, abdi gaduh patarosan nested. Maksudna, kumaha anjeun mastikeun siklus hirup modul ieu? Kami ngagaduhan masalah ieu sareng carita anu misah. Kumaha ieu kajadian?

Aya sababaraha ttl pikeun tiap klon. Dasarna, urang gaduh ttl tetep.

Naon, lamun teu rusiah?

1 jam, nyaéta dianggurkeun - 1 jam. Lamun teu dipaké, teras urang bang eta. Tapi teu aya kejutan di dieu, sabab urang tiasa ngangkat clone dina sababaraha detik. Sareng upami anjeun peryogi deui, mangga.

Kuring ogé resep kana pilihan téknologi, sabab, contona, kami nganggo sababaraha metode paralel pikeun hiji alesan atanapi anu sanés. Naha ZFS? Naha anjeun henteu nganggo LVM? Anjeun disebutkeun yen aya masalah sareng LVM. Naon masalahna? Dina pamanggih kuring, pilihan anu paling optimal nyaéta kalayan neundeun, dina hal kinerja.

Naon masalah utama ZFS? Kanyataan yén anjeun kedah ngajalankeun dina host anu sami, nyaéta sadaya instansi bakal hirup dina OS anu sami. Sareng dina kasus neundeun, anjeun tiasa nyambungkeun alat anu béda. Sareng bottleneck ngan ukur blok anu aya dina sistem panyimpen. Sareng sual pilihan téknologi anu pikaresepeun. Naha henteu LVM?

Husus, urang tiasa ngabahas LVM di meetup. Ngeunaan neundeun - éta ngan mahal. Urang tiasa nerapkeun sistem ZFS dimana waé. Anjeun tiasa nyebarkeun éta dina mesin anjeun. Anjeun ngan saukur tiasa ngaunduh gudang sareng nyebarkeunana. ZFS dipasang ampir di mana waé upami urang nyarioskeun Linux. Hartina, urang meunang solusi pisan fléksibel. Sarta ZFS sorangan méré loba out of the box. Anjeun tiasa unggah saloba data anu anjeun pikahoyong, sambungkeun sajumlah ageung disk, aya snapshot. Jeung, sakumaha ceuk kuring, éta gampang pikeun administer. Maksudna, sigana pisan pikaresepeun ngagunakeun. Anjeunna diuji, umurna mangtaun-taun. Anjeunna ngagaduhan komunitas anu ageung pisan anu ngembang. ZFS mangrupikeun solusi anu tiasa dipercaya.

Nikolai Samokhvalov: Dupi abdi tiasa mairan salajengna? Ngaran abdi Nikolay, urang gawé bareng jeung Anatoly. Kuring satuju yén gudang hébat. Sareng sababaraha konsumén urang gaduh Panyimpenan Murni jsb.

Anatoly leres nyatet yén kami fokus kana modularitas. Sareng di hareup, anjeun tiasa nerapkeun hiji antarmuka - nyandak snapshot, ngadamel clone, ngancurkeun clone. Éta sadayana gampang. Jeung neundeun téh tiis, lamun éta.

Tapi ZFS sayogi pikeun sadayana. DelPhix parantos cekap, aranjeunna gaduh 300 klien. Tina ieu, rejeki 100 ngagaduhan 50 klien, nyaéta aranjeunna ditujukeun ka NASA, jsb. Waktosna pikeun sadayana kéngingkeun téknologi ieu. Sareng sababna urang gaduh Inti open source. Kami ngagaduhan bagian antarmuka anu henteu open source. Ieu mangrupikeun platform anu bakal kami tunjukkeun. Tapi kami hoyong éta tiasa diaksés ku sadayana. Kami hoyong ngadamel révolusi supados sadayana panguji lirén nebak dina laptop. Urang kudu nulis PILIH jeung geura tingali yén éta téh slow. Ngeureunkeun ngantosan DBA ngabejaan Anjeun tentang eta. Ieu tujuan utama. Sareng kuring nyangka yén urang sadayana bakal dugi ka ieu. Sarta kami nyieun hal ieu for everyone boga. Kituna ZFS, sabab bakal sadia madhab. Hatur nuhun ka komunitas pikeun ngarengsekeun masalah sareng gaduh lisénsi open source, jsb.*

salam wanoh! Hatur nuhun laporan! Ngaran abdi Maxim. Kami parantos ngurus masalah anu sami. Aranjeunna mutuskeun sorangan. Kumaha anjeun ngabagi sumber antara klon ieu? Unggal klon tiasa ngalakukeun hal sorangan iraha waé: hiji nguji hiji hal, anu sanés, batur ngawangun indéks, batur ngagaduhan padamelan anu beurat. Sareng upami anjeun masih tiasa ngabagi CPU, teras ku IO, kumaha anjeun ngabagi? Ieu patarosan kahiji.

Jeung patarosan kadua ngeunaan dissimilarity tina stand. Hayu urang nyebutkeun kuring boga ZFS dieu jeung sagalana geus tiis, tapi klien on prod teu ZFS, tapi ext4, contona,. Kumaha dina hal ieu?

Patarosan anu saé pisan. Kuring disebutkeun masalah ieu bit kalawan kanyataan yén urang babagi sumberdaya. Jeung leyuran ieu. Bayangkeun yén anjeun nguji dina pementasan. Anjeun ogé tiasa gaduh kaayaan sapertos kitu dina waktos anu sami anu masihan hiji beban, anu sanés. Sareng hasilna, anjeun ningali métrik anu teu kaharti. Malah masalah anu sarua bisa jadi kalawan prod. Nalika anjeun hoyong pariksa sababaraha pamundut tur tingal yen aya sababaraha masalah jeung eta - gawéna lalaunan, lajeng dina kanyataanana masalah teu di pamundut, tapi kanyataan yén aya sababaraha jenis beban paralel.

Ku sabab éta, penting di dieu pikeun difokuskeun naon rencanana, léngkah-léngkah naon anu bakal urang laksanakeun dina rencana éta sareng sabaraha data anu bakal kami kumpulkeun pikeun ieu. Kanyataan yén disk urang, contona, bakal dieusian ku hal, éta bakal mangaruhan husus timing. Tapi urang tiasa estimasi kumaha dimuat pamundut ieu ku jumlah data. Henteu penting pisan yén dina waktos anu sami bakal aya sababaraha palaksanaan.

Abdi gaduh dua patarosan. Ieu barang keren pisan. Naha aya kasus dimana data produksi penting, sapertos nomer kartu kiridit? Naha aya anu siap atanapi éta tugas anu misah? Sareng patarosan kadua - naha aya anu sapertos ieu pikeun MySQL?

Ngeunaan data. Urang bakal ngalakukeun obfuscation dugi kami ngalakukeun. Tapi upami anjeun nyebarkeun persis Joe, upami anjeun henteu masihan aksés ka pamekar, maka henteu aya aksés kana data. Naha? Kusabab Joe henteu nunjukkeun data. Éta ngan ukur nunjukkeun métrik, rencana sareng éta waé. Hal ieu dilakukeun sacara ngahaja, sabab ieu mangrupikeun salah sahiji sarat klien kami. Aranjeunna hoyong tiasa ngaoptimalkeun tanpa masihan aksés ka sadayana.

Ngeunaan MySQL. Sistem ieu tiasa dianggo pikeun naon waé anu nyimpen kaayaan dina disk. Sarta saprak urang ngalakukeun Postgres, urang ayeuna ngalakonan sagala automation pikeun Postgres munggaran. Kami hoyong ngajadikeun otomatis nyandak data tina cadangan. Kami ngonpigurasikeun Postgres leres. Urang terang kumaha carana sangkan rencana cocog, jsb.

Tapi kusabab sistemna tiasa diperpanjang, éta ogé tiasa dianggo pikeun MySQL. Sareng aya conto sapertos kitu. Yandex gaduh hal anu sami, tapi aranjeunna henteu nyebarkeun dimana waé. Maranehna ngagunakeun eta di jero Yandex.Metrica. Sareng ngan ukur aya carita ngeunaan MySQL. Tapi téknologina sami, ZFS.

Hatur nuhun laporan! Abdi ogé gaduh sababaraha patarosan. Anjeun nyarios yén kloning tiasa dianggo pikeun analitik, contona pikeun ngawangun indéks tambahan di dinya. Naha anjeun tiasa nyarios langkung seueur ngeunaan kumaha jalanna?

Sareng kuring bakal langsung naroskeun patarosan kadua ngeunaan kamiripan lapak, kamiripan rencana. Rencanana ogé gumantung kana statistik anu dikumpulkeun ku Postgres. Kumaha anjeun ngajawab masalah ieu?

Numutkeun kana analytics, henteu aya kasus khusus, sabab kami henteu acan dianggo, tapi aya kasempetan sapertos kitu. Lamun urang ngobrol ngeunaan indexes, lajeng ngabayangkeun yén query a chasing tabel kalawan ratusan juta rékaman sarta kolom nu biasana teu saestuna dina prod. Sarta kami rék ngitung sababaraha data aya. Lamun pamundut ieu dikirim ka prod, lajeng aya kamungkinan yén éta bakal basajan on prod, sabab pamundut bakal diolah aya pikeun menit.

Muhun, hayu urang nyieun clone ipis nu teu dahsyat eureun pikeun sababaraha menit. Sareng supados langkung saé maca analitik, kami bakal nambihan indéks pikeun kolom anu kami resep kana data.

indéks bakal dijieun unggal waktu?

Anjeun tiasa ngadamel éta supados urang nyabak data, ngadamel snapshot, teras urang bakal pulih tina snapshot ieu sareng ngajalankeun pamundut énggal. Nyaéta, anjeun tiasa ngadamel éta supados anjeun tiasa naékkeun klon énggal kalayan indéks anu parantos dipasang.

Sedengkeun pikeun patarosan ngeunaan statistik, lamun urang balikkeun ti cadangan, lamun urang ngalakukeun réplikasi, mangka statistik urang bakal persis sarua. Kusabab urang gaduh sakabéh struktur data fisik, nyaeta, urang bakal mawa data sakumaha anu kasebut kalayan sagala metrics statistik teuing.

Ieu masalah sejen. Upami anjeun nganggo solusi awan, maka ngan ukur dump logis anu sayogi, sabab Google, Amazon henteu ngamungkinkeun anjeun nyandak salinan fisik. Bakal aya masalah.

Hatur nuhun kana laporan. Aya dua patarosan anu saé ngeunaan MySQL sareng ngabagi sumber daya. Tapi, kanyataanna, éta sadayana turun kana kanyataan yén ieu sanés topik DBMS khusus, tapi sistem file sacara gembleng. Sareng, sasuai, masalah ngabagi sumber daya ogé kedah direngsekeun ti dinya, sanés dina tungtung éta Postgres, tapi dina sistem file, dina server, contona.

Patarosan abdi rada béda. Éta ngadeukeutan ka database multi-layered, dimana aya sababaraha lapisan. Contona, urang nyetél update gambar sapuluh-terabyte, urang ngayakeun réplikasi. Sarta kami husus ngagunakeun solusi ieu pikeun database. Réplikasi keur lumangsung, data keur diropéa. Aya 100 pagawé anu sajajar di dieu, anu terus-terusan ngaluncurkeun nembak anu béda-béda ieu. Naon anu kedah dilakukeun? Kumaha pikeun mastikeun yén teu aya konflik, aranjeunna dibuka hiji, lajeng sistem file robah, sarta gambar ieu sadayana indit?

Aranjeunna moal balik sabab éta kumaha ZFS jalan. Urang bisa nyimpen misah dina hiji thread parobahan sistem file nu datang alatan réplikasi. Sareng jaga klon anu dianggo ku pamekar dina vérsi data anu langkung lami. Sarta gawéna pikeun urang, sagalana aya dina urutan kalawan ieu.

Tétéla yén update bakal lumangsung salaku lapisan tambahan, sarta sakabeh gambar anyar bakal balik geus, dumasar kana lapisan ieu, katuhu?

Ti lapisan saméméhna anu ti réplikasi saméméhna.

Lapisan saméméhna bakal layu atawa gugur, tapi maranéhna bakal ngarujuk kana lapisan heubeul, sarta aranjeunna bakal nyandak gambar anyar tina lapisan panungtungan nu narima di update teh?

Sacara umum, enya.

Lajeng salaku konsekuensi urang bakal boga nepi ka anjir lapisan. Sareng kana waktosna aranjeunna kedah dikomprés?

Sumuhun sadayana leres. Aya sababaraha jandela. Urang nyimpen snapshot mingguan. Eta gumantung kana naon sumberdaya anjeun boga. Upami Anjeun gaduh kamampuhan pikeun nyimpen loba data, Anjeun bisa nyimpen snapshots pikeun lila. Aranjeunna moal angkat nyalira. Moal aya korupsi data. Lamun snapshots geus luntur, sakumaha sigana urang, i.e. gumantung kana kawijakan di parusahaan, urang ngan saukur bisa ngahapus aranjeunna sarta ngosongkeun spasi.

Halo, hatur nuhun pikeun laporan! Patarosan ngeunaan Joe. Anjeun nyarios yén nasabah henteu hoyong masihan sadayana aksés kana data. Tegesna, lamun hiji jalma miboga hasil Explain Analyze, mangka manéhna bisa ngintip datana.

Sapertos kitu. Contona, urang bisa nulis: "PILIH FROM WHERE email = ka nu". Hartina, urang moal ningali data sorangan, tapi urang bisa ningali sababaraha tanda teu langsung. Ieu kudu dipikaharti. Tapi di sisi séjén, éta sadayana aya. Simkuring boga Inok log, urang boga kontrol kolega séjén anu ogé ningali naon pamekar lakukeun. Sareng upami aya anu nyobian ngalakukeun ieu, maka jasa kaamanan bakal sumping ka aranjeunna sareng ngusahakeun masalah ieu.

Wilujeng sonten Hatur nuhun laporan! Abdi gaduh patarosan pondok. Upami perusahaan henteu nganggo Slack, naha aya anu ngariung ayeuna, atanapi naha pamekar tiasa nyebarkeun instansi pikeun nyambungkeun aplikasi tés kana pangkalan data?

Ayeuna aya tautan ka Slack, nyaéta henteu aya utusan sanés, tapi kuring ogé hoyong ngadukung utusan sanés. Anjeun tiasa naon? Anjeun tiasa nyebarkeun DB Lab tanpa Joe, angkat kalayan bantosan REST API atanapi kalayan bantosan platform kami sareng nyiptakeun klon sareng nyambung sareng PSQL. Tapi ieu tiasa dilakukeun upami anjeun siap masihan pamekar anjeun aksés kana data, sabab moal aya deui layar.

Abdi henteu peryogi lapisan ieu, tapi kuring peryogi kasempetan sapertos kitu.

Teras enya, éta tiasa dilakukeun.

sumber: www.habr.com