Considérations relatives à l’unité de partage des données en lecture et en écriture dans Amazon Redshift

Le partage de fonctions UDF SQL ne peut se faire que par l’intermédiaire d’unités de partage de données. Les systèmes UDF Python et Lambda ne sont pas pris en charge.

Si la base de données producteur a un classement spécifique, utilisez les mêmes paramètres de classement pour la base de données consommateur.

Amazon Redshift ne prend pas en charge les fonctions SQL imbriquées définies par l’utilisateur sur les clusters producteur.

Amazon Redshift ne prend pas en charge le partage de tables avec des clés de tri entrelacées et des vues qui font référence à des tables avec des clés de tri entrelacées.

Amazon Redshift ne prend pas en charge l’accès à un objet d’unité de partage des données pour lequel un DDL se produit simultanément entre la préparation et l’exécution de l’accès.

Amazon Redshift ne prend pas en charge le partage de procédures stockées via des unités de partage des données.

Amazon Redshift ne prend pas en charge le partage de vues système de métadonnées et de tables système.

Type de calcul : vous devez utiliser des groupes de travail sans serveur, des clusters ra3.large, ra3.xlplus, ra3.4xl ou ra3.16xl pour utiliser cette fonctionnalité.

Niveau d’isolement : le niveau d’isolement de la base de données doit être une isolement d’instantanés afin de permettre à d’autres groupes de travail sans serveur et clusters alloués d’y écrire.

Requêtes et transactions à instructions multiples : les requêtes à instructions multiples en dehors d’un bloc de transactions ne sont actuellement pas prises en charge. Par conséquent, si vous utilisez un éditeur de requêtes tel que dbeaver et que vous avez plusieurs requêtes d’écriture, vous devez les encapsuler dans une instruction de transaction BEGIN...END explicite.

Lorsque des instructions multicommandes sont utilisées en dehors des transactions, si la première commande est une écriture dans une base de données producteur, les commandes d’écriture suivantes dans l’instruction ne sont autorisées que dans cette base de données producteur. Si la première commande est une lecture, les commandes d’écriture suivantes ne sont autorisées que pour la base de données utilisée, si elles sont définies, sinon pour la base de données locale. Notez que les écritures d’une transaction ne sont prises en charge que dans une seule base de données.

Dimensionnement des consommateurs : les clusters consommateurs doivent comporter au moins 64 tranches pour effectuer des écritures à l’aide de l’unité de partage des données.

Vues et vues matérialisées : vous ne pouvez pas créer, mettre à jour ou modifier des vues ou des vues matérialisées dans une base de données d’unités de partage de données.

Sécurité : vous ne pouvez pas associer ou supprimer des politiques de sécurité telles que au niveau des colonnes (CLS), au niveau des lignes (RLS) et le masquage dynamique des données (DDM) aux objets d’unité de partage des données.

Facilité de gestion : les entrepôts consommateur ne peuvent pas ajouter d’objets d’unité de partage des données ou de vues qui font référence à des objets d’unité de partage des données à une autre unité de partage des données. Les consommateurs ne peuvent pas non plus modifier ou supprimer une unité de partage des données existante.

Opérations de troncation : les écritures d’unité de partage des données prennent en charge les troncations transactionnelles pour les tables distantes. Cela est différent des troncations que vous exécutez localement sur un cluster, qui sont validés automatiquement. Pour plus d’informations sur la commande SQL, consultez TRUNCATE.

Clonage : les instructions de clause CREATE TABLE with LIKE prennent en charge le clonage à partir d’une seule table parent lorsque vous écrivez depuis des entrepôts de consommateurs vers des producteurs.