Qualquer arquiteto de banco de dados projetando um banco de dados MySQL enfrenta o problema de selecionar o mecanismo de armazenamento adequado. Normalmente, um aplicativo usa apenas um mecanismo:MyISAM ou InnoDB . Mas vamos tentar ser um pouco mais flexíveis e imaginar como diferentes mecanismos de armazenamento podem ser usados.
O modelo de dados inicial
Para começar, vamos construir um modelo de dados simplificado para um sistema de CRM (gerenciamento de relacionamento com o cliente) que usaremos para ilustrar o ponto. O design abrangerá as principais funções do CRM:dados de vendas, definições de produtos e informações para análise. Ele não conterá detalhes normalmente usados em sistemas de CRM.
Como você pode ver, esse modelo de dados possui tabelas que armazenam informações transacionais chamadas
sale e sale_item . Quando um cliente compra algo, o aplicativo cria uma nova linha na sale tabela. Cada produto comprado será refletido no sale_item tabela. Uma tabela relacionada, sale_status , serve para armazenar possíveis status (ou seja, pendente, concluído etc.). O
product tabela armazena informações sobre mercadorias. Ele define cada produto e seus descritores básicos. Em um diagrama mais detalhado, eu adicionaria mais tabelas para lidar com a especificação e categorização do produto. Mas para nossas necessidades atuais, isso não é necessário. A tabela de clientes mantém dados sobre clientes. Isso é parte integrante de qualquer sistema de CRM e geralmente rastreia a atividade individual de todos os usuários. Obviamente, muitas vezes tem informações realmente detalhadas. Mas, como observei, não precisamos desses detalhes agora.
O
log table armazena o que cada cliente fez dentro do aplicativo. E o report_sales table é projetado para uso de análise de dados. Em seguida, descreverei os mecanismos de armazenamento MySQL que poderiam ser usados neste projeto. E mais tarde, discutiremos qual mecanismo é adequado para cada tipo de tabela.
Uma visão geral dos mecanismos de armazenamento MySQL
Um mecanismo de armazenamento é um módulo de software que o MySQL usa para criar, ler ou atualizar dados de um banco de dados. Não é recomendado escolher aleatoriamente um mecanismo, mas muitos desenvolvedores ficam felizes em usar MyISAM ou InnoDB, embora outras opções também estejam disponíveis. Cada motor tem seus próprios prós e contras, e a seleção adequada do motor depende de vários fatores. Vamos dar uma olhada nos motores mais populares.
- MyISAM tem uma longa história com o MySQL. Era o mecanismo padrão para bancos de dados MySQL antes da versão 5.5. MyISAM não suporta transações e possui apenas bloqueio em nível de tabela. É usado principalmente para aplicativos de leitura intensiva.
- InnoDB é um mecanismo de armazenamento geral que equilibra alta confiabilidade e bom desempenho. Ele suporta transações, bloqueio em nível de linha, recuperação de falhas e controle de simultaneidade de várias versões. Além disso, fornece uma restrição de integridade referencial de chave estrangeira.
- A memória mecanismo armazena todos os dados na RAM. Ele pode ser usado para armazenar referências de pesquisa.
- Outro mecanismo, CSV , mantém os dados em arquivos de texto com valores separados por vírgulas. Este formato é usado principalmente para integração com outros sistemas.
- Mesclar é uma boa escolha para sistemas de relatórios, como em data warehousing. Ele permite o agrupamento lógico de um conjunto de tabelas MyISAM idênticas, que também podem ser referenciadas como um objeto.
- Arquivo é otimizado para inserção de alta velocidade. Ele armazena informações em tabelas compactas e não indexadas e não suporta transações. O mecanismo de armazenamento Archive é ideal para manter grandes quantidades de dados históricos ou arquivados raramente referenciados.
- O Federado engine oferece a capacidade de separar servidores MySQL ou criar um banco de dados lógico de muitos servidores físicos. Nenhum dado é armazenado nas tabelas locais e as consultas são executadas automaticamente nas tabelas remotas (federadas).
- O Buraco Negro motor atua como um “buraco negro” que aceita dados, mas não os armazena. Todas as seleções retornam um conjunto de dados vazio.
- O mecanismo Exemplo é usado para mostrar como desenvolver novos mecanismos de armazenamento.
Esta não é uma lista completa de mecanismos de armazenamento. O MySQL 5.x suporta nove deles diretamente da caixa, além de dezenas de outros desenvolvidos pela comunidade MySQL. Mais detalhes sobre mecanismos de armazenamento podem ser encontrados na documentação oficial do MySQL.
Atualizando o design do modelo de dados
Olhe novamente para o nosso modelo de dados. Obviamente, tabelas diferentes serão usadas de maneiras diferentes. A
sale tabela deve suportar transações. Por outro lado, o log e report_sales tabelas não requerem este recurso. A principal missão do log table está armazenando dados com a máxima eficiência. A recuperação rápida é o principal requisito para o report_sales tabela. Vamos ter em mente os pontos acima e modificar nosso esquema de banco de dados. No Vertabelo, você pode definir “Storage engine” nas Propriedades da tabela painel. Por favor, dê uma olhada nas fotos abaixo.
Configurando o mecanismo de armazenamento
Então, vamos ver o design atualizado do banco de dados.
Eu especifiquei mecanismos de armazenamento para tabelas existentes e reorganizei o report_sales tabela. Como você pode ver, as tabelas são divididas em três grupos:
- Tabelas de transações, que são usadas com o aplicativo principal
- Tabelas de relatório para análise de BI
- Tabela de registro para armazenar todas as atividades do usuário
Vamos falar sobre todos eles separadamente.
Tabelas de transações
Essas tabelas contêm dados inseridos pelos usuários durante as operações de rotina diária. No nosso caso, haveria informações de venda, como:
- qual funcionário fez a venda
- quem comprou o produto
- o que foi vendido
- quanto custa
Na maioria dos casos, o InnoDB é a melhor solução para tabelas de transações. Esse mecanismo de armazenamento oferece suporte ao bloqueio de linha e alguns usuários podem trabalhar juntos. Da mesma forma, o InnoDB permite o uso de transações e chaves estrangeiras. Mas, como você sabe, esses benefícios não são gratuitos; o mecanismo pode executar instruções selecionadas mais lentamente do que o MyISAM e salvar dados com menos eficácia do que o Archive.
Todos os mecanismos descritos acima possuem algumas proteções, para que os desenvolvedores não precisem escrever funções de reversão complexas para cada operação. Em um aplicativo de vendas típico, manter a consistência dos dados é mais importante do que possíveis problemas de desempenho.
Tabelas de relatório
No novo design, dividi uma mesa em duas mesas menores. Isso economiza esforço na hora de gerenciar dados e realizar manutenção de tabelas e índices. Também nos permite criar a tabela MERGE
sale_report para combinar outras tabelas de relatórios. Como resultado, a ferramenta de BI ainda recupera dados de uma tabela enorme (para fins de análise), mas temos o benefício de trabalhar com tabelas menores. O
Report_sale_{year} tabelas são tabelas MyISAM. Este mecanismo de armazenamento não suporta transações e só pode bloquear a tabela como um todo. Como o MyISAM não se preocupa com esses itens complexos, ele realiza operações de manipulação de dados em velocidade. Por causa de sua estrutura de arquivos, esse mecanismo de armazenamento lê dados mais rapidamente do que o InnoDB mais popular. A Tabela de Registros
O mecanismo de armazenamento Archive é uma boa opção para armazenar dados de log. Ele pode inserir linhas e compactar dados armazenados rapidamente. Há grandes benefícios para manter informações sobre as atividades do usuário. No entanto, o arquivo tem algumas restrições. Ele não oferece suporte a operações de atualização e recupera dados lentamente. Mas em uma tabela de log, os benefícios descritos são mais importantes do que as desvantagens.
Integrando mecanismos de armazenamento
Cada sistema deve ser integrado com a vida externa. Para aplicativos, podem ser usuários que preenchem tabelas de referência e transação. Podem ser serviços e integração via REST, SOAP, WCF ou algo assim. E por último, mas não menos importante, pode ser a integração de banco de dados.
MySQL e Oracle desenvolveram dois mecanismos de armazenamento realmente úteis:Federado e CSV . O primeiro, Federado , deve ser usado para carregar dados de um banco de dados MySQL externo. O segundo mecanismo de armazenamento, CSV , permite que os bancos de dados salvem registros no formato CSV e leiam arquivos separados por vírgulas no ar, sem nenhum esforço adicional.
Como você pode ver, usar diferentes mecanismos de armazenamento para diferentes propósitos dá maior flexibilidade ao seu banco de dados. Se um arquiteto de banco de dados tomar sua decisão depois de considerar todos os prós e contras, o resultado pode ser realmente impressionante.
Você tem experiência no uso de diferentes mecanismos de armazenamento no design de banco de dados? Gostaria de ver suas dicas e sugestões. Por favor, compartilhe-os na seção de comentários.
