A cuntribuzione di Yandex à e seguenti basa di dati serà rivista.
- CliccaCasa
- Lacrime
- Recuperazione à un puntu in u tempu (WAL-G)
- PostgreSQL (cumpresi logerrors, Amcheck, heapcheck)
- Prugna verde
Video:
Salutu mondu ! Mi chjamu Andrey Borodin. È ciò chì facciu in Yandex.Cloud hè di sviluppà basa di dati relazionali aperti in l'interessi di i clienti Yandex.Cloud è Yandex.Cloud.
In questu discorsu, parleremu di e sfide chì affruntà e basa di dati aperte à scala. Perchè hè impurtante? Perchè picculi, picculi prublemi chì, cum'è i moschiti, diventanu poi elefanti. Si diventanu grandi quandu avete parechji clusters.
Ma questu ùn hè micca u principale. Cose incredibili succedenu. Cose chì succede in unu in un milione di casi. È in un ambiente di nuvola, duvete esse preparatu per quessa, perchè e cose incredibili diventanu assai probabili quandu qualcosa esiste à scala.
Ma! Chì hè u vantaghju di e basa di dati aperti? U fattu hè chì avete l'uppurtunità teorica di trattà cù qualsiasi prublema. Avete u codice fonte, avete a cunniscenza di prugrammazione. Cumbinemu è funziona.
Chì approcci ci sò in u travagliu nantu à u software open source?
- L'approcciu più simplice hè di utilizà u software. Sè vo aduprate protokolli, sè vo aduprate normi, sè vo aduprate furmati, se scrivite dumande in un software open source, allora avete digià sustegnu.
- Fate più grande u so ecosistema. Fate a probabilità di rilevazione precoce di un bug più grande. Aumenterete l'affidabilità di stu sistema. Aumente a dispunibilità di sviluppatori in u mercatu. Avete migliurà stu software. Siete digià un cuntributore s'ellu avete appena ottinutu di stile è tinkered cù qualcosa quì.
- Un altru approcciu comprensibile hè a sponsorizazione di software open source. Per esempiu, u cunnisciuta Google Summer of Code prugramma, quandu Google paga un gran numaru di studienti di tuttu u mondu di soldi comprensibile in modu chì sviluppanu prughjetti di software aperti chì rispondenu à certi requisiti di licenza.
- Questu hè un approcciu assai interessante perchè permette à u software di evoluzione senza alluntanà u focusu da a cumunità. Google, cum'è un giant tecnulugicu, ùn dice micca chì vulemu sta funzione, vulemu riparà stu bug è hè quì chì avemu bisognu di scavà. Google dice: "Fate ciò chì fate. Basta à cuntinuà à travaglià cum'è avete travagliatu è tuttu sarà bè ".
- L'approcciu prossimu per participà in open source hè a participazione. Quandu avete un prublema in u software open source è ci sò sviluppatori, i vostri sviluppatori cumincianu à risolve i prublemi. Cumincianu à fà a vostra infrastruttura più efficiente, i vostri prugrammi più veloci è più affidabili.
Unu di i prughjetti Yandex più famosi in u campu di u software open source hè ClickHouse. Questa hè una basa di dati chì hè natu cum'è una risposta à e sfide di Yandex.Metrica.
È cum'è una basa di dati, hè stata fatta in open source per creà un ecosistema è sviluppà inseme cù altri sviluppatori (micca solu in Yandex). È avà questu hè un grande prughjettu in quale parechje cumpagnie diverse sò implicate.
In Yandex.Cloud, avemu creatu ClickHouse nantu à Yandex Object Storage, vale à dì nantu à u almacenamentu in nuvola.
Perchè hè questu impurtante in u nuvulu? Perchè ogni basa di dati travaglia in questu triangulu, in questa piramide, in questa ghjerarchia di tipi di memoria. Avete registri veloci ma chjuchi è SSD grandi ma lenti economici, discu duru è altri dispositi di bloccu. È se site efficace à a cima di a piramide, allora avete una basa di dati veloce. se site efficace à u fondu di sta piramide, allora avete una basa di dati scalata. È in questu sensu, aghjunghjendu una altra capa da quì sottu hè un approcciu logicu per aumentà a scalabilità di a basa di dati.
Cumu puderia esse fattu? Questu hè un puntu impurtante in stu rapportu.
- Pudemu implementà ClickHouse nantu à MDS. MDS hè una interfaccia interna di almacenamentu in nuvola Yandex. Hè più cumplessu chè u protocolu S3 cumuni, ma hè più adattatu per un dispositivu di bloccu. Hè megliu per a registrazione di dati. Hè bisognu di più prugrammazione. I programatori programaranu, hè ancu bonu, hè interessante.
- S3 hè un approcciu più cumuni chì rende l'interfaccia più simplice à u costu di menu adattazione à certi tipi di carichi di travagliu.
Naturalmente, vulendu furnisce funziunalità à tuttu l'ecosistema di ClickHouse è fà u compitu chì hè necessariu in Yandex.Cloud, avemu decisu di assicurà chì tutta a cumunità ClickHouse ne riceve u benefiziu. Avemu implementatu ClickHouse over S3, micca ClickHouse over MDS. È questu hè assai travagliu.
Referenze:
"Capu di astrazione di u sistema di file"
"Integrazione AWS SDK S3"
"Implementazione di basa di l'interafce IDisk per S3"
"Integrazione di i motori di almacenamiento di log cù l'interfaccia IDisk"
"Supportu di u mutore di log per S3 è SeekableReadBuffer"
"Supportu di Storage Stripe Log S3"
"Storage MergeTree supportu iniziale per S3"
"MergeTree supportu cumpletu per S3"
"Supporta ReplicatedMergeTree nantu à S3"
"Aghjunghje credenziali predeterminate è intestazioni persunalizati per u almacenamiento s3"
"S3 cù cunfigurazione proxy dinamica"
"S3 cù risoluzione proxy"
Questa hè una lista di richieste di pull per implementà un sistema di fugliale virtuale in ClickHouse. Questu hè un gran numaru di richieste di pull.
Referenze:
"DiskS3 hardlinks implementazione ottimale"
"Client HTTP S3 - Evite di copià u flussu di risposta in memoria"
"Evite di copià u flussu di risposta tutale in memoria in S3 HTTP
cliente"
"Capacità di marcà in cache è i fugliali indici per u discu S3"
"Sposta parti da DiskLocal à DiskS3 in parallelu"
Ma u travagliu ùn hè micca finitu quì. Dopu chì a funzione hè stata fatta, un pocu di più travagliu era necessariu per ottimisà sta funziunalità.
Referenze:
"Aggiungi eventi SelectedRows è SelectedBytes"
"Aghjunghje l'avvenimenti di prufilu da a dumanda S3 à system.events"
"Aghjunghje QueryTimeMicroseconds, SelectQueryTimeMicroseconds è InsertQueryTimeMicroseconds"
È tandu era necessariu di rende diagnosticable, stabilisce u monitoraghju è rende gestionable.
E tuttu questu hè statu fattu per chì tutta a cumunità, tuttu l'ecosistema ClickHouse, hà ricevutu u risultatu di stu travagliu.
Passemu à basa di dati transazzione, à basa di dati OLTP, chì sò più vicinu à mè personalmente.
Questa hè a divisione di sviluppu DBMS open source. Questi picciotti facenu magia di strada per migliurà e basa di dati aperte transazzione.
Unu di i prughjetti, utilizendu un esempiu di quale pudemu parlà cumu è ciò chì facemu, hè u Connection Pooler in Postgres.
Postgres hè una basa di dati di prucessu. Questu significa chì a basa di dati duveria avè un pocu di cunnessione di rete pussibule chì gestisce e transacciones.
Per d 'altra banda, in un ambiente di nuvola, una situazione tipica hè quandu mille cunnessione vene à un cluster à una volta. È u compitu di u pooler di cunnessione hè di imballà mille cunnessione in un picculu numeru di cunnessione di u servitore.
Pudemu dì chì u pooler di cunnessione hè l'operatore telefuninu chì rearranges the bytes in modu chì ghjunghjenu in modu efficiente à a basa di dati.
Sfurtunatamente, ùn ci hè micca una bona parolla russa per a cunnessione pooler. A volte hè chjamatu cunnessione multiplexer. Sè vo sapete ciò chì chjamà u pooler di cunnessione, allora assicuratevi di dì à mè, saraghju assai cuntentu di parlà a lingua tecnica russa curretta.
Avemu investigatu i poolers di cunnessione chì eranu adattati per un cluster postgres amministratu. E PgBouncer era a megliu scelta per noi. Ma avemu scontru una quantità di prublemi cù PgBouncer. Parechji anni fà, Volodya Borodin hà datu rapporti chì avemu usatu PgBouncer, ci piace tuttu, ma ci sò sfumature, ci hè qualcosa per travaglià.
È avemu travagliatu. Avemu risoltu i prublemi chì avemu scontru, avemu patched Bouncer, è pruvatu à spinghje e richieste di pull upstream. Ma un filu unicu fundamentale era difficiule di travaglià.
Avemu avutu à cullà cascate da Bouncers patched. Quandu avemu parechji Bouncers single-threaded, i cunnessione nantu à a capa superiore sò trasferiti à a capa interna di Bouncers. Questu hè un sistema pocu amministratu chì hè difficiule di custruisce è scala avanti è avanti.
Avemu ghjuntu à a cunclusione chì avemu creatu u nostru propiu pooler di cunnessione, chì hè chjamatu Odissea. Avemu scrittu da zero.
In 2019, à a cunferenza PgCon, aghju prisentatu stu pooler à a cumunità di sviluppatori. Avà avemu un pocu menu di 2 000 stelle in GitHub, vale à dì chì u prugettu hè vivu, u prugettu hè populari.
È se crea un cluster Postgres in Yandex.Cloud, allora serà un cluster cun Odyssey integratu, chì hè reconfiguratu quandu scaling u cluster in avanti o in avanti.
Chì avemu amparatu da stu prughjettu ? A lanciazione di un prughjettu cuncurrenti hè sempre un passu aggressivu, hè una misura estrema quandu dicemu chì ci sò prublemi chì ùn sò micca risolti abbastanza rapidamente, ùn sò micca risolti in l'intervalli di tempu chì ci cunvene. Ma questu hè una misura efficace.
PgBouncer hà cuminciatu à sviluppà più veloce.
È avà sò apparsu altri prughjetti. Per esempiu, pgagroal, chì hè sviluppatu da i sviluppatori Red Hat. Perseguenu scopi simili è implementanu idee simili, ma, sicuru, cù i so specifichi, chì sò più vicinu à i sviluppatori pgagroal.
Un altru casu di travaglià cù a cumunità di postgres hè di ritruvà à un puntu in u tempu. Questu hè a ricuperazione dopu un fallimentu, questu hè a ricuperazione da una copia di salvezza.
Ci sò parechje backups è sò tutti diffirenti. Quasi ogni venditore Postgres hà a so propria suluzione di salvezza.
Se pigliate tutti i sistemi di salvezza, creanu una matrice di funziunalità è calculate in scherzu u determinante in questa matrice, serà cero. Chì significà questu? Chì si pigliate un schedariu di salvezza specificu, allora ùn pò micca esse assemblatu da pezzi di tutti l'altri. Hè unicu in a so implementazione, hè unicu in u so scopu, hè unicu in l'idee chì sò incrustati in questu. È sò tutti specifichi.
Mentre avemu travagliatu annantu à questu prublema, CitusData hà lanciatu u prughjettu WAL-G. Questu hè un sistema di salvezza chì hè statu fattu cù un ochju à l'ambienti nuvola. Avà CitusData hè digià parte di Microsoft. È in quellu mumentu, ci piaceva assai l'idee chì sò state stabilite in e versioni iniziali di WAL-G. È avemu cuminciatu à cuntribuisce à stu prughjettu.
Avà ci sò parechje decine di sviluppatori in stu prughjettu, ma i primi 10 cuntributori à WAL-G includenu 6 Yandexoids. Avemu purtatu assai di e nostre idee quì. E, sicuru, l'avemu implementatu noi stessi, li pruvemu noi stessi, li lanciamu in a produzzione noi stessi, l'utilicemu noi stessi, avemu capitu induve si move dopu, mentre interagisce cù a grande comunità WAL-G.
E da u nostru puntu di vista, avà stu sistema di salvezza, cumpresu cù i nostri sforzi, hè diventatu ottimali per un ambiente di nuvola. Questu hè u megliu costu di salvezza di Postgres in u nuvulu.
Cosa significa? Avemu prumuvutu una idea abbastanza grande: a copia di salvezza duveria esse sicura, economica per operare è u più veloce pussibule per restaurà.
Perchè deve esse economicu per operare? Quandu nunda ùn hè ruttu, ùn avete micca sapè chì avete copia di salvezza. Tuttu u travagliu bè, perdite u più pocu CPU pussibule, utilizate u più pocu di i vostri risorse di discu pussibule, è mandate quant'è pochi bytes à a reta per ùn interferiscenu micca cù a carica di i vostri servizii preziosi.
È quandu tuttu si rompe, per esempiu, l'amministratore abbandunò i dati, qualcosa hè andatu male, è avete bisognu urgente di vultà in u passatu, ricuperate cù tutti i soldi, perchè vulete chì i vostri dati tornanu rapidamente è intactu.
E avemu prumuvutu sta idea simplice. È, ci pari, avemu riesciutu à implementà.
Ma ùn hè micca tuttu. Vulemu una cosa più chjuca. Vulemu parechje basa di dati diffirenti. Micca tutti i nostri clienti usanu Postgres. Alcune persone utilizanu MySQL, MongoDB. In a cumunità, altri sviluppatori anu supportatu FoundationDB. È sta lista hè in espansione constantemente.
A cumunità li piace l'idea chì a basa di dati sia eseguita in un ambiente gestitu in u nuvulu. È i sviluppatori mantenenu e so basa di dati, chì ponu esse salvate uniformemente cù Postgres cù u nostru sistema di salvezza.
Chì avemu amparatu da sta storia ? U nostru pruduttu, cum'è una divisione di sviluppu, ùn hè micca linee di codice, ùn hè micca dichjarazioni, ùn hè micca schedari. U nostru pruduttu ùn hè micca richieste di pull. Eccu l'idee chì trasmettemu à a cumunità. Questa hè a cumpetenza tecnologica è u muvimentu di a tecnulugia versu un ambiente nuvola.
Ci hè una basa di dati cum'è Postgres. Mi piace u core di Postgres u più. Passu assai tempu à sviluppà u core di Postgres cù a cumunità.
Ma quì ci vole à dì chì Yandex.Cloud hà una stallazione interna di basa di dati amministrati. È hà cuminciatu assai tempu fà in Yandex.Mail. L'expertise chì avà hà purtatu à a gestione di Postgres hè stata accumulata quandu u mail vulia passà in Postgres.
Mail hà esigenze assai simili à u nuvulu. Hè bisognu di pudè scalà à una crescita esponenziale inespettata in ogni puntu di i vostri dati. È u mail avia digià una carica cù qualchi cintinara di milioni di cassette postali di un gran numaru d'utilizatori chì facenu constantemente parechje dumande.
È questu era una sfida abbastanza seria per a squadra chì sviluppava Postgres. Allora, ogni prublema chì avemu scontru hè statu signalatu à a cumunità. E sti prublemi sò stati curretti, è curretti da a cumunità in certi lochi ancu à u livellu di supportu pagatu per qualchì altra basa di dati è ancu megliu. Questu hè, pudete mandà una lettera à u pirate PgSQL è riceve una risposta in 40 minuti. U supportu pagatu in certi basa di dati pò pensà chì ci sò più cose di priorità cà u vostru bug.
Avà l'installazione interna di Postgres hè qualchì petabyte di dati. Quessi sò parechji milioni di richieste per seconda. Quessi sò millaie di clusters. Hè assai grande scala.
Ma ci hè una sfumatura. Vive micca nantu à unità di rete di fantasia, ma in hardware abbastanza simplice. È ci hè un ambiente di prova specificamente per cose novi interessanti.
È in un certu momentu in l'ambiente di teste avemu ricevutu un missaghju chì indicava chì l'invarianti internu di l'indici di basa di dati sò stati violati.
Un invariant hè un tipu di relazione chì aspittemu di mantene sempre.
Una situazione assai critica per noi. Indica chì certi dati pò esse persu. È a perdita di dati hè qualcosa di veramente catastròficu.
L'idea generale chì seguitamu in e basa di dati amministrati hè chì ancu cù u sforzu, serà difficiule di perde dati. Ancu s'è vo sguassate deliberatamente, avete sempre bisognu di ignurà a so assenza per un longu periodu di tempu. A sicurità di dati hè una religione chì seguimu abbastanza diligentemente.
È quì una situazione si presenta chì suggerisce chì ci pò esse una situazione per quale ùn pudemu micca esse preparatu. È avemu cuminciatu à preparà per sta situazione.
A prima cosa chì avemu fattu era intarrà i logs da sti millaie di clusters. Avemu trovu quale di i clusters sò stati situati nantu à dischi cun firmware problematicu chì perdevanu l'aghjurnamenti di a pagina di dati. Marcatu tuttu u codice di dati Postgres. E avemu marcatu quelli messagi chì indicanu violazioni di invarianti internu cù codice chì hè designatu per detectà a corruzzione di dati.
Stu patch era praticamente accettatu da a cumunità senza assai discussione, perchè in ogni casu specificu era evidenti chì qualcosa di male era accadutu è avia da esse informatu à u logu.
Dopu questu, avemu ghjuntu à u puntu chì avemu un monitoraghju chì scans logs. È in casu di messagi sospetti, sveglia l'ufficiale di u duvere, è l'uffiziale di u duvere ripara.
Ma! Scanning logs hè una operazione economica nantu à un cluster è catastroficamente caru per mille clusters.
Avemu scrittu una estensione chjamata . Crea una vista di a basa di dati in quale pudete selezziunà rapidamente è à pocu pressu statistiche nantu à l'errori passati. È s'ellu ci vole à sveglià l'ufficiale di u duvere, allora avemu da sapè da questu senza scanning files gigabyte, ma estrattendu uni pochi bytes da a tavola hash.
Questa estensione hè stata aduttata, per esempiu, in u repository per . Se vulete usà, pudete installà sè stessu. Di sicuru, hè open source.
Ma ùn hè micca tuttu. Avemu cuminciatu à aduprà Amcheck, una estensione di a cumunità, per truvà violazioni invarianti in l'indici.
È avemu scupertu chì, se l'operate à scala, ci sò bug. Avemu cuminciatu à riparà elli. E nostre correzioni sò state accettate.
Avemu scupertu chì sta estensione ùn pò analizà l'indici GiST & GIT. Avemu fattu u sustegnu. Ma stu supportu hè sempre discututu da a cumunità, perchè questu hè una funziunalità relativamente nova è ci sò assai dettagli.
È avemu ancu scupertu chì quandu cuntrollà l'indici per violazioni nantu à u capu di replicazione, nantu à u maestru, tuttu funziona bè, ma nantu à e rèpliche, nantu à u seguitore, a ricerca di corruzzione ùn hè micca cusì efficace. Ùn sò micca tutti l'invarianti verificati. È un invariante ci hà assai disturbatu. È avemu passatu un annu è mezu à cumunicà cù a cumunità per attivà stu cuntrollu di e rèpliche.
Avemu scrittu codice chì deve seguità tutti i protokolli pò .... Avemu discututu stu patch per un bellu pezzu cù Peter Gaghan da Crunchy Data. Hà avutu à mudificà ligeramente l'arburu B esistente in Postgres per accettà stu patch. Hè statu accettatu. È avà a verificazione di l'indici nantu à e repliche hè ancu diventata abbastanza efficace per detectà e violazioni chì avemu scontru. Vale à dì, queste sò e violazioni chì ponu esse causate da errori in u firmware di discu, bugs in Postgres, bugs in u kernel Linux, è prublemi di hardware. Una lista abbastanza larga di fonti di prublemi per quale avemu preparatu.
Ma in più di l'indici, ci hè una parte cum'è heap, vale à dì u locu induve i dati sò almacenati. È ùn sò micca assai invarianti chì ponu esse verificati.
Avemu una estensione chjamata Heapcheck. Avemu cuminciatu à sviluppà. È in parallelu, cun noi, a cumpagnia EnterpriseDB hà ancu cuminciatu à scrive un modulu, chì chjamanu Heapcheck in u listessu modu. Solu l'avemu chjamatu PgHeapcheck, è l'anu chjamatu Heapcheck. L'anu cù funzioni simili, una firma un pocu sfarente, ma cù i stessi idee. L'anu implementatu un pocu megliu in certi lochi. È l'anu publicatu in open source prima.
È avà avemu sviluppatu a so espansione, perchè ùn hè più a so espansione, ma l'espansione di a cumunità. È in u futuru, questu hè una parte di u kernel chì serà furnitu à tutti per ch'elli ponu cunnosce i prublemi futuri in anticipu.
In certi lochi, avemu ancu ghjuntu à a cunclusione chì avemu falsi pusitivi in i nostri sistemi di surviglianza. Per esempiu, u sistema 1C. Quandu si usa una basa di dati, Postgres qualchì volta scrive dati in questu chì pò leghje, ma pg_dump ùn pò micca leghje.
Sta situazione pareva corruzzione à u nostru sistema di rilevazione di prublemi. L'ufficiale di turnu hè stata svegliata. L'ufficiale di guardia hà guardatu ciò chì succede. Dopu qualchì tempu, un cliente hè vinutu è disse chì aghju avutu prublemi. L'assistente spiegò quale era u prublema. Ma u prublema hè in u core di Postgres.
Aghju trovu una discussione nantu à sta funzione. È hà scrittu chì avemu scontru sta funzione è era spiacevoli, una persona si svegliò di notte per capisce ciò chì era.
A cumunità hà rispostu: "Oh, avemu veramente bisognu di riparà".
Aghju una analogia simplice. Sè andate in una scarpa chì hà un granu di sabbia in questu, allora, in principiu, pudete passà - senza prublema. Se vendi stivali à millaie di persone, allora femu stivali senza sabbia in tuttu. È se unu di l'utilizatori di i vostri scarpi hà da curriri una maratona, allora vulete fà scarpi assai boni, è poi scala à tutti i vostri utilizatori. È tali utilizatori inespettati sò sempre in l'ambienti nuvola. Ci sò sempre utilizatori chì sfruttanu u cluster in qualchì modu originale. Avete sempre preparatu per questu.
Chì avemu amparatu quì ? Avemu amparatu una cosa simplice : u più impurtante hè di spiegà à a cumunità chì ci hè un prublema. Se a cumunità hà ricunnisciutu u prublema, allora a cumpetizione naturale nasce per risolve u prublema. Perchè tutti volenu risolve un prublema impurtante. Tutti i venditori, tutti i pirate capiscenu chì elli stessi ponu passà nantu à questu rake, cusì volenu eliminà.
Sè vo site à travaglià nant'à un prublema, ma ùn disturba nimu, ma voi, ma vi travaglià nant'à u sistematicamente è hè ultimamente cunzidiratu un prublema, allura a vostra dumanda pull sarà definitivamente accettatu. U vostru patch serà accettatu, e vostre migliure o ancu e dumande di migliure seranu riviste da a cumunità. À a fine di u ghjornu, facemu a basa di dati megliu per l'altri.
Una basa di dati interessanti hè Greenplum. Hè una basa di dati assai parallela basata nantu à a basa di codice Postgres, chì sò assai familiarizatu.
E Greenplum hà una funziunalità interessante - aghjunghje tavule ottimizzate. Quessi sò tavule chì pudete aghjunghje rapidamente. Puderanu esse colonnari o fila.
Ma ùn ci era micca clustering, vale à dì ùn ci era micca funziunalità induve pudete organizà e dati situati in a tavula in cunfurmità cù l'ordine chì hè in unu di l'indici.
I ragazzi di u taxi sò ghjunti à mè è mi dissenu: "Andrey, sapete Postgres. È quì hè quasi u listessu. Cambia à 20 minuti. Pigliate è fate ". Pensu chì sì, cunnoscu Postgres, cambiendu per 20 minuti - aghju bisognu di fà questu.
Ma nò, ùn era micca 20 minuti, l'aghju scrittu annantu à mesi. À a cunferenza PgConf.Russia, aghju avvicinatu à Heikki Linakangas da Pivotal è dumandò: "Ci sò prublemi cù questu? Perchè ùn ci hè micca un clustering di tavule ottimizzatu per append?" Ellu dice: "Pigliate i dati. Tu sorte, riarrangiate. Hè solu un travagliu ". Eiu: "Oh, sì, basta à piglià è fà". Dice: "Iè, avemu bisognu di mani libere per fà questu". Pensu chì aghju bisognu di fà questu.
È uni pochi di mesi dopu aghju mandatu una dumanda di pull chì implementava sta funziunalità. Questa dumanda di pull hè stata rivista da Pivotal inseme cù a cumunità. Di sicuru, ci sò stati bug.
Ma u più interessante hè chì quandu sta dumanda di pull hè stata fusionata, i bugs sò stati truvati in Greenplum stessu. Avemu trovu chì i tavulini di cumuli volte rompenu a transazzione quandu sò raggruppati. È questu hè una cosa chì deve esse riparata. È ella hè in u locu chì aghju appena toccu. È a mo reazione naturale hè stata - va bè, lasciami ancu fà questu.
Aghju riparatu stu bug. Mandatu una dumanda di pull à i riparatori. Hè statu tombu.
Dopu à quessa, si scopre chì sta funziunalità deve esse acquistata in a versione Greenplum per PostgreSQL 12. Questu hè, l'avventura di 20 minuti cuntinueghja cù novi aventure interessanti. Hè stata interessante per tuccà u sviluppu attuale, induve a cumunità hè tagliata funzioni novi è più impurtanti. Hè congelatu.
Ma ùn hè micca finitu quì. Dopu tuttu, hè statu chì avemu bisognu di scrive documentazione per tuttu questu.
Aghju cuminciatu à scrive documentazione. Per furtuna, i documentalisti di Pivotal sò ghjunti. L'inglese hè a so lingua nativa. M'anu aiutatu cù a documentazione. In fatti, elli stessi anu riscritto ciò chì aghju prupostu in un veru inglese.
È quì, pare, l'avventura hè finita. E sapete ciò chì hè accadutu tandu ? I picciotti di u taxi sò ghjunti à mè è mi dissenu: "Ci sò ancu duie avventure, ognunu per 10 minuti". È chì li devu dì ? Aghju dettu chì avà daraghju un rapportu nantu à a scala, allora vedemu e vostre avventure, perchè questu hè un travagliu interessante.
Chì avemu amparatu da stu casu? Perchè u travagliu cù open source hè sempre travagliatu cù una persona specifica, hè sempre travagliatu cù a cumunità. Perchè in ogni tappa aghju travagliatu cù un sviluppatore, un tester, un pirate, un documentaliste, un architettu. Ùn aghju micca travagliatu cù Greenplum, aghju travagliatu cù e persone intornu à Greenplum.
Ma! Ci hè un altru puntu impurtante - hè solu u travagliu. Hè, vene, beie caffè, scrivite codice. Tutti i tipi di invarianti simplici travaglianu. Fate di solitu - sarà bè! È hè un travagliu assai interessante. Ci hè una dumanda per stu travagliu da i clienti Yandex.Cloud, utilizatori di i nostri clusters sia in Yandex sia fora. E pensu chì u nùmeru di prughjetti in quale participemu aumenterà è a prufundità di a nostra implicazione crescerà ancu.
Eccu tuttu. Passemu à e dumande.
Sessione di dumande
Bonghjornu! Avemu una altra sessione di dumande è risposte. È in u studiu Andrei Borodin. Questa hè a persona chì vi hà dettu solu nantu à a cuntribuzione di Yandex.Cloud è Yandex à open source. U nostru rapportu avà ùn hè micca solu nantu à u Cloud, ma à u stessu tempu simu basatu annantu à tali tecnulugia. Senza ciò chì avete fattu in Yandex, ùn ci saria micca serviziu in Yandex.Cloud, cusì vi ringraziu da mè personalmente. È a prima dumanda da a trasmissione: "Quale hè scrittu annantu à ognunu di i prughjetti chì avete mintuatu?"
U sistema di salvezza in WAL-G hè scrittu in Go. Questu hè unu di i prughjetti più novi chì avemu travagliatu. Hè literalmente solu 3 anni. È una basa di dati hè spessu di affidabilità. E questu significa chì e basa di dati sò abbastanza vechji è sò generalmente scritti in C. U prughjettu Postgres hà iniziatu circa 30 anni fà. Allora u C89 era a scelta bona. È Postgres hè scrittu annantu. Basi di dati più muderni cum'è ClickHouse sò generalmente scritti in C++. Tuttu u sviluppu di u sistema hè basatu annantu à C è C++.
Una quistione di u nostru direttore finanziariu, chì hè rispunsevule per e spese in Cloud: "Perchè Cloud spende soldi per sustene l'open source?"
Ci hè una risposta simplice per u manager finanziariu quì. Facemu questu per fà i nostri servizii megliu. In quali modi pudemu fà megliu? Pudemu fà e cose in modu più efficiente, più veloce, è rende e cose più scalabili. Ma per noi, sta storia hè principalmente di affidabilità. Per esempiu, in un sistema di salvezza, rivisemu u 100% di i patches chì si applicanu. Sapemu quale hè u codice. È simu più cunfortu à sparghje novi versioni à a produzzione. Hè, prima di tuttu, si tratta di cunfidenza, di prontezza per u sviluppu è di affidabilità
Un'altra quistione: "Sò i bisogni di l'utilizatori esterni chì campanu in Yandex.Cloud diffirenti da l'utilizatori internu chì campanu in u Cloud internu?"
U prufilu di carica hè, sicuru, sfarente. Ma da u puntu di vista di u mo dipartimentu, tutti i casi speciali è interessanti sò creati nantu à una carica non standard. I sviluppatori cù l'imaginazione, i sviluppatori chì facenu l'imprevisu, sò cum'è prubabile di truvà sia internamente sia esternamente. In questu sensu, simu tutti quasi uguali. È, prubabilmente, l'unica funzione impurtante in l'operazione Yandex di basa di dati serà chì in Yandex avemu un insegnamentu. À un certu puntu, una certa zona di dispunibilità hè cumplettamente in ombra, è tutti i servizii Yandex duveranu in qualchì manera cuntinuà à funziunà malgradu questu. Questa hè una piccula differenza. Ma crea assai sviluppu di ricerca à l'interfaccia di a basa di dati è a pila di rete. Altrimenti, e installazioni esterne è interne generanu e stesse richieste di funzioni è richieste simili per migliurà a affidabilità è u rendiment.
Prussima quistione: "Cumu vi sentite personalmente u fattu chì assai di ciò chì fate hè utilizatu da altri Nuvole?" Ùn avemu micca nome specifichi, ma assai prughjetti chì sò stati fatti in Yandex.Cloud sò usati in i nuvuli di l'altri.
Questu hè cool. Prima, hè un signu chì avemu fattu qualcosa bè. È graffia l'ego. È simu più cunfidenti chì avemu fattu a decisione bona. Per d 'altra banda, questu hè a speranza chì in u futuru questu ci purterà idee novi, richieste novi da utilizatori di terzu. A maiò parte di i prublemi nantu à GitHub sò creati da amministratori di sistema individuali, DBA individuali, architetti individuali, ingegneri individuali, ma qualchì volta e persone cù una sperienza sistematica venenu è dicenu chì in u 30% di certi casi avemu stu prublema è pensemu cumu risolve. Questu hè ciò chì aspettemu più. Aspittemu di sparta sperienze cù altre piattaforme cloud.
Avete parlatu assai di a maratona. Sò chì avete curritu una maratona in Mosca. Di cunsiguenza? Superatu i ragazzi di PostgreSQL?
Innò, Oleg Bartunov corre assai veloce. Finì una ora davanti à mè. In generale, sò cuntentu di quantu aghju ghjuntu. Per mè, solu finisce era un successu. In generale, hè surprisante chì ci sò tanti corridori in a cumunità postgres. Mi pari chì ci hè un tipu di relazione trà l'sport aerobicu è u desideriu di prugrammazione di sistemi.
Dici chì ùn ci sò micca corridori in ClickHouse?
Sò sicuru chì sò quì. ClickHouse hè ancu una basa di dati. A propositu, Oleg mi scrive avà: "Andemu per una corsa dopu à u rapportu?" Questa hè una grande idea.
Un'altra dumanda da a trasmissione da Nikita: "Perchè avete riparatu u bug in Greenplum stessu è ùn dà micca à i juniors?" True, ùn hè micca assai chjaru quale hè u bug è in quale serviziu, ma probabilmente significa quellu chì avete parlatu.
Iè, in principiu, puderia esse datu à qualchissia. Era solu u codice chì aghju cambiatu solu. È era naturali di cuntinuà à fà subitu. In principiu, l'idea di sparta sapè fà cù a squadra hè una bona idea. Di sicuru, sparteremu i travaglii di Greenplum trà tutti i membri di a nostra divisione.
Siccomu si parla di juniors, eccu una quistione. A persona hà decisu di creà u primu commit in Postgres. Chì ci vole à fà per fà u primu impegnu ?
Questa hè una quistione interessante: "Da induve principià?" Di solitu hè abbastanza difficiule di principià cù qualcosa in u kernel. In Postgres, per esempiu, ci hè una lista di fà. Ma in fattu, questu hè un fogliu di ciò chì anu pruvatu à fà, ma ùn hà micca successu. Quessi sò cose complicate. È di solitu pudete truvà qualchi utilità in l'ecosistema, alcune estensioni chì ponu esse migliurate, chì attiranu menu attenzione da i sviluppatori di u kernel. È, dunque, ci sò più punti per a crescita quì. À u Google Summer di u prugramma di codice, ogni annu a cumunità postgres presenta assai temi diffirenti chì puderanu esse indirizzati. Quist'annu avemu avutu, pensu, trè studienti. Unu ancu hà scrittu in WAL-G nantu à temi chì sò impurtanti per Yandex. In Greenplum, tuttu hè più simplice chè in a cumunità Postgres, perchè i pirate di Greenplum trattanu assai bè e richieste di pull è cumincianu à rivisione subitu. Invià un patch à Postgres hè una materia di mesi, ma Greenplum vene in un ghjornu è vede ciò chì avete fattu. Un'altra cosa hè chì Greenplum hà bisognu di risolve i prublemi attuali. Greenplum ùn hè micca largamente utilizatu, cusì truvà u vostru prublema hè abbastanza difficiule. È prima di tuttu, avemu bisognu di risolve i prublemi, sicuru.
Source: www.habr.com