O Amazon Redshift não permitirá mais a criação de funções definidas pelo usuário (UDFs) do Python a partir de 1.º de novembro de 2025. Se quiser usar UDFs do Python, você deve criá-las antes dessa data. As UDFs do Python existentes continuarão a funcionar normalmente. Para ter mais informações, consulte a publicação de blog
Níveis de isolamento no Amazon Redshift
As operações de gravação simultâneas são aceitas no Amazon Redshift de forma protetora, usando bloqueios de gravação em tabelas e o princípio de isolamento serializável. O isolamento serializável preserva a ilusão de que uma transação em execução em uma tabela é a única transação em execução naquela tabela.
Os bancos de dados do Amazon Redshift comportam operações de gravação simultâneas fazendo com que cada operação use a versão confirmada mais recente, ou o snapshot, de seus dados no início da transação. Um snapshot do banco de dados é criado em uma transação na primeira ocorrência da maioria das instruções SELECT, comandos DML tais como COPY, DELETE, INSERT, UPDATE e TRUNCATE, e após os seguintes comandos DDL:
ALTER TABLE (para adicional ou descartar colunas)
CRIAR TABELA
DESCARTAR TABELA
TRUNCATE TABLE
Nenhuma outra transação consegue alterar esse snapshot, o que significa que as transações são isoladas umas das outras. Ou seja, as transações simultâneas são invisíveis entre si; não podem detectar as alterações uma das outras.
Qualquer execução simultânea de transações deve produzir os mesmos resultados que a execução em série dessas transações. Se nenhuma execução serial dessas transações pode produzir os mesmos resultados, a transação que executa uma instrução que pode quebrar a capacidade de serializar é interrompida e revertida.
Por exemplo, suponha que um usuário tente executar duas transações simultâneas, T1 e T2. A execução de T1 e T2 deve produzir os mesmos resultados de pelo menos um dos seguintes casos:
-
T1 e T2 são executadas em série nessa ordem.
-
T2 e T1 são executadas em série nessa ordem.
Os níveis de isolamento no Amazon Redshift evitam os seguintes problemas:
Leituras sujas: uma leitura suja ocorre quando uma transação lê dados que ainda não foram confirmados. Por exemplo, suponha que a transação 1 atualize uma linha. A transação 2 lê a linha atualizada antes que T1 confirme a atualização. Se T1 reverter a alteração, T2 terá lido dados em linhas não confirmadas que o Amazon Redshift agora considera que nunca existiram.
Leituras não repetíveis: uma leitura não repetível ocorre quando uma única transação lê a mesma linha duas vezes, mas recebe dados diferentes a cada vez. Por exemplo, digamos que a transação 1 leia uma linha. A transação 2 atualiza ou exclui essa linha e confirma a atualização ou exclusão. Se T1 reler a linha, recuperará valores de linha diferentes ou descobrirá que a linha foi excluída.
Fantasmas: fantasma é uma linha que corresponde aos critérios de pesquisa, mas não é vista inicialmente. Por exemplo, suponha que a transação 1 leia um conjunto de linhas que atenda aos seus critérios de pesquisa. A transação 2 gera uma nova linha em uma instrução UPDATE ou INSERT que corresponda aos critérios de pesquisa para T1. Se T1 executar novamente sua instrução de pesquisa, ele receberá um conjunto diferente de linhas.
Isolamento SNAPSHOT e SERIALIZABLE
Os isolamentos SNAPSHOT e SERIALIZABLE são os dois níveis de isolamento serializáveis disponíveis no Amazon Redshift.
O isolamento SNAPSHOT é o nível de isolamento padrão ao criar clusters provisionados e grupos de trabalho sem servidor, permitindo processar volumes maiores de dados do que o isolamento SERIALIZABLE em menos tempo.
O isolamento SERIALIZABLE leva mais tempo, mas implementa restrições mais rígidas em transações simultâneas. Esse nível de isolamento evita problemas, como anomalias de distorção de gravação, permitindo que apenas uma transação seja confirmada, enquanto cancela todas as outras transações simultâneas com um erro de violação de isolamento serializável.
Veja a seguir um exemplo de cronograma de como duas operações de gravação simultâneas seriam tratadas ao usar o isolamento SNAPSHOT. A declaração UPDATE de cada usuário pode ser confirmada porque ela não entra em conflito ao tentar atualizar as mesmas linhas.
| Hora | Ação do usuário 1 | Ação do usuário 2 |
|---|---|---|
| 1 | BEGIN; | |
| 2 | BEGIN; | |
| 3 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 4 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 5 | UPDATE Numbers SET digits=0 WHERE digits=1; | |
| 6 | SELECT * FROM Numbers; digits ------ 0 0 |
|
| 7 | COMMIT; | |
| 8 | Update Numbers SET digits=1 WHERE digits=0; | |
| 9 | SELECT * FROM Numbers; digits ------ 1 1 |
|
| 10 | COMMIT; | |
| 11 | SELECT * FROM Numbers; digits ------ 1 0 |
|
| 12 | SELECT * FROM Numbers; digits ------ 1 0 |
Se o mesmo cenário for executado usando o isolamento serializável, o Amazon Redshift encerrará o usuário 2 devido a uma violação serializável e retornará um erro 1023. Para obter mais informações, consulte Solucionar problemas de erros de isolamento serializável. Nesse caso, somente o usuário 1 pode confirmar com sucesso.
Considerações
Ao usar os níveis de isolamento no Amazon Redshift, pense no seguinte:
Consulte a visualização do catálogo STV_DB_ISOLATION_LEVEL para visualizar o nível de isolamento que seu banco de dados está usando. Para obter mais informações, consulte STV_DB_ISOLATION_LEVEL.
Consulte a visualização PG_DATABASE_INFO para ver quantas transações simultâneas são aceitas em seu banco de dados. Para obter mais informações, consulte PG_DATABASE_INFO.
As tabelas de catálogo de sistema (PG) e outras tabelas de sistema do Amazon Redshift não são bloqueadas em uma transação. Portanto, alterações nos objetos do banco de dados decorrentes de operações DDL e TRUNCATE são visíveis na confirmação para quaisquer transações simultâneas.
Por exemplo, suponha que a tabela A exista no banco de dados quando duas transações simultâneas, T1 e T2, começam. Suponha que T2 retorna uma lista de tabelas selecionando na tabela de catálogo PG_TABLES. Em seguida, T1 descarta a tabela A e confirmações e, em seguida, T2 lista as tabelas novamente. A tabela A agora não está mais listada. Se T2 tentar consultar a tabela descartada, o Amazon Redshift retornará um erro "relação não existe". A consulta de catálogo que retorna a lista de tabelas para T2 ou verifica se a tabela A existe não está sujeita às mesmas regras de isolamento que as operações realizadas nas tabelas do usuário.
Transações para atualizações dessas tabelas são executadas em um modo de isolamento de leitura confirmada.
As tabelas de catálogo com prefixo PG não aceitam o isolamento SNAPSHOT.
