Kontribusi Yandex menyang database ing ngisor iki bakal dideleng.
- clickhouse
- Odyssey
- Recovery to a point in time (WAL-G)
- PostgreSQL (kalebu logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Hello donya! Jenengku Andrey Borodin. Lan apa sing ditindakake ing Yandex.Cloud yaiku ngembangake basis data relasional sing mbukak kanggo kepentingan klien Yandex.Cloud lan Yandex.Cloud.
Ing pirembagan iki, kita bakal ngomong babagan tantangan sing diadhepi ing basis data mbukak kanthi skala. Apa sebabe penting? Amarga masalah cilik sing, kaya nyamuk, banjur dadi gajah. Padha dadi gedhe nalika sampeyan duwe akeh klompok.
Nanging dudu sing utama. Kedadeyan sing luar biasa. Iku sing kelakon ing siji ing yuta kasus. Lan ing lingkungan maya, sampeyan kudu siyap, amarga kedadeyan sing luar biasa dadi kemungkinan gedhe nalika ana ing skala.
Nanging! Apa keuntungan saka database mbukak? Kasunyatane sampeyan duwe kesempatan teoritis kanggo ngatasi masalah apa wae. Sampeyan duwe kode sumber, sampeyan duwe kawruh pemrograman. Kita gabungke lan kerjane.
Apa pendekatan sing ana ing nggarap piranti lunak sumber terbuka?
- Pendekatan sing paling gampang yaiku nggunakake piranti lunak. Yen sampeyan nggunakake protokol, yen sampeyan nggunakake standar, yen sampeyan nggunakake format, yen sampeyan nulis pitakon ing piranti lunak open source, sampeyan wis ndhukung.
- Sampeyan nggawe ekosistem luwih gedhe. Sampeyan nggawe kemungkinan deteksi awal bug luwih gedhe. Sampeyan nambah linuwih sistem iki. Sampeyan nambah kasedhiyan pangembang ing pasar. Sampeyan nambah piranti lunak iki. Sampeyan wis dadi kontributor yen sampeyan mung nggawe gaya lan tinkered karo soko ana.
- Pendekatan liyane sing bisa dingerteni yaiku nyeponsori piranti lunak sumber terbuka. Contone, program Google Summer of Code sing kondhang, nalika Google mbayar akeh siswa saka kabeh ndonya sing bisa dingerteni dhuwit supaya bisa ngembangake proyek piranti lunak mbukak sing nyukupi syarat lisensi tartamtu.
- Iki minangka pendekatan sing menarik banget amarga ngidini piranti lunak berkembang tanpa ngalih fokus saka komunitas. Google, minangka raksasa teknologi, ora ujar manawa kita pengin fitur iki, kita pengin ndandani bug iki lan ing kene kita kudu digali. Google ngandika: "Tindakake apa sing sampeyan lakoni. Mung terus kerja kaya sing wis ditindakake lan kabeh bakal apik."
- Pendekatan sabanjure kanggo melu ing open source yaiku partisipasi. Yen sampeyan duwe masalah ing piranti lunak open source lan ana pangembang, pangembang sampeyan miwiti ngrampungake masalah kasebut. Dheweke wiwit nggawe infrastruktur sampeyan luwih efisien, program sampeyan luwih cepet lan luwih dipercaya.
Salah sawijining proyek Yandex sing paling misuwur ing bidang piranti lunak sumber terbuka yaiku ClickHouse. Iki minangka basis data sing lair minangka respon kanggo tantangan sing diadhepi Yandex.Metrica.
Lan minangka basis data, digawe ing open source kanggo nggawe ekosistem lan ngembangake bebarengan karo pangembang liyane (ora mung ing Yandex). Lan saiki iki minangka proyek gedhe sing melu macem-macem perusahaan.
Ing Yandex.Cloud, kita nggawe ClickHouse ing ndhuwur Panyimpenan Obyek Yandex, yaiku ing ndhuwur panyimpenan maya.
Napa iki penting ing méga? Amarga database apa wae bisa digunakake ing segitiga iki, ing piramida iki, ing hirarki jinis memori iki. Sampeyan duwe ndhaptar cepet nanging cilik lan murah SSD gedhe nanging alon, hard drive lan sawetara piranti pamblokiran liyane. Lan yen sampeyan efisien ing ndhuwur piramida, sampeyan duwe database cepet. yen sampeyan efisien ing ngisor piramida iki, sampeyan duwe database skala. Lan ing babagan iki, nambah lapisan liyane saka ngisor minangka pendekatan logis kanggo nambah skalabilitas database.
Kepiye carane bisa ditindakake? Iki minangka titik penting ing laporan iki.
- Kita bisa ngetrapake ClickHouse liwat MDS. MDS minangka antarmuka panyimpenan maya Yandex internal. Iku luwih rumit tinimbang protokol S3 umum, nanging luwih cocok kanggo piranti pamblokiran. Iku luwih apik kanggo ngrekam data. Mbutuhake luwih akeh pemrograman. Programer bakal program, malah apik, iku menarik.
- S3 minangka pendekatan sing luwih umum sing ndadekake antarmuka luwih gampang kanthi biaya adaptasi sing kurang kanggo jinis beban kerja tartamtu.
Alami, pengin nyedhiyakake fungsi kanggo kabeh ekosistem ClickHouse lan nindakake tugas sing dibutuhake ing Yandex.Cloud, kita mutusake kanggo mesthekake yen kabeh komunitas ClickHouse bakal entuk manfaat saka iku. Kita ngetrapake ClickHouse liwat S3, ora ClickHouse liwat MDS. Lan iki akeh karya.
Cathetan:
"Lapisan abstraksi sistem file"
"Integrasi AWS SDK S3"
"Implementasi basis antarmuka IDisk kanggo S3"
"Integrasi mesin panyimpenan log kanthi antarmuka IDisk"
"Dhukungan mesin log kanggo S3 lan SeekableReadBuffer"
"Dukungan Storage Stripe Log S3"
"Dhukungan awal Storage MergeTree kanggo S3"
"Dhukungan lengkap MergeTree kanggo S3"
"Dhukungan ReplicatedMergeTree liwat S3"
"Tambah kredensial standar lan header khusus kanggo panyimpenan s3"
"S3 kanthi konfigurasi proxy dinamis"
"S3 karo solusi proxy"
Iki minangka dhaptar panjaluk tarik kanggo ngetrapake sistem file virtual ing ClickHouse. Iki nomer akeh panjalukan narik.
Cathetan:
"Implementasi optimal hardlinks DiskS3"
"Klien HTTP S3 - Aja nyalin stream respon menyang memori"
"Aja nyalin kabeh aliran respon menyang memori ing S3 HTTP
klien"
"Kemampuan kanggo tandha cache lan ngindeks file kanggo disk S3"
"Pindhah bagean saka DiskLocal menyang DiskS3 kanthi paralel"
Nanging karya ora mungkasi ing kono. Sawise fitur kasebut digawe, sawetara karya liyane dibutuhake kanggo ngoptimalake fungsi kasebut.
Cathetan:
"Tambah acara SelectedRows lan SelectedBytes"
"Tambah acara profil saka panjalukan S3 menyang system.events"
"Tambah QueryTimeMicroseconds, SelectQueryTimeMicroseconds lan InsertQueryTimeMicroseconds"
Banjur perlu kanggo nggawe diagnosis, nyiyapake ngawasi lan bisa diatur.
Lan kabeh iki ditindakake supaya kabeh komunitas, kabeh ekosistem ClickHouse, nampa asil karya iki.
Ayo pindhah menyang database transaksional, menyang database OLTP, sing luwih cedhak karo aku pribadi.
Iki minangka divisi pangembangan DBMS open source. Wong lanang iki nindakake sihir dalan kanggo nambah database mbukak transaksional.
Salah sawijining proyek, nggunakake conto sing bisa kita pirembagan babagan carane lan apa sing kita lakoni, yaiku Connection Pooler ing Postgres.
Postgres minangka basis data proses. Iki tegese database kudu duwe sawetara sambungan jaringan sing bisa nangani transaksi.
Ing sisih liya, ing lingkungan maya, kahanan sing khas yaiku nalika sewu sambungan teka ing siji kluster bebarengan. Lan tugas pooler sambungan iku kanggo Pack sewu sambungan menyang nomer cilik sambungan server.
Kita bisa ngomong sing pooler sambungan iku operator telpon sing rearranges bait supaya padha irit tekan database.
Sayange, ora ana tembung Rusia sing apik kanggo pooler sambungan. Kadhangkala disebut sambungan multiplexer. Yen sampeyan ngerti apa kanggo nelpon pooler sambungan, banjur dadi manawa kanggo pitutur marang aku, aku bakal seneng banget ngomong basa technical Russian bener.
We nyelidiki poolers sambungan sing cocog kanggo klompok postgres ngatur. Lan PgBouncer minangka pilihan sing paling apik kanggo kita. Nanging kita nemoni sawetara masalah karo PgBouncer. Akeh taun kepungkur, Volodya Borodin menehi laporan yen kita nggunakake PgBouncer, kita seneng kabeh, nanging ana nuansa, ana sing bisa digarap.
Lan kita makarya. Kita ndandani masalah sing kita temoni, kita nambal Bouncer, lan nyoba nyurung panjaluk tarik ing hulu. Nanging dhasar single-threading angel digarap.
Kita kudu ngumpulake kaskade saka Bouncers sing ditambal. Nalika kita duwe akeh Bouncers siji-Utas, sambungan ing lapisan ndhuwur ditransfer menyang lapisan utama Bouncers. Iki minangka sistem sing ora dikelola kanthi apik sing angel dibangun lan ukurane bolak-balik.
We teka menyang kesimpulan sing nggawe pooler sambungan dhewe, kang disebut Odyssey. Kita nulis saka awal.
Ing 2019, ing konferensi PgCon, aku nampilake pooler iki menyang komunitas pangembang. Saiki kita duwe kurang saka 2 bintang ing GitHub, yaiku proyek kasebut urip, proyek kasebut populer.
Lan yen sampeyan nggawe kluster Postgres ing Yandex.Cloud, mula bakal dadi kluster kanthi Odyssey sing dibangun, sing dikonfigurasi ulang nalika nggedhekake kluster kasebut bali utawa maju.
Apa sing kita sinau saka proyek iki? Ngluncurake proyek saingan mesthi minangka langkah agresif, minangka langkah sing ekstrem nalika ujar manawa ana masalah sing ora bisa dirampungake kanthi cepet, ora ditanggulangi ing interval wektu sing cocog karo kita. Nanging iki minangka langkah sing efektif.
PgBouncer wiwit berkembang luwih cepet.
Lan saiki proyek liyane wis muncul. Contone, pgagroal, sing dikembangake dening pangembang Red Hat. Padha ngupayakake tujuan sing padha lan ngleksanakake gagasan sing padha, nanging, mesthi, kanthi spesifik dhewe, sing luwih cedhak karo pangembang pgagroal.
Kasus liya kanggo nggarap komunitas postgres yaiku mbalekake menyang titik wektu. Iki Recovery sawise Gagal, iki Recovery saka serep.
Ana akeh serep lan kabeh beda. Meh saben vendor Postgres duwe solusi serep dhewe.
Yen sampeyan njupuk kabeh sistem serep, nggawe matriks fitur lan jokingly ngetung determinant ing matrik iki, iku bakal nul. Apa tegese iki? Apa yen sampeyan njupuk file serep tartamtu, mula ora bisa dirakit saka potongan kabeh liyane. Iku unik ing implementasine, iku unik ing tujuane, iku unik ing gagasan sing ditempelake ing. Lan kabeh padha spesifik.
Nalika kita nggarap masalah iki, CitusData ngluncurake proyek WAL-G. Iki minangka sistem serep sing digawe kanthi mripat menyang lingkungan maya. Saiki CitusData wis dadi bagian saka Microsoft. Lan ing wektu iku, kita seneng banget karo gagasan sing disedhiyakake ing rilis awal WAL-G. Lan kita miwiti kontribusi kanggo proyek iki.
Saiki ana akeh puluhan pangembang ing proyek iki, nanging 10 kontributor paling dhuwur kanggo WAL-G kalebu 6 Yandexoids. Kita nggawa akeh gagasan ing kana. Lan, mesthi, kita nindakake dhewe, nyoba dhewe, digulung menyang produksi dhewe, kita nggunakake dhewe, kita dhewe nemtokake ngendi kanggo pindhah sabanjuré, nalika sesambungan karo masyarakat WAL-G gedhe.
Lan saka sudut pandang kita, saiki sistem serep iki, kalebu nganggep usaha kita, wis dadi optimal kanggo lingkungan maya. Iki minangka biaya paling apik kanggo nggawe serep Postgres ing méga.
Iki artine apa? Kita promosiake gagasan sing cukup gedhe: serep kudu aman, murah kanggo operate lan kanthi cepet bisa dipulihake.
Apa kudu murah kanggo operate? Yen ora ana sing rusak, sampeyan ora ngerti sampeyan duwe serep. Kabeh bisa digunakake kanthi apik, sampeyan mbuwang CPU sethithik, sampeyan nggunakake sumber daya disk sing sethithik, lan sampeyan ngirim sawetara bita menyang jaringan supaya ora ngganggu muatan layanan sing penting.
Lan nalika kabeh rusak, contone, admin dropped data, ana sing salah, lan sampeyan kudu cepet bali menyang kepungkur, waras kabeh dhuwit, amarga sampeyan pengin data bali cepet lan utuh.
Lan kita ningkataké gagasan prasaja iki. Lan, misale jek, kita bisa ngetrapake.
Nanging ora mung kuwi. We wanted siji liyane cilik. We wanted akeh database beda. Ora kabeh klien kita nggunakake Postgres. Sawetara wong nggunakake MySQL, MongoDB. Ing komunitas, pangembang liyane wis ndhukung FoundationDB. Lan dhaptar iki terus berkembang.
Komunitas seneng ide database sing ditindakake ing lingkungan sing dikelola ing awan. Lan pangembang njaga basis data, sing bisa didhukung kanthi seragam bebarengan karo Postgres karo sistem serep kita.
Apa sing wis kita sinau saka crita iki? Produk kita, minangka divisi pangembangan, dudu baris kode, dudu pernyataan, dudu file. Produk kita ora narik panjaluk. Iki minangka gagasan sing kita aturaken marang masyarakat. Iki minangka keahlian teknologi lan gerakan teknologi menyang lingkungan awan.
Ana database kaya Postgres. Aku paling inti Postgres. Aku nglampahi akeh wektu kanggo ngembangake inti Postgres karo masyarakat.
Nanging ing kene kudu dikandhakake yen Yandex.Cloud duwe instalasi internal database sing dikelola. Lan wiwit dangu kepungkur ing Yandex.Mail. Keahlian sing saiki wis mimpin kanggo ngatur Postgres akumulasi nalika mail pengin pindhah menyang Postgres.
Mail nduweni syarat sing padha karo awan. Sampeyan mbutuhake sampeyan bisa nggedhekake pertumbuhan eksponensial sing ora dikarepke ing sembarang titik ing data sampeyan. Lan surat kasebut wis ngemot sawetara atusan yuta kothak layang saka akeh pangguna sing terus-terusan njaluk akeh panjaluk.
Lan iki minangka tantangan serius kanggo tim sing ngembangake Postgres. Mbiyen, masalah apa wae sing kita temui dilaporake menyang komunitas. Lan masalah iki didandani, lan didandani dening masyarakat ing sawetara panggonan malah ing tingkat support mbayar kanggo sawetara database liyane lan malah luwih apik. Yaiku, sampeyan bisa ngirim layang menyang peretas PgSQL lan nampa tanggapan sajrone 40 menit. Dhukungan mbayar ing sawetara database bisa uga mikir yen ana prekara sing luwih prioritas tinimbang bug sampeyan.
Saiki instalasi internal Postgres minangka sawetara petabyte data. Iki sawetara yuta panjalukan saben detik. Iki ewu kluster. Iku banget gedhe-ukuran.
Nanging ana nuansa. Urip ora ing drive jaringan apik, nanging ing hardware cukup prasaja. Lan ana lingkungan tes khusus kanggo perkara anyar sing menarik.
Lan ing wayahe tartamtu ing lingkungan tes kita nampa pesen sing nuduhake yen invarian internal indeks database dilanggar.
Invarian minangka sawetara jinis hubungan sing kita ngarepake bakal terus.
Kahanan sing kritis banget kanggo kita. Iki nuduhake yen sawetara data bisa uga ilang. Lan mundhut data soko downright catastrophic.
Gagasan umum sing kita tindakake ing database sing dikelola yaiku sanajan kanthi gaweyan, bakal angel ilang data. Sanajan sampeyan sengaja nyopot, sampeyan isih kudu nglirwakake ora ana ing wektu sing suwe. Keamanan data minangka agama sing kita tindakake kanthi temenan.
Lan ing kene ana kahanan sing nuduhake manawa ana kahanan sing ora bisa disiapake. Lan kita wiwit nyiapake kahanan iki.
Babagan pisanan sing ditindakake yaiku ngubur log saka ewonan kluster kasebut. Kita nemokake klompok sing ana ing disk kanthi perangkat kukuh masalah sing ilang nganyari kaca data. Ditandhani kabeh kode data Postgres. Lan kita menehi tandha pesen kasebut sing nuduhake pelanggaran invarian internal kanthi kode sing dirancang kanggo ndeteksi korupsi data.
Tembelan iki praktis ditampa dening masyarakat tanpa akeh diskusi, amarga ing saben kasus tartamtu ketok yen ana kedadeyan sing ala lan kudu dilaporake menyang log.
Sawise iki, kita teka ing titik sing kita kudu ngawasi sing mindai log. Lan yen ana pesen sing curiga, dheweke nggugah petugas tugas, lan petugas tugas ndandani.
Nanging! Log mindhai minangka operasi murah ing siji kluster lan larang banget kanggo sewu kluster.
We wrote extension disebut . Iki nggawe tampilan database sing bisa kanthi murah lan cepet milih statistik babagan kesalahan sing kepungkur. Lan yen kita kudu tangi pejabat tugas, kita bakal mangerteni bab iki tanpa mindhai file gigabyte, nanging extract sawetara bita saka tabel hash.
Ekstensi iki wis diadopsi, contone, ing gudang kanggo . Yen sampeyan pengin nggunakake, sampeyan bisa nginstal dhewe. Mesthi iku open source.
Nanging ora mung kuwi. Kita miwiti nggunakake Amcheck, ekstensi sing dibangun komunitas, kanggo nemokake pelanggaran invarian ing indeks.
Lan kita nemokake yen sampeyan ngoperasikake kanthi skala, ana kewan omo. Kita miwiti ndandani. Koreksi kita wis ditampa.
Kita nemokake manawa ekstensi iki ora bisa nganalisa indeks GiST & GIT. Kita nggawe dheweke ndhukung. Nanging dhukungan iki isih dibahas dening komunitas, amarga iki minangka fungsi sing relatif anyar lan ana akeh rincian ing kana.
Lan kita uga nemokake manawa mriksa indeks kanggo pelanggaran ing pimpinan replikasi, ing master, kabeh bisa digunakake kanthi apik, nanging ing replika, ing pengikut, panelusuran korupsi ora efektif. Ora kabeh invarian dicenthang. Lan siji invarian ngganggu kita banget. Lan kita nglampahi setaun setengah kanggo komunikasi karo masyarakat supaya bisa mriksa replika iki.
We wrote kode sing kudu tindakake kabeh bisa ... protokol. Kita rembugan tembelan iki kanggo sawetara wektu karo Peter Gaghan saka Crunchy Data. Dheweke kudu rada ngowahi wit B sing ana ing Postgres supaya bisa nampa tembelan iki. Dheweke ditampa. Lan saiki mriksa indeks ing replika uga wis cukup efektif kanggo ndeteksi pelanggaran sing kita temoni. Tegese, iki minangka pelanggaran sing bisa disebabake kesalahan ing firmware disk, bug ing Postgres, bug ing kernel Linux, lan masalah hardware. Cukup dhaftar ekstensif sumber masalah sing kita nyepakaké.
Nanging saliyane indeks, ana bagean kaya heap, yaiku papan ing ngendi data disimpen. Lan ora akeh invarian sing bisa dicenthang.
Kita duwe ekstensi sing diarani Heapcheck. Kita miwiti ngembangaken. Lan podo karo, bebarengan karo kita, perusahaan EnterpriseDB uga wiwit nulis modul, kang padha disebut Heapcheck ing cara sing padha. Mung kita disebut PgHeapcheck, lan padha mung disebut Heapcheck. Dheweke duwe fungsi sing padha, teken sing rada beda, nanging kanthi ide sing padha. Padha dileksanakake luwih apik ing sawetara panggonan. Lan padha dikirim ing open source sadurunge.
Lan saiki kita ngembangake ekspansi kasebut, amarga ora ana ekspansi maneh, nanging perluasan masyarakat. Lan ing mangsa ngarep, iki minangka bagean saka kernel sing bakal diwenehake kanggo kabeh wong supaya bisa ngerti babagan masalah ing mangsa ngarep.
Ing sawetara panggonan, kita malah nyimpulake yen kita duwe positip palsu ing sistem pemantauan kita. Contone, sistem 1C. Nalika nggunakake database, Postgres kadhangkala nulis data menyang sing bisa maca, nanging pg_dump ora bisa maca.
Kahanan iki katon kaya korupsi ing sistem deteksi masalah kita. Petugas wis tangi. Petugas tugas nyawang apa sing kedadeyan. Sawise sawetara wektu, klien teka lan ngomong yen aku duwe masalah. Petugas kasebut nerangake apa masalahe. Nanging masalah ana ing inti Postgres.
Aku nemokake diskusi babagan fitur iki. Lan dheweke nulis yen kita nemoni fitur iki lan ora nyenengake, ana wong sing tangi ing wayah wengi kanggo ngerteni apa iku.
Masyarakat mangsuli, "Oh, kita kudu ndandani."
Aku duwe analogi prasaja. Yen sampeyan mlaku-mlaku ing sepatu sing nduweni butir pasir, banjur, ing prinsip, sampeyan bisa nerusake - ora ana masalah. Yen sampeyan adol sepatu bot menyang ewonan wong, ayo nggawe sepatu bot tanpa pasir. Lan yen salah sawijining pangguna sepatu sampeyan bakal mlaku maraton, mula sampeyan pengin nggawe sepatu sing apik banget, banjur ukurane menyang kabeh pangguna. Lan pangguna sing ora dikarepake mesthi ana ing lingkungan maya. Ana uga pangguna sing ngeksploitasi kluster kanthi cara asli. Sampeyan kudu tansah nyiapake iki.
Apa sing wis kita sinau ing kene? Kita sinau bab sing prasaja: sing paling penting yaiku nerangake marang masyarakat yen ana masalah. Yen masyarakat wis ngakoni masalah kasebut, mula muncul kompetisi alami kanggo ngrampungake masalah kasebut. Amarga saben wong kepengin ngrampungake masalah sing penting. Kabeh vendor, kabeh peretas ngerti yen dheweke dhewe bisa ngindhari rake iki, mula dheweke pengin ngilangi.
Yen sampeyan nggarap masalah, nanging ora ana sing ngganggu nanging sampeyan, nanging sampeyan nggarap kanthi sistematis lan pungkasane dianggep minangka masalah, mula panjaluk narik sampeyan bakal ditampa. Tembelan sampeyan bakal ditampa, perbaikan utawa panjaluk perbaikan bakal dideleng dening komunitas. Ing pungkasan dina, kita nggawe database luwih apik kanggo saben liyane.
Database sing menarik yaiku Greenplum. Iki minangka basis data paralel sing adhedhasar basis kode Postgres, sing aku kenal banget.
Lan Greenplum nduweni fungsi sing menarik - nambah tabel sing dioptimalake. Iki minangka tabel sing bisa ditambahake kanthi cepet. Padha bisa dadi kolom utawa baris.
Nanging ora ana clustering, yaiku ora ana fungsi ing ngendi sampeyan bisa ngatur data sing ana ing tabel miturut urutan sing ana ing salah sawijining indeks.
Wong-wong saka taksi marani aku lan ngomong: "Andrey, sampeyan ngerti Postgres. Lan ing kene meh padha. Ganti dadi 20 menit. Sampeyan njupuk lan nindakaken. Aku panginten sing ya, Aku ngerti Postgres, ngoper kanggo 20 menit - Aku kudu nindakake iki.
Nanging ora, ora 20 menit, aku nulis nganti pirang-pirang wulan. Ing konferensi PgConf.Russia, aku nyedhaki Heikki Linakangas saka Pivotal lan takon: "Apa ana masalah karo iki? Napa ora ana clustering tabel sing dioptimalake?" Dheweke kandha: "Sampeyan njupuk data. Sampeyan urut, sampeyan ngatur maneh. Iku mung gaweyan." Aku: "Oh, ya, sampeyan mung kudu njupuk lan nindakake." Dheweke kandha, "Ya, kita butuh tangan gratis kanggo nindakake iki." Aku panginten sing aku mesthi kudu nindakake iki.
Lan sawetara sasi mengko aku ngirim panjalukan narik sing dileksanakake fungsi iki. Panjaluk tarik iki dideleng dening Pivotal bebarengan karo komunitas. Mesthi, ana kewan omo.
Nanging sing paling menarik yaiku nalika panjaluk tarik iki digabung, kewan omo ditemokake ing Greenplum dhewe. Kita wis nemokake manawa tabel tumpukan kadhangkala ngilangi transaksional nalika diklompok. Lan iki bab sing kudu didandani. Lan dheweke ana ing papan sing dakdemek. Lan reaksi alamiku yaiku - oke, ayo aku nindakake iki uga.
Aku ndandani bug iki. Ngirim panjalukan narik kanggo fixers. Dheweke dipateni.
Sawise iku ternyata fungsi iki kudu dipikolehi ing versi Greenplum kanggo PostgreSQL 12. Yaiku, petualangan 20 menit terus karo petualangan anyar sing menarik. Iku menarik kanggo ndemek pangembangan saiki, ing ngendi komunitas nglereni fitur anyar lan paling penting. Wis beku.
Nanging ora rampung ing kono. Sawise kabeh, ternyata kita kudu nulis dokumentasi kanggo kabeh iki.
Aku miwiti nulis dokumentasi. Untunge, dokumenter saka Pivotal teka. Inggris iku basa asline. Dheweke mbantu aku karo dokumentasi. Nyatane, dheweke dhewe nulis ulang apa sing dakkarepake dadi basa Inggris nyata.
Lan ing kene, mesthine, petualangan kasebut rampung. Lan sampeyan ngerti apa sing kedadeyan? Wong-wong saka taksi marani aku lan ujar: "Isih ana rong petualangan, saben 10 menit." Lan apa sing kudu dakkandhakake? Aku ngomong yen saiki aku bakal menehi laporan kanthi skala, banjur kita bakal weruh petualangan sampeyan, amarga iki minangka proyek sing menarik.
Apa sing kita sinau saka kasus iki? Amarga nggarap sumber terbuka mesthi nggarap wong tartamtu, mula kerjane karo komunitas. Amarga ing saben tahapan aku kerja karo sawetara pangembang, sawetara tester, sawetara peretas, sawetara dokumenter, sawetara arsitek. Aku ora kerja karo Greenplum, aku kerja karo wong-wong ing sekitar Greenplum.
Nanging! Ana titik penting liyane - iku mung karya. Yaiku, sampeyan teka, ngombe kopi, nulis kode. Kabeh jinis invarian prasaja bisa digunakake. Tindakake biasane - bakal apik! Lan iku proyek cukup menarik. Ana panjalukan kanggo karya iki saka klien Yandex.Cloud, pangguna kluster kita ing njero Yandex lan njaba. Lan aku mikir yen jumlah proyek sing kita melu bakal nambah lan ambane keterlibatan kita uga bakal nambah.
Mekaten. Ayo dadi pindhah menyang pitakonan.
Sesi pitakonan
Hello! Kita duwe sesi pitakonan lan jawaban liyane. Lan ing studio Andrei Borodin. Iki wong sing mung ngandhani sampeyan babagan kontribusi Yandex.Cloud lan Yandex kanggo mbukak sumber. Laporan kita saiki ora kabeh babagan Cloud, nanging ing wektu sing padha adhedhasar teknologi kasebut. Tanpa apa sing sampeyan tindakake ing Yandex, ora bakal ana layanan ing Yandex.Cloud, mula matur nuwun saka aku pribadi. Lan pitakonan pisanan saka siaran kasebut: "Apa saben proyek sing sampeyan sebutake ditulis?"
Sistem serep ing WAL-G ditulis ing Go. Iki minangka salah sawijining proyek anyar sing wis digarap. Dheweke secara harfiah mung 3 taun. Lan database asring babagan linuwih. Lan iki tegese database cukup lawas lan biasane ditulis ing C. Proyek Postgres diwiwiti udakara 30 taun kepungkur. Banjur C89 minangka pilihan sing tepat. Lan Postgres ditulis ing. Database luwih modern kayata ClickHouse biasane ditulis ing C++. Kabeh pembangunan sistem adhedhasar watara C lan C ++.
Pitakonan saka manajer finansial, sing tanggung jawab kanggo biaya ing Cloud: "Napa Cloud mbuwang dhuwit kanggo ndhukung sumber terbuka?"
Ana jawaban sing gampang kanggo manajer finansial ing kene. Kita nindakake iki kanggo nggawe layanan kita luwih apik. Kanthi cara apa kita bisa luwih apik? Kita bisa nindakake samubarang kanthi luwih efisien, luwih cepet, lan nggawe samubarang luwih bisa diukur. Nanging kanggo kita, crita iki utamane babagan linuwih. Contone, ing sistem serep kita mriksa 100% patch sing ditrapake. Kita ngerti apa kode kasebut. Lan kita luwih nyaman ngluncurake versi anyar kanggo produksi. Yaiku, pisanan kabeh, babagan kapercayan, babagan kesiapan kanggo pangembangan lan babagan linuwih
Pitakonan liyane: "Apa syarat pangguna eksternal sing manggon ing Yandex.Cloud beda karo pangguna internal sing manggon ing Cloud internal?"
Profil beban, mesthi, beda. Nanging saka sudut pandang departemenku, kabeh kasus khusus lan menarik digawe kanthi beban sing ora standar. Pangembang kanthi imajinasi, pangembang sing nindakake sing ora dikarepake, bisa ditemokake ing njero lan njaba. Ing babagan iki, kita kabeh kira-kira padha. Lan, mbokmenawa, siji-sijine fitur penting ing operasi database Yandex yaiku ing Yandex kita duwe piwulang. Ing sawetara titik, sawetara zona kasedhiyan rampung dadi bayangan, lan kabeh layanan Yandex kudu terus dienggo sanajan iki. Iki prabédan cilik. Nanging nggawe akeh pangembangan riset ing antarmuka database lan tumpukan jaringan. Yen ora, panginstalan eksternal lan internal ngasilake panjalukan sing padha kanggo fitur lan panjaluk sing padha kanggo ningkatake linuwih lan kinerja.
Pitakonan sabanjure: "Kepiye perasaan sampeyan babagan kasunyatan manawa akeh sing sampeyan lakoni digunakake dening Awan liyane?" Kita ora bakal menehi jeneng tartamtu, nanging akeh proyek sing ditindakake ing Yandex.Cloud digunakake ing awan wong liya.
Iki keren. Kaping pisanan, iki minangka tandha manawa kita wis nindakake kanthi bener. Lan goresan ego. Lan kita luwih yakin manawa kita wis nggawe keputusan sing bener. Ing sisih liya, iki minangka pangarep-arep yen ing mangsa ngarep iki bakal nggawa kita gagasan anyar, panjaluk anyar saka pangguna pihak katelu. Umume masalah ing GitHub digawe dening administrator sistem individu, DBA individu, arsitek individu, insinyur individu, nanging kadhangkala wong sing duwe pengalaman sistematis teka lan ujar manawa ing 30% kasus tartamtu, kita duwe masalah iki lan ayo mikir babagan cara ngatasi. Iki sing paling kita ngarep-arep. Kita ngarepake nuduhake pengalaman karo platform awan liyane.
Sampeyan ngomong akeh babagan maraton. Aku ngerti yen sampeyan mlayu maraton ing Moskow. Akibaté? Ngluwihi wong lanang saka PostgreSQL?
Ora, Oleg Bartunov mlaku cepet banget. Dheweke rampung sejam luwih dhisik tinimbang aku. Sakabèhé, aku seneng karo sepira aku entuk. Kanggo kula, mung ngrampungake minangka prestasi. Sakabèhé, nggumunake manawa ana akeh pelari ing komunitas postgres. Iku misale jek kula sing ana sawetara jenis hubungan antarane olahraga aerobik lan kepinginan kanggo program sistem.
Apa sampeyan ngomong ora ana pelari ing ClickHouse?
Aku ngerti manawa dheweke ana. ClickHouse uga database. Miturut cara, Oleg saiki nulis marang aku: "Apa kita bakal mlayu sawise laporan?" Iki minangka ide sing apik.
Pitakonan liyane saka siaran saka Nikita: "Napa sampeyan ndandani bug ing Greenplum dhewe lan ora menehi menyang junior?" Bener, ora pati jelas apa bug lan layanan apa, nanging bisa uga tegese sing sampeyan gunakake.
Ya, ing asas, iku bisa wis diwenehi kanggo wong. Iku mung kode sing aku mung ngganti. Lan iku wajar kanggo terus nindakake langsung. Prinsipe, ide nuduhake keahlian karo tim minangka ide sing apik. Kita mesthi bakal nuduhake tugas Greenplum ing antarane kabeh anggota divisi kita.
Awit kita ngomong babagan junior, kene ana pitakonan. Wong kasebut mutusake nggawe komitmen pisanan ing Postgres. Apa sing kudu ditindakake kanggo nggawe komitmen pisanan?
Iki minangka pitakonan sing menarik: "Endi kanggo miwiti?" Iku biasane cukup angel kanggo miwiti karo soko ing kernel. Ing Postgres, umpamane, ana dhaptar sing kudu ditindakake. Nanging nyatane, iki minangka lembaran apa sing dicoba, nanging ora kasil. Iki minangka perkara sing rumit. Lan biasane sampeyan bisa nemokake sawetara utilitas ing ekosistem, sawetara ekstensi sing bisa ditingkatake, sing kurang narik kawigaten para pangembang kernel. Lan, kanthi mangkono, ana luwih akeh poin kanggo tuwuh ing kana. Ing program kode Musim Panas Google, saben taun komunitas postgres nyedhiyakake akeh topik sing bisa diatasi. Ing taun iki, aku duwe telung siswa. Siji malah nulis ing WAL-G babagan topik sing penting kanggo Yandex. Ing Greenplum, kabeh luwih gampang tinimbang ing komunitas Postgres, amarga peretas Greenplum nganggep panjaluk tarik kanthi apik lan langsung mriksa maneh. Ngirim tembelan menyang Postgres yaiku sawetara wulan, nanging Greenplum bakal teka ing sawijining dina lan ndeleng apa sing wis sampeyan lakoni. Bab liyane yaiku Greenplum kudu ngrampungake masalah saiki. Greenplum ora digunakake kanthi akeh, mula angel golek masalah sampeyan. Lan pisanan, kita kudu ngrampungake masalah, mesthi.
Source: www.habr.com