Práticas recomendadas para usar o Cloud Spanner como um banco de dados de jogos

Neste documento, descrevemos as práticas recomendadas para usar o Cloud Spanner como o principal banco de dados de back-end para armazenamento de estado de jogos. É possível usar o Cloud Spanner no lugar de bancos de dados comuns para armazenar dados de autenticação dos jogadores e dados de inventário. Este documento destina-se a engenheiros de back-end de jogos que trabalham em armazenamento de estado de longo prazo e operadores e administradores de infraestrutura de jogos compatíveis com o Google Cloud Platform (GCP).

Os jogos multijogador e on-line evoluíram para exigir estruturas de banco de dados cada vez mais complexas para rastrear direitos, estado e dados de inventário do jogador. Aumentar a base de jogadores e aumentar a complexidade do jogo levou a soluções de banco de dados que são um desafio de escalonamento e gerenciamento, exigindo frequentemente o uso de fragmentação ou de clustering (links em inglês). Manter o controle de itens valiosos no jogo ou do progresso mais relevante dos jogadores normalmente exige transações, e é um desafio trabalhar em muitos tipos de bancos de dados distribuídos.

O Cloud Spanner é o primeiro serviço de banco de dados escalonável de nível empresarial altamente consistente e globalmente distribuído criado para a nuvem a combinar os benefícios da estrutura de banco de dados relacional com a escala horizontal não relacional. Muitas empresas de jogos descobriram que é adequado substituir bancos de dados de estado e autenticação de jogos em sistemas em escala de produção. É possível escalonar para ter mais desempenho ou armazenamento usando o Console do GCP para adicionar nós. O Cloud Spanner pode lidar de forma transparente com a replicação global com consistência forte, eliminando a necessidade de gerenciar réplicas regionais.

Neste documento de práticas recomendadas, falamos sobre os itens a seguir:

  • Conceitos e diferenças importantes do Cloud Spanner em bancos de dados comumente usados em jogos
  • Quando o Cloud Spanner é o banco de dados certo para seu jogo
  • Padrões a serem evitados ao usar o Cloud Spanner para jogos
  • Como projetar suas operações de banco de dados com o Cloud Spanner como banco de dados do seu jogo
  • Como modelar seus dados e criando um esquema para conseguir o melhor desempenho com o Cloud Spanner

Terminologia

Direitos
Jogos, expansões ou compras em aplicativos pertencentes a um jogador.
Informações de identificação pessoal (PII, na sigla em inglês)
Em jogos, informações que normalmente incluem endereço de e-mail e dados da conta para pagamentos, como número de cartão de crédito e endereço de faturamento. Em alguns mercados, essas informações podem incluir um número de identificação nacional.
Banco de dados do jogo
Um banco de dados que mantém o progresso do jogador e o inventário de um jogo.
Banco de dados de autenticação
Um banco de dados que inclui os direitos do jogador e as PII que os jogadores usam quando fazem uma compra. O banco de dados de autenticação também é conhecido como banco de dados da conta ou banco de dados do jogador. Esse banco de dados às vezes é combinado com o banco de dados do jogo, mas eles são frequentemente separados em estúdios ou editores que têm vários títulos.
Transação
Uma transação de banco de dados: um conjunto de operações de gravação que têm um efeito de tudo ou nada. Ou a transação é bem-sucedida e todas as atualizações entram em vigor ou o banco de dados é retornado a um estado que não inclui nenhuma das atualizações da transação. Nos jogos, as transações do banco de dados são mais importantes ao processar pagamentos e ao atribuir a propriedade de um inventário ou moeda no jogo.
Sistema de gerenciamento de banco de dados relacional (RDBMS, na sigla em inglês)
Um sistema de banco de dados com base em tabelas e linhas que fazem referência mútua. SQL Server, MySQL e (menos comumente) Oracle® são exemplos de bancos de dados relacionais usados em jogos. Eles são frequentemente usados porque podem fornecer metodologias familiares e garantias fortes em relação a transações.
Banco de dados NoSQL
Bancos de dados que não são estruturados relacionalmente. Esses bancos de dados estão sendo mais usados em jogos porque têm muita flexibilidade quando o modelo de dados é alterado. Os bancos de dados NoSQL incluem o MongoDB e o Cassandra.
Chave primária
Normalmente, a coluna que contém o código exclusivo para itens de inventário, contas de jogadores e transações de compra.
Instância
Um único banco de dados. Por exemplo, um cluster executa várias cópias do software de banco de dados, mas aparece como uma única instância no back-end do jogo.
Para os propósitos deste documento, uma única máquina executando uma cópia do software de banco de dados.
Réplica
Uma segunda cópia de um banco de dados. As réplicas são usadas com frequência para recuperação de dados e alta disponibilidade ou para aumentar a capacidade de leitura.
Grupo
Várias cópias do software em execução em diversas máquinas que, juntas, aparecem como uma única instância no back-end do jogo. O cluster é usado para proporcionar escalonabilidade e disponibilidade.
Fragmento
Uma instância de um banco de dados. Muitos estúdios de jogos executam várias instâncias de banco de dados homogêneas, cada uma com um subconjunto dos dados do jogo. Cada uma dessas instâncias é chamada de fragmento. Geralmente, a fragmentação é feita para proporcionar desempenho ou escalonabilidade, sacrificando a eficiência do gerenciamento e aumentando a complexidade do aplicativo. A fragmentação no Cloud Spanner é implementada usando divisões.
Divisão
O Cloud Spanner divide seus dados em partes chamadas de divisões, em que divisões individuais podem se mover independentemente umas das outras e ser atribuídas a diferentes servidores. Uma divisão é definida como um intervalo de linhas em uma tabela de nível superior (em outras palavras, não intercalada), em que as linhas são ordenadas pela chave primária. As chaves de início e término desse intervalo são chamadas de "limites de divisão". O Cloud Spanner adiciona e remove automaticamente os limites de divisão, o que altera o número de divisões no banco de dados. O Cloud Spanner divide os dados com base na carga: ele adiciona limites de divisão automaticamente quando detecta alta carga de leitura ou gravação espalhada entre muitas chaves em uma divisão.
Ponto de acesso
Quando um único fragmento em um banco de dados distribuído, como o Cloud Spanner, contém registros que recebem uma grande parte de todas as consultas direcionadas ao banco de dados. Esse cenário não é desejável porque reduz o desempenho.

Como usar o Cloud Spanner para jogos

Na maioria dos casos em que você está considerando um RDBMS para seu jogo, o Cloud Spanner é uma opção apropriada porque pode substituir efetivamente o banco de dados do jogo, o banco de dados de autenticação ou, em muitos casos, ambos.

Bancos de dados do jogo

O Cloud Spanner pode operar como uma única autoridade transacional em todo o mundo, o que o torna uma excelente opção para sistemas de inventário de jogos. Qualquer moeda ou item no jogo que possa ser negociado, vendido, presenteado ou transferido de um jogador para outro apresenta um desafio em back-ends de jogos em larga escala. Frequentemente, a fama de um jogo pode ultrapassar a capacidade de um banco de dados tradicional de lidar com tudo em um sistema de nó único. Dependendo do tipo de jogo, o banco de dados pode ter dificuldades com o número de operações necessárias para lidar com a carga do jogador e a quantidade de dados armazenados. Isso geralmente leva os desenvolvedores de jogos a fragmentar o banco de dados para melhorar o desempenho ou para armazenar tabelas cada vez maiores. Esse tipo de solução gera complexidade operacional e grande sobrecarga de manutenção.

Para reduzir essa complexidade, uma estratégia comum é executar regiões de jogos completamente separadas, sem nenhuma maneira de mover dados entre elas. Nesse caso, itens e moedas não podem ser negociados entre jogadores em diferentes regiões do jogo, porque os estoques em cada região são separados em bancos de dados distintos. No entanto, essa configuração sacrifica a experiência preferida do jogador, em favor da simplicidade operacional e do desenvolvedor.

Por outro lado, é possível permitir transações entre regiões em um banco de dados geograficamente fragmentado, mas geralmente com alto custo de complexidade. Essa configuração requer que as transações abranjam várias instâncias de banco de dados, gerando uma lógica complexa do lado do aplicativo, propensa a erros. Tentar receber bloqueios de transação em vários bancos de dados pode ter impactos significativos no desempenho. Além disso, não poder confiar em transações atômicas pode levar os jogadores a se aproveitar das falhas, como duplicação da moeda ou dos itens. Isso prejudica o ecossistema e a comunidade do jogo.

O Cloud Spanner simplifica sua abordagem a transações de inventário e moedas. Mesmo ao usar o Cloud Spanner para armazenar todos os seus dados de jogos em todo o mundo, ele oferece transações de leitura e gravação com propriedades mais fortes do que as tradicionais de atomicidade, consistência, isolamento e durabilidade (ACID, na sigla em inglês). Com a escalonabilidade do Cloud Spanner, os dados não precisam ser fragmentados em instâncias separadas do banco de dados quando é necessário mais desempenho ou armazenamento. Em vez disso, basta adicionar nós. Além disso, a alta disponibilidade e a resiliência de dados para os quais os jogos costumam realizar o clustering dos bancos de dados são manipulados de forma transparente pelo Cloud Spanner, não exigindo configuração ou gerenciamento extra.

Bancos de dados de autenticação

Os bancos de dados de autenticação também podem ser bem atendidos pelo Cloud Spanner, especialmente se você quiser padronizar um único RDBMS no nível do seu estúdio ou editor. Embora os bancos de dados de autenticação para jogos muitas vezes não exijam a escala do Cloud Spanner, as garantias transacionais e a alta disponibilidade de dados podem torná-la atraente. A replicação de dados no Cloud Spanner é transparente, síncrona e integrada. O Cloud Spanner tem configurações que oferecem 99,99% ("quatro noves") ou 99,999% ("cinco noves") de disponibilidade, este último correspondente a menos de cinco minutos e meio de indisponibilidade em um ano. Esse tipo de disponibilidade o torna uma boa opção para o caminho de autenticação essencial exigido no início de cada sessão do jogador.

Práticas recomendadas

Nesta seção, fornecemos recomendações sobre como usar o Cloud Spanner no design de jogos. É importante modelar os dados do seu jogo para aproveitar os recursos exclusivos oferecidos pelo Cloud Spanner. É possível acessar o Cloud Spanner usando a semântica do banco de dados relacional, mas alguns pontos de design do esquema podem ajudar a aumentar seu desempenho. A documentação do Cloud Spanner tem recomendações detalhadas de design de esquema, mas as seções a seguir são algumas das práticas recomendadas para bancos de dados de jogos.

As práticas neste documento são baseadas em experiências de uso do cliente e estudos de caso.

Usar UUIDs como códigos de jogadores e personagens

A tabela de jogadores geralmente tem uma linha para cada jogador e a respectiva moeda, progresso ou outros dados no jogo que não são mapeados facilmente para as diferentes linhas da tabela do inventário. Se seu jogo permitir que os jogadores tenham um progresso salvo separado para vários personagens, como muitos jogos multijogador massivos e persistentes, essa tabela normalmente contém uma linha para cada personagem. O padrão é o mesmo.

Recomendamos usar um identificador de personagem ou de jogador (ID de personagem) globalmente exclusivo como a chave primária da tabela de personagens. Também recomendamos o uso do Identificador universalmente exclusivo (UUID, na sigla em inglês) v4 porque ele distribui os dados dos jogadores para os nós do banco de dados e pode ajudar você a conseguir mais desempenho com o Cloud Spanner.

Usar intercalação para tabelas de inventário

Muitas vezes, a tabela de inventário contém itens inseridos no jogo, como cards, unidades ou equipamentos de personagens. Normalmente, um único jogador tem muitos itens no inventário. Cada item é representado por uma única linha na tabela.

Semelhante a outros bancos de dados relacionais, uma tabela de inventário no Cloud Spanner tem uma chave primária que é um identificador global exclusivo para o item, conforme ilustrado na tabela a seguir.

itemID type playerID
7c14887e-8d45 1 6f1ede3b-25e2
8ca83609-bb93 40 6f1ede3b-25e2
33fedada-3400 1 5fa0aa7d-16da
e4714487-075e 23 5fa0aa7d-16da
d4fbfb92-a8bd 14 5fa0aa7d-16da
31b7067b-42ec 3 26a38c2c-123a

Na tabela de exemplo de inventário, itemID e playerID são truncados para facilitar a leitura. Uma tabela de inventário real também conterá muitas outras colunas que não estão incluídas no exemplo.

Uma abordagem típica em um RDBMS para controlar a propriedade do item é usar uma coluna como uma chave externa que contém o ID de jogador do proprietário atual. Essa coluna é a chave primária de uma tabela de banco de dados separada. No Cloud Spanner, é possível usar a intercalação, que armazena as linhas de inventário perto da linha da tabela do jogador associada para melhor desempenho. Ao usar tabelas intercaladas, tenha em mente o seguinte:

  • Você precisa manter o total de dados na linha do jogador e todas as linhas decrescentes de inventário dele abaixo de 2 GiB (aproximadamente). Essa restrição não é tipicamente um problema com um design de modelo de dados apropriado.
  • Não é possível gerar um objeto sem um proprietário. Evite objetos sem dono no design do jogo, desde que a limitação seja conhecida antecipadamente.

Indexação de design para evitar pontos de acesso

Muitos desenvolvedores de jogos implementam índices em muitos dos campos de inventário para otimizar certas consultas. No Cloud Spanner, criar ou atualizar uma linha com dados nesse índice gera uma carga de gravação adicional proporcional ao número de colunas indexadas. Melhore o desempenho do Cloud Spanner eliminando índices que não são usados com frequência ou implementando esses índices de outras maneiras que não afetem o desempenho do banco de dados.

No exemplo a seguir, existe uma tabela para registros de longo prazo referentes à maior pontuação do jogador:

CREATE TABLE Ranking (
        PlayerID STRING(36) NOT NULL,
        GameMode INT64 NOT NULL,
        Score INT64 NOT NULL
) PRIMARY KEY (PlayerID, GameMode)

Essa tabela contém o ID do jogador (UUIDv4), um número que representa um modo de jogo, estágio ou temporada, e a pontuação do jogador.

Para acelerar as consultas que filtram o modo de jogo, considere o índice a seguir:

CREATE INDEX idx_score_ranking ON Ranking (
        GameMode,
        Score DESC
)

Se todos jogarem o mesmo modo de jogo chamado 1, esse índice criará um ponto de acesso em que GameMode=1. Se você quiser ver uma classificação para esse modo de jogo, o índice só verificará as linhas que contêm GameMode=1, retornando a classificação rapidamente.

Se você alterar a ordem do índice anterior, poderá resolver esse problema de ponto de acesso:

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC,
        GameMode
)

Esse índice não cria um ponto de acesso significativo para os jogadores que competem no mesmo modo de jogo, desde que suas pontuações estejam distribuídas no intervalo possível. No entanto, conseguir pontuações não será tão rápido quanto com o índice anterior porque a consulta verifica todas as pontuações de todos os modos para determinar se GameMode=1.

Como resultado, o índice reordenado resolve o ponto de acesso anterior no modo de jogo, mas ainda tem espaço para melhorias, conforme ilustrado no design a seguir.

CREATE TABLE GameMode1Ranking (
        PlayerID STRING(36) NOT NULL,
        Score INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_score_ranking ON Ranking (
        Score DESC
)

Recomendamos mover o modo de jogo para fora do esquema da tabela e usar uma tabela por modo, se possível. Ao usar esse método, quando você recupera as pontuações de um modo, consulta apenas uma tabela com pontuações para esse modo. Essa tabela pode ser indexada por pontuação para rápida recuperação de intervalos de pontuação sem perigo significativo de pontos de acesso (desde que as pontuações sejam bem distribuídas). No momento da criação deste documento, o número máximo de tabelas por banco de dados no Cloud Spanner é 2.048, o que é mais do que suficiente para a maioria dos jogos.

Bancos de dados separados por locatário

Ao contrário de outras cargas de trabalho, em que recomendamos criar um design para multilocação no Cloud Spanner usando diferentes valores de chave primária, para dados de jogos, recomendamos a abordagem mais convencional de bancos de dados separados por locatário. As alterações de esquema são comuns com o lançamento de novos recursos em jogos com serviço ao vivo. O isolamento de locatários em um nível de banco de dados pode simplificar as atualizações de esquema. Essa estratégia também pode otimizar o tempo necessário para fazer backup ou restaurar os dados de um locatário, porque essas operações são executadas em um banco de dados inteiro de uma só vez.

Evitar atualizações incrementais de esquema

Ao contrário de alguns bancos de dados relacionais convencionais, o Cloud Spanner permanece operacional durante as atualizações de esquema. Todas as consultas no esquema antigo são retornadas (embora possam retornar menos rapidamente que o normal) e as consultas no novo esquema são retornadas à medida que se tornam disponíveis. É possível criar seu processo de atualização para manter seu jogo ativo durante as atualizações de esquema quando ele for executado no Cloud Spanner, desde que tenha em mente as restrições anteriores.

No entanto, se você solicitar outra alteração de esquema enquanto uma estiver sendo processada, a nova atualização ficará na fila e não ocorrerá até que todas as atualizações de esquema anteriores sejam concluídas. Evite essa situação planejando atualizações de esquema maiores, em vez de emitir muitas atualizações de esquema incrementais em um curto período. Para mais informações sobre atualizações de esquema, incluindo como realizar uma atualização de esquema que exija a validação de dados, consulte as atualizações de esquema do Cloud.

Considerar o tamanho e o acesso ao banco de dados

Ao desenvolver seus serviços de plataforma e servidor de jogos para usar o Cloud Spanner, considere como o jogo acessa o banco de dados e como dimensionar o banco de dados para evitar custos desnecessários.

Usar drivers e bibliotecas nativos

Ao desenvolver o Cloud Spanner, considere como o código interage com o banco de dados. O Cloud Spanner oferece bibliotecas de clientes nativas para muitas linguagens conhecidas, que geralmente são ricas em recursos e desempenho. Os drivers JDBC também estão disponíveis e oferecem suporte às instruções da linguagem de manipulação de dados (DML, na sigla em inglês) e da linguagem de definição de dados (DDL, na sigla em inglês). Nos casos em que o Cloud Spanner é usado em novos desenvolvimentos, recomendamos o uso das bibliotecas de cliente do Cloud para Cloud Spanner. As integrações típicas de mecanismos de jogos não têm muita flexibilidade na seleção de linguagens, mas, para os serviços de plataforma que acessam o Cloud Spanner, existem casos em que os clientes de jogos usam Java ou Go. Para aplicativos de alto rendimento, selecione uma biblioteca em que seja possível usar o mesmo cliente do Cloud Spanner para várias solicitações sequenciais.

Dimensionar o banco de dados para as necessidades de teste e produção

Durante o desenvolvimento, uma instância do Cloud Spanner de nó único provavelmente é suficiente para a maioria das atividades, incluindo testes funcionais.

Avaliar as necessidades do Cloud Spanner para produção

Quando você passa do desenvolvimento para o teste e depois para a produção, é importante reavaliar as necessidades do Cloud Spanner para garantir que o jogo possa lidar com o tráfego de jogadores ao vivo.

Antes de passar para a produção, os testes de carga são cruciais para verificar se o back-end pode lidar com a carga durante a produção. Recomendamos executar testes de carga com o dobro da carga esperada na produção para estar preparado para picos de uso e casos em que seu jogo fique mais famoso do que o previsto.

Executar testes de carga usando dados reais

Executar um teste de carga com dados sintéticos não é suficiente. Também é preciso executar testes de carga usando dados e padrões de acesso o mais próximos possível do que é esperado na produção. Os dados sintéticos podem não detectar possíveis pontos de acesso no design do esquema do Cloud Spanner. Nada é melhor do que executar um teste Beta (aberto ou fechado) com jogadores reais para verificar como o Cloud Spanner se comporta com os dados de verdade.

O diagrama a seguir é um exemplo de esquema de tabela de jogadores de um estúdio de jogos que ilustra a importância do uso de testes beta de carga.

Lista de nomes de jogadores e um atributo para teste de carga.

O estúdio preparou esses dados com base nas tendências de um jogo anterior que eles operaram por alguns anos. A empresa esperava que o esquema representasse bem os dados nesse novo jogo.

Cada registro de jogador tem alguns atributos numéricos associados a ele que acompanham o progresso do jogador no jogo (como classificação e tempo de jogo). Para o atributo de exemplo usado na tabela anterior, os novos jogadores recebem um valor inicial de 50 que muda para um valor entre 1 e 100 à medida que o jogador avança.

O estúdio quer indexar esse atributo para acelerar consultas importantes durante o jogo.

Com base nesses dados, o estúdio criou a seguinte tabela do Cloud Spanner, com uma chave primária usando o PlayerID e um índice secundário no Attribute.

CREATE TABLE Player (
        PlayerID STRING(36) NOT NULL,
        Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_attribute ON Player(Attribute)

O índice foi consultado para encontrar até 10 jogadores com Attribute=23, assim:

SELECT PlayerID
        FROM Player@{force_index=idx_attribute}
        WHERE Attribute = 23
        LIMIT 10

De acordo com a documentação sobre como otimizar o design do esquema, o Cloud Spanner armazena dados de índice da mesma maneira que as tabelas, com uma linha por entrada de índice. Nos testes de carga, esse modelo faz um trabalho aceitável de distribuir a carga de leitura e gravação do índice secundário entre várias divisões do Cloud Spanner, conforme ilustrado no diagrama a seguir:

Os jogadores distribuídos pelo Cloud Spanner são divididos por seus atributos.

Embora os dados sintéticos usados no teste de carga sejam semelhantes ao eventual estado estacionário do jogo, em que os valores de Attribute estão bem distribuídos, o design do jogo determina que todos os jogadores iniciem com Attribute=50. Como cada novo jogador começa com Attribute=50, quando novos jogadores entram, eles são inseridos na mesma parte do índice secundário idx_attribute. Isso significa que as atualizações são roteadas para a mesma divisão do Cloud Spanner, causando um ponto de acesso durante a janela de lançamento do jogo. Esse é um uso ineficaz do Cloud Spanner.

Jogadores no lançamento com o mesmo atributo, criando um ponto de acesso em uma única divisão do Cloud Spanner.

No diagrama a seguir, a adição de uma coluna IndexPartition ao esquema após o lançamento resolve o problema do ponto de acesso e os jogadores são distribuídos uniformemente pelas divisões disponíveis do Cloud Spanner. O comando atualizado para criar a tabela e o índice é semelhante a este:

CREATE TABLE Player (
        PlayerID STRING(36) NOT NULL,
        IndexPartition INT64 NOT NULL
        Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)

CREATE INDEX idx_attribute ON Player(IndexPartition,Attribute)

A adição de uma coluna IndexPartition ao esquema distribui uniformemente os jogadores no lançamento.

O valor IndexPartition precisa ter um intervalo limitado para consultas eficientes, mas também necessita ter um intervalo que seja pelo menos o dobro do número de divisões para uma distribuição eficiente.

Nesse caso, o estúdio atribui manualmente a cada jogador uma IndexPartition entre 1 e 6 no aplicativo de jogo.

É possível usar métodos alternativos para atribuir um número aleatório a cada jogador ou atribuir um valor derivado de um hash no valor PlayerID. Consulte O que os DBAs precisam saber sobre o Cloud Spanner, parte 1: chaves e índices para mais estratégias de fragmentação no nível do aplicativo.

A atualização da consulta anterior para usar esse índice aprimorado se parece com o seguinte:

SELECT PlayerID
        FROM Player@{force_index=idx_attribute}
        WHERE IndexPartition BETWEEN 1 and 6
        AND Attribute = 23
        LIMIT 10

Como nenhum teste Beta foi executado, o estúdio não percebeu que os testes tinham dados com suposições incorretas. Os testes de carga sintética são uma boa maneira de validar quantas consultas por segundo (QPS, na sigla em inglês) sua instância pode manipular, mas um teste Beta com jogadores reais é necessário para validar seu esquema e preparar um lançamento bem-sucedido.

Dimensionar o ambiente de produção para antecipar a demanda de pico

Geralmente, o pico de tráfego dos principais jogos ocorre no lançamento. A criação de um back-end escalonável não se aplica apenas aos serviços de plataforma e aos servidores de jogos dedicados, mas também aos bancos de dados. Usando as soluções do GCP, como o App Engine, é possível criar serviços de API de front-end que podem ser escalonados rapidamente. O Cloud Spanner oferece a flexibilidade de adicionar e remover nós on-line, mas ele não é um banco de dados com escalonamento automático. Você precisa provisionar nós suficientes para lidar com o pico de tráfego durante o lançamento.

Com base nos dados coletados durante o teste de carga ou em qualquer teste Beta público, é possível estimar o número de nós necessários para lidar com solicitações no lançamento. É recomendável adicionar alguns nós como buffer, caso você receba mais jogadores do que o esperado. Sempre dimensione o banco de dados de modo a não exceder um uso médio da CPU de 65%.

Pré-aquecer o banco de dados antes do lançamento

Uma outra coisa importante para preparar antes do lançamento é o aquecimento do banco de dados.

O Cloud Spanner em estado frio não pode fornecer os nós necessários para o lançamento sem primeiro ser aquecido.

O Cloud Spanner é um banco de dados distribuído, o que significa que, conforme seu banco de dados cresce, o Cloud Spanner separa seus dados em partes chamadas divisões. As divisões podem ser movimentadas independentemente entre si e atribuídas a servidores diferentes, que podem estar em locais físicos distintos. Para mais informações, consulte Divisões de banco de dados.

Uma divisão é definida como um intervalo de linhas. Em outras palavras, contém um subconjunto de sua tabela. O Cloud Spanner divide os dados com base na carga e no tamanho. Dessa forma, as divisões podem ser movidas dinamicamente nos nós do Cloud Spanner para equilibrar a carga geral no banco de dados. Quanto mais dados você inserir no Cloud Spanner, mais divisões serão geradas.

No diagrama a seguir, existem quatro nós.

Dados em um nó quando o Cloud Spanner está frio.

Como você não tem dados no Cloud Spanner, quando começa a gravar dados, só grava em um único nó. O Cloud Spanner está atualmente em um estado frio.

O diagrama a seguir ilustra a divisão para os outros nós.

Divisão de dados entre nós quando o Cloud Spanner está quente.

Conforme os dados entram no sistema, o Cloud Spanner começa a dividir esses dados para rebalancear a carga nos quatro nós provisionados. O Cloud Spanner está em um estado quente.

O ideal é lançar seu jogo quando o Cloud Spanner está em um estado quente, com divisões já equilibradas em todos os nós. Para aquecer seu banco de dados, siga estas etapas:

  1. Verifique se as chaves primárias da tabela geradas para o teste de carga estão no mesmo keyspace (têm as mesmas propriedades estatísticas) que as chaves que você está usando para o tráfego de produção real.
  2. Faça um teste de carga dois dias antes do lançamento. Execute o teste de carga por pelo menos uma hora no pico de carga esperado. O teste de carga faz com que o Cloud Spanner crie mais divisões devido à divisão com base em carga.
  3. Após a conclusão do teste de carga, é possível excluir as linhas geradas pelo teste de carga de suas tabelas, mas não as exclua. Isso mantém as divisões disponíveis para sua janela de lançamento.

Monitorar e entender o desempenho

Qualquer banco de dados de produção requer métricas abrangentes de monitoramento e desempenho. O Cloud Spanner vem com métricas integradas no Stackdriver. Sempre que possível, recomendamos incorporar as bibliotecas de gRPC fornecidas ao seu processo de back-end do jogo porque elas incluem o rastreamento do OpenCensus. Esse rastreamento permite ver traces de consulta no Stackdriver, bem como outras ferramentas de rastreamento de código aberto compatíveis.

No Stackdriver, é possível ver detalhes sobre o uso do Cloud Spanner, incluindo armazenamento de dados e uso de CPU. Para a maioria dos casos, recomendamos que você baseie as decisões de escalonamento do Cloud Spanner nessa métrica de uso de CPU ou na latência observada. Para mais informações sobre o uso sugerido de CPU para desempenho otimizado, consulte Práticas recomendadas para instâncias.

O Cloud Spanner oferece planos de execução de consulta. Analise esses planos no Console do GCP e entre em contato com o suporte se precisar de ajuda para entender o desempenho da sua consulta.

Ao avaliar o desempenho, mantenha os testes de ciclo curto no mínimo, porque o Cloud Spanner divide de maneira transparente seus dados em segundo plano para otimizar o desempenho com base nos padrões de acesso a dados. É preciso avaliar o desempenho usando cargas de consulta sustentadas e realistas.

Ao remover dados, excluir linhas em vez de recriar tabelas

Ao trabalhar com o Cloud Spanner, as tabelas recém-criadas ainda não tiveram a oportunidade de passar por divisão com base em carga ou em tamanho para melhorar o desempenho. Quando você exclui dados descartando uma tabela e recriando-a, o Cloud Spanner precisa de dados, consultas e tempo para determinar as divisões corretas da tabela. Se estiver planejando preencher novamente uma tabela com os mesmos tipos de dados (por exemplo, ao executar testes de desempenho consecutivos), poderá executar uma consulta DELETE nas linhas que contêm dados desnecessários. Pela mesma razão, as atualizações de esquema precisam usar a API Cloud Spanner fornecida e evitar uma estratégia manual, como criar uma nova tabela e copiar os dados de outra tabela ou um arquivo de backup.

Selecionar uma localidade de dados para atender aos requisitos de conformidade

Muitos jogos precisam cumprir as leis regionais de dados, como o GDPR, quando jogados em todo o mundo. Para atender às suas necessidades de GDPR, consulte o whitepaper sobre o GCP e GDPR e selecione a configuração regional correta do Cloud Spanner.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…