Bancos de dados no HighLoad ++ 2019

Trabalhar com um banco de dados é o que afeta significativamente o desempenho de qualquer serviço da web. Se você tentar , poderá organizar uma carga alta sem nenhuma carga.

E se você fizer tudo com sabedoria, será processado os pedidos de muitos milhares de usuários. Portanto, o agendamento do HighLoad ++ tradicionalmente possui muitos relatórios em bancos de dados. Temos faixas no PostgreSQL, MySQL e ClickHouse, existem vários relatórios sobre o MongoDB (na melhor tradição, o palestrante é um engenheiro de desempenho no MongoDB). Além disso, há discursos sobre a comparação de diferentes abordagens ou considerando soluções especializadas. E, de maneira geral, vamos adicionar Tarantool e memória aqui. Um total de 33 relatórios está diretamente relacionado à seção “Bancos de dados e sistemas de armazenamento” e pelo menos 10 indiretamente. E isso não está contando as mitaps , que não são menos que dez, e novas serão adicionadas ao longo do caminho.

Tentaremos ajudá-lo a navegar em toda a sua diversidade e não perder relatórios verdadeiramente únicos. Para maior confiabilidade, solicitamos a opinião do membro do Comitê de Programa responsável por esta seção, Nikolay Samokhvalov. E não pense que Nikolai é o fundador do Postgres.ai e geralmente do pós-gerente - ele é versado no mundo dos bancos de dados, conhece histórias e tendências interessantes nos bastidores.

A revisão está organizada da maneira mais simples possível: abrimos a lista de relatórios e fomos de cima para baixo, abordando os tópicos que devem ser prestados atenção.

Perfil de consulta ClickHouse

O criador de perfil de consulta em bancos de dados analíticos é uma coisa muito interessante. A abordagem deve ser muito diferente dos bancos de dados OLTP, porque, como regra, as consultas são realizadas em bancos de dados analíticos por um longo tempo. Se no PostgreSQL o plano de execução da consulta é estático, faz sentido monitorar quase uma consulta.

Neste relatório, Nikita Lapkov falará sobre o dispositivo desse perfilador para solicitações ClickHouse, que permite determinar qual seção do código fica mais lenta para uma solicitação específica . E tome as medidas apropriadas para implementar o famoso "ClickHouse não diminui a velocidade".

Backup em infraestrutura moderna

Este relatório é apenas da série “próximo ao banco de dados”, que examina o problema do sistema, mas a maior parte é dedicada à questão de backups no MySQL. A história de Anton Turetsky certamente será interessante, porque é a experiência do Badoo, ou seja, é uma questão de um grande número de servidores . Nessa escala, fazer backup e, o mais importante, verificar tudo é uma tarefa não trivial. Além disso, eles conseguiram fazer amizade com as tendências e paradigmas modernos do design de sistemas com backup, para não perder a confiança de que os dados necessários podem ser obtidos em qualquer caso, mesmo o mais crítico.

Nota: os backups sem verificação automática não são backups.

Movendo-se para ClickHouse: 3 anos depois

A ClickHouse conquista com confiança sua posição, mas poucos desenvolvedores de terceiros conseguiram acumular sólida experiência trabalhando com ela. Alexander Zaitsev e Altinity são pioneiros no uso do ClickHouse. Há 3 anos, eles falaram no HighLoad ++ sobre a mudança do sistema de análise de vários petabytes para o ClickHouse.

O que mudou desde então? Alexander compartilhará sua experiência e know-how, que não podem ser encontrados na documentação.

MongoDB vs. Benchmarks do Postgres

Dois convidados falarão sobre o MongoDB no HighLoad ++. O relatório Álvaro Hernández tem um histórico interessante, até escandaloso. Quando Alvaro fez e apresentou benchmarks comparando o MongoDB e o PostgreSQL, houve uma disputa na Internet. O MongoDB posteriormente apresentou seus benchmarks.

Como resultado, cada um dos mundos simplesmente tem sua própria filosofia. Os adeptos do PostgreSQL têm dificuldade em aceitar uma atitude tão confusa em relação aos dados, mas as soluções MongoDB estão em demanda no mercado. Compará-los diretamente é quase impossível, e isso torna o relatório de Alvaro muito empolgante. É fácil aderir cegamente a um ponto de vista, mas é muito melhor conhecer e entender os dois.

Este é um fato divertido para todos - Michael Stonebreaker participou. Ele chamou a atenção para a disputa entre Postgres e Mongo e publicou vários artigos sobre os problemas desse modelo. Ou seja, o fundador do Postgres, que já disse que um tamanho não é adequado para todos e, como resultado, lançou a criação de bancos de dados especializados, incluindo o NoSQL, agora está voltando ao Postgres. Ele escreve quais são os problemas, sugere se casar com modelos de dados e geralmente diz que está tudo bem com o Postgres. É muito interessante assistir a esse ciclo de vinte anos.

Transações distribuídas do MongoDB de cima para baixo

O segundo relatório sobre o MongoDB será elaborado por Henrik Ingo, arquiteto da solução MongoDB, especializado em melhorar o desempenho do MongoDB e fornecer alta disponibilidade. Mas Henrik, antes do MongoDB, trabalhou no mundo MySQL por muitos anos, então ele conhece exatamente os argumentos de vários campos.

No HighLoad ++, Henrik explica como fazer transações em um banco de dados NoSQL distribuído satisfazerem o ACID e por que você pode precisar disso.

Roteiro Odyssey: o que mais queremos do extrator de conexão

Há três semanas, a principal limitação do PgBouncer, na qual as empresas costumam se deparar, foi removida, mas já conseguiu incomodar a todos. Por exemplo, porque era impossível comprometer melhorias no código aberto - os patches Yandex e Avito não são aceitos há anos.

A Yandex não esperou por essas alterações e fez o extrator de conexões - Odyssey. É multi-thread, possui chips adicionais, e Andrei Borodin contará com mais detalhes em seu relatório . Além disso, será possível discutir o roteiro - quais recursos do extrator gostariam de ver nas novas versões da comunidade.

DBA bot Joe. Aliviar a dor do desenvolvimento de back-end

Com este relatório, o Postgres.ai propõe alterar fundamentalmente a abordagem do desenvolvimento de back-end. Em vez de verificar o código e as consultas em bancos de dados pequenos, verifique bancos de dados grandes e veja imediatamente o resultado. Parece lógico - se a solicitação for lenta, será detectada imediatamente. Outra coisa é o que fazer para isso, por exemplo, cópias completas do banco de dados de combate são muito inconvenientes. É aqui que o bot artificial do DBA Joe vem em socorro

Joe pode escrever uma solicitação ou pedir para criar um índice e ele executará todas as ações em uma cópia em tamanho real do banco de dados de combate. A qualquer momento, você pode começar de novo, cancelando todas as alterações em alguns segundos, eliminando os caches de SO e DBMS. E para o trabalho de dez desenvolvedores não precisam de espaço em disco x10. Como essa mágica funciona e com quais componentes de código aberto você pode tentar coletá-la, Anatoly Stansler dirá .

Caro DELETE. Erros típicos ao executar operações massivas em bancos de dados PostgreSQL altamente carregados

E se alguém parecer que não há nada de errado em excluir vários milhões de linhas com um DELETE, quando a condição for conhecida e houver um índice adequado, será necessário ouvir o relatório de Nikolay Samokhvalov. Se você tentar executar uma operação nessas condições, é provável que o serviço caia e há muitas razões para isso imediatamente: o DBA não funcionou, os desenvolvedores não se comportaram corretamente e a abordagem organizacional estava errada.

Nikolay mostrará como o Postgres.ai ajuda a resolver esses problemas e como configurar a proteção sem usá-lo e sempre agir de maneira confiável sem deixar cair o produto. Tudo isso é baseado na experiência real de dor e enormes perdas financeiras . Porque parece claro que você não pode excluir imediatamente, mas, por exemplo, marcar os dados para exclusão primeiro, mas todas as operações de bloqueio em um milhão de linhas são encontradas.

Patroni em GitLab.com

O GitLab usa o PostgreSQL para o MySQL completo, recentemente abandonado, e para garantir que o HA alterne do REPMGR para o Patroni. O Patroni foi desenvolvido por Zalando, sua tarefa é alternar automaticamente se algo aconteceu com o assistente e garantir a disponibilidade do serviço.

Agora, Patroni é o padrão de fato , e o GitLab o implementou em sua solução em nuvem - por uma segunda, 25.000.000 de operações de pull por dia - e está preparando uma solução para verificar as instalações. Jose Cores Finotto compartilhará essa experiência super interessante no HighLoad ++ em 7 de novembro.

StackGres: PostgreSQL nativo da nuvem no Kubernetes

Álvaro Hernández, em comparação com o PostgreSQL e o MongoDB, também apresentará o produto StackGres - essencialmente um substituto para o RDS. Mas torna possível implantar o RDS no Kubernetes muito mais barato, configurar backups com o mínimo de esforço com um trailer, Patroni para failover automático, verificação de integridade e várias ferramentas diferentes.

Este é um empreendimento promissor em uma direção semelhante à história do Linux. Há um kernel do Linux e muitos conjuntos diferentes em torno dele. Vemos a mesma coisa com relação ao PostgreSQL, que pode ser considerado o kernel de um DBMS, e os assemblies aparecerão em torno dele. O StackGres tem boas chances de ganhar popularidade, porque há uma equipe animada e clientes onde você pode tomar suas decisões.

Bloqueios do PostgreSQL

Bloqueios são basicamente um tópico que todos os que trabalham com o PostgreSQL devem ouvir. Além disso, Yegor Rogov, que se estabeleceu como um professor morto, falará sobre eles. Ele conhece profundamente o material e o ajudará a entender os tipos de bloqueios e a ler pg_locks e pg_stat_activity, além de evitar vários erros no design do sistema. O relatório de Egor sobre o HighLoad ++ é uma ótima oportunidade, não apenas para ouvir, mas para conversar com um especialista, fazer suas perguntas e possivelmente discutir problemas completamente diferentes.

Fazendo backup do DBMS carregado

Andrey Borodin e Georgy Rylov trabalham na Yandex e estão desenvolvendo o WAL-G, uma ferramenta de backup de código aberto.

Inicialmente, o WAL-G é uma ferramenta para o PostgreSQL desenvolvida pelo Citus (é curioso que a Microsoft tenha absorvido o Citus recentemente, ou seja, ele comprou um pedaço do PostgreSQL). Porém, a ideia de organizar o trabalho com o WAL-G é adequada para outros bancos de dados. Andrew e George vão apenas falar sobre a funcionalidade do MySQL, Redis, MongoDB e as perspectivas que se abrem em conexão com isso.

Vitess: Escalando sem medo na nuvem

Sugu Sougoumarane é o fundador do PlanetScale. Você talvez ainda não tenha ouvido falar dessa empresa, mas recentemente recebeu um financiamento de US $ 25 milhões para desenvolver seu produto Vitess aberto. Você pode não ter ouvido falar de Vitess também. Portanto, o Vitess é um sistema de sharding do MySQL , e você definitivamente conhece mais de uma grande empresa que usa o Vitess para bancos de dados altamente carregados.

Tudo começou com o YouTube. Foi lá que Sugu e sua equipe criaram o que mais tarde se tornou o sistema de código aberto Vitess. A propósito, eles escolheram Go - um idioma muito jovem na época. Sugu pode contar muitas histórias interessantes sobre os primeiros anos do Go e sobre seu desenvolvimento em geral - no Google, sua equipe se tornou o primeiro usuário importante da linguagem.

Bem, agora, além do YouTube, o Vitess é usado por empresas como GitHub, Pinterest, Slack, Square. Depois de deixar o Google, Sugu fundou a PlanetScale e continua desenvolvendo o Vitess, mantendo o código aberto. Venha ouvir sobre o sharding em escala planetária e sobre o uso do Go no Highload real. E não se esqueça de perguntar sobre os planos para a versão do Vitess no Postgres - Sugu ama muito essa pergunta.

Histórias de falhas do Patroni ou Como travar seu cluster do PostgreSQL

É engraçado ouvirmos o principal mantenedor do Patroni sobre um assunto diferente , porque ele já nos falou sobre o Patroni. Mas Aleksey Lesovsky pode dizer como Patroni é explorado fora de Zalando e que cones são recheados. Porque esses cones podem ser muito diferentes, e Alex promete compartilhar os detalhes de casos reais de acidentes . Aprenderemos com o relatório quais são os problemas, quais lições foram aprendidas no Data Egret e como configurar o Patroni (e, possivelmente, o PostgreSQL) corretamente. E, é claro, temos uma idéia de como identificar rapidamente problemas emergentes e resolvê-los rapidamente.

SQL / JSON: implementamos o padrão e não paramos por aí

Recentemente, a fronteira entre os DBMSs relacionais e os orientados para documentos ficou embaçada. O padrão SQL possui funções para trabalhar com JSON, e o PostgreSQL é pioneiro no suporte eficaz a JSON entre DBMSs relacionais . Em grande parte graças ao Postgres Professional, o padrão já foi parcialmente implementado.

O relatório de Alexander Korotkov é um relato em primeira mão da implementação do SQL / JSON e seu caminho "coração" no PostgreSQL. Essa é uma oportunidade para aprender sobre os recursos internos, a experiência operacional e os planos para o futuro.

PostgreSQL sobre K8s em Zalando: dois anos de batalha

Alexander Kukushkin é co-autor de Patroni, mas este ano ele falará sobre outro desenvolvimento interessante de Zalando. Há dois anos, eles começaram a desenvolver o Postgres-Operator e, no momento, com sua ajuda, os operadores de DBA atendem a mais de 1000 clusters do Postgres em execução no Kubernetes.

Enquanto alguns ainda duvidam da possibilidade de bancos de dados no Kubernetes, as grandes empresas já estão trabalhando com tudo isso. Seria legal conhecer e aprender com outro lugar.

A empresa solicita o Postgres

As grandes empresas estão cada vez mais usando o PostgreSQL, muitas vezes esperando com que estão acostumadas na empresa. Um exemplo típico - precisamos de soluções para replicação lógica - procuramos o fornecedor. E alguns fornecedores até deram esse suporte - havia o Oracle, agora o PostgreSQL apareceu. Mas começamos a entender, e acontece que muito funciona de maneira diferente.

Estamos testemunhando a colisão dos mundos de código aberto e empresas. Andreessen Horowitz publicou recentemente um estudo dizendo que o interesse dos investidores em código aberto cresceu substancialmente e continuará a crescer. Portanto, os fornecedores precisam mudar para código aberto e novos modelos de monetização - isso será melhor por vários motivos.

Ivan Panchenko lhe dirá exatamente quais dificuldades de migração para o PostgreSQL para empresas são subjetivas e pertencem ao tipo "mãos tortas", e quando são esses desafios importantes com os quais o PostgreSQL enfrenta durante seu desenvolvimento. Os resumos prometem discutir esses tópicos: fatores de escala (tamanhos de tabela, número de objetos, memória, conexões, replicação), recursos de armazenamento (Heap, armazenamentos plugáveis), tabelas temporárias, vácuo, interação com o sistema operacional.

E nesta nota - o futuro é de código aberto - concluiremos um estudo detalhado dos relatórios. Infelizmente, nos bastidores o MySQL foi quase completamente deixado para trás. Se esse é o seu tópico, confira Vittorio Cioe e Alkin Tezuysal .

O ClickHouse também é representado em um número maior de relatórios e, como sempre, um mitap é de particular valor, onde você pode fazer qualquer pergunta sobre o ClickHouse, junto com os desenvolvedores, encontrar uma solução para os problemas, discutir oportunidades e planos.

Também não tocamos no Tarantool, pois este é um servidor de banco de dados e aplicativos em uma garrafa. E os relatórios do programa HighLoad ++ 2019 focam nessa multifuncionalidade. Vasily Tyubek falará sobre o Tarantool Kubernetes Operator para executar um banco de dados em Kubernetes, Yaroslav Dynnikov mostrará a conveniência de construir sistemas distribuídos usando Tarantool. E não perca a oportunidade de esclarecer todos os detalhes com os próprios desenvolvedores - é muito mais produtivo e interessante do que ler a documentação.

Em geral, consideramos perguntas para palestrantes, discussões nos bastidores e networking - uma parte muito, se não a mais importante da conferência. Portanto, criamos todas as condições para a comunicação informal e tentamos nos divertir.

Nos dias 7 e 8 de novembro, o HighLoad ++ enche o SKOLKOVO até a borda e sai dele. Em Novosibirsk e São Petersburgo, haverá as filiais do HighLoad ++ com uma teleconferência para o salão principal e todos os benefícios da criação de redes na conferência. No youtube, lançaremos uma transmissão de vídeo aberta dos relatórios mais esperados e o Prêmio HighLoad ++ e, no canal de telegrama, no outro caminho, lançaremos os agentes de tradução de texto. Em resumo, mesmo que você não vá para o HighLoad ++ (em vão - você ainda pode mudar de idéia, conseguir uma multa e decolar), ainda pode se divertir muito através de nossas redes.