Guida alla traduzione SQL di Teradata
Questo documento illustra le analogie e le differenze della sintassi SQL tra Teradata e BigQuery per aiutarti a pianificare la migrazione. Utilizza la traduzione SQL batch per eseguire la migrazione collettiva degli script SQL o la traduzione SQL interattiva per tradurre le 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 parametrizzati di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata ti consente di inserire valori di maggiore precisione arrotondando il valore memorizzato; tuttavia, mantiene l'alta precisione nei calcoli. Ciò può portare a un comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
FLOAT |
FLOAT64 |
|
NUMERIC |
Utilizza Utilizza i tipi di dati decimali parametrizzati di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata ti consente di inserire valori di maggiore precisione arrotondando il valore memorizzato; tuttavia, mantiene l'alta precisione nei calcoli. Ciò può portare a un comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
NUMBER |
Utilizza Utilizza i tipi di dati decimali parametrizzati di BigQuery se devi applicare limiti (vincoli) personalizzati per cifre o scale. Teradata ti consente di inserire valori di maggiore precisione arrotondando il valore memorizzato; tuttavia, mantiene l'alta precisione nei calcoli. Ciò può portare a 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 la formattazione personalizzata simile a quella supportata da Teradata con DataForm in SDF. |
TIME |
TIME |
|
TIME WITH TIME ZONE |
TIME |
Teradata memorizza il tipo di dati TIME in UTC e ti consente di trasmettere un offset da UTC utilizzando la sintassi WITH TIME ZONE .
Il tipo di dati TIME in BigQuery rappresenta un orario indipendente da qualsiasi data o fuso orario. |
TIMESTAMP |
TIMESTAMP |
I tipi di dati di Teradata e BigQuery
TIMESTAMP
hanno una precisione di microsecondi (ma Teradata supporta i secondi intercalari, mentre
BigQuery no).I tipi di dati Teradata e BigQuery sono solitamente associati a un fuso orario UTC (dettagli). |
TIMESTAMP WITH TIME ZONE |
TIMESTAMP |
Il campo TIMESTAMP di Teradata 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 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 all'importazione. In alternativa, assicurati di
convertire le informazioni sul fuso orario in UTC prima dell'esportazione.BigQuery dispone di DATETIME per un'astrazione tra il tempo civile, che non mostra un fuso orario quando viene visualizzato, e TIMESTAMP , che è un punto preciso nel tempo che mostra sempre il fuso orario UTC. |
ARRAY |
ARRAY |
|
MULTI-DIMENSIONAL ARRAY |
ARRAY |
In BigQuery, utilizza un array di struct, con ogni struct contenente 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 ,
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 utilizzato
con le funzioni finestra. |
PERIOD(TIMESTAMP WITH TIME ZONE) |
TIMESTAMP ,
TIMESTAMP |
|
PERIOD(TIMESTAMP) |
TIMESTAMP ,
TIMESTAMP |
|
PERIOD(TIME) |
TIME ,
TIME |
|
PERIOD(TIME WITH TIME ZONE) |
TIME ,
TIME |
|
UDT |
STRING |
|
XML |
STRING |
|
TD_ANYTYPE |
STRING |
Per saperne di più sul trasferimento di tipo, consulta la sezione successiva.
Formattazione del tipo Teradata
Teradata SQL utilizza un insieme di formati predefiniti per la visualizzazione di espressioni e dati di colonna 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, se possibile, per garantire la conformità a ANSI SQL e di sfruttare questa opportunità per ripulire i formati precedenti.
Teradata consente l'applicazione automatica di formati personalizzati utilizzando la clausola FORMAT
, senza modificare lo spazio di archiviazione sottostante, come attributo del tipo di dati quando crei una tabella utilizzando DDL o in un'espressione derivata. Ad esempio, una specifica FORMAT
9.99
arrotonderà qualsiasi valore FLOAT
a due cifre.
In BigQuery, questa funzionalità deve essere convertita utilizzando la funzioneROUND()
.
Questa funzionalità richiede la gestione di casi limite intricati. Ad esempio,
quando la clausola FORMAT
viene applicata a una colonna NUMERIC
, devi tenere conto
di regole di arrotondamento e formattazione speciali.
Una clausola FORMAT
può essere utilizzata per eseguire il casting implicito di un valore di epocha INTEGER
in un formato DATE
. In alternativa, una specifica FORMAT
X(6)
in una colonna VARCHAR
tronca il valore della colonna e devi quindi convertire in una funzione SUBSTR()
. Questo comportamento non è conforme ad ANSI SQL. Pertanto, ti consigliamo di non eseguire la migrazione dei formati delle colonne a BigQuery.
Se i formati delle colonne sono assolutamente necessari, utilizza le viste o le funzioni definite dall'utente (UDF).
Per informazioni sui formati predefiniti utilizzati da Teradata SQL per ogni tipo di dato, consulta la documentazione sulla formattazione predefinita di Teradata.
Formattazione del tipo di timestamp e data
La seguente tabella riassume le differenze negli elementi di formattazione della data e del timestamp tra Teradata SQL e GoogleSQL.
Formato Teradata | Descrizione di Teradata | BigQuery |
---|---|---|
CURRENT_TIMESTAMP
|
Le informazioni TIME e TIMESTAMP in Teradata possono avere informazioni sui fusi orari diversi, che vengono 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.
(BigQuery non ha un fuso orario interno).Tieni presente i seguenti dettagli sulle differenze nel formato ISO. DATETIME viene formattato in base alle convenzioni dei canali di output. Nello strumento a riga di comando BigQuery e nella console BigQuery, viene formattato utilizzando un separatore T in base a RFC 3339. Tuttavia, in Python e Java JDBC, viene utilizzato uno spazio come separatore.Se vuoi utilizzare un formato esplicito, utilizza FORMAT_DATETIME() , che esegue un passaggio esplicito a una stringa. Ad esempio, la seguente expressione restituisce sempre un separatore di spazi:CAST(CURRENT_DATETIME() AS STRING) Teradata supporta una parola chiave DEFAULT
nelle colonne TIME per impostare l'ora corrente (timestamp);
questa non viene utilizzata in BigQuery.
|
CURRENT_DATE |
Le date vengono memorizzate 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 sempre
restituisce una data nel formato ISO 8601.DATE_FROM_UNIX_DATE non può essere utilizzato perché è basato su
il 1970.Teradata supporta una parola chiave DEFAULT
nelle colonne DATE per impostare la data corrente. Questa parola chiave non viene
utilizzata in BigQuery.
|
CURRENT_DATE-3 |
I valori di data sono rappresentati come numeri interi. Teradata supporta gli operatori matematici per i tipi di date. |
Per i tipi di date, utilizza DATE_ADD()
o
DATE_SUB() .BigQuery utilizza operatori aritmetici per i tipi di dati: INT64 , NUMERIC e FLOAT64 .
|
SYS_CALENDAR.CALENDAR |
Teradata fornisce una visualizzazione per le operazioni di calendario che vanno oltre le operazioni con 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 le date e le ore di Teradata. |
Sintassi delle query
Questa sezione illustra le differenze nella sintassi delle query tra Teradata e BigQuery.
SELECT
dichiarazione
La maggior parte delle SELECT
istruzioni Teradata è compatibile con BigQuery. La tabella seguente contiene un elenco di differenze minori.
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 delle 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 Teradata specifici di Teradata e che devono essere convertiti in 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 la semantica non ANSI per NOT CASESPECIFIC , puoi utilizzare RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
|
Quando si confrontano le stringhe per verificarne l'uguaglianza, Teradata potrebbe ignorare gli spazi iniziali e finali, mentre BigQuery li considera parte della stringa. Ad esempio, 'xyz'=' xyz' è TRUE in
Teradata, ma FALSE in BigQuery.Teradata fornisce anche un attributo colonna
NOT CASESPECIFIC
che indica a Teradata di ignorare la maiuscola quando confronta due stringhe. BigQuery è sempre sensibile alle maiuscole
quando confronta 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 tabella seguente contiene un elenco di differenze minori.
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 JOIN di disuguaglianza per tutte le unioni interne o se è specificata almeno una condizione di uguaglianza (=). Tuttavia, non supporta solo una condizione di disuguaglianza (= e <) in un OUTER JOIN .
A volte questi costrutti vengono utilizzati per eseguire query su intervalli di date o interi.
BigQuery impedisce agli utenti di creare inavvertitamente join tra più tabelle di grandi dimensioni.
|
FROM A, B ON A.id = B.id
|
FROM A JOIN B ON A.id = B.id
|
L'utilizzo di una virgola tra le tabelle in Teradata equivale a un INNER JOIN , mentre in BigQuery equivale a un CROSS JOIN (prodotto cartesiano). Poiché la virgola in BigQuery
SQL precedente è trattata 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. In questo modo, BigQuery esegue il parallellismo delle query. |
Conversione e trasmissione di tipi
BigQuery ha meno tipi di dati, ma più ampi rispetto a Teradata, il che richiede che BigQuery sia più rigoroso nel casting.
Teradata | BigQuery | Note |
---|---|---|
exp EQ exp2 exp IN (exp2, exp3)
|
exp = exp2 exp IN (exp2, exp3) Per mantenere la semantica non ANSI per NOT CASESPECIFIC , puoi utilizzare RTRIM(UPPER(exp)) = RTRIM(UPPER(exp2))
|
Quando si confrontano le stringhe per verificarne l'uguaglianza, Teradata potrebbe ignorare gli spazi iniziali e finali, mentre BigQuery li considera parte della stringa. Ad esempio, 'xyz'=' xyz' è TRUE in
Teradata, ma FALSE in BigQuery.Teradata fornisce anche un attributo colonna
NOT CASESPECIFIC
che indica a Teradata di ignorare la maiuscola quando confronta due stringhe. BigQuery è sempre sensibile alle maiuscole
quando confronta 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)
|
A volte, il passaggio di una colonna di caratteri in Teradata viene utilizzato come metodo non standard e non ottimale per creare una sottostringa con spaziatura interna. |
CAST(92617 AS TIME)
92617 (FORMAT '99:99:99')
|
PARSE_TIME("%k%M%S", CAST(92617 AS STRING)) |
Teradata esegue molte conversioni di tipo più implicite e arrotondamenti rispetto a BigQuery, che è generalmente più rigoroso 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 numerici e con virgola mobile possono richiedere regole di arrotondamento speciali se applicati con formati come le valute.
(questo esempio restituisce 48) |
Consulta anche gli operatori di confronto e i formati delle colonne. Sia i confronti che la formattazione delle colonne possono comportarsi come conversioni di tipo.
QUALIFY
, ROWS
clausole
La clausola QUALIFY
in Teradata ti 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 di quelle che in BigQuery sono chiamate funzioni finestra.
Teradata | BigQuery |
---|---|
SELECT col1, col2
|
La clausola QUALIFY di Teradata con una funzione di 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, sia RANGE che ROWS possono essere utilizzati nella clausola intervallo finestra. 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 sovrapposti in un singolo periodo o intervallo che racchiude tutti i valori dei singoli periodi.
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 sezioni seguenti elencano le mappature tra le funzioni Teradata e i relativi equivalenti di BigQuery.
Funzioni di aggregazione
La tabella seguente mappa le funzioni aggregate, di aggregazione statistica e di aggregazione approssimativa comuni di Teradata ai relativi equivalenti di BigQuery. BigQuery offre le seguenti funzioni aggregate 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 di negación
a livello di bit (~ ) |
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 personalizzata. |
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 di analisi e di analisi di aggregazione Teradata comuni alle relative funzione finestra di BigQuery. BigQuery offre le seguenti funzionalità aggiuntive:
Funzioni di data/ora
La tabella seguente mappa le funzioni di data/ora Teradata comuni ai relativi equivalenti BigQuery. BigQuery offre le seguenti funzioni aggiuntive per 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 sia le espressioni di input DATE sia quelle 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 tabella seguente mappa le funzioni di stringa Teradata ai relativi equivalenti BigQuery. BigQuery offre le seguenti funzioni aggiuntive per le stringhe:
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 personalizzata. |
CSVLD |
Funzione definita dall'utente personalizzata. |
FORMAT |
FORMAT
|
INDEX |
STRPOS(string, substring)
|
INITCAP |
INITCAP |
INSTR |
Funzione definita dall'utente personalizzata. |
LEFT |
SUBSTR(source_string, 1, length)
|
LENGTH |
LENGTH
|
LOWER |
LOWER
|
LPAD |
LPAD
|
LTRIM |
LTRIM
|
NGRAM |
Funzione definita dall'utente personalizzata. |
NVP |
Funzione definita dall'utente personalizzata. |
OREPLACE |
REPLACE
|
OTRANSLATE |
Funzione definita dall'utente personalizzata. |
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 personalizzata. |
REVERSE |
REVERSE
|
RIGHT |
SUBSTR(source_string, -1, length)
|
RPAD |
RPAD
|
RTRIM |
RTRIM
|
STRTOK Nota: ogni carattere nell'argomento stringa del delimitatore è considerato un carattere delimitatore separato. Il delimitatore predefinito è un carattere di spazio. |
SPLIT(instring, delimiter)[ORDINAL(tokennum)] Nota: l'intero argomento stringa delimiter 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 Teradata alle relative 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 nella sintassi del linguaggio di gestione dei dati tra Teradata e BigQuery.
INSERT
dichiarazione
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 degli snapshot e della gestione delle sessioni e delle transazioni, consulta la sezione CREATE INDEX
di questo documento.
Teradata | BigQuery |
---|---|
INSERT INTO table VALUES (...);
|
INSERT INTO
table (...) VALUES (...); Teradata offre una parola chiave DEFAULT per le colonne non null.Nota: in BigQuery, l'omissione dei nomi delle colonne nell'istruzione INSERT funziona solo se i valori di tutte le colonne della tabella di destinazione sono inclusi in ordine crescente in base alle relative posizioni ordinali. |
INSERT INTO table VALUES (1,2,3);
|
INSERT INTO
table VALUES (1,2,3),
Teradata ha un concetto di richiesta con più istruzioni (MSR), che invia più istruzioni INSERT contemporaneamente. In BigQuery, questa operazione non è consigliata a causa del confine di transazione implicito tra le istruzioni.
Utilizza invece multi-value
INSERT .BigQuery consente istruzioni INSERT concorrenti, ma potrebbe mettere in coda UPDATE .
Per migliorare il rendimento, valuta i seguenti approcci:
|
UPDATE
dichiarazione
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
viene invertito in Teradata e BigQuery. - In GoogleSQL, ogni istruzione
UPDATE
deve includere la parola chiaveWHERE
, followed by a condition. Per aggiornare tutte le righe della tabella, utilizzaWHERE true
.
Come best practice, dovresti raggruppare più mutazioni DML anziché 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 sull'isolamento degli snapshot e sulla gestione delle sessioni e delle transazioni, consulta la sezione CREATE INDEX
di questo documento.
La tabella seguente mostra gli statement UPDATE
Teradata e
gli statement BigQuery che svolgono le stesse attività.
Per ulteriori informazioni su UPDATE
in BigQuery, consulta gli esempi di UPDATE
di BigQuery nella documentazione DML.
Teradata | BigQuery | |
---|---|---|
UPDATE table_A
|
UPDATE table_A
|
|
UPDATE table alias
|
UPDATE table
|
|
UPDATE table_A
|
UPDATE table_A
|
DELETE
e TRUNCATE
estratti conto
Sia le istruzioni DELETE
che TRUNCATE
consentono di rimuovere righe da una tabella senza influire sullo schema o sugli indici della tabella. TRUNCATE
non viene 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 (troncamento), utilizza WHERE true
. Per velocizzare le operazioni di troncamento per tabelle di grandi dimensioni, 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 partizione e clustering quando le utilizzi.
Teradata esegue il 'evacuazione' delle righe eliminate 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 le operazioni DELETE
su larga scala che influiscono sulla maggior parte di una tabella. Per utilizzare un approccio simile in BigQuery, ti consigliamo 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 ulteriori informazioni su DELETE
in BigQuery, consulta gli esempi di DELETE
nella documentazione DML.
Teradata | BigQuery |
---|---|
BEGIN TRANSACTION;
|
La sostituzione dei contenuti di una tabella con l'output della query è equivalente a una transazione. Puoi farlo con un'operazione di 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 di grandi dimensioni, puoi utilizzare un metodo più rapido: CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;
|
MERGE
dichiarazione
L'istruzione MERGE
può combinare le operazioni INSERT
, UPDATE
e DELETE
in un'unica istruzione "upsert" ed eseguire le operazioni in modo atomico. L'operazione MERGE
deve corrispondere a un massimo di una riga di origine per ogni riga di destinazione.
Sia BigQuery che Teradata rispettano la sintassi ANSI.
L'operazione MERGE
di Teradata è limitata alla corrispondenza delle chiavi principali all'interno di un
processore del modulo di accesso (AMP).
Al contrario, BigQuery non ha limitazioni di dimensioni o colonne per le operazioni MERGE
, pertanto l'utilizzo di MERGE
è un'ottimizzazione utile. Tuttavia, se MERGE
è costituito principalmente da un'eliminazione di grandi dimensioni, consulta le ottimizzazioni per DELETE
altrove 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à di 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 delle sessioni e delle transazioni, consulta la sezione CREATE INDEX
in questo documento.
Variabili interessate dalle righe
In Teradata, la variabile
ACTIVITY_COUNT
è un'estensione SQL ANSI di Teradata compilata con il numero di righe
colpite da un'istruzione DML.
La variabile di sistema @@row_count
nella funzionalità di scripting ha una funzionalità simile.
In BigQuery sarebbe più comune controllare il valore restituito da numDmlAffectedRows
nei log di controllo o nelle viste INFORMATION_SCHEMA
.
Sintassi DDL
Questa sezione illustra le differenze nella sintassi del linguaggio di definizione dei dati tra Teradata e BigQuery.
CREATE TABLE
dichiarazione
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 Ripristino dei dati precedenti.[NO] BEFORE JOURNAL
,[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 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 visualizzazioni.
Teradata | BigQuery |
---|---|
CREATE TABLE table (
|
CREATE TABLE dataset.table (
|
Tabelle temporanee
Teradata supporta le 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 a uno script, puoi utilizzare le altre opzioni in questo elenco.TTL del set di dati:crea un set di dati con un TTL breve (ad es. 1 ora) in modo che le tabelle create nel set di dati siano effettivamente temporanee poiché non rimarranno più a lungo del TTL del set di dati. Puoi anteporre a tutti i nomi delle tabelle in questo set di dati il prefisso
temp
per indicare chiaramente che le tabelle sono temporanee.TTL tabella:crea una tabella con un periodo di tempo breve specifico per la 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 una tabella temporanea è necessaria solo all'interno dello stesso blocco, utilizza un risultato temporaneo con un'istruzione o una sottoqueryWITH
. Questa è l'opzione più efficiente.
Un pattern spesso utilizzato negli script Teradata (BTEQ) consiste nel creare una tabella permanente, inserirvi un valore, utilizzarla come tabella temporanea nelle istruzioni in corso ed eliminarla o troncarla in un secondo momento.
In pratica, la tabella viene utilizzata come variabile costante (un semaforo). Questo approccio non è efficiente in BigQuery e consigliamo di utilizzare le variabili reali in Scripting oppure CREATE OR REPLACE
con la sintassi di query AS SELECT
per creare una tabella contenente già dei valori.
CREATE VIEW
dichiarazione
La tabella seguente 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
|
|
Non supportata |
CREATE VIEW IF NOT EXISTS
|
Crea una nuova vista solo se al momento non esiste nel set di dati specificato. |
CREATE [UNIQUE] INDEX
dichiarazione
Teradata richiede indici per tutte le tabelle e 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 per creare funzionalità simili a come vengono utilizzati gli indici in Teradata quando è necessaria una logica aziendale effettiva.
Indicizzazione per il rendimento
Poiché è un database orientato alle colonne con ottimizzazione di query e spazio di archiviazione, BigQuery non ha bisogno di indici espliciti. BigQuery offre funzionalità come il partizionamento e il clustering, nonché i 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 essenzialmente materializza i dati
necessari per un join. BigQuery non ha bisogno di indici materializzati per velocizzare le prestazioni, così come non ha bisogno di spazio spool dedicato per le unioni.
Per altri casi di ottimizzazione, è possibile utilizzare le viste materializzate.
Indicizzazione per garantire coerenza (UNIQUE, PRIMARY INDEX)
In Teradata, è possibile utilizzare un indice univoco per impedire la presenza di righe con chiavi non univoche in una tabella. Se un processo tenta di inserire o aggiornare dati con un valore già presente nell'indice, l'operazione non va a buon fine con una violazione dell'indice (tabelle MULTISET) o lo ignora silenziosamente (tabelle SET).
Poiché BigQuery non fornisce indici espliciti, è possibile utilizzare un'istruzione MERGE
per inserire solo record univoci in una tabella di destinazione
da una tabella intermedia, ignorando contemporaneamente i record duplicati. Tuttavia, non esiste un modo per impedire a un utente con autorizzazioni di modifica di inserire un record duplicato, poiché BigQuery non esegue mai il blocco durante le operazioni INSERT
.
Per generare un errore per i record duplicati in BigQuery, puoi utilizzare un'istruzione MERGE
da una tabella intermedia, 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 a valle.
BigQuery non supporta le colonne DEFAULT
e IDENTITY
(sequenze).
Indicizzazione per il blocco
Teradata fornisce risorse nel
processore del modulo di accesso
(AMP); le query possono utilizzare risorse AMP, AMP singole o AMP di gruppo. Le istruzioni DDL sono completamente AMP e quindi simili a un blocco DDL globale.
BigQuery non dispone di un meccanismo di blocco come questo e può eseguire query e istruzioni INSERT
concorrenti fino alla tua quota. Solo le istruzioni DML UPDATE
concorrenti hanno determinate implicazioni di concorrenza: le operazioni UPDATE
sulla stessa partizione vengono messe in coda per garantire l'isolamento degli snapshot, quindi non è necessario il blocco per impedire letture fantasma o aggiornamenti persi.
A causa di queste differenze, i seguenti elementi 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 di Teradata
in scripting, procedure o funzioni definite dall'utente (UDF) di BigQuery.
Tutti questi elementi sono disponibili per gli amministratori di sistema che possono controllarli utilizzando le visualizzazioni INFORMATION_SCHEMA
.
CREATE PROCEDURE
dichiarazione
Le stored procedure sono supportate nell'ambito dello scripting di BigQuery.
In BigQuery, la programmazione di script si riferisce a qualsiasi utilizzo di istruzioni di controllo, mentre le procedure sono script denominati (con argomenti, se necessario) che possono essere richiamati da altri script e archiviati in modo permanente, se necessario. Una funzione definita dall'utente (UDF) può essere scritta anche in JavaScript.
Teradata | BigQuery |
---|---|
CREATE PROCEDURE |
CREATE PROCEDURE
se è richiesto un nome, altrimenti utilizza in linea con BEGIN
o in una singola riga con CREATE TEMP FUNCTION .
|
REPLACE PROCEDURE |
CREATE OR REPLACE PROCEDURE |
CALL |
CALL |
Le sezioni seguenti descrivono i modi per convertire le istruzioni procedurali Teradata esistenti in istruzioni di scripting BigQuery con funzionalità simili.
Dichiarazione e assegnazione di variabili
Le variabili BigQuery sono valide per tutta la durata dello script.
Teradata | BigQuery |
---|---|
DECLARE |
DECLARE |
SET |
SET |
Gestori delle condizioni di errore
Teradata utilizza gestori per i codici di stato nelle procedure per il controllo degli errori. In
BigQuery, la gestione degli errori è una funzionalità di base del flusso di controllo
principale, simile a quella fornita 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; |
Gli gestori delle eccezioni che si attivano per determinate condizioni di errore non vengono utilizzati da BigQuery. Consigliamo di utilizzare le istruzioni ASSERT
quando le condizioni di uscita vengono utilizzate per i pre-controlli o il debug, in quanto sono conformi allo standard ANSI SQL:2011. |
La variabile SQLSTATE
in Teradata è simile alla variabile di sistema @@error
in BigQuery. In BigQuery, è più comune esaminare gli errori utilizzando l'audit logging o le visualizzazioni 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 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; |
I seguenti statement SQL dinamici non vengono utilizzati in BigQuery:
PREPARE stmt_id FROM sql_str;
Istruzioni di controllo del flusso
La funzionalità di scripting in BigQuery supporta istruzioni di controllo del flusso 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 di blocco in stile GOTO non vengono utilizzati in BigQuery. Ti consigliamo di riscriverli come funzioni definite dall'utente (UDF) oppure di utilizzare le istruzioni ASSERT se 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; viene utilizzato come sinonimo di BREAK per uscire da un ciclo WHILE . |
LEAVE label;
|
LEAVE non viene utilizzato per i blocchi in stile GOTO; viene utilizzato come sinonimo di BREAK per uscire da un ciclo WHILE . |
WITH RECURSIVE temp_table AS ( ... );
|
Le query ricorsive (note anche come espressioni di tabella comune ricorsive (CTE)) non vengono utilizzate in BigQuery. Possono essere riscritti utilizzando array di
UNION ALL . |
I seguenti comandi di controllo del flusso non vengono utilizzati 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 visualizzazioni. Per ulteriori informazioni, consulta la visualizzazione Colonna in BigQuery INFORMATION_SCHEMA . |
SELECT * FROM dbc.tables WHERE tablekind = 'T'; (Visualizzazione DBC di Teradata) |
SELECT Per ulteriori informazioni, 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 Garanzia di coerenza in un altro punto di questo documento. |
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ... |
BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta la sezione Garanzia della coerenza in un'altra parte di questo documento. |
BEGIN TRANSACTION; |
BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, consulta la sezione Garanzia della coerenza in un'altra parte di questo documento. |
EXPLAIN ... |
Non utilizzato in BigQuery. Funzionalità simili sono la spiegazione del piano di query nell'interfaccia utente web di BigQuery e l'allocazione degli slot visibile nelle viste INFORMATION_SCHEMA e nei log di controllo in Cloud Monitoring. |
Istruzioni SQL con più istruzioni e su più righe
Sia Teradata che BigQuery supportano le transazioni (sessioni) e quindi supportano le istruzioni separate da punti e virgola che vengono eseguite in modo coerente insieme. Per ulteriori informazioni, consulta la sezione Transazioni con più istruzioni.
Messaggi e codici di errore
I codici di errore Teradata e BigQuery sono diversi. Fornendo un'API REST, BigQuery si basa principalmente sui codici di stato HTTP oltre che su messaggi di errore dettagliati.
Se la logica dell'applicazione sta attualmente rilevando i seguenti errori, prova a eliminare la fonte dell'errore, perché BigQuery non restituirà gli stessi codici di errore.
SQLSTATE = '02000'
- "Riga non trovata"SQLSTATE = '21000'
- "Violazione cardinalità (indice univoco)"SQLSTATE = '22000'
- "Violazione dei dati (tipo di dati)"SQLSTATE = '23000'
- "Violazione vincolo"
In BigQuery, è più comune utilizzare le visualizzazioni INFORMATION_SCHEMA
o l'audit logging per visualizzare in dettaglio gli errori.
Per informazioni su come gestire gli errori in Scripting, consulta le sezioni seguenti.
Garanzie di coerenza e isolamento delle transazioni
Sia Teradata che BigQuery sono atomici, ovvero conformi ad ACID a livello di mutazione su molte righe. Ad esempio, un'operazione MERGE
è completamente atomica, anche con più valori inseriti e aggiornati.
Transazioni
Teradata fornisce il livello di isolamento delle operazioni Serializable o Lettura non confermata (che consente letture sporche) quando viene eseguito in modalità di sessione (anziché in modalità di commit automatico). Nel caso migliore, Teradata raggiunge l'isolamento rigorosamente serializzabile utilizzando i blocchi pessimistici contro un hash di riga in tutte le colonne delle righe di tutte le partizioni. I deadlock sono possibili. DDL forza sempre un confine di transazione. I job Teradata Fastload vengono eseguiti in modo indipendente, ma solo su tabelle vuote.
BigQuery supporta inoltre le transazioni.
BigQuery contribuisce a garantire il controllo della concorrenza ottimistico (chi esegue prima il commit vince) con l'isolamento degli snapshot, in cui una query legge gli ultimi dati sottoposti a commit prima dell'inizio 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 contempo i deadlock. Nel caso di più istruzioni UPDATE
per la stessa tabella, BigQuery passa al controllo della concorrenza pessimistico e accoda più istruzioni UPDATE
, riprova automaticamente in caso di conflitti. Le istruzioni DML e i job di caricamento INSERT
possono essere eseguiti contemporaneamente e in modo indipendente per accodare dati alle tabelle.
Esegui il rollback
Teradata supporta
due modalità di rollback della sessione,
la modalità di sessione ANSI e la modalità di sessione Teradata (SET SESSION CHARACTERISTICS
e
SET SESSION TRANSACTION
), a seconda della modalità di rollback che preferisci. In caso di errore, il rollback della transazione potrebbe non essere eseguito.
BigQuery supporta l'istruzione ROLLBACK TRANSACTION
.
In BigQuery non esiste l'istruzione ABORT
.
Limiti per i database
Controlla sempre la documentazione pubblica di BigQuery per conoscere le quote e i limiti più recenti. Molte quote per utenti con volumi elevati possono essere aumentate contattando il team di assistenza Cloud. La tabella seguente mostra un confronto tra i limiti dei database Teradata e BigQuery.
Limite | Teradata | BigQuery |
---|---|---|
Tabelle per database | Senza restrizioni | Senza restrizioni |
Colonne per tabella | 2048 | 10.000 |
Dimensioni massime delle righe | 1 MB | 100 MB |
Lunghezza del nome delle colonne e delle tabelle | 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 GoogleSQL e legacy risolte) Streaming:
|
Dimensioni massime di richiesta e risposta | 7 MB (richiesta), 16 MB (risposta) | 10 MB (richiesta) e 10 GB (risposta) oppure praticamente illimitato se utilizzi la paginazione o l'API Cloud Storage. |
Numero massimo di sessioni simultanee | 120 per motore di analisi (PE) | 100 query simultanee (possono essere aumentate con una prenotazione di slot), 300 richieste API in parallelo per utente. |
Numero massimo di caricamenti (rapidi) simultanei | 30 (valore predefinito 5) | Nessun limite di concorrenza; i job vengono messi in coda. 100.000 job di caricamento per progetto al giorno. |