Este documento descreve as práticas recomendadas para usar o Spanner como a base de dados de back-end principal para o armazenamento do estado do jogo. Pode usar o Spanner em vez de bases de dados comuns para armazenar dados de autenticação de jogadores e dados de inventário. Este documento destina-se a engenheiros de back-end de jogos que trabalham no armazenamento de estado a longo prazo e a operadores e administradores de infraestrutura de jogos que suportam esses sistemas e estão interessados em alojar a respetiva base de dados de back-end noGoogle Cloud.
Os jogos online e multijogador evoluíram para exigir estruturas de base de dados cada vez mais complexas para monitorizar os direitos, o estado e os dados de inventário dos jogadores. O crescimento das bases de jogadores e o aumento da complexidade dos jogos levaram a soluções de bases de dados que são um desafio para dimensionar e gerir, o que requer frequentemente a utilização de divisão ou agrupamento. Normalmente, o acompanhamento de itens valiosos no jogo ou do progresso crítico do jogador requer transações e é difícil de contornar em muitos tipos de bases de dados distribuídas.
O Spanner é o primeiro serviço de base de dados escalável, de nível empresarial, distribuído globalmente e fortemente consistente criado para a nuvem para combinar as vantagens da estrutura de base de dados relacional com a escala horizontal não relacional. Muitas empresas de jogos consideraram que é adequado para substituir as bases de dados de autenticação e de estado do jogo em sistemas de escala de produção. Pode dimensionar para um desempenho ou armazenamento adicional através da Google Cloud consola para adicionar nós. O Spanner pode processar de forma transparente a replicação global com consistência forte, eliminando a necessidade de gerir réplicas regionais.
Este documento de práticas recomendadas aborda o seguinte:
- Conceitos importantes do Spanner e diferenças em relação às bases de dados usadas habitualmente em jogos.
- Quando o Spanner é a base de dados certa para o seu jogo.
- Padrões a evitar quando usa o Spanner para jogos.
- Conceber as operações da base de dados com o Spanner como base de dados do jogo.
- Modelar os seus dados e criar um esquema para obter o melhor desempenho com o Spanner.
Terminologia
- Concessões
- Jogos, expansões ou compras na app pertencentes a um jogador.
- Informações de identificação pessoal (IIP)
- Em jogos, informações que incluem normalmente o endereço de email e informações da conta de pagamento, como um número de cartão de crédito e uma morada de faturação. Em alguns mercados, estas informações podem incluir um número de identificação nacional.
- Base de dados de jogos (BD de jogos)
- Uma base de dados que contém o progresso e o inventário dos jogadores de um jogo.
- Base de dados de autenticação (BD de autenticação)
- Uma base de dados que inclui os direitos dos jogadores e as IPI que os jogadores usam quando fazem uma compra. A base de dados de autorização também é conhecida como base de dados da conta ou base de dados do jogador. Por vezes, esta base de dados é combinada com a base de dados do jogo, mas são frequentemente separadas em estúdios ou editoras que têm vários títulos.
- Transação
- Uma transação de base de dados: um conjunto de operações de escrita que têm um efeito de tudo ou nada. A transação é bem-sucedida e todas as atualizações entram em vigor, ou a base de dados é devolvida a um estado que não inclui nenhuma das atualizações da transação. Nos jogos, as transações de base de dados são mais críticas quando processam pagamentos e quando atribuem a propriedade de inventário ou moeda valiosos no jogo.
- Sistema de gestão de base de dados relacional (RDBMS)
- Um sistema de base de dados baseado em tabelas e linhas que fazem referência umas às outras. O SQL Server, o MySQL e (menos frequentemente) o Oracle® são exemplos de bases de dados relacionais usadas em jogos. São frequentemente usadas porque podem fornecer metodologias familiares e fortes garantias em torno das transações.
- Base de dados NoSQL (base de dados NoSQL)
- Bases de dados que não estão estruturadas de forma relacional. Estas bases de dados estão a tornar-se mais populares nos jogos porque têm muita flexibilidade quando o modelo de dados muda. As bases de dados NoSQL incluem o MongoDB e o Cassandra.
- Chave principal
- Normalmente, a coluna que contém o ID exclusivo dos artigos de inventário, das contas de jogadores e das transações de compra.
- Instância
- Uma única base de dados. Por exemplo, um cluster executa várias cópias do software de base de dados, mas aparece como uma única instância para o back-end do jogo.
- Nó
- Para efeitos deste documento, uma única máquina que executa uma cópia do software de base de dados.
- Réplica
- Uma segunda cópia de uma base de dados. As réplicas são usadas frequentemente para a recuperação de dados e a alta disponibilidade, ou para ajudar a aumentar a taxa de transferência de leitura.
- Cluster
- Várias cópias do software em execução em várias máquinas que, em conjunto, aparecem como uma única instância no back-end do jogo. O clustering é usado para escalabilidade e disponibilidade.
- Fragmento
- Uma instância de uma base de dados. Muitos estúdios de jogos executam várias instâncias de base de dados homogéneas, cada uma das quais contém um subconjunto dos dados do jogo. Cada uma destas instâncias é frequentemente denominada fragmento. Normalmente, a divisão em partições é feita para melhorar o desempenho ou a escalabilidade, sacrificando a eficiência da gestão e aumentando a complexidade da app. A fragmentação no Spanner é implementada através de divisões.
- Espargata
- O Spanner divide os seus dados em partes denominadas divisões, em que as divisões individuais podem mover-se independentemente umas das outras e ser atribuídas a servidores diferentes. Uma divisão é definida como um intervalo de linhas numa tabela de nível superior (por outras palavras, não intercalada), em que as linhas são ordenadas pela chave principal. As chaves de início e fim deste intervalo são denominadas "limites de divisão". O Spanner adiciona e remove automaticamente limites de divisão, o que altera o número de divisões na base de dados. O Spanner divide os dados com base na carga: adiciona limites de divisão automaticamente quando deteta uma carga de leitura ou escrita elevada distribuída por muitas chaves numa divisão.
- Zona Wi-Fi
- Quando uma única divisão numa base de dados distribuída, como o Spanner, contém registos que recebem uma grande parte de todas as consultas dirigidas à base de dados. Este cenário é indesejável porque degrada o desempenho.
Usar o Spanner para jogos
Na maioria dos casos em que está a considerar um SGBDR para o seu jogo, o Spanner é uma escolha adequada porque pode substituir eficazmente a BD do jogo, a BD de autorização ou, em muitos casos, ambas.
DBs de jogos
O Spanner pode funcionar como uma única autoridade transacional mundial, o que o torna uma excelente opção para sistemas de inventário de jogos. Qualquer moeda ou item no jogo que possa ser trocado, vendido, oferecido ou de outra forma transferido de um jogador para outro apresenta um desafio em backends de jogos de grande escala. Muitas vezes, a popularidade de um jogo pode ultrapassar a capacidade de uma base de dados tradicional para processar tudo numa base de dados de nó único. Consoante o tipo de jogo, a base de dados pode ter dificuldades com o número de operações necessárias para processar a carga de jogadores, bem como a quantidade de dados armazenados. Isto leva frequentemente os programadores de jogos a dividir a base de dados para melhorar o desempenho ou a armazenar tabelas em constante crescimento. Este tipo de solução leva a uma complexidade operacional e a uma sobrecarga de manutenção elevada.
Para ajudar a mitigar esta complexidade, uma estratégia comum é executar regiões de jogos completamente separadas sem forma de mover dados entre elas. Neste caso, não é possível negociar itens nem moedas entre jogadores em diferentes regiões do jogo, porque os inventários em cada região estão separados em bases de dados distintas. No entanto, esta configuração sacrifica a experiência do jogador preferida em favor da simplicidade operacional e do programador.
Por outro lado, pode permitir transações entre regiões numa base de dados dividida geograficamente, mas, muitas vezes, a um custo de complexidade elevado. Esta configuração requer que as transações abranjam várias instâncias da base de dados, o que leva a uma lógica complexa e propensa a erros do lado da aplicação. A tentativa de obter bloqueios de transações em várias bases de dados pode ter impactos significativos no desempenho. Além disso, não poder confiar em transações atómicas pode levar a explorações por parte dos jogadores, como a duplicação de moeda ou itens no jogo, o que prejudica o ecossistema e a comunidade do jogo.
O Spanner pode simplificar a sua abordagem às transações de inventário e moeda. Mesmo quando usa o Spanner para armazenar todos os dados do seu jogo a nível mundial, oferece transações de leitura/escrita com propriedades mais fortes do que a atomicidade, a consistência, o isolamento e a durabilidade (ACID) convencionais. Com a escalabilidade do Spanner, os dados não precisam de ser divididos em instâncias de base de dados separadas quando é necessário mais desempenho ou armazenamento. Em alternativa, pode adicionar mais nós. Além disso, a elevada disponibilidade e a resiliência dos dados para os quais os jogos agrupam frequentemente as respetivas bases de dados são processadas de forma transparente pelo Spanner, não sendo necessária configuração nem gestão adicionais.
BDs de autenticação
As bases de dados de autenticação também podem ser bem servidas pelo Spanner, especialmente se quiser padronizar um único SGBDR ao nível do estúdio ou do publicador. Embora as bases de dados de autenticação para jogos não exijam frequentemente a escala do Spanner, as garantias transacionais e a elevada disponibilidade de dados podem torná-lo apelativo. A replicação de dados no Spanner é transparente, síncrona e incorporada. O Spanner tem configurações que oferecem 99,99% ("quatro noves") ou 99,999% ("cinco noves") de disponibilidade, com "cinco noves" a corresponder a menos de cinco minutos e meio de indisponibilidade num ano. Este tipo de disponibilidade torna-o uma boa escolha para o caminho de autenticação crítico necessário no início de cada sessão do leitor.
Práticas recomendadas
Esta secção fornece recomendações sobre como usar o Spanner no design de jogos. É importante modelar os dados do jogo para tirar partido das funcionalidades únicas oferecidas pelo Spanner. Embora possa aceder ao Spanner através da semântica de base de dados relacional, alguns pontos de design de esquemas podem ajudar a aumentar o desempenho. A documentação do Spanner tem recomendações detalhadas de design de esquemas que pode rever, mas as secções seguintes são algumas práticas recomendadas para bases de dados de jogos.
As práticas neste documento baseiam-se em experiências de utilização por parte dos clientes e estudos de caso.
Use UUIDs como IDs de jogadores e personagens
Normalmente, a tabela de jogadores tem uma linha para cada jogador e a respetiva moeda no jogo, progresso ou outros dados que não são facilmente mapeados para linhas discretas da tabela de inventário. Se o seu jogo permitir que os jogadores tenham um progresso guardado separado para vários personagens, como muitos jogos multijogador massivos persistentes de grande escala, esta tabela contém normalmente uma linha para cada personagem. O padrão é igual.
Recomendamos que use um identificador de jogador ou personagem globalmente único (ID da personagem) como a chave principal da tabela de personagens. Também recomendamos a utilização do identificador exclusivo universal (UUID) v4, porque distribui os dados dos jogadores pelos nós da base de dados e pode ajudar a melhorar o desempenho do Spanner.
Use a intercalação para tabelas de inventário
A tabela de inventário contém frequentemente itens no jogo, como equipamento de personagens, cartas ou unidades. Normalmente, um único jogador tem muitos artigos no seu inventário. Cada item é representado por uma única linha na tabela.
Semelhante a outras bases de dados relacionais, uma tabela de inventário no Spanner tem uma chave principal que é um identificador único global para o item, conforme ilustrado na tabela seguinte.
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 inventário de exemplo, itemID e playerID são truncados para facilitar a leitura. Uma tabela de inventário real também conteria muitas outras colunas que não estão incluídas no exemplo.
Uma abordagem típica num SGBDR para acompanhar a propriedade de itens é usar uma coluna como uma chave externa que contém o ID do jogador do proprietário atual. Esta coluna é a chave principal de uma tabela de base de dados separada. No Spanner, pode usar a intercalação, que armazena as linhas de inventário perto da linha da tabela de jogadores associada para um melhor desempenho. Quando usar tabelas intercaladas, tenha em atenção o seguinte:
- Não pode gerar um objeto sem um proprietário. Pode evitar objetos sem proprietário no design do jogo, desde que a limitação seja conhecida antecipadamente.
Crie a indexação para evitar hotspots
Muitos programadores de jogos implementam índices em muitos dos campos de inventário para otimizar determinadas consultas. No Spanner, a criação ou a atualização de uma linha com dados nesse índice gera uma carga de escrita adicional proporcional ao número de colunas indexadas. Pode melhorar o desempenho do Spanner eliminando índices que não são usados com frequência ou implementando estes índices de outras formas que não afetem o desempenho da base de dados.
No exemplo seguinte, existe uma tabela para os recordes de pontuação máxima de jogadores a longo prazo:
CREATE TABLE Ranking (
PlayerID STRING(36) NOT NULL,
GameMode INT64 NOT NULL,
Score INT64 NOT NULL
) PRIMARY KEY (PlayerID, GameMode)
Esta tabela contém o ID do jogador (UUIDv4), um número que representa um modo de jogo, uma fase ou uma temporada, e a pontuação do jogador.
Para acelerar as consultas que filtram o modo de jogo, considere o seguinte índice:
CREATE INDEX idx_score_ranking ON Ranking (
GameMode,
Score DESC
)
Se todos jogarem o mesmo modo de jogo chamado 1, este índice cria um ponto de interesse
onde GameMode=1. Se quiser obter uma classificação para este modo de jogo, o índice apenas analisa as linhas que contêm GameMode=1, devolvendo a classificação rapidamente.
Se alterar a ordem do índice anterior, pode resolver este problema da zona Wi-Fi:
CREATE INDEX idx_score_ranking ON Ranking (
Score DESC,
GameMode
)
Este índice não cria um ponto crítico significativo de jogadores que competem no mesmo modo de jogo, desde que as respetivas pontuações estejam distribuídas pelo intervalo possível. No entanto, a obtenção de pontuações não é tão rápida como com o índice anterior, porque a consulta analisa todas as pontuações de todos os modos para determinar se GameMode=1.
Como resultado, o índice reordenado resolve o ponto crítico anterior no modo de jogo, mas ainda tem espaço para melhorias, conforme ilustrado no seguinte design.
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 que mova o modo de jogo para fora do esquema da tabela e use uma tabela por modo, se possível. Ao usar este método, quando obtém as pontuações de um modo, consulta apenas uma tabela com as pontuações desse modo. Esta tabela pode ser indexada por pontuação para uma obtenção rápida dos intervalos de pontuação sem perigo significativo de pontos críticos (desde que as pontuações estejam bem distribuídas). À data da redação deste documento, o número máximo de tabelas por base de dados no Spanner é 2560, o que é mais do que suficiente para a maioria dos jogos.
Bases de dados separadas por inquilino
Ao contrário de outras cargas de trabalho, em que recomendamos a conceção para multi-tenancy no Spanner através da utilização de diferentes valores de chave primária, para dados de jogos, recomendamos a abordagem mais convencional de bases de dados separadas por inquilino. As alterações ao esquema são comuns com o lançamento de novas funcionalidades de jogos em jogos de serviço em direto, e o isolamento de inquilinos ao nível da base de dados pode simplificar as atualizações do esquema. Esta estratégia também pode otimizar o tempo necessário para fazer uma cópia de segurança ou restaurar os dados de um inquilino, porque estas operações são realizadas numa base de dados inteira de uma só vez.
Evite atualizações incrementais do esquema
Ao contrário de algumas bases de dados relacionais convencionais, o Spanner permanece operacional durante as atualizações do esquema. Todas as consultas ao esquema antigo são devolvidas (embora possam ser devolvidas mais lentamente do que o habitual), e as consultas ao novo esquema são devolvidas à medida que ficam disponíveis. Pode conceber o processo de atualização para manter o jogo em execução durante as atualizações do esquema quando é executado no Spanner, desde que tenha em atenção as restrições anteriores.
No entanto, se pedir outra alteração ao esquema enquanto existir uma em processamento, a nova atualização é colocada em fila e só é realizada quando todas as atualizações ao esquema anteriores estiverem concluídas. Pode evitar esta situação planeando atualizações de esquema maiores, em vez de emitir muitas atualizações de esquema incrementais num curto período. Para mais informações sobre as atualizações do esquema, incluindo como fazer uma atualização do esquema que requer a validação de dados, consulte a documentação de atualização do esquema do Spanner
Considere o acesso e o tamanho da base de dados
Quando desenvolve o servidor de jogos e os serviços de plataforma para usar o Spanner, considere como o jogo acede à base de dados e como dimensionar a base de dados para evitar custos desnecessários.
Use controladores e bibliotecas integrados
Quando desenvolve em função do Spanner, considere como o seu código interage com a base de dados. O Spanner oferece bibliotecas cliente incorporadas para muitos idiomas populares, que são normalmente ricos em funcionalidades e têm um bom desempenho. Também estão disponíveis controladores JDBC, que suportam declarações de linguagem de manipulação de dados (DML) e linguagem de definição de dados (LDD). Nos casos em que o Spanner é usado em novos desenvolvimentos, recomendamos a utilização das bibliotecas de cliente da Google Cloud para o Spanner. Embora as integrações típicas de motores de jogos não tenham muita flexibilidade na seleção de idiomas, para os serviços de plataforma que acedem ao Spanner, existem casos de clientes de jogos que usam Java ou Go. Para aplicações de elevado débito, selecione uma biblioteca onde possa usar o mesmo cliente do Spanner para vários pedidos sequenciais.
Dimensione a base de dados de acordo com as necessidades de testes e produção
Durante o desenvolvimento, é provável que uma instância do Spanner de nó único seja suficiente para a maioria das atividades, incluindo os testes funcionais.
Avalie as necessidades do Spanner para produção
Quando passa do desenvolvimento para os testes e, em seguida, para a produção, é importante reavaliar as suas necessidades do Spanner para garantir que o seu jogo consegue processar o tráfego de jogadores ativos.
Antes de passar para a produção, os testes de carga são essenciais para verificar se o seu back-end consegue processar a carga durante a produção. Recomendamos que execute testes de carga com o dobro da carga esperada na produção para se preparar para picos de utilização e casos em que o seu jogo seja mais popular do que o previsto.
Execute testes de carga com dados reais
A execução de um teste de carga com dados sintéticos não é suficiente. Também deve executar testes de carga com dados e padrões de acesso o mais próximo possível do que é esperado na produção. Os dados sintéticos podem não detetar potenciais pontos críticos no design do esquema do Spanner. Nada é melhor do que executar um teste beta (aberto ou fechado) com jogadores reais para verificar o comportamento do Spanner com dados reais.
O diagrama seguinte é um exemplo do esquema da tabela de jogadores de um estúdio de jogos que ilustra a importância de usar testes beta para realizar testes de carga.
O estúdio preparou estes dados com base nas tendências de um jogo anterior que tinha explorado durante alguns anos. A empresa esperava que o esquema representasse bem os dados neste novo jogo.
Cada registo de jogador tem alguns atributos numéricos associados que monitorizam o progresso do jogador no jogo (como a classificação e o tempo de jogo). Para o atributo de exemplo usado na tabela anterior, os novos jogadores recebem um valor inicial de 50, e este valor muda para um valor entre 1 e 100 à medida que o jogador avança.
O estúdio quer indexar este atributo para acelerar as consultas importantes durante o jogo.
Com base nestes dados, o estúdio criou a seguinte tabela do Spanner, com uma chave primária que usa o PlayerID e um índice secundário em Attribute.
CREATE TABLE Player (
PlayerID STRING(36) NOT NULL,
Attribute INT64 NOT NULL
) PRIMARY KEY (PlayerID)
CREATE INDEX idx_attribute ON Player(Attribute)
E o índice foi consultado para encontrar até dez jogadores com Attribute=23, como se segue:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE Attribute = 23
LIMIT 10
De acordo com a documentação sobre a otimização do design do esquema, o Spanner armazena os dados de índice da mesma forma que as tabelas, com uma linha por entrada de índice. Nos testes de carga, este modelo faz um trabalho aceitável de distribuição da carga de leitura e escrita do índice secundário em várias divisões do Spanner, conforme ilustrado no diagrama seguinte:
Embora os dados sintéticos usados no teste de carga sejam semelhantes ao estado estável final do jogo, em que os valores de Attribute estão bem distribuídos, a conceção do jogo determina que todos os jogadores começam com Attribute=50. Uma vez que cada novo jogador começa com Attribute=50, quando novos jogadores aderem, são inseridos na mesma parte do índice secundário idx_attribute. Isto significa que as atualizações são
encaminhadas para a mesma divisão do Spanner, o que provoca um ponto crítico durante o
período de lançamento do jogo. Esta é uma utilização ineficiente do Spanner.
No diagrama seguinte, a adição de uma coluna IndexPartition ao esquema após o lançamento resolve o problema do ponto crítico e os jogadores são distribuídos uniformemente pelas divisões do Spanner disponíveis. O comando atualizado para criar a tabela e o índice tem o seguinte aspeto:
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)
O valor de IndexPartition tem de ter um intervalo limitado para consultas eficientes, mas também deve ter um intervalo que seja, pelo menos, o dobro do número de divisões para uma distribuição eficiente.
Neste caso, o estúdio atribuiu manualmente a cada jogador um valor IndexPartition
entre 1 e 6 na aplicação do jogo.
Os métodos alternativos podem ser atribuir um número aleatório a cada jogador ou atribuir um valor derivado de um hash no valor PlayerID.
Consulte o artigo O que os DBAs precisam de saber sobre o Spanner, parte 1: chaves e índices
para ver mais estratégias de divisão em partições ao nível da aplicação.
A atualização da consulta anterior para usar este índice melhorado tem o seguinte aspeto:
SELECT PlayerID
FROM Player@{force_index=idx_attribute}
WHERE IndexPartition BETWEEN 1 and 6
AND Attribute = 23
LIMIT 10
Como não foi executado nenhum teste beta, o estúdio não se apercebeu de que estava a fazer testes usando dados com pressupostos incorretos. Embora os testes de carga sintéticos sejam uma boa forma de validar quantas consultas por segundo (QPS) a sua instância consegue processar, é necessário um teste beta com jogadores reais para validar o seu esquema e preparar um lançamento bem-sucedido.
Dimensione o ambiente de produção para antecipar o pico de procura
Os jogos importantes atingem frequentemente o pico do respetivo tráfego no lançamento. A criação de um back-end escalável aplica-se não só aos serviços de plataforma e aos servidores de jogos dedicados, mas também às bases de dados. Usando Google Cloud soluções como o App Engine, pode criar serviços de API de front-end que podem ser rapidamente dimensionados. Embora o Spanner ofereça a flexibilidade de adicionar e remover nós online, não é uma base de dados com escalabilidade automática. Tem de aprovisionar nós suficientes para processar o pico de tráfego no lançamento.
Com base nos dados recolhidos durante os testes de carga ou em quaisquer testes beta públicos, pode estimar o número de nós necessários para processar pedidos no lançamento. É uma boa prática adicionar alguns nós como buffer caso tenha mais jogadores do que o esperado. Deve dimensionar sempre a base de dados com base no facto de não exceder uma utilização média da CPU de 65%.
Aqueça a base de dados antes do lançamento do jogo
Antes de lançar o jogo, recomendamos que aqueça a base de dados para tirar partido das funcionalidades de paralelização do Spanner. Para mais informações, consulte o artigo Aquecer a base de dados antes do lançamento da aplicação.
Monitorize e compreenda o desempenho
Qualquer base de dados de produção requer uma monitorização abrangente e métricas de desempenho. O Spanner inclui métricas incorporadas no Cloud Monitoring. Sempre que possível, recomendamos que incorpore as bibliotecas gRPC fornecidas no processo de back-end do jogo, uma vez que estas bibliotecas incluem a monitorização do OpenCensus. O rastreio do OpenCensus permite-lhe ver rastreios de consultas no Cloud Trace, bem como outras ferramentas de rastreio de código aberto suportadas.
No Cloud Monitoring, pode ver detalhes sobre a sua utilização do Spanner, incluindo o armazenamento de dados e a utilização da CPU. Na maioria dos casos, recomendamos que baseie as suas decisões de escalabilidade do Spanner nesta métrica de utilização da CPU ou na latência observada. Para mais informações sobre a utilização da CPU sugerida para um desempenho otimizado, consulte as práticas recomendadas.
O Spanner oferece planos de execução de consultas. Pode rever estes planos na Google Cloud consola Google Cloud e contactar o apoio técnico se precisar de ajuda para compreender o desempenho das suas consultas.
Quando estiver a avaliar o desempenho, mantenha os testes de ciclo curto ao mínimo, porque o Spanner divide de forma transparente os seus dados nos bastidores para otimizar o desempenho com base nos seus padrões de acesso aos dados. Deve avaliar o desempenho usando cargas de consultas realistas e sustentadas.
Quando remover dados, elimine linhas em vez de recriar tabelas
Quando trabalha com o Spanner, as tabelas criadas recentemente ainda não tiveram a oportunidade de passar por uma divisão baseada no carregamento ou no tamanho para melhorar o desempenho. Quando elimina dados ao eliminar uma tabela e, em seguida, recriá-la, o Spanner precisa de dados, consultas e tempo para determinar as divisões corretas para a sua tabela. Se planeia repovoar uma tabela com o mesmo tipo de dados (por exemplo, quando executa testes de desempenho consecutivos), pode, em alternativa, executar uma consulta DELETE nas linhas que contêm dados de que já não precisa. Pelo mesmo motivo, as atualizações do esquema devem usar a API Cloud Spanner fornecida e devem evitar uma estratégia manual, como criar uma nova tabela e copiar os dados de outra tabela ou de um ficheiro de cópia de segurança.
Selecione uma localidade de dados para cumprir os requisitos de conformidade
Muitos jogos têm de agir em conformidade com as leis de localização de dados, como o RGPD, quando jogados em todo o mundo. Para ajudar a dar resposta às suas necessidades relacionadas com o RGPD, consulte o Google Cloud e o relatório técnico sobre o RGPD e selecione a configuração regional do Spanner correta.
O que se segue?
- Leia sobre como a Bandai Namco Entertainment usou o Spanner no lançamento bem-sucedido do Dragon Ball Legends.
- Veja a sessão do Cloud Next '18 sobre a Otimização de aplicações, esquemas e design de consultas no Spanner.
- Leia o nosso guia sobre a migração do DynamoDB para o Spanner.