Guida alla traduzione SQL di Teradata
Questo documento descrive le analogie e le differenze nella sintassi SQL tra Teradata e BigQuery per aiutarti a pianificare la migrazione. Utilizza le funzionalità di traduzione SQL batch in eseguire la migrazione collettiva degli script SQL 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 la classe di archiviazione con parametri tipi di dati decimali se devi applicare limiti di cifre o di scala personalizzati (vincoli). Teradata consente di inserire valori di precisione maggiore mediante l'arrotondamento il valore memorizzato; ma mantiene l'elevata precisione nei calcoli. Questo può determinare comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
FLOAT |
FLOAT64 |
|
NUMERIC |
Utilizza Utilizza la classe di archiviazione con parametri tipi di dati decimali se devi applicare limiti di cifre o di scala personalizzati (vincoli). Teradata consente di inserire valori di precisione maggiore mediante l'arrotondamento il valore memorizzato; ma mantiene l'elevata precisione nei calcoli. Questo può determinare comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
NUMBER |
Utilizza Utilizza la classe di archiviazione con parametri tipi di dati decimali se devi applicare limiti di cifre o di scala personalizzati (vincoli). Teradata consente di inserire valori di precisione maggiore mediante l'arrotondamento il valore memorizzato; ma mantiene l'elevata precisione nei calcoli. Questo può determinare comportamento di arrotondamento imprevisto rispetto allo standard ANSI. |
|
REAL |
FLOAT64 |
|
CHAR/CHARACTER |
STRING |
Utilizza la classe di archiviazione
con parametri
|
VARCHAR |
STRING |
Utilizza la classe di archiviazione
con parametri
|
CLOB |
STRING |
|
JSON |
JSON |
|
BLOB |
BYTES |
|
BYTE |
BYTES |
|
VARBYTE |
BYTES |
|
DATE |
DATE |
BigQuery non supporta una formattazione personalizzata simile a quella Supporta Teradata con DataForm nei file SDF. |
TIME |
TIME |
|
TIME WITH TIME ZONE |
TIME |
Teradata archivia il tipo di dati TIME in UTC e ti consente di:
passare un offset rispetto al fuso orario UTC utilizzando la sintassi WITH TIME ZONE .
Il tipo di dati TIME in BigQuery
rappresenta un orario indipendente da data o fuso orario. |
TIMESTAMP |
TIMESTAMP |
Sia Teradata che BigQuery
TIMESTAMP
i tipi di dati hanno una precisione in microsecondi (ma Teradata supporta i secondi intercalari, mentre
al contrario di BigQuery).In genere sono associati i tipi di dati Teradata e BigQuery con un fuso orario UTC (dettagli). |
TIMESTAMP WITH TIME ZONE |
TIMESTAMP |
Il 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 il fuso UTC se
non specifichino esplicitamente un fuso orario. Assicurati di esportare il fuso orario
le informazioni correttamente (non concatenare DATE e
TIME senza informazioni sul fuso orario) in modo che
BigQuery può convertirlo al momento dell'importazione. Oppure assicurati di
convertire le informazioni sul fuso orario in UTC prima dell'esportazione.BigQuery ha DATETIME per un'astrazione
tra l'ora civile, che non mostra il fuso orario in fase di output, e
TIMESTAMP , un momento preciso che viene sempre visualizzato
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
BigQuery
documentazione). |
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 DATE
colonne contenenti le date di inizio e di fine in modo da poterle utilizzare
con 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 ulteriori informazioni sulla trasmissione del tipo, consulta la sezione successiva.
Formattazione del tipo Teradata
Teradata SQL utilizza un insieme di formati predefiniti per visualizzare espressioni e
e per le conversioni tra tipi di dati diversi. Ad esempio, un
Il tipo di dati PERIOD(DATE)
in modalità INTEGERDATE
è formattato come YY/MM/DD
per impostazione predefinita. Ti consigliamo di utilizzare la modalità ANSIDATE, ove possibile, per assicurarti
conforme ad ANSI SQL e sfrutta questa opportunità per eliminare i formati precedenti.
Teradata consente l'applicazione automatica di formati personalizzati utilizzando
FORMAT
senza modificare lo spazio di archiviazione sottostante, sia come attributo del tipo di dati
quando crei una tabella utilizzando DDL o in un'espressione derivata. Per
Ad esempio, la specifica FORMAT
9.99
arrotonda qualsiasi valore FLOAT
a due cifre.
In BigQuery, questa funzionalità deve essere convertita utilizzando il metodo
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 in considerazione
regole di formattazione e arrotondamento speciali dell'account.
È possibile usare una clausola FORMAT
per trasmettere in modo implicito un valore dell'epoca INTEGER
a un
DATE
. Oppure una specifica FORMAT
X(6)
su una colonna VARCHAR
tronca il valore della colonna e devi quindi convertirlo in un SUBSTR()
personalizzata. Questo comportamento non è conforme ad ANSI SQL. Pertanto, ti suggeriamo di non
migrazione dei formati delle colonne 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 dato tipo, consulta le Formattazione predefinita di Teradata documentazione.
Formattazione di timestamp e tipo di data
La tabella seguente riassume le differenze di timestamp e data degli elementi di formattazione tra SQL Teradata e GoogleSQL.
Formato Teradata | Descrizione Teradata | BigQuery |
---|---|---|
CURRENT_TIMESTAMP
|
Le informazioni su TIME e TIMESTAMP in Teradata possono
hanno informazioni di 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.Di seguito sono riportati i dettagli sulle differenze nel formato ISO. Il formato DATETIME è basato sulle convenzioni del canale di output. Nel
lo strumento a riga di comando BigQuery e BigQuery
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() ,
il che rende esplicita la trasmissione di una stringa. Ad esempio,
l'espressione restituisce sempre un separatore di spazi:CAST(CURRENT_DATETIME() AS STRING) Teradata supporta un DEFAULT
parola chiave in TIME colonne per impostare l'ora corrente (timestamp);
e non viene usato in BigQuery.
|
CURRENT_DATE |
Le date vengono archiviate in Teradata come valori INT64 utilizzando
seguente formula:(YEAR - 1900) * 10000 + (MONTH * 100) + DAY Le date possono essere formattate come numeri interi. |
BigQuery ha un formato DATE separato che fa sempre
restituisce una data in formato ISO 8601.Non puoi utilizzare DATE_FROM_UNIX_DATE perché è
basata sul 1970.Teradata supporta una DEFAULT
parola chiave in DATE colonne per impostare la data corrente; questo non è
utilizzata in BigQuery.
|
CURRENT_DATE-3 |
I valori delle date sono rappresentati come numeri interi. Teradata supporta l'aritmetica per i tipi di date. |
Per i tipi di date, usa 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 il numero intero operations. | 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 in BigQuery.
Istruzione SELECT
La maggior parte dei Teradata
Estratti conto SELECT
sono compatibili con BigQuery. La tabella seguente contiene un elenco
di piccole differenze.
Teradata | BigQuery | |
---|---|---|
SEL |
Converti in SELECT . BigQuery non utilizza
Abbreviazione SEL . |
|
SELECT
|
In BigQuery, le colonne non possono fare riferimento all'output di altri
colonne definite all'interno dello stesso elenco di selezione. Preferisci spostare una sottoquery in
una clausola WITH .
WITH flags AS (
|
|
SELECT * FROM table
|
BigQuery non utilizza la logica ANY
predicato.La stessa funzionalità può essere ottenuta usando più OR
operatori:SELECT * FROM table In questo caso, anche il confronto tra stringhe differisce. Consulta la sezione Operatori di confronto. |
|
SELECT TOP 10 * FROM table
|
BigQuery utilizza LIMIT
alla fine di una query anziché TOP n seguendo il
SELECT parola chiave.
|
Operatori di confronto
La tabella seguente mostra gli operatori di confronto di Teradata specifici per Teradata e deve essere convertito in operatori conformi ad ANSI SQL:2011 utilizzati in in BigQuery.
Per informazioni sugli operatori in BigQuery, consulta 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 la parte finale
gli spazi vuoti, mentre BigQuery li considera parte
stringa. Ad esempio, 'xyz'=' xyz' è TRUE in
Teradata ma FALSE in BigQuery.Teradata offre inoltre una
NOT CASESPECIFIC
attributo di colonna che indica a Teradata di ignorare
quando si confrontano due stringhe. BigQuery è sempre scritto in maiuscole e minuscole
quando si confrontano 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 lo stesso JOIN
,
Condizioni ON
e USING
. La tabella seguente
contiene un elenco di differenze minime.
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 interni o se è stata assegnata almeno una condizione di uguaglianza (=). ma non
solo una condizione di disuguaglianza (= e <) in un 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.
|
FROM A, B ON A.id = B.id
|
FROM A JOIN B ON A.id = B.id
|
Utilizzare una virgola tra le tabelle in Teradata è uguale a INNER JOIN ,
mentre in BigQuery equivale a CROSS JOIN
(prodotto cartesiano). Poiché la virgola in BigQuery
SQL precedente viene considerato 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 correlate o aggregazioni nei predicati di join. Ciò consente BigQuery mette in parallelo le query. |
Tipo di conversione e trasmissione
BigQuery ha tipi di dati meno numerosi, ma più ampi rispetto a Teradata, il che richiede che BigQuery sia più restrittivo nella trasmissione.
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 la parte finale
gli spazi vuoti, mentre BigQuery li considera parte
stringa. Ad esempio, 'xyz'=' xyz' è TRUE in
Teradata ma FALSE in BigQuery.Teradata offre inoltre una
NOT CASESPECIFIC
attributo di colonna che indica a Teradata di ignorare
quando si confrontano due stringhe. BigQuery è sempre scritto in maiuscole e minuscole
quando si confrontano 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 a volte viene utilizzata come 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 i 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 ti consente di:
filtrare i risultati per le funzioni finestra.
In alternativa,
ROWS
frase
può essere utilizzato per la stessa attività. Funzionano in modo simile a una condizione HAVING
per una
Clausola GROUP
, che limita l'output dei valori in BigQuery
chiamata
funzioni finestra.
Teradata | BigQuery |
---|---|
SELECT col1, col2
|
La clausola QUALIFY di Teradata con una finestra
come ROW_NUMBER() , SUM() ,
COUNT() e con OVER PARTITION BY è espresso
in BigQuery come una clausola WHERE su una sottoquery
che contiene un valore di analisi. ROW_NUMBER() in uso:SELECT col1, col2 Viene utilizzato ARRAY_AGG , che supporta partizioni più grandi:
SELECT
|
SELECT col1, col2
|
SELECT col1, col2 In BigQuery, sia RANGE sia ROWS
può essere utilizzato
nella clausola relativa al frame della finestra. Tuttavia, le clausole finestra possono essere
utilizzata con funzioni finestra come AVG() , non con la numerazione
come ROW_NUMBER() . |
NORMALIZE
parola chiave
Teradata fornisce
NORMALIZE
parola chiave per le clausole SELECT
per unire periodi o intervalli che si sovrappongono in
un singolo periodo o intervallo che comprende tutti i valori dei singoli periodi.
BigQuery non supporta il tipo PERIOD
, quindi qualsiasi PERIOD
di testo in Teradata deve essere inserita in BigQuery come due
campi DATE
o DATETIME
separati che corrispondono all'inizio e alla fine del
punto.
Teradata | BigQuery |
---|---|
SELECT NORMALIZE
|
SELECT
|
Funzioni
Le sezioni seguenti elencano le mappature tra le funzioni Teradata e equivalenti BigQuery.
Funzioni di aggregazione
La tabella seguente mappa i dati aggregati di Teradata, le funzioni di aggregazione statistica e di aggregazione approssimata alle loro 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 |
A bit
Operatore 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 personalizzata definita 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 i dati di analisi e di aggregare le funzioni di analisi equivalenti funzione finestra. BigQuery offre le seguenti opzioni funzioni aggiuntive:
Funzioni di data/ora
La tabella seguente mappa le funzioni di data/ora comuni di Teradata agli 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 tabella seguente mappa le funzioni stringa di Teradata alle relative 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 personalizzata definita dall'utente. |
CSVLD |
Funzione personalizzata definita dall'utente. |
FORMAT |
FORMAT
|
INDEX |
STRPOS(string, substring)
|
INITCAP |
INITCAP |
INSTR |
Funzione personalizzata definita dall'utente. |
LEFT |
SUBSTR(source_string, 1, length)
|
LENGTH |
LENGTH
|
LOWER |
LOWER
|
LPAD |
LPAD
|
LTRIM |
LTRIM
|
NGRAM |
Funzione personalizzata definita dall'utente. |
NVP |
Funzione personalizzata definita dall'utente. |
OREPLACE |
REPLACE
|
OTRANSLATE |
Funzione personalizzata definita 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 personalizzata definita dall'utente. |
REVERSE |
REVERSE
|
RIGHT |
SUBSTR(source_string, -1, length)
|
RPAD |
RPAD
|
RTRIM |
RTRIM
|
STRTOK Nota: ogni carattere nell'argomento stringa del delimitatore è considerato un carattere di delimitatore separato. Il delimitatore predefinito è uno spazio . |
SPLIT(instring, delimiter)[ORDINAL(tokennum)] Nota: l'intero argomento della stringa delimitatore è utilizzato come singolo delimitatore. Il delimitatore predefinito è una virgola. |
STRTOK_SPLIT_TO_TABLE |
Funzione personalizzata definita dall'utente |
SUBSTRING , SUBSTR |
SUBSTR
|
TRIM |
TRIM
|
UPPER |
UPPER
|
Funzioni matematiche
La tabella seguente mappa le funzioni matematiche di 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 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 coerenza leggermente diversa
rispetto alle istruzioni equivalenti in Teradata. Per una panoramica
per l'isolamento degli snapshot e la gestione di sessioni e transazioni,
CREATE INDEX
sezione in un altro punto del documento.
Teradata | BigQuery |
---|---|
INSERT INTO table VALUES (...);
|
INSERT INTO
table (...) VALUES (...); Teradata offre una parola chiave DEFAULT per le colonne con valori non null.Nota: in BigQuery, l'omissione dei nomi delle colonne nelle l'istruzione INSERT funziona solo se i valori per tutte le colonne in
le tabelle target vengono incluse in ordine crescente in base al loro
posizioni. |
INSERT INTO table VALUES (1,2,3);
|
INSERT INTO
table VALUES (1,2,3),
Teradata ha un concetto di multi-statement richiesta (MSR), che invia più istruzioni INSERT
alla volta. In BigQuery, questa operazione non è consigliata a causa del
confine tra transazioni implicite
tra le istruzioni.
Utilizza più valori.
INSERT in alternativa.BigQuery consente istruzioni INSERT simultanee, ma potrebbe accodare UPDATE .
Per migliorare le prestazioni, considera questi approcci:
|
Istruzione UPDATE
La maggior parte degli estratto conto Teradata UPDATE
sono compatibili con BigQuery, ad eccezione dei seguenti elementi:
- Quando utilizzi una clausola
FROM
, l'ordine diFROM
eSET
viene invertito in Teradata e BigQuery. - In GoogleSQL, ogni istruzione
UPDATE
deve includere la parola chiaveWHERE
, seguito da una condizione. Per aggiornare tutte le righe della tabella, utilizzaWHERE true
.
Come best practice, dovresti raggruppare più mutazioni DML anziché singole
Estratti conto UPDATE
e INSERT
. Gli script DML in BigQuery hanno
una semantica a coerenza leggermente diversa rispetto alle istruzioni equivalenti in Teradata.
Per una panoramica dell'isolamento degli snapshot e della gestione di sessioni e transazioni, consulta
il
CREATE INDEX
sezione in un altro punto del documento.
La tabella seguente mostra le istruzioni UPDATE
di Teradata e
Istruzioni BigQuery che svolgono le stesse attività.
Per saperne di più su UPDATE
in BigQuery, consulta
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
sono modi per rimuovere righe da un
senza influire sullo schema o sugli indici della tabella. TRUNCATE
non è utilizzato in
da Teradata o BigQuery. Tuttavia, puoi utilizzare DELETE
istruzioni 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
. Troncamento rapido
operazioni per tabelle molto grandi, consigliamo di utilizzare
CREATE OR REPLACE TABLE ... AS SELECT
utilizzando un'istruzione LIMIT 0
nella stessa tabella. 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
vengono
inizialmente più veloce rispetto a BigQuery, ma richiedono risorse
in un secondo momento, in particolare per operazioni DELETE
su larga scala che interessano la maggior parte
. Per utilizzare un approccio simile in BigQuery, suggeriamo di ridurre
il numero di operazioni DELETE
, ad esempio la copia delle 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
DELETE
esempi
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 una copia
operativa. Con 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, puoi procedere più rapidamente: CREATE OR REPLACE table AS SELECT * FROM table LIMIT 0;
|
Istruzione MERGE
L'istruzione MERGE
può combinare le operazioni INSERT
, UPDATE
e DELETE
in un unico "superiore" ed eseguire le operazioni a livello atomico. La
L'operazione MERGE
deve corrispondere al massimo a una riga di origine per ogni riga target.
Sia BigQuery che Teradata seguono la sintassi ANSI.
L'operazione MERGE
di Teradata è limitata alla corrispondenza delle chiavi primarie in una
processore modulo di accesso (AMP).
Al contrario, BigQuery non ha limiti di dimensioni o colonne per
MERGE
, pertanto l'utilizzo di MERGE
è un'ottimizzazione utile. Tuttavia,
se MERGE
è principalmente un'eliminazione di grandi dimensioni, consulta le ottimizzazioni per DELETE
in altre sezioni del documento.
Gli script DML in BigQuery hanno lievi differenze
e coerenza più elevata rispetto alle istruzioni equivalenti in Teradata. Ad esempio:
Le tabelle SET di Teradata in modalità sessione potrebbero
ignora duplicati
durante un'operazione MERGE
. Per una panoramica della gestione di MULTISET e
IMPOSTARE tabelle, isolamento degli snapshot e gestione di sessioni e transazioni
vedi il
CREATE INDEX
sezione in un altro punto del documento.
Variabili interessate da righe
In Teradata, il
ACTIVITY_COUNT
è un'estensione SQL ANSI di Teradata compilata con il numero di righe
interessati da un'istruzione DML.
La variabile di sistema @@row_count
nella funzionalità di script ha una funzionalità simile.
In BigQuery sarebbe più comune controllare la numDmlAffectedRows
restituiscono il valore 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 dei Teradata
CREATE TABLE
sono compatibili con BigQuery, ad eccezione delle seguenti
di sintassi non utilizzati in BigQuery:
MULTISET
. Consulta leCREATE INDEX
.VOLATILE
. Consulta le Tabelle temporanee .[NO] FALLBACK
. Consulta la sezione Rollback.[NO] BEFORE JOURNAL
,[NO] AFTER JOURNAL
CHECKSUM = DEFAULT | val
DEFAULT MERGEBLOCKRATIO
PRIMARY INDEX (col, ...)
. Consulta leCREATE INDEX
.UNIQUE PRIMARY INDEX
. Consulta leCREATE INDEX
.CONSTRAINT
DEFAULT
IDENTITY
Per saperne di più su CREATE TABLE
in BigQuery, consulta
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 sono
utilizzata in BigQuery:
FORMAT 'format'
. Consulta la sezione sulla formattazione del tipo di Teradata.CHARACTER SET name
. BigQuery utilizza sempre la codifica UTF-8.[NOT] CASESPECIFIC
COMPRESS val | (val, ...)
Teradata estende lo standard ANSI con una 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 volatile che sono spesso utilizzate per archiviare risultati intermedi negli script. Esistono diversi modi per ottenere qualcosa di simile alle tabelle volatili in BigQuery:
CREATE TEMPORARY TABLE
può essere utilizzato nello scripting, ed è valido per tutta la durata dello script. Se la tabella deve esistere oltre allo script, puoi utilizzare le altre opzioni in questo elenco.TTL del set di dati: crea un set di dati di breve durata (ad esempio, 1 ora) in modo che tutte le tabelle create nel set di dati siano temporaneamente poiché non durano più a lungo della durata del set di dati. Puoi anteporre
temp
a tutti i nomi delle tabelle in questo set di dati in modo indica che le tabelle sono temporanee.TTL tabella: crea una tabella con un breve periodo di tempo specifico per utilizzando istruzioni DDL simili alle seguenti:
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 della stessa blocca, utilizza un risultato temporaneoWITH
un'istruzione o una sottoquery. Questa è l'opzione più efficiente.
Un pattern utilizzato spesso negli script Teradata (BTEQ)
consiste nel creare una tabella permanente, inserire un valore al suo interno, utilizzare questo come
nelle istruzioni in corso, per poi eliminarla o troncarla in seguito.
In questo modo viene utilizzata la tabella come variabile costante (un semaforo). Questo
non è efficiente in BigQuery e consigliamo di usare
variabili reali
in Scripting
oppure usare CREATE OR REPLACE
con AS SELECT
la sintassi della query per creare una tabella che contiene già dei valori.
Istruzione CREATE VIEW
La tabella seguente mostra gli equivalenti tra Teradata e
BigQuery per l'istruzione CREATE VIEW
. Le clausole della tabella
del blocco 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 la vista non esiste al momento nel del set di dati specificato. |
Istruzione CREATE [UNIQUE] INDEX
Teradata richiede indici per tutte le tabelle e richiede soluzioni alternative speciali come MULTISET e Tabelle NoPI lavorare con dati non univoci o non indicizzati.
BigQuery non richiede indici. Questa sezione descrive di 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 così come campi nidificati, che può aumentare l'efficienza e le prestazioni delle query ottimizzando il modo in cui i dati vengono archiviati.
Teradata non supporta le viste materializzate. Tuttavia, offre
indici di join
utilizzando l'istruzione CREATE JOIN INDEX
, che essenzialmente materializza i dati
necessario per un join. BigQuery non ha bisogno di modelli
per velocizzare le prestazioni, così come non ha bisogno di uno spool dedicato
spazio per i join.
Per altri casi di ottimizzazione, le viste materializzate è possibile utilizzare.
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à presenti nell'indice, l'operazione non va a buon fine e causa una violazione dell'indice (tabelle MULTISET) o la ignora automaticamente (tabelle SET).
Poiché BigQuery non fornisce indici espliciti, un MERGE
è possibile utilizzare l'istruzione per inserire solo record univoci in una tabella di destinazione
da una tabella temporanea mentre vengono eliminati i record duplicati. Tuttavia, non c'è
un modo per 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:
utilizza un'istruzione MERGE
di una tabella temporanea, come mostrato di seguito
esempio.
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 DEFAULT
e IDENTITY
(sequenze)
colonne.
Indicizzazione per ottenere il blocco
Teradata fornisce risorse
processore modulo di accesso
(AMP); le query possono utilizzare risorse tutte AMP, AMP singole o AMP di gruppo. DDL
sono completamente AMP e pertanto sono simili a un blocco DDL globale.
BigQuery non dispone di un meccanismo di blocco come questo e può eseguire
query simultanee e istruzioni INSERT
fino alla tua quota;
solo le istruzioni DML UPDATE
simultanee hanno determinate
implicazioni della contemporaneità:
UPDATE
operazioni sulla stessa partizione sono in coda per garantire lo snapshot
l'isolamento, così non dovrai bloccarlo per evitare letture fantasma o la perdita degli aggiornamenti.
A causa di queste differenze, i seguenti elementi Teradata non vengono utilizzati 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.
Tutti questi elementi possono essere controllati dagli amministratori di sistema utilizzando
INFORMATION_SCHEMA
visualizzazioni.
Istruzione CREATE PROCEDURE
Le stored procedure sono supportate in BigQuery Esecuzione di script.
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 richiamati 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 è richiesto un nome, altrimenti usa l'incorporamento di BEGIN
o su una sola riga con CREATE TEMP FUNCTION .
|
REPLACE PROCEDURE |
CREATE OR REPLACE PROCEDURE |
CALL |
CALL |
Le sezioni che seguono descrivono i modi per convertire i dati procedurali Teradata esistenti alle istruzioni di scripting BigQuery che hanno funzionalità.
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. Nel
BigQuery, la gestione degli errori è una funzionalità principale del controllo
simile a quello fornito da altre lingue 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. Ti consigliamo di utilizzare ASSERT
in cui vengono utilizzate condizioni di uscita per i precontrolli o il debug, in quanto sono conformi ad ANSI SQL:2011. |
La SQLSTATE
in Teradata è simile alla variabile di sistema @@error
in BigQuery. In BigQuery, è più comune
esamina gli errori utilizzando il log di controllo
o INFORMATION_SCHEMA
visualizzazioni.
Dichiarazioni e operazioni del cursore
Poiché BigQuery non supporta cursori o sessioni, in BigQuery non vengono utilizzate le seguenti istruzioni:
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 script in BigQuery supporta le istruzioni SQL dinamiche come quelle mostrate nella seguente tabella.
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 script in BigQuery supporta 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 riscriverli come funzioni definite dall'utente oppure utilizza le istruzioni ASSERT quando 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 di tipo GOTO. viene utilizzato come sinonimo di BREAK per lasciare un loop WHILE . |
LEAVE label;
|
LEAVE non viene utilizzato per i blocchi di tipo GOTO. viene 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 flow-of-control non vengono utilizzate in BigQuery poiché 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 colonna in BigQuery INFORMATION_SCHEMA . |
SELECT * FROM dbc.tables WHERE tablekind = 'T'; (vista Teradata DBC) |
SELECT Per ulteriori informazioni, consulta Introduzione in 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 Garanzie di coerenza in altre sezioni del documento. |
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ... |
BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, vedi Garanzie di coerenza in altre sezioni del documento. |
BEGIN TRANSACTION; |
BigQuery utilizza sempre l'isolamento degli snapshot. Per maggiori dettagli, vedi Garanzie di coerenza in altre sezioni del documento. |
EXPLAIN ... |
Non utilizzato in BigQuery. Funzionalità simili sono il piano di query spiegazione nella UI web di BigQuery e lo slot allocazione visibile in INFORMATION_SCHEMA
di visualizzazioni e nell'audit logging
con 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 sono in modo coerente eseguite insieme. Per ulteriori informazioni, vedi Transazioni multi-istruzione.
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 sui codici di stato HTTP oltre a messaggi di errore dettagliati.
Se la logica dell'applicazione sta rilevando i seguenti errori, prova a elimina l'origine dell'errore, perché BigQuery non restituiscono 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
un livello per mutazione su molte righe. Ad esempio, un'operazione MERGE
completamente atomico, anche con più valori inseriti e aggiornati.
Transazioni
Teradata fornisce Lettura senza impegno (consente letture dirty) o Transazione serializzabile livello di isolamento in modalità sessione (anziché in modalità di commit automatico). Nella migliore delle ipotesi, Teradata raggiunge un isolamento strettamente serializzabile grazie al blocco pessimistico rispetto a un hash di riga in tutte le colonne delle righe di tutte le partizioni. Deadlock sono possibili. Il DDL forza sempre un limite di transazione. Job Teradata Fastload vengono eseguite in modo indipendente, ma solo su tabelle vuote.
BigQuery inoltre
supporta le transazioni.
BigQuery aiuta a garantire
controllo ottimistico della contemporaneità
(vittorie che eseguono prima il commit) con
isolamento dello snapshot,
in cui una query legge gli ultimi dati di cui è stato eseguito il commit prima dell'inizio della query. Questo
garantisce lo stesso livello di coerenza su riga e per mutazione
e tra righe all'interno della stessa istruzione DML, evitando comunque i deadlock. Nel
nel caso di più istruzioni UPDATE
nella stessa tabella, BigQuery
passa a
controllo pessimistico della contemporaneità
e code
più istruzioni UPDATE
, riprovando automaticamente in caso di conflitti. INSERT
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,
Modalità sessione ANSI e modalità sessione Teradata (SET SESSION CHARACTERISTICS
e
SET SESSION TRANSACTION
), a seconda della modalità di rollback che vuoi. Nel
in casi di errore, la transazione potrebbe non essere sottoposta a rollback.
BigQuery supporta
ROLLBACK TRANSACTION
.
Non è presente una dichiarazione ABORT
in BigQuery.
Limiti per i database
Controlla sempre la documentazione pubblica di BigQuery per le quote e i limiti più recenti. Molte quote per gli utenti con volumi elevati possono essere aumentate contattando il team di assistenza Cloud. La tabella seguente mostra un confronto delle i limiti dei database 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) Flussi 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 l'impaginazione o l'API Cloud Storage. |
Numero massimo di sessioni simultanee | 120 per motore di analisi (PE) | 100 query in parallelo (può essere generato con un prenotazione slot), 300 richieste API simultanee per utente. |
Numero massimo di caricamenti simultanei (rapidi) | 30 (valore predefinito 5) | Nessun limite di contemporaneità; di job vengono messi in coda. 100.000 job di caricamento per progetto per giorno. |