Como melhorar o desempenho do banco de dados: 5 etapas que você pode seguir

Implantar uma solução de monitoramento de desempenho
Use a versão comercial mais recente do Couchbase
Dimensione sua infraestrutura adequadamente
Usar declarações preparadas
Otimizar índices

Há muitas etapas no caminho para melhorar o desempenho do banco de dados. Mas primeiro é necessário perguntar qual é o desempenho ideal do banco de dados? Nesta publicação, vou orientá-lo em algumas das áreas que considero úteis em minha carreira como especialista em banco de dados. Cada uma das etapas abaixo é um ponto de partida para que você investigue mais a fundo o mundo da otimização de bancos de dados. Algumas delas proporcionarão ganhos mais explosivos do que outras, mas vale a pena investigar todas elas. Lembre-se de que cada ambiente é diferente e pode exigir uma abordagem diferente de sua parte e de suas equipes para atender às necessidades de seus clientes internos e externos. Por fim, quando se trata de como melhorar o desempenho do seu banco de dados, estamos aqui para ajudá-lo no que for possível.

Implantar uma solução de monitoramento do desempenho do banco de dados

Usar o banco de dados NoSQL mais rápido do mundo sem monitoramento é tão imprudente quanto usar papel como guarda-fogo. Inacreditavelmente, o papel já foi usado como proteção contra fogo entre o motor e os pilotos de corrida no automobilismo! Igualmente inacreditável é o fato de que algumas empresas não investem o tempo e o dinheiro necessários para monitorar corretamente. É claro que não é o seu caso, caro leitor, pois você é um dos iluminados que já implementou uma solução de monitoramento e está verificando se todas as BASE estão cobertas (viu o que eu fiz? Não se preocupe se não estiver, Você pode ler sobre nosso IPO aqui) ou está no topo de sua lista de tarefas.

A primeira coisa que você precisa decidir é o que deve monitorar. O que você está tentando alcançar? Se a sua avaliação concluir que você ainda não tem tudo o que precisa, você deve comprar ou construir para atender aos critérios comerciais?

Tendo passado mais de dez anos trabalhando para ISVs (Independent Software Vendors) no setor de ferramentas (especializado em monitoramento e otimização), já escrevi milhares de palavras sobre o debate entre comprar e construir e o que você deve procurar em uma solução de monitoramento. Em resumo, isso geralmente se resume à batalha entre despesas operacionais e de capital e ao que é mais valorizado em seu ambiente político:

• Qual é o valor do seu tempo do ponto de vista de gastos fiscais e geração de receita?
• Qual é o ROI da compra?

Quando se trata de como medir o desempenho do banco de dados, essas são as perguntas fundamentais que precisarão ser respondidas para moldar essa área de aprimoramento do desempenho.

Existem, é claro, várias empresas que fornecem soluções de monitoramento prontas para serem implantadas. Elas não serão mencionadas aqui, pois isso desatualizará o conteúdo, e é uma tarefa simples digitar algumas palavras-chave em seu mecanismo de busca favorito. No restante desta seção, apresentarei alguns dos recursos de monitoramento nativos e opções de código aberto para monitoramento.

A primeira e mais acessível maneira de visualizar as métricas é por meio do console da Web do Couchbase. Qualquer pessoa com as permissões relevantes pode visualizar a infinidade de métricas disponíveis ou criar seu painel personalizado.

Um exemplo do painel padrão pode ser visto abaixo. Observe a capacidade de alterar os períodos de tempo, os compartimentos e de se aprofundar em nós individuais.

Para criar seu painel, verifique se você está na página Painel de controle e, em seguida, clique na lista suspensa Choose Dashboard ou crie o seu próprio. Neste exemplo, começamos com uma tela em branco em vez de usar os gráficos atuais.

Depois de clicar em Salvar, você será solicitado a criar um novo grupo para os gráficos. Quando você tiver adicionado um grupo, clique em Adicionar um gráfico.

Você pode escolher um tamanho e uma métrica de dados para mostrar ao adicionar um gráfico. Neste exemplo específico, mostramos nós separados em vez de uma exibição combinada. Observe que as dicas de ferramentas estão disponíveis quando você passa o mouse sobre uma métrica, caso não tenha certeza de qual é a métrica.

Como falaremos sobre índices mais adiante neste post, escolhi quatro contadores de índice nesse sistema ocioso para mostrar o tipo de dados que o sistema poderia mostrar:

Como você pode ver, é fácil criar seus painéis e permite que você se concentre nas métricas que mais importam para o seu ambiente da maneira que melhor lhe convier.

Se você prefere arregaçar as mangas e investigar dados, talvez esteja mais interessado em cbstats ou Obtenção de estatísticas do cluster por meio da API REST. Como há muitas métricas que você pode visualizar, não entraremos em detalhes aqui. Em vez disso, para se aprofundar no que é possível coletar, consulte o seguinte Guia de monitoramento do Couchbase.

Depois de escolher as métricas de seu interesse, você poderá visualizá-las no Grafana; esta excelente postagem do blog o orientará no processo. Como criar painéis de observabilidade com Prometheus, Grafana e Couchbase.

Use a versão mais recente do Couchbase Enterprise

Não é de surpreender que a edição comercial do Couchbase ofereça funcionalidades muito superiores às da versão gratuita. Esta seção abordará algumas das principais funcionalidades das quais você se beneficiará com o Couchbase Enterprise Edition.

Para obter uma lista completa das diferenças entre as várias edições do Couchbase, consulte https://www.couchbase.com/products/editions.

Quantidade de nós
Como era de se esperar, o número de nós permitidos na Community Edition é muito menor do que o da versão comercial. No momento, ele está limitado a 5 nós; no entanto, é preciso sempre verificar a documentação mais recente, pois isso está sujeito a alterações.

Por que esse é um problema de desempenho do banco de dados e quais são as soluções? Há alguns motivos, o principal deles é a escalabilidade, que afeta o desempenho. Não é de se surpreender que a incapacidade de escalonar além de cinco nós cause problemas com conjuntos de dados maiores. A incapacidade de usar mais hardware será um problema em uma arquitetura que prioriza a memória. Como seria de se esperar, a Enterprise atenua esse problema de várias maneiras, por exemplo, por meio da compactação.

Compressão
Esse é um elemento essencial para melhorar o desempenho e manter o custo total de propriedade baixo. Se for possível colocar mais documentos na RAM, isso significa menos hardware e menor custo. Isso também simplifica a implementação e o gerenciamento (não que isso seja muito difícil), reduzindo ainda mais os custos.

A compactação é indiscutivelmente mais importante quando se trata de cenários em que há alta densidade de dados ou, em termos leigos, "muito mais dados do que cabem na memória". Por isso, eles precisam ser mantidos e recuperados do disco para serem fornecidos de volta ao usuário final. Como os discos geralmente são fatores de magnitude mais lentos do que a memória, se os dados forem menores, eles serão lidos do disco mais rapidamente.

Indexação
Se você quiser migrar um aplicativo relacional legado diretamente para o NoSQL, provavelmente usará o SQL++, nossa linguagem SQL para JSON. Além disso, você desejará transferir seus esquemas e tabelas e ter os mesmos índices neles. Com o Couchbase 7.0, você certamente pode fazer isso; no entanto, haverá algumas diferenças no comportamento dos índices entre as edições Community e Enterprise.

Em primeiro lugar, eles usam dois mecanismos diferentes. Em segundo lugar, é possível usar o particionamento na versão Enterprise. A vantagem do particionamento é que o usuário pode dividir o índice em vários nós, permitindo que ele se beneficie do uso de mais núcleos em vez de ficar restrito aos núcleos de um nó. Em índices mais extensos, isso pode fazer uma diferença significativa no desempenho.

Escopos e coleções
Embora os escopos e as coleções estejam disponíveis na Community Edition, eles não estão disponíveis em todos os serviços que o Couchbase oferece. Se você é novo no Couchbase e nunca ouviu falar de Escopos e Coleções, mas está acostumado com bancos de dados relacionais, então um Escopo seria semelhante a um esquema e uma Coleção seria semelhante a uma tabela.

Parece que o Couchbase pode estar se tornando um banco de dados relacional, mas, na verdade, somos a opção de banco de dados moderno para aplicativos corporativos, fornecendo uma fusão entre os mundos relacional e NoSQL distribuído. Estamos tornando mais fácil do que nunca a migração de sistemas monolíticos legados para uma nova arquitetura distribuída que prioriza a memória e oferece suporte a microsserviços.

A adição de escopos e coleções nos permitiu rearquitetar vários processos internos, resultando em um desempenho muito mais rápido do que nas versões anteriores, além de aumentar os recursos, como o número de índices suportados por um cluster.

Quando se trata de como aumentar o desempenho do banco de dados, esse novo recurso aumenta nossa capacidade de oferecer suporte a ambientes multilocatários, reduzindo seu custo total de propriedade. Para saber mais sobre a implementação de escopos e coleções no Couchbase 7.0, confira este blog Como os escopos e as coleções simplificam as implantações de aplicativos multilocatários no Couchbase.

Dimensione sua infraestrutura adequadamente

Vindo de um ambiente relacional, muitas vezes me deparei com inúmeras restrições, como o fato de todos os dados e todos os vários componentes oferecidos pela plataforma estarem em um único servidor. Esta não é uma conversa sobre plataformas relacionais. No entanto, você provavelmente já está bem familiarizado com a necessidade de aumentar a escala, sabe como isso pode se tornar caro e entende como pode ser difícil rearquitetar e tentar aumentar a escala com essas plataformas.

É aqui que Escala multidimensional (MDS) chegou e imediatamente chamou minha atenção pelos motivos acima. Meus sistemas não eram mais limitados. Eu podia aumentar ou diminuir a escala apenas dos serviços que precisavam de mais potência. Se você nunca ouviu falar do MDS, dê uma lida rápida na documentação cujo link encontrei acima. O resumo é que ele permite que você instale vários serviços em várias máquinas. Você pode distribuí-los em todas as máquinas ou distribuí-los em máquinas dedicadas para cada serviço. Recomendo que máquinas dedicadas sejam usadas na produção, pois isso isola a carga de trabalho e garante que nenhuma parte do sistema afete negativamente outra. É claro que, para reduzir os custos, os ambientes que não são de produção, como desenvolvimento, controle de qualidade, pré-produção etc., podem ter recursos compartilhados.

Por que o isolamento é tão importante? Boa pergunta. Tudo se resume à maneira monolítica de fazer as coisas com tudo em uma única máquina e à dificuldade de utilizar os recursos compartilhados de maneira uniforme. Mesmo que você não tenha passado por isso com um banco de dados relacional, provavelmente já passou por isso com máquinas virtuais em que os recursos foram alocados em excesso e a CPU que você achava que tinha foi atribuída a outro lugar.

Ainda não está convencido? Se sim, compartilharei três problemas comuns que vi em centenas de ambientes nos últimos anos e que serão evitados com uma carga de trabalho isolada e distribuída.

Programação
O banco de dados relacional com o qual tenho mais experiência usa um agendador cooperativo. Ele cederá solicitações de CPU a outros processos para garantir que o sistema operacional possa fazer o que precisa fazer. Isso parece ótimo - meu banco de dados não manterá meu sistema operacional como refém - feliz dia! Bem, sim e não. O problema é que o cooperativo normalmente não distingue o que é do sistema operacional e de outros aplicativos de terceiros, principalmente porque o sistema operacional mudará com o tempo e adicionará novos processos.

O problema surge quando outros aplicativos são instalados de fornecedores diferentes ou, em alguns casos, do mesmo fornecedor de banco de dados. O mecanismo do banco de dados cederá quando esses outros aplicativos solicitarem tempo de CPU. Já vi vários sistemas esperando por períodos significativos de tempo pela CPU simplesmente porque outros aplicativos a solicitaram. É claro que o banco de dados é culpado, embora apenas obedeça às suas regras. O outro lado é que, se fosse uma arquitetura distribuída realmente isolada, esse problema nunca aconteceria.

Inchaço do cache
Em resumo, muitos fornecedores de bancos de dados criam uma área de memória chamada cache de plano ou cache de procedimento. A ideia é que a criação contínua do que geralmente é chamado de plano de execução ou de explicação consome muita CPU. Depois que um plano é criado, ele é colocado nessa área da memória. O problema surge quando essa área de memória é compartilhada na mesma máquina que armazena dados na memória para reduzir o tempo de acesso aos dados no disco.

O que pode acontecer (e isso será específico do banco de dados, pois alguns têm mais controles do que outros) é que o cache do plano/procedimento consome significativamente a quantidade de memória disponível. Isso significa que há pouca memória disponível para os dados e são necessárias mais viagens ao disco físico, o que resulta em aumento da latência e queda significativa da taxa de transferência.

Novamente, um sistema pode ser projetado para separar os nós de consulta e de dados com isolamento. Isso não significa apenas que a memória está separada, o que não aconteceria, mas que a CPU também está isolada - lembre-se de que eu disse que a criação de um plano consumia muita CPU.

Reconstrução de índices
Esse problema tem alguns pontos em comum com o cenário acima, mas usa partes diferentes dos vários mecanismos de banco de dados. Alguns mecanismos de banco de dados armazenam os dados e as páginas de índice no mesmo espaço de memória. Você provavelmente pode prever onde isso vai dar. Nem todo ambiente terá rotinas para desfragmentar os índices; como regra geral, você deve fazer isso durante os períodos que causem o mínimo de interrupção, pois os índices podem ser grandes e causar muito acesso ao disco e registro em log.

Por causa disso, já vi várias empresas realizarem a reconstrução do índice em um domingo, quando o sistema está mais silencioso. O problema é que a manhã de segunda-feira é uma das mais movimentadas, com muitas pessoas fazendo login ao mesmo tempo e querendo executar relatórios da semana anterior, talvez até do mês anterior, do trimestre ou anuais.

Por que isso é um problema? Bem, isso se refere novamente ao espaço de memória compartilhada. Para fins de argumentação, digamos que eu tenha atualmente 50% de índice e 50% de dados em meu cache de memória. O que acontecerá quando eu reconstruir todos os meus índices? A resposta simplista é que ele lerá os dados de cada tabela/documento e reconstruirá cada índice por vez.

Na verdade, é um pouco mais complexo. O resultado é que os dados que você tinha no cache antes do fim de semana não estão mais no cache na segunda-feira, quando todos esses relatórios urgentes são executados. Isso significa que o acesso lento ao disco puxa todos os índices e dados necessários para atender a essas solicitações. Novamente, com uma arquitetura isolada e distribuída, é possível se beneficiar de serviços separados em nós diferentes, o que significa que os dados necessários na memória ainda estão na memória.

Esses são apenas alguns dos benefícios da Enterprise Edition. Se você quiser considerar testando nosso software, entre em contato com nossos equipe de vendas. Se você já é um cliente e deseja garantir que tem o número correto de nós e que arquitetou as coisas corretamente, entre em contato com seu representante de vendas e engenheiro de vendas, que terão prazer em ajudar.

Usar declarações preparadas

Podemos dividir as consultas em duas categorias: mal escritas e altamente otimizadas. (Desculpe, não desculpe). Alguns de vocês podem estar pensando: "Espere aí, essa consulta é boa o suficiente". Sim, ela pode estar no seu conjunto de testes, mas quando se trata de como melhorar um banco de dados, você tem mais de 1.000 usuários prontos para testar como ela é dimensionada nesse sistema? Provavelmente não. Entende por que o monitoramento foi o primeiro item da lista agora?

Quando são necessários tempos de resposta de alta taxa de transferência e baixa latência, são necessários um bom modelo de dados e etiqueta de consulta. Já falamos sobre por que o Couchbase Enterprise Edition seria uma ótima opção e abordaremos a otimização de índices em seguida. Nesta seção, falaremos sobre consultas preparadas. Talvez seja algo novo para você, mas vale a pena aprender.

Como em tudo, há possíveis desvantagens em cada decisão que você toma. Certamente não estou sugerindo que você utilize instruções preparadas para todas as suas consultas SQL++. Você deve fazer a devida diligência para ver onde isso faz sentido.

A esta altura, você deve estar se perguntando: o que é uma declaração preparada? Bem, falamos um pouco sobre isso na última seção sobre Dimensionamento. Uma das otimizações que muitos fornecedores de bancos de dados adicionam aos seus produtos é salvar os planos de execução. Isso reduz o custo de ter de calculá-lo toda vez que for executado.

É possível fazer isso por meio do SDK e da CLI ou do Query Workbench. Os exemplos mostrados abaixo foram projetados para funcionar no Query Workbench.

Exemplo 1 - Uma declaração preparada, antes do Couchbase 7.0:

O Exemplo 1 mostra uma consulta simples que retorna todos os dados de cinco documentos de hotel. Se você só começou a usar o Couchbase 7.0 ou superior, não deve ter visto o atributo "type" antes. Ele era usado para identificar o tipo de documento que estava sendo usado. Ele foi eliminado com a introdução de escopos e coleções.

Exemplo 2 - Uma declaração preparada no Couchbase 7+, observe que você precisará definir o bucket como amostra de viagem e escopo para Inventário no Query Workbench:

O Exemplo 2 mostra uma consulta que será um pouco mais próxima de uma consulta do mundo real que você gostaria de preparar. Nesse caso, escolhemos cuidadosamente os atributos que desejamos retornar em vez de todos os atributos do documento. Também adicionamos mais predicados, incluindo um parâmetro e uma cláusula ORDER BY. Isso facilita o suporte à consulta com uma boa estratégia de indexação.

Embora esta postagem seja muito longa para abordar a modelagem de dados, pois é um assunto muito extenso por si só, quero fornecer alguns links para que você possa obter mais informações.

Para arquitetos, aqui está um curso rápido gratuito, CB131que aborda alguns conceitos básicos do Couchbase, incluindo modelagem de dados. Aqui está um curso mais aprofundado que você pode adquirir, CD212que se aprofunda na modelagem de dados e nas abordagens de consulta.

Otimizar índices

Criar os índices corretos geralmente é considerado arte em vez de ciência; a verdade é que provavelmente é um pouco dos dois. No entanto, vamos dar um passo atrás, pois talvez você nunca tenha usado ou mesmo ouvido falar de um índice antes.

Um índice é geralmente definido como uma cópia materializada de valores de dados de forma ordenada, permitindo que você encontre os dados de origem muito mais rapidamente. Há outros tipos, mas essa declaração serve para uma introdução. Se você tem idade suficiente para se lembrar de livros (coisas pesadas feitas de papel com palavras impressas), especialmente livros de não ficção, quase sempre havia algo chamado índice. O índice era uma seção no final do livro que continha uma lista de palavras (em ordem alfabética) com números de página associados. Isso permitia que o usuário procurasse uma seção específica sem ter que folhear o livro inteiro.

Essa é a mesma premissa de um índice de banco de dados, para fornecer outra cópia materializada dos dados com a capacidade de encontrar dados de forma eficiente sem incorrer em muita sobrecarga - nesse caso, sem ler mais documentos do que o necessário.

A indexação é um tópico vasto, e não podemos fazer justiça a ele aqui. Para facilitar as coisas, o Couchbase criou a função Consultor de índices para eliminar o esforço de criar o índice perfeito. Ele está disponível no Query Workbench ou você pode usar a função CONSELHO comando.

A ordem em que você adiciona os atributos ao índice e a cardinalidade deles (a exclusividade dos valores) podem afetar drasticamente o desempenho da consulta.

Para ajudar aqueles que desejam criar seus próprios índices, esta é a ordem em que você deve adicionar predicados e uniões:

1. IGUALDADE
2. IN
3. MENOS QUE
4. ENTRE
5. MAIOR DO QUE
6. Predicados de matriz
7. Procure adicionar campos adicionais para que o índice cubra a consulta

Na seção Use a versão mais recente do Couchbase Enterprise, abordamos o tópico de índices particionados. Sem dúvida, isso é algo a ser testado se você tiver índices mais significativos e vários nós de índice.

Outra técnica de aprimoramento do desempenho do banco de dados para aumentar o desempenho por meio da arquitetura de índices é a introdução de réplicas adicionais. Você pode adicionar até duas réplicas; cada réplica precisaria residir em um nó de índice separado. Isso forneceria três nós para ler os dados em vez de apenas um.

Esse é apenas um dos benefícios da arquitetura distribuída usada pelo Couchbase. Normalmente, os bancos de dados relacionais têm apenas uma cópia legível de um índice, o que pode causar um gargalo.

Recursos

Independentemente da maneira como você prefere aprender e do tempo que você tem ou não, você certamente pode se beneficiar da ideia compartilhada acima e dos links resumidos abaixo. Boa otimização!

• Guia de monitoramento do Couchbase
• Como criar painéis de observabilidade com o Prometheus, o Grafana e o Couchbase
• Como os escopos e coleções simplificam as implementações de aplicativos multilocatários no Couchbase
• Dimensionamento multidimensional 
• CB131: Curso de Certificação de Arquiteto Associado do Couchbase
• CD212: Curso de modelagem, consulta e pesquisa de dados NoSQL do Couchbase
• Consultor de índice do Couchbase
• Comparar diferentes edições do Couchbase