Atualizações de esquema

Com o Cloud Spanner, é possível fazer atualizações de esquema sem tempo de inatividade. Você pode atualizar o esquema de um banco de dados existente de várias maneiras:

Atualizações de esquema compatíveis

O Cloud Spanner é compatível com as seguintes atualizações para o esquema de um banco de dados existente:

  • Criar novas tabelas. As colunas em novas tabelas podem ser NOT NULL.
  • Excluir uma tabela, se nenhuma outra estiver intercalada nela e ela não tiver índices secundários.
  • Adicionar uma coluna sem chave a qualquer tabela. Novas colunas sem chave não podem ser NOT NULL.
  • Adicionar NOT NULL a uma coluna sem chave.
  • Remover NOT NULL de uma coluna sem chave.
  • Eliminar uma coluna sem chave de qualquer tabela, a menos que seja usada por um índice secundário.
  • Alterar uma coluna STRING para uma coluna BYTES ou uma coluna BYTES para uma coluna STRING.
  • Aumentar ou diminuir o limite de comprimento para um tipo STRING ou BYTES (incluindo para MAX), a menos que seja uma coluna de chave primária herdada por uma ou mais tabelas filho.
  • Ativar ou desativar carimbos de data/hora de confirmação em colunas de valor e chave principal.
  • Adicionar ou remover qualquer índice secundário.

Desempenho de atualização do esquema

As atualizações de esquema no Cloud Spanner não exigem tempo de inatividade. Quando você emite um lote de instruções em DDL para um banco de dados Cloud Spanner, pode continuar gravando e lendo do banco de dados sem interrupção enquanto o Cloud Spanner aplica a atualização como uma operação de longa duração.

O tempo necessário para executar uma instrução em DDL depende de a atualização exigir a validação dos dados existentes ou o preenchimento de dados. Por exemplo, se você adicionar a anotação NOT NULL a uma coluna existente, o Cloud Spanner precisará ler todos os valores na coluna para garantir que ela não contenha nenhum valor NULL. Essa etapa poderá levar muito tempo se houver muitos dados para validar. Outro exemplo é se você estiver adicionando um índice a um banco de dados: o Cloud Spanner preencherá o índice usando dados existentes. Esse processo pode demorar muito, dependendo de como o índice é definido e do tamanho da tabela de base correspondente. No entanto, se você adicionar uma nova coluna a uma tabela, não haverá dados existentes para validar, então o Cloud Spanner poderá fazer a atualização em minutos.

Em resumo, as atualizações de esquema que não exigem que o Cloud Spanner valide dados existentes podem acontecer em minutos. As atualizações de esquema que necessitam de validação podem demorar mais, dependendo da quantidade de dados existentes que precisam ser validados. Porém, a validação de dados acontece em segundo plano sem afetar o tráfego de produção. As atualizações de esquema que requerem validação de dados são discutidas com mais detalhes na próxima seção.

Atualizações de esquema que exigem validação de dados

Você pode fazer atualizações de esquema que exigem a validação de que os dados existentes atendem às novas restrições. Quando essa alteração de esquema exige validação de dados, o Cloud Spanner não permite a realização de alterações conflitantes do esquema nas entidades de esquema afetadas e valida os dados em segundo plano. Se a validação for bem-sucedida, a atualização do esquema será bem-sucedida. Se a validação não for bem-sucedida, a atualização do esquema não será bem-sucedida. As operações de validação são executadas como operações de longa duração. Verifique o status dessas operações para determinar se elas foram bem-sucedidas ou falharam.

Por exemplo, suponha que você tenha definido uma tabela Songwriters no esquema:

CREATE TABLE Songwriters (
  Id         INT64 NOT NULL,
  FirstName  STRING(1024),
  LastName   STRING(1024),
  Nickname   STRING(MAX),
  OpaqueData BYTES(MAX),
) PRIMARY KEY (Id);

As seguintes atualizações de esquema são permitidas, mas exigem validação e podem levar mais tempo para serem concluídas, dependendo da quantidade de dados existentes:

  • adição da anotação NOT NULL em uma coluna sem chave

    Exemplo: ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL

  • redução do comprimento de uma coluna

    Exemplo: ALTER TABLE Songwriters ALTER COLUMN FirstName STRING(10)

  • alteração de BYTES para STRING

    Exemplo: ALTER TABLE Songwriters ALTER COLUMN OpaqueData STRING(MAX)

  • ativação de carimbos de data/hora de confirmação em uma coluna TIMESTAMP atual

    Exemplo: ALTER TABLE Albums ALTER COLUMN LastUpdateTime SET OPTIONS (allow_commit_timestamp = true)

Essas atualizações de esquema falharão se os dados subjacentes não satisfizerem as novas restrições. Por exemplo, a instrução ALTER TABLE Songwriters ALTER COLUMN Nickname STRING(MAX) NOT NULL acima falhará se algum valor na coluna Nickname for NULL, porque os dados existentes não atendem à restrição NOT NULL da nova definição.

A validação de dados pode demorar de vários minutos a muitas horas. O tempo para completar a validação de dados depende:

  • do tamanho do conjunto de dados;
  • do número de nodes na instância;
  • da carga na instância.

Algumas atualizações de esquema podem alterar o comportamento das solicitações no banco de dados antes que a atualização do esquema seja concluída. Por exemplo, se você estiver adicionando NOT NULL a uma coluna, o Cloud Spanner quase imediatamente começará a rejeitar as gravações para novas solicitações que usam NULL para a coluna. Se a nova atualização de esquema acabar falhando na validação de dados, haverá um período de tempo em que as gravações serão bloqueadas, mesmo que elas tenham sido aceitas pelo esquema antigo.

É possível cancelar uma operação de validação de dados de longa duração usando o método projects.instances.databases.operations.cancel ou usando gcloud spanner operations.

Ordem de execução de instruções em lotes

Se você usar a ferramenta gcloud, a API REST ou a API RPC, emita um lote de um ou mais declarações CREATE, ALTER ou DROP.

O Cloud Spanner aplica instruções do mesmo lote em ordem, parando no primeiro erro. Se a aplicação de uma instrução resultar em um erro, essa instrução será revertida. Os resultados de quaisquer instruções aplicadas anteriormente no lote não são revertidos.

O Cloud Spanner pode combinar e reordenar instruções de diferentes lotes, misturando potencialmente instruções de diferentes lotes para a mesma alteração atômica aplicada ao banco de dados. Dentro de cada alteração atômica, as instruções de diferentes lotes ocorrem em uma ordem arbitrária. Por exemplo, se um lote de instruções contiver ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(50) e o outro contiver ALTER TABLE MyTable ALTER COLUMN MyColumn STRING(20), o Cloud Spanner deixará essa coluna em um desses dois estados, mas sem especificar em qual.

Versões de esquema criadas durante atualizações de esquema

O Cloud Spanner usa o controle de versão do esquema para que não haja tempo de inatividade durante uma atualização de esquema para um banco de dados grande. O Cloud Spanner mantém a versão antiga do esquema para oferecer suporte a leituras enquanto a atualização do esquema é processada. O Cloud Spanner cria uma ou mais novas versões do esquema para processar a atualização do esquema. Cada versão contém o resultado de uma coleção de instruções em uma única alteração atômica, conforme descrito acima. As versões do esquema não correspondem necessariamente um para um com lotes de instruções DDL ou instruções DDL individuais. Algumas instruções DDL individuais, como, por exemplo, criação de índice não intercalado ou instruções que requerem validação de dados, resultam em várias versões de esquema. Em outros casos, várias instruções DDL podem ser agrupadas em uma única versão. Versões de esquema podem consumir recursos significativos de servidor e armazenamento, e elas persistem por até uma semana.

A tabela a seguir mostra a duração das operações de atualização do esquema.

Operação de esquema Duração estimada
CREATE TABLE Minutos
CREATE INDEX

Minutos a horas, se o índice não for intercalado. A criação do índice pode levar muito tempo, mesmo no caso de tabelas pequenas ou vazias.

Minutos, se o índice for intercalado e executado ao mesmo tempo que CREATE TABLE para a tabela de base.

DROP TABLE Minutos
DROP INDEX Minutos
ALTER TABLE ... ADD COLUMN Minutos
ALTER TABLE ... ALTER COLUMN

Várias horas, se a validação de segundo plano for necessária.

Minutos, se a validação de segundo plano não for necessária.

ALTER TABLE ... DROP COLUMN Minutos

Práticas recomendadas para atualizações de esquema

As seções a seguir descrevem as práticas recomendadas para a atualização de esquemas.

Procedimentos antes da emissão da atualização do esquema

Antes de emitir uma atualização de esquema, realize as seguintes ações:

  • Verifique se todos os dados existentes no banco de dados que você está alterando atendem às restrições que a atualização do esquema está impondo. Como o sucesso de alguns tipos de atualizações de esquema depende dos dados no banco de dados e não apenas do esquema atual, uma atualização de esquema bem-sucedida de um banco de dados de teste não garante uma atualização de esquema bem-sucedida de um banco de dados de produção. Veja alguns exemplos comuns:
    • Se você estiver adicionando uma anotação NOT NULL a uma coluna existente, confira se a coluna não contém valores NULL existentes.
    • Se o comprimento permitido de uma coluna STRING ou BYTES estiver sendo encurtado, confira se todos os valores existentes nessa coluna atendem à restrição de comprimento que você quer.
  • Se você estiver gravando em uma coluna, tabela ou índice que estiver passando por uma atualização de esquema, verifique se os valores que estão sendo gravados atendem às novas restrições.
  • Se você estiver excluindo uma coluna, uma tabela ou um índice, confira se eles ainda não estão sendo usados para gravação ou leitura.

Limitar o número de atualizações de esquema em um período de sete dias

Evite fazer muitas atualizações no esquema de um único banco de dados em um período de sete dias. Aumente o tempo no qual você faz atualizações de esquema para permitir que o Cloud Spanner remova versões antigas do esquema antes que novas versões sejam criadas.

  • Para alguns sistemas de gerenciamento de banco de dados relacional, há pacotes de software que fazem uma longa série de atualizações de esquema de atualização e downgrade do banco de dados em cada implementação de produção. Esses tipos de processos não são recomendados para o Cloud Spanner.
  • O Cloud Spanner é otimizado para usar chaves primárias para particionar dados de soluções de multilocação. As soluções de multilocação que usam tabelas separadas para cada cliente podem resultar em um grande backlog de operações de atualização de esquema que levam muito tempo para serem concluídas.

Evite mais de 30 instruções DDL que exigem validação ou preenchimento de índice em um período de 7 dias, porque cada instrução cria várias versões do esquema internamente.

Opções para grandes atualizações de esquema

Se você estiver criando um banco de dados com um grande número de índices, especialmente se os índices não forem intercalados, use um destes métodos:

  • Crie o banco de dados e o esquema na solicitação de criação do banco de dados. Criar tabelas e índices na criação do banco de dados é uma operação rápida, porque o Cloud Spanner não precisa validar dados, armazenar várias versões de esquema ou coordenar alterações de esquema com transações simultâneas.
  • Crie o banco de dados e adicione novos índices a uma taxa média de 3 por dia.

Se você tiver uma atualização de esquema com um grande número de instruções DDL, não as execute um pouco de cada vez usando solicitações projects.instances.databases.updateDdl (API REST) ou UpdateDatabaseDdl (API RPC). Em vez disso, agrupe-as em grupos maiores. Você pode agrupar milhares de instruções DDL em uma única solicitação, mas somente 10 das instruções podem exigir validação ou preenchimento. O limite de validação e de preenchimento é devido à capacidade do Cloud Spanner de combinar as instruções, bem como o número de versões de esquema criadas pelo Cloud Spanner. Mesmo com lotes, limite o número de índices que você adiciona a aproximadamente 3 por dia.

Aguardar a conclusão das solicitações da API

Ao criar solicitações projects.instances.databases.updateDdl (API REST) ou UpdateDatabaseDdl (API RPC), use projects.instances.databases.operations.get (API REST) ou GetOperation (API RPC), respectivamente, para aguardar cada solicitação ser concluída antes de iniciar uma nova solicitação. Aguardar a conclusão de cada solicitação permite que seu aplicativo acompanhe o andamento das atualizações de esquema. Ele também mantém o backlog de atualizações de esquema pendentes em um tamanho gerenciável.

Carregamento em massa

Se você estiver carregando nas tabelas dados em massa depois de criados, geralmente é mais eficiente criar índices após os dados serem carregados. Se você estiver adicionando vários índices, pode ser mais eficiente criar o banco de dados com todas as tabelas e índices no esquema inicial, conforme descrito em Opções para grandes atualizações.

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

Enviar comentários sobre…

Documentação do Cloud Spanner