Amor e ódio pelo MySQL

No processo de desenvolvimento do banco de dados, os quatro pontos ordenados de segurança -> estabilidade -> eficiência -> baixo custo têm estado nas sombras. O último é apenas conversa fiada quando deixa o primeiro. Na noite de 19 de outubro, o MySQL lançou a versão 8.0.22. Um dos novos recursos (failover automático de conexão para canais de replicação assíncrona) chamou minha atenção e também fiquei muito interessado. Como um veterano de DBA, tenho sentimentos contraditórios. Nos últimos 20 anos, A função de failover sempre foi dominada pela ferramenta passo a passo de três partes. Ela tem sido a dor de várias gerações de DBAs. O banco de dados mais popular da Internet tem sido criticado nessa área. Esse recurso ainda não foi testado, aconteça o que acontecer, pelo menos essa parte do oficial finalmente começou a resolvê-lo. Na calada da noite, resolvi meus pensamentos e resumi o desenvolvimento dos produtos MySQL. Basicamente, eles se desenvolveram nas seguintes direções:
1. Direção da sincronização mestre-escravo: sincronização assíncrona para semissincronização e, em seguida, para semissincronização aprimorada. Replicação de grupo; adotando a estratégia de segurança de sincronização para melhorar a eficiência da sincronização e de replicação de thread único para replicação paralela, dedicado a reduzir o problema de atraso mestre-escravo, mas o atraso absoluto relativo de sincronização acompanhou todo o processo de desenvolvimento até agora.
2. Direção de otimização de desempenho: multi-threaded, pool de threads (suportado pela versão empresarial da versão original do MySQL, não suportado pela versão da comunidade); vários logs são independentes, a partir da versão 8.0.22, os logs para garantir a segurança e os registros de problemas são basicamente independentes. Você pode ajustar os parâmetros dinamicamente para controlar individualmente o fechamento e a abertura; refatorar o motor central Innodb, otimizar vários bloqueios, bloqueios independentes e otimizar as operações de transação. Várias otimizações de uma operação de refeição fazem o desempenho da versão mais recente do MySQL atingir níveis sem precedentes.
3. A direção do banco de dados multimodo: dados relacionais, dados semiestruturados JSON, dados de objetos, tipo de memória e mecanismo de pesquisa de texto completo, etc. vários mecanismos de dados, apoiando negócios OLTP começaram a se expandir para negócios OLAP (serviço de análise com suporte na nuvem Oracle) ), embora seja compatível apenas com sua própria nuvem.
4. Aprenda com outras direções de banco de dados:A maior referência é o banco de dados ORACLE. As várias gramáticas e alguns usos estão se tornando cada vez mais ORACLE; algumas funções do MongoDB são usadas para referência, como configurações relacionadas no MIC, clonagem automática de nós escravos, etc., mas existem alguns complexo.
5. Operação inteligente e direção de manutenção: suporte a todos os tipos de DDL online, quase nenhuma percepção de negócios, isso estabelece uma base sólida para o índice de otimização dinâmica de autoatendimento inteligente futuro; quase todos os principais parâmetros de desempenho suportam modificação online; suportam parâmetros de ajuste dinâmico persistentes, Certifique-se de que os parâmetros após a reinicialização são os mesmos de antes da reinicialização; quando o MySQL é fechado, os dados ativos na memória podem ser persistidos no disco rígido e recarregados do disco rígido para a memória ao iniciar, reduzindo o pré-aquecimento do banco de dados e entrando rapidamente no estado de tempo de guerra anterior após o banco de dados ser reiniciado; Função de reescrita de instrução SQL, reescrevendo SQL sem alterar o código de negócios; pode suportar o ajuste automático de algumas configurações de parâmetros na inicialização de acordo com a configuração de hardware, embora os parâmetros que podem ser ajustados automaticamente sejam limitados, combinados com os itens anteriores, é para o futuro MySQL nos parâmetros inteligentes Em termos de ajuste e auto-otimização, o desenvolvimento de bancos de dados autônomos estabeleceu a base.
6. Melhorar a direção da segurança: um registro de som garante que nenhum dado seja perdido em várias condições anormais. Este também é o requisito mais básico do banco de dados. O MySQL tem trabalhado muito para aprimorá-lo e se esforça para construir um banco de dados de nível financeiro; métodos de autenticação de usuário aprimorados caching_sha2_password, fortalece o modo de autenticação e aumenta a dificuldade de cracking por força bruta de strings de autenticação do usuário. Mas o maior recurso de segurança, failove, nunca foi.
7. Direção da redução de custos: o progresso desta rota é um pouco lento. No momento, a compressão innodb foi exercida e a taxa de compressão foi melhorada; esforços foram feitos para melhorar a experiência do usuário e simplificar o uso e operação dos custos de mão de obra, mas algumas operações são comparadas Configuração de operação complicada e malformada, como a configuração do cluster innodb MySQL.
Embora o MySQL seja muito querido pelas pessoas, a capacidade instalada também é muito grande e também é muito boa, mas ainda tem muitas deficiências :
1. Criar nós escravos automaticamente:A replicação de grupo acabou de adicionar automaticamente um novo nó, mas todos os logs do Binlog devem ser inicializados para iniciar o banco de dados (eu sinto que o produto que está projetando esta solução é um pouco pequeno), caso contrário, você precisa usar o mysqldump para fazer isso manualmente, e a operação de adicionar novos nós ainda é muito problemática , Ainda é inconveniente e a operação ainda é complicada. Por outro lado, o MongoDB é muito mais simples. Tanto a operação quanto o custo de operação e manutenção são muito baixos.
2. Failover: Após mais de 20 anos de desenvolvimento, o MySQL ainda depende de ferramentas de terceiros para failover.Os aspectos de autocorreção da falha foram aprimorados, mas até agora não é o ideal. Na verdade, no MySQL JDBC, semelhante ao MongoDB, ele suporta a configuração de vários bancos de dados e vários nós, mas não há detecção automática de falhas e função de comutação.Esta função sempre foi uma decoração. A versão MySQL8.0.22 finalmente suporta comutação de failover. Olhando para os parâmetros de configuração, a operação é interrompida. Estima-se que esta função do MongoDB não seja uma estrela. Espera-se que o governante invista mais mão de obra e recursos materiais nesta área, para que o MySQL termine com este estado original de operação e melhore o SLA e o tempo de indisponibilidade comercial do pessoal de operação e manutenção.
3. Otimização da operação de exclusão de tabelas / bancos de dados: No momento, a exclusão de grandes tabelas e bibliotecas tem um grande impacto no desempenho do banco de dados e até mesmo o banco de dados pode ficar seco.
4. Exclusão falsa ou exclusão atrasada das tabelas do banco de dados , faça com que o banco de dados exclua a lixeira e personalize o remédio do arrependimento para o banco de dados.
5. O MySQL Innodb Cluster do MySQL é atualmente amargo e estima-se que não seja usado por pessoas. Os componentes do roteador e do shell podem ser totalmente integrados ao MySQL. Quanto mais componentes, maior o custo de operação e manutenção. Este modo de gerenciamento não é muito bom com middleware. , Também pode ser personalizado de forma privada (afinal, o custo de modificar o middleware não é tão alto quanto o do código-fonte do MySQL), o gerenciamento de configuração é complicado, não é bom corresponder ao conjunto de replicação do MongoDB?
6. Não fazer negócios corretamente:Cada produto tem sua competitividade central. Os produtos atuais do MySQL têm a suspeita de esquecer suas intenções originais (seguro, estável, eficiente e de baixo custo). Eles gastam muito tempo, querem fazer muito e querem consultar outras funções de banco de dados. , Todo banco de dados no MySQL pode funcionar? Você pode realmente unificar o banco de dados?
O lendário armazenamento MySQL e separação de computação terão suporte oficial?
A arquitetura de armazenamento de banco de dados e separação de computação tem sido muito popular nos últimos dois anos. Essa também é uma direção para o desenvolvimento de banco de dados. Por um lado, os avanços na tecnologia de hardware suportam escalonamento elástico, uso racional de recursos e redução de custos. Por outro lado, os negócios precisam de alta simultaneidade e grande volume de dados. Principalmente no momento em que tudo é nuvem, o surgimento desse tipo de arquitetura é de fato oportuno. Se o MySQL suportar essa arquitetura, ele inevitavelmente terá que fazer muitas modificações no mecanismo de armazenamento MySQL-Innodb e também ter seu próprio sistema de arquivos distribuído correspondente.A arquitetura MySQL atual pode precisar de muitos ajustes. Para reduzir ainda mais o atraso da sincronização mestre-escravo, os funcionários do MySQL podem oferecer suporte à replicação física para otimizar o problema de atraso. Quanto à separação de armazenamento e computação, pessoalmente sinto que não será oficialmente suportado, pelo menos em um curto período de tempo. Talvez seja suportado no MySQL 13, porque meu colega de Henan Wang Shouyi disse que treze incenso ^ - ^
define as vantagens de vários bancos de dados. Não se esqueça da intenção original, o mar é o rio, a tolerância é grande, sinto que o MySQL não é tolerante e aberto o suficiente. Muitos casos prontos de sucesso e ideias de programas podem ser usados ​​como referência. Além disso, o pessoal oficial de P&D também é de primeira linha no mundo. Como eles podem aprender? Não entendemos muitas coisas, não sabemos, não ousamos perguntar, quem sabe, talvez você acorde amanhã e o MySQL fará uma virada linda e entrará na era dos bancos de dados inteligentes e autônomos com maquiagem de noiva ?