Guida alla traduzione SQL di Teradata
Questo documento descrive le somiglianze e le differenze nella sintassi SQL tra Teradata e BigQuery per aiutarti a pianificare la migrazione. Utilizza la traduzione SQL batch per eseguire la migrazione in blocco degli script SQL o la traduzione SQL interattiva per tradurre query ad hoc.
Tipi di dati
Questa sezione mostra gli equivalenti tra i tipi di dati in Teradata e in BigQuery.
Teradata | BigQuery | Note |
---|---|---|
INTEGER |
INT64 |
|
SMALLINT |
INT64 |
|
BYTEINT |
INT64 |
|
BIGINT |
INT64 |
|
DECIMAL |
Utilizza Utilizza i tipi di dati decimali con parametri di BigQuery se devi applicare limiti di cifre o di scalabilità personalizzati (vincoli). Teradata consente di inserire valori con una precisione maggiore arrotondando il valore archiviato. Tuttavia, mantiene un'elevata precisione nei calcoli. Ciò può causare un comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
FLOAT |
FLOAT64 |
|
NUMERIC |
Utilizza Utilizza i tipi di dati decimali con parametri di BigQuery se devi applicare limiti di cifre o di scalabilità personalizzati (vincoli). Teradata consente di inserire valori con una precisione maggiore arrotondando il valore archiviato. Tuttavia, mantiene un'elevata precisione nei calcoli. Ciò può causare un comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
NUMBER |
Utilizza Utilizza i tipi di dati decimali con parametri di BigQuery se devi applicare limiti di cifre o di scalabilità personalizzati (vincoli). Teradata consente di inserire valori con una precisione maggiore arrotondando il valore archiviato. Tuttavia, mantiene un'elevata precisione nei calcoli. Ciò può causare un comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
REAL |
FLOAT64 |
|
CHAR/CHARACTER |
STRING |
Utilizza il tipo di dati |
VARCHAR |
STRING |
Utilizza il tipo di dati |
CLOB |
STRING |
|
JSON |
JSON |
|
BLOB |
BYTES |
|
BYTE |
BYTES |
|
VARBYTE |
BYTES |
|
DATE |
DATE |
BigQuery non supporta una formattazione personalizzata simile a quella supportata da Teradata con DataForm nei file SDF. |
TIME |
TIME |
|
TIME WITH TIME ZONE |
TIME |
Teradata archivia il tipo di dati TIME nel fuso orario UTC e consente di
passare un offset da UTC utilizzando la sintassi WITH TIME ZONE .
Il tipo di dati TIME in BigQuery
rappresenta un'ora indipendente da qualsiasi data o fuso orario. |
TIMESTAMP |
TIMESTAMP |
Entrambi i tipi di dati Teradata e BigQuery TIMESTAMP hanno una precisione in microsecondi (ma Teradata supporta i secondi intercalari, contrariamente a BigQuery).Entrambi i tipi di dati Teradata e BigQuery sono generalmente associati al fuso orario UTC (dettagli). |
TIMESTAMP WITH TIME ZONE |
TIMESTAMP |
Il campo Teradata TIMESTAMP può essere impostato su un fuso orario
diverso a livello di sistema, per utente o per colonna (utilizzando
WITH TIME ZONE ).Il tipo TIMESTAMP di BigQuery presuppone l'UTC se non
specifichi esplicitamente un fuso orario. Assicurati di esportare correttamente le informazioni sul fuso orario (non concatenare un valore DATE e TIME senza informazioni sul fuso orario) in modo che BigQuery possa convertirle al momento dell'importazione. In alternativa, assicurati di convertire le informazioni sul fuso orario in UTC prima di esportarle.BigQuery ha DATETIME per un'astrazione
tra l'ora civile, che non mostra un fuso orario quando viene generata, e
TIMESTAMP , che è un momento preciso che mostra sempre
il fuso orario UTC. |
ARRAY |
ARRAY |
|
MULTI-DIMENSIONAL ARRAY |
ARRAY |
In BigQuery, utilizza un array di struct, dove ogni struct contiene un campo di tipo ARRAY (per maggiori dettagli, consulta la
documentazione di BigQuery). |
INTERVAL HOUR |
INT64 |
|
INTERVAL MINUTE |
INT64 |
|
INTERVAL SECOND |
INT64 |
|
INTERVAL DAY |
INT64 |
|
INTERVAL MONTH |
INT64 |
|
INTERVAL YEAR |
INT64 |
|
PERIOD(DATE) |
DATE e DATE |
PERIOD(DATE) deve essere convertito in due colonne DATE
contenenti la data di inizio e la data di fine in modo da poter essere utilizzate
con le funzioni finestra. |
PERIOD(TIMESTAMP WITH TIME ZONE) |
TIMESTAMP e TIMESTAMP |
|
PERIOD(TIMESTAMP) |
TIMESTAMP e TIMESTAMP |
|
PERIOD(TIME) |
TIME e TIME |
|
PERIOD(TIME WITH TIME ZONE) |
TIME e TIME |
|
UDT |
STRING |
|
XML |
STRING |
|
TD_ANYTYPE |
STRING |
Per ulteriori informazioni sulla trasmissione del tipo, consulta la sezione successiva.
Formattazione del tipo Teradata
Teradata SQL utilizza un insieme di formati predefiniti per la visualizzazione di espressioni e dati delle colonne e per le conversioni tra tipi di dati. Ad esempio, un tipo di dati PERIOD(DATE)
in modalità INTEGERDATE
è formattato come YY/MM/DD
per impostazione predefinita. Ti consigliamo di utilizzare la modalità ANSIDATE, quando possibile, per garantire
la conformità ad ANSI SQL e di sfruttare questa occasione per eliminare i formati precedenti.
Teradata consente l'applicazione automatica di formati personalizzati utilizzando la clausola FORMAT
, senza modificare l'archiviazione sottostante, come attributo del tipo di dati quando crei una tabella utilizzando DDL o in un'espressione derivata. Ad
esempio, la specifica FORMAT
9.99
arrotonda qualsiasi valore FLOAT
a due cifre.
In BigQuery, questa funzionalità deve essere convertita usando la
funzione ROUND()
.
Questa funzionalità richiede la gestione di complessi casi limite. Ad esempio,
quando la clausola FORMAT
viene applicata a una colonna NUMERIC
, devi tenere conto delle
regole di arrotondamento e formattazione speciali dell'account.
Puoi usare una clausola FORMAT
per trasmettere in modo implicito un valore dell'epoca INTEGER
in un formato
DATE
. Oppure una specifica FORMAT
X(6)
su una colonna VARCHAR
tronca il valore della colonna e pertanto devi convertirlo in una funzione
SUBSTR()
. Questo comportamento non è conforme ad ANSI SQL. Consigliamo quindi di non eseguire la migrazione
dei formati colonna a BigQuery.
Se i formati colonna sono assolutamente necessari, utilizza gli elementi View o funzioni definite dall'utente.
Per informazioni sui formati predefiniti utilizzati da Teradata SQL per ogni tipo di dati, consulta la documentazione sulla formattazione predefinita di Teradata.
Formattazione di timestamp e tipo di data
La tabella seguente riassume le differenze negli elementi di formattazione data e timestamp tra Teradata SQL e GoogleSQL.
Formato Teradata | Descrizione Teradata | BigQuery |
---|---|---|
CURRENT_TIMESTAMP
|
Le informazioni relative a TIME e TIMESTAMP in Teradata possono
avere informazioni sul fuso orario diverse, definite utilizzando WITH
TIME ZONE .
|
Se possibile, utilizza CURRENT_TIMESTAMP() , che è formattato in formato ISO. Tuttavia, il formato di output mostra sempre il fuso orario UTC.
Internamente, BigQuery non ha un fuso orario.Prendi nota dei seguenti dettagli sulle differenze nel formato ISO. Il formato DATETIME è formattato in base alle convenzioni del canale di output. Nello strumento a riga di comando di BigQuery e nella console BigQuery, questo viene formattato utilizzando un separatore T secondo RFC 3339. Tuttavia, in JDBC per Python e Java, uno spazio viene utilizzato come separatore.Se vuoi usare un formato esplicito, usa FORMAT_DATETIME() ,
che determina la trasmissione di una stringa in modo esplicito. Ad esempio, la seguente
espressione restituisce sempre un separatore di spazi:CAST(CURRENT_DATETIME() AS STRING) Teradata supporta una parola chiave DEFAULT
nelle colonne TIME per impostare l'ora attuale (timestamp);
non viene utilizzata in BigQuery.
|
CURRENT_DATE |
Le date vengono archiviate in Teradata come valori INT64 utilizzando la
seguente formula:(YEAR - 1900) * 10000 + (MONTH * 100) + DAY Le date possono essere formattate come numeri interi. |
BigQuery ha un formato DATE separato che restituisce sempre una data in formato ISO 8601.DATE_FROM_UNIX_DATE non può essere utilizzato perché è basato sul 1970.Per impostare la data corrente, Teradata supporta una parola chiave DEFAULT
nelle colonne DATE ; non viene
utilizzata in BigQuery.
|
CURRENT_DATE-3 |
I valori delle date sono rappresentati come numeri interi. Teradata supporta operatori aritmetici per i tipi di date. |
Per i tipi di data, utilizza DATE_ADD()
o
DATE_SUB() .BigQuery utilizza operatori aritmetici per i tipi di dati: INT64 , NUMERIC e FLOAT64 .
|
SYS_CALENDAR.CALENDAR |
Teradata offre una visualizzazione per consentire alle operazioni di calendario di andare oltre le operazioni con numeri interi. | Non utilizzato in BigQuery. |
SET SESSION DATEFORM=ANSIDATE |
Imposta il formato della data della sessione o del sistema su ANSI (ISO 8601). | BigQuery utilizza sempre ISO 8601, quindi assicurati di convertire date e ore di Teradata. |
Sintassi delle query
Questa sezione illustra le differenze nella sintassi delle query tra Teradata e BigQuery.
Istruzione SELECT
La maggior parte delle istruzioni SELECT
Teradata è compatibile con BigQuery. La seguente tabella contiene un elenco
di differenze di minore entità.
Teradata | BigQuery | |
---|---|---|
SEL |
Converti in SELECT . BigQuery non utilizza
l'abbreviazione SEL . |
|
SELECT
|
In BigQuery, le colonne non possono fare riferimento all'output di altre colonne definite nello stesso elenco di selezione. Preferisci spostare una sottoquery
in una clausola WITH .
WITH flags AS (
|
|
SELECT * FROM table
|
BigQuery non utilizza il predicato logico
ANY .La stessa funzionalità può essere ottenuta utilizzando più operatori OR :SELECT * FROM table In questo caso, anche il confronto di stringhe è diverso. Consulta la sezione Operatori di confronto. |
|
SELECT TOP 10 * FROM table
|
BigQuery utilizza LIMIT
alla fine di una query anziché TOP n dopo
la parola chiave SELECT .
|
Operatori di confronto
La tabella seguente mostra gli operatori di confronto di Teradata specifici per Teradata e che devono essere convertiti negli operatori conformi ad ANSI SQL:2011 utilizzati in BigQuery.
Per informazioni sugli operatori in BigQuery, consulta la sezione Operatori della documentazione di BigQuery.
Teradata | BigQuery | Note |
---|---|---|
exp EQ exp2 exp IN (exp2, exp3)
|
exp = exp2 exp IN (exp2, exp3) Per mantenere una semantica non ANSI per NOT CASESPECIFIC , puoi utilizzare RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
|
Quando confronti le stringhe per stabilire l'uguaglianza, Teradata potrebbe ignorare gli spazi vuoti finali, mentre BigQuery li considera parte della stringa. Ad esempio, 'xyz'=' xyz' è TRUE in Teradata, ma FALSE in BigQuery.Teradata fornisce anche un attributo di colonna
NOT CASESPECIFIC
che indica a Teradata di ignorare
maiuscole e minuscole quando confronta due stringhe. BigQuery è sempre specifico per le maiuscole e le minuscole quando confronti le stringhe. Ad esempio, 'xYz' = 'xyz' è
TRUE in Teradata, ma FALSE in BigQuery.
|
exp LE exp2 |
exp <= exp2 |
|
exp LT exp2 |
exp < exp2 |
|
exp NE exp2 |
exp <> exp2
|
|
exp GE exp2 |
exp >= exp2 |
|
exp GT exp2 |
exp > exp2 |
JOIN
condizioni
BigQuery e Teradata supportano le stesse condizioni JOIN
,
ON
e USING
. La seguente tabella contiene un elenco di differenze di minore entità.
Teradata | BigQuery | Note |
---|---|---|
FROM A LEFT OUTER JOIN B ON A.date >
B.start_date AND A.date < B.end_date
|
FROM A LEFT OUTER JOIN (SELECT d FROM B JOIN
UNNEST(GENERATE_DATE_ARRAY(B.start_date, B.end_date)) d)
B ON A.date = B.date
|
BigQuery supporta le clausole di disuguaglianza JOIN per
tutti i join inner o se viene assegnata almeno una condizione di uguaglianza (=). Non è
solo una condizione di disuguaglianza (= e <) in un elemento OUTER JOIN .
Questi costrutti vengono talvolta utilizzati per eseguire query su intervalli di date o interi.
BigQuery impedisce agli utenti di creare inavvertitamente cross join di grandi dimensioni.
|
FROM A, B ON A.id = B.id
|
FROM A JOIN B ON A.id = B.id
|
La virgola tra le tabelle in Teradata equivale a INNER JOIN ,
mentre in BigQuery equivale a CROSS JOIN
(prodotto cartesiano). Poiché la virgola in BigQuery
SQL precedente viene considerata come UNION , ti consigliamo di rendere esplicita l'operazione per evitare confusione.
|
FROM A JOIN B ON
(COALESCE(A.id , 0) = COALESCE(B.id, 0))
|
FROM A JOIN B ON
(COALESCE(A.id , 0) = COALESCE(B.id, 0))
|
Nessuna differenza per le funzioni scalari (costanti). |
FROM A JOIN B ON
A.id = (SELECT MAX(B.id) FROM B)
|
FROM A JOIN (SELECT MAX(B.id) FROM B)
B1 ON A.id = B1.id
|
BigQuery impedisce agli utenti di utilizzare sottoquery, sottoquery correlate o aggregazioni nei predicati di join. Ciò consente a BigQuery di caricare in contemporanea le query. |
Tipo di conversione e trasmissione
BigQuery ha tipi di dati meno numerosi, ma più ampi di Teradata, per cui la trasmissione deve essere più restrittiva.
Teradata | BigQuery | Note |
---|---|---|
exp EQ exp2 exp IN (exp2, exp3)
|
exp = exp2 exp IN (exp2, exp3) Per mantenere una semantica non ANSI per NOT CASESPECIFIC , puoi utilizzare RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
|
Quando confronti le stringhe per stabilire l'uguaglianza, Teradata potrebbe ignorare gli spazi vuoti finali, mentre BigQuery li considera parte della stringa. Ad esempio, 'xyz'=' xyz' è TRUE in Teradata, ma FALSE in BigQuery.Teradata fornisce anche un attributo di colonna
NOT CASESPECIFIC
che indica a Teradata di ignorare
maiuscole e minuscole quando confronta due stringhe. BigQuery è sempre specifico per le maiuscole e le minuscole quando confronti le stringhe. Ad esempio, 'xYz' = 'xyz' è
TRUE in Teradata, ma FALSE in BigQuery.
|
CAST(long_varchar_column AS CHAR(6))
|
LPAD(long_varchar_column, 6)
|
La trasmissione di una colonna di caratteri in Teradata viene a volte utilizzata come modo non standard e non ottimale per creare una sottostringa riempita. |
CAST(92617 AS TIME)
92617 (FORMAT '99:99:99')
|
PARSE_TIME("%k%M%S", CAST(92617 AS STRING)) |
Teradata esegue molti conversioni di tipo implicite e arrotondamenti rispetto a BigQuery, che in genere è più restrittivo e applica gli standard ANSI.
(Questo esempio restituisce 09:26:17). |
CAST(48.5 (FORMAT 'zz') AS FLOAT)
|
CAST(SUBSTR(CAST(48.5 AS STRING), 0, 2) AS FLOAT64) |
I tipi di dati con virgola mobile e numerici possono richiedere regole di arrotondamento speciali se applicati con formati come le valute.
(questo esempio restituisce 48) |
Vedi anche Operatori di confronto e Formati colonna. Sia i confronti che la formattazione delle colonne possono comportarsi come le trasmissioni del tipo.
QUALIFY
, ROWS
clausole
La clausola QUALIFY
in Teradata consente di
filtrare i risultati per le funzioni finestra.
In alternativa, per la stessa attività è possibile utilizzare una
frase ROWS
. Funzionano in modo simile a una condizione HAVING
per una
clausola GROUP
, limitando l'output delle
funzioni finestra in BigQuery.
Teradata | BigQuery |
---|---|
SELECT col1, col2
|
La clausola QUALIFY di Teradata con una funzione
finestra come ROW_NUMBER() , SUM() ,
COUNT() e con OVER PARTITION BY è espressa in BigQuery come clausola WHERE in una sottoquery
che contiene un valore di analisi. Utilizzo di ROW_NUMBER() :SELECT col1, col2 Utilizzo di ARRAY_AGG , che supporta partizioni più grandi:
SELECT
|
SELECT col1, col2
|
SELECT col1, col2 In BigQuery, nella clausola relativa al frame della finestra possono essere utilizzati sia RANGE sia ROWS . Tuttavia, le clausole finestra possono essere
utilizzate solo con funzioni finestra come AVG() , non con funzioni
di numerazione come ROW_NUMBER() . |
NORMALIZE
parola chiave
Teradata fornisce la parola chiave NORMALIZE
per le clausole SELECT
per unire periodi o intervalli che si sovrappongono in un singolo periodo o intervallo che includa tutti i singoli valori di periodo.
BigQuery non supporta il tipo PERIOD
, pertanto qualsiasi colonna di tipo PERIOD
in Teradata deve essere inserita in BigQuery come due campi DATE
o DATETIME
separati che corrispondono all'inizio e alla fine del periodo.
Teradata | BigQuery |
---|---|
SELECT NORMALIZE
|
SELECT
|
Funzioni
Le seguenti sezioni elencano le mappature tra le funzioni Teradata e gli equivalenti BigQuery.
Funzioni di aggregazione
La seguente tabella mappa le funzioni aggregate comuni di Teradata, di aggregazione statistica e di aggregazione approssimata agli equivalenti BigQuery. BigQuery offre le seguenti funzioni di aggregazione aggiuntive:
ANY_VALUE
APPROX_COUNT_DISTINCT
APPROX_QUANTILES
APPROX_TOP_COUNT
APPROX_TOP_SUM
COUNTIF
LOGICAL_AND
LOGICAL_OR
STRING_AGG
Teradata | BigQuery |
---|---|
AVG |
AVG |
BITAND |
BIT_AND |
BITNOT |
Operatore Bitwise
not (~ ) |
BITOR |
BIT_OR |
BITXOR |
BIT_XOR |
CORR |
CORR |
COUNT |
COUNT |
COVAR_POP |
COVAR_POP |
COVAR_SAMP |
COVAR_SAMP |
MAX |
MAX |
MIN |
MIN |
REGR_AVGX |
AVG( |
REGR_AVGY |
AVG( |
REGR_COUNT |
SUM( |
REGR_INTERCEPT |
AVG(dep_var_expression) - AVG(ind_var_expression) *
(COVAR_SAMP(ind_var_expression,
|
REGR_R2 |
(COUNT(dep_var_expression)* |
REGR_SLOPE |
- COVAR_SAMP(ind_var_expression, |
REGR_SXX |
SUM(POWER(ind_var_expression, 2)) -
COUNT(ind_var_expression) * |
REGR_SXY |
SUM(ind_var_expression * dep_var_expression) -
COUNT(ind_var_expression) |
REGR_SYY |
SUM(POWER(dep_var_expression, 2)) -
COUNT(dep_var_expression) |
SKEW |
Funzione definita dall'utente dall'utente. |
STDDEV_POP |
STDDEV_POP |
STDDEV_SAMP |
STDDEV_SAMP,
STDDEV |
SUM |
SUM |
VAR_POP |
VAR_POP |
VAR_SAMP |
VAR_SAMP,
VARIANCE |
Funzioni analitiche e funzioni finestra
La seguente tabella mappa le funzioni analitiche e di analisi aggregate comuni di Teradata agli equivalenti delle funzione finestra BigQuery. BigQuery offre le seguenti funzioni aggiuntive:
Funzioni di data/ora
La seguente tabella mappa le funzioni data/ora comuni di Teradata ai rispettivi equivalenti BigQuery. BigQuery offre le seguenti funzioni aggiuntive di data/ora:
CURRENT_DATETIME
DATE_ADD
DATE_DIFF
DATE_FROM_UNIX_DATE
DATE_SUB
DATE_TRUNC
DATETIME
DATETIME_ADD
DATETIME_DIFF
DATETIME_SUB
DATETIME_TRUNC
PARSE_DATE
PARSE_DATETIME
PARSE_TIME
PARSE_TIMESTAMP
STRING
TIME
TIME_ADD
TIME_DIFF
TIME_SUB
TIME_TRUNC
TIMESTAMP
TIMESTAMP_ADD
TIMESTAMP_DIFF
TIMESTAMP_MICROS
TIMESTAMP_MILLIS
TIMESTAMP_SECONDS
TIMESTAMP_SUB
TIMESTAMP_TRUNC
UNIX_DATE
UNIX_MICROS
UNIX_MILLIS
UNIX_SECONDS
Teradata | BigQuery |
---|---|
ADD_MONTHS |
DATE_ADD,
TIMESTAMP_ADD
|
CURRENT_DATE |
CURRENT_DATE
|
CURRENT_TIME |
CURRENT_TIME
|
CURRENT_TIMESTAMP |
CURRENT_TIMESTAMP
|
DATE + k |
DATE_ADD(date_expression,
INTERVAL k DAY)
|
DATE - k |
DATE_SUB(date_expression,
INTERVAL k DAY)
|
EXTRACT |
EXTRACT(DATE),
EXTRACT(TIMESTAMP)
|
FORMAT_DATE
|
|
FORMAT_DATETIME
|
|
FORMAT_TIME
|
|
FORMAT_TIMESTAMP
|
|
LAST_DAY |
LAST_DAY
Nota: questa funzione supporta le espressioni di input sia DATE che DATETIME .
|
MONTHS_BETWEEN |
DATE_DIFF(date_expression, date_expression, MONTH)
|
NEXT_DAY |
DATE_ADD( |
OADD_MONTHS |
DATE_SUB( |
td_day_of_month |
EXTRACT(DAY FROM date_expression) |
td_day_of_week |
EXTRACT(DAYOFWEEK FROM date_expression) |
td_day_of_year |
EXTRACT(DAYOFYEAR FROM date_expression) |
td_friday |
DATE_TRUNC( |
td_monday |
DATE_TRUNC( |
td_month_begin |
DATE_TRUNC(date_expression, MONTH)
|
td_month_end |
DATE_SUB( |
td_month_of_calendar |
(EXTRACT(YEAR FROM date_expression) - 1900) * 12 + EXTRACT(MONTH FROM date_expression)
|
td_month_of_quarter |
EXTRACT(MONTH FROM date_expression) |
td_month_of_year |
EXTRACT(MONTH FROM date_expression) |
td_quarter_begin |
DATE_TRUNC(date_expression, QUARTER)
|
td_quarter_end |
DATE_SUB( |
td_quarter_of_calendar |
(EXTRACT(YEAR FROM date_expression) |
td_quarter_of_year |
EXTRACT(QUARTER FROM date_expression) |
td_saturday |
DATE_TRUNC( |
td_sunday |
DATE_TRUNC( |
td_thursday |
DATE_TRUNC( |
td_tuesday |
DATE_TRUNC( |
td_wednesday |
DATE_TRUNC( |
td_week_begin |
DATE_TRUNC(date_expression, WEEK)
|
td_week_end |
DATE_SUB( |
td_week_of_calendar |
(EXTRACT(YEAR FROM date_expression) - 1900) * 52 + EXTRACT(WEEK FROM date_expression)
|
td_week_of_month |
EXTRACT(WEEK FROM date_expression) |
td_week_of_year |
EXTRACT(WEEK FROM date_expression) |
td_weekday_of_month |
CAST( |
td_year_begin |
DATE_TRUNC(date_expression, YEAR)
|
td_year_end |
DATE_SUB( |
td_year_of_calendar |
EXTRACT(YEAR FROM date_expression)
|
TO_DATE |
PARSE_DATE
|
TO_TIMESTAMP |
PARSE_TIMESTAMP
|
TO_TIMESTAMP_TZ |
PARSE_TIMESTAMP
|
Funzioni di stringa
La seguente tabella mappa le funzioni stringa Teradata agli equivalenti BigQuery. BigQuery offre le seguenti funzioni stringa aggiuntive:
BYTE_LENGTH
CODE_POINTS_TO_BYTES
ENDS_WITH
FROM_BASE32
FROM_BASE64
FROM_HEX
NORMALIZE
NORMALIZE_AND_CASEFOLD
REGEXP_CONTAINS
REGEXP_EXTRACT
REGEXP_EXTRACT_ALL
REPEAT
REPLACE
SAFE_CONVERT_BYTES_TO_STRING
SPLIT
STARTS_WITH
STRPOS
TO_BASE32
TO_BASE64
TO_CODE_POINTS
TO_HEX
Teradata | BigQuery |
---|---|
ASCII |
TO_CODE_POINTS(string_expression)[OFFSET(0)]
|
CHAR2HEXINT |
TO_HEX
|
CHARACTER LENGTH |
CHAR_LENGTH
|
CHARACTER LENGTH |
CHARACTER_LENGTH
|
CHR |
CODE_POINTS_TO_STRING( |
CONCAT, (|| operator) |
CONCAT, (|| operator)
|
CSV |
Funzione definita dall'utente dall'utente. |
CSVLD |
Funzione definita dall'utente dall'utente. |
FORMAT |
FORMAT
|
INDEX |
STRPOS(string, substring)
|
INITCAP |
INITCAP |
INSTR |
Funzione definita dall'utente dall'utente. |
LEFT |
SUBSTR(source_string, 1, length)
|
LENGTH |
LENGTH
|
LOWER |
LOWER
|
LPAD |
LPAD
|
LTRIM |
LTRIM
|
NGRAM |
Funzione definita dall'utente dall'utente. |
NVP |
Funzione definita dall'utente dall'utente. |
OREPLACE |
REPLACE
|
OTRANSLATE |
Funzione definita dall'utente dall'utente. |
POSITION |
STRPOS(string, substring)
|
REGEXP_INSTR |
STRPOS(source_string, Nota: restituisce la prima occorrenza. |
REGEXP_REPLACE |
REGEXP_REPLACE |
REGEXP_SIMILAR |
IF(REGEXP_CONTAINS,1,0) |
REGEXP_SUBSTR |
REGEXP_EXTRACT, |
REGEXP_SPLIT_TO_TABLE |
Funzione definita dall'utente dall'utente. |
REVERSE |
REVERSE
|
RIGHT |
SUBSTR(source_string, -1, length)
|
RPAD |
RPAD
|
RTRIM |
RTRIM
|
STRTOK Nota: ogni carattere nell'argomento stringa delimitatore è considerato un carattere delimitatore separato. Il delimitatore predefinito è un carattere spazio. |
SPLIT(instring, delimiter)[ORDINAL(tokennum)] Nota: l'intero argomento stringa delimitatore viene utilizzato come singolo delimitatore. Il delimitatore predefinito è una virgola. |
STRTOK_SPLIT_TO_TABLE |
Funzione definita dall'utente dall'utente |
SUBSTRING , SUBSTR |
SUBSTR
|
TRIM |
TRIM
|
UPPER |
UPPER
|
Funzioni matematiche
La seguente tabella mappa le funzioni matematiche di Teradata agli equivalenti BigQuery. BigQuery offre le seguenti funzioni matematiche aggiuntive:
Teradata | BigQuery |
---|---|
ABS |
ABS |
ACOS |
ACOS |
ACOSH |
ACOSH |
ASIN |
ASIN |
ASINH |
ASINH |
ATAN |
ATAN |
ATAN2 |
ATAN2 |
ATANH |
ATANH |
CEILING |
CEIL |
CEILING |
CEILING |
COS |
COS |
COSH |
COSH |
EXP |
EXP |
FLOOR |
FLOOR |
GREATEST |
GREATEST |
LEAST |
LEAST |
LN |
LN |
LOG |
LOG |
MOD (operatore % ) |
MOD |
NULLIFZERO |
NULLIF(expression, 0) |
POWER (operatore ** ) |
POWER,
POW
|
RANDOM |
RAND |
ROUND |
ROUND |
SIGN |
SIGN |
SIN |
SIN |
SINH |
SINH |
SQRT |
SQRT |
TAN |
TAN |
TANH |
TANH |
TRUNC |
TRUNC |
ZEROIFNULL |
IFNULL(expression, 0),
COALESCE(expression, 0)
|
Sintassi DML
Questa sezione illustra le differenze di sintassi del linguaggio di gestione dei dati tra Teradata e BigQuery.
Istruzione INSERT
La maggior parte delle istruzioni INSERT
di Teradata è compatibile con BigQuery.
La tabella seguente mostra le eccezioni.
Gli script DML in BigQuery hanno una semantica
di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata. Per una panoramica dell'isolamento dello snapshot e della gestione di sessioni e transazioni, consulta la sezione CREATE INDEX
in un altro punto di questo documento.
Teradata | BigQuery |
---|---|
INSERT INTO table VALUES (...);
|
INSERT INTO
table (...) VALUES (...); Teradata offre una parola chiave DEFAULT per le colonne con valori non nulli.Nota: in BigQuery, l'omissione dei nomi delle colonne nell'istruzione INSERT funziona solo se i valori di tutte le colonne nella tabella di destinazione sono inclusi in ordine crescente in base alla loro posizione ordinale. |
INSERT INTO table VALUES (1,2,3);
|
INSERT INTO
table VALUES (1,2,3),
Teradata utilizza il concetto di richiesta multi-statement (MSR), che invia più istruzioni INSERT
contemporaneamente. In BigQuery, questa operazione non è consigliata a causa del confine
implicito delle transazioni tra le istruzioni.
Utilizza invece INSERT a più valori.BigQuery consente istruzioni INSERT simultanee, ma potrebbe inserire in coda UPDATE .
Per migliorare le prestazioni, considera i seguenti approcci:
|
Istruzione UPDATE
La maggior parte delle istruzioni UPDATE
di Teradata è compatibile con BigQuery, ad eccezione dei seguenti elementi:
- Quando utilizzi una clausola
FROM
, l'ordine delle clausoleFROM
eSET
è invertito in Teradata e BigQuery. - In GoogleSQL, ogni istruzione
UPDATE
deve includere la parola chiaveWHERE
, seguita da una condizione. Per aggiornare tutte le righe della tabella, utilizzaWHERE true
.
Come best practice, dovresti raggruppare più mutazioni DML invece di singole istruzioni UPDATE
e INSERT
. Gli script DML in BigQuery hanno
una semantica di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata.
Per una panoramica dell'isolamento degli snapshot e della gestione di sessioni e transazioni, consulta la sezione CREATE INDEX
in un altro punto di questo documento.
La tabella seguente mostra le istruzioni UPDATE
di Teradata e le istruzioni BigQuery
che svolgono le stesse attività.
Per ulteriori informazioni su UPDATE
in BigQuery, consulta gli esempi di UPDATE
di BigQuery nella documentazione di DML.
Teradata | BigQuery | |
---|---|---|
UPDATE table_A
|
UPDATE table_A
|
|
UPDATE table alias
|
UPDATE table
|
|
UPDATE table_A
|
UPDATE table_A
|
Estratti conto DELETE
e TRUNCATE
Entrambe le istruzioni DELETE
e TRUNCATE
consentono di rimuovere le righe da una
tabella senza influire sullo schema o sugli indici della tabella. TRUNCATE
non è utilizzato né in Teradata né in BigQuery. Tuttavia, puoi utilizzare le istruzioni DELETE
per ottenere lo stesso effetto.
In BigQuery, l'istruzione DELETE
deve avere una clausola WHERE
.
Per eliminare tutte le righe della tabella (troncare), utilizza WHERE true
. Per velocizzare le operazioni di troncamento per tabelle molto grandi, consigliamo di utilizzare l'istruzione CREATE OR REPLACE TABLE ... AS SELECT
, utilizzando un LIMIT 0
nella stessa tabella per sostituirsi. Tuttavia, assicurati di aggiungere manualmente le informazioni di partizionamento e clustering quando le utilizzi.
Teradata vacuum ha eliminato le righe in un secondo momento. Ciò significa che le operazioni DELETE
sono
inizialmente più veloci rispetto a BigQuery, ma richiedono risorse
in un secondo momento, in particolare operazioni DELETE
su larga scala che interessano la maggior parte
di una tabella. Per utilizzare un approccio simile in BigQuery, suggeriamo di ridurre
il numero di operazioni DELETE
, ad esempio copiando le righe da non eliminare
in una nuova tabella. In alternativa, puoi rimuovere intere partizioni.
Entrambe queste opzioni sono progettate per essere operazioni più veloci delle mutazioni DML atomiche.
Per saperne di più su DELETE
in BigQuery, consulta gli esempi di DELETE
nella documentazione di DML.
Teradata | BigQuery |
---|---|
BEGIN TRANSACTION;
|
La sostituzione dei contenuti di una tabella con l'output della query è l'equivalente di una
transazione. Puoi farlo con un'operazione query o di copia. Utilizzo di un'operazione di query:
bq query --replace --destination_table table_A 'SELECT * FROM table_B';
Utilizzo di un'operazione di copia: bq cp -f table_A table_B |
DELETE database.table ALL; |
DELETE FROM table WHERE TRUE; In alternativa, per tabelle molto grandi, in modo più rapido: CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;
|
Istruzione MERGE
L'istruzione MERGE
può combinare le operazioni INSERT
, UPDATE
e DELETE
in una singola istruzione "upsert" ed eseguire le operazioni in modo atomico. L'operazione MERGE
deve corrispondere al massimo a una riga di origine per ogni riga di destinazione.
Sia BigQuery che Teradata seguono la sintassi ANSI.
L'operazione MERGE
di Teradata è limitata alla corrispondenza delle chiavi primarie all'interno di un
processore di moduli di accesso (AMP).
Al contrario, BigQuery non ha limiti di dimensioni o colonne per le operazioni di MERGE
, pertanto l'utilizzo di MERGE
è un'ottimizzazione utile. Tuttavia,
se l'elemento MERGE
è principalmente un'eliminazione di grandi dimensioni, puoi vedere le ottimizzazioni per DELETE
altro in questo documento.
Gli script DML in BigQuery hanno una semantica
di coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata. Ad esempio,
le tabelle SET di Teradata in modalità sessione potrebbero
ignorare i duplicati
durante un'operazione MERGE
. Per una panoramica della gestione delle tabelle MULTISET e SET, dell'isolamento degli snapshot e della gestione di sessioni e transazioni, consulta la sezione CREATE INDEX
in un altro punto di questo documento.
Variabili interessate da righe
In Teradata, la variabile ACTIVITY_COUNT
è un'estensione SQL ANSI di Teradata completata con il numero di righe interessate da un'istruzione DML.
La variabile di sistema @@row_count
nella funzionalità di scripting ha funzionalità simili.
In BigQuery sarebbe più comune controllare il valore restituito numDmlAffectedRows
negli audit log o nelle viste INFORMATION_SCHEMA
.
Sintassi DDL
Questa sezione illustra le differenze nella sintassi del linguaggio di definizione dei dati tra Teradata e BigQuery.
Istruzione CREATE TABLE
La maggior parte delle istruzioni Teradata CREATE TABLE
è compatibile con BigQuery, ad eccezione dei seguenti elementi di sintassi, che non vengono utilizzati in BigQuery:
MULTISET
. Consulta la sezioneCREATE INDEX
.VOLATILE
. Consulta la sezione Tabelle temporanee.[NO] FALLBACK
. Consulta la sezione Rollback.[NO] BEFORE JOURNAL
e[NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...)
. Consulta la sezioneCREATE INDEX
.UNIQUE PRIMARY INDEX
. Consulta la sezioneCREATE INDEX
.CONSTRAINT
DEFAULT
IDENTITY
Per ulteriori informazioni su CREATE TABLE
in BigQuery, consulta gli esempi di CREATE
di BigQuery nella documentazione di DML.
Opzioni e attributi delle colonne
Le seguenti specifiche di colonna per l'istruzione CREATE TABLE
non vengono
utilizzate in BigQuery:
FORMAT 'format'
. Consulta la sezione sulla formattazione dei tipi di Teradata.CHARACTER SET name
. BigQuery utilizza sempre la codifica UTF-8.[NOT] CASESPECIFIC
COMPRESS val | (val, ...)
Teradata estende lo standard ANSI con un'opzione colonna TITLE
. Questa funzionalità può essere implementata in modo simile in BigQuery
utilizzando la descrizione della colonna come mostrato nella tabella seguente. Tieni presente che questa opzione
non è disponibile per le viste.
Teradata | BigQuery |
---|---|
CREATE TABLE table (
|
CREATE TABLE dataset.table (
|
Tabelle temporanee
Teradata supporta tabelle volatili, che vengono spesso utilizzate per archiviare i risultati intermedi negli script. Esistono diversi modi per ottenere qualcosa di simile alle tabelle volatili in BigQuery:
CREATE TEMPORARY TABLE
può essere utilizzato in scripting ed è valido per tutta la durata dello script. Se la tabella deve esistere oltre uno script, puoi usare le altre opzioni in questo elenco.TTL del set di dati: crea un set di dati con una breve durata (ad esempio, un'ora) in modo che le tabelle create nel set di dati siano temporaneamente temporanee poiché non si mantengono più a lungo della durata del set di dati. Puoi anteporre
temp
a tutti i nomi delle tabelle in questo set di dati per indicare chiaramente che le tabelle sono temporanee.TTL tabella: crea una tabella con una breve durata specifica della tabella utilizzando istruzioni DDL simili alla seguente:
CREATE TABLE temp.name (col1, col2, ...) OPTIONS(expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
Clausola
WITH
: se è necessaria una tabella temporanea solo all'interno dello stesso blocco, utilizza un risultato temporaneo con un'istruzione o una sottoqueryWITH
. Questa è l'opzione più efficiente.
Un pattern molto utilizzato negli script Teradata (BTEQ)
è la creazione di una tabella permanente, l'inserimento di un valore al suo interno, l'utilizzo come una tabella
temporanea nelle istruzioni in corso, per poi eliminare o troncare la tabella in un secondo momento.
In questo modo viene utilizzata la tabella come variabile costante (un semaforo). Questo approccio non è efficiente in BigQuery e ti consigliamo di utilizzare invece variabili reali nello scripting o di utilizzare CREATE OR REPLACE
con la sintassi di query AS SELECT
per creare una tabella che contiene già valori.
Istruzione CREATE VIEW
La seguente tabella mostra gli equivalenti tra Teradata e BigQuery per l'istruzione CREATE VIEW
. Le clausole per il blocco delle tabelle come LOCKING ROW FOR ACCESS
non sono necessarie in BigQuery.
Teradata | BigQuery | Note |
---|---|---|
CREATE VIEW view_name AS SELECT ...
|
CREATE VIEW
view_name AS SELECT ...
|
|
REPLACE VIEW view_name AS SELECT ...
|
CREATE OR REPLACE VIEW
|
|
Funzionalità non supportata |
CREATE VIEW IF NOT EXISTS
|
Crea una nuova vista solo se al momento non esiste nel set di dati specificato. |
Istruzione CREATE [UNIQUE] INDEX
Teradata richiede indici per tutte le tabelle e richiede soluzioni alternative speciali come le tabelle MULTISET e le tabelle NoPI per lavorare con dati non univoci o non indicizzati.
BigQuery non richiede indici. Questa sezione descrive gli approcci in BigQuery su come creare funzionalità simili a come vengono utilizzati gli indici in Teradata quando esiste un'effettiva esigenza di logica di business.
Indicizzazione per il rendimento
Poiché è un database orientato a colonne con ottimizzazione di query e archiviazione, BigQuery non ha bisogno di indici espliciti. BigQuery offre funzionalità come partizionamento e clustering e campi nidificati, che possono aumentare l'efficienza e le prestazioni delle query ottimizzando la modalità di archiviazione dei dati.
Teradata non supporta le viste materializzate. Tuttavia, offre indici di join utilizzando l'istruzione CREATE JOIN INDEX
, che sostanzialmente materializza i dati necessari per un join. BigQuery non ha bisogno di indici materializzati per accelerare le prestazioni, così come non ha bisogno di uno spazio di spool dedicato per i join.
Per altri casi di ottimizzazione, è possibile usare le viste materializzate.
Indicizzazione per coerenza (UNIQUE, PRIMARY INDEX)
In Teradata, è possibile utilizzare un indice univoco per impedire le righe con chiavi non univoche in una tabella. Se un processo tenta di inserire o aggiornare dati con un valore già nell'indice, l'operazione non riesce con una violazione dell'indice (tabelle MULTISET) o la ignora automaticamente (tabelle SET).
Poiché BigQuery non fornisce indici espliciti, è possibile utilizzare un'istruzione MERGE
per inserire solo i record univoci in una tabella di destinazione da una tabella temporanea, eliminando i record duplicati. Tuttavia, non c'è modo di impedire a un utente con autorizzazioni di modifica di inserire un record duplicato, perché BigQuery non si blocca mai durante le operazioni di INSERT
.
Per generare un errore per i record duplicati in BigQuery, puoi
utilizzare un'istruzione MERGE
da una tabella temporanea, come mostrato nell'esempio seguente.
Teradata | BigQuery | |
---|---|---|
CREATE [UNIQUE] INDEX name;
|
MERGE `prototype.FIN_MERGE` t
|
Più spesso, gli utenti preferiscono rimuovere i duplicati in modo indipendente per trovare errori nei sistemi downstream.
BigQuery non supporta le colonne DEFAULT
e IDENTITY
(sequenze).
Indicizzazione per ottenere il blocco
Teradata fornisce risorse nel processore del modulo di accesso (AMP); le query possono utilizzare risorse completamente AMP, AMP singole o AMP di gruppo. Le istruzioni DDL
sono tutte AMP e pertanto sono simili a un blocco DDL globale.
BigQuery non ha un meccanismo di blocco come questo e può eseguire
query e istruzioni INSERT
in contemporanea fino alla tua quota;
solo le istruzioni DML UPDATE
simultanee hanno determinate
implicazioni in termini di contemporaneità:
le operazioni UPDATE
sulla stessa partizione vengono messe in coda per garantire l'isolamento degli snapshot, quindi non è necessario bloccarli per evitare letture fantasma o aggiornamenti persi.
A causa di queste differenze, i seguenti elementi di Teradata non vengono utilizzati in BigQuery:
ON COMMIT DELETE ROWS;
ON COMMIT PRESERVE ROWS;
Istruzioni SQL procedurali
Questa sezione descrive come convertire le istruzioni SQL procedurali utilizzate in stored procedure, funzioni e trigger da Teradata a BigQuery Scripting, procedure o funzioni definite dall'utente (UDF).
Tutti questi elementi possono essere controllati dagli amministratori di sistema tramite le viste INFORMATION_SCHEMA
.
Istruzione CREATE PROCEDURE
Le stored procedure sono supportate come parte dello scripting di BigQuery.
In BigQuery, per scripting si intende qualsiasi utilizzo di istruzioni di controllo, mentre le procedure sono script denominati (con argomenti, se necessario) che possono essere chiamati da altri script e archiviati in modo permanente, se necessario. Una funzione definita dall'utente può essere scritta anche in JavaScript.
Teradata | BigQuery |
---|---|
CREATE PROCEDURE |
CREATE PROCEDURE
se è obbligatorio un nome, altrimenti utilizzalo in linea con BEGIN
o in una singola riga con CREATE TEMP FUNCTION .
|
REPLACE PROCEDURE |
CREATE OR REPLACE PROCEDURE |
CALL |
CALL |
Le sezioni che seguono descrivono i modi per convertire le istruzioni procedurali Teradata esistenti in istruzioni BigQuery Scripting con funzionalità simili.
Dichiarazione di variabili e assegnazione
Le variabili BigQuery sono valide per tutta la durata dello script.
Teradata | BigQuery |
---|---|
DECLARE |
DECLARE |
SET |
SET |
Gestori delle condizioni degli errori
Teradata utilizza gestori sui codici di stato nelle procedure per il controllo degli errori. In BigQuery, la gestione degli errori è una funzionalità principale del flusso di controllo principale, simile a quella offerta da altri linguaggi con i blocchi TRY ... CATCH
.
Teradata | BigQuery |
---|---|
DECLARE EXIT HANDLER
FOR SQLEXCEPTION |
BEGIN ... EXCEPTION WHEN ERROR THEN |
SIGNAL sqlstate |
RAISE message |
DECLARE CONTINUE HANDLER
FOR SQLSTATE VALUE 23505; |
I gestori di eccezioni che si attivano per determinate condizioni di errore non vengono utilizzati da BigQuery. Consigliamo di utilizzare le istruzioni ASSERT
dove vengono utilizzate le condizioni di uscita per i precontrolli o il debug, in quanto sono conformi ad ANSI SQL:2011. |
La variabile SQLSTATE
in Teradata è simile alla variabile di sistema @@error
in BigQuery. In BigQuery, è più comune analizzare gli errori utilizzando l'audit logging o le viste INFORMATION_SCHEMA
.
Dichiarazioni e operazioni del cursore
Poiché BigQuery non supporta cursori o sessioni, le seguenti istruzioni non vengono utilizzate in BigQuery:
DECLARE cursor_name CURSOR [FOR | WITH] ...
PREPARE stmt_id FROM sql_str;
OPEN cursor_name [USING var, ...];
FETCH cursor_name INTO var, ...;
CLOSE cursor_name;
Istruzioni SQL dinamiche
La funzionalità di scripting in BigQuery supporta le istruzioni SQL dinamiche come quelle mostrate nella tabella seguente.
Teradata | BigQuery |
---|---|
EXECUTE IMMEDIATE
sql_str; |
EXECUTE IMMEDIATE
sql_str; |
EXECUTE
stmt_id [USING var,...]; |
EXECUTE IMMEDIATE
stmt_id USING var; |
Le seguenti istruzioni SQL dinamiche non vengono utilizzate in BigQuery:
PREPARE stmt_id FROM sql_str;
Istruzioni Flow-of-control
La funzionalità di scripting in BigQuery supporta le istruzioni flow-of-control come quelle mostrate nella tabella seguente.
Teradata | BigQuery |
---|---|
IF condition THEN stmts ELSE stmts END IF
|
IF condition THEN stmts ELSE stmts END IF |
label_name: LOOP stmts END LOOP label_name;
|
I costrutti a blocchi in stile GOTO non vengono utilizzati in BigQuery. Ti consigliamo di riscriverle come funzioni definite dall'utente (UDF) o di utilizzare istruzioni ASSERT dove vengono utilizzate per la gestione degli errori.
|
REPEAT stmts UNTIL condition END REPEAT;
|
WHILE condition DO stmts END WHILE |
LEAVE outer_proc_label;
|
LEAVE non viene utilizzato per i blocchi in stile GOTO; è utilizzato come sinonimo di BREAK per lasciare un loop WHILE . |
LEAVE label;
|
LEAVE non viene utilizzato per i blocchi in stile GOTO; è utilizzato come sinonimo di BREAK per lasciare un loop WHILE . |
WITH RECURSIVE temp_table AS ( ... );
|
Le query ricorsive (note anche come espressioni di tabella ricorrenti comuni (CTE)) non vengono utilizzate in BigQuery. Possono essere riscritti utilizzando array di
UNION ALL . |
Le seguenti istruzioni di flusso di controllo non vengono utilizzate in BigQuery perché BigQuery non utilizza cursori o sessioni:
Istruzioni SQL per metadati e transazioni
Teradata | BigQuery |
---|---|
HELP TABLE table_name;
HELP VIEW view_name;
|
SELECT La stessa query è valida per ottenere informazioni sulle colonne per le viste. Per ulteriori informazioni, consulta la Visualizzazione a colonne in BigQuery INFORMATION_SCHEMA . |
SELECT * FROM dbc.tables WHERE tablekind = 'T'; (visualizzazione DBC di Teradata) |
SELECT Per saperne di più, consulta Introduzione a BigQuery INFORMATION_SCHEMA . |
HELP STATISTICS table_name; |
APPROX_COUNT_DISTINCT(col) |
COLLECT STATS USING SAMPLE ON table_name column (...); |
Non utilizzato in BigQuery. |
LOCKING TABLE table_name FOR EXCLUSIVE; |
BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta la sezione Garanzie di coerenza in un altro punto di questo documento. |
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ... |
BigQuery utilizza sempre l'isolamento degli snapshot. Per i dettagli, consulta la sezione Garanzie di coerenza in un'altra sezione di questo documento. |
BEGIN TRANSACTION; |
BigQuery utilizza sempre l'isolamento degli snapshot. Per i dettagli, consulta la sezione Garanzie di coerenza in un'altra sezione di questo documento. |
EXPLAIN ... |
Non utilizzato in BigQuery. Funzionalità simili sono la spiegazione del piano di query nella UI web di BigQuery e l'allocazione degli slot visibile nelle viste INFORMATION_SCHEMA
e nell'audit logging in
Cloud Monitoring. |
Istruzioni SQL a più istruzioni e multiriga
Sia Teradata che BigQuery supportano le transazioni (sessioni) e di conseguenza supportano istruzioni separate da punti e virgola che vengono eseguite in modo coerente insieme. Per maggiori informazioni, consulta Transazioni multi-statement.
Codici e messaggi di errore
I codici di errore Teradata e quelli di BigQuery sono diversi. Poiché fornisce un'API REST, BigQuery si basa principalmente su codici di stato HTTP e su messaggi di errore dettagliati.
Se la logica dell'applicazione attualmente rileva gli errori seguenti, prova a eliminare l'origine dell'errore, poiché BigQuery non restituirà gli stessi codici di errore.
SQLSTATE = '02000'
- "Riga non trovata"SQLSTATE = '21000'
- "Violazione della cardinalità (indice univoco)"SQLSTATE = '22000'
- "Violazione dei dati (tipo di dati)"SQLSTATE = '23000'
- "Violazione del vincolo"
In BigQuery, sarebbe più comune utilizzare le viste INFORMATION_SCHEMA
o l'audit logging per visualizzare in dettaglio gli errori.
Per informazioni su come gestire gli errori nello script, vedi le sezioni seguenti.
Garanzie di coerenza e isolamento delle transazioni
Sia Teradata che BigQuery sono atomici, ovvero compatibili con ACID, a livello di singola mutazione in molte righe. Ad esempio, un'operazione MERGE
è
completamente atomica, anche con più valori inseriti e aggiornati.
Transazioni
Teradata fornisce un livello di isolamento di lettura senza impegno (che consente letture dirty) o serializzabile quando viene eseguito in modalità sessione (anziché in modalità di commit automatico). Nella migliore delle ipotesi, Teradata ottiene un isolamento strettamente serializzabile mediante blocchi pessimistici su un hash di riga in tutte le colonne delle righe in tutte le partizioni. Sono possibili i deadlock. Il DDL forza sempre un limite di transazione. I job Teradata Fastload vengono eseguiti in modo indipendente, ma solo su tabelle vuote.
BigQuery supporta anche le transazioni.
BigQuery aiuta a garantire un controllo ottimistico della contemporaneità (prima che si verifichi il commit delle vittorie) con l'isolamento degli snapshot, in cui una query legge gli ultimi dati di cui è stato eseguito il commit prima dell'avvio della query. Questo
approccio garantisce lo stesso livello di coerenza su base per riga, per mutazione
e tra righe all'interno della stessa istruzione DML, evitando al tempo stesso i deadlock. Nel
caso di più istruzioni UPDATE
sulla stessa tabella, BigQuery
passa al
controllo della contemporaneità pessimistico
e alle coda
più istruzioni UPDATE
, riprovando automaticamente in caso di conflitti. INSERT
Le istruzioni DML e i job di caricamento possono essere eseguiti contemporaneamente e in modo indipendente da aggiungere alle tabelle.
Esegui il rollback
Teradata supporta
due modalità di rollback della sessione,
la modalità di sessione ANSI e quella di sessione Teradata (SET SESSION CHARACTERISTICS
e
SET SESSION TRANSACTION
), a seconda della modalità di rollback desiderata. Nei casi di errore, potrebbe non essere possibile eseguire il rollback della transazione.
BigQuery supporta
l'istruzione ROLLBACK TRANSACTION
.
In BigQuery non è presente un'istruzione ABORT
.
Limiti per i database
Consulta sempre la documentazione pubblica di BigQuery per conoscere le quote e i limiti più recenti. Per aumentare le quote per gli utenti con volumi elevati, rivolgiti al team di assistenza Cloud. La tabella seguente mostra un confronto dei limiti di Teradata e BigQuery.
Limite | Teradata | BigQuery |
---|---|---|
Tabelle per database | Senza restrizioni | Senza restrizioni |
Colonne per tabella | 2048 | 10.000 |
Dimensione massima della riga | 1 MB | 100 MB |
Lunghezza del nome della colonna e della tabella | 128 caratteri Unicode | 16.384 caratteri Unicode |
Righe per tabella | Illimitato | Illimitato |
Lunghezza massima della richiesta SQL | 1 MB | 1 MB (lunghezza massima delle query GoogleSQL non risolte) 12 MB (lunghezza massima delle query precedenti e GoogleSQL risolte) Flusso di dati:
|
Dimensioni massime di richiesta e risposta | 7 MB (richiesta), 16 MB (risposta) | 10 MB (richiesta) e 10 GB (risposta) o praticamente illimitati se utilizzi la paginazione o l'API Cloud Storage. |
Numero massimo di sessioni simultanee | 120 per motore di analisi (PE) | 100 query in parallelo (possono essere generate con una prenotazione di slot), 300 richieste API in parallelo per utente. |
Numero massimo di caricamenti simultanei (rapidi) | 30 (valore predefinito 5) | Nessun limite di contemporaneità; i job sono in coda. 100.000 job di caricamento per progetto al giorno. |