Vista geral das alterações de streams

Um fluxo de alterações monitoriza e transmite as alterações de dados de uma base de dados do Spanner, ou seja, inserções, atualizações e eliminações, quase em tempo real.

Esta página oferece uma vista geral de alto nível dos streams de alterações do Spanner: o que fazem e como funcionam. Para saber como criar e gerir streams de alterações na sua base de dados e associá-las a outros serviços, siga os links em Passos seguintes.

Finalidade dos fluxos de alterações

As streams de alterações oferecem uma forma flexível e escalável de transmitir alterações de dados para outros serviços. Os exemplos de utilização comuns incluem:

  • Replicar alterações de dados do Spanner num armazém de dados, como o BigQuery, para fins de análise.

  • Acionar a lógica da aplicação com base nas alterações de dados enviadas para uma fila de mensagens, como o Pub/Sub.

  • Armazenar alterações de dados no Cloud Storage para fins de conformidade ou arquivo.

Altere a configuração da stream

O Spanner trata as streams de alterações como objetos de esquema, tal como as tabelas e os índices. Como tal, cria, modifica e elimina streams de alterações com declarações LDD, e pode ver as streams de alterações de uma base de dados tal como outros objetos de esquema geridos por LDD.

Pode configurar um fluxo de alterações para monitorizar as alterações de dados numa base de dados inteira ou limitar o respetivo âmbito a tabelas e colunas específicas. Uma base de dados pode ter vários fluxos de alterações e uma tabela ou coluna específica pode ter vários fluxos a monitorizá-la, dentro dos limites.

Opcionalmente, pode configurar uma stream de alterações com o seguinte:

A emissão do DDL que cria um fluxo de alterações inicia uma operação de longa duração. Quando estiver concluída, a nova stream de alterações começa imediatamente a monitorizar as tabelas e as colunas que lhe foram atribuídas.

Monitorizar tabelas e colunas implicitamente

As alterações de streams que observam uma tabela inteira observam implicitamente todas as colunas nessa tabela, mesmo quando a definição da tabela é atualizada. Por exemplo, quando adiciona novas colunas a essa tabela, o fluxo de alterações começa automaticamente a monitorizar essas novas colunas, sem exigir qualquer modificação à configuração desse fluxo de alterações. Da mesma forma, a stream de alterações deixa automaticamente de monitorizar as colunas que são removidas dessa tabela.

As streams de alterações de base de dados completa funcionam da mesma forma. Observam implicitamente todas as colunas em todas as tabelas, observando automaticamente quaisquer tabelas ou colunas adicionadas após a criação da stream de alterações e deixando de observar quaisquer tabelas ou colunas eliminadas.

Monitorizar tabelas e colunas explicitamente

Se configurar um fluxo de alterações para monitorizar apenas colunas específicas numa tabela e, posteriormente, adicionar colunas a essa tabela, o fluxo de alterações não começa a monitorizar essas colunas, a menos que reconfigure esse fluxo de alterações para o fazer.

O esquema da base de dados trata os fluxos de alterações como objetos dependentes de quaisquer colunas ou tabelas que monitorizem explicitamente. Antes de poder eliminar qualquer coluna ou tabela deste tipo, tem de a remover manualmente da configuração de qualquer stream de alterações que a esteja a monitorizar explicitamente.

Tipos de alterações de dados que os fluxos de alterações monitorizam

As alterações de dados que um fluxo de alterações monitoriza incluem todas as inserções, atualizações e eliminações feitas às tabelas e colunas que monitoriza. Estas alterações podem ser provenientes de:

As streams de alterações só podem monitorizar alterações de dados em colunas e tabelas criadas pelo utilizador. Não monitorizam índices, visualizações, outras streams de alterações nem tabelas do sistema, como o esquema de informações ou as tabelas de estatísticas. As alterações de streams não monitorizam colunas geradas, a menos que a coluna faça parte da chave primária. As colunas de chave principal são sempre acompanhadas.

Além disso, as streams de alterações não monitorizam alterações de esquema nem alterações de dados que resultem diretamente de alterações de esquema, exceto preenchimentos para valores predefinidos. Por exemplo, uma stream de alterações que monitoriza uma base de dados inteira não considera nem regista a eliminação de uma tabela como uma alteração de dados, mesmo que esta ação elimine todos os dados dessa tabela da base de dados.

Como o Spanner escreve e armazena streams de alterações

Sempre que o Spanner deteta uma alteração de dados numa coluna que está a ser monitorizada por um fluxo de alterações, escreve um registo de alteração de dados no respetivo armazenamento interno. A gravação da alteração de dados e o registo da alteração de dados são escritos na mesma transação. O Spanner localiza conjuntamente estas duas escritas para que sejam processadas pelo mesmo servidor, minimizando o processamento de escrita. A transação é, em seguida, replicada nas réplicas da base de dados, ficando sujeita a custos de armazenamento e replicação. Para mais informações, consulte os preços do Spanner.

Conteúdo de um registo de alteração de dados

Cada registo de alteração de dados escrito por uma stream de alterações inclui as seguintes informações sobre a alteração de dados:

  • O nome da tabela afetada

  • Os nomes, os valores e os tipos de dados das chaves primárias que identificam a linha alterada

  • Os nomes e os tipos de dados das colunas da linha alterada que foram capturados com base na definição da stream de alterações.

  • Os valores antigos das colunas da linha. A disponibilidade dos valores antigos e do conteúdo que acompanham, que pode ser apenas as colunas modificadas ou a linha acompanhada completa, depende do tipo de captura de valor configurado pelo utilizador.

  • Os novos valores das colunas da linha. A disponibilidade dos novos valores e o conteúdo que acompanham dependem do tipo de captura de valor configurado pelo utilizador.

  • O tipo de modificação (inserção, atualização ou eliminação)

  • A data/hora da confirmação

  • O ID da transação

  • O número de sequência do registo

  • O tipo de captura de valor do registo de alteração de dados.

Para uma análise mais detalhada da estrutura dos registos de alterações de dados, consulte o artigo Registos de alterações de dados.

Retenção de dados

Uma stream de alterações retém os respetivos registos de alterações de dados durante um período entre um e trinta dias. Pode usar DDL para especificar um limite de retenção de dados diferente do predefinido de um dia quando criar inicialmente uma stream de alterações ou ajustá-lo em qualquer altura no futuro. Tenha em atenção que a redução do limite de retenção de dados de um fluxo de alterações torna todos os dados de alterações do histórico mais antigos do que o novo limite imediatamente e permanentemente indisponíveis para os leitores desse fluxo de alterações.

Este período de retenção de dados apresenta uma compensação: um período de retenção mais longo implica maiores exigências de armazenamento na base de dados da stream.

Tipo de captura de valor

A opção de configuração do tipo de captura de valor de um fluxo de alterações controla a forma como armazena os valores de uma linha alterada. Pode usar DDL para especificar um dos seguintes tipos de captura de valores para um fluxo de alterações:

  • OLD_AND_NEW_VALUES: captura os valores antigos e novos das colunas modificadas de uma linha.

  • NEW_VALUES: captura apenas os novos valores das colunas não principais, mas não os valores antigos.

  • NEW_ROW: captura todos os novos valores das colunas observadas, modificados e não modificados, sempre que alguma dessas colunas é alterada. Não são captados valores antigos.

  • NEW_ROW_AND_OLD_VALUES: Captura todos os novos valores para colunas modificadas e não modificadas, bem como os valores antigos para colunas modificadas.

Exclua eliminações baseadas no tempo de vida

No Spanner, o tempo de vida (TTL) permite-lhe definir políticas para eliminar periodicamente dados de tabelas do Spanner. Por predefinição, as streams de alterações incluem todas as eliminações baseadas no TTL. Pode usar exclude_ttl_deletes para definir o fluxo de alterações de modo a excluir eliminações baseadas no TTL. Quando define este filtro para excluir eliminações baseadas no TTL, apenas as eliminações baseadas no TTL futuras são excluídas da sua stream de alterações.

O valor predefinido para este filtro é false. Para excluir eliminações baseadas no TTL, defina o filtro como true. Pode adicionar o filtro quando cria uma stream de alterações ou modificar uma stream de alterações existente para incluir o filtro.

Tipo de modificação da tabela

Por predefinição, as streams de alterações incluem todas as modificações de tabelas, como inserções, atualizações e eliminações. Pode filtrar uma ou mais destas modificações da tabela do âmbito da sua stream de alterações usando as seguintes opções de filtro disponíveis:

  • exclude_insert: excluir todas as modificações da tabela INSERT
  • exclude_update: excluir todas as modificações da tabela UPDATE
  • exclude_delete: excluir todas as modificações da tabela DELETE

O valor predefinido para estes filtros é false. Para excluir um tipo específico de modificação da tabela, defina o filtro como true. Pode definir um ou mais filtros em simultâneo.

Pode adicionar um filtro para um tipo de modificação de tabela quando cria um fluxo de alterações ou modifica o filtro para um tipo de modificação de tabela para um fluxo de alterações existente.

Exclusão de registos ao nível da transação

Por predefinição, um fluxo de alterações monitoriza todas as transações de escrita na base de dados, porque a opção allow_txn_exclusion DDL está definida como false. Pode definir a opção allow_txn_exclusion como true para permitir que a sua stream de alterações ignore registos de transações de escrita especificadas. Se não definir esta opção como true, todas as transações de escrita são monitorizadas, mesmo que use o parâmetro exclude_txn_from_change_streams na sua transação de escrita.

Pode ativar esta opção quando cria uma stream de alterações ou modificar uma stream de alterações existente.

Exclua a transação de escrita dos fluxos de alterações

Para excluir uma transação de escrita de streams de alterações, tem de definir o parâmetro exclude_txn_from_change_streams como true. Este parâmetro faz parte dos métodos TransactionOptions e BatchWriteRequest. O valor predefinido para este parâmetro é false. Pode definir este parâmetro com a API RPC, a API REST ou através das bibliotecas cliente. Para mais informações, consulte o artigo Especifique uma transação de escrita a excluir dos fluxos de alterações.

Não pode definir este parâmetro como true para transações só de leitura. Se o fizer, a API devolve um erro de argumento inválido.

Para colunas de monitorização de streams de alterações modificadas por transações, quando exclude_txn_from_change_streams está definido como true, são possíveis dois cenários:

  • Se a opção DDL allow_txn_exclusion estiver definida como true, as atualizações feitas nesta transação não são registadas no fluxo de alterações.
  • Se não definir a opção DDL allow_txn_exclusion ou se estiver definida como false, as atualizações feitas nesta transação são registadas no fluxo de alterações.

Se não definir a opção exclude_txn_from_change_streams ou se estiver definida como false, todas as colunas de monitorização de streams de alterações modificadas por transações capturam as atualizações feitas nessa transação.

Ler streams de alterações

O Spanner oferece várias formas de ler os dados de um fluxo de alterações:

  • Através do Dataflow, usando o conetor Apache Beam SpannerIO. Esta é a nossa solução recomendada para a maioria das aplicações de fluxo de alterações. A Google também fornece modelos do Dataflow para exemplos de utilização comuns.

  • Diretamente, através da API Spanner. Isto troca a abstração e as capacidades dos pipelines do Dataflow pela máxima velocidade e flexibilidade.

  • Através da utilização do conetor do Kafka baseado no Debezium para streams de alterações do Spanner. Este conetor transmite registos de alterações diretamente para tópicos do Kafka.

Pode fornecer isolamento parcial para leituras de streams de alterações através de leituras direcionadas. As leituras direcionadas podem ajudar a minimizar o impacto nas cargas de trabalho transacionais na sua base de dados. Pode usar a API Spanner para encaminhar leituras de streams de alterações para um tipo de réplica ou uma região específicos numa configuração de instâncias de várias regiões ou numa configuração regional personalizada com regiões só de leitura opcionais. Para mais informações, consulte leituras direcionadas.

Usar o Dataflow

Use o conetor Apache Beam SpannerIO para criar pipelines do Dataflow que leiam a partir de streams de alterações. Depois de configurar o conector com detalhes sobre uma stream de alterações específica, este gera automaticamente novos registos de alterações de dados num único conjunto de dados PCollection ilimitado, pronto para processamento adicional por transformações subsequentes no pipeline do Dataflow.

O Dataflow usa funções de janelas para dividir coleções ilimitadas em componentes lógicos ou janelas. Como resultado, o Dataflow oferece streaming quase em tempo real quando lê a partir de streams de alterações.

A Google fornece modelos que lhe permitem criar rapidamente pipelines do Dataflow para exemplos de utilização comuns de streams de alterações, incluindo o envio de todas as alterações de dados de uma stream para um conjunto de dados do BigQuery ou a respetiva cópia para um contentor do Cloud Storage.

Para uma vista geral mais detalhada de como as streams de alterações e o Dataflow funcionam em conjunto, consulte o artigo Crie ligações de streams de alterações com o Dataflow.

Usar a API

Em alternativa à utilização do Dataflow para criar pipelines de fluxo de alterações, pode escrever código que use a API Spanner para ler diretamente os registos de um fluxo de alterações. Isto permite-lhe ler registos de alterações de dados da mesma forma que o conector SpannerIO, fornecendo as latências mais baixas possíveis ao ler dados de fluxo de alterações em vez de oferecer a flexibilidade do Dataflow.

Para saber mais, consulte o artigo Consultar streams de alterações. Para uma discussão mais detalhada sobre como consultar streams de alterações e interpretar os registos devolvidos, consulte o artigo Partições, registos e consultas de streams de alterações.

Usar o conetor do Kafka

O conetor do Kafka envia diretamente registos de streams de alterações para um tópico do Kafka. Abstrai os detalhes da consulta de streams de alterações através da API Spanner.

Para saber como os fluxos de alterações e o conector do Kafka funcionam em conjunto, consulte o artigo Crie ligações de fluxos de alterações com o conector do Kafka.

Limites

Existem vários limites para os fluxos de alterações, incluindo o número máximo de fluxos de alterações que uma base de dados pode ter e o número máximo de fluxos que podem monitorizar uma única coluna. Para ver uma lista completa, consulte os limites do fluxo de alterações.

Autorizações

As alterações de streams usam o seguinte:

  • A criação, a atualização ou a eliminação de streams de alterações requerem spanner.databases.updateDdl.

  • A leitura dos dados de uma stream de alterações requer spanner.databases.select.

Se usar o conetor SpannerIO, o proprietário da tarefa do Dataflow que lê os dados da stream de alterações requer autorizações do IAM adicionais, quer na base de dados da sua aplicação, quer numa base de dados de metadados separada. Consulte o artigo Crie uma base de dados de metadados.

O que se segue?