Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la publicación del blog
Niveles de aislamiento en Amazon Redshift
Las operaciones de escritura simultáneas son compatibles con Amazon Redshift en modo protegido, con bloqueos de escritura en las tablas y el principio de aislamiento serializable. El aislamiento serializable conserva la ilusión de que una transacción que se ejecuta en una tabla es la única transacción ejecutándose en ella.
Las bases de datos de Amazon Redshift admiten operaciones de escritura simultáneas, ya que cada operación utiliza la última versión confirmada, o instantánea, de sus datos al inicio de la transacción. Una instantánea de base de datos se crea dentro de una transacción con la primera aparición de la mayoría de las instrucciones SELECT, los comandos DML como COPY, DELETE, INSERT, UPDATE y TRUNCATE, y los siguientes comandos DDL:
ALTER TABLE (para agregar o eliminar columnas)
CREATE TABLE
DROP TABLE
TRUNCATE TABLE
Ninguna otra transacción puede cambiar esta instantánea, lo que significa que las transacciones están aisladas unas de otras. Es decir, las transacciones simultáneas son invisibles entre sí, no pueden detectar los cambios de la otra.
Cualquier ejecución simultánea de transacciones debe producir los mismos resultados que la ejecución en serie de esas transacciones. Si ninguna ejecución en serie de esas transacciones puede producir los mismos resultados, la transacción que ejecuta una instrucción que podría afectar la capacidad de serialización se anula y revierte.
Por ejemplo, supongamos que un usuario intenta ejecutar dos transacciones simultáneas, T1 y T2. La ejecución de T1 y T2 debe producir los mismos resultados que al menos uno de los siguientes escenarios:
-
T1 y T2 se ejecutan en serie en ese orden.
-
T2 y T1 se ejecutan en serie en ese orden.
Los niveles de aislamiento de Amazon Redshift evitan los siguientes problemas:
Lecturas incorrectas: una lectura incorrecta se produce cuando una transacción lee datos que aún no se han confirmado. Por ejemplo, supongamos que la transacción 1 actualiza una fila. La transacción 2 lee la fila actualizada antes de que T1 confirme la actualización. Si T1 anula el cambio, T2 habrá leído los datos de las filas no confirmadas que Amazon Redshift considera ahora que nunca existieron.
Lecturas no repetibles: se produce una lectura no repetible cuando una sola transacción lee la misma fila dos veces, pero obtiene datos diferentes cada vez. Por ejemplo, supongamos que la transacción 1 lee una fila. La transacción 2 actualiza o elimina esa fila y confirma la actualización o la eliminación. Si T1 vuelve a leer la fila, recupera valores de fila diferentes o descubre que la fila se ha eliminado.
Fantasmas: un fantasma es una fila que coincide con los criterios de búsqueda pero que no se ve inicialmente. Por ejemplo, supongamos que la transacción 1 lee un conjunto de filas que cumplen sus criterios de búsqueda. La transacción 2 genera una nueva fila en una instrucción UPDATE o INSERT que coincide con los criterios de búsqueda de T1. Si T1 vuelve a ejecutar su instrucción de búsqueda, obtiene un conjunto de filas diferente.
Aislamiento SNAPSHOT y SERIALIZABLE
Los aislamientos SNAPSHOT y SERIALIZABLE son dos niveles de aislamiento serializable disponibles en Amazon Redshift.
El aislamiento SNAPSHOT es el nivel de aislamiento predeterminado al crear clústeres aprovisionados y grupos de trabajo sin servidor, lo que permite procesar volúmenes de datos más grandes que el aislamiento SERIALIZABLE en menos tiempo.
El aislamiento SERIALIZABLE lleva más tiempo, pero implementa restricciones más estrictas en las transacciones simultáneas. Este nivel de aislamiento evita problemas como las anomalías en el sesgo de escritura, ya que solo permite que se confirme una transacción y cancela todas las demás transacciones simultáneas con un error de infracción del aislamiento que se puede serializar.
A continuación, se muestra un ejemplo cronológico de cómo se gestionarían dos operaciones de escritura simultáneas al utilizar el aislamiento SNAPSHOT. La instrucción UPDATE de cada usuario puede confirmarse porque no entra en conflicto al intentar actualizar las mismas filas.
| Time | Acción del usuario 1 | Acción del usuario 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 | Actualizar número SET dígitos=0 WHERE dígitos=1; | |
| 9 | SELECT * FROM Numbers; digits ------ 1 1 |
|
| 10 | COMMIT; | |
| 11 | SELECT * FROM Numbers; digits ------ 1 0 |
|
| 12 | SELECT * FROM Numbers; digits ------ 1 0 |
Si se ejecuta el mismo escenario mediante aislamiento serializable, Amazon Redshift termina el usuario 2 debido a una infracción serializable y devuelve un error 1023. Para obtener más información, consulte Solución de problemas de errores de aislamiento serializable. En este caso, solo el usuario 1 puede confirmar correctamente.
Consideraciones
Cuando utilice niveles de aislamiento en Amazon Redshift, tenga en cuenta lo siguiente:
Consulte la vista del catálogo STV_DB_ISOLATION_LEVEL para ver qué nivel de aislamiento utiliza la base de datos. Para obtener más información, consulte STV_DB_ISOLATION_LEVEL.
Consulte la vista de PG_DATABASE_INFO para ver cuántas transacciones simultáneas se admiten para la base de datos. Para obtener más información, consulte PG_DATABASE_INFO.
Las tablas de catálogo del sistema (PG) y otras tablas del sistema de Amazon Redshift no se bloquean en una transacción. Por lo tanto, los cambios realizados en los objetos de base de datos que surjan de las operaciones DDL y TRUNCATE son visibles con cualquier transacción simultánea cuando se confirman.
Por ejemplo, supongamos que la tabla A existe en la base de datos al momento en que comienzan dos transacciones simultáneas, T1 y T2. Supongamos que T2 devuelve una lista de tablas al seleccionar las de la tabla de catálogo PG_TABLES. Luego T1 elimina la tabla A y confirma los cambios y, a continuación, T2 vuelve a especificar las tablas. La tabla A ya no aparece en la lista. Si T2 intenta ejecutar una consulta en la tabla eliminada, Amazon Redshift devuelve un error de tipo “la relación no existe”. La consulta de catálogo que le devuelve la lista de tablas a T2 o que verifica la existencia de la tabla A no se encuentra sujeta a las mismas reglas de aislamiento que las operaciones que se realizan en las tablas de usuario.
Las transacciones de las actualizaciones de estas tablas se ejecutan en un modo de aislamiento de lectura confirmada.
Las tablas de catálogo con el prefijo PG no son compatibles con el aislamiento de SNAPSHOT.
