Revisarase a contribución de Yandex ás seguintes bases de datos.
- clickhouse
- Odisea
- Recuperación a un punto no tempo (WAL-G)
- PostgreSQL (incluíndo erros de rexistro, Amcheck, Heapcheck)
- Ameixeira verde
Vídeo:
Ola mundo! O meu nome é Andrey Borodin. E o que fago en Yandex.Cloud é desenvolver bases de datos relacionais abertas en interese dos clientes Yandex.Cloud e Yandex.Cloud.
Nesta charla, falaremos dos retos aos que se enfrontan as bases de datos abertas a escala. Por que é importante? Porque pequenos, pequenos problemas que, como os mosquitos, se converten logo en elefantes. Eles fanse grandes cando tes moitos grupos.
Pero iso non é o principal. Pasan cousas incribles. Cousas que pasan nun de cada millón de casos. E nun ambiente de nube, tes que estar preparado para iso, porque as cousas incribles vólvense moi probables cando algo existe a escala.
Pero! Cal é a vantaxe das bases de datos abertas? O caso é que tes unha oportunidade teórica para tratar calquera problema. Tes o código fonte, tes coñecementos de programación. Combinámolo e funciona.
Que enfoques hai para traballar no software de código aberto?
- O enfoque máis sinxelo é usar software. Se usa protocolos, se usa estándares, se usa formatos, se escribe consultas en software de código aberto, entón xa o admite.
- Estás facendo máis grande o seu ecosistema. Aumenta a probabilidade de detección precoz dun erro. Aumenta a fiabilidade deste sistema. Aumentas a dispoñibilidade de desenvolvedores no mercado. Vostede mellora este software. Xa es un colaborador se acabas de poñerte estilo e retocaches algo alí.
- Outro enfoque comprensible é o patrocinio de software de código aberto. Por exemplo, o coñecido programa Google Summer of Code, cando Google paga un gran número de estudantes de todo o mundo diñeiro comprensible para que desenvolvan proxectos de software aberto que cumpran determinados requisitos de licenza.
- Este é un enfoque moi interesante porque permite que o software evolucione sen afastar o foco da comunidade. Google, como xigante tecnolóxico, non di que queremos esta función, queremos corrixir este erro e hai que buscar alí. Google di: "Fai o que fas. Sigue traballando como estiveches e todo estará ben".
- O seguinte enfoque para participar en código aberto é a participación. Cando tes un problema no software de código aberto e hai desenvolvedores, os teus desenvolvedores comezan a resolver os problemas. Comezan a facer a túa infraestrutura máis eficiente, os teus programas máis rápidos e fiables.
Un dos proxectos Yandex máis famosos no campo do software de código aberto é ClickHouse. Esta é unha base de datos que nace como resposta aos retos aos que se enfronta Yandex.Metrica.
E como base de datos, foi feita en código aberto para crear un ecosistema e desenvolvelo xunto con outros desenvolvedores (non só dentro de Yandex). E agora este é un gran proxecto no que están implicadas moitas empresas diferentes.
En Yandex.Cloud, creamos ClickHouse encima de Yandex Object Storage, é dicir, encima do almacenamento na nube.
Por que é importante isto na nube? Porque calquera base de datos funciona neste triángulo, nesta pirámide, nesta xerarquía de tipos de memoria. Tes rexistros rápidos pero pequenos e SSD, discos duros e algúns outros dispositivos de bloque baratos, grandes pero lentos. E se es eficiente na parte superior da pirámide, entón tes unha base de datos rápida. se es eficiente na parte inferior desta pirámide, entón tes unha base de datos escalada. E neste sentido, engadir outra capa desde abaixo é un enfoque lóxico para aumentar a escalabilidade da base de datos.
Como se podería facer? Este é un punto importante neste informe.
- Poderíamos implementar ClickHouse sobre MDS. MDS é unha interface interna de almacenamento na nube de Yandex. É máis complexo que o protocolo S3 común, pero é máis axeitado para un dispositivo de bloque. É mellor para gravar datos. Require máis programación. Os programadores programarán, incluso é bo, é interesante.
- S3 é un enfoque máis común que simplifica a interface ao custo dunha menor adaptación a certos tipos de cargas de traballo.
Por suposto, querendo proporcionar funcionalidade a todo o ecosistema de ClickHouse e facer a tarefa que se precisa dentro de Yandex.Cloud, decidimos asegurarnos de que toda a comunidade de ClickHouse se beneficiase diso. Implementamos ClickHouse sobre S3, non ClickHouse sobre MDS. E isto é moito traballo.
Referencias:
"Capa de abstracción do sistema de ficheiros"
"Integración de AWS SDK S3"
"Implementación base da interafce IDisk para S3"
"Integración de motores de almacenamento de rexistros coa interface IDisk"
"Compatible con motor de rexistro para S3 e SeekableReadBuffer"
"Soporte de Storage Stripe Log S3"
"Soporte inicial de Storage MergeTree para S3"
"Soporte completo de MergeTree para S3"
"Soporta ReplicatedMergeTree sobre S3"
"Engadir credenciais predeterminadas e cabeceiras personalizadas para o almacenamento s3"
"S3 con configuración de proxy dinámica"
"S3 con resolución de proxy"
Esta é unha lista de solicitudes de extracción para implementar un sistema de ficheiros virtual en ClickHouse. Este é un gran número de solicitudes de extracción.
Referencias:
"Implementación óptima de enlaces duros de DiskS3"
"Cliente HTTP S3 - Evite copiar o fluxo de resposta na memoria"
"Evita copiar todo o fluxo de respostas na memoria en HTTP S3
clienta"
"Capacidade para marcar na caché e indexar ficheiros para o disco S3"
"Mover pezas de DiskLocal a DiskS3 en paralelo"
Pero o traballo non rematou aí. Despois de facer a función, foi necesario traballar máis para optimizar esta funcionalidade.
Referencias:
"Engadir eventos SelectedRows e SelectedBytes"
"Engadir eventos de perfilado da solicitude S3 a system.events"
"Engadir QueryTimeMicrosegundos, SelectQueryTimeMicrosegundos e InsertQueryTimeMicrosegundos"
E despois foi necesario facelo diagnosticable, configurar a vixilancia e facela manexable.
E todo isto fíxose para que toda a comunidade, todo o ecosistema ClickHouse, recibise o resultado deste traballo.
Pasemos ás bases de datos transaccionais, ás bases de datos OLTP, que están máis preto de min persoalmente.
Esta é a división de desenvolvemento de DBMS de código aberto. Estes mozos están facendo maxia na rúa para mellorar as bases de datos abertas transaccionais.
Un dos proxectos, usando un exemplo do que podemos falar de como e que facemos, é o Connection Pooler en Postgres.
Postgres é unha base de datos de procesos. Isto significa que a base de datos debería ter o menor número posible de conexións de rede que xestionen as transaccións.
Por outra banda, nun ambiente de nube, unha situación típica é cando mil conexións chegan a un clúster á vez. E a tarefa do agrupador de conexións é empaquetar mil conexións nun pequeno número de conexións de servidor.
Podemos dicir que o agrupador de conexións é o operador de telefonía que reordena os bytes para que cheguen á base de datos de forma eficiente.
Desafortunadamente, non hai unha boa palabra rusa para a agrupación de conexións. Ás veces chámase conexións multiplexadoras. Se sabes como chamar ao agrupador de conexións, asegúrate de dicirme que estarei moi feliz de falar o idioma técnico ruso correcto.
Investigamos agrupadores de conexións adecuados para un clúster de Postgres xestionado. E PgBouncer foi a mellor opción para nós. Pero atopamos unha serie de problemas con PgBouncer. Hai moitos anos, Volodya Borodin informou de que usamos PgBouncer, gústanos todo, pero hai matices, hai algo no que traballar.
E traballamos. Resolvemos os problemas que atopamos, parcheamos Bouncer e tentamos enviar solicitudes de extracción. Pero o fío único fundamental era difícil de traballar.
Tivemos que recoller cascadas de Bouncers remendados. Cando temos moitos Bouncers dun só fío, as conexións da capa superior transfírense á capa interna de Bouncers. Este é un sistema mal xestionado que é difícil de construír e escalar cara atrás e cara atrás.
Chegamos á conclusión de que creamos a nosa propia agrupación de conexións, que se chama Odisea. Escribimos dende cero.
En 2019, na conferencia PgCon, presentei esta agrupación á comunidade de desenvolvedores. Agora temos algo menos de 2 estrelas en GitHub, é dicir, o proxecto está vivo, o proxecto é popular.
E se creas un clúster de Postgres en Yandex.Cloud, será un clúster con Odyssey incorporado, que se reconfigura ao escalar o clúster cara atrás ou cara atrás.
Que aprendemos deste proxecto? Poñer en marcha un proxecto competitivo sempre é un paso agresivo, é unha medida extrema cando dicimos que hai problemas que non se solucionan con suficiente rapidez, non se están solucionando nos intervalos de tempo que nos convén. Pero esta é unha medida eficaz.
PgBouncer comezou a desenvolverse máis rápido.
E agora apareceron outros proxectos. Por exemplo, pgagroal, que é desenvolvido polos desenvolvedores de Red Hat. Perseguen obxectivos similares e implementan ideas similares, pero, por suposto, coas súas propias especificidades, que están máis preto dos desenvolvedores pgagroal.
Outro caso de traballo coa comunidade de postgres é a restauración a un punto no tempo. Esta é a recuperación despois dun fallo, esta é a recuperación dunha copia de seguridade.
Hai moitas copias de seguridade e todas son diferentes. Case todos os provedores de Postgres teñen a súa propia solución de copia de seguridade.
Se tomas todos os sistemas de copia de seguridade, creas unha matriz de funcións e calculas en broma o determinante nesta matriz, será cero. Que significa isto? E se tomas un ficheiro de copia de seguridade específico, entón non se pode montar a partir de anacos de todos os demais. É único na súa implementación, é único no seu propósito, é único nas ideas que están incorporadas nel. E todos son específicos.
Mentres traballabamos neste tema, CitusData lanzou o proxecto WAL-G. Este é un sistema de copia de seguridade que se fixo coa atención no contorno da nube. Agora CitusData xa forma parte de Microsoft. E nese momento, gustáronnos moito as ideas que se expuxeron nos lanzamentos iniciais de WAL-G. E comezamos a contribuír a este proxecto.
Agora hai moitas decenas de desenvolvedores neste proxecto, pero os 10 principais colaboradores de WAL-G inclúen 6 Yandexoids. Alí trouxemos moitas das nosas ideas. E, por suposto, implementámolos nós mesmos, probámolos nós mesmos, puxémolos en produción nós mesmos, usámolos nós mesmos, nós mesmos descubrimos onde movernos a continuación, mentres interactuamos coa gran comunidade WAL-G.
E desde o noso punto de vista, agora este sistema de copia de seguridade, incluíndo os nosos esforzos, converteuse en óptimo para un ambiente de nube. Este é o mellor custo de facer unha copia de seguranza de Postgres na nube.
Qué significa? Fomentabamos unha idea bastante grande: a copia de seguridade debería ser segura, barata de operar e o máis rápido posible para restaurar.
Por que debería ser barato operar? Cando nada está roto, non debes saber que tes copias de seguridade. Todo funciona ben, desperdicias a menor CPU posible, usas o mínimo posible dos teus recursos de disco e envías o menor número posible de bytes á rede para non interferir coa carga útil dos teus valiosos servizos.
E cando todo se rompe, por exemplo, o administrador deixou caer os datos, algo saíu mal e necesitas con urxencia volver ao pasado, recuperas todo o diñeiro, porque queres que os teus datos volvan rapidamente e intactos.
E promovemos esta sinxela idea. E, parécenos, conseguimos poñelo en marcha.
Pero iso non é todo. Queriamos unha pequena cousa máis. Queriamos moitas bases de datos diferentes. Non todos os nosos clientes usan Postgres. Algunhas persoas usan MySQL, MongoDB. Na comunidade, outros desenvolvedores apoiaron FoundationDB. E esta lista está en constante expansión.
Á comunidade gústalle a idea de que a base de datos se execute nun ambiente xestionado na nube. E os desenvolvedores manteñen as súas bases de datos, das que se pode facer unha copia de seguranza uniforme xunto con Postgres co noso sistema de copia de seguridade.
Que aprendemos desta historia? O noso produto, como división de desenvolvemento, non son liñas de código, non son declaracións, non son ficheiros. O noso produto non son solicitudes de extracción. Estas son as ideas que transmitimos á comunidade. Esta é a experiencia tecnolóxica e o movemento da tecnoloxía cara a un ambiente na nube.
Existe unha base de datos como Postgres. O núcleo de Postgres me gusta máis. Levo moito tempo desenvolvendo o núcleo de Postgres coa comunidade.
Pero aquí hai que dicir que Yandex.Cloud ten unha instalación interna de bases de datos xestionadas. E comezou hai moito tempo en Yandex.Mail. A experiencia que levou agora a xestionar Postgres acumulouse cando o correo quería pasar a Postgres.
O correo ten requisitos moi similares aos da nube. Precísase que poida escalar a un crecemento exponencial inesperado en calquera punto dos seus datos. E o correo xa tiña unha carga con algúns centos de millóns de caixas de correo dun gran número de usuarios que constantemente fan moitas solicitudes.
E este foi un reto bastante serio para o equipo que estaba a desenvolver Postgres. Daquela, os problemas que atopamos foron comunicados á comunidade. E estes problemas foron corrixidos, e corrixidos pola comunidade nalgúns lugares mesmo a nivel de soporte pago para algunhas outras bases de datos e aínda mellor. É dicir, pode enviar unha carta ao hacker PgSQL e recibir unha resposta en 40 minutos. O apoio de pago nalgunhas bases de datos pode pensar que hai máis cousas prioritarias que o teu erro.
Agora a instalación interna de Postgres son uns petabytes de datos. Son uns millóns de solicitudes por segundo. Son miles de clusters. É a moi grande escala.
Pero hai un matiz. Non vive en unidades de rede elegantes, senón en hardware bastante sinxelo. E hai un ambiente de proba específicamente para cousas novas interesantes.
E nun momento determinado no ambiente de proba recibimos unha mensaxe que indicaba que se violaban os invariantes internos dos índices da base de datos.
Un invariante é algún tipo de relación que esperamos manter sempre.
Unha situación moi crítica para nós. Indica que se puido perder algúns datos. E a perda de datos é algo francamente catastrófico.
A idea xeral que seguimos nas bases de datos xestionadas é que aínda con esforzo, será difícil perder datos. Aínda que os elimines deliberadamente, aínda terás que ignorar a súa ausencia durante un longo período de tempo. A seguridade dos datos é unha relixión que seguimos con bastante dilixencia.
E aquí xorde unha situación que fai pensar que pode haber unha situación para a que quizais non esteamos preparados. E comezamos a prepararnos para esta situación.
O primeiro que fixemos foi enterrar os troncos destes miles de racimos. Descubrimos cales dos clústeres estaban localizados en discos con firmware problemático que estaban perdendo actualizacións da páxina de datos. Marcado todo o código de datos de Postgres. E marcamos aquelas mensaxes que indican violacións de invariantes internos cun código que está deseñado para detectar a corrupción de datos.
Este parche foi practicamente aceptado pola comunidade sen moita discusión, porque en cada caso concreto era obvio que algo malo acontecera e había que informar ao rexistro.
Despois disto, chegamos ao punto de que temos un seguimento que analiza os rexistros. E en caso de mensaxes sospeitosas, esperta o oficial de servizo, e o oficial de servizo repara.
Pero! A exploración dos rexistros é unha operación barata nun clúster e catastróficamente cara para mil clústeres.
Escribimos unha extensión chamada . Crea unha vista da base de datos na que pode seleccionar de forma rápida e barata estatísticas sobre erros pasados. E se necesitamos espertar o oficial de servizo, descubrirémolo sen escanear ficheiros de gigabytes, pero extraendo algúns bytes da táboa hash.
Esta extensión foi adoptada, por exemplo, no repositorio para . Se queres usalo, podes instalalo ti mesmo. Por suposto, é de código aberto.
Pero iso non é todo. Comezamos a usar Amcheck, unha extensión creada pola comunidade, para atopar infraccións invariables nos índices.
E descubrimos que se o operas a escala, hai erros. Comezamos a arranxalos. As nosas correccións foron aceptadas.
Descubrimos que esta extensión non pode analizar os índices GiST e GIT. Fixémoslles apoio. Pero este apoio aínda está a ser discutido pola comunidade, porque esta é unha funcionalidade relativamente nova e hai moitos detalles alí.
E tamén descubrimos que ao comprobar os índices de violacións no líder de replicación, no mestre, todo funciona ben, pero nas réplicas, no seguidor, a busca de corrupción non é tan eficaz. Non todos os invariantes están marcados. E un invariante molestounos moito. E levamos ano e medio comunicándonos coa comunidade para habilitar esta comprobación de réplicas.
Escribimos código que debería seguir todos os protocolos de... Comentamos este parche durante bastante tempo con Peter Gaghan de Crunchy Data. Tivo que modificar lixeiramente a árbore B existente en Postgres para aceptar este parche. Foi aceptado. E agora a comprobación de índices nas réplicas tamén se fixo o suficientemente efectiva como para detectar as infraccións que atopamos. É dicir, estas son as violacións que poden ser causadas por erros no firmware do disco, erros en Postgres, erros no núcleo de Linux e problemas de hardware. Unha lista bastante extensa de fontes de problemas para as que nos estabamos preparando.
Pero ademais dos índices, hai unha parte como o montón, é dicir, o lugar onde se almacenan os datos. E non hai moitos invariantes que se poidan comprobar.
Temos unha extensión chamada Heapcheck. Comezamos a desenvolvelo. E paralelamente, xunto a nós, a empresa EnterpriseDB tamén comezou a escribir un módulo, ao que chamaron do mesmo xeito Heapcheck. Só nós o chamamos PgHeapcheck, e eles só o chamaron Heapcheck. Téñeno con funcións similares, unha sinatura un pouco diferente, pero coas mesmas ideas. Implementáronos un pouco mellor nalgúns lugares. E xa o publicaron en código aberto antes.
E agora estamos a desenvolver a súa expansión, porque xa non é a súa expansión, senón a expansión da comunidade. E no futuro, esta forma parte do núcleo que se proporcionará a todos para que poidan coñecer con antelación os problemas futuros.
Nalgúns lugares, ata chegamos á conclusión de que temos falsos positivos nos nosos sistemas de vixilancia. Por exemplo, o sistema 1C. Cando se usa unha base de datos, Postgres ás veces escribe datos nela que pode ler, pero pg_dump non pode ler.
Esta situación parecía corrupción para o noso sistema de detección de problemas. O oficial de servizo foi espertado. O oficial de servizo mirou o que estaba a pasar. Despois dun tempo, veu un cliente e dixo que tiña problemas. O encargado explicou cal era o problema. Pero o problema está no núcleo de Postgres.
Atopei unha discusión sobre esta función. E escribiu que atopamos esta característica e que foi desagradable, unha persoa espertou pola noite para descubrir o que era.
A comunidade respondeu: "Oh, realmente necesitamos solucionalo".
Teño unha analoxía sinxela. Se estás camiñando cun zapato que ten un gran de area, entón, en principio, podes seguir adiante, sen problema. Se vendes botas a miles de persoas, fagamos botas sen area. E se un dos usuarios dos teus zapatos vai correr un maratón, entón queres facer uns zapatos moi bos e despois escalalos a todos os teus usuarios. E os usuarios tan inesperados están sempre no contorno da nube. Sempre hai usuarios que explotan o clúster dalgún xeito orixinal. Sempre debes prepararte para iso.
Que aprendemos aquí? Aprendemos unha cousa sinxela: o máis importante é explicarlle á comunidade que hai un problema. Se a comunidade recoñeceu o problema, entón xorde a competencia natural para resolver o problema. Porque todos queren resolver un problema importante. Todos os vendedores, todos os hackers entenden que eles mesmos poden pisar este rake, polo que queren eliminalos.
Se estás a traballar nun problema, pero non molesta a ninguén máis que a ti, pero traballas nel sistematicamente e, en última instancia, considérase un problema, entón a túa solicitude de extracción será definitivamente aceptada. O teu parche será aceptado, as túas melloras ou mesmo as solicitudes de melloras serán revisadas pola comunidade. Ao final do día, melloramos a base de datos entre si.
Unha base de datos interesante é Greenplum. É unha base de datos moi paralela baseada na base de código Postgres, coa que estou moi familiarizado.
E Greenplum ten unha funcionalidade interesante: engadir táboas optimizadas. Estas son táboas ás que pode engadir rapidamente. Poden ser columnas ou fileiras.
Pero non había agrupación, é dicir, non había ningunha funcionalidade onde poder organizar os datos situados na táboa de acordo coa orde que está nun dos índices.
Os mozos do taxi achegáronseme e dixéronme: “Andrey, xa coñeces a Postgres. E aquí é case o mesmo. Cambia a 20 minutos. Tómao e faino". Pensei que si, coñezo a Postgres, cambiando durante 20 minutos; teño que facelo.
Pero non, non foron 20 minutos, escribíno durante meses. Na conferencia PgConf.Russia, achegueime a Heikki Linakangas de Pivotal e preguntei: "¿Hai algún problema con isto? Por que non hai agrupación de táboas optimizada para anexar?" El di: "Ti tomas os datos. Ordenas, reorganizas. É só un traballo". Eu: "Oh, si, só tes que tomalo e facelo". El di: "Si, necesitamos mans libres para facelo". Pensei que definitivamente teño que facer isto.
E uns meses despois enviei unha solicitude de extracción que implementaba esta funcionalidade. Esta solicitude de extracción foi revisada por Pivotal xunto coa comunidade. Por suposto, houbo erros.
Pero o máis interesante é que cando se fusionou esta solicitude de extracción, atopáronse erros no propio Greenplum. Descubrimos que as táboas de montón ás veces rompen a transacción cando se agrupan. E isto é algo que hai que arranxar. E está no lugar que acabo de tocar. E a miña reacción natural foi: vale, déixame facer isto tamén.
Reparei este erro. Enviou unha solicitude de extracción aos reparadores. Foi asasinado.
Despois do cal resultou que esta funcionalidade cómpre obter na versión de Greenplum para PostgreSQL 12. É dicir, a aventura de 20 minutos continúa con novas e interesantes aventuras. Foi interesante tocar o desenvolvemento actual, onde a comunidade está recortando características novas e máis importantes. Está conxelado.
Pero non rematou aí. Despois de todo, resultou que necesitabamos escribir documentación para todo isto.
Comecei a escribir documentación. Por sorte, acudiron os documentalistas de Pivotal. O inglés é a súa lingua nativa. Axudáronme coa documentación. De feito, eles mesmos volveron escribir o que eu propuxen ao inglés real.
E aquí, ao parecer, rematou a aventura. E sabes que pasou entón? Os mozos do taxi achegáronse a min e dixéronme: "Aínda quedan dúas aventuras, cada unha de 10 minutos". E que lles debo dicir? Dixen que agora darei un informe a escala, logo veremos as vosas aventuras, porque este é un traballo interesante.
Que aprendemos deste caso? Porque traballar con código aberto sempre é traballar cunha persoa específica, sempre é traballar coa comunidade. Porque en cada etapa traballei con algún programador, algún probador, algún hacker, algún documentalista, algún arquitecto. Eu non traballei con Greenplum, traballei con xente arredor de Greenplum.
Pero! Hai outro punto importante: é só traballo. É dicir, ti ven, bebes café, escribes código. Todo tipo de invariantes simples funcionan. Faino normalmente: estará ben! E é un traballo bastante interesante. Hai unha solicitude para este traballo dos clientes de Yandex.Cloud, usuarios dos nosos clústeres tanto dentro como fóra de Yandex. E creo que aumentará o número de proxectos nos que participamos e tamén aumentará o calado da nosa implicación.
Iso é todo. Pasemos ás preguntas.
Sesión de preguntas
Ola! Temos outra sesión de preguntas e respostas. E no estudo Andrei Borodin. Esta é a persoa que che acaba de falar da contribución de Yandex.Cloud e Yandex ao código aberto. O noso informe agora non trata enteiramente sobre a nube, pero ao mesmo tempo baseámonos nesas tecnoloxías. Sen o que fixeches dentro de Yandex, non habería servizo en Yandex.Cloud, así que grazas persoalmente. E a primeira pregunta da emisión: "En que está escrito cada un dos proxectos que mencionaches?"
O sistema de copia de seguridade en WAL-G está escrito en Go. Este é un dos proxectos máis novos nos que traballamos. Ten literalmente só 3 anos. E unha base de datos adoita tratarse de fiabilidade. E isto significa que as bases de datos son bastante antigas e adoitan escribirse en C. O proxecto Postgres comezou hai uns 30 anos. Entón o C89 foi a elección correcta. E Postgres está escrito nel. As bases de datos máis modernas como ClickHouse adoitan escribirse en C++. Todo o desenvolvemento do sistema baséase en C e C++.
Unha pregunta do noso xestor financeiro, que é responsable dos gastos en Cloud: "Por que Cloud gasta diñeiro en apoiar o código aberto?"
Aquí hai unha resposta sinxela para o xestor financeiro. Facemos isto para mellorar os nosos servizos. De que xeitos podemos facelo mellor? Podemos facer as cousas de forma máis eficiente, máis rápida e facer as cousas máis escalables. Pero para nós, esta historia trata sobre todo de fiabilidade. Por exemplo, nun sistema de copia de seguridade revisamos o 100% dos parches que se lle aplican. Sabemos cal é o código. E estamos máis cómodos ao lanzar novas versións á produción. É dicir, en primeiro lugar, trátase de confianza, de preparación para o desenvolvemento e de fiabilidade
Outra pregunta: "Os requisitos dos usuarios externos que viven en Yandex.Cloud son diferentes dos usuarios internos que viven na nube interna?"
O perfil de carga é, por suposto, diferente. Pero desde o punto de vista do meu departamento, todos os casos especiais e interesantes créanse nunha carga non estándar. Os desenvolvedores con imaxinación, os desenvolvedores que fan o inesperado, teñen tanta probabilidade de atoparse tanto internamente como externamente. Neste sentido, todos somos aproximadamente iguais. E, probablemente, a única característica importante dentro do funcionamento das bases de datos de Yandex será que dentro de Yandex temos unha ensinanza. Nalgún momento, algunha zona de dispoñibilidade queda completamente en sombra e todos os servizos de Yandex deben seguir funcionando a pesar diso. Esta é unha pequena diferenza. Pero crea moito desenvolvemento de investigación na interface da base de datos e da pila de rede. En caso contrario, as instalacións externas e internas xeran as mesmas solicitudes de funcións e solicitudes similares para mellorar a fiabilidade e o rendemento.
Próxima pregunta: "Como te pareces persoalmente o feito de que gran parte do que fas sexa utilizado por outras nubes?" Non imos nomear uns específicos, pero moitos proxectos que se fixeron en Yandex.Cloud utilízanse nas nubes doutras persoas.
Isto é xenial. En primeiro lugar, é un sinal de que fixemos algo ben. E rasca o ego. E estamos máis seguros de que tomamos a decisión correcta. Por outra banda, esta é a esperanza de que no futuro isto nos traia novas ideas, novas solicitudes de usuarios alleos. A maioría dos problemas en GitHub son creados por administradores de sistemas individuais, DBA individuais, arquitectos individuais, enxeñeiros individuais, pero ás veces veñen persoas con experiencia sistemática que din que no 30% de certos casos temos este problema e pensemos como solucionalo. Isto é o que máis esperamos. Agardamos compartir experiencias con outras plataformas na nube.
Falaches moito do maratón. Sei que correches un maratón en Moscova. Como resultado? Superou aos mozos de PostgreSQL?
Non, Oleg Bartunov corre moi rápido. Rematou unha hora por diante de min. En xeral, estou feliz co lonxe que cheguei. Para min, só rematar foi un logro. En xeral, é sorprendente que haxa tantos corredores na comunidade de postgres. Paréceme que hai algún tipo de relación entre os deportes aeróbicos e o desexo de programar sistemas.
Estás a dicir que non hai corredores en ClickHouse?
Sei con certeza que están alí. ClickHouse tamén é unha base de datos. Por certo, agora Oleg está a escribirme: "Imos a correr despois do informe?" Esta é unha gran idea.
Outra pregunta da emisión de Nikita: "Por que solucionaste ti mesmo o erro en Greenplum e non llo deches aos mozos?" É certo, non está moi claro cal é o erro e en que servizo, pero probablemente significa o que falaches.
Si, en principio, podería terlle dado a alguén. Foi só o código que acabo de cambiar. E era natural seguir facéndoo de inmediato. En principio, a idea de compartir coñecementos co equipo é unha boa idea. Definitivamente compartiremos tarefas de Greenplum entre todos os membros da nosa división.
Xa que falamos de xuvenís, aquí tedes unha pregunta. A persoa decidiu crear o primeiro commit en Postgres. Que ten que facer para facer o primeiro compromiso?
Esta é unha pregunta interesante: "Por onde comezar?" Normalmente é bastante difícil comezar con algo no núcleo. En Postgres, por exemplo, hai unha lista de tarefas. Pero, de feito, esta é unha folla do que tentaron facer, pero non o conseguiron. Son cousas complexas. E normalmente podes atopar algunhas utilidades no ecosistema, algunhas extensións que se poden mellorar, que chaman menos a atención dos desenvolvedores do núcleo. E, en consecuencia, hai máis puntos de crecemento alí. No programa Google Summer of code, cada ano a comunidade de postgres presenta moitos temas diferentes que poderían ser abordados. Este ano tivemos, creo, tres alumnos. Un mesmo escribiu en WAL-G sobre temas importantes para Yandex. En Greenplum, todo é máis sinxelo que na comunidade Postgres, porque os hackers de Greenplum tratan moi ben as solicitudes de extracción e comezan a revisar de inmediato. Enviar un parche a Postgres é cuestión de meses, pero Greenplum chegará nun día e verá o que fixeches. Outra cousa é que Greenplum necesite resolver os problemas actuais. Greenplum non é moi utilizado, polo que atopar o teu problema é bastante difícil. E antes de nada, hai que resolver problemas, claro.
Fonte: www.habr.com