A contribuição do Yandex para os seguintes bancos de dados será revisada.
- clickhouse
- Odyssey
- Recuperação até um ponto no tempo (WAL-G)
- PostgreSQL (incluindo logerrors, Amcheck, heapcheck)
- Ameixa verde
Vídeo:
Olá Mundo! Meu nome é Andrei Borodin. E o que faço na Yandex.Cloud é desenvolver bancos de dados relacionais abertos no interesse dos clientes Yandex.Cloud e Yandex.Cloud.
Nesta palestra, falaremos sobre os desafios enfrentados pelos bancos de dados abertos em grande escala. Por que isso é importante? Porque pequenos, pequenos problemas que, como os mosquitos, se transformam em elefantes. Eles ficam grandes quando você tem muitos clusters.
Mas isso não é o principal. Coisas incríveis acontecem. Coisas que acontecem em um em um milhão de casos. E em um ambiente de nuvem, você precisa estar preparado para isso, porque coisas incríveis se tornam altamente prováveis quando algo existe em grande escala.
Mas! Qual é a vantagem dos bancos de dados abertos? O fato é que você tem uma oportunidade teórica para lidar com qualquer problema. Você tem o código-fonte, você tem conhecimento de programação. Nós combinamos e funciona.
Que abordagens existem para trabalhar com software de código aberto?
- A abordagem mais direta é usar software. Se você usa protocolos, se usa padrões, se usa formatos, se escreve consultas em software de código aberto, então você já oferece suporte.
- Você está tornando seu ecossistema maior. Você aumenta a probabilidade de detecção precoce de um bug. Você aumenta a confiabilidade deste sistema. Você aumenta a disponibilidade de desenvolvedores no mercado. Você melhora este software. Você já é um contribuidor se acabou de adquirir estilo e mexeu em alguma coisa lá.
- Outra abordagem compreensível é patrocinar software de código aberto. Por exemplo, o conhecido programa Google Summer of Code, quando o Google paga a um grande número de estudantes de todo o mundo um dinheiro compreensível para que desenvolvam projetos de software aberto que atendam a determinados requisitos de licenciamento.
- Esta é uma abordagem muito interessante porque permite que o software evolua sem desviar o foco da comunidade. O Google, como gigante da tecnologia, não diz que queremos esse recurso, queremos consertar esse bug e é aqui que precisamos nos aprofundar. O Google diz: “Faça o que você faz. Continue trabalhando do jeito que você está trabalhando e tudo ficará bem.”
- A próxima abordagem para participar em código aberto é a participação. Quando você tem um problema com software de código aberto e há desenvolvedores, seus desenvolvedores começam a resolver os problemas. Eles começam a tornar sua infraestrutura mais eficiente e seus programas mais rápidos e confiáveis.
Um dos projetos Yandex mais famosos na área de software de código aberto é o ClickHouse. Esta é uma base de dados que nasceu como resposta aos desafios que o Yandex.Metrica enfrenta.
E como banco de dados, foi feito em código aberto para criar um ecossistema e desenvolvê-lo em conjunto com outros desenvolvedores (não apenas dentro do Yandex). E agora este é um grande projeto no qual muitas empresas diferentes estão envolvidas.
No Yandex.Cloud, criamos ClickHouse sobre o Yandex Object Storage, ou seja, sobre o armazenamento em nuvem.
Por que isso é importante na nuvem? Porque qualquer banco de dados funciona nesse triângulo, nessa pirâmide, nessa hierarquia de tipos de memória. Você tem registros rápidos, mas pequenos, e SSDs, discos rígidos e alguns outros dispositivos de bloco grandes, mas lentos. E se você for eficiente no topo da pirâmide, terá um banco de dados rápido. se você for eficiente na base desta pirâmide, terá um banco de dados dimensionado. E nesse sentido, adicionar outra camada abaixo é uma abordagem lógica para aumentar a escalabilidade do banco de dados.
Como poderia ser feito? Este é um ponto importante neste relatório.
- Poderíamos implementar ClickHouse sobre MDS. MDS é uma interface interna de armazenamento em nuvem Yandex. É mais complexo que o protocolo S3 comum, mas é mais adequado para um dispositivo de bloco. É melhor para registrar dados. Requer mais programação. Os programadores vão programar, é até bom, é interessante.
- S3 é uma abordagem mais comum que torna a interface mais simples ao custo de menos adaptação a determinados tipos de cargas de trabalho.
Naturalmente, querendo fornecer funcionalidade a todo o ecossistema ClickHouse e realizar as tarefas necessárias dentro do Yandex.Cloud, decidimos ter certeza de que toda a comunidade ClickHouse se beneficiaria com isso. Implementamos ClickHouse sobre S3, não ClickHouse sobre MDS. E isso dá muito trabalho.
Links:
"Camada de abstração do sistema de arquivos"
"Integração AWS SDK S3"
“Implementação básica da interface IDisk para S3”
"Integração de mecanismos de armazenamento de logs com interface IDisk"
"Suporte ao mecanismo de log para S3 e SeekableReadBuffer"
"Suporte ao Storage Stripe Log S3"
"Suporte inicial do Storage MergeTree para S3"
"Suporte total do MergeTree para S3"
"Suporte ReplicatedMergeTree sobre S3"
“Adicionar credenciais padrão e cabeçalhos personalizados para armazenamento s3”
"S3 com configuração de proxy dinâmico"
"S3 com resolvedor de proxy"
Esta é uma lista de pull request para implementar um sistema de arquivos virtual no ClickHouse. Este é um grande número de solicitações pull.
Links:
"Implementação ideal de hardlinks DiskS3"
“Cliente HTTP S3 – Evite copiar o fluxo de resposta na memória”
“Evite copiar todo o fluxo de resposta na memória no S3 HTTP
cliente"
“Capacidade de armazenar marcas em cache e indexar arquivos para disco S3”
"Mover peças do DiskLocal para DiskS3 em paralelo"
Mas o trabalho não terminou aí. Depois que o recurso foi criado, mais algum trabalho foi necessário para otimizar essa funcionalidade.
Links:
"Adicionar eventos SelectedRows e SelectedBytes"
"Adicionar eventos de criação de perfil da solicitação S3 a system.events"
"Adicionar QueryTimeMicroseconds, SelectQueryTimeMicroseconds e InsertQueryTimeMicroseconds"
E então foi preciso torná-lo diagnosticável, configurar o monitoramento e torná-lo gerenciável.
E tudo isso foi feito para que toda a comunidade, todo o ecossistema ClickHouse, recebesse o resultado desse trabalho.
Vamos passar para os bancos de dados transacionais, para os bancos de dados OLTP, que são mais próximos de mim pessoalmente.
Esta é a divisão de desenvolvimento de DBMS de código aberto. Esses caras estão fazendo mágica nas ruas para melhorar os bancos de dados abertos transacionais.
Um dos projetos, a partir do qual podemos falar sobre como e o que fazemos, é o Connection Pooler no Postgres.
Postgres é um banco de dados de processos. Isso significa que o banco de dados deve ter o mínimo possível de conexões de rede para lidar com transações.
Por outro lado, em um ambiente de nuvem, uma situação típica é quando mil conexões chegam a um cluster de uma só vez. E a tarefa do pooler de conexões é agrupar mil conexões em um pequeno número de conexões de servidor.
Podemos dizer que o pooler de conexões é a operadora de telefonia que reorganiza os bytes para que cheguem de forma eficiente ao banco de dados.
Infelizmente, não existe uma boa palavra russa para pooler de conexões. Às vezes é chamado de conexões multiplexadoras. Se você sabe como chamar o pooler de conexão, diga-me, ficarei muito feliz em falar o idioma técnico russo correto.
Investigamos poolers de conexão adequados para um cluster postgres gerenciado. E o PgBouncer foi a melhor escolha para nós. Mas encontramos vários problemas com o PgBouncer. Há muitos anos, Volodya Borodin relatou que usamos o PgBouncer, gostamos de tudo, mas há nuances, há algo para trabalhar.
E nós trabalhamos. Corrigimos os problemas que encontramos, corrigimos o Bouncer e tentamos enviar solicitações pull upstream. Mas era difícil trabalhar com o single-threading fundamental.
Tivemos que coletar cascatas de seguranças remendados. Quando temos muitos Bouncers de thread único, as conexões na camada superior são transferidas para a camada interna dos Bouncers. Este é um sistema mal gerenciado que é difícil de construir e dimensionar para frente e para trás.
Chegamos à conclusão de que criamos nosso próprio pooler de conexões, chamado Odyssey. Nós escrevemos do zero.
Em 2019, na conferência PgCon, apresentei este pooler à comunidade de desenvolvedores. Agora temos pouco menos de 2 estrelas no GitHub, ou seja, o projeto está vivo, o projeto é popular.
E se você criar um cluster Postgres no Yandex.Cloud, então será um cluster com Odyssey integrado, que é reconfigurado ao dimensionar o cluster para frente ou para trás.
O que aprendemos com este projeto? Lançar um projeto concorrente é sempre um passo agressivo, é uma medida extrema quando dizemos que há problemas que não estão a ser resolvidos com rapidez suficiente, não estão a ser resolvidos nos intervalos de tempo que nos convêm. Mas esta é uma medida eficaz.
O PgBouncer começou a se desenvolver mais rápido.
E agora surgiram outros projetos. Por exemplo, pgagroal, desenvolvido por desenvolvedores da Red Hat. Eles perseguem objetivos semelhantes e implementam ideias semelhantes, mas, claro, com especificidades próprias, mais próximas dos desenvolvedores pgagroal.
Outro caso de trabalho com a comunidade postgres é a restauração de um determinado momento. Esta é a recuperação após uma falha, esta é a recuperação de um backup.
Existem muitos backups e são todos diferentes. Quase todos os fornecedores do Postgres possuem sua própria solução de backup.
Se você pegar todos os sistemas de backup, criar uma matriz de recursos e calcular, de brincadeira, o determinante nessa matriz, será zero. O que isto significa? E se você pegar um arquivo de backup específico, ele não poderá ser montado a partir de pedaços de todos os outros. É único na sua implementação, é único no seu propósito, é único nas ideias que nele estão incorporadas. E eles são todos específicos.
Enquanto trabalhávamos neste assunto, a CitusData lançou o projeto WAL-G. Este é um sistema de backup que foi feito pensando no ambiente de nuvem. Agora o CitusData já faz parte da Microsoft. E naquele momento gostamos muito das ideias que foram traçadas nos lançamentos iniciais do WAL-G. E começamos a contribuir para este projeto.
Agora, existem dezenas de desenvolvedores neste projeto, mas os 10 principais contribuidores do WAL-G incluem 6 Yandexoids. Trouxemos muitas das nossas ideias para lá. E, claro, nós mesmos os implementamos, testamos nós mesmos, os colocamos em produção nós mesmos, nós mesmos os usamos, nós mesmos descobrimos para onde ir em seguida, enquanto interagimos com a grande comunidade WAL-G.
E do nosso ponto de vista, agora este sistema de backup, inclusive levando em consideração nossos esforços, tornou-se ideal para um ambiente em nuvem. Este é o melhor custo para fazer backup do Postgres na nuvem.
O que isso significa? Estávamos promovendo uma ideia bastante grande: o backup deveria ser seguro, barato para operar e o mais rápido possível para restaurar.
Por que deveria ser barato operar? Quando nada está quebrado, você não deve saber que tem backups. Tudo funciona bem, você desperdiça o mínimo de CPU possível, usa o mínimo possível de recursos de disco e envia o mínimo possível de bytes para a rede para não interferir na carga útil de seus valiosos serviços.
E quando tudo quebra, por exemplo, o administrador derrubou os dados, algo deu errado, e você precisa voltar ao passado com urgência, você se recupera com todo o dinheiro, porque quer seus dados de volta rápido e intactos.
E promovemos esta ideia simples. E, parece-nos, conseguimos implementá-lo.
Mas isso não é tudo. Queríamos mais uma pequena coisa. Queríamos muitos bancos de dados diferentes. Nem todos os nossos clientes usam Postgres. Algumas pessoas usam MySQL, MongoDB. Na comunidade, outros desenvolvedores apoiaram o FoundationDB. E esta lista está em constante expansão.
A comunidade gosta da ideia do banco de dados rodar em um ambiente gerenciado na nuvem. E os desenvolvedores mantêm seus bancos de dados, dos quais pode ser feito backup uniformemente junto com o Postgres com nosso sistema de backup.
O que aprendemos com essa história? Nosso produto, como divisão de desenvolvimento, não são linhas de código, não são declarações, não são arquivos. Nosso produto não são solicitações pull. Estas são as ideias que transmitimos à comunidade. Trata-se de conhecimento tecnológico e do movimento da tecnologia em direção a um ambiente de nuvem.
Existe um banco de dados como Postgres. Eu gosto mais do núcleo do Postgres. Passo muito tempo desenvolvendo o núcleo do Postgres com a comunidade.
Mas aqui é preciso dizer que Yandex.Cloud possui uma instalação interna de bancos de dados gerenciados. E tudo começou há muito tempo no Yandex.Mail. A experiência que agora levou ao Postgres gerenciado foi acumulada quando o correio quis migrar para o Postgres.
O Mail tem requisitos muito semelhantes aos da nuvem. É necessário que você seja capaz de escalar para um crescimento exponencial inesperado em qualquer ponto dos seus dados. E o correio já estava carregado com algumas centenas de milhões de caixas de correio de um grande número de usuários que constantemente fazem muitas solicitações.
E este foi um desafio bastante sério para a equipe que estava desenvolvendo o Postgres. Naquela época, quaisquer problemas que encontrássemos eram relatados à comunidade. E esses problemas foram corrigidos, e corrigidos pela comunidade em alguns lugares até no nível de suporte pago para alguns outros bancos de dados e ainda melhor. Ou seja, você pode enviar uma carta ao hacker do PgSQL e receber uma resposta em até 40 minutos. O suporte pago em alguns bancos de dados pode pensar que há coisas mais prioritárias do que o seu bug.
Agora, a instalação interna do Postgres envolve alguns petabytes de dados. São alguns milhões de solicitações por segundo. São milhares de clusters. É muito grande.
Mas há uma nuance. Ele não reside em unidades de rede sofisticadas, mas em hardware bastante simples. E há um ambiente de teste específico para coisas novas e interessantes.
E em determinado momento do ambiente de testes recebemos uma mensagem indicando que os invariantes internos dos índices do banco de dados foram violados.
Um invariante é algum tipo de relacionamento que esperamos manter sempre.
Uma situação muito crítica para nós. Indica que alguns dados podem ter sido perdidos. E a perda de dados é algo totalmente catastrófico.
A ideia geral que seguimos em bancos de dados gerenciados é que mesmo com esforço será difícil perder dados. Mesmo que você os remova deliberadamente, ainda precisará ignorar sua ausência por um longo período de tempo. A segurança de dados é uma religião que seguimos com bastante diligência.
E aqui surge uma situação que sugere que pode haver uma situação para a qual talvez não estejamos preparados. E começamos a nos preparar para esta situação.
A primeira coisa que fizemos foi enterrar os logs desses milhares de clusters. Descobrimos quais clusters estavam localizados em discos com firmware problemático que estavam perdendo atualizações de páginas de dados. Marcado todo o código de dados do Postgres. E marcamos as mensagens que indicam violações de invariantes internas com código projetado para detectar corrupção de dados.
Este patch foi praticamente aceito pela comunidade sem muita discussão, pois em cada caso específico era óbvio que algo ruim havia acontecido e precisava ser reportado no log.
Depois disso, chegamos ao ponto em que temos um monitoramento que verifica os logs. E em caso de mensagens suspeitas, ele acorda o plantonista, e o plantonista conserta.
Mas! A verificação de logs é uma operação barata em um cluster e catastroficamente cara para mil clusters.
Escrevemos uma extensão chamada . Ele cria uma visualização do banco de dados na qual você pode selecionar estatísticas sobre erros passados de maneira barata e rápida. E se precisarmos acordar o oficial de plantão, descobriremos isso sem escanear arquivos de gigabyte, mas extraindo alguns bytes da tabela hash.
Esta extensão foi adotada, por exemplo, no repositório de . Se quiser usá-lo, você mesmo pode instalá-lo. Claro que é código aberto.
Mas isso não é tudo. Começamos a usar Amcheck, uma extensão criada pela comunidade, para encontrar violações invariantes em índices.
E descobrimos que se você operar em grande escala, haverá bugs. Começamos a consertá-los. Nossas correções foram aceitas.
Descobrimos que esta extensão não pode analisar índices GiST e GIT. Nós os fizemos apoiar. Mas esse suporte ainda está sendo discutido pela comunidade, porque é uma funcionalidade relativamente nova e tem muitos detalhes aí.
E também descobrimos que ao verificar índices de violações no líder da replicação, no mestre, tudo funciona bem, mas nas réplicas, no seguidor, a busca por corrupção não é tão eficaz. Nem todos os invariantes são verificados. E um invariante nos incomodou muito. E passamos um ano e meio nos comunicando com a comunidade para possibilitar essa verificação nas réplicas.
Escrevemos um código que deveria seguir todos os protocolos can.... Discutimos esse patch há algum tempo com Peter Gaghan da Crunchy Data. Ele teve que modificar ligeiramente a árvore B existente no Postgres para aceitar este patch. Ele foi aceito. E agora a verificação de índices em réplicas também se tornou eficaz o suficiente para detectar as violações que encontramos. Ou seja, essas são as violações que podem ser causadas por erros no firmware do disco, bugs no Postgres, bugs no kernel do Linux e problemas de hardware. Uma lista bastante extensa de fontes de problemas para os quais estávamos nos preparando.
Mas além dos índices, existe uma parte chamada heap, ou seja, o local onde os dados são armazenados. E não há muitos invariantes que possam ser verificados.
Temos uma extensão chamada Heapcheck. Começamos a desenvolvê-lo. E paralelamente, junto conosco, a empresa EnterpriseDB também começou a escrever um módulo, que chamaram de Heapcheck da mesma forma. Só que chamamos de PgHeapcheck, e eles apenas chamaram de Heapcheck. Têm-no com funções semelhantes, uma assinatura ligeiramente diferente, mas com as mesmas ideias. Eles os implementaram um pouco melhor em alguns lugares. E eles postaram em código aberto antes.
E agora estamos desenvolvendo a expansão deles, porque não é mais a expansão deles, mas a expansão da comunidade. E no futuro, isso faz parte do kernel que será fornecido a todos para que possam saber com antecedência sobre problemas futuros.
Em alguns locais, chegámos mesmo à conclusão de que temos falsos positivos nos nossos sistemas de monitorização. Por exemplo, o sistema 1C. Ao usar um banco de dados, o Postgres às vezes grava dados nele que podem ser lidos, mas o pg_dump não consegue ler.
Esta situação parecia corrupção para o nosso sistema de detecção de problemas. O oficial de plantão foi acordado. O oficial de plantão olhou o que estava acontecendo. Depois de algum tempo, um cliente chegou e disse que eu estava com problemas. O atendente explicou qual era o problema. Mas o problema está no núcleo do Postgres.
Encontrei uma discussão sobre esse recurso. E ele escreveu que encontramos esse recurso e foi desagradável, uma pessoa acordou à noite para descobrir o que era.
A comunidade respondeu: “Oh, realmente precisamos consertar isso”.
Eu tenho uma analogia simples. Se você está andando com um sapato que contém um grão de areia, então, em princípio, você pode seguir em frente - sem problemas. Se você vende botas para milhares de pessoas, então vamos fazer botas sem areia. E se um dos usuários de seus calçados vai correr uma maratona, então você quer fazer calçados muito bons e depois dimensioná-los para todos os seus usuários. E esses usuários inesperados estão sempre no ambiente de nuvem. Sempre há usuários que exploram o cluster de alguma forma original. Você deve sempre se preparar para isso.
O que aprendemos aqui? Aprendemos uma coisa simples: o mais importante é explicar à comunidade que existe um problema. Se a comunidade reconheceu o problema, surge então uma competição natural para resolver o problema. Porque todo mundo quer resolver um problema importante. Todos os fornecedores, todos os hackers entendem que eles próprios podem pisar nesse rake, então querem eliminá-los.
Se você está trabalhando em um problema, mas ele não incomoda ninguém além de você, mas você trabalha nisso sistematicamente e, em última análise, é considerado um problema, então sua solicitação pull será definitivamente aceita. Seu patch será aceito, suas melhorias ou mesmo solicitações de melhorias serão analisadas pela comunidade. No final das contas, tornamos o banco de dados melhor uns para os outros.
Um banco de dados interessante é o Greenplum. É um banco de dados altamente paralelo baseado na base de código Postgres, com a qual estou bastante familiarizado.
E o Greenplum tem uma funcionalidade interessante - anexar tabelas otimizadas. Estas são tabelas às quais você pode adicionar rapidamente. Eles podem ser colunares ou em linha.
Mas não houve clustering, ou seja, não houve funcionalidade onde você possa organizar os dados localizados na tabela de acordo com a ordem que está em um dos índices.
O pessoal do táxi veio até mim e disse: “Andrey, você conhece o Postgres. E aqui é quase a mesma coisa. Mude para 20 minutos. Você pega e faz.” Pensei que sim, conheço Postgres, trocando por 20 minutos - preciso fazer isso.
Mas não, não foram 20 minutos, escrevi durante meses. Na conferência PgConf.Russia, abordei Heikki Linakangas da Pivotal e perguntei: “Há algum problema com isso? Por que não há cluster de tabela otimizado para acréscimos?” Ele diz: “Você pega os dados. Você classifica, você reorganiza. É apenas um trabalho." Eu: “Ah, sim, você só precisa pegar e fazer.” Ele diz: “Sim, precisamos de mãos livres para fazer isso”. Eu pensei que definitivamente precisava fazer isso.
E alguns meses depois enviei uma solicitação pull que implementava essa funcionalidade. Esta solicitação pull foi revisada pela Pivotal junto com a comunidade. Claro, houve bugs.
Mas o mais interessante é que quando esse pull request foi mesclado, foram encontrados bugs no próprio Greenplum. Descobrimos que as tabelas heap às vezes quebram a transacionalidade quando agrupadas. E isso é algo que precisa ser consertado. E ela está no lugar que acabei de tocar. E minha reação natural foi – ok, deixe-me fazer isso também.
Eu consertei esse bug. Enviou uma solicitação pull para os fixadores. Ele foi morto.
Depois disso, descobriu-se que essa funcionalidade precisava ser obtida na versão Greenplum para PostgreSQL 12. Ou seja, a aventura de 20 minutos continua com novas aventuras interessantes. Foi interessante tocar no desenvolvimento atual, onde a comunidade está cortando recursos novos e mais importantes. Está congelado.
Mas não terminou aí. Depois de tudo, descobrimos que precisávamos escrever documentação para tudo isso.
Comecei a escrever documentação. Felizmente, os documentaristas da Pivotal apareceram. Inglês é sua língua nativa. Eles me ajudaram com a documentação. Na verdade, eles próprios reescreveram o que propus em inglês real.
E aqui, ao que parece, a aventura terminou. E você sabe o que aconteceu então? O pessoal do táxi veio até mim e disse: “Ainda faltam duas aventuras, cada uma de 10 minutos”. E o que devo dizer a eles? Eu falei que agora vou dar um relatório em escala, depois veremos suas aventuras, porque esse é um trabalho interessante.
O que aprendemos com este caso? Porque trabalhar com código aberto é sempre trabalhar com uma pessoa específica, é sempre trabalhar com a comunidade. Porque em cada etapa trabalhei com algum desenvolvedor, algum testador, algum hacker, algum documentarista, algum arquiteto. Não trabalhei com Greenplum, trabalhei com pessoas próximas a Greenplum.
Mas! Há outro ponto importante: é apenas trabalho. Ou seja, você vem, toma café, escreve código. Todos os tipos de invariantes simples funcionam. Faça normalmente - vai ficar tudo bem! E é um trabalho bastante interessante. Há uma solicitação para este trabalho de clientes Yandex.Cloud, usuários de nossos clusters dentro e fora do Yandex. E penso que o número de projetos em que participamos aumentará e a profundidade do nosso envolvimento também aumentará.
Isso é tudo. Vamos às perguntas.
Sessão de perguntas
Olá! Temos outra sessão de perguntas e respostas. E no estúdio Andrei Borodin. Esta é a pessoa que acabou de falar sobre a contribuição do Yandex.Cloud e do Yandex para o código aberto. O nosso relatório agora não é inteiramente sobre a Nuvem, mas ao mesmo tempo baseamo-nos nessas tecnologias. Sem o que você fez dentro do Yandex, não haveria serviço no Yandex.Cloud, então, obrigado pessoalmente. E a primeira pergunta da transmissão: “Em que está escrito cada um dos projetos que você mencionou?”
O sistema de backup no WAL-G é escrito em Go. Este é um dos projetos mais recentes em que trabalhamos. Ele tem literalmente apenas 3 anos. E um banco de dados geralmente envolve confiabilidade. E isso significa que os bancos de dados são bastante antigos e geralmente são escritos em C. O projeto Postgres começou há cerca de 30 anos. Então o C89 foi a escolha certa. E Postgres está escrito nele. Bancos de dados mais modernos, como ClickHouse, geralmente são escritos em C++. Todo o desenvolvimento do sistema é baseado em C e C++.
Uma pergunta do nosso gerente financeiro, responsável pelas despesas na Cloud: “Por que a Cloud gasta dinheiro no suporte ao código aberto?”
Há uma resposta simples para o gestor financeiro aqui. Fazemos isso para melhorar nossos serviços. De que forma podemos fazer melhor? Podemos fazer as coisas com mais eficiência, rapidez e torná-las mais escaláveis. Mas para nós, esta história é principalmente sobre confiabilidade. Por exemplo, em um sistema de backup revisamos 100% dos patches que se aplicam a ele. Sabemos qual é o código. E estamos mais confortáveis em lançar novas versões para produção. Ou seja, antes de tudo, trata-se de confiança, de prontidão para o desenvolvimento e de confiabilidade
Outra pergunta: “Os requisitos dos usuários externos que vivem no Yandex.Cloud são diferentes dos dos usuários internos que vivem na nuvem interna?”
O perfil de carga é, obviamente, diferente. Mas do ponto de vista do meu departamento, todos os casos especiais e interessantes são criados em uma carga fora do padrão. Desenvolvedores com imaginação, desenvolvedores que fazem o inesperado, têm a mesma probabilidade de serem encontrados tanto interna quanto externamente. Nesse aspecto, somos todos aproximadamente iguais. E, provavelmente, a única característica importante dentro do funcionamento dos bancos de dados Yandex será que dentro do Yandex temos um ensinamento. Em algum momento, alguma zona de disponibilidade fica completamente na sombra e todos os serviços Yandex devem, de alguma forma, continuar a funcionar apesar disso. Esta é uma pequena diferença. Mas isso cria muito desenvolvimento de pesquisa na interface do banco de dados e da pilha de rede. Caso contrário, as instalações externas e internas geram as mesmas solicitações de recursos e solicitações semelhantes para melhorar a confiabilidade e o desempenho.
Próxima pergunta: “Como você se sente pessoalmente sobre o fato de que muito do que você faz é usado por outras nuvens?” Não vamos citar alguns específicos, mas muitos projetos que foram feitos no Yandex.Cloud são usados em nuvens de outras pessoas.
Isso é legal. Primeiro, é um sinal de que fizemos algo certo. E isso coça o ego. E estamos mais confiantes de que tomamos a decisão certa. Por outro lado, fica a esperança de que no futuro isso nos traga novas ideias, novos pedidos de utilizadores terceiros. A maioria dos problemas no GitHub são criados por administradores de sistema individuais, DBAs individuais, arquitetos individuais, engenheiros individuais, mas às vezes pessoas com experiência sistemática vêm e dizem que em 30% dos casos certos temos esse problema e vamos pensar em como resolvê-lo. Isto é o que mais esperamos. Estamos ansiosos para compartilhar experiências com outras plataformas em nuvem.
Você falou muito sobre a maratona. Eu sei que você correu uma maratona em Moscou. Como resultado? Ultrapassou os caras do PostgreSQL?
Não, Oleg Bartunov corre muito rápido. Ele terminou uma hora antes de mim. No geral, estou feliz com o quão longe cheguei. Para mim, só terminar já foi uma conquista. No geral, é surpreendente que existam tantos corredores na comunidade postgres. Parece-me que existe algum tipo de relação entre os esportes aeróbicos e o desejo de programação de sistemas.
Você está dizendo que não há corredores no ClickHouse?
Eu tenho certeza de que eles estão lá. ClickHouse também é um banco de dados. A propósito, Oleg agora está me escrevendo: “Vamos correr atrás do relatório?” Esta é uma ótima idéia.
Outra pergunta da transmissão de Nikita: “Por que você mesmo corrigiu o bug no Greenplum e não o entregou aos juniores?” É verdade que não está muito claro qual é o bug e em qual serviço, mas provavelmente significa aquele de que você falou.
Sim, em princípio, poderia ter sido dado a alguém. Foi apenas o código que acabei de alterar. E foi natural continuar fazendo isso imediatamente. A princípio, a ideia de compartilhar expertise com a equipe é uma boa ideia. Definitivamente compartilharemos as tarefas do Greenplum entre todos os membros da nossa divisão.
Já que estamos falando de juniores, aqui vai uma pergunta. A pessoa decidiu criar o primeiro commit no Postgres. O que ele precisa fazer para realizar o primeiro commit?
Esta é uma pergunta interessante: “Por onde começar?” Geralmente é muito difícil começar com algo no kernel. No Postgres, por exemplo, existe uma lista de tarefas. Mas, na verdade, esta é uma folha do que eles tentaram fazer, mas não tiveram sucesso. Estas são coisas complexas. E normalmente você pode encontrar alguns utilitários no ecossistema, algumas extensões que podem ser melhoradas, que atraem menos atenção dos desenvolvedores do kernel. E, consequentemente, há mais pontos de crescimento aí. No programa Google Summer of Code, todos os anos a comunidade postgres apresenta diversos tópicos diferentes que poderiam ser abordados. Este ano tivemos, creio, três alunos. Alguém até escreveu no WAL-G sobre tópicos importantes para o Yandex. No Greenplum, tudo é mais simples do que na comunidade Postgres, porque os hackers do Greenplum tratam muito bem os pull requests e começam a revisar imediatamente. Enviar um patch para o Postgres é uma questão de meses, mas Greenplum chegará em um dia e verá o que você fez. Outra coisa é que o Greenplum precisa resolver os problemas atuais. Greenplum não é amplamente utilizado, então encontrar o seu problema é bastante difícil. E antes de mais nada, precisamos resolver problemas, claro.
Fonte: habr.com