

 Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Considerazioni generali sulla condivisione di dati in Amazon Redshift
<a name="considerations-datashare-general"></a>

Le seguenti sono considerazioni generali relative all’utilizzo delle unità di condivisione dati in Amazon Redshift:
+ *Database predefinito*: quando leggi i dati da un’unità di condivisione dati, rimani connesso al database del cluster locale. Per ulteriori informazioni sulla configurazione e sulla lettura da un database creato da un’unità di condivisione dati, consulta [Esecuzione di query sugli oggetti dell’unità di condivisione dati](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-datashare-using.html#query-editor-v2-datashare-consumer) e [Viste materializzate per le tabelle di data lake esterne in Amazon Redshift SpectrumViste materializzate per le tabelle di data lake esterne](materialized-view-external-table.md).
+ *Connessioni*: deve essere connesso direttamente a un database dell’unità di condivisione dati o eseguire il comando USE per scrivere nelle unità di condivisione dati. Puoi anche utilizzare una notazione in tre parti. Il comando USE non è supportato per le tabelle esterne. 
+ *Prestazioni*: le prestazioni delle query sui dati condivisi dipendono dalla capacità di calcolo dei cluster consumer.
+ *Costi di trasferimento dei dati*: la condivisione dei dati tra Regioni include costi aggiuntivi per il trasferimento dei dati tra Regioni. 
  + Questi costi di trasferimento dei dati non si applicano all’interno della stessa Regione, ma solo tra Regioni. Per ulteriori informazioni, consulta [Gestione del controllo dei costi per la condivisione dei dati tra regioni](cross-region-billing.md). 
  + Al consumer vengono addebitati tutti i costi di calcolo e di trasferimento di dati tra regioni necessari per eseguire query sui dati del producer. Al producer vengono addebitati i costi per l'archiviazione sottostante dei dati nel cluster con provisioning o nello spazio dei nomi serverless.
+ *Condivisione dei dati all’interno di e tra cluster*: devi utilizzare le unità di condivisione dati solo quando condividi i dati tra diversi cluster con provisioning o gruppi di lavoro serverless Amazon Redshift. All'interno dello stesso cluster, è possibile eseguire query su un altro database utilizzando una semplice notazione in tre parti `database.schema.table` purché si disponga delle autorizzazioni richieste per gli oggetti dell'altro database.
+ *Rilevamento dei metadati*: un consumer connesso direttamente a un database dell’unità di condivisione dati tramite i driver JDBC, ODBC o Python Redshift può visualizzare i dati del catalogo nei seguenti modi: 
  + Comandi SQL [SHOW](https://docs.aws.amazon.com/redshift/latest/dg/r_SHOW.html).
  + Query su tabelle e viste information\$1schema.
  + Query su [viste SVV dei metadati](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html).
+ *Visibilità delle autorizzazioni*: i consumer possono vedere le autorizzazioni concesse alle unità di condivisione dati tramite il comando SQL SHOW GRANTS.
+ *Gestione della crittografia dei cluster per la condivisione dei dati*: per condividere i dati su un cluster Account AWS, sia il cluster di produttori che quello di consumatori devono essere crittografati. 
  + Se i cluster di producer e consumer e i namespace serverless si trovano nello stesso account, devono avere lo stesso tipo di crittografia (entrambi non crittografati o entrambi crittografati). In tutti gli altri casi, comprese le unità di condivisione dati gestite da Lake Formation, sia il consumer che il producer devono essere crittografati. Questo è per motivi di sicurezza. Tuttavia, non è necessario che condividano la stessa chiave di crittografia.
  + Per proteggere i dati in transito, tutti i dati vengono crittografati in transito attraverso lo schema di crittografia del cluster producer. Il cluster consumer adotta questo schema di crittografia quando vengono caricati i dati. Il cluster consumer funziona quindi come un normale cluster crittografato. Anche le comunicazioni tra produttore e consumatore vengono crittografate utilizzando uno schema a chiave condivisa. Per ulteriori informazioni sulla crittografia in transito, consultare [Crittografia in transito](https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption-in-transit.html).