Contribuția Yandex la următoarele baze de date va fi revizuită.
- Faceți clic pe Casă
- Odiseea
- Recuperare la un moment dat (WAL-G)
- PostgreSQL (inclusiv erori de log, Amcheck, heapcheck)
- Prună verde
video:
Salut Lume! Numele meu este Andrey Borodin. Și ceea ce fac la Yandex.Cloud este să dezvolt baze de date relaționale deschise în interesul clienților Yandex.Cloud și Yandex.Cloud.
În această discuție, vom vorbi despre provocările cu care se confruntă bazele de date deschise la scară. De ce este important? Pentru că mici, mici probleme care, ca țânțarii, devin apoi elefanți. Ele devin mari atunci când ai multe grupuri.
Dar asta nu este principalul lucru. Se întâmplă lucruri incredibile. Lucruri care se întâmplă într-unul dintr-un milion de cazuri. Și într-un mediu cloud, trebuie să fii pregătit pentru asta, pentru că lucrurile incredibile devin foarte probabile atunci când ceva există la scară.
Dar! Care este avantajul bazelor de date deschise? Cert este că ai o oportunitate teoretică de a face față oricărei probleme. Ai codul sursă, ai cunoștințe de programare. Îl combinăm și funcționează.
Ce abordări există în lucrul cu software-ul open source?
- Cea mai simplă abordare este utilizarea software-ului. Dacă folosești protocoale, dacă folosești standarde, dacă folosești formate, dacă scrii interogări în software open source, atunci deja îl suporti.
- Îi faci ecosistemul mai mare. Creșteți probabilitatea detectării timpurii a unei erori. Creșteți fiabilitatea acestui sistem. Creșteți disponibilitatea dezvoltatorilor pe piață. Îmbunătățiți acest software. Sunteți deja un colaborator dacă tocmai v-ați făcut stil și ați lucrat cu ceva acolo.
- O altă abordare de înțeles este sponsorizarea software-ului open source. De exemplu, binecunoscutul program Google Summer of Code, când Google plătește un număr mare de studenți din întreaga lume bani de înțeles pentru ca aceștia să dezvolte proiecte software deschise care să îndeplinească anumite cerințe de licențiere.
- Aceasta este o abordare foarte interesantă, deoarece permite software-ului să evolueze fără a deplasa concentrarea de la comunitate. Google, ca gigant al tehnologiei, nu spune că vrem această funcție, vrem să remediem acest bug și aici trebuie să săpăm. Google spune: „Fă ceea ce faci. Continuați să lucrați așa cum ați lucrat și totul va fi bine.”
- Următoarea abordare a participării la sursa deschisă este participarea. Când aveți o problemă în software-ul open source și există dezvoltatori, dezvoltatorii dvs. încep să rezolve problemele. Încep să vă facă infrastructura mai eficientă, programele dvs. mai rapide și mai fiabile.
Unul dintre cele mai cunoscute proiecte Yandex din domeniul software-ului open source este ClickHouse. Aceasta este o bază de date care s-a născut ca răspuns la provocările cu care se confruntă Yandex.Metrica.
Și ca bază de date, a fost realizată în sursă deschisă pentru a crea un ecosistem și a-l dezvolta împreună cu alți dezvoltatori (nu numai în cadrul Yandex). Și acum acesta este un proiect mare în care sunt implicate multe companii diferite.
În Yandex.Cloud, am creat ClickHouse deasupra Yandex Object Storage, adică deasupra stocării în cloud.
De ce este important acest lucru în cloud? Pentru că orice bază de date funcționează în acest triunghi, în această piramidă, în această ierarhie a tipurilor de memorie. Aveți registre rapide, dar mici și SSD-uri mari, dar lente ieftine, hard disk-uri și alte dispozitive bloc. Și dacă ești eficient în vârful piramidei, atunci ai o bază de date rapidă. dacă sunteți eficient în partea de jos a acestei piramide, atunci aveți o bază de date la scară. Și în acest sens, adăugarea unui alt strat de jos este o abordare logică pentru creșterea scalabilității bazei de date.
Cum s-ar putea face? Acesta este un punct important în acest raport.
- Am putea implementa ClickHouse peste MDS. MDS este o interfață internă de stocare în cloud Yandex. Este mai complex decât protocolul comun S3, dar este mai potrivit pentru un dispozitiv bloc. Este mai bine pentru înregistrarea datelor. Necesită mai multă programare. Programatorii vor programa, este chiar bine, este interesant.
- S3 este o abordare mai comună care face interfața mai simplă cu prețul unei adaptări mai reduse la anumite tipuri de sarcini de lucru.
Bineînțeles, dorind să oferim funcționalitate întregului ecosistem ClickHouse și să îndeplinim sarcina necesară în Yandex.Cloud, am decis să ne asigurăm că întreaga comunitate ClickHouse va beneficia de pe urma acesteia. Am implementat ClickHouse peste S3, nu ClickHouse peste MDS. Și aceasta este multă muncă.
referințe:
„Stratul de abstractizare a sistemului de fișiere”
„Integrare AWS SDK S3”
„Implementarea de bază a interafcei IDisk pentru S3”
„Integrarea motoarelor de stocare a jurnalelor cu interfața IDisk”
„Suport motor de jurnal pentru S3 și SeekableReadBuffer”
„Suport pentru stocare Stripe Log S3”
„Suport inițial pentru stocare MergeTree pentru S3”
„Suport complet MergeTree pentru S3”
„Suport ReplicatedMergeTree peste S3”
„Adăugați acreditări implicite și anteturi personalizate pentru stocarea s3”
„S3 cu configurație proxy dinamică”
„S3 cu soluție proxy”
Aceasta este o listă de cereri de extragere pentru implementarea unui sistem de fișiere virtual în ClickHouse. Acesta este un număr mare de solicitări pull.
referințe:
„Implementarea optimă a hardlink-urilor DiskS3”
„Client HTTP S3 — Evitați copierea fluxului de răspuns în memorie”
„Evitați să copiați întregul flux de răspuns în memorie în S3 HTTP
client"
„Posibilitatea de a marca și indexa fișierele în cache pentru discul S3”
„Mutați părți de la DiskLocal la DiskS3 în paralel”
Dar munca nu s-a încheiat aici. După ce a fost creată caracteristica, a fost nevoie de mai multă muncă pentru a optimiza această funcționalitate.
referințe:
„Adăugați evenimente SelectedRows și SelectedBytes”
„Adăugați evenimente de profilare de la cererea S3 la system.events”
„Adăugați QueryTimeMicroseconds, SelectQueryTimeMicroseconds și InsertQueryTimeMicroseconds”
Și apoi a fost necesar să îl facem diagnosticabil, să configurați monitorizarea și să îl facem gestionabil.
Și toate acestea au fost făcute astfel încât întreaga comunitate, întreg ecosistemul ClickHouse, să primească rezultatul acestei lucrări.
Să trecem la bazele de date tranzacționale, la bazele de date OLTP, care sunt mai aproape de mine personal.
Aceasta este divizia de dezvoltare DBMS open source. Acești tipi fac magie stradală pentru a îmbunătăți bazele de date tranzacționale deschise.
Unul dintre proiecte, folosind un exemplu despre care putem vorbi despre cum și ce facem, este Connection Pooler din Postgres.
Postgres este o bază de date de proces. Aceasta înseamnă că baza de date ar trebui să aibă cât mai puține conexiuni la rețea care să gestioneze tranzacțiile.
Pe de altă parte, într-un mediu cloud, o situație tipică este atunci când o mie de conexiuni vin la un cluster deodată. Iar sarcina poolerului de conexiuni este să împacheteze o mie de conexiuni într-un număr mic de conexiuni la server.
Putem spune că poolerul de conexiuni este operatorul de telefonie care rearanjează octeții astfel încât aceștia să ajungă eficient în baza de date.
Din păcate, nu există un cuvânt rusesc bun pentru pooler de conexiuni. Uneori se numește conexiuni multiplexer. Dacă știți cum să numiți poolerul de conexiuni, atunci asigurați-vă că îmi spuneți, voi fi foarte bucuros să vorbesc limba tehnică rusă corectă.
Am investigat grupurile de conexiuni care erau potrivite pentru un cluster postgres gestionat. Și PgBouncer a fost cea mai bună alegere pentru noi. Dar am întâmpinat o serie de probleme cu PgBouncer. Cu mulți ani în urmă, Volodya Borodin a dat rapoarte că folosim PgBouncer, ne place totul, dar există nuanțe, există ceva de lucrat.
Și am muncit. Am remediat problemele pe care le-am întâlnit, am corectat Bouncer și am încercat să împingem cererile de extragere în amonte. Dar a fost dificil de lucrat cu un singur threading fundamental.
A trebuit să colectăm cascade de la Bouncers petic. Când avem multe Bouncers cu un singur fir, conexiunile de pe stratul superior sunt transferate în stratul interior al Bouncers. Acesta este un sistem prost gestionat care este dificil de construit și scalat înainte și înapoi.
Am ajuns la concluzia că am creat propriul nostru pooler de conexiuni, care se numește Odyssey. Am scris-o de la zero.
În 2019, la conferința PgCon, am prezentat acest pooler comunității de dezvoltatori. Acum avem puțin mai puțin de 2 de stele pe GitHub, adică proiectul este în viață, proiectul este popular.
Și dacă creați un cluster Postgres în Yandex.Cloud, atunci acesta va fi un cluster cu Odyssey încorporat, care este reconfigurat la scalarea clusterului înainte sau înapoi.
Ce am învățat din acest proiect? Lansarea unui proiect concurent este întotdeauna un pas agresiv, este o măsură extremă atunci când spunem că sunt probleme care nu se rezolvă suficient de repede, nu se rezolvă în intervalele de timp care ni s-ar potrivi. Dar aceasta este o măsură eficientă.
PgBouncer a început să se dezvolte mai repede.
Și acum au apărut și alte proiecte. De exemplu, pgagroal, care este dezvoltat de dezvoltatorii Red Hat. Ei urmăresc obiective similare și implementează idei similare, dar, desigur, cu specificul lor, care sunt mai aproape de dezvoltatorii pgagroal.
Un alt caz de lucru cu comunitatea postgres este restaurarea la un moment dat. Aceasta este recuperarea după o eroare, aceasta este recuperarea dintr-o copie de rezervă.
Există multe copii de rezervă și toate sunt diferite. Aproape fiecare furnizor Postgres are propria soluție de rezervă.
Dacă luați toate sistemele de rezervă, creați o matrice de caracteristici și calculați în glumă determinantul din această matrice, acesta va fi zero. Ce înseamnă acest lucru? Ce se întâmplă dacă luați un anumit fișier de rezervă, atunci acesta nu poate fi asamblat din bucăți din toate celelalte. Este unic în implementarea sa, este unic în scopul său, este unic în ideile care sunt încorporate în el. Și toate sunt specifice.
În timp ce lucram la această problemă, CitusData a lansat proiectul WAL-G. Acesta este un sistem de rezervă care a fost realizat cu privire la mediul cloud. Acum CitusData face parte deja din Microsoft. Și în acel moment, ne-au plăcut foarte mult ideile care au fost expuse în lansările inițiale ale WAL-G. Și am început să contribuim la acest proiect.
Acum există multe zeci de dezvoltatori în acest proiect, dar primii 10 contribuitori la WAL-G includ 6 Yandexoids. Am adus multe dintre ideile noastre acolo. Și, bineînțeles, le-am implementat singuri, le-am testat singuri, le-am lansat în producție, le folosim singuri, ne dăm seama singuri unde să ne mișcăm în continuare, în timp ce interacționăm cu marea comunitate WAL-G.
Și din punctul nostru de vedere, acum acest sistem de backup, inclusiv ținând cont de eforturile noastre, a devenit optim pentru un mediu cloud. Acesta este cel mai bun cost pentru backupul Postgres în cloud.
Ce înseamnă? Promovam o idee destul de mare: backup-ul ar trebui să fie sigur, ieftin de operat și cât mai rapid posibil de restaurat.
De ce ar trebui să fie ieftin de operat? Când nimic nu este stricat, nu ar trebui să știți că aveți copii de rezervă. Totul funcționează bine, irosești cât mai puțin CPU, folosești cât mai puține resurse de disc și trimiți cât mai puțini octeți în rețea pentru a nu interfera cu sarcina utilă a serviciilor tale valoroase.
Și când totul se strică, de exemplu, administratorul a scăpat datele, ceva a mers prost și trebuie urgent să te întorci în trecut, te recuperezi cu toți banii, pentru că vrei datele înapoi rapid și intacte.
Și am promovat această idee simplă. Și, ni se pare, am reușit să o punem în aplicare.
Dar asta nu este tot. Ne-am dorit încă un lucru mărunt. Ne doream multe baze de date diferite. Nu toți clienții noștri folosesc Postgres. Unii oameni folosesc MySQL, MongoDB. În comunitate, alți dezvoltatori au susținut FoundationDB. Și această listă este în continuă extindere.
Comunității îi place ideea ca baza de date să fie rulată într-un mediu gestionat în cloud. Și dezvoltatorii își mențin bazele de date, care pot fi copiate uniform împreună cu Postgres cu sistemul nostru de rezervă.
Ce am învățat din această poveste? Produsul nostru, ca divizie de dezvoltare, nu este linii de cod, nu sunt declarații, nu sunt fișiere. Produsul nostru nu este cereri de tragere. Acestea sunt ideile pe care le transmitem comunității. Aceasta este expertiza tehnologică și mișcarea tehnologiei către un mediu cloud.
Există o bază de date precum Postgres. Imi place cel mai mult nucleul Postgres. Petrec mult timp dezvoltării nucleului Postgres cu comunitatea.
Dar aici trebuie spus că Yandex.Cloud are o instalare internă de baze de date gestionate. Și a început cu mult timp în urmă în Yandex.Mail. Expertiza care a condus acum la administrarea Postgres a fost acumulată atunci când e-mailul a vrut să se mute în Postgres.
Mail are cerințe foarte asemănătoare cu cele ale cloud-ului. Are nevoie de tine pentru a putea scala la o creștere exponențială neașteptată în orice moment al datelor tale. Și e-mailul avea deja o încărcătură cu câteva sute de milioane de cutii poștale ale unui număr mare de utilizatori care fac în mod constant multe solicitări.
Și aceasta a fost o provocare destul de serioasă pentru echipa care dezvolta Postgres. Pe atunci, orice probleme pe care le-am întâlnit erau raportate comunității. Și aceste probleme au fost corectate și corectate de comunitate în unele locuri chiar și la nivelul suportului plătit pentru alte baze de date și chiar mai bine. Adică, puteți trimite o scrisoare hackerului PgSQL și puteți primi un răspuns în 40 de minute. Asistența plătită în unele baze de date poate crede că există mai multe lucruri prioritare decât bug-ul dvs.
Acum, instalarea internă a Postgres este de câțiva petabytes de date. Acestea sunt câteva milioane de solicitări pe secundă. Acestea sunt mii de clustere. Este la scară foarte mare.
Dar există o nuanță. Nu trăiește pe unități de rețea de lux, ci pe un hardware destul de simplu. Și există un mediu de testare special pentru lucruri noi interesante.
Și la un moment dat în mediul de testare am primit un mesaj care indică faptul că invarianții interni ai indicilor bazei de date au fost încălcați.
Un invariant este un fel de relație pe care ne așteptăm să o păstrăm mereu.
O situație foarte critică pentru noi. Indică faptul că este posibil să se fi pierdut unele date. Și pierderea de date este ceva de-a dreptul catastrofal.
Ideea generală pe care o urmăm în bazele de date gestionate este că, chiar și cu efort, va fi dificil să pierdeți date. Chiar dacă le eliminați în mod deliberat, va trebui totuși să ignorați absența lor pentru o perioadă lungă de timp. Securitatea datelor este o religie pe care o respectăm cu destulă sârguință.
Și aici apare o situație care sugerează că poate exista o situație pentru care s-ar putea să nu fim pregătiți. Și am început să ne pregătim pentru această situație.
Primul lucru pe care l-am făcut a fost să îngropam buștenii din aceste mii de ciorchini. Am descoperit care dintre clustere erau localizate pe discuri cu firmware problematic care pierdeau actualizările paginii de date. A marcat tot codul de date Postgres. Și am marcat acele mesaje care indică încălcări ale invarianților interni cu un cod conceput pentru a detecta corupția datelor.
Acest patch a fost practic acceptat de comunitate fără prea multe discuții, deoarece în fiecare caz specific era evident că ceva rău s-a întâmplat și trebuia raportat la jurnal.
După aceasta, am ajuns la punctul în care avem monitorizare care scanează jurnalele. Și în caz de mesaje suspecte, îl trezește pe ofițerul de serviciu, iar ofițerul de serviciu îl repara.
Dar! Scanarea jurnalelor este o operațiune ieftină pe un cluster și catastrofal de costisitoare pentru o mie de clustere.
Am scris o extensie numită . Acesta creează o vizualizare a bazei de date în care puteți selecta ieftin și rapid statistici privind erorile trecute. Și dacă trebuie să-l trezim pe ofițerul de serviciu, atunci vom afla despre asta fără a scana fișiere gigabyte, ci extragând câțiva octeți din tabelul hash.
Această extensie a fost adoptată, de exemplu, în depozitul pentru . Dacă doriți să-l utilizați, îl puteți instala singur. Desigur, este open source.
Dar asta nu este tot. Am început să folosim Amcheck, o extensie creată de comunitate, pentru a găsi încălcări invariante în indexuri.
Și am aflat că dacă îl operezi la scară, există bug-uri. Am început să le reparăm. Corecțiile noastre au fost acceptate.
Am descoperit că această extensie nu poate analiza indicii GiST și GIT. I-am făcut să sprijine. Dar acest suport este încă discutat de comunitate, deoarece aceasta este o funcționalitate relativ nouă și există o mulțime de detalii acolo.
Și am mai descoperit că atunci când verificăm indici pentru încălcări pe liderul de replicare, pe master, totul funcționează bine, dar pe replici, pe follower, căutarea corupției nu este atât de eficientă. Nu toți invarianții sunt verificați. Și un invariant ne-a deranjat foarte tare. Și am petrecut un an și jumătate comunicând cu comunitatea pentru a permite această verificare a replicilor.
Am scris cod care ar trebui să respecte toate protocoalele posibile. Am discutat despre acest patch de ceva timp cu Peter Gaghan de la Crunchy Data. A trebuit să modifice ușor arborele B existent în Postgres pentru a accepta acest patch. A fost acceptat. Și acum verificarea indexurilor pe replici a devenit suficient de eficientă pentru a detecta încălcările pe care le-am întâlnit. Adică, acestea sunt încălcările care pot fi cauzate de erori în firmware-ul discului, erori în Postgres, erori în nucleul Linux și probleme hardware. O listă destul de extinsă de surse de probleme pentru care ne pregătim.
Dar, pe lângă indici, există o astfel de parte ca heap, adică locul în care sunt stocate datele. Și nu există multe invariante care ar putea fi verificate.
Avem o extensie numită Heapcheck. Am început să o dezvoltăm. Și în paralel, împreună cu noi, compania EnterpriseDB a început să scrie și un modul, pe care l-au numit în același mod Heapcheck. Numai noi l-am numit PgHeapcheck, iar ei i-au numit Heapcheck. O au cu funcții similare, o semnătură puțin diferită, dar cu aceleași idei. Le-au implementat puțin mai bine în unele locuri. Și l-au postat în sursă deschisă înainte.
Și acum dezvoltăm extinderea lor, pentru că nu mai este extinderea lor, ci extinderea comunității. Și în viitor, aceasta face parte din nucleul care va fi furnizat tuturor, astfel încât să poată afla în avans despre problemele viitoare.
În unele locuri, am ajuns chiar la concluzia că avem false pozitive în sistemele noastre de monitorizare. De exemplu, sistemul 1C. Când folosește o bază de date, Postgres scrie uneori date în ea pe care le poate citi, dar pg_dump nu poate citi.
Această situație a arătat ca o corupție a sistemului nostru de detectare a problemelor. Ofițerul de serviciu a fost trezit. Ofițerul de serviciu s-a uitat la ce se întâmpla. După ceva timp, a venit un client și a spus că am probleme. Însoțitorul a explicat care este problema. Dar problema este în nucleul Postgres.
Am găsit o discuție despre această funcție. Și a scris că am întâlnit această caracteristică și a fost neplăcut, o persoană s-a trezit noaptea pentru a-și da seama ce este.
Comunitatea a răspuns: „Oh, chiar trebuie să o reparăm”.
Am o analogie simplă. Dacă mergi cu un pantof care are un grăunte de nisip în el, atunci, în principiu, poți merge mai departe - nicio problemă. Dacă vindeți cizme la mii de oameni, atunci să facem cizme fără nisip deloc. Și dacă unul dintre utilizatorii pantofilor tăi urmează să alerge un maraton, atunci vrei să faci pantofi foarte buni și apoi să-i extinzi pentru toți utilizatorii tăi. Și astfel de utilizatori neaștepți sunt întotdeauna în mediul cloud. Întotdeauna există utilizatori care exploatează clusterul într-un mod original. Trebuie să vă pregătiți întotdeauna pentru asta.
Ce am învățat aici? Am învățat un lucru simplu: cel mai important este să explicăm comunității că există o problemă. Dacă comunitatea a recunoscut problema, atunci apare concurența naturală pentru a rezolva problema. Pentru că toată lumea vrea să rezolve o problemă importantă. Toți vânzătorii, toți hackerii înțeleg că ei înșiși pot călca pe acest rake, așa că vor să-i elimine.
Dacă lucrezi la o problemă, dar nu deranjează pe nimeni în afară de tine, dar lucrezi sistematic la ea și în cele din urmă este considerată o problemă, atunci cererea ta de tragere va fi cu siguranță acceptată. Patch-ul tău va fi acceptat, îmbunătățirile sau chiar cererile de îmbunătățiri vor fi revizuite de comunitate. La sfârșitul zilei, facem baza de date mai bună unul pentru celălalt.
O bază de date interesantă este Greenplum. Este o bază de date extrem de paralelă bazată pe baza de cod Postgres, cu care sunt foarte familiarizat.
Și Greenplum are o funcționalitate interesantă - adăugați tabele optimizate. Acestea sunt tabele la care le puteți adăuga rapid. Ele pot fi fie coloane sau rânduri.
Dar nu a existat o grupare, adică nu a existat nicio funcționalitate în care să puteți aranja datele situate în tabel în conformitate cu ordinea care se află într-unul dintre indici.
Băieții de la taxi au venit la mine și mi-au spus: „Andrey, îl cunoști pe Postgres. Și aici este aproape la fel. Treceți la 20 de minute. O iei și o faci.” Am crezut că da, cunosc Postgres, schimbând timp de 20 de minute - trebuie să fac asta.
Dar nu, nu au fost 20 de minute, am scris-o de-a lungul lunilor. La conferința PgConf.Russia, l-am abordat pe Heikki Linakangas de la Pivotal și l-am întrebat: „Există probleme cu asta? De ce nu există un clustering de tabele optimizat pentru adăugare?” El spune: „Tu iei datele. Sortiți, rearanjați. Este doar o meserie.” Eu: „Oh, da, trebuie doar să o iei și să o faci.” El spune: „Da, avem nevoie de mâini libere pentru a face asta”. M-am gândit că trebuie neapărat să fac asta.
Și câteva luni mai târziu am trimis o cerere de extragere care a implementat această funcționalitate. Această solicitare de extragere a fost examinată de Pivotal împreună cu comunitatea. Desigur, au existat bug-uri.
Dar cel mai interesant lucru este că atunci când această solicitare de extragere a fost îmbinată, au fost găsite erori în Greenplum. Am descoperit că tabelele heap rup uneori tranzacționalitatea atunci când sunt grupate. Și acesta este un lucru care trebuie remediat. Și ea este în locul pe care tocmai l-am atins. Și reacția mea naturală a fost – bine, lasă-mă să fac și eu asta.
Am remediat acest bug. A trimis o cerere de tragere către reparatori. A fost ucis.
După care s-a dovedit că această funcționalitate trebuie obținută în versiunea Greenplum pentru PostgreSQL 12. Adică, aventura de 20 de minute continuă cu noi aventuri interesante. A fost interesant să atingem dezvoltarea actuală, în care comunitatea creează funcții noi și cele mai importante. E inghetat.
Dar nu s-a terminat aici. După toate, s-a dovedit că trebuie să scriem documentație pentru toate acestea.
Am început să scriu documentație. Din fericire, au venit și documentariștii de la Pivotal. Engleza este limba lor maternă. M-au ajutat cu documentația. De fapt, ei înșiși au rescris ceea ce mi-am propus în engleză reală.
Și aici, s-ar părea, aventura s-a încheiat. Și știi ce s-a întâmplat atunci? Băieții de la taxi au venit la mine și mi-au spus: „Mai sunt două aventuri, fiecare timp de 10 minute.” Și ce să le spun? Am spus că acum voi da un raport la scară, apoi vom vedea aventurile voastre, pentru că aceasta este o meserie interesantă.
Ce am învățat din acest caz? Deoarece lucrul cu sursa deschisă înseamnă întotdeauna lucrul cu o anumită persoană, este întotdeauna lucrul cu comunitatea. Pentru că la fiecare etapă am lucrat cu un dezvoltator, cu un tester, cu un hacker, cu un documentarist, cu un arhitect. Nu am lucrat cu Greenplum, am lucrat cu oameni din jurul Greenplum.
Dar! Există un alt punct important - este doar muncă. Adică vii, bei cafea, scrii cod. Funcționează tot felul de invarianți simpli. Fă-o în mod normal - va fi bine! Și este o muncă destul de interesantă. Există o solicitare pentru această lucrare din partea clienților Yandex.Cloud, utilizatori ai clusterelor noastre atât în interiorul Yandex, cât și în exterior. Și cred că va crește numărul de proiecte la care participăm și va crește și profunzimea implicării noastre.
Asta e tot. Să trecem la întrebări.
Sesiune de întrebări
Buna ziua! Avem o altă sesiune de întrebări și răspunsuri. Și în studio Andrei Borodin. Aceasta este persoana care tocmai ți-a spus despre contribuția Yandex.Cloud și Yandex la sursa deschisă. Raportul nostru acum nu este în întregime despre Cloud, dar în același timp ne bazăm pe astfel de tehnologii. Fără ceea ce ați făcut în Yandex, nu ar exista niciun serviciu în Yandex.Cloud, așa că vă mulțumesc din partea mea personal. Și prima întrebare din emisiune: „Pe ce este scris fiecare dintre proiectele pe care le-ați menționat?”
Sistemul de rezervă din WAL-G este scris în Go. Acesta este unul dintre proiectele mai noi la care am lucrat. El are literalmente doar 3 ani. Și o bază de date este adesea despre fiabilitate. Și asta înseamnă că bazele de date sunt destul de vechi și de obicei sunt scrise în C. Proiectul Postgres a început acum aproximativ 30 de ani. Atunci C89 a fost alegerea potrivită. Și Postgres este scris pe el. Bazele de date mai moderne, cum ar fi ClickHouse, sunt de obicei scrise în C++. Toată dezvoltarea sistemului se bazează pe C și C++.
O întrebare din partea managerului nostru financiar, care este responsabil pentru cheltuieli la Cloud: „De ce cheltuiește Cloud bani pentru susținerea open source?”
Există un răspuns simplu pentru managerul financiar aici. Facem acest lucru pentru a ne îmbunătăți serviciile. În ce moduri putem face mai bine? Putem face lucrurile mai eficient, mai rapid și facem lucrurile mai scalabile. Dar pentru noi, această poveste este în primul rând despre fiabilitate. De exemplu, într-un sistem de rezervă revizuim 100% din patch-urile care i se aplică. Știm care este codul. Și ne simțim mai confortabil să lansăm versiuni noi în producție. Adică, în primul rând, este vorba despre încredere, despre disponibilitatea pentru dezvoltare și despre fiabilitate
O altă întrebare: „Cerințele utilizatorilor externi care locuiesc în Yandex.Cloud sunt diferite de utilizatorii interni care locuiesc în Cloud intern?”
Profilul de încărcare este, desigur, diferit. Dar din punctul de vedere al departamentului meu, toate cazurile speciale și interesante sunt create pe o încărcare non-standard. Dezvoltatorii cu imaginație, dezvoltatorii care fac neașteptat, sunt la fel de probabil să fie găsiți atât în interior, cât și în exterior. În acest sens, toți suntem aproximativ la fel. Și, probabil, singura caracteristică importantă în funcționarea Yandex a bazelor de date va fi aceea că în interiorul Yandex avem o învățătură. La un moment dat, o zonă de disponibilitate intră complet în umbră și toate serviciile Yandex trebuie cumva să continue să funcționeze în ciuda acestui fapt. Aceasta este o mică diferență. Dar creează o mulțime de dezvoltare a cercetării la interfața bazei de date și a stivei de rețea. În caz contrar, instalațiile externe și interne generează aceleași solicitări pentru caracteristici și solicitări similare pentru îmbunătățirea fiabilității și a performanței.
Următoarea întrebare: „Cum te simți personal despre faptul că o mare parte din ceea ce faci este folosit de alți nori?” Nu vom numi unele specifice, dar multe proiecte care au fost realizate în Yandex.Cloud sunt folosite în norii altor oameni.
Aceasta este cool. În primul rând, este un semn că am făcut ceva bine. Și zgârie ego-ul. Și suntem mai încrezători că am luat decizia corectă. Pe de altă parte, aceasta este speranța că în viitor acest lucru ne va aduce noi idei, noi solicitări de la utilizatori terți. Majoritatea problemelor de pe GitHub sunt create de administratori de sistem individuali, DBA individuali, arhitecți individuali, ingineri individuali, dar uneori vin oameni cu experiență sistematică și spun că în 30% din anumite cazuri avem această problemă și să ne gândim cum să o rezolvăm. Acesta este ceea ce așteptăm cel mai mult. Așteptăm cu nerăbdare să împărtășim experiențe cu alte platforme cloud.
Ai vorbit mult despre maraton. Știu că ai alergat un maraton la Moscova. Ca urmare? I-ai depășit pe băieții de la PostgreSQL?
Nu, Oleg Bartunov aleargă foarte repede. A terminat cu o oră înaintea mea. În general, sunt mulțumit de cât de departe am ajuns. Pentru mine, doar terminarea a fost o realizare. În general, este surprinzător că există atât de mulți alergători în comunitatea postgres. Mi se pare că există un fel de relație între sporturile aerobe și dorința de programare a sistemelor.
Vrei să spui că nu există alergători la ClickHouse?
Știu sigur că sunt acolo. ClickHouse este, de asemenea, o bază de date. Apropo, Oleg îmi scrie acum: „Să mergem să alergăm după raport?” Aceasta este o idee grozavă.
O altă întrebare din emisiunea de la Nikita: „De ce ai remediat singur bug-ul din Greenplum și nu l-ai dat juniorilor?” Adevărat, nu este foarte clar care este eroarea și în ce serviciu, dar probabil înseamnă cel despre care ai vorbit.
Da, în principiu, ar fi putut fi dat cuiva. A fost doar codul pe care tocmai l-am schimbat. Și era firesc să continui să o faci imediat. În principiu, ideea de a împărtăși expertiza cu echipa este o idee bună. Cu siguranță vom împărți sarcinile Greenplum între toți membrii diviziei noastre.
Întrucât vorbim de juniori, iată o întrebare. Persoana a decis să creeze primul commit în Postgres. Ce trebuie să facă pentru a face primul comite?
Aceasta este o întrebare interesantă: „De unde să încep?” De obicei, este destul de dificil să începi cu ceva din nucleu. În Postgres, de exemplu, există o listă de lucruri de făcut. Dar, de fapt, aceasta este o foaie a ceea ce au încercat să facă, dar nu au reușit. Acestea sunt lucruri complexe. Și, de obicei, puteți găsi câteva utilități în ecosistem, niște extensii care pot fi îmbunătățite, care atrag mai puțină atenție din partea dezvoltatorilor de kernel. Și, în consecință, există mai multe puncte de creștere acolo. La programul Google Summer of code, în fiecare an comunitatea postgres propune multe subiecte diferite care ar putea fi abordate. Anul acesta am avut, cred, trei elevi. Unul chiar a scris în WAL-G despre subiecte care sunt importante pentru Yandex. În Greenplum, totul este mai simplu decât în comunitatea Postgres, deoarece hackerii Greenplum tratează foarte bine cererile de extragere și încep să revizuiască imediat. Trimiterea unui patch către Postgres este o chestiune de luni, dar Greenplum va veni într-o zi și va vedea ce ați făcut. Un alt lucru este că Greenplum trebuie să rezolve problemele actuale. Greenplum nu este utilizat pe scară largă, așa că găsirea problemei dvs. este destul de dificilă. Și, în primul rând, trebuie să rezolvăm problemele, desigur.
Sursa: www.habr.com