Spanner: Transações mais robustas para dados em larga escala

O Google Cloud Spanner, reconhecido por sua escalabilidade horizontal e alta disponibilidade, anuncia uma novidade que promete simplificar o gerenciamento de transações mais complexas e volumosas. A plataforma, que já é a espinha dorsal de workloads críticos em setores como financeiro, varejo e mídia, agora oferece uma maneira mais flexível de lidar com operações de dados, mantendo a consistência em níveis elevados.

Spanner Amplia Limites de Transações DML para Maior Flexibilidade

A eficiência operacional em muitas aplicações modernas depende da combinação de decisões em tempo real com atualizações de dados granulares. Pense, por exemplo, em um processo de checkout em um e-commerce, onde a detecção de fraude deve ocorrer de forma transacional. Essas operações precisam ser atômicas: ou todas as alterações são aplicadas com sucesso, ou nenhuma delas é executada, garantindo que as requisições subsequentes acessem dados consistentes. A nova atualização do Spanner nas transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) permite que as aplicações processem um volume maior de dados em uma única atualização, sem comprometer a consistência, escalabilidade ou disponibilidade, tudo isso utilizando a familiar Linguagem de Manipulação de Dados (DML).

Um Teto Mais Alto e Maior Liberdade para Desenvolvedores

Anteriormente, o Spanner impunha um limite de 80.000 "mutation mods" (modificações de dados) por transação ao utilizar DML. Esse limite era calculado com base no número de linhas e colunas atualizadas, somado a quaisquer índices dependentes. Com a evolução das aplicações, que naturalmente tendem a gerenciar mais dados e oferecer novas funcionalidades, transações antes consideradas pequenas podiam atingir esse limite, exigindo refatorações complexas.

A mudança fundamental introduzida é o deslocamento do limite de 80.000 "mutation mods" do nível transacional para cada declaração DML individual. Isso significa que as declarações DML, como INSERT, UPDATE ou DELETE, não contribuem mais para um limite cumulativo da transação. Uma única transação agora pode conter um número ilimitado de declarações DML, desde que cada declaração individual gere menos de 80.000 "mutation mods".

Benefícios Chave da Nova Abordagem

1. Transações Mais Amplas: Desenvolvedores podem agrupar declarações DML logicamente com base nos requisitos de negócio, em vez de fragmentá-las artificialmente para contornar os limites de mutação cumulativa.
2. Transição Transparente: Esta atualização é totalmente compatível com as bibliotecas cliente do Spanner existentes, dispensando a necessidade de atualizações no código da aplicação.

Considerações Técnicas Importantes

Locking e Aborts

Embora a capacidade de incluir mais declarações DML em uma única transação seja um avanço, é crucial notar que transações maiores e de longa duração manterão locks por períodos mais extensos. Isso pode aumentar a probabilidade de contensão de locks e aborts de transação. Manter as transações concisas continua sendo uma prática recomendada para garantir alta performance e minimizar a contenção de recursos.

DML vs. Mutation API

A aplicação dos limites de mutação difere dependendo do método utilizado para modificar os dados:

• Declarações DML: Cada declaração (ex: `executeUpdate`) é avaliada independentemente contra o limite de 80.000 "mutation mods".
• Mutation API: Ao usar métodos de bibliotecas cliente como `insert()` ou `update()`, as mutações são fornecidas durante a chamada de `Commit`. O limite de 80.000 continua a ser aplicado ao conjunto completo de mutações incluídas nessa única chamada.

Entendendo "Mutation Mods"

O Spanner contabiliza "mods" com base na complexidade das alterações, o que inclui células modificadas, chaves primárias e atualizações de índices secundários. Para detalhes aprofundados sobre como as mutações são contadas, consulte a documentação oficial. É possível monitorar o total de "mods" de uma transação confirmada através do `mutation_count` em `CommitStats`. Note que este contador incluirá todas as mutações pertencentes à transação, abrangendo todas as declarações DML e chamadas de commit.

Exemplo de Implementação em Java

O exemplo a seguir ilustra como múltiplas declarações DML podem ser executadas dentro de uma única transação sob a nova lógica de limites:

import com.google.cloud.spanner.DatabaseClient;
import com.google.cloud.spanner.Statement;
import com.google.cloud.spanner.TransactionContext;
import com.google.cloud.spanner.TransactionRunner.Work;

// Assumindo que dbClient é o seu DatabaseClient inicializado
dbClient
    .readWriteTransaction()
    .run(
        new Work() {
          @Override
          public Void doWork(TransactionContext transaction) throws Exception {
            // Cada chamada a executeUpdate é avaliada separadamente contra o limite de 80k mods.

            // Exemplo 1: Atualizando produtos específicos
            Statement stmt1 = Statement.newBuilder(
                        "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")
                    .bind("productId").to(1L)
                    .build();
            transaction.executeUpdate(stmt1); // Verificado contra o limite de 80k

            Statement stmt2 = Statement.newBuilder(
                        "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")
                    .bind("productId").to(2L)
                    .build();
            transaction.executeUpdate(stmt2); // Verificado separadamente contra o limite de 80k

            // Exemplo 2: Inserindo dados relacionados de pedidos
            Statement stmt3 = Statement.newBuilder(
                        "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")
                    .bind("orderId").to(100L)
                    .bind("itemId").to(1L)
                    .bind("qty").to(2)
                    .build();
            transaction.executeUpdate(stmt3); 

            Statement stmt4 = Statement.newBuilder(
                        "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")
                    .bind("orderId").to(100L)
                    .build();
            transaction.executeUpdate(stmt4); 

            return null;
          }
        });

O Que Permanece Igual

• Limite da Declaração Individual: Qualquer declaração DML única que gere mais de 80.000 "mods" continuará a retornar o mesmo erro que ocorre atualmente.
• Outros Limites Transacionais: Restrições como o tamanho máximo de transação em bytes permanecem em vigor. Detalhes podem ser encontrados nas quotas do Google Cloud Spanner.

Melhores Práticas

• Monitorar CommitStats: Utilize o `mutation_count` retornado em `CommitStats` para entender a carga gerada por suas operações.
• Manter Transações Concisas: Para garantir a melhor performance e minimizar a contenção, sempre que possível, mantenha as transações focadas em um conjunto lógico de operações relacionadas.