Playbook de prova de conceito do Spanner

Nesta página, apresentamos uma estratégia para planejar e executar uma prova de conceito (POC) com o Spanner. Ele oferece referências e insights detalhados sobre aspectos cruciais de um POC, como configuração de instância, design de esquema, carregamento de dados e avaliação de performance. Ele destaca etapas essenciais para avaliar os recursos do Spanner e ajuda a identificar possíveis riscos e benefícios relacionados à adoção do Spanner.

Além de validar os recursos técnicos do Spanner, um POC tem duas finalidades:

• Para ajudar você a entender os benefícios que o Spanner oferece para seu caso de uso
• Para ajudar você a identificar os riscos associados à adoção do Spanner

Uma POC do Spanner abrange várias facetas de avaliação, cada uma personalizada para atender aos seus objetivos comerciais e técnicos específicos, conforme mostrado no diagrama a seguir.

As diretrizes neste documento ajudam você a avaliar cada uma dessas áreas.

• Performance e escalonabilidade ajuda você a entender como o Spanner processa cargas de trabalho específicas, requisitos de latência e o impacto de várias configurações de instância. Esses testes podem demonstrar a capacidade do Spanner de escalonar sem problemas.

• Os recursos de monitoramento ajudam a avaliar se o Spanner fornece os insights necessários para operações de banco de dados eficazes. Essa avaliação inclui:

  • Opções para analisar planos de execução de consultas
  • Uso de recursos do sistema
  • Opções para configurar alertas

  Uma POC pode revelar lacunas que precisam ser abordadas para otimizar totalmente a eficiência operacional.

• Segurança e compliance são essenciais para determinar a adequação do Spanner à sua organização. Isso inclui avaliações para garantir que o Spanner possa reduzir os riscos de segurança e oferecer benefícios de compliance robustos, como os seguintes:

  • Opções de criptografia, como CMEK ou EKM para dados em trânsito e em repouso
  • Postura de controle de acesso de privilégio mínimo
  • Registro de auditoria
  • Obediência aos requisitos regulamentares

• Os recursos de backup e recuperação de desastres (DR) são essenciais para garantir a resiliência operacional e de dados. Uma POC pode validar os recursos de DR do Spanner, como recuperação pontual e disponibilidade.

• A viabilidade da migração envolve entender a complexidade da transição da sua solução de banco de dados atual para o Spanner. A avaliação da compatibilidade de esquemas, das ferramentas de migração e das mudanças de aplicativos ajuda a quantificar os investimentos necessários e determinar os riscos e benefícios da adoção do Spanner.

Durante a avaliação, talvez você queira conhecer o conjunto de recursos do Spanner para garantir que ele atenda aos requisitos funcionais do seu aplicativo. Isso pode incluir o teste da consistência global, dos recursos de consulta SQL ou da integração com outros serviços do Google Cloud.

As avaliações podem destacar os pontos fortes exclusivos do Spanner, como a consistência entre regiões, mas também podem mostrar possíveis riscos, como esforços de integração com a arquitetura de aplicativo atual.

Ciclo de vida das atividades de POC

Esta POC orienta você nas seguintes etapas. Siga as recomendações neste documento para configurar e avaliar o Spanner para seu caso de uso específico.

Planeje sua POC

A base de um POC bem-sucedido está na definição de metas claras e mensuráveis que se alinham às prioridades técnicas e de negócios. Evite objetivos vagos, como explorar o potencial do Spanner, porque eles geralmente levam a esforços sem foco e resultados ambíguos. Em vez disso, vincule as metas do POC a objetivos concretos, como alcançar 99,999% de disponibilidade, reduzir o tempo de inatividade ou escalonar para lidar com um aumento de 200% na taxa de transferência, mantendo as latências de transação abaixo de 20 ms.

A arquitetura exclusiva do Spanner é ideal para cargas de trabalho que exigem escalonabilidade massiva. Portanto, avaliar a escalonabilidade para seu caso de uso é um bom ponto de partida. Os cenários de teste precisam incluir:

• Como lidar com cargas operacionais típicas
• Como gerenciar picos de tráfego
• Reduzir a escala com eficiência

Esses testes ajudam você a entender como o Spanner funciona em diferentes condições e se ele atende aos seus requisitos técnicos de escalonabilidade. Metas específicas e práticas não apenas ajudam a estruturar a POC, mas também criam uma base sólida para avaliar o sucesso.

Definir uma rubrica de avaliação quantificada

Uma rubrica com métricas claras e mensuráveis e critérios de sucesso discretos é essencial para concluir se o POC atingiu os objetivos. Por exemplo, em vez de testar apenas a performance, especifique também metas como:

• Atender a QPS (consultas por segundo) específicas de nível de produção
• Manter latências abaixo de 20 ms em cargas de pico predefinidas
• Lidar com bursts de tráfego claramente definidos sem degradação de desempenho

Critérios bem definidos ajudam você a avaliar o Spanner de forma objetiva para sua carga de trabalho e fornecem insights úteis para as próximas etapas. Seja específico e defina metas de percentil para a latência de operações de leitura e gravação (como p50 e p95). Uma definição clara de limites de latência aceitáveis ajuda a projetar testes de desempenho do Spanner que se alinham às necessidades da sua empresa.

Um exemplo de rubrica de avaliação pode ser semelhante a este:

Facet de avaliação	Critérios de sucesso
Disponibilidade	99,999%
Segurança	CMEK com um EKM obrigatório
Garantia de objetivo do ponto de recuperação (RPO) em caso de interrupção regional	0
Limite de latência para as transações mais críticas	p50 abaixo de 20 ms
Latência para nossas consultas mais importantes voltadas ao usuário	p50 abaixo de 100 ms
Escalonabilidade	Demonstrar que é possível aumentar de 10.000 transações por segundo para 100.000 transações por segundo com latência p50 abaixo de 20 ms ao longo de uma hora

Definir o escopo dos casos de avaliação

Uma POC não exige uma migração em grande escala. Em vez disso, concentre-se em testar cargas de trabalho representativas ou componentes críticos do seu sistema. Por exemplo, identifique consultas principais, formas de transação críticas ou fluxos de trabalho específicos orientados por dados que são essenciais para suas operações. Reduza o escopo para diminuir a complexidade e garantir que os resultados sejam relevantes e significativos. Essa abordagem oferece uma maneira gerenciável de avaliar os recursos do Spanner sem se perder nas complexidades de uma migração completa do sistema.

Escolher uma configuração de instância do Spanner

Ao criar uma instância do Spanner para fins de avaliação, escolha uma configuração de instância que atenda aos requisitos de negócios para localização geográficae SLA de disponibilidade de serviço. O Spanner oferece várias configurações, incluindo região única, multirregional e birregional. Cada configuração foi projetada para atender a diferentes requisitos de latência, disponibilidade e redundância.

• As configurações de região única armazenam dados em uma região do Google Cloud, oferecendo baixa latência e custo-benefício. Essas topologias são ideais para cargas de trabalho que exigem redundância zonal intrarregional, oferecendo disponibilidade de 99,99%.
• As configurações birregionais replicam dados em duas regiões de um único país com uma réplica testemunha em cada região para failovers. Essa configuração oferece maior disponibilidade (99,999%) e tolerância a falhas do que uma configuração de região única. Essas topologias são adequadas para cargas de trabalho com conformidade rigorosa (como residência de dados) ou requisitos de proximidade geográfica.
• As configurações multirregionais replicam dados em várias regiões, garantindo alta disponibilidade e resiliência a interrupções regionais. Essas topologias são ideais para aplicativos que exigem georredundância com uma disponibilidade de até 99,999%.

Considerações sobre latência em instâncias entre regiões

Em configurações birregionais e multirregionais, a distribuição geográfica das réplicas do Spanner pode influenciar a latência. A latência de gravação depende da proximidade da região líder, que coordena as transações de leitura/gravação, e das outras regiões, que confirmam cada operação de gravação. Colocar os recursos de computação do aplicativo perto da região líder reduz os atrasos de ida e volta e minimiza a latência.

É possível modificar a região líder de um banco de dados para se alinhar às necessidades do seu aplicativo. Para operações somente leitura, o Spanner pode disponibilizar leituras desatualizadas da réplica mais próxima, reduzindo a latência. Já as leituras consistentes podem envolver a região líder, aumentando potencialmente a latência da operação. Para otimizar a latência em configurações multirregionais, escolha a região líder de forma estratégica, coloque os recursos de computação dos seus serviços na mesma região líder e aproveite as leituras desatualizadas para cargas de trabalho com muitas leituras.

Configurações que atendem aos requisitos do seu aplicativo

Ao selecionar uma configuração de instância para seu aplicativo, considere fatores como disponibilidade, latência e requisitos de residência de dados. Por exemplo, se o aplicativo exigir respostas de baixa latência para usuários em uma área geográfica específica, uma instância regional pode ser suficiente. No entanto, para aplicativos que exigem maior disponibilidade ou atendem usuários distribuídos globalmente, as configurações multirregionais são mais adequadas.

Comece com uma configuração que esteja alinhada aos requisitos de produção do aplicativo para avaliar o desempenho. Lembre-se de que a latência e os custos variam entre as configurações. Portanto, adapte seu ambiente de POC para refletir as necessidades do seu caso de uso. Para implantações multirregionais, simule a distribuição geográfica de serviços e teste a latência para garantir que a configuração esteja alinhada aos requisitos de produção. Para mais detalhes, consulte Orientações sobre o posicionamento de líderes multirregionais do Spanner.

Dimensionamento do Spanner

Provisione a capacidade de computação inicial para sua instância do Spanner e garanta que ela possa processar sua carga de trabalho de avaliação de maneira eficaz durante a POC. O tamanho inicial da instância precisa estar alinhado à carga de trabalho esperada, considerando a combinação de consultas de leitura e gravação por segundo (QPS), a complexidade da consulta e os níveis de simultaneidade.

Começar com uma proposição razoável permite estabelecer uma base e aumentar gradualmente com base na performance observada. Use as orientações de dimensionamento dos benchmarks de referência do Spanner para estabelecer uma configuração de instância de referência.

O dimensionamento durante uma POC precisa ser iterativo. Comece com uma configuração inicial, monitore as principais métricas, como latência e utilização da CPU, e ajuste a capacidade de computação atribuída conforme necessário. Isso garante que você possa validar a escalonabilidade e os recursos de desempenho do Spanner ao replicar condições semelhantes ao seu ambiente de produção.

Padrões típicos de carga de trabalho, como tráfego consistente x demanda flutuante, devem influenciar sua abordagem de dimensionamento. Quando você ativa o escalonamento automático, o Spanner provisiona dinamicamente a capacidade de recursos de computação para corresponder à intensidade da carga de trabalho.

Design de esquema

O design do esquema é um aspecto fundamental de uma POC do Spanner porque a forma como você organiza os dados pode afetar diretamente o desempenho e a escalonabilidade.

Um esquema bem projetado é fundamental para demonstrar os recursos do Spanner em um POC. Os testes de carga geralmente revelam possíveis gargalos ou ineficiências, informando refinamentos iterativos que criam um esquema ideal.

Design para escalonabilidade

Ao criar um esquema de banco de dados para o Spanner, é essencial considerar a arquitetura distribuída dele. Confira algumas considerações e otimizações importantes:

• Chaves primárias:escolha chaves primárias que distribuam os dados de maneira uniforme no espaço de chaves, evitando chaves que aumentam constantemente, como carimbos de data/hora, que podem causar pontos de acesso nas divisões.
• Índices:crie índices para otimizar o desempenho das consultas, mas sem se esquecer do impacto deles no desempenho de gravação e nos custos de armazenamento. Muitos índices ou índices mal planejados podem gerar sobrecarga desnecessária.
• Intercalação de tabelas:use a intercalação de tabelas para otimizar padrões de acesso para dados relacionados. Isso pode reduzir a comunicação entre processos e melhorar a eficiência da consulta.

Consulte as práticas recomendadas de design do esquema do Spanner para evitar armadilhas comuns e criar um esquema que ofereça alto desempenho e escalonabilidade.

É possível criar um esquema de rascunho no console do Google Cloud , conforme mostrado na imagem a seguir.

Migração de esquema com a ferramenta de migração do Spanner

A ferramenta de migração do Spanner (SMT) pode simplificar a criação de esquemas ao migrar de bancos de dados relacionais, incluindo MySQL ou PostgreSQL. O SMT automatiza a geração de esquemas e inclui otimizações básicas, como sugestões de índices e ajustes de esquema. Embora o SMT ofereça um bom ponto de partida, muitas vezes são necessários refinamentos manuais para alinhar o esquema aos seus casos de uso ou padrões de carga de trabalho específicos.

Usar um processo iterativo de design de esquema

Embora um esquema inicial forneça um ponto de partida, é improvável que ele seja perfeito. A criação de um esquema para um POC não é uma tarefa única, mas um processo iterativo que evolui à medida que você recebe insights dos testes. Um esquema robusto é essencial para o desempenho do aplicativo. Para isso, é necessário um design inicial bem pensado, o uso de ferramentas como o SMT e o refinamento iterativo com base nos resultados dos testes de carga. Seguindo esse processo, você garante que seu esquema atenda às demandas do aplicativo. Você também vai aprender a aproveitar ao máximo os recursos do Spanner.

Carregamento de dados

Para uma POC do Spanner bem-sucedida, é necessário carregar dados representativos no banco de dados para validar o design do esquema e simular fluxos de trabalho de aplicativos. Há várias ferramentas recomendadas que podem simplificar esse processo. Para carregar seus próprios dados, o Spanner oferece as seguintes opções:

• A extração, transformação e carregamento (ETL) reversos do BigQuery para o Spanner é um mecanismo de carregamento de dados integrado e fácil de usar que permite usar transformações baseadas em SQL para carregar dados no Spanner. Esse método é ideal para uma ampla variedade de formatos de dados, incluindo dados semiestruturados, como JSON.
• Para bancos de dados relacionais, como MySQL e PostgreSQL, a ferramenta de migração do Spanner (SMT) automatiza a criação de esquemas, o mapeamento de tipos de dados e o carregamento de dados em massa.
• Para formatos de arquivo simples, o Google oferece modelos do Dataflow de CSV para Spanner e Avro para Spanner para criar definições de esquema manuais para carregamento de dados em massa. Para bancos de dados compatíveis com JDBC, o Google oferece o modelo do Dataflow JDBC para Spanner.

Para mais informações sobre essas opções, consulte Usar seus próprios dados.

Se não houver dados de amostra disponíveis, use ferramentas de geração de dados sintéticos, como JMeter do Machmeter e QuickPerf, para criar conjuntos de dados personalizados para seu esquema e caso de uso. Para mais informações, consulte Gerar dados de amostra.

Use seus próprios dados

Se você tiver dados de amostra disponíveis que quer usar para o POC, há várias opções para carregar esses dados no Spanner.

Origem	Ferramenta	Criação de esquema	Transformações	Tamanho dos dados
MySQL	SMT	automático	Somente conversão de tipo de dados	pequeno
PostgreSQL	SMT	automático	Somente conversão de tipo de dados	pequeno
Qualquer JDBC	JDBC para Spanner	manual	Somente conversão de tipo de dados	grande
CSV	CSV para Spanner	manual	Somente conversão de tipo de dados	grande
	ETL reverso do BigQuery	manual	Transformações complexas aceitas	grande
Avro	Avro para Spanner	manual	Somente conversão de tipo de dados	grande
	ETL reverso do BigQuery	manual	Transformações complexas aceitas	grande
JSON	ETL reverso do BigQuery	manual	Transformações complexas aceitas	grande

ETL reverso do BigQuery para o Spanner

Com o ETL reverso do BigQuery para o Spanner, é possível ingerir rapidamente uma ampla variedade de fontes de dados e transformá-las em tabelas do BigQuery usando SQL. Depois, é possível exportar dados da tabela do BigQuery para uma tabela do Spanner. Ele é especialmente útil para dados semiestruturados, como JSON, que geralmente são exportados de fontes de dados NoSQL. Embora o BigQuery tenha detecção automática de esquema, a criação de esquema do Spanner é manual, exigindo que você defina o esquema antes de carregar os dados.

Ferramenta de migração do Spanner

Para iniciar seu POC, use a ferramenta de migração do Spanner (SMT) para migrar dados de fontes MySQL e PostgreSQL para o Spanner. O SMT automatiza o processo de criação de esquema, mapeando tipos de dados do banco de dados de origem para os tipos equivalentes no Spanner. Ele também faz recomendações de otimização de esquema específicas do Spanner. Isso o torna particularmente útil para migrações simples em que a conversão automática de esquema é suficiente.

O SMT oferece uma interface do usuário que orienta você no processo de migração. Durante esse processo, você seleciona o banco de dados de origem e analisa as recomendações e opções de design do esquema.

Modelos do Dataflow

O Dataflow é um serviço totalmente gerenciado projetado para processamento de dados escalonável, o que o torna uma opção adequada para carregar grandes quantidades de dados.

O Google oferece os seguintes modelos de código aberto para padrões de carregamento comuns:

• O CSV para Spanner carrega dados de arquivos CSV armazenados no Cloud Storage para o Spanner.
• Avro para Spanner carrega arquivos de dados Avro do Cloud Storage.
• O JDBC para Spanner carrega dados de bancos de dados compatíveis com JDBC.

Cada um desses modelos exige que você crie manualmente o esquema do Spanner antes de iniciar o carregamento de dados.

O Dataflow faz escalonamento horizontal automático para acomodar conjuntos de dados de qualquer tamanho, garantindo a ingestão de dados de alta performance no Spanner, mesmo para conjuntos de dados da ordem de terabytes. Essa escalonabilidade é fornecida às custas de algumas compensações:

• Os pipelines do Dataflow exigem configuração manual para definir o esquema, o mapeamento de dados e os parâmetros de execução para uma execução ideal.
• O Dataflow oferece a flexibilidade e a capacidade necessárias para migrações de dados em grande escala, mas pode exigir mais esforço para configurar e gerenciar do que outras ferramentas.

Gerar dados de amostra

Se você não tiver dados de exemplo, mas tiver um caso de uso específico em mente, poderá modelar o esquema com base nos seus requisitos e usar ferramentas para gerar conjuntos de dados representativos. Com elas, é possível preencher o Spanner com dados significativos para validar o design do esquema e os fluxos de trabalho do aplicativo.

JMeter do Machmeter

O JMeter do Machmeter fornece exemplos que usam o JMeter para gerar dados de amostra para o Spanner. O foco do Machmeter em exemplos orientados a casos de uso o torna um ótimo ponto de partida para gerar padrões de dados estruturalmente semelhantes ao esquema de produção esperado. Os exemplos fornecidos incluem scripts para inserções em massa e outras operações. É possível adaptar os scripts para gerar conjuntos de dados sintéticos em grande escala. Para mais informações, consulte o repositório ou a documentação do Machmeter.

QuickPerf

O QuickPerf é distribuído com o driver JDBC do Spanner. O QuickPerf fornece scripts baseados em SQL que criam rapidamente conjuntos de dados representativos para testar a integridade do esquema e o comportamento do banco de dados. Essa é uma opção de baixo esforço para gerar rapidamente conjuntos de dados pequenos a médios e menos complexos.

Teste de carga

Com o teste de carga, é possível observar a performance do Spanner ao processar cargas de trabalho para garantir que o banco de dados tenha a configuração ideal para demandas de produção. Duas ferramentas apresentadas anteriormente, o JMeter do Machmeter e o QuickPerf, são particularmente eficazes para simular cargas de trabalho e medir métricas de desempenho, como capacidade de processamento, latência e uso de recursos.

O Apache JMeter, aprimorado pelo projeto Machmeter, oferece um framework eficiente para testes de carga distribuída com o Spanner. O Machmeter inclui configurações pré-criadas do JMeter projetadas especificamente para simular cargas de trabalho do Spanner. Essas configurações podem ser personalizadas para executar consultas, transações e operações em lote representativas, permitindo medir a performance do Spanner em diferentes cenários.

A capacidade do JMeter de simular usuários e transações simultâneas o torna uma boa opção para testar a escalonabilidade e a capacidade de recuperação da sua instância do Spanner. É possível implantar o JMeter em um modo distribuído usando o Kubernetes ou o serviço gerenciado GKE para escalonar seu ambiente de teste. Os resultados oferecem insights sobre como o Spanner gerencia cargas de trabalho específicas, faz o escalonamento com o aumento da demanda e funciona durante picos de carga.

Para mais informações e exemplos de configurações, consulte o repositório do Machmeter.

O QuickPerf é uma ferramenta de comparativo de mercado leve criada para testes de performance com o Spanner. Ele se concentra em gerar métricas de performance com configuração mínima, permitindo que você itere rapidamente nas otimizações. O QuickPerf é fácil de configurar e é especialmente adequado para testes de menor escala e cenários em que você quer medir rapidamente o impacto na performance de otimizações específicas de esquema ou consulta.

Práticas recomendadas para testes de carga

Ao realizar testes de carga, é fundamental seguir as práticas recomendadas do Spanner para garantir resultados precisos e úteis.

• Período de aquecimento:aguarde um período de aquecimento (normalmente 30 minutos ou mais) para que o Spanner alcance um estado estável após o escalonamento de nós ou a introdução de uma nova carga de trabalho.
• Meça métricas relevantes:concentre-se em métricas como capacidade de processamento (operações por segundo), percentis de latência (por exemplo, p50, p95) e utilização da CPU para entender como o Spanner atende à sua carga de trabalho.
• Execute comparativos de longa duração:para resultados mais representativos, execute os testes de carga por períodos mais longos (por exemplo, mais de uma hora) para considerar comportamentos do sistema, como rebalanceamento e tarefas de manutenção em segundo plano.
• Testes de escalonamento:teste cenários de escalonamento vertical e horizontal para observar o comportamento do Spanner em diferentes configurações de nós e picos de carga.

Use ferramentas como JMeter Machmeter e QuickPerf, além de práticas recomendadas para teste de carga, para avaliar a performance do Spanner, identificar gargalos e otimizar seu banco de dados para atender às demandas da sua carga de trabalho.

Monitoramento

Para demonstrar de maneira eficaz a performance e a escalonabilidade do Spanner durante uma POC, especialmente sob carga, é necessário ter um conhecimento profundo das características operacionais dele. O Spanner oferece um conjunto abrangente de ferramentas de monitoramento e diagnóstico projetadas para fornecer insights detalhados sobre todos os aspectos da performance do seu banco de dados. Esse conjunto de ferramentas oferece vários recursos, desde painéis de métricas até tabelas detalhadas do sistema, que ajudam a identificar gargalos, validar escolhas de design e otimizar a performance.

Os insights do sistema oferecem observabilidade detalhada sobre o desempenho e a integridade operacional de uma instância do Spanner. Ele oferece métricas e insights em várias áreas, incluindo utilização da CPU, latência, capacidade de processamento e muito mais, em níveis ajustáveis de granularidade. Durante uma POC, esse é o ponto de partida para observar o comportamento do Spanner durante os testes. Com os insights do sistema, é possível identificar rapidamente gargalos de desempenho, como alta utilização da CPU ou aumento das latências de leitura ou gravação. Ele estabelece a base para investigações subsequentes.

O Query Insights oferece uma visão de cima para baixo da execução de consultas, começando com a identificação das consultas mais frequentes e caras com base em métricas como tempo de CPU, contagem de execução e latência média. Para ir mais fundo, o Query Insights permite examinar planos de execução detalhados, incluindo estatísticas de cada etapa da consulta, e identifica operações específicas que causam lentidão. Ele também oferece recursos que investigam tendências históricas de performance e comparam a performance de consultas em diferentes períodos. Isso ajuda a identificar regressões ou o impacto de mudanças no esquema e no código. Outras ferramentas, como o consultor de índice, analisam suas consultas para recomendar índices novos ou alterados que podem melhorar o desempenho delas.

Os insights de transação oferecem visibilidade da performance de transações com métricas detalhadas sobre latência, tempos de espera de confirmação, número de linhas e bytes lidos e gravados, além de participantes em transações distribuídas. Essas métricas revelam alta latência ou transações interrompidas e fornecem detalhes sobre as características delas. Durante um teste de carga de POC, os insights de transação são essenciais para avaliar a eficiência transacional do sistema sob estresse. Assim, é possível monitorar e identificar qualquer degradação à medida que a carga aumenta. A análise de transações individuais ajuda a identificar as causas de lentidão, como transações de longa duração bloqueando outras ou transações únicas lendo ou gravando volumes de dados excessivamente grandes. Com as informações dos insights de transação, é possível fazer ajustes direcionados, como otimizar os limites de transação, refinar consultas dentro das transações ou ajustar o esquema para reduzir a quantidade de dados envolvidos em transações típicas. Isso garante que o POC demonstre a capacidade do Spanner de manter a consistência transacional e o desempenho no nível de carga esperado.

Os insights de bloqueio oferecem visibilidade do comportamento de bloqueio de transações, ajudando a identificar e resolver problemas de contenção de bloqueios. Ele mostra informações sobre esperas de bloqueio, incluindo os intervalos de chave de linha específicos que estão causando o problema. Durante um teste de carga de prova de conceito, os insights de bloqueio são cruciais para identificar se os conflitos de bloqueio transacional estão causando limitações de escalonabilidade. À medida que a carga simultânea aumenta, as transações podem começar a competir para atualizar os mesmos dados, o que aumenta os tempos de espera e reduz a capacidade. Essas informações ajudam na otimização do esquema, na modificação do limite da transação e nos ajustes da lógica do aplicativo. Essas ações reduzem a disputa e garantem que o banco de dados do Spanner mantenha o desempenho sob a carga de trabalho projetada, evitando a degradação devido a mecanismos de bloqueio.

Os insights de ponto de acesso identificam gargalos de desempenho, especificamente o aumento da latência, que resultam de condições de ponto de acesso. Os pontos de acesso geralmente ocorrem quando há uma carga alta e desigual. Geralmente, a causa dos pontos de acesso são:

• Design de esquema abaixo do ideal
• Seleção de chave primária
• Padrões de acesso que concentram operações em um pequeno subconjunto de dados em vez de distribuí-las uniformemente entre os nós

Durante um teste de carga de POC, os insights sobre o uso excessivo dos pontos de acesso ajudam você a decidir onde otimizar seu esquema. Por exemplo, talvez seja necessário ajustar as chaves primárias ou modificar os índices secundários para evitar hotspots.

O Key Visualizer oferece uma representação visual dos padrões de uso do banco de dados ao longo do tempo em todo o espaço de chave de tabelas e índices. Ele gera mapas de calor que mostram a atividade de leitura e gravação, destacando áreas de alta intensidade e padrões potencialmente problemáticos. Durante uma POC, essa ferramenta ajuda a validar o design do esquema e identificar possíveis limitações de escalonabilidade. À medida que a carga aumenta, é possível observar como ela é distribuída no espaço de chaves e nas tabelas e índices correspondentes.

As tabelas de introspecção, principalmente o sistema de tabelas Spanner_SYS, fornecem muitas informações sobre o estado interno e a performance do banco de dados. Essas tabelas expõem estatísticas detalhadas sobre execução de consultas, comportamento de transações, disputa de bloqueios e detalhes do esquema. Durante um teste de carga de POC, essas tabelas de introspecção fornecem uma abordagem orientada por dados para diagnósticos de desempenho, além do que as ferramentas de insights mencionadas anteriormente oferecem. Por exemplo, é possível usá-los para resolver a causa raiz de conflitos de bloqueio no banco de dados que seriam difíceis de detectar e gerar insights úteis para otimização.

Otimização

O teste de carga é uma etapa essencial para identificar problemas de desempenho e possíveis gargalos na sua implementação do Spanner. Os insights obtidos com esses testes devem orientar os esforços de otimização no design do esquema, no comportamento das transações e na performance das consultas para garantir que o Spanner atenda às demandas da sua carga de trabalho.

Otimizar o design do esquema

Embora um design de esquema inicial seja informado pelas práticas recomendadas de escalonabilidade e performance, a execução de cargas de trabalho em condições reais geralmente revela áreas que precisam de refinamento. Os testes de carga fornecem insights valiosos sobre o desempenho do esquema em condições específicas, destacando problemas como hotspotting, distribuição desigual de dados ou ineficiências no desempenho da consulta.

A otimização se concentra no ajuste das seguintes áreas para se alinhar às características da carga de trabalho do aplicativo.

• Ajustes de chave primária:se os testes de carga revelarem pontos de acesso ou distribuição de dados desequilibrada, revise o design da chave primária. Por exemplo, adicione aleatoriedade no prefixo da chave para distribuir os dados de maneira mais uniforme entre os nós, preservando a eficiência da consulta.
• Refinamentos de índice:os testes de carga podem revelar se índices redundantes ou indexação excessiva estão afetando negativamente a capacidade de gravação. Remova índices desnecessários ou reestruture os atuais para melhorar a performance da consulta. Avalie a seletividade do índice e verifique se ela está alinhada aos padrões de consulta típicos.
• Tabelas e hierarquias intercaladas:analise se tabelas relacionadas podem se beneficiar da intercalação de tabelas para reduzir a latência de consulta. Ajuste as decisões de intercalação com base nos padrões de acesso observados durante o teste. Por outro lado, considere modelar essas tabelas separadamente se a estrutura hierárquica causar uma sobrecarga inesperada.

Para informações sobre como criar esquemas escalonáveis, consulte as práticas recomendadas de design de esquema do Spanner.

Otimizar consultas e semântica de transação

Os testes de carga geralmente destacam ineficiências na execução de transações e consultas, como alta contenção ou problemas de bloqueio. Otimize a semântica de transação e as estruturas de consulta para maximizar a capacidade de processamento e minimizar a latência:

• Modos de transação:use o modo de transação adequado para cada operação de carga de trabalho. Por exemplo, use transações somente leitura para consultas que não modificam dados ou DML particionada para atualizações e exclusões em massa.
• Lote: sempre que possível, use operações de gravação em lote para reduzir a sobrecarga causada por várias viagens de ida e volta.
• Otimização de consultas:refatore as consultas para incluir apenas as colunas e linhas necessárias, aproveite os índices e use parâmetros de consulta no aplicativo para reduzir a sobrecarga.

Para informações sobre estratégias de otimização, consulte a Visão geral das transações e as Práticas recomendadas de SQL.

Teste de carga iterativo

A otimização é um processo iterativo. Faça testes de carga após cada mudança significativa no esquema ou na consulta para validar melhorias e garantir que nenhum novo gargalo seja introduzido.

Simule cenários de aplicativos realistas com níveis variados de simultaneidade, tipos de transação e volumes de dados para confirmar se o Spanner funciona conforme o esperado em condições de pico e de estado estável.

Principais métricas a serem monitoradas

Acompanhe as principais métricas, como latência (p50, p99), capacidade de processamento e utilização da CPU durante a otimização.

A seguir

• Assista Como planejar e executar um contato de operações de parceiro do Spanner para aprender as etapas essenciais, as práticas recomendadas e as ferramentas necessárias para avaliar com eficácia os recursos do Spanner.