A arquitetura distribuída do Spanner permite projetar o esquema para evitar pontos de acesso, situações em que muitas solicitações são enviadas para o mesmo servidor, o que satura os recursos do servidor e pode causar altas latências.
Nesta página, descrevemos as práticas recomendadas para criar esquemas e evitar criar pontos de acesso. Uma forma de evitar pontos de acesso é ajustar o design do esquema para permitem que o Spanner divida e distribua os dados por vários servidores. A distribuição de dados entre servidores ajuda o banco de dados do Spanner a operar eficiente, especialmente ao realizar inserções de dados em massa.
Como escolher uma chave primária para evitar pontos de acesso
Como mencionado em Esquema e modelo de dados, tenha cuidado ao escolher uma chave primária no projeto do esquema para não criar acidentalmente pontos de acesso em seu no seu banco de dados. Uma das causas dos pontos de acesso é ter uma coluna com valor monotonicamente muda como a primeira parte-chave, pois isso resulta em todas as inserções ocorrendo no ao final do espaço da chave. Esse padrão não é desejável, porque o Spanner utiliza intervalos de chaves para dividir os dados entre os servidores, o que significa que todas as inserções são direcionadas a um único servidor que acaba fazendo todo o trabalho.
Por exemplo, suponha que você queira manter uma última coluna de carimbo de data/hora de acesso nas linhas da tabela UserAccessLog. A definição de tabela a seguir usa uma
com base em chave primária de data/hora
como a primeira parte da chave. Não recomendamos isso se
a tabela tiver uma alta taxa de inserção:
GoogleSQL
CREATE TABLE UserAccessLog ( LastAccess TIMESTAMP NOT NULL, UserId INT64 NOT NULL, ... ) PRIMARY KEY (LastAccess, UserId);
PostgreSQL
CREATE TABLE UserAccessLog ( LastAccess TIMESTAMPTZ NOT NULL, UserId bigint NOT NULL, ... PRIMARY KEY (LastAccess, UserId) );
O problema é que as linhas são gravadas nessa tabela na ordem do último de acesso e, como os carimbos de data/hora do último acesso estão sempre aumentando, elas são sempre gravadas no final da tabela. O ponto de acesso é criado servidor do Spanner recebe todas as gravações, o que sobrecarrega esse um servidor.
Essa armadilha está ilustrada no diagrama a seguir:
A tabela UserAccessLog acima inclui cinco linhas de dados de exemplo. Elas representam cinco usuários diferentes que realizam algum tipo de ação do usuário com cerca de um milésimo de segundo de diferença uma da outra. O diagrama também anota a ordem em que
O Spanner insere as linhas (as setas rotuladas indicam a ordem
gravações de cada linha). Como as inserções são ordenadas por carimbo de data/hora, e o
o valor do carimbo de data/hora sempre aumenta, o Spanner sempre adiciona as inserções
ao final da tabela e direciona-os para a mesma divisão. (Como discutido em
Esquema e modelo de dados, uma
é um conjunto de linhas de uma ou mais tabelas relacionadas que o Spanner
armazena na ordem da chave de linha.
Isso é um problema porque o Spanner atribui o trabalho a diferentes servidores em unidades de divisão, de modo que o servidor atribuído a essa divisão que processa todas as solicitações de inserção. À medida que a frequência dos eventos de acesso do usuário aumenta, o mesmo ocorre com a frequência das solicitações de inserção para o servidor correspondente. O servidor fica propenso a se tornar um ponto de acesso e tem esta aparência: a borda vermelha e o plano de fundo acima. Observe que, nesta ilustração simplificada, cada servidor lida com no máximo uma divisão, mas na verdade o Spanner pode atribuir mais de uma divisão a cada servidor.
Quando o Spanner anexa mais linhas à tabela, a divisão aumenta e, quando alcance cerca de 8 GB, o Spanner cria outro dividida, conforme descrito em Divisão baseada em carga. O Spanner anexa novas linhas subsequentes a essa nova divisão, e o servidor atribuído à divisão se torna o novo ponto de acesso potencial.
Quando ocorrem pontos de acesso, as inserções tornam-se lentas e outros trabalhos no mesmo servidor podem ficar mais lentos. Alterar a ordem da coluna LastAccess para ordem crescente não resolverá esse problema, já que todas as gravações serão inseridas na parte superior da tabela, o que ainda enviará todas as inserções para um único servidor.
Prática recomendada de design de esquema nº 1: não escolha uma coluna cujo valor aumente ou diminua monotonicamente como a primeira parte importante de uma tabela de alta taxa de gravação.
Usar um identificador universal exclusivo (UUID, na sigla em inglês)
É possível usar um identificador universal exclusivo (UUID, na sigla em inglês), conforme definido pela RFC 4122 como a chave primária. Recomendamos usar a versão 4 do UUID, porque usa valores aleatórios na sequência de bits. Não recomendamos os UUIDs da versão 1 porque armazenam o carimbo de data/hora nos bits de ordem superior.
Existem várias maneiras de armazenar o UUID como chave primária:
- Em uma coluna
STRING(36). - Em um par de colunas
INT64. - Em uma coluna
BYTES(16).
Para uma coluna STRING(36), é possível usar o Spanner GENERATE_UUID()
(GoogleSQL ou PostgreSQL) como o valor padrão da coluna para
fazer com que o Spanner gere valores UUID automaticamente.
Existem algumas desvantagens em usar um UUID:
- Eles são um pouco grandes, usando 16 bytes ou mais. Outras opções para chaves primárias não utilizam tanto armazenamento.
- Elas não contêm informações sobre o registro. Por exemplo, uma chave primária de
SingerIdeAlbumIdtêm um significado inerente, enquanto um UUID não tem. - Você perde localidade entre registros relacionados, e é por isso que usar um UUID e elimina os pontos de acesso.
Fazer reversão em bits dos valores sequenciais
Verifique se os valores numéricos (INT64 no GoogleSQL ou bigint no PostgreSQL)
as chaves primárias não estão aumentando ou diminuindo sequencialmente. Primário sequencial
pode causar uso excessivo do ponto de acesso em grande escala. Uma forma de evitar
problema é fazer uma reversão em bits dos valores sequenciais, certificando-se de distribuir
valores de chave primária de maneira uniforme em todo o espaço da chave.
O Spanner dá suporte à sequência reversa de bits, que gera valores inteiros invertidos em bits. É possível usar uma sequência na primeira (ou apenas) em uma chave primária para evitar problemas de ponto de acesso. Para mais informações, consulte Sequência invertida.
Trocar a ordem das chaves
Uma maneira de espalhar as gravações no espaço da chave de maneira mais uniforme é trocar a ordem das chaves para que a coluna que contém o valor monotônico não seja primeira parte importante:
GoogleSQL
CREATE TABLE UserAccessLog ( LastAccess TIMESTAMP NOT NULL, UserId INT64 NOT NULL, ... ) PRIMARY KEY (UserId, LastAccess);
PostgreSQL
CREATE TABLE UserAccessLog ( LastAccess TIMESTAMPTZ NOT NULL, UserId bigint NOT NULL, ... PRIMARY KEY (UserId, LastAccess) );
Nesse esquema modificado, as inserções agora são ordenadas primeiro por UserId, e não pelo carimbo de data/hora do último acesso cronológico. Esse esquema espalha gravações
divisões porque é improvável que um único usuário produza milhares
de eventos por segundo.
A seguir, ilustramos as cinco linhas da tabela UserAccessLog
que o Spanner ordena com UserId em vez do carimbo de data/hora de acesso:
Aqui o Spanner divide os dados de UserAccessLog em três divisões, com
cada divisão contendo aproximadamente mil linhas de valores de UserId ordenados.
Essa é uma estimativa razoável de como os dados do usuário podem ser divididos, supondo que cada
linha contém cerca de 1 MB de dados do usuário e recebe um tamanho máximo de divisão de
aproximadamente 8 GB. Embora os eventos do usuário tenham ocorrido em torno de um
milissegundos de diferença, cada evento foi gerado por um usuário diferente, então a ordem
é muito menor a probabilidade de criar um ponto de acesso em comparação com o uso do
carimbo de data/hora para ordenação.
Consulte também as práticas recomendadas relacionadas à ordenação baseada em carimbo de data/hora chaves.
Gere o hash da chave única e espalhe as gravações em fragmentos lógicos
Outra técnica comum para espalhar a carga em vários servidores é criar uma coluna que contenha o hash da chave exclusiva real e usar a coluna hash (ou a coluna hash junto com as colunas de chave única) como a chave primária. Esse padrão ajuda a evitar pontos de acesso porque as novas linhas são distribuídas de maneira mais uniforme no espaço da chave.
Você pode usar o valor de hash para criar fragmentos lógicos ou partições em seu banco de dados. Em um banco de dados fisicamente fragmentado, as linhas são distribuídas
servidores de banco de dados. Em um banco de dados logicamente fragmentado, os dados da tabela definem
os fragmentos Por exemplo, para espalhar gravações na tabela UserAccessLog em N fragmentos lógicos, seria possível preceder uma coluna-chave ShardId à tabela:
GoogleSQL
CREATE TABLE UserAccessLog ( ShardId INT64 NOT NULL, LastAccess TIMESTAMP NOT NULL, UserId INT64 NOT NULL, ... ) PRIMARY KEY (ShardId, LastAccess, UserId);
PostgreSQL
CREATE TABLE UserAccessLog ( ShardId bigint NOT NULL, LastAccess TIMESTAMPTZ NOT NULL, UserId bigint NOT NULL, ... PRIMARY KEY (ShardId, LastAccess, UserId) );
Para computar ShardId, gere hash de uma combinação das colunas de chave primária e, em seguida,
calcular o módulo N do hash. Exemplo:
ShardId = hash(LastAccess and UserId) % N
Sua opção de função hash e combinação de colunas determina como as linhas são distribuídas pelo espaço de chave. O Spanner vai criar divisões nas linhas para para otimizar o desempenho.
O diagrama abaixo ilustra como o uso de um hash para criar três fragmentos lógicos pode espalhar a taxa de transferência de gravação de maneira mais uniforme entre os servidores:
Aqui, a tabela UserAccessLog é ordenada por ShardId, que é calculada como uma função hash de colunas de chave. As cinco linhas de UserAccessLog são divididas em três fragmentos lógicos, cada um deles, coincidentemente, em uma divisão diferente. As inserções são distribuídas uniformemente entre as divisões, o que equilibra a capacidade de gravação para os três servidores que manipulam as divisões.
O Spanner também permite criar uma função hash em um coluna gerada.
Para fazer isso no Google SQL, use o comando FARM_FINGERPRINT durante o tempo de gravação, conforme mostrado no exemplo a seguir:
GoogleSQL
CREATE TABLE UserAccessLog (
ShardId INT64 NOT NULL
AS (MOD(FARM_FINGERPRINT(CAST(LastAccess AS STRING)), 2048)) STORED,
LastAccess TIMESTAMP NOT NULL,
UserId INT64 NOT NULL,
) PRIMARY KEY (ShardId, LastAccess, UserId);
A escolha da função hash determina a distribuição das inserções em todo o intervalo de chaves. Você não precisa de um hash criptográfico, e o hash criptográfico pode ser uma boa escolha. Ao escolher uma função hash, você precisa considerar os seguintes fatores:
- Evasão do ponto de acesso. Uma função que resulte em mais valores de hash tende a reduzir os pontos de acesso.
- Eficiência de leitura. As leituras em todos os valores de hash são mais rápidas se houver menos valores de hash a serem verificados.
- Contagem de nós
Usar a ordem decrescente para as chaves baseadas em carimbo de data/hora
Se houver uma tabela do histórico que use o carimbo de data/hora como chave, use a ordem decrescente para a coluna da chave se uma das seguintes aplicar:
- Se quiser ler o histórico mais recente, você está usando um
tabela intercalada para o histórico, e está
como ler a linha pai. Nesse caso, com uma coluna de carimbo de data/hora
DESC, as entradas de histórico mais recentes são armazenadas adjacentes à linha-pai. Caso contrário, a leitura da linha-pai e seu histórico recente exigirão uma busca no meio para pular o histórico mais antigo. - Se você está lendo entradas sequenciais em ordem cronológica inversa, e não sabe exatamente a que distância está indo. Por exemplo, é possível usar uma consulta SQL com
LIMITpara ver os N eventos mais recentes ou planejar cancelar a leitura depois de ler um determinado número de linhas. Nessas casos, convém começar com as entradas mais recentes e ler sequencialmente entradas mais antigas até que a condição seja atendida, o que o Spanner faz com mais eficiência para chaves de carimbo de data/hora armazenadas pelo Spanner em ordem decrescente.
Adicione a palavra-chave DESC para tornar a chave de carimbo de data/hora decrescente. Exemplo:
GoogleSQL
CREATE TABLE UserAccessLog ( UserId INT64 NOT NULL, LastAccess TIMESTAMP NOT NULL, ... ) PRIMARY KEY (UserId, LastAccess DESC);
Prática recomendada de criação do esquema no 2: ordem decrescente ou crescente depende das consultas do usuário, por exemplo, se a maior é a mais recente ou a mais antiga é a mais antiga.
Usar um índice intercalado em uma coluna em que o valor aumenta ou diminui monotonicamente
Semelhante ao exemplo anterior de chave primária que deve ser evitado, ela também é uma uma má ideia criar índices não intercalados em colunas cujos valores sejam aumentando ou diminuindo monotonicamente, mesmo que não sejam colunas de chave primária.
Por exemplo, suponha que você defina a seguinte tabela, em que LastAccess é uma coluna de chave não primária:
GoogleSQL
CREATE TABLE Users ( UserId INT64 NOT NULL, LastAccess TIMESTAMP, ... ) PRIMARY KEY (UserId);
PostgreSQL
CREATE TABLE Users ( UserId bigint NOT NULL, LastAccess TIMESTAMPTZ, ... PRIMARY KEY (UserId) );
Pode parecer conveniente definir um índice na coluna LastAccess para consultar rapidamente o banco de dados em busca dos acessos de usuários "desde a hora X", como este:
GoogleSQL
CREATE NULL_FILTERED INDEX UsersByLastAccess ON Users(LastAccess);
PostgreSQL
CREATE INDEX UsersByLastAccess ON Users(LastAccess) WHERE LastAccess IS NOT NULL;
No entanto, isso resulta na mesma armadilha descrita na seção sobre porque o Spanner implementa índices como tabelas em segundo plano, e a tabela de índice resultante usa uma coluna com valor que aumenta monotonicamente como primeira parte principal.
Não há problema em criar um índice intercalado como esse, porque as linhas de índices intercalados são intercalados em linhas pai correspondentes e é é improvável que uma única linha pai produza milhares de eventos por segundo.
Prática recomendada de criação de esquema no 3: não crie uma índice não intercalado em uma coluna com alta taxa de gravação, cujo valor monotonicamente aumenta ou diminui. Em vez de usar índices intercalados, use técnicas como as que você usaria para o design da chave primária da tabela base ao projetar colunas de índice, exemplo, adicione "shardId".
A seguir
- Confira exemplos de designs de esquemas.
- Saiba mais sobre carregar dados em massa.