Get best of the week

O que acontece com a popularidade do MySQL e PostgreSQL? Discussão Mitap

Em 24 de abril, hospedamos a mitap on-line MySQL @ Scale sobre questões de escalabilidade do MySQL . Oradores da Avito, Badoo e ECOMMPAY participaram: Andrey Aksenov (autor da Sphinx, líder da infraestrutura de pesquisa), Evgeny Kuzovlev (CIO ECOMMPAY), Vladimir Fedorkov (especialista em MySQL / DBA no ECOMMPAY) e Nikolai Korolev (especialista em MySQL / DBA no Badoo).

O Mitap saiu por muito tempo, então decidimos publicá-lo em partes e começar do final - com uma discussão muito interessante em nossa opinião sobre a popularidade do MySQL e do PostgreSQL, os motivos da popularidade do PostgreSQL, ORM, incompatibilidade de impedância, índices fractais, raiva, negação, negociação e configuração do vácuo automático e outros problemas de escolha de um DBMS pelos desenvolvedores de livros de visitas no NodeJS. Atenção! Não há vocabulário muito censurado, várias generalizações incorretas foram substituídas e quaisquer coincidências são aleatórias e de modo algum são ofensivas por natureza.

Alexey Rybak : Tome MySQL vs PostgreSQL, não apenas um holivar, mas uma coisa bastante mensurável e visível. Há análises, eu olhei não apenas para um indicador. Agora me lembro de duas coisas na minha cabeça. Temos um grupo no Facebook sobre gerenciamento e desenvolvimento de grandes projetos. Existem vários milhares de pessoas. Fiz uma pesquisa no PostgreSQL ou MySQL, incluindo quem usa nuvem e não em nuvem, porque esse também é um tópico tão novo, muito quente nos últimos anos.

E aconteceu que o Postgres está (um pouco) à frente do MySQL, e para mim era basicamente algum tipo de história nova, porque parecia que a proporção deveria ser diferente. E há pesquisas que são realizadas nas conferências HighLoad, elas foram publicadas. Não tenho uma comparação sistemática direta ano a ano, mas isso mostrou claramente que o Postgres em algum momento em termos do número de respostas para a pergunta "qual é o seu banco de dados principal" alcançou e ultrapassou o MySQL.

Eu tive uma conversa com Petya Zaitsev. Há muito tempo, talvez dois anos atrás, ele veio a Moscou. Isso é basicamente todos os pensamentos de Petya. Pensamentos são tais que, em primeiro lugar, muito foi feito para introduzir vários tipos de soluções ou operadores de gerenciamento no histórico da nuvem. E a lacuna inicial entre a escolha do MySQL ou do Postgres, parecia estar nivelada, no sentido de que se tudo fosse mais simples com o MySQL, demorasse e funcionasse, o Postgres teria que ter muitas danças com pandeiros primeiro, para que isso pudesse curar . E no ambiente de nuvem você tem algo: clicou em um botão - tudo apareceu. Ou seja, por um lado, essa lacuna foi removida. Então, uma certa percepção geral em termos de licenças, proprietária, não proprietária, blá blá blá, também afetou. Grosso modo, se você simplificá-lo completamente, se eu não quiser fazê-lo com um botão, escolherei o que é mais gratuito, bem,ou eles dizem que é grátis. De fato, não está claro, mas mesmo assim. O que é embalado em uma caixa ideologicamente mais correta. Esta é uma história.

E a segunda história é que é especificamente para a Rússia, já que confio nos dados, afinal, não no mundo, mas na Rússia, talvez no mundo a história seja um pouco diferente. Havia uma história que, em algum momento, os pós-congressistas se uniram fortemente, e começaram muito a relações públicas. E eles criaram grupos de trabalho e conferências e, por vários anos, houve uma empresa que realmente faz a solução corporativa russa.

Primeiro de tudo, o que você acha, na Rússia, no mundo, é esse reequilíbrio entre MySQL e Postgres, e se sim, quais são seus motivos, quais dos motivos que eu indiquei são racionais, razoáveis, talvez existam outros causas?

Evgeny Kuzovlev: Para ser sincero, nunca pensei que a nuvem parecesse suavizar todas as diferenças, provavelmente porque tenho tudo no local. Para mim, nuvens são coisas que, digamos, algo na Amazônia, vamos preenchê-lo rapidamente, depois são nuvens para mim. Portanto, deste lado, de alguma forma, nunca considerei. Mas aqui, de fato, a complexidade é reduzida.

Anteriormente, há cerca de oito anos, para que o Postgres funcionasse apenas para você, era necessário dançar tanto com um pandeiro que agora a mãe não sofre. E você colocou o MySQL fora da caixa e funcionou para você. Talvez não oito, talvez 10 a 12 anos atrás. De fato, essa complexidade no Postgres foi bastante reduzida, e o ponto de entrada é operacional e de desenvolvimento; foi comparado com o MySQL de alguma forma.

Mas eu, por exemplo, resolvemos um problema desse tipo, tentei me aproximar e tento me aproximar o mais distante possível. Precisamos, quando iniciamos o DWH, selecionar o mecanismo para a tabela desnormalizada. Ao mesmo tempo, não há análises, há um nível um pouco diferente. É apenas armazenamento puro. Um DBMS revolucionário foi necessário para fornecer, respectivamente, uma análise da comparação de dados.

E abordamos essa questão MySQL ou Postgres, e apesar do fato de os recursos operacionais serem altamente qualificados, escolhemos. E eu, por exemplo, tive a impressão de que o Postgres, ele é, você sabe, acadêmico. Conforme escrito no livro, ele funcionará. E o MySQL, de alguma forma, é bastante leve e com muitos hacks. Mas, ao mesmo tempo, esses hacks funcionam em 99% dos casos. E não importa quantas pessoas do Postgres ofereçam benchmarks sintéticos, em situações reais, que cobrem 99% do uso real de bancos de dados, o MySQL conquista usuários comuns.

E a vantagem, realmente, droga, é apenas uma enorme vantagem do MySQL, que não possui vácuo automático. Porque configurar isso no Postgres, nem todo mundo pode. E assim que os usuários ...

Vladimir Fedorkov: Soa mal (em relação aos engenheiros - aprox. AR ).

Evgeny Kuzovlev: E assim que os usuários se deparam com o vácuo automático, eles começam a enfrentar os problemas mais selvagens. Ou seja, assim, para obter uma degradação de 60% do sistema, isso é para você mesmo, isso é ...

Alexei Rybak: Não, eu apenas entrei no trunfo.

Evgeny Kuzovlev: Bem, me desculpe. Imediatamente disposto como se estivesse em uma mesa. No entanto, eu sei, é claro, que temos o Postgres. Temos muito disso. Temos problemas com o auto-vácuo, graças a Deus, não. Mas, em minha carreira, passei por todos esses casos - raiva, negação, negociação e ajuste do vácuo automático. Mas essa é uma sensação tão dolorosa, vou lhe dizer. O MySQL não causa tanta dor.

Ao mesmo tempo, fico furioso porque no MySQL não tenho a oportunidade ... quero, mas aqui tenho um índice de árvore B e é isso. E mesmo que você crack! Não sei, não consigo criar ...

Alexey Rybak: Existem índices de hash.

Evgeny Kuzovlev: Sim. Mas, vamos comparar o número de índices que temos no MySQL e o número de índices que temos no Postgres. Isso é incomparável. Ao mesmo tempo, o mesmo pode ser dito sobre os mecanismos de tabela. No MySQL, temos um mecanismo de tabela, você quer, eu não sei, você pega um TokuDB e desfruta de um por cento dos casos e em 99% dos casos você não entende por que o tomou ...

Andrey Aksyonov: esfregue com fractais.

Alexey Rybak:Bem, espere, com os motores, isso também é uma farsa. Anteriormente, quando foi inventado, parecia uma coisa legal. Mas, de fato, nada realmente se enraizou.

Andrey Aksyonov: Por que não se enraizou? O InnoDB criou raízes.

Alexey Rybak: Não, quero dizer, além do InnoDB. Ou seja, o InnoDB se tornou apenas um padrão. E todas as outras histórias com peças de coluna, com algumas peças mais específicas, como Toku. Você está certo, eu nem sei onde está essa porcentagem. Ou seja, os motores acabaram sendo uma coisa tão duvidosa.

Evgeny Kuzovlev: Você sabe, psicologia humana, é tal que às vezes a própria possibilidade de escolha é mais importante que a própria escolha. O MySQL fornece.

Alexei Rybak: As pessoas não escolhem o MySQL contra o Postgres, porque existem mecanismos diferentes. Eu acho que este é o último ...

Vladimir Fedorkov: Porque quando as pessoas escolhem o MySQL contra o Postgres, se houver pelo menos alguém na empresa que está por trás do Postgres, ele será escolhido por ser uma religião.

Alexey Rybak: O MySQL também é uma religião.

Vladimir Fedorkov: Não, de maneira alguma.

Andrey Aksyonov:Ninguém colocou outro ponto importante, chamado “o contingente cresceu.” Os requisitos cresceram naturalmente em uma determinada camada. A questão inicial é por que a porcentagem do Postgres está crescendo, a porcentagem dessa falsa miséria chamada MySQL está diminuindo constantemente. E, é claro, no final, Em princípio, o planeta é o mesmo, os dinossauros vão pisar e o MongoDB derrotará todo mundo, mas é no futuro, mas a escala da web ainda é importante, porque os requisitos que os aplicativos fazem mudam com o tempo - uma vez e em um momento do Postgres amadureceu, por sua vez, e um conjunto de requisitos dos desenvolvedores amadureceu da parte deles

: Alexei Rybak: Ouça, eu não acredito nisso, me perdoe. Diga-me, vamos especificamente ...

Andrey Aksyonov: Vamos especificamente. Olha, 1995 ...

Alexey Rybak:As empresas que lançaram originalmente produtos em escala de web projetados para os mesmos caras ... Deus, saíram da minha cabeça! Acabei de ligar ... Agora, aqui está quem derrotará a todos ...

Andrey Aksyonov: Mongo vencerá.

Alexey Rybak: Mongo, sim, sim, sim, desculpe, sim. Então, Mongo inicialmente tinha duas coisas. Primeiro, o armazenamento de objetos, não pense, em resumo, ORM, basta escrever, salvar e não precisa de nada, o SQL não precisa saber, em resumo, é tudo. Isso levou alguns caras, seus requisitos não mudaram, eles são simples: sim, mas era possível, SQL não podia ser ensinado, uau! Que legal! Ele simplesmente disse: salve o objeto, e ele me deixou em algum lugar, classe! Este é o primeiro.

Segundo o que? Não pense em tolerância a falhas, inicialmente podemos fazê-lo em vários CDs e assim por diante. No começo, era besteira de marketing. Então eles distorceram algo e, em princípio, como eu o entendo, nas versões mais recentes agora (funciona e) muito onde realmente o Mongo é usado em grandes instalações.

Quero dizer, este é um bom exemplo quando você entra no mercado, outro mercado, tendo sentido essas duas possibilidades: primeiro, as pessoas que cresceram no paradigma de programação em linguagens de objetos, em geral, essa incompatibilidade de impedância, Esta é uma história fundamental. É mais fácil para eles usar ferramentas que dizem: "apenas me salve", farei tudo por você. E, ao mesmo tempo, fora da caixa, coisas associadas à fila e outras coisas.
Aqui eu entenderia, apesar do fato de eu dizer novamente, você troll, você o configura como algum tipo de caso hiperbolizado, relativamente falando, algum tipo de ficção. No entanto, neste caso, ele diz exatamente a respeito, que você pode sair com esse produto, encontrar um nicho e ele voará, pisará, explodirá. Não entendo o que o Postgres sugeriu ou como eles mudaram e quais requisitos o Postgres subitamente, de acordo com sua lógica, se tornou tão atraente.

Andrey Aksyonov: Repito mais uma vez. Brotos de ambos os lados; Postgres em certos parâmetros, por um lado, e desenvolvedores em certos parâmetros, por outro. Mais uma vez, 1995. Você é um desenvolvedor. Você senta em B ... ( Atyrau ), ganha $ 15, e este é um ano. E você escreve c ***** ( sem valor) livro de visitas em Perl. E então você inicia o processo de seleção - qual banco de dados escolher. Surpreendentemente, o MySQL e o Postgres já existem. E se não estiverem, aparecerão em 1996. Mas você, s *** (mulher da família canina) , a desenvolvedora do livro de visitas sobre Perl em B ... ( Syzran )! Você tem uma tarefa dessa magnitude, você as resolve.

A única referência de referência em que você pode pensar é em quantas solicitações "por círculo" por segundo você será péssimo. E "no círculo" de solicitações por segundo, neste momento, o Postgres recebe quatro vezes e meia menos. Só assim, só porque te fodo. Depois disso, você olha: bem, sim, mas nas transações do Postgres e no MySQL 3.23 MyISAM. Mas, para ser sincero, as transações do meu livro de visitas não são nada para mim (de jeito nenhum)Não é necessário. Escolha fortemente o MySQL.

Agora, um pouco de tempo se passou, 25 anos. Em princípio, você ainda mora em B ... ( Tuymazy ), não está mais escrevendo em Perl, mas no NodeJS, seu salário foi indexado, porque é apenas inflação do dólar, e agora são 15 dólares, multiplicados pela inflação, - 45, e isso é um mês. Você tem os mesmos problemas, além de 100.500 pacotes no NodeJS. E esses pacotes 100500 NodeJS precisam armazenar todo o seu estado em algum lugar, solicitações complexas sobre o gerenciador de pacotes e assim por diante.

E, de repente, você tem seus requisitos, que você utiliza no banco de dados, cresceram um pouco. Por exemplo, por algum motivo, você não pode viver e não deseja viver sem transações. Que coincidência incrível! Você ainda precisa de junções. Aqui estão alguns índices estranhos que começam a pensar, e não apenas uma árvore B automática, como: oh, droga! Mas seria bom ter um índice geográfico, alguma árvore R, ou, digamos, Deus nos salve, árvores fractais.

Isso mudou o conjunto de requisitos dos desenvolvedores, vezes. E, por outro lado, o Postgres, que, nos anos antigos, naturalmente simplesmente reduzia a velocidade encantadora em simples "círculos" ( solicitações), burros e necessários a todos, ele melhorou bastante nos últimos 25 anos, por sua vez. E então eles se conheceram de repente, e mais e mais pessoas ficam surpresas ao descobrir isso, op! Você parece! Mas o Postgres não é tão ruim, ao que parece! E é um pouco melhor para meus requisitos. Minha hipótese é exatamente tal que, grosso modo, no início do MySQL ...

Alexey Rybak: Escute, mas eu não entendo onde é melhor? O que é melhor? Eu entendo que eles são iguais em alguma coisa, mas o que é melhor, eu não entendo.

Andrey Aksyonov: Então, ambos são piores.

Alexey Rybak: Que Mongo?

Andrey Aksyonov:Claro, que, entre aspas, "Mongo". Mas este é um tópico para toda uma conversa separada e todo um segmento de conversa separado chamado "onde está o futuro brilhante".

Vladimir Fedorkov: Não há futuro brilhante. O banco de dados é ruim. Assim que você seleciona um banco de dados, assina uma sentença de morte. Não use bancos de dados. Escreva arquivos.

Alexey Rybak: / dev / null! Escreva para / dev / null, amigos, dev / null é escala na web.

Andrey Aksyonov: Sim. Bem, tudo bem, você também pode encontrar / dev / null em princípio no desempenho, nós podemos.

Alexey Rybak: Ok, amigos. Todo mundo provavelmente está muito cansado. Estamos conversando há mais de duas horas.

Andrey Aksyonov: Mas questões realmente interessantes não foram levantadas.

Nikolay Korolev:Acabei de começar.

Alexey Rybak: Sério? Você quer continuar?

Andrey Aksyonov: Também não derramei uísque.

Alexey Rybak: Mas essa é uma grande questão por que você não fez.

Andrei Aksyonov: Eu não me preparei, é claro ...

Vladimir Fedorkov: Então eles disseram que transmitir, transmitir, nada é impossível, você não pode jurar, não pode ser gordinho.

Alexey Rybak: Ah! Amigos! Todo mundo que estava assistindo a transmissão, muito obrigado por estar conosco. Começamos a parte não oficial, onde ela desliga ... Agora ... removo a transmissão ao vivo. Muito obrigado a todos, obrigado aos nossos convidados - Vladimir, Andrey, Eugene, Nikolai. Tchau, tchau, até mais.

(fim da gravação)

O registro completo da mitap pode ser visualizado no youtube:



Em um futuro próximo, também publicaremos outras partes da infraestrutura, padrões de escala / tolerância a falhas e o estado do ecossistema MySQL.

Se você gosta desse formato, nesta sexta-feira haverá outro rally dedicado à infraestrutura de contêineres, ainda há lugares para ele . Participantes: Yevgeny Potapov (CEO da ITSumma), Dmitry Stolyarov (CTO Flant), Denis Remchukov (também conhecido como Eric Oldmann, COO argotech.io, ex - RAO UES da Rússia), Andrey Fedorovsky (CTO News360.com) e Ivan Kruglov (engenheiro de sistemas, ex - Booking.com). Vamos falar sobre as ferramentas, problemas e perspectivas de contêineres e Kubernetes em uma infraestrutura moderna.

Também temos o grupo do Facebook mencionado "Gerenciamento e desenvolvimento de grandes projetos de TI" , o canal @feedmeto com publicações interessantes de blogs de tecnologia corporativos (principalmente estrangeiros) e o canal do autor @rybakalexey sobre gerenciamento de desenvolvimento em empresas de alimentos.

More articles:


All Articles