Verrà preso in considerazione il contributo di Yandex ai seguenti database.
- CliccaCasa
- Odyssey
- Recupero ad un punto nel tempo (WAL-G)
- PostgreSQL (inclusi logerrors, Amcheck, heapcheck)
- prugna verde
Video:
Ciao mondo! Il mio nome è Andrej Borodin. E in Yandex.Cloud sto sviluppando database relazionali aperti a vantaggio dei clienti Yandex.Cloud e Yandex.Cloud.
In questo discorso parleremo delle sfide dei database aperti su larga scala. Perché è importante? Perché piccoli, piccoli problemi, che, come le zanzare, poi diventano elefanti. Diventano grandi quando hai molti cluster.
Ma non è questo il punto. Accadono cose incredibili. Cose che accadono in un caso su un milione. E in un ambiente cloud, devi essere preparato per questo, perché cose incredibili diventano molto probabili quando qualcosa esiste su larga scala.
Ma! Quali sono i vantaggi dei database aperti? Il fatto che tu abbia un'opportunità teorica per affrontare qualsiasi problema. Hai il codice sorgente, hai conoscenze di programmazione. Uniamo e lavoriamo.
Quali approcci esistono nel lavorare su software open source?
- L'approccio più comprensibile è utilizzare il software. Se usi protocolli, se usi standard, se usi formati, se scrivi richieste su software open source, allora lo supporti già.
- Rendi il suo ecosistema più grande. Rendi più probabile la scoperta anticipata di un bug. Aumenti l'affidabilità di questo sistema. Aumenti la disponibilità degli sviluppatori sul mercato. Migliora questo software. Sei già un collaboratore se hai appena trovato lo stile e ci hai armeggiato.
- Un altro approccio comprensibile è quello di sponsorizzare il software open source. Ad esempio, il noto programma Google Summer of Code, in cui Google paga un gran numero di studenti provenienti da tutto il mondo con denaro comprensibile per sviluppare progetti software open source che soddisfano determinati requisiti di licenza.
- Questo è un approccio molto interessante perché permette di sviluppare il software senza spostare l'attenzione dalla comunità. Google, in quanto gigante della tecnologia, non dice che vogliamo questa funzionalità, vogliamo correggere questo bug, ed è qui che dobbiamo scavare. Google dice: “Fai quello che fai. Continua a lavorare come hai sempre fatto e tutto andrà bene."
- Il prossimo approccio alla partecipazione nell'open source è la partecipazione. Quando hai un problema con il software open source e ci sono sviluppatori, allora i tuoi sviluppatori iniziano a risolvere i problemi. Cominciano a rendere la tua infrastruttura più efficiente, i tuoi programmi più veloci e più affidabili.
Uno dei progetti open source Yandex più famosi è ClickHouse. Si tratta di un database che nasce come risposta alle sfide che Yandex.Metrica deve affrontare.
E come database, è stato realizzato in open source per creare un ecosistema e svilupparlo insieme ad altri sviluppatori (non solo all'interno di Yandex). E ora è un grande progetto in cui sono coinvolte molte aziende diverse.
In Yandex.Cloud, abbiamo realizzato ClickHouse su Yandex Object Storage, ovvero sul cloud storage.
Perché è importante nel cloud? Perché qualsiasi database funziona in questo triangolo, in questa piramide, in questa gerarchia di tipi di memoria. Hai registri veloci ma piccoli e SSD, HDD e altri dispositivi a blocchi economici grandi ma lenti. E se sei efficiente al vertice della piramide, allora hai un database veloce. se sei efficace alla base di questa piramide, allora hai un database in scala. E a questo proposito, aggiungere un altro livello dal basso è un approccio logico per aumentare la scalabilità del database.
Come potrebbe essere fatto? Questo è un punto importante della presente relazione.
- Potremmo implementare ClickHouse su MDS. MDS è un'interfaccia di archiviazione cloud interna Yandex. È più complesso del comune protocollo S3, ma è più adatto per un dispositivo a blocchi. È più adatto per la scrittura di dati. Richiede più programmazione. I programmatori programmeranno, è anche bello, interessante.
- S3 è un approccio più comune che rende l'interfaccia più semplice al costo di un minore adattamento a determinati tipi di carichi di lavoro.
Naturalmente, volendo fornire funzionalità all'intero ecosistema ClickHouse ed eseguire le attività necessarie all'interno di Yandex.Cloud, abbiamo deciso di farlo in modo che l'intera comunità ClickHouse ne traesse beneficio. Abbiamo implementato ClickHouse su S3, non ClickHouse su MDS. E questo è molto lavoro.
Links:
"Livello di astrazione del file system"
Integrazione dell'SDK AWS S3
"Implementazione di base dell'interfaccia IDisk per S3"
"Integrazione dei motori di archiviazione dei log con l'interfaccia IDisk"
"Supporto del motore di registro per S3 e SeekableReadBuffer"
"Supporto per Storage Stripe Log S3"
"Supporto iniziale di Storage MergeTree per S3"
Supporto completo di MergeTree per S3
"Supporta MergeTree replicato su S3"
"Aggiungi credenziali predefinite e intestazioni personalizzate per l'archiviazione s3"
"S3 con configurazione proxy dinamica"
S3 con risolutore proxy
Questo è un elenco di richieste pull per l'implementazione del file system virtuale di ClickHouse. Sono molte le richieste pull.
Links:
"Implementazione ottimale degli hardlink DiskS3"
"Client HTTP S3: evita di copiare il flusso di risposta in memoria"
"Evita di copiare l'intero flusso di risposta in memoria in S3 HTTP
cliente"
"Possibilità di contrassegnare nella cache e indicizzare i file per il disco S3"
"Sposta le parti da DiskLocal a DiskS3 in parallelo"
Ma il lavoro non è finito qui. Dopo aver creato la funzionalità, è stato necessario ulteriore lavoro per ottimizzare questa funzionalità.
Links:
"Aggiungi eventi SelectedRows e SelectedBytes"
"Aggiungi eventi di profilazione dalla richiesta S3 a system.events"
"Aggiungi QueryTimeMicroseconds, SelectQueryTimeMicroseconds e InsertQueryTimeMicroseconds"
E allora occorreva renderlo diagnosticabile, istituire un monitoraggio e renderlo gestibile.
E tutto questo è stato fatto affinché l'intera comunità, l'intero ecosistema ClickHouse ricevesse il risultato di questo lavoro.
Passiamo ai database transazionali, ai database OLTP, che sono più vicini a me personalmente.
Questa è la divisione di sviluppo DBMS open source. Questi ragazzi stanno facendo magie di strada per migliorare i database aperti transazionali.
Uno dei progetti che possiamo usare come esempio per parlare di come e cosa facciamo è Connection Pooler in Postgres.
Postgres è un database di processi. Ciò significa che il database dovrebbe includere il minor numero possibile di connessioni di rete che funzionino con le transazioni.
D'altra parte, in un ambiente cloud, una situazione tipica è quando un migliaio di connessioni arrivano contemporaneamente a un cluster. E il compito del pooler di connessioni è quello di racchiudere un migliaio di connessioni in un numero limitato di connessioni server.
Possiamo dire che il Connection Pooler è un operatore telefonico che sposta i byte affinché raggiungano effettivamente il database.
Sfortunatamente, non esiste una parola russa valida per indicare un pool di connessioni. A volte viene definita connessione multiplexer. Se sai come chiamare il pooler di connessione, assicurati di dirmelo, sarò molto felice di parlare la lingua tecnica russa corretta.
Abbiamo esplorato i pool di connessioni adatti per un cluster postgres gestito. E PgBouncer era la soluzione migliore per noi. Ma abbiamo riscontrato una serie di problemi con PgBouncer. Molti anni fa Volodya Borodin ha riferito che usiamo PgBouncer, ci piace tutto, ma ci sono delle sfumature, c'è qualcosa su cui lavorare.
E abbiamo lavorato. Abbiamo risolto i problemi che riscontravamo, abbiamo patchato Bouncer, abbiamo provato ad attribuire la pull request all'upstream. Ma era difficile lavorare con il single-threading fondamentale.
Abbiamo dovuto effettuare una cascata da buttafuori patchati. Quando abbiamo molti buttafuori a thread singolo, nello strato superiore le connessioni vengono trasferite allo strato interno dei buttafuori. È un sistema mal gestito, difficile da costruire e difficile da scalare avanti e indietro.
Siamo giunti alla conclusione che abbiamo creato il nostro pool di connessioni, che si chiama Odyssey. L'abbiamo scritto da zero.
Nel 2019, al PgCon, ho presentato questo estrattore alla comunità degli sviluppatori. Adesso abbiamo poco meno di 2 stelle su GitHub, cioè il progetto è vivo, il progetto è popolare.
E se crei un cluster Postgres in Yandex.Cloud, sarà un cluster con Odyssey integrato, che viene riconfigurato quando il cluster viene ridimensionato avanti e indietro.
Cosa abbiamo imparato da questo progetto? Lanciare un progetto concorrente è sempre un passo aggressivo, è l'ultima risorsa quando diciamo che ci sono problemi che non vengono risolti abbastanza velocemente, non risolti negli intervalli di tempo che ci converrebbero. Ma è una misura efficace.
PgBouncer ha iniziato a svilupparsi più velocemente.
E ora ci sono altri progetti. Ad esempio, pgagroal, sviluppato dagli sviluppatori Red Hat. Perseguono obiettivi simili e implementano idee simili, ma, ovviamente, con le proprie specificità, che sono più vicine agli sviluppatori pgagroal.
Un altro caso di collaborazione con la comunità Postgres è il ripristino di un punto nel tempo. Si tratta di un ripristino di emergenza, ovvero di un ripristino da un backup.
Esistono molti backup e sono tutti diversi. Quasi tutti i fornitori di Postgres hanno la propria soluzione di backup.
Se prendiamo tutti i sistemi di backup, creiamo una matrice di caratteristiche e calcoliamo scherzosamente il determinante in questa matrice, allora sarà zero. Cosa significa questo? Cosa succede se si prende un backup particolare, non può essere assemblato dai pezzi di tutti gli altri. È unico nella sua implementazione, è unico nel suo scopo, è unico nelle idee in esso racchiuse. E sono tutti specifici.
Mentre esaminavamo questo problema, CitusData ha lanciato il progetto WAL-G. Questo è un sistema di backup realizzato con un occhio all'ambiente cloud. CitusData ora fa parte di Microsoft. E in quel momento ci sono piaciute molto le idee che erano state presentate nelle versioni iniziali di WAL-G. E abbiamo iniziato a contribuire a questo progetto.
Ora ci sono molte dozzine di sviluppatori in questo progetto, ma tra i primi 10 contributori di WAL-G ci sono 6 Yandexoid. Abbiamo portato lì molte delle nostre idee. E, naturalmente, li abbiamo implementati noi stessi, li abbiamo testati noi stessi, li abbiamo messi in produzione noi stessi, li usiamo noi stessi, abbiamo capito dove andare dopo, interagendo con la grande comunità WAL-G.
E dal nostro punto di vista, ora questo sistema di backup, tenendo conto dei nostri sforzi, è diventato ottimale per l'ambiente cloud. Questo è meglio che eseguire il backup di Postgres sul cloud.
Cosa significa? Stavamo spingendo un'idea piuttosto grande: i backup dovrebbero essere sicuri, economici da eseguire e il più veloci possibile da ripristinare.
Perché dovrebbe essere economico gestirlo? Quando nulla è rotto, non devi sapere di avere dei backup. Tutto funziona bene, sprechi meno CPU possibile, usi meno risorse disco possibile e invii meno byte possibile alla rete in modo da non interferire con il carico utile dei tuoi preziosi servizi.
E quando tutto si è rotto, ad esempio, l'amministratore ha perso i dati, qualcosa è andato storto e hai urgentemente bisogno di tornare al passato, recuperare con tutti i soldi, perché vuoi che i tuoi dati vengano restituiti rapidamente e intatti.
E abbiamo avanzato questa semplice idea. E, come ci sembra, siamo riusciti a realizzarlo.
Ma non è tutto. Volevamo ancora una piccola cosa. Volevamo molti database diversi. Non tutti i nostri clienti utilizzano Postgres. Alcuni usano MySQL, MongoDB. Nella comunità, altri sviluppatori hanno supportato FoundationDB. E questo elenco è in continua espansione.
Alla community piace l'idea di avere un database eseguito in un ambiente gestito nel cloud. E gli sviluppatori mantengono i loro database, che possono essere copiati uniformemente insieme a Postgres dal nostro sistema di backup.
Cosa abbiamo imparato da questa storia? Il nostro prodotto, come divisione di sviluppo, non è costituito da righe di codice, questi non sono operatori, questi non sono file. Il nostro prodotto non è pull request. Queste sono le idee che trasmettiamo alla comunità. Si tratta di competenze tecnologiche e del movimento della tecnologia verso l'ambiente cloud.
Esiste un database come Postgres. Mi piace di più il core Postgres. Trascorro molto tempo a sviluppare il core di Postgres con la comunità.
Ma qui devo dire che Yandex.Cloud ha un'installazione interna di database gestiti. Ed è iniziato molto tempo fa in Yandex.Mail. Il tipo di esperienza che ora ha portato alla gestione di Postgres è stata accumulata quando la posta voleva arrivare a Postgres.
La posta ha requisiti molto simili al cloud. È necessario che tu sia in grado di scalare per una crescita esponenziale inaspettata in qualsiasi punto dei tuoi dati. E la posta era già carica di alcune centinaia di milioni di caselle di posta di un numero enorme di utenti che fanno costantemente molte richieste.
Ed è stata una sfida piuttosto grande per il team di sviluppo di Postgres. Poi tutti i problemi che abbiamo riscontrato sono stati segnalati alla comunità. E questi problemi sono stati corretti, e in alcuni punti sono stati corretti dalla comunità anche a livello di supporto a pagamento per alcuni altri database e anche meglio. Cioè, puoi inviare una lettera all'hacker PgSQL e ottenere una risposta entro 40 minuti. Il supporto a pagamento in alcuni database potrebbe pensare che ci siano più cose prioritarie del tuo bug.
Ora un'installazione interna di Postgres contiene alcuni petabyte di dati. Si tratta di alcuni milioni di richieste al secondo. Si tratta di migliaia di cluster. Lei è molto grande.
Ma c'è una sfumatura. Non vive su unità di rete alla moda, ma su hardware abbastanza semplice. E c'è un ambiente di test specifico per cose nuove interessanti.
E ad un certo punto nell'ambiente di test, abbiamo ricevuto un messaggio del genere, che indica che le invarianti interne degli indici del database sono state violate.
Un invariante è un tipo di relazione che ci aspettiamo di mantenere sempre.
Una situazione molto critica per noi. Indica che alcuni dati potrebbero essere andati persi. E la perdita di dati è qualcosa di assolutamente catastrofico.
L'idea generale che seguiamo nei database gestiti è che, anche con lo sforzo, sarà difficile perdere dati. Anche se li rimuovi intenzionalmente, devi comunque ignorare la loro assenza per un lungo periodo di tempo. L’integrità dei dati è una religione che seguiamo abbastanza diligentemente.
E poi si presenta una situazione che suggerisce che potrebbe esserci una situazione per la quale potremmo non essere pronti. E abbiamo iniziato a prepararci per questa situazione.
La prima cosa che abbiamo fatto è stata seppellire i tronchi di queste migliaia di ammassi. Abbiamo scoperto quali cluster si trovano su dischi con firmware problematico che hanno perso le pagine di dati di aggiornamento. Contrassegnato tutti i dati del codice Postgres. E quei messaggi che indicano violazioni delle invarianti interne, li abbiamo contrassegnati con un codice progettato per rilevare la corruzione dei dati.
Questa patch è stata praticamente accettata dalla community senza troppe discussioni, perché in ogni caso era ovvio che era successo qualcosa di brutto, e andava segnalato nel log.
Successivamente, siamo giunti alla conclusione che disponiamo di un monitoraggio che scansiona i registri. E in caso di messaggi sospetti, sveglia l'addetto e l'addetto risolve il problema.
Ma! La scansione dei log è un'operazione economica su un cluster e catastroficamente costosa per migliaia di cluster.
Abbiamo scritto un'estensione chiamata . Crea una vista del database in cui le statistiche degli errori passati possono essere compilate in modo economico e rapido. E se hai bisogno di svegliare l'addetto, lo scopriremo non scansionando file gigabyte, ma estraendo alcuni byte dalla tabella hash.
Questa estensione è stata accettata, ad esempio, nel repository for . Se vuoi usarlo, puoi installarlo tu stesso. Ovviamente è open source.
Ma non è tutto. Abbiamo iniziato a utilizzare Amcheck, un'estensione creata dalla community per trovare violazioni invarianti negli indici.
E abbiamo scoperto che se lo sfrutti su larga scala, ci sono dei bug. Abbiamo iniziato a realizzarli. Le nostre correzioni sono state accettate.
Abbiamo scoperto che questa estensione non può analizzare gli indici GiST e GIT. Li abbiamo fatti sostenere. Ma questo supporto è ancora oggetto di discussione da parte della comunità, perché si tratta di una funzionalità relativamente nuova e contiene molti dettagli.
E abbiamo anche scoperto che nel caso del controllo degli indici per violazioni sul leader della replica, tutto funziona bene sul master, ma sulle repliche, sul follower, la ricerca della corruzione non è così efficace. Non tutti gli invarianti sono verificati. E un invariante ci ha infastidito moltissimo. E abbiamo parlato con la community per un anno e mezzo per consentire questo controllo sulle repliche.
Abbiamo scritto un codice che dovrebbe seguire tutti i protocolli can. Ho avuto una lunga discussione con Peter Gagan di Crunchy Data riguardo questa patch. Ha dovuto modificare leggermente l'albero B esistente in Postgres per accettare questa patch. È stato accettato. E ora anche il controllo degli indici sulle repliche è diventato abbastanza efficace per rilevare le violazioni che abbiamo riscontrato. Cioè, queste sono le violazioni che possono essere causate da errori nel firmware del disco, bug in Postgres, bug nel kernel Linux, problemi di Iron. Un elenco piuttosto ampio di fonti di problemi per i quali ci stavamo preparando.
Ma oltre agli indici, esiste una parte chiamata heap, ad es. il luogo in cui sono archiviati i dati. E non ci sono molti invarianti che potrebbero essere controllati.
Abbiamo un'estensione chiamata Heapcheck. Abbiamo iniziato a svilupparlo. E parallelamente a noi, anche la società EnterpriseDB ha iniziato a scrivere un modulo, che hanno chiamato allo stesso modo Heapcheck. Solo che l'abbiamo chiamato PgHeapcheck e loro l'hanno chiamato semplicemente Heapcheck. Ce l'hanno con funzioni simili, con una firma leggermente diversa, ma con le stesse idee. Li hanno implementati un po' meglio in alcuni punti. E precedentemente presentato in open source.
E ora ci occupiamo di sviluppare la loro estensione, perché questa non è più la loro estensione, ma un'estensione della comunità. E in futuro questa è una parte del kernel che verrà fornita a tutti per poter conoscere in anticipo eventuali problemi futuri.
In alcuni luoghi siamo addirittura giunti alla conclusione che nei nostri monitor siano presenti falsi positivi. Ad esempio, il sistema 1C. Quando si utilizza un database, Postgres a volte scrive dati che può leggere da solo, ma pg_dump non può leggere.
Questa situazione sembrava una corruzione nel nostro sistema di rilevamento dei problemi. L'addetto è stato svegliato. L'addetto guardò per vedere cosa stesse succedendo. Dopo un po' arrivò un cliente e disse che avevo un problema. L'addetto spiegò quale fosse il problema. Ma il problema è nel kernel Postgres.
Ho trovato una discussione su questa funzione. E ha scritto che abbiamo riscontrato questa caratteristica ed è stato spiacevole, una persona si è svegliata di notte per capire di cosa si tratta.
La comunità ha risposto: “Oh, davvero, deve essere risolto”.
Ho una semplice analogia. Se cammini con una scarpa che ha un granello di sabbia, allora, in linea di principio, puoi andare oltre, va bene. Se vendi scarpe a migliaia di persone, allora facciamo scarpe senza sabbia. E se uno degli utenti delle tue scarpe correrà una maratona, allora vorrai realizzare scarpe ottime e poi adattarle a tutti i tuoi utenti. E questi utenti inaspettati si trovano sempre nell'ambiente cloud. Ci sono sempre utenti che gestiscono il cluster in modo originale. Devi sempre prepararti per questo.
Cosa abbiamo imparato qui? Abbiamo imparato una cosa semplice: la cosa più importante è spiegare alla comunità che c'è un problema. Se la comunità ha riconosciuto il problema, allora c’è una competizione naturale per risolverlo. Perché tutti vogliono risolvere un problema importante. Tutti i venditori, tutti gli hacker capiscono che loro stessi possono calpestare questo rastrello, quindi vogliono eliminarli.
Se stai lavorando su qualche problema, ma non disturba nessuno tranne te, ma ci stai lavorando sistematicamente e alla fine è stato considerato un problema, la tua richiesta pull sarà sicuramente accettata. La tua patch verrà accettata, i tuoi miglioramenti o anche le richieste di miglioramento saranno presi in considerazione dalla comunità. Dopotutto, miglioriamo il database l'uno per l'altro.
Un database interessante è Greenplum. È un database altamente parallelo basato sulla base di codice Postgres con cui ho familiarità.
E Greenplum ha una funzionalità interessante: aggiunge tabelle ottimizzate. Queste sono le tabelle in cui puoi aggiungere rapidamente. Possono essere colonnari o in linea.
Ma non c'era il clustering, cioè non c'era alcuna funzionalità quando è possibile ordinare i dati presenti nella tabella secondo l'ordine che si trova in uno degli indici.
I ragazzi del taxi sono venuti da me e hanno detto: “Andrey, conosci Postgres. E qui è quasi la stessa cosa. Cambio per 20 minuti. Prendilo e fallo." Ho pensato, sì, conosco Postgres, passando a 20 minuti: devo farlo.
Ma no, non sono passati 20 minuti, sono mesi che scrivo questo. Alla conferenza PgConf.Russia, mi sono avvicinato a Heikki Linakangas di Pivotal e ho chiesto: “Ci sono problemi con questo? Perché non esiste un clustering di tabelle ottimizzate per l'aggiunta?". Dice: “Prendi i dati. Ordinare, tradurre. È solo lavoro." Io: "Oh, sì, devi solo andare e farlo." Dice: "Sì, abbiamo bisogno di mani libere per farlo". Ho pensato che questo fosse esattamente ciò che dovevo fare.
E pochi mesi dopo ho inviato una richiesta pull che implementava questa funzionalità. Questa richiesta pull è stata esaminata in Pivotal insieme alla community. Naturalmente c'erano degli insetti.
Ma la cosa più interessante è che quando questa richiesta pull è stata unita, sono stati rilevati bug nello stesso Greenplum. Abbiamo scoperto che le tabelle heap a volte interrompono la transazionalità quando vengono raggruppate in cluster. E questa è la cosa che deve essere risolta. E lei è nel posto che ho appena toccato. E la mia reazione naturale è stata: beh, lasciami fare anche questo.
Ho corretto questo bug. Inviata una richiesta pull per le correzioni. È stato ucciso.
Successivamente, si è scoperto che questa funzionalità deve essere ottenuta nella versione Greenplum per PostgreSQL 12. Cioè, le avventure per 20 minuti continuano con nuove avventure interessanti. È stato interessante toccare con mano lo sviluppo attuale, dove la comunità ha visto caratteristiche nuove e più importanti. E' morto.
Ma non è finita qui. Dopotutto, si è scoperto che era necessario scrivere la documentazione per tutto questo.
Ho iniziato a scrivere documentazione. Fortunatamente sono arrivati i documenti di Pivotal. Per loro l’inglese è la loro lingua madre. Mi hanno aiutato con la documentazione. In effetti, loro stessi hanno riscritto ciò che ho suggerito in inglese reale.
E quella sembrava essere la fine dell'avventura. E sai cosa è successo dopo? I ragazzi del taxi sono venuti da me e mi hanno detto: "Ci sono ancora due avventure, ciascuna di 10 minuti". E cosa dovrei dire loro? Ho detto che adesso farò un resoconto sulla bilancia, poi vedremo le tue avventure, perché questo è un lavoro interessante.
Cosa abbiamo imparato in questo caso? Il fatto che lavorare con l'open source significa sempre lavorare con una persona specifica, significa sempre lavorare con la comunità. Perché in ogni singola fase ho lavorato con qualche sviluppatore, con qualche tester, con qualche hacker, con qualche documentatore, con qualche architetto. Non ho lavorato con Greenplum, ho lavorato con le persone intorno a Greenplum.
Ma! C'è un altro punto importante: è solo lavoro. Cioè, vieni, bevi un caffè, scrivi codice. Tutti i tipi di invarianti semplici funzionano. Fallo normalmente: andrà tutto bene! Ed è un lavoro piuttosto interessante. C'è una richiesta per questo lavoro da parte dei clienti Yandex.Cloud, utenti dei nostri cluster sia all'interno che all'esterno di Yandex. E penso che aumenterà il numero di progetti a cui parteciperemo e aumenterà anche la profondità del nostro coinvolgimento.
È tutto. Passiamo alle domande.
Sessione di domande
Ciao! Abbiamo un'altra sessione di domande e risposte. E nello studio Andrey Borodin. Questa è la persona che ti ha appena parlato del contributo di Yandex.Cloud e Yandex all'open source. Il nostro report non riguarda interamente il Cloud, ma allo stesso tempo ci basiamo su tali tecnologie. Se non fosse stato per quello che hai fatto all'interno di Yandex, non ci sarebbe stato alcun servizio in Yandex.Cloud, quindi grazie da parte mia personalmente. E la prima domanda della trasmissione: "Cosa c'è scritto in ognuno dei progetti che hai citato?".
Il sistema di backup in WAL-G è scritto in Go. Questo è uno dei progetti più recenti su cui abbiamo lavorato. Ha letteralmente solo 3 anni. E il database spesso riguarda l'affidabilità. E questo significa che i database sono piuttosto vecchi e solitamente sono scritti in C. Il progetto Postgres è iniziato circa 30 anni fa. Allora il C89 è stata la scelta giusta. E sopra c'è scritto Postgres. I database più moderni come ClickHouse sono solitamente già scritti in C++. Tutto lo sviluppo del sistema è basato su C e C++.
Una domanda del nostro responsabile finanziario, che si occupa delle spese nel Cloud: "Perché il Cloud spende soldi per supportare l'open source?".
C'è una risposta semplice per il direttore finanziario. Lo facciamo per migliorare i nostri servizi. In che modo possiamo fare meglio? Possiamo rendere le cose più efficienti, più veloci, più scalabili. Ma per noi questa storia riguarda principalmente l’affidabilità. Ad esempio, nel sistema di backup, esamineremo il 100% delle patch ad esso applicabili. Sappiamo qual è il codice. E siamo più rilassati nel lanciare nuove versioni in produzione. Cioè, prima di tutto, si tratta di fiducia, di disponibilità allo sviluppo e di affidabilità
Un'altra domanda: "I requisiti degli utenti esterni che vivono in Yandex.Cloud differiscono da quelli degli utenti interni che vivono nel Cloud interno?".
Il profilo di carico è, ovviamente, diverso. Ma dal punto di vista del mio dipartimento, tutti i casi speciali e interessanti vengono creati con un carico non standard. Sviluppatori dotati di immaginazione, sviluppatori che fanno cose inaspettate, hanno la stessa probabilità di essere trovati sia all'interno che all'esterno. A questo proposito, siamo tutti più o meno uguali. E, probabilmente, l'unica caratteristica importante nel funzionamento dei database Yandex sarà che all'interno di Yandex abbiamo un insegnamento. Ad un certo punto, alcune zone di accesso passano completamente nell'ombra e, nonostante ciò, tutti i servizi Yandex devono in qualche modo continuare a funzionare. Ecco una piccola differenza. Ma crea molta ricerca e sviluppo nell'interfaccia tra il database e lo stack di rete. Altrimenti, le installazioni esterne e interne creano le stesse richieste di funzionalità e richieste simili per affidabilità e prestazioni migliorate.
La domanda successiva è: “Come ti senti personalmente riguardo al fatto che gran parte di ciò che fai viene utilizzato da altri Cloud?”. Non nomineremo quelli specifici, ma molti dei progetti che abbiamo realizzato in Yandex.Cloud vengono utilizzati nei cloud di altre persone.
Questo è bello. Innanzitutto è un segno che abbiamo fatto qualcosa di giusto. E scalfisce l'ego. E siamo più sicuri di aver preso la decisione giusta. D'altronde la speranza è che in futuro ci porti nuove idee, nuove richieste da parte di utenti terzi. La maggior parte dei problemi su GitHub sono creati da singoli amministratori di sistema, singoli DBA, singoli architetti, singoli ingegneri, ma a volte persone con esperienza sistematica arrivano e dicono che nel 30% dei casi abbiamo questo o quel problema e pensiamo a come risolverlo Esso. Questo è ciò che aspettiamo con più ansia. Non vediamo l'ora di condividere esperienze con altre piattaforme cloud.
Hai parlato molto della maratona. So che hai corso una maratona a Mosca. Di conseguenza? Hai superato i ragazzi di Postgres Pro?
No, Oleg Bartunov corre molto veloce. Ha finito un'ora prima di me. Nel complesso, sono contento di quello che ho corso. Per me, solo finire è stato un risultato. In generale, è sorprendente che ci siano così tanti corridori nella comunità postgres. Mi sembra che ci sia una relazione tra gli sport aerobici e il desiderio di programmazione del sistema.
Stai dicendo che non ci sono corridori in ClickHouse?
So per certo che sono lì. ClickHouse è anche un database. A proposito, ora Oleg mi scrive: "Andiamo a correre dopo il rapporto?". Questa è una grande idea.
Un'altra domanda dalla trasmissione di Nikita: "Perché hai risolto tu stesso il bug in Greenplum e non l'hai dato ai junior?" È vero, non è molto chiaro qui che tipo di bug e in quale servizio, ma, probabilmente, si intende quello di cui hai parlato.
Sì, in linea di principio potresti darlo a qualcuno. Era solo il codice che ho appena cambiato. Ed è stato naturale continuare a farlo proprio lì. In linea di principio, l’idea di condividere le competenze con un team è una buona idea. Divideremo sicuramente i compiti di Greenplum tra tutti i membri della nostra divisione.
Visto che stiamo parlando di junior, una domanda del genere. La persona ha deciso di creare il primo commit in Postgres. Cosa deve fare per effettuare il primo commit?
Questa è una domanda interessante: "Da dove cominciare?". Di solito è difficile iniziare con qualcosa nel kernel. Postgres, ad esempio, ha una lista di cose da fare. Ma in realtà, questo è un elenco di ciò che hanno provato a fare, ma non ha funzionato. Queste sono cose complesse. E di solito puoi trovare alcune utilità nell'ecosistema, alcune estensioni che possono essere migliorate, che ricevono meno attenzione da parte degli sviluppatori del kernel. E, di conseguenza, ci sono più punti di crescita. Al programma Google Summer of code di ogni anno, la community di Postgres propone molti argomenti diversi che potrebbero essere affrontati. Quest'anno sembra che abbiamo avuto tre studenti. Qualcuno ha anche scritto in WAL-G su argomenti importanti per Yandex. Le cose sono più facili in Greenplum che nella comunità Postgres perché gli hacker Greenplum sono molto bravi con le richieste pull e iniziano subito a revisionare. Inviare una patch a Postgres è una specie di storia che dura mesi e Greenplum arriverà tra un giorno e vedrà cosa hai fatto. Un’altra cosa è che Greenplum deve risolvere i problemi reali. Greenplum non è ampiamente sfruttato, quindi trovare il tuo problema è piuttosto difficile. E prima di tutto è necessario risolvere, ovviamente, i problemi.
Fonte: habr.com