Es revisarà la contribució de Yandex a les bases de dades següents.
- Feu clic a Casa
- Odissea
- Recuperació a un punt en el temps (WAL-G)
- PostgreSQL (inclosos errors de registre, Amcheck, Heapcheck)
- Greenplum
Vídeo:
Hola món! Em dic Andrey Borodin. I el que faig a Yandex.Cloud és desenvolupar bases de dades relacionals obertes en interès dels clients Yandex.Cloud i Yandex.Cloud.
En aquesta xerrada, parlarem dels reptes als quals s'enfronten les bases de dades obertes a escala. Per què és important? Perquè petits, petits problemes que, com els mosquits, després es converteixen en elefants. Es fan grans quan tens molts clústers.
Però això no és el principal. Passen coses increïbles. Coses que passen en un de cada milió de casos. I en un entorn de núvol, cal estar preparat per a això, perquè les coses increïbles es tornen molt probables quan hi ha alguna cosa a escala.
Però! Quin és l'avantatge de les bases de dades obertes? El fet és que tens una oportunitat teòrica per fer front a qualsevol problema. Tens el codi font, tens coneixements de programació. Ho combinem i funciona.
Quins enfocaments hi ha per treballar amb programari de codi obert?
- L'enfocament més senzill és utilitzar programari. Si feu servir protocols, si feu servir estàndards, si feu servir formats, si escriviu consultes en programari de codi obert, ja ho feu servir.
- Estàs fent més gran el seu ecosistema. Augmenteu la probabilitat de detecció precoç d'un error. Augmenteu la fiabilitat d'aquest sistema. Augmenteu la disponibilitat de desenvolupadors al mercat. Vostè millora aquest programari. Ja ets un col·laborador si acabes d'aconseguir estil i has fet alguna cosa allà.
- Un altre enfocament comprensible és patrocinar programari de codi obert. Per exemple, el conegut programa Google Summer of Code, quan Google paga un gran nombre d'estudiants d'arreu del món diners comprensibles perquè desenvolupin projectes de programari obert que compleixin determinats requisits de llicència.
- Aquest és un enfocament molt interessant perquè permet que el programari evolucioni sense desviar el focus de la comunitat. Google, com a gegant de la tecnologia, no diu que volem aquesta funció, volem solucionar aquest error i aquí és on hem d'excavar. Google diu: "Fes el que fas. Seguiu treballant com heu estat treballant i tot anirà bé".
- El següent enfocament per participar en codi obert és la participació. Quan tens un problema amb el programari de codi obert i hi ha desenvolupadors, els teus desenvolupadors comencen a resoldre els problemes. Comencen a fer que la vostra infraestructura sigui més eficient, els vostres programes més ràpids i més fiables.
Un dels projectes Yandex més famosos en el camp del programari de codi obert és ClickHouse. Es tracta d'una base de dades que neix com a resposta als reptes als quals s'enfronta Yandex.Metrica.
I com a base de dades, es va fer en codi obert per tal de crear un ecosistema i desenvolupar-lo juntament amb altres desenvolupadors (no només dins de Yandex). I ara aquest és un gran projecte en el qual participen moltes empreses diferents.
A Yandex.Cloud, hem creat ClickHouse a la part superior de Yandex Object Storage, és a dir, a la part superior de l'emmagatzematge al núvol.
Per què és important això al núvol? Perquè qualsevol base de dades funciona en aquest triangle, en aquesta piràmide, en aquesta jerarquia de tipus de memòria. Teniu registres ràpids però petits i SSD barats, grans però lents, discs durs i alguns altres dispositius de bloc. I si sou eficient a la part superior de la piràmide, aleshores teniu una base de dades ràpida. si sou eficient a la part inferior d'aquesta piràmide, teniu una base de dades escalada. I en aquest sentit, afegir una altra capa des de sota és un enfocament lògic per augmentar l'escalabilitat de la base de dades.
Com es podria fer? Aquest és un punt important d'aquest informe.
- Podríem implementar ClickHouse sobre MDS. MDS és una interfície interna d'emmagatzematge al núvol de Yandex. És més complex que el protocol S3 comú, però és més adequat per a un dispositiu de bloc. És millor per gravar dades. Requereix més programació. Els programadors programaran, fins i tot és bo, és interessant.
- S3 és un enfocament més comú que fa que la interfície sigui més senzilla a costa d'una menor adaptació a determinats tipus de càrregues de treball.
Naturalment, amb la voluntat de proporcionar funcionalitat a tot l'ecosistema de ClickHouse i fer la tasca que es necessita dins de Yandex.Cloud, vam decidir assegurar-nos que tota la comunitat de ClickHouse se'n beneficiés. Hem implementat ClickHouse sobre S3, no ClickHouse sobre MDS. I això és molta feina.
Enllaços:
"Capa d'abstracció del sistema de fitxers"
"Integració AWS SDK S3"
"Implementació bàsica de la interafce IDisk per a S3"
"Integració de motors d'emmagatzematge de registres amb la interfície IDisk"
"Compatibilitat del motor de registre per a S3 i SeekableReadBuffer"
"Suport d'emmagatzematge Stripe Log S3"
"Suport inicial d'emmagatzematge MergeTree per a S3"
"Compatibilitat total de MergeTree per a S3"
"Suport ReplicatedMergeTree sobre S3"
"Afegiu credencials predeterminades i capçaleres personalitzades per a l'emmagatzematge s3"
"S3 amb configuració de proxy dinàmic"
"S3 amb resolució de proxy"
Aquesta és una llista de sol·licituds d'extracció per implementar un sistema de fitxers virtual a ClickHouse. Aquest és un gran nombre de sol·licituds d'extracció.
Enllaços:
"Implementació òptima dels enllaços durs de DiskS3"
"Client HTTP S3: eviteu copiar el flux de resposta a la memòria"
"Eviteu copiar tot el flux de respostes a la memòria a S3 HTTP
client"
"Capacitat de marcar a la memòria cau i indexar fitxers per al disc S3"
"Mou peces de DiskLocal a DiskS3 en paral·lel"
Però la feina no va acabar aquí. Un cop feta la funció, calia treballar més per optimitzar aquesta funcionalitat.
Enllaços:
"Afegiu esdeveniments SelectedRows i SelectedBytes"
"Afegiu esdeveniments de perfil de la sol·licitud S3 a system.events"
"Afegiu QueryTimeMicrosegons, SelectQueryTimeMicrosegons i InsertQueryTimeMicrosegons"
I després calia fer-ho diagnosticable, configurar un seguiment i fer-lo manejable.
I tot això es va fer perquè tota la comunitat, tot l'ecosistema ClickHouse, rebé el resultat d'aquest treball.
Passem a les bases de dades transaccionals, a les bases de dades OLTP, que són més properes a mi personalment.
Aquesta és la divisió de desenvolupament de DBMS de codi obert. Aquests nois estan fent màgia de carrer per millorar les bases de dades obertes transaccionals.
Un dels projectes, amb un exemple del qual podem parlar de com i què fem, és el Connection Pooler a Postgres.
Postgres és una base de dades de processos. Això vol dir que la base de dades hauria de tenir el menor nombre possible de connexions de xarxa que gestionen les transaccions.
D'altra banda, en un entorn de núvol, una situació típica és quan mil connexions arriben a un clúster alhora. I la tasca de l'agrupador de connexions és empaquetar mil connexions en un petit nombre de connexions de servidor.
Podem dir que l'agrupador de connexions és l'operador telefònic que reordena els bytes perquè arribin de manera eficient a la base de dades.
Malauradament, no hi ha una bona paraula russa per a agrupar connexions. De vegades s'anomena connexions multiplexor. Si sabeu com anomenar l'agrupador de connexions, assegureu-vos de dir-me, estaré encantat de parlar l'idioma tècnic rus correcte.
Hem investigat agrupadors de connexions que eren adequats per a un clúster de postgres gestionat. I PgBouncer va ser la millor opció per a nosaltres. Però hem trobat una sèrie de problemes amb PgBouncer. Fa molts anys, Volodya Borodin va informar que utilitzem PgBouncer, ens agrada tot, però hi ha matisos, hi ha alguna cosa per treballar.
I vam treballar. Hem solucionat els problemes que hem trobat, hem pegat Bouncer i hem intentat impulsar les sol·licituds d'extracció. Però era difícil treballar amb un fil únic fonamental.
Vam haver de recollir cascades de Bouncers pegats. Quan tenim molts Bouncers d'un sol fil, les connexions de la capa superior es transfereixen a la capa interna de Bouncers. Aquest és un sistema mal gestionat que és difícil de construir i escalar cap endavant i cap enrere.
Vam arribar a la conclusió que vam crear el nostre propi agrupador de connexions, que es diu Odissea. Ho vam escriure des de zero.
El 2019, a la conferència PgCon, vaig presentar aquest agrupador a la comunitat de desenvolupadors. Ara tenim una mica menys de 2 estrelles a GitHub, és a dir, el projecte està viu, el projecte és popular.
I si creeu un clúster Postgres a Yandex.Cloud, serà un clúster amb Odyssey integrat, que es reconfigura quan s'escala el clúster cap endavant o cap enrere.
Què hem après d'aquest projecte? Llançar un projecte competitiu és sempre un pas agressiu, és una mesura extrema quan diem que hi ha problemes que no s'estan resolent amb prou rapidesa, no s'estan resolent en els intervals de temps que ens convindrien. Però aquesta és una mesura eficaç.
PgBouncer va començar a desenvolupar-se més ràpidament.
I ara han aparegut altres projectes. Per exemple, pgagroal, desenvolupat pels desenvolupadors de Red Hat. Persegueixen objectius similars i implementen idees similars, però, per descomptat, amb les seves pròpies especificitats, que estan més a prop dels desenvolupadors pgagroal.
Un altre cas de treball amb la comunitat de postgres és la restauració a un punt en el temps. Aquesta és la recuperació després d'un error, aquesta és la recuperació d'una còpia de seguretat.
Hi ha moltes còpies de seguretat i totes són diferents. Gairebé tots els venedors de Postgres tenen la seva pròpia solució de còpia de seguretat.
Si agafeu tots els sistemes de còpia de seguretat, creeu una matriu de característiques i calculeu en broma el determinant d'aquesta matriu, serà zero. Què vol dir això? Què passa si agafeu un fitxer de còpia de seguretat específic, no es pot muntar a partir de peces de tots els altres. És únic en la seva implementació, és únic en el seu propòsit, és únic en les idees que hi estan incrustades. I tots són específics.
Mentre estàvem treballant en aquest tema, CitusData va llançar el projecte WAL-G. Es tracta d'un sistema de còpia de seguretat que es va fer amb l'atenció de l'entorn del núvol. Ara CitusData ja forma part de Microsoft. I en aquell moment, ens van agradar molt les idees que es van establir en els llançaments inicials de WAL-G. I vam començar a col·laborar en aquest projecte.
Ara hi ha moltes desenes de desenvolupadors en aquest projecte, però els 10 principals col·laboradors de WAL-G inclouen 6 Yandexoids. Hi vam portar moltes idees. I, per descomptat, els vam implementar nosaltres mateixos, els vam provar nosaltres mateixos, els vam implementar a la producció nosaltres mateixos, els fem servir nosaltres mateixos, nosaltres mateixos descobrim on hem de moure'ns a continuació, mentre interactuem amb la gran comunitat WAL-G.
I des del nostre punt de vista, ara aquest sistema de còpia de seguretat, inclòs tenint en compte els nostres esforços, s'ha convertit en òptim per a un entorn de núvol. Aquest és el millor cost de fer una còpia de seguretat de Postgres al núvol.
Què vol dir? Estàvem promovent una idea bastant gran: la còpia de seguretat hauria de ser segura, econòmica d'operar i el més ràpid possible per restaurar-la.
Per què hauria de ser barat d'operar? Quan no hi ha res trencat, no hauríeu de saber que teniu còpies de seguretat. Tot funciona bé, malgasteu la menor quantitat de CPU possible, utilitzeu el mínim possible dels recursos del vostre disc i envieu el menor nombre possible de bytes a la xarxa per no interferir amb la càrrega útil dels vostres valuosos serveis.
I quan tot es trenca, per exemple, l'administrador va deixar caure les dades, alguna cosa va sortir malament i necessiteu tornar al passat amb urgència, us recupereu amb tots els diners, perquè voleu que les vostres dades tornin ràpidament i intactes.
I vam promoure aquesta senzilla idea. I, ens sembla, ho hem aconseguit implementar.
Però això no és tot. Volíem una petita cosa més. Volíem moltes bases de dades diferents. No tots els nostres clients utilitzen Postgres. Algunes persones utilitzen MySQL, MongoDB. A la comunitat, altres desenvolupadors han donat suport a FoundationDB. I aquesta llista s'amplia constantment.
A la comunitat li agrada la idea que la base de dades s'executi en un entorn gestionat al núvol. I els desenvolupadors mantenen les seves bases de dades, de les quals es poden fer còpies de seguretat de manera uniforme juntament amb Postgres amb el nostre sistema de còpia de seguretat.
Què hem après d'aquesta història? El nostre producte, com a divisió de desenvolupament, no són línies de codi, no són declaracions, no són fitxers. El nostre producte no són sol·licituds d'extracció. Aquestes són les idees que transmetem a la comunitat. Aquesta és l'experiència tecnològica i el moviment de la tecnologia cap a un entorn al núvol.
Hi ha una base de dades com Postgres. M'agrada més el nucli de Postgres. Passo molt de temps desenvolupant el nucli de Postgres amb la comunitat.
Però aquí cal dir que Yandex.Cloud té una instal·lació interna de bases de dades gestionades. I va començar fa molt de temps a Yandex.Mail. L'experiència que ara ha donat lloc a Postgres gestionat es va acumular quan el correu volia traslladar-se a Postgres.
El correu té requisits molt similars als del núvol. Necessiteu que pugueu escalar fins a un creixement exponencial inesperat en qualsevol punt de les vostres dades. I el correu ja tenia una càrrega amb uns centenars de milions de bústies d'un gran nombre d'usuaris que constantment fan moltes peticions.
I aquest va ser un repte força seriós per a l'equip que estava desenvolupant Postgres. Aleshores, qualsevol problema que vam trobar es va informar a la comunitat. I aquests problemes van ser corregits i corregits per la comunitat en alguns llocs fins i tot a nivell de suport de pagament per a algunes altres bases de dades i encara millor. És a dir, podeu enviar una carta al pirata informàtic PgSQL i rebre una resposta en 40 minuts. El suport de pagament en algunes bases de dades pot pensar que hi ha més coses prioritàries que el vostre error.
Ara la instal·lació interna de Postgres és uns petabytes de dades. Són uns milions de peticions per segon. Són milers de clústers. És a molt gran escala.
Però hi ha un matís. No viu en unitats de xarxa elegants, sinó en maquinari bastant senzill. I hi ha un entorn de prova específic per a coses noves interessants.
I en un moment determinat a l'entorn de prova vam rebre un missatge que indicava que s'havien violat els invariants interns dels índexs de la base de dades.
Un invariant és una mena de relació que esperem mantenir sempre.
Una situació molt crítica per a nosaltres. Indica que algunes dades s'han perdut. I la pèrdua de dades és una cosa francament catastròfica.
La idea general que seguim a les bases de dades gestionades és que, fins i tot amb esforç, serà difícil perdre dades. Fins i tot si els elimineu deliberadament, encara haureu d'ignorar la seva absència durant un llarg període de temps. La seguretat de les dades és una religió que seguim amb força diligència.
I aquí sorgeix una situació que fa pensar que hi pot haver una situació per a la qual potser no estem preparats. I vam començar a preparar-nos per a aquesta situació.
El primer que vam fer va ser enterrar els troncs d'aquests milers de grups. Hem trobat quins dels clústers es trobaven en discs amb microprogramari problemàtic que perdien actualitzacions de pàgines de dades. S'ha marcat tot el codi de dades de Postgres. I hem marcat aquells missatges que indiquen infraccions d'invariants interns amb un codi dissenyat per detectar la corrupció de dades.
Aquest pegat va ser pràcticament acceptat per la comunitat sense gaire discussió, perquè en cada cas concret era obvi que havia passat alguna cosa dolenta i s'havia d'informar al registre.
Després d'això, vam arribar al punt que tenim un seguiment que escaneja els registres. I en cas de missatges sospitosos, desperta l'oficial de servei i l'oficial de servei el repara.
Però! L'exploració de registres és una operació barata en un clúster i catastròficament cara per a mil clústers.
Vam escriure una extensió anomenada . Crea una vista de la base de dades en la qual podeu seleccionar de manera econòmica i ràpida estadístiques sobre errors passats. I si hem de despertar l'oficial de servei, ho sabrem sense escanejar fitxers gigabytes, sinó extreure uns quants bytes de la taula hash.
Aquesta extensió s'ha adoptat, per exemple, al repositori per . Si el voleu utilitzar, podeu instal·lar-lo vosaltres mateixos. Per descomptat, és de codi obert.
Però això no és tot. Vam començar a utilitzar Amcheck, una extensió creada per la comunitat, per trobar infraccions invariants als índexs.
I vam descobrir que si l'executeu a escala, hi ha errors. Vam començar a arreglar-los. Les nostres correccions han estat acceptades.
Hem descobert que aquesta extensió no pot analitzar els índexs GiST i GIT. Els vam donar suport. Però aquest suport encara s'està discutint per la comunitat, perquè es tracta d'una funcionalitat relativament nova i hi ha molts detalls.
I també hem descobert que quan es comproven índexs de violacions al líder de rèplica, al mestre, tot funciona bé, però a les rèpliques, al seguidor, la recerca de corrupció no és tan efectiva. No es comproven tots els invariants. I un invariant ens va molestar molt. I vam estar un any i mig comunicant-nos amb la comunitat per tal d'habilitar aquesta comprovació de rèpliques.
Vam escriure codi que hauria de seguir tots els protocols possibles. Vam parlar d'aquest pedaç durant força temps amb Peter Gaghan de Crunchy Data. Va haver de modificar lleugerament l'arbre B existent a Postgres per acceptar aquest pedaç. Va ser acceptat. I ara la comprovació dels índexs de les rèpliques també s'ha fet prou eficaç per detectar les infraccions que hem trobat. És a dir, aquestes són les infraccions que poden ser causades per errors en el microprogramari del disc, errors en Postgres, errors en el nucli de Linux i problemes de maquinari. Una llista força extensa de fonts de problemes per als quals ens estàvem preparant.
Però, a més dels índexs, hi ha una part com la pila, és a dir, el lloc on s'emmagatzemen les dades. I no hi ha molts invariants que es puguin comprovar.
Tenim una extensió anomenada Heapcheck. Vam començar a desenvolupar-lo. I paral·lelament, juntament amb nosaltres, l'empresa EnterpriseDB també va començar a escriure un mòdul, que de la mateixa manera van anomenar Heapcheck. Només nosaltres l'hem anomenat PgHeapcheck, i ells només l'anomenaven Heapcheck. El tenen amb funcions semblants, una signatura una mica diferent, però amb les mateixes idees. Els van implementar una mica millor en alguns llocs. I abans ho van publicar en codi obert.
I ara estem desenvolupant la seva expansió, perquè ja no és la seva expansió, sinó l'expansió de la comunitat. I en el futur, això forma part del nucli que es subministrarà a tothom perquè pugui conèixer amb antelació els problemes futurs.
En alguns llocs, fins i tot vam arribar a la conclusió que tenim falsos positius en els nostres sistemes de monitorització. Per exemple, el sistema 1C. Quan s'utilitza una base de dades, Postgres de vegades hi escriu dades que pot llegir, però pg_dump no pot llegir.
Aquesta situació semblava corrupció al nostre sistema de detecció de problemes. L'oficial de servei es va despertar. L'oficial de servei va mirar què passava. Al cap d'un temps, va venir un client i va dir que tenia problemes. L'encarregat va explicar quin era el problema. Però el problema està al nucli de Postgres.
He trobat una discussió sobre aquesta funció. I va escriure que ens vam trobar amb aquesta característica i va ser desagradable, una persona es va despertar a la nit per esbrinar què era.
La comunitat va respondre: "Oh, realment hem de solucionar-ho".
Tinc una simple analogia. Si esteu caminant amb una sabata que té un gra de sorra, llavors, en principi, podeu seguir endavant, sense cap problema. Si veneu botes a milers de persones, anem a fer botes sense sorra. I si un dels usuaris de les teves sabates va a córrer una marató, voldràs fer sabates molt bones i després escalar-les a tots els teus usuaris. I aquests usuaris inesperats sempre es troben a l'entorn del núvol. Sempre hi ha usuaris que exploten el clúster d'alguna manera original. Sempre t'has de preparar per a això.
Què hem après aquí? Hem après una cosa senzilla: el més important és explicar a la comunitat que hi ha un problema. Si la comunitat ha reconegut el problema, sorgeix competència natural per resoldre el problema. Perquè tothom vol resoldre un problema important. Tots els venedors, tots els pirates informàtics entenen que ells mateixos poden trepitjar aquest rastell, així que volen eliminar-los.
Si esteu treballant en un problema, però no us molesta ningú més que vosaltres, però hi treballeu de manera sistemàtica i finalment es considera un problema, la vostra sol·licitud d'extracció definitivament serà acceptada. El vostre pegat serà acceptat, les vostres millores o fins i tot les sol·licituds de millores seran revisades per la comunitat. Al final del dia, fem la base de dades millor els uns per als altres.
Una base de dades interessant és Greenplum. És una base de dades molt paral·lela basada en la base de codi Postgres, amb la qual estic molt familiaritzat.
I Greenplum té una funcionalitat interessant: afegiu taules optimitzades. Aquestes són taules que podeu afegir ràpidament. Poden ser columnars o filades.
Però no hi havia cap agrupació, és a dir, no hi havia cap funcionalitat on es pugui ordenar les dades situades a la taula d'acord amb l'ordre que hi ha en un dels índexs.
Els nois del taxi van venir a mi i em van dir: “Andrey, ja coneixes Postgres. I aquí és gairebé el mateix. Canvia a 20 minuts. Ho prens i ho fas". Vaig pensar que sí, que conec Postgres, canviant durant 20 minuts; he de fer això.
Però no, no van ser 20 minuts, ho vaig escriure durant mesos. A la conferència de PgConf.Russia, em vaig acostar a Heikki Linakangas de Pivotal i vaig preguntar: "Hi ha problemes amb això? Per què no hi ha cap agrupació de taules optimitzada per afegir?" Ell diu: “Tu prens les dades. Ordena, reordena. Només és una feina". Jo: "Oh, sí, només has d'agafar-ho i fer-ho". Ell diu: "Sí, necessitem mans lliures per fer això". Vaig pensar que definitivament havia de fer això.
I uns mesos més tard vaig enviar una sol·licitud d'extracció que implementava aquesta funcionalitat. Pivotal va revisar aquesta sol·licitud d'extracció juntament amb la comunitat. Per descomptat, hi havia errors.
Però el més interessant és que quan es va fusionar aquesta sol·licitud d'extracció, es van trobar errors al mateix Greenplum. Hem descobert que les taules de pila de vegades trenquen la transaccionalitat quan s'agrupen. I això és una cosa que cal arreglar. I ella està al lloc que acabo de tocar. I la meva reacció natural va ser: d'acord, deixeu-me fer això també.
Vaig solucionar aquest error. Va enviar una sol·licitud d'extracció als reparadors. El van matar.
Després d'això, va resultar que aquesta funcionalitat s'havia d'obtenir a la versió de Greenplum per a PostgreSQL 12. És a dir, l'aventura de 20 minuts continua amb noves aventures interessants. Va ser interessant tocar el desenvolupament actual, on la comunitat està tallant les funcions noves i més importants. Està congelat.
Però no va acabar aquí. Després de tot, va resultar que calia escriure documentació per a tot això.
Vaig començar a escriure documentació. Per sort, van venir els documentalistes de Pivotal. L'anglès és la seva llengua materna. Em van ajudar amb la documentació. De fet, ells mateixos van reescriure el que vaig proposar en anglès real.
I aquí, sembla que s'ha acabat l'aventura. I saps què va passar llavors? Els nois del taxi van venir a mi i em van dir: "Encara queden dues aventures, cadascuna de 10 minuts". I què els he de dir? Vaig dir que ara faré un informe a escala, després veurem les vostres aventures, perquè és una feina interessant.
Què hem après d'aquest cas? Com que treballar amb codi obert sempre és treballar amb una persona específica, sempre és treballar amb la comunitat. Perquè en cada etapa vaig treballar amb algun desenvolupador, algun provador, algun pirata informàtic, algun documentalista, algun arquitecte. No vaig treballar amb Greenplum, vaig treballar amb gent del voltant de Greenplum.
Però! Hi ha un altre punt important: només és feina. És a dir, vens, beus cafè, escriu codi. Tot tipus d'invariants simples funcionen. Fes-ho normalment: anirà bé! I és una feina força interessant. Hi ha una sol·licitud per a aquest treball dels clients de Yandex.Cloud, usuaris dels nostres clústers tant dins com fora de Yandex. I crec que augmentarà el nombre de projectes en què participem i també augmentarà la profunditat de la nostra implicació.
Això és tot. Passem a les preguntes.
Sessió de preguntes
Hola! Tenim una altra sessió de preguntes i respostes. I a l'estudi Andrei Borodin. Aquesta és la persona que us acaba de parlar de la contribució de Yandex.Cloud i Yandex al codi obert. El nostre informe ara no tracta totalment del núvol, però al mateix temps ens basem en aquestes tecnologies. Sense el que heu fet a Yandex, no hi hauria servei a Yandex.Cloud, així que personalment us agraeixo. I la primera pregunta de l'emissió: "En què està escrit cadascun dels projectes que heu esmentat?"
El sistema de còpia de seguretat a WAL-G està escrit a Go. Aquest és un dels nous projectes en què hem treballat. Literalment només té 3 anys. I una base de dades sovint tracta de fiabilitat. I això vol dir que les bases de dades són força antigues i que solen estar escrites en C. El projecte Postgres va començar fa uns 30 anys. Aleshores, el C89 va ser l'opció correcta. I Postgres hi està escrit. Les bases de dades més modernes, com ara ClickHouse, solen escriure's en C++. Tot el desenvolupament del sistema es basa en C i C++.
Una pregunta del nostre gerent financer, responsable de les despeses a Cloud: "Per què Cloud gasta diners en donar suport al codi obert?"
Aquí hi ha una resposta senzilla per al gestor financer. Ho fem per millorar els nostres serveis. De quines maneres podem fer-ho millor? Podem fer les coses de manera més eficient, més ràpida i fer que les coses siguin més escalables. Però per a nosaltres, aquesta història tracta principalment de la fiabilitat. Per exemple, en un sistema de còpia de seguretat revisem el 100% dels pedaços que s'hi apliquen. Sabem quin és el codi. I ens sentim més còmodes llançant noves versions a producció. És a dir, en primer lloc, es tracta de confiança, de preparació per al desenvolupament i de fiabilitat
Una altra pregunta: "Els requisits dels usuaris externs que viuen a Yandex.Cloud són diferents dels usuaris interns que viuen al núvol intern?"
El perfil de càrrega és, per descomptat, diferent. Però des del punt de vista del meu departament, tots els casos especials i interessants es creen amb una càrrega no estàndard. Els desenvolupadors amb imaginació, els desenvolupadors que fan l'inesperat, són tan propensos a trobar-se tant internament com externament. En aquest sentit, tots som aproximadament iguals. I, probablement, l'única característica important dins del funcionament de les bases de dades Yandex serà que dins de Yandex tenim un ensenyament. En algun moment, alguna zona de disponibilitat passa completament a l'ombra i tots els serveis Yandex han de continuar funcionant d'alguna manera malgrat això. Aquesta és una petita diferència. Però crea una gran quantitat de desenvolupament de recerca a la interfície de la base de dades i la pila de xarxa. En cas contrari, les instal·lacions externes i internes generen les mateixes peticions de característiques i peticions similars per millorar la fiabilitat i el rendiment.
Següent pregunta: "Com et sents personalment sobre el fet que gran part del que fas sigui utilitzat per altres núvols?" No n'anomenarem cap concret, però molts projectes que es van fer a Yandex.Cloud s'utilitzen en núvols d'altres persones.
Això mola. En primer lloc, és un senyal que hem fet alguna cosa bé. I esgarrapa l'ego. I estem més segurs que hem pres la decisió correcta. D'altra banda, aquesta és l'esperança que en el futur això ens aporti noves idees, noves peticions d'usuaris de tercers. La majoria de problemes a GitHub els creen administradors de sistemes individuals, DBA individuals, arquitectes individuals, enginyers individuals, però de vegades vénen persones amb experiència sistemàtica i diuen que en el 30% de determinats casos tenim aquest problema i pensem com resoldre'l. Això és el que més esperem. Esperem compartir experiències amb altres plataformes al núvol.
Vas parlar molt de la marató. Sé que vas córrer una marató a Moscou. Com a resultat? Va superar els nois de PostgreSQL?
No, Oleg Bartunov corre molt ràpid. Va acabar una hora per davant meu. En general, estic content amb el lluny que he arribat. Per a mi, només acabar va ser un èxit. En general, és sorprenent que hi hagi tants corredors a la comunitat de postgres. Em sembla que hi ha algun tipus de relació entre els esports aeròbics i el desig de programació de sistemes.
Vols dir que no hi ha corredors a ClickHouse?
Sé del cert que hi són. ClickHouse també és una base de dades. Per cert, l'Oleg m'escriu ara: "Anem a córrer després de l'informe?" Aquesta és una gran idea.
Una altra pregunta de l'emissió de Nikita: "Per què vas arreglar tu mateix l'error a Greenplum i no el vas donar als joves?" És cert que no està molt clar quin és l'error i en quin servei, però probablement es refereix al que heu parlat.
Sí, en principi, podria haver estat donat a algú. Era només el codi que acabo de canviar. I era natural continuar fent-ho de seguida. En principi, la idea de compartir coneixements amb l'equip és una bona idea. Definitivament compartirem les tasques de Greenplum entre tots els membres de la nostra divisió.
Com que parlem de júniors, aquí teniu una pregunta. La persona va decidir crear el primer commit a Postgres. Què ha de fer per fer el primer compromís?
Aquesta és una pregunta interessant: "Per on començar?" Normalment és bastant difícil començar amb alguna cosa al nucli. A Postgres, per exemple, hi ha una llista de tasques pendents. Però, de fet, aquest és un full del que van intentar fer, però no ho van aconseguir. Són coses complexes. I normalment es poden trobar algunes utilitats a l'ecosistema, algunes extensions que es poden millorar, que criden menys l'atenció dels desenvolupadors del nucli. I, en conseqüència, hi ha més punts de creixement allà. Al programa Google Summer of code, cada any la comunitat de postgres proposa molts temes diferents que es podrien tractar. Aquest any hem tingut, crec, tres alumnes. Fins i tot un va escriure a WAL-G sobre temes importants per a Yandex. A Greenplum, tot és més senzill que a la comunitat Postgres, perquè els pirates informàtics de Greenplum tracten molt bé les sol·licituds d'extracció i comencen a revisar immediatament. Enviar un pegat a Postgres és qüestió de mesos, però Greenplum vindrà d'aquí un dia a veure què heu fet. Una altra cosa és que Greenplum necessita resoldre els problemes actuals. Greenplum no s'utilitza àmpliament, així que trobar el vostre problema és bastant difícil. I primer de tot, hem de resoldre problemes, és clar.
Font: www.habr.com