Guide de traduction SQL d'Amazon Redshift
Ce document décrit les similitudes et les différences de syntaxe SQL entre Amazon Redshift et BigQuery pour vous aider à planifier votre migration. Utilisez la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc.
Ce guide est destiné aux architectes d'entreprise, aux administrateurs de bases de données, aux développeurs d'applications et aux spécialistes de la sécurité informatique. Nous partons du principe que vous connaissez bien Amazon Redshift.
Types de données
Cette section présente les équivalences entre les types de données Amazon Redshift et BigQuery.
Amazon Redshift | BigQuery | Remarques | |
---|---|---|---|
Type de données | Alias | Type de données | |
SMALLINT |
INT2 |
INT64 |
Le SMALLINT d'Amazon Redshift est de 2 octets, tandis que le INT64 de BigQuery est de 8 octets. |
INTEGER |
INT64 |
Le INTEGER d'Amazon Redshift est de 4 octets, tandis que le INT64 de BigQuery est de 8 octets. |
|
BIGINT |
INT8 |
INT64 |
Le BIGINT d'Amazon Redshift et le INT64 de BigQuery sont tous deux de 8 octets. |
DECIMAL |
NUMERIC |
NUMERIC |
|
REAL |
FLOAT4 |
FLOAT64 |
Le REAL d'Amazon Redshift est de 4 octets, tandis que le FLOAT64 de BigQuery est de 8 octets. |
DOUBLE
PRECISION |
FLOAT64 |
||
BOOLEAN |
BOOL |
BOOL |
Le fichier BOOLEAN d'Amazon Redshift peut utiliser TRUE , t , true , y , yes et 1 comme valeurs littérales valides pour "true". Le type de données BOOL de BigQuery utilise un champ TRUE non sensible à la casse. |
CHAR |
STRING |
||
VARCHAR |
STRING |
||
DATE |
DATE |
||
TIMESTAMP |
TIMESTAMP WITHOUT TIME ZONE |
DATETIME |
|
TIMESTAMPTZ |
TIMESTAMP |
Remarque : Dans BigQuery, les fuseaux horaires sont utilisés lors de l'analyse ou du formatage des horodatages à des fins d'affichage. Un horodatage au format de chaîne peut inclure un fuseau horaire, mais lorsque BigQuery analyse la chaîne, il stocke l'horodatage dans l'heure UTC équivalente. Lorsqu'un fuseau horaire n'est pas spécifié explicitement, le fuseau horaire par défaut est utilisé (UTC). Les noms de fuseau horaire ou les décalages par rapport à l'heure UTC utilisant le format (-|+)HH:MM sont acceptés, mais les abréviations de fuseau horaire telles que PDT ne le sont pas. | |
GEOMETRY |
GEOGRAPHY |
Compatibilité avec l'interrogation des données géospatiales. |
BigQuery dispose également des types de données suivants, qui ne sont pas associés à une empreinte Amazon Redshift directe :
Types de conversion implicites
Lors de la migration vers BigQuery, vous devez convertir la plupart de vos conversions implicites Amazon Redshift en conversions explicites BigQuery, à l'exception des types de données suivants que BigQuery convertit implicitement.
BigQuery effectue des conversions implicites pour les types de données suivants :
Depuis le type BigQuery | Vers le type BigQuery |
---|---|
|
|
|
|
|
|
BigQuery effectue également des conversions implicites pour les littéraux suivants :
Depuis le type BigQuery | Vers le type BigQuery |
---|---|
Littéral de STRING (par exemple, "2008-12-25") |
|
Littéral de STRING (par exemple, "2008-12-25 15:30:00") |
|
Littéral de STRING (par exemple, "2008-12-25T07:30:00") |
|
Littéral de STRING (par exemple, "15:30:00") |
|
Types de conversions explicites
Vous pouvez convertir les types de données Amazon Redshift que BigQuery ne convertit pas implicitement à l'aide de la fonction CAST(expression AS type)
de BigQuery ou l'une des fonctions de conversion DATE
et TIMESTAMP
.
Lors de la migration de vos requêtes, modifiez toutes les occurrences de la fonction
CONVERT(type, expression)
d'Amazon Redshift (ou la syntaxe ::) vers la fonctionCAST(expression AS type)
de BigQuery comme indiqué dans le tableau de la section Fonctions de mise en forme des types de données.
Syntaxe des requêtes
Cette section traite des différences de syntaxe des requêtes entre Amazon Redshift et BigQuery.
Instruction SELECT
La plupart des instructions SELECT
Amazon Redshift sont compatibles avec BigQuery. Le tableau suivant contient une liste de différences mineures.
Amazon Redshift | BigQuery |
---|---|
|
|
|
|
BigQuery accepte également les expressions suivantes dans les instructions SELECT
, qui n'ont pas d'équivalent Amazon Redshift :
Clause FROM
Une clause FROM
d'une requête répertorie les références de table à partir desquelles les données sont sélectionnées. Dans Amazon Redshift, les références de tables possibles incluent les tables, les vues et les sous-requêtes. Toutes ces références de table sont acceptées dans BigQuery.
Les tables BigQuery peuvent être référencées dans la clause FROM
à l'aide des éléments suivants :
[project_id].[dataset_id].[table_name]
[dataset_id].[table_name]
[table_name]
BigQuery accepte également d'autres références de table :
- Versions historiques de la définition de table et des lignes, en utilisant
FOR SYSTEM_TIME AS OF
- Chemins d'accès de champ, ou tout chemin menant à un champ dans un type de données (par exemple, une
STRUCT
). - Tableaux aplatis.
Types JOIN
Amazon Redshift et BigQuery sont compatibles avec les types de jointure suivants :
[INNER] JOIN
LEFT [OUTER] JOIN
RIGHT [OUTER] JOIN
FULL [OUTER] JOIN
CROSS JOIN
et la jointure croisée implicite équivalente.
Le tableau suivant contient une liste de différences mineures.
Amazon Redshift | BigQuery |
---|---|
|
Remarque: Dans BigQuery, les clauses JOIN nécessitent une condition JOIN , sauf si la clause est un CROSS
JOIN ou que l'une des tables jointes est un champ dans un type de données ou un tableau. |
Clause WITH
Une clause WITH
BigQuery contient une ou plusieurs sous-requêtes nommées qui s'exécutent lorsqu'une instruction SELECT
ultérieure y fait référence. Les clauses WITH
d'Amazon Redshift se comportent de la même manière que BigQuery, à l'exception du fait que vous pouvez évaluer la clause une fois et réutiliser ses résultats.
Opérateurs d'ensemble
Il existe des différences mineures entre les opérateurs d'ensemble Amazon Redshift et les opérateurs d'ensemble BigQuery. Cependant, toutes les opérations d'ensemble réalisables dans Amazon Redshift sont reproductibles dans BigQuery.
Amazon Redshift | BigQuery |
---|---|
|
Remarque : BigQuery et Amazon Redshift prennent en charge l'opérateur |
|
|
|
|
|
|
|
Remarque : BigQuery nécessite des parenthèses pour séparer les différentes opérations d'ensemble. Si le même opérateur d'ensemble est répété, les parenthèses ne sont pas nécessaires. |
Clause ORDER BY
Il existe des différences mineures entre les clauses ORDER BY
D'Amazon Redshift et les clauses ORDER BY
de BigQuery.
Amazon Redshift | BigQuery |
---|---|
Dans Amazon Redshift, les NULL sont classées en dernier par défaut (ordre croissant). |
Dans BigQuery, les NULL sont classés par défaut en premier (par ordre croissant). |
|
Remarque : BigQuery n'utilise pas la syntaxe LIMIT ALL . Toutefois, ORDER BY trie toutes les lignes par défaut, ce qui entraîne le même comportement que la clause LIMIT ALL d'Amazon Redshift. Nous vous recommandons vivement d'inclure une clause LIMIT avec chaque clause ORDER BY . Le tri de toutes les lignes de résultats dégrade inutilement les performances d'exécution des requêtes. |
|
Remarque : Dans BigQuery, OFFSET doit être utilisé avec un compte LIMIT . Veillez à définir la valeur de compte INT64 sur le nombre minimal de lignes ordonnées nécessaires.
Le tri de toutes les lignes de résultats dégrade inutilement les performances d'exécution des requêtes. |
Conditions
Le tableau suivant présente les conditions Amazon Redshift ou prédicats qui sont spécifiques à Amazon Redshift et doivent être convertis dans leur équivalent BigQuery.
Amazon Redshift | BigQuery |
---|---|
|
|
|
|
|
|
|
Remarque : BigQuery n'accepte pas les caractères d'échappement personnalisés. Vous devez utiliser deux barres obliques inverses (\\) comme caractères d'échappement pour BigQuery. |
|
Remarque : Si NOT est spécifié, encapsulez l'expression IF ci-dessus dans une expression NOT comme indiqué ci-dessous :
|
|
|
Fonctions
Les sections suivantes répertorient les fonctions Amazon Redshift et leurs équivalents dans BigQuery.
Fonctions d'agrégation
Le tableau suivant présente les mappages des fonctions courantes d'agrégation, d'analyse agrégée et d'agrégation approximative d'Amazon Redshift avec leurs équivalents dans BigQuery.
Amazon Redshift | BigQuery |
---|---|
APPROXIMATE
COUNT(DISTINCT expression) |
APPROX_COUNT_DISTINCT(expression) |
APPROXIMATE
PERCENTILE_DISC( |
APPROX_QUANTILES(expression,
100) |
AVG([DISTINCT] expression) |
AVG([DISTINCT] expression) |
COUNT(expression) |
COUNT(expression) |
LISTAGG( |
STRING_AGG( |
MAX(expression) |
MAX(expression) |
MEDIAN(median_expression) |
PERCENTILE_CONT( median_expression, 0.5
) OVER() |
MIN(expression) |
MIN(expression) |
PERCENTILE_CONT( |
PERCENTILE_CONT( Remarque : Ne couvre pas les cas d'utilisation d'agrégation. |
STDDEV([DISTINCT] expression) |
STDDEV([DISTINCT] expression) |
STDDEV_SAMP([DISTINCT] expression) |
STDDEV_SAMP([DISTINCT] expression) |
STDDEV_POP([DISTINCT] expression) |
STDDEV_POP([DISTINCT] expression) |
SUM([DISTINCT] expression) |
SUM([DISTINCT] expression) |
VARIANCE([DISTINCT] expression) |
VARIANCE([DISTINCT] expression) |
VAR_SAMP([DISTINCT] expression) |
VAR_SAMP([DISTINCT] expression) |
VAR_POP([DISTINCT] expression) |
VAR_POP([DISTINCT] expression) |
BigQuery propose également les fonctions d'agrégation, d'analyse analytique et d'agrégation approximative de BigQuery, comme indiqué ci-dessous, qui n'ont pas d'équivalent direct dans Amazon Redshift:
ANY_VALUE
APPROX_TOP_COUNT
APPROX_TOP_SUM
ARRAY_AGG
ARRAY_CONCAT_AGG
COUNTIF
CORR
COVAR_POP
COVAR_SAMP
Fonctions d'agrégation bit à bit
Le tableau suivant présente les mappages des fonctions d'agrégation bit à bit courantes d'Amazon Redshift avec leurs équivalents dans BigQuery.
Amazon Redshift | BigQuery |
---|---|
BIT_AND(expression) |
BIT_AND(expression) |
BIT_OR(expression) |
BIT_OR(expression) |
BOOL_AND>(expression) |
LOGICAL_AND(expression) |
BOOL_OR(expression) |
LOGICAL_OR(expression) |
BigQuery propose également la fonction d'agrégation bit à bit suivante, qui n'a pas d'équivalent analogue dans Amazon Redshift :
Fonctions de fenêtrage
Le tableau suivant présente les mappages des fonctions de fenêtrage courantes d'Amazon Redshift avec leurs équivalents dans BigQuery. Les fonctions de fenêtrage dans BigQuery sont les suivantes : Fonctions d'agrégation analytique, Fonctions d'agrégation, Fonctions de navigation et Fonctions de numérotation.
Amazon Redshift | BigQuery |
---|---|
AVG(expression) OVER |
AVG(expression) OVER |
COUNT(expression) OVER |
COUNT(expression) OVER |
CUME_DIST() OVER |
CUME_DIST() OVER |
DENSE_RANK() OVER |
DENSE_RANK() OVER |
FIRST_VALUE(expression)
OVER |
FIRST_VALUE(expression)
OVER |
LAST_VALUE(expression) OVER |
LAST_VALUE(expression) OVER |
LAG(value_expr [, offset])
OVER |
LAG(value_expr [, offset])
OVER |
LEAD(value_expr [, offset])
OVER |
LEAD(value_expr [, offset])
OVER |
LISTAGG( |
STRING_AGG( |
MAX(expression) OVER |
MAX(expression) OVER |
MEDIAN(median_expression)
OVER |
PERCENTILE_CONT( |
MIN(expression) OVER |
MIN(expression) OVER |
NTH_VALUE(expression,
offset) OVER (
[PARTITION BY window_partition] [ORDER BY window_ordering
frame_clause]
) |
NTH_VALUE(expression,
offset) OVER |
NTILE(expr) OVER |
NTILE(expr) OVER |
PERCENT_RANK() OVER |
PERCENT_RANK() OVER |
PERCENTILE_CONT(percentile)
|
PERCENTILE_CONT(expr,
percentile) OVER |
PERCENTILE_DISC(percentile)
WITHIN GROUP (ORDER BY expr) OVER |
PERCENTILE_DISC(expr,
percentile) OVER |
RANK() OVER |
RANK() OVER |
RATIO_TO_REPORT(ratio_expression)
OVER |
ratio_expression SUM(ratio_expression) OVER |
ROW_NUMBER() OVER |
ROW_NUMBER() OVER |
STDDEV(expression) OVER |
STDDEV(expression) OVER |
STDDEV_SAMP(expression)
OVER |
STDDEV_SAMP(expression)
OVER |
STDDEV_POP(expression) OVER |
STDDEV_POP(expression) OVER |
SUM(expression) OVER |
SUM(expression) OVER |
VAR_POP(expression) OVER |
VAR_POP(expression) OVER |
VAR_SAMP(expression) OVER |
VAR_SAMP(expression) OVER |
VARIANCE(expression) OVER |
VARIANCE(expression) OVER |
Expressions conditionnelles
Le tableau suivant présente les mappages des expressions conditionnelles courantes d'Amazon Redshift avec leurs équivalents dans BigQuery.
Amazon Redshift | BigQuery |
---|---|
CASEexpression |
CASE expression |
COALESCE(expression1[,
...]) |
COALESCE(expression1[,
...]) |
DECODE( |
CASE expression |
GREATEST(value [,
...]) |
GREATEST(value [,
...]) |
LEAST(value [, ...]) |
LEAST(value [, ...]) |
NVL(expression1[, ...])
|
COALESCE(expression1[,
...]) |
NVL2( |
IF( |
NULLIF(expression1,
expression2) |
NULLIF(expression1,
expression2) |
BigQuery propose également les expressions conditionnelles suivantes, qui n'ont pas d'équivalent direct dans Amazon Redshift :
Fonctions de date et heure
Le tableau suivant présente les mappages des fonctions de date et heure courantes d'Amazon Redshift avec leurs équivalents dans BigQuery. Les fonctions de date et heure de BigQuery incluent les fonctions de date, les fonctions datetime, les fonctions temporelles et les fonctions de code temporel.
Gardez à l'esprit que les fonctions qui semblent identiques dans Amazon Redshift et BigQuery peuvent renvoyer des types de données différents.
Amazon Redshift | BigQuery |
---|---|
ADD_MONTHS( |
CAST( DATE_ADD( |
timestamptz_or_timestamp AT TIME
ZONE timezone |
PARSE_TIMESTAMP( Remarque : Les fuseaux horaires sont utilisés lors de l'analyse ou du formatage des horodatages à des fins d'affichage. Un horodatage au format de chaîne peut inclure un fuseau horaire, mais lorsque BigQuery analyse la chaîne, il stocke l'horodatage dans l'heure UTC équivalente. Lorsqu'un fuseau horaire n'est pas spécifié explicitement, le fuseau horaire par défaut est utilisé (UTC). Les noms de fuseau horaire ou les décalages par rapport à l'heure UTC sont acceptés, mais les abréviations de fuseau horaire (telles que PDT) ne le sont pas. |
CONVERT_TIMEZONE( |
PARSE_TIMESTAMP( Remarque : source_timezone correspond à UTC dans BigQuery. |
CURRENT_DATE Remarque : Renvoie la date de début de la transaction en cours dans le fuseau horaire de la session en cours (par défaut, UTC). |
CURRENT_DATE() Remarque : Renvoie la date de début de l'instruction en cours dans le fuseau horaire UTC. |
DATE_CMP(date1, date2)
|
CASE |
DATE_CMP_TIMESTAMP(date1,
date2) |
CASE |
DATE_CMP_TIMESTAMPTZ(date,
timestamptz) |
CASE |
DATE_PART_YEAR(date) |
EXTRACT(YEAR FROM
date) |
DATEADD(date_part,
interval, date) |
CAST( |
DATEDIFF( |
DATE_DIFF( |
DATE_PART(date_part, date)
|
EXTRACT(date_part FROM
date) |
DATE_TRUNC('date_part',
timestamp) |
TIMESTAMP_TRUNC(timestamp,
date_part) |
EXTRACT(date_part FROM
timestamp) |
EXTRACT(date_part FROM
timestamp) |
GETDATE() |
PARSE_TIMESTAMP( |
INTERVAL_CMP( |
Pour les intervalles dans Redshift, une année compte 360 jours.
Dans BigQuery, vous pouvez utiliser la fonction définie par l'utilisateur suivante pour analyser un intervalle Redshift et le traduire en secondes. CREATE TEMP FUNCTION Pour comparer des littéraux d'intervalle, procédez comme suit : IF( |
LAST_DAY(date) |
DATE_SUB( |
MONTHS_BETWEEN( |
DATE_DIFF( |
NEXT_DAY(date, day) |
DATE_ADD( |
SYSDATE Remarque : Renvoie l'horodatage de début pour la transaction en cours dans le fuseau horaire de la session en cours (UTC par défaut). |
CURRENT_TIMESTAMP() Remarque : Renvoie l'horodatage de début pour l'instruction en cours dans le fuseau horaire UTC. |
TIMEOFDAY() |
FORMAT_TIMESTAMP( |
TIMESTAMP_CMP( |
CASE |
TIMESTAMP_CMP_DATE( |
CASE |
TIMESTAMP_CMP_TIMESTAMPTZ(
Remarque : Redshift compare les horodatages dans le fuseau horaire défini par la session utilisateur. Le fuseau horaire par défaut d'une session utilisateur est UTC. |
CASE Remarque : BigQuery compare les horodatages dans le fuseau horaire UTC. |
TIMESTAMPTZ_CMP( Remarque : Redshift compare les horodatages dans le fuseau horaire défini par la session utilisateur. Le fuseau horaire par défaut d'une session utilisateur est UTC. |
CASE Remarque : BigQuery compare les horodatages dans le fuseau horaire UTC. |
TIMESTAMPTZ_CMP_DATE( Remarque : Redshift compare les horodatages dans le fuseau horaire défini par la session utilisateur. Le fuseau horaire par défaut d'une session utilisateur est UTC. |
CASE Remarque : BigQuery compare les horodatages dans le fuseau horaire UTC. |
TIMESTAMPTZ_CMP_TIMESTAMP(
Remarque : Redshift compare les horodatages dans le fuseau horaire défini par la session utilisateur. Le fuseau horaire par défaut d'une session utilisateur est UTC. |
CASE Remarque : BigQuery compare les horodatages dans le fuseau horaire UTC. |
TIMEZONE( |
PARSE_TIMESTAMP( Remarque : Les fuseaux horaires sont utilisés lors de l'analyse ou du formatage des horodatages à des fins d'affichage. Un horodatage au format de chaîne peut inclure un fuseau horaire, mais lorsque BigQuery analyse la chaîne, il stocke l'horodatage dans l'heure UTC équivalente. Lorsqu'un fuseau horaire n'est pas spécifié explicitement, le fuseau horaire par défaut est utilisé (UTC). Les noms de fuseau horaire ou les décalages par rapport à l'heure UTC (-HH:MM) sont acceptés, mais les abréviations de fuseau horaire (telles que PDT) ne le sont pas. |
TO_TIMESTAMP(timestamp,
format) |
PARSE_TIMESTAMP( Remarque: BigQuery applique un ensemble différent d'éléments de format. Les fuseaux horaires sont utilisés lors de l'analyse ou du formatage des horodatages à des fins d'affichage. Un horodatage au format de chaîne peut inclure un fuseau horaire, mais lorsque BigQuery analyse la chaîne, il stocke l'horodatage dans l'heure UTC équivalente. Lorsqu'un fuseau horaire n'est pas spécifié explicitement, le fuseau horaire par défaut est utilisé (UTC). Les noms de fuseau horaire ou les décalages par rapport à l'heure UTC (-HH:MM) sont acceptés dans la chaîne de format, mais les abréviations de fuseau horaire (telles que PDT) ne le sont pas. |
TRUNC(timestamp) |
CAST(timestamp AS
DATE) |
BigQuery propose également les fonctions de date et heure suivantes, qui n'ont pas d'équivalent direct dans Amazon Redshift :
EXTRACT
DATE
DATE_SUB
DATE_ADD
(renvoie le type de donnéesDATE
)DATE_FROM_UNIX_DATE
FORMAT_DATE
PARSE_DATE
UNIX_DATE
DATETIME
DATETIME_ADD
DATETIME_SUB
DATETIME_DIFF
DATETIME_TRUNC
FORMAT_DATETIME
PARSE_DATETIME
CURRENT_TIME
TIME
TIME_ADD
TIME_SUB
TIME_DIFF
TIME_TRUNC
FORMAT_TIME
PARSE_TIME
TIMESTAMP_SECONDS
TIMESTAMP_MILLIS
TIMESTAMP_MICROS
UNIX_SECONDS
UNIX_MILLIS
UNIX_MICROS
Opérateurs mathématiques
Le tableau suivant présente les mappages des opérateurs mathématiques courants d'Amazon Redshift avec leurs équivalents dans BigQuery.
Amazon Redshift | BigQuery |
---|---|
|
|
|
|
|
|
Remarque : Si l'opérateur effectue une division de nombres entiers (en d'autres termes, si X et Y sont tous les deux des entiers), un entier est renvoyé. Si l'opérateur effectue une division de nombres non-entiers, un non-entier est renvoyé. |
En cas de division de nombres entiers : CAST(FLOOR(X / Y) AS INT64)
En cas de division de nombres non-entiers :
Remarque : La division dans BigQuery renvoie un nombre non-entier. Pour éviter les erreurs dues à une opération de division (erreur de division par zéro), utilisez SAFE_DIVIDE(X, Y) ou IEEE_DIVIDE(X, Y) . |
|
Remarque : Pour éviter les erreurs dues à une opération de division (division par zéro), utilisez SAFE.MOD(X, Y) . SAFE.MOD(X, 0) fournit un résultat égal à 0. |
|
Remarque : Contrairement à celui d'Amazon Redshift, l'opérateur ^ de BigQuery effectue une opération xor bit à bit. |
|
Remarque : Pour éviter les erreurs dues à une opération de racine carrée (entrée négative), utilisez SAFE.SQRT(X) . L'utilisation d'entrées négatives avec SAFE.SQRT(X) fournit un résultat de NULL . |
|
Remarque : La fonction POWER(X, Y) de BigQuery renvoie une erreur si la valeur de X est inférieure à 0 et que Y est une valeur non entière. |
|
|
|
Cet opérateur renvoie 0 ou une séquence d'octets de b'\x00' si le deuxième opérande Y est supérieur ou égal à la longueur en bits du premier opérande X (par exemple, 64 si X est de type INT64). Cet opérateur génère une erreur si Y est négatif. |
|
Remarque : Décale le premier opérande X vers la droite. Cet opérateur n'effectue pas d'extension de bit de signe avec un type signé (il remplit les bits vacants à gauche avec des 0). Cet opérateur renvoie 0 ou une séquence d'octets de b'\x00' si le deuxième opérande Y est supérieur ou égal à la longueur en bits du premier opérande X (par exemple, 64 si X est de type INT64). Cet opérateur génère une erreur si Y est négatif. |
|
|
|
|
|
|
BigQuery propose également l'opérateur mathématique suivant, qui ne dispose pas d'un équivalent direct dans Amazon Redshift :
X ^ Y
(au niveau du bit xor)
Fonctions mathématiques
Amazon Redshift | BigQuery |
---|---|
ABS(number) |
ABS(number) |
ACOS(number) |
ACOS(number) |
ASIN(number) |
ASIN(number) |
ATAN(number) |
ATAN(number) |
ATAN2(number1,
number2) |
ATAN2(number1,
number2) |
CBRT(number) |
POWER(number, 1/3) |
CEIL(number) |
CEIL(number) |
CEILING(number) |
CEILING(number) |
CHECKSUM(expression) |
FARM_FINGERPRINT(expression)
|
COS(number) |
COS(number) |
COT(number) |
1/TAN(number) |
DEGREES(number) |
number *180/ACOS(-1) |
DEXP(number) |
EXP(number) |
DLOG1(number) |
LN(number) |
DLOG10(number) |
LOG10(number) |
EXP(number) |
EXP(number) |
FLOOR(number) |
FLOOR(number) |
LNnumber) |
LN(number) |
LOG(number) |
LOG10(number) |
MOD(number1, number2) |
MOD(number1, number2) |
PI |
ACOS(-1) |
POWER(expression1,
expression2) |
POWER(expression1,
expression2) |
RADIANS(number) |
ACOS(-1)*(number/180) |
RANDOM() |
RAND() |
ROUND(number [,
integer]) |
ROUND(number [,
integer]) |
SIN(number) |
SIN(number) |
SIGN(number) |
SIGN(number) |
SQRT(number) |
SQRT(number) |
TAN(number) |
TAN(number) |
TO_HEX(number) |
FORMAT('%x', number) |
TRUNC(number [,
integer])+-+++ |
TRUNC(number [, integer])
|
Fonctions de chaîne
Amazon Redshift | BigQuery |
---|---|
string1 || string2 |
CONCAT(string1,
string2) |
BPCHARCMP(string1,
string2) |
CASE |
BTRIM(string [,
matching_string]) |
TRIM(string [,
matching_string]) |
BTTEXT_PATTERN_CMP(string1,
string2) |
CASE |
CHAR_LENGTH(expression) |
CHAR_LENGTH(expression) |
CHARACTER_LENGTH(expression) |
CHARACTER_LENGTH(expression) |
CHARINDEX(substring,
string) |
STRPOS(string, substring)
|
CHR(number) |
CODE_POINTS_TO_STRING([number])
|
CONCAT(string1,
string2) |
CONCAT(string1,
string2) Remarque : La fonction CONCAT (...) de BigQuery accepte la concaténation de n'importe quel nombre de chaînes. |
CRC32 |
Fonction définie par l'utilisateur personnalisée. |
FUNC_SHA1(string) |
SHA1(string) |
INITCAP |
INITCAP |
LEFT(string, integer) |
SUBSTR(string, 0, integer)
|
RIGHT(string, integer)
|
SUBSTR(string,
-integer) |
LEN(expression) |
LENGTH(expression) |
LENGTH(expression) |
LENGTH(expression) |
LOWER(string) |
LOWER(string) |
LPAD(string1, length[,
string2]) |
LPAD(string1, length[,
string2]) |
RPAD(string1, length[,
string2]) |
RPAD(string1, length[,
string2]) |
LTRIM(string,
trim_chars) |
LTRIM(string,
trim_chars) |
MD5(string) |
MD5(string) |
OCTET_LENGTH(expression) |
BYTE_LENGTH(expression) |
POSITION(substring IN
string) |
STRPOS(string,
substring) |
QUOTE_IDENT(string) |
CONCAT('"',string,'"') |
QUOTE_LITERAL(string) |
CONCAT("'",string,"'")
|
REGEXP_COUNT(
source_string, pattern |
ARRAY_LENGTH( REGEXP_EXTRACT_ALL( Si position est spécifié : ARRAY_LENGTH( REGEXP_EXTRACT_ALL( Remarque : La bibliothèque re2 permet l'utilisation d'expressions régulières dans BigQuery. Consultez la documentation pour découvrir la syntaxe d'expression régulière à utiliser. |
REGEXP_INSTR( |
IFNULL( STRPOS( Si source_string est spécifié: REGEXP_REPLACE( Si position est spécifié:IFNULL( STRPOS( Si occurrence est spécifié:IFNULL( STRPOS( Remarque: BigQuery fournit un support de l'expression régulière en utilisant la bibliothèque re2 ; voir la documentation de la syntaxe de son expression régulière . |
REGEXP_REPLACE(
source_string, |
REGEXP_REPLACE( Si source_string est spécifié:
REGEXP_REPLACE( Si position est spécifié:CASE |
REGEXP_SUBSTR(
source_string, pattern |
REGEXP_EXTRACT( Si position est spécifié:REGEXP_EXTRACT( Si occurrence est spécifié :REGEXP_EXTRACT_ALL( Remarque: BigQuery fournit un support de l'expression régulière en utilisant la bibliothèque re2 ; voir la documentation de la syntaxe de son expression régulière.
|
REPEAT(string,
integer) |
REPEAT(string,
integer) |
REPLACE(string, old_chars,
new_chars) |
REPLACE(string, old_chars,
new_chars) |
REPLICA(string,
integer) |
REPEAT(string,
integer) |
REVERSE(expression) |
REVERSE(expression) |
RTRIM(string,
trim_chars) |
RTRIM(string,
trim_chars) |
SPLIT_PART(string,
delimiter, part) |
SPLIT( |
STRPOS(string,
substring) |
STRPOS(string,
substring) |
STRTOL(string, base) |
|
SUBSTRING( |
SUBSTR( |
TEXTLEN(expression) |
LENGTH(expression) |
TRANSLATE( |
Peut être mis en œuvre à l'aide des fonctions définies par l'utilisateur : CREATE TEMP FUNCTION |
TRIM([BOTH] string) |
TRIM(string) |
TRIM([BOTH] characters FROM
string) |
TRIM(string, characters)
|
UPPER(string) |
UPPER(string) |
Fonctions de mise en forme des types de données
Amazon Redshift | BigQuery |
---|---|
CAST(expression AS type) |
CAST(expression AS type) |
expression ::
type |
CAST(expression AS type) |
CONVERT(type, expression) |
CAST(expression AS type) |
TO_CHAR(
|
FORMAT_TIMESTAMP( Remarque : La spécification d'une chaîne de format pour timestamp_expression diffère dans BigQuery et Amazon Redshift. |
TO_CHAR(
|
FORMAT( Remarque : La spécification d'une chaîne de format pour timestamp_expression diffère dans BigQuery et Amazon Redshift.
|
TO_DATE(date_string, format) |
PARSE_DATE(date_string, format)
Remarque : La spécification d'une chaîne de format pour date_string diffère dans BigQuery et Amazon Redshift. |
TO_NUMBER(string, format) |
CAST( Remarque : La spécification d'une chaîne de format numérique diffère dans BigQuery et Amazon Redshift. |
SAFE_CAST
("apple"
AS INT64)
renvoie NULL
. SAFE_CAST
(expression
AS typename)
NULL
Syntaxe LMD
Cette section traite des différences de syntaxe du langage de manipulation de données entre Amazon Redshift et BigQuery.
Instruction INSERT
Amazon Redshift propose un mot clé DEFAULT
configurable pour les colonnes. Dans BigQuery, la valeur DEFAULT
des colonnes pouvant être vides est NULL
, et DEFAULT
n'est pas accepté pour les colonnes obligatoires. La plupart des instructions INSERT
d'Amazon Redshift sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.
Amazon Redshift | BigQuery |
---|---|
INSERT INTO table (column1 [, ...]) |
INSERT [INTO] table (column1 [, ...]) |
INSERT INTO table (column1, [,...]) VALUES ( |
INSERT [INTO] table (column1, [,...]) |
BigQuery permet également d'insérer des valeurs à l'aide d'une sous-requête (où l'une des valeurs est calculée à l'aide d'une sous-requête), ce qui n'est pas compatible avec Amazon Redshift. Exemple :
INSERT INTO table (column1, column2)
VALUES ('value_1', (
SELECT column2
FROM table2
))
Instruction COPY
La commande COPY
d'Amazon Redshift charge des données dans une table à partir de fichiers de données ou d'une table Amazon DynamoDB.
BigQuery n'utilise pas la commande SQL COPY
pour charger des données, mais vous pouvez utiliser l'un des outils et options non-SQL pour charger des données dans des tables BigQuery.
Vous pouvez également utiliser les récepteurs de pipelines de données fournis dans Apache Spark ou Apache Beam pour écrire des données dans BigQuery.
Instruction UPDATE
La plupart des instructions UPDATE
d'Amazon Redshift sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.
Amazon Redshift | BigQuery |
---|---|
UPDATE table |
UPDATE table Remarque : Toutes les instructions UPDATE de BigQuery nécessitent un mot clé WHERE , suivi d'une condition. |
UPDATE table |
UPDATE table Remarque : La commande UPDATE de BigQuery n'est pas compatible avec les valeurs DEFAULT .
Si l'instruction Amazon Redshift UPDATE n'inclut pas de clause WHERE , l'instruction BigQuery UPDATE doit être conditionnée pour WHERE TRUE . |
Instructions DELETE
et TRUNCATE
Les instructions DELETE
et TRUNCATE
permettent de supprimer des lignes d'une table sans que cela n'affecte son schéma ou ses index.
Dans Amazon Redshift, l'instruction TRUNCATE
est recommandée plutôt qu'une instruction DELETE
non qualifiée, car elle est plus rapide et ne nécessite pas d'opérations VACUUM
et ANALYZE
par la suite.
Cependant, vous pouvez utiliser les instructions DELETE
pour obtenir le même effet.
Dans BigQuery, l'instruction DELETE
doit comporter une clause WHERE
. Pour en savoir plus sur l'instruction DELETE
dans BigQuery, consultez les exemples d'instructions DELETE
BigQuery dans la documentation sur le LMD.
Amazon Redshift | BigQuery |
---|---|
DELETE
[FROM] table_name TRUNCATE
[TABLE] table_name |
DELETE FROM table_name Les instructions BigQuery DELETE nécessitent une clause WHERE . |
DELETE FROM table_name |
DELETE FROM table_name DELETE FROM table_name Dans Amazon Redshift, USING permet de référencer des tables supplémentaires dans la clause WHERE . Vous pouvez effectuer cette opération dans BigQuery à l'aide d'une sous-requête dans la clause WHERE . |
Instruction MERGE
L'instruction MERGE
peut combiner les opérations INSERT
, UPDATE
et DELETE
en une seule instruction upsert et effectuer les opérations de manière atomique. L'opération MERGE
doit correspondre à une ligne source au maximum pour chaque ligne cible.
Amazon Redshift ne peut pas prendre en charge une seule commande MERGE
. Toutefois, une opération de fusion peut être effectuée dans Amazon Redshift en mettant en œuvre des opérations INSERT
, UPDATE
et DELETE
dans une même transaction.
Opération de fusion en remplaçant les lignes existantes
Dans Amazon Redshift, vous pouvez effectuer un écrasement de toutes les colonnes de la table cible à l'aide d'une instruction DELETE
, puis d'une instruction INSERT
. L'instruction DELETE
supprime les lignes qui doivent être mises à jour, puis l'instruction INSERT
insère les lignes mises à jour. Les tables BigQuery sont limitées à 1 000 instructions LMD par jour. Vous devez donc regrouper les instructions INSERT
, UPDATE
et DELETE
dans une même instruction MERGE
, comme indiqué dans le tableau suivant.
Amazon Redshift | BigQuery |
---|---|
Consultez la section Effectuer une opération de fusion en remplaçant les lignes existantes. CREATE TEMP TABLE temp_table; |
MERGE target Remarque : Toutes les colonnes doivent être répertoriées si vous souhaitez mettre à jour toutes les colonnes. |
Consultez la section Effectuer une opération de fusion en spécifiant une liste de colonnes. CREATE TEMP TABLE temp_table; |
MERGE target |
Syntaxe LDD
Cette section traite des différences de syntaxe du langage de définition de données entre Amazon Redshift et BigQuery.
Instruction SELECT INTO
Dans Amazon Redshift, vous pouvez insérer les résultats d'une requête dans une nouvelle table à l'aide de l'instruction SELECT INTO
, en combinant la création de table et l'insertion.
Amazon Redshift | BigQuery |
---|---|
SELECT expression, ... INTO table |
INSERT table |
WITH subquery_table AS ( SELECT ... |
INSERT table |
SELECT expression |
BigQuery propose plusieurs méthodes pour émuler des tables temporaires. Pour plus d'informations, consultez la section Tables temporaires. |
Instruction CREATE TABLE
La plupart des instructions CREATE TABLE
Amazon Redshift sont compatibles avec BigQuery, à l'exception des éléments de syntaxe suivants, qui ne sont pas utilisés dans BigQuery :
Amazon Redshift | BigQuery |
---|---|
CREATE TABLE table_name ( Remarque : Les contraintes UNIQUE et PRIMARY KEY sont informatives et ne sont pas appliquées par le système Amazon Redshift. |
CREATE TABLE table_name ( |
CREATE TABLE table_name Remarque : Les contraintes UNIQUE et PRIMARY KEY sont informatives et ne sont pas appliquées par le système Amazon Redshift.
|
CREATE TABLE table_name Remarque : BigQuery n'utilise pas les contraintes de table UNIQUE , PRIMARY KEY ou FOREIGN KEY . Pour obtenir une optimisation similaire à celle fournie par ces contraintes lors de l'exécution des requêtes, partitionnez et mettez en cluster vos tables BigQuery. CLUSTER BY accepte jusqu'à quatre colonnes. |
CREATE TABLE table_name |
Consultez cet exemple pour apprendre à utiliser les tables INFORMATION_SCHEMA pour copier les noms de colonnes, les types de données et les contraintes NOT NULL vers une nouvelle table. |
CREATE TABLE table_name Remarque : Dans Amazon Redshift, le paramètre BACKUP
NO est spécifié pour gagner du temps de traitement et réduire l'espace de stockage. |
L'option de table BACKUP NO n'est pas utilisée ou nécessaire, car BigQuery conserve automatiquement jusqu'à sept jours de versions historiques de toutes vos tables, sans effet sur le temps de traitement ou le stockage facturé.
|
CREATE TABLE table_name |
BigQuery accepte le clustering, ce qui permet de stocker les clés dans un ordre trié. |
CREATE TABLE table_name |
CREATE TABLE table_name |
CREATE TABLE IF NOT EXISTS table_name ... |
CREATE TABLE IF NOT EXISTS |
BigQuery est également compatible avec l'instruction LDD CREATE OR REPLACE TABLE
, qui écrase une table si elle existe déjà.
L'instruction BigQuery CREATE TABLE
accepte également les clauses suivantes, qui n'ont pas d'équivalent dans Amazon Redshift :
Pour en savoir plus sur l'instruction CREATE TABLE
dans BigQuery, consultez les exemples d'instructions CREATE TABLE
BigQuery dans la documentation sur le LMD.
Tables temporaires
Amazon Redshift est compatible avec les tables temporaires, qui ne sont visibles que dans la session en cours. Il existe plusieurs façons d'émuler des tables temporaires dans BigQuery :
- Valeur TTL de l'ensemble de données : créez un ensemble de données ayant une durée de vie courte (par exemple, 1 heure) afin que les tables créées dans cet ensemble de données soient effectivement temporaires, car elles ne persisteront pas au-delà de la durée de vie d'un script. Vous pouvez ajouter le préfixe à tous les noms de tables de cet ensemble de données pour indiquer clairement que les tables sont temporaires.
Valeur TTL de la table : créez une table ayant une durée de vie courte à l'aide d'instructions LDD semblables à ce qui suit :
CREATE TABLE temp.name (col1, col2, ...) OPTIONS (expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
Instruction CREATE VIEW
Le tableau suivant présente les équivalences entre Amazon Redshift et BigQuery pour l'instruction CREATE VIEW
.
Amazon Redshift | BigQuery |
---|---|
CREATE VIEW view_name AS SELECT ... code> |
CREATE VIEW view_name AS SELECT
... |
CREATE OR REPLACE VIEW view_name AS SELECT ... |
CREATE OR REPLACE VIEW |
CREATE VIEW view_name |
CREATE VIEW view_name AS SELECT
... |
Non compatible. | CREATE VIEW IF NOT EXISTS c
view_name Crée une vue uniquement si la vue n'existe pas dans l'ensemble de données spécifié. |
CREATE VIEW view_name Dans Amazon Redshift, une vue à liaison tardive est requise pour référencer une table externe. |
Dans BigQuery, tous les objets référencés doivent déjà exister pour créer une vue. BigQuery vous permet d'interroger des sources de données externes. |
Fonctions définies par l'utilisateur
Les fonctions définies par l'utilisateur (UDF) vous permettent de créer des fonctions pour des opérations personnalisées. Ces fonctions acceptent des colonnes d'entrée, effectuent des actions et renvoient le résultat de ces dernières sous la forme d'une valeur.
Amazon Redshift et BigQuery sont tous les deux compatibles avec les fonctions définies par l'utilisateur utilisant des expressions SQL. De plus, vous pouvez créer une UDF basée sur Python dans Amazon Redshift ou créer une UDF basée sur JavaScript dans BigQuery.
Reportez-vous au dépôt GitHub des utilitaires Google Cloud BigQuery pour obtenir une bibliothèque de fonctions BigQuery définies par l'utilisateur.
Syntaxe de CREATE FUNCTION
Le tableau suivant traite des différences de syntaxe de création d'UDF (fonctions définies par l'utilisateur) SQL entre Amazon Redshift et BigQuery.
Amazon Redshift | BigQuery |
---|---|
CREATE [OR
REPLACE] FUNCTION |
CREATE [OR REPLACE] FUNCTION Remarque : Dans une UDF SQL BigQuery, le type de données renvoyé est facultatif. BigQuery déduit le type renvoyé par votre fonction à partir du corps de la fonction SQL lorsqu'elle est appelée par une requête. |
CREATE [OR
REPLACE] FUNCTION |
CREATE [OR REPLACE] FUNCTION Remarque : La volatilité des fonctions n'est pas un paramètre configurable dans BigQuery. Toute volatilité d'UDF BigQuery est équivalente à la volatilité IMMUTABLE d'Amazon Redshift (c'est-à-dire qu'elle n'effectue pas de recherches de base de données et n'utilise pas d'autres informations que celles directement présentes dans sa liste d'arguments).
|
CREATE [OR
REPLACE] FUNCTION Remarque : Amazon Redshift ne prend en charge que les clauses SQL SELECT comme définition de fonction. De plus, la clause SELECT ne peut inclure aucune de clauses FROM,
INTO, WHERE, GROUP BY, ORDER BY, et LIMIT . |
CREATE [OR REPLACE] FUNCTION Remarque : BigQuery prend en charge toutes les expressions SQL comme définition de fonction. Il n'est toutefois pas possible de référencer des tables, des vues ou des modèles. |
CREATE [OR
REPLACE] FUNCTION |
CREATE [OR REPLACE] FUNCTION
function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS
data_type AS sql_function_definition Remarque : Il n'est pas nécessaire de spécifier un littéral de langage dans une UDF en langage GoogleSQL. BigQuery interprète l'expression SQL par défaut. En outre, les guillemets dollars ( $$ ) is not supported in BigQuery. |
CREATE [OR
REPLACE] FUNCTION function_name (integer, integer) RETURNS
integer IMMUTABLE AS $$ SELECT $1 + $2 $$ LANGUAGE sql |
CREATE [OR REPLACE] FUNCTION Note: BigQuery UDFs require all input arguments to be named. The Amazon Redshift argument variables ( $1 , $2 , …) are not supported in
BigQuery. |
CREATE [OR
REPLACE] FUNCTION Note: Amazon Redshift does not support ANY TYPE for SQL UDFs. However, it
supports using the ANYELEMENT
data type in Python-based UDFs. |
CREATE [OR REPLACE] FUNCTION Note: BigQuery supports using ANY TYPE as argument type. The function
accepts an input of any type for this argument. For more information,
see templated parameter in BigQuery.
|
BigQuery also supports the CREATE FUNCTION IF NOT EXISTS
statement, which
treats the query as successful and takes no action if a function with the same
name already exists.
BigQuery's CREATE FUNCTION
statement also supports creating
TEMPORARY
or TEMP
functions, which do not have an Amazon Redshift equivalent.
See calling UDFs for details on executing a BigQuery-persistent UDF.
DROP FUNCTION
syntax
The following table addresses differences in DROP FUNCTION
syntax between
Amazon Redshift and BigQuery.
Amazon Redshift | BigQuery |
---|---|
DROP
FUNCTION |
DROP FUNCTION Note: BigQuery does not require using the function's signature for deleting the function. Also, removing function dependencies is not supported in BigQuery. |
BigQuery also supports the
DROP FUNCTION IF EXISTS
statement,
which deletes the function only if the function exists in the specified
dataset.
BigQuery requires that you specify the project_name
if the function is not located in the current project.
UDF components
This section highlights the similarities and differences in UDF components between Amazon Redshift andBigQuery.
Component | Amazon Redshift | BigQuery |
---|---|---|
Name | Amazon Redshift recommends using the prefix
_f for function names to avoid conflicts with existing
or future built-in SQL function names. |
In BigQuery, you can use any custom function name. |
Arguments | Arguments are optional. You can use name and data types for Python
UDF arguments and only data types for SQL UDF arguments. In SQL UDFs,
you must refer to arguments using $1 , $2 ,
and so on. Amazon Redshift also restricts
the number of arguments to 32. |
Arguments are optional, but if you specify arguments, they must use both name and data types for both JavaScript and SQL UDFs. The maximum number of arguments for a persistent UDF is 256. |
Data type | Amazon Redshift supports a different set of data types for SQL
and Python UDFs. For a Python UDF, the data type might also be ANYELEMENT .You must specify a RETURN data type for both SQL and
Python UDFs.See Data types in this document for equivalents between data types in Amazon Redshift and in BigQuery. |
BigQuery supports a different set of data types for SQL and JavaScript UDFs. For a SQL UDF, the data type might also be ANY TYPE . For
more information, see templated parameters in
BigQuery.The RETURN data type is optional for SQL UDFs.See Supported JavaScript UDF data types for information on how BigQuery data types map to JavaScript data types. |
Definition | For both SQL and Python UDFs, you must enclose the function
definition using dollar quoting, as in a pair of dollar signs
($$ ) d'Amazon Redshift pour indiquer le début et la fin des instructions de la fonction.Pour les fonctions SQL définies par l'utilisateur, Amazon Redshift ne prend en charge qu'une clause SQL SELECT en tant que définition de fonction. De plus, la clause SELECT
ne peut inclure aucune des clauses FROM , INTO ,
WHERE , GROUP BY , ORDER BY et LIMIT
.Pour les fonctions Python définies par l'utilisateur, vous pouvez écrire un programme Python à l'aide de la bibliothèque standard Python 2.7 ou importer vos modules personnalisés en en créant un à l'aide de la commande CREATE
LIBRARY . |
Dans BigQuery, vous devez placer le code JavaScript entre guillemets. Consultez les règles de citation pour en savoir plus. Pour les UDF SQL, vous pouvez utiliser n'importe quelle expression SQL comme définition de fonction. Cependant, BigQuery ne permet pas de référencer des tables, des vues ou des modèles. Pour les UDF JavaScript, vous pouvez inclure des bibliothèques de code externes directement en utilisant la section OPTIONS . Vous pouvez également utiliser l'outil de test d'UDF (fonction définie par l'utilisateur) BigQuery pour tester vos fonctions. |
Langue | Vous devez utiliser la valeur littérale LANGUAGE pour spécifier le langage en tant que sql pour les fonctions SQL définies par l'utilisateur ou plpythonu
pour les fonctions Python définies par l'utilisateur. |
Vous n'avez pas besoin de spécifier LANGUAGE pour les UDF SQL, mais vous devez spécifier le langage js pour les UDF JavaScript. |
État | Amazon Redshift ne permet pas de créer des UDF (fonctions définies par l'utilisateur) temporaires. Amazon Redshift offre une option permettant de définir la volatilité d'une fonction en utilisant des littéraux VOLATILE , STABLE ou IMMUTABLE . L'optimiseur de requête peut ainsi optimiser la requête. |
BigQuery est compatible avec les UDF (fonctions définies par l'utilisateur) persistantes et temporaires. Vous pouvez réutiliser une fonction persistante définie par l'utilisateur dans plusieurs requêtes, alors qu'une fonction temporaire définie par l'utilisateur ne peut être utilisée que dans une seule requête. La volatilité des fonctions n'est pas un paramètre configurable dans BigQuery. Toute la volatilité des UDF (fonctions définies par l'utilisateur) BigQuery est équivalente à la volatilité IMMUTABLE
d'Amazon Redshift. |
Sécurité et privilèges | Pour créer une UDF (fonction définie par l'utilisateur), vous devez disposer d'une autorisation d'utilisation sur le langage pour SQL ou plpythonu (Python). Par défaut, USAGE ON LANGUAGE SQL est accordé à PUBLIC , mais vous devez explicitement accorder USAGE ON LANGUAGE PLPYTHONU
à des utilisateurs ou des groupes spécifiques.De plus, vous devez être un super-utilisateur pour remplacer une UDF (fonction définie par l'utilisateur). |
Il n'est pas nécessaire d'accorder des autorisations explicites pour créer ou supprimer une UDF de n'importe quel type. Tout utilisateur disposant d'un rôle d'Éditeur de données BigQuery (c'est-à-dire qui comporte bigquery.routines.* parmi ses autorisations) peut créer ou supprimer des fonctions pour l'ensemble de données spécifié.BigQuery est également compatible avec la création de rôles personnalisés. Vous pouvez gérer ce comportement en utilisant Cloud IAM. |
Limites | Consultez les limites des fonctions définies par l'utilisateur pour Python. | Consultez les limites des fonctions définies par l'utilisateur. |
Instructions SQL de métadonnées et de transactions
Amazon Redshift | BigQuery |
---|---|
SELECT * FROM STL_ANALYZE WHERE name |
Non utilisé dans BigQuery. Vous n'avez pas besoin de collecter des statistiques afin d'améliorer les performances des requêtes. Pour obtenir des informations sur la distribution des données, vous pouvez utiliser des fonctions d'agrégation approximative. |
ANALYZE
[[ table_name[(column_name |
Non utilisé dans BigQuery. |
LOCK
TABLE table_name; |
Non utilisé dans BigQuery. |
BEGIN
TRANSACTION; SELECT ... |
BigQuery utilise l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence. |
EXPLAIN
... |
Non utilisé dans BigQuery. L'explication de plan de requête dans la console Google CLoud de BigQuery et la journalisation d'audit dans Cloud Monitoring sont des fonctionnalités similaires. |
SELECT * FROM SVV_TABLE_INFO WHERE |
SELECT * EXCEPT(is_typed) FROM Pour en savoir plus, consultez la page Présentation des vues INFORMATION_SCHEMA de BigQuery. |
VACUUM
[table_name] |
Non utilisé dans BigQuery. Les tables en cluster BigQuery sont automatiquement triées. |
Instructions SQL multi-instructions et multilignes
Amazon Redshift et BigQuery acceptent les transactions (sessions) et donc les instructions séparées par un point-virgule qui sont systématiquement exécutées ensemble. Pour plus d'informations, consultez la section Transactions multi-instructions.
Instructions SQL procédurales
Instruction CREATE PROCEDURE
Amazon Redshift | BigQuery |
---|---|
CREATE or
REPLACE PROCEDURE |
CREATE PROCEDURE si un nom est requis. Sinon, utilisez l'instruction sous le bloc BEGIN ou sur une seule ligne avec CREATE TEMP FUNCTION . |
CALL |
CALL |
Déclaration et attribution de variables
Amazon Redshift | BigQuery |
---|---|
DECLARE |
DECLARE Déclare une variable du type spécifié. |
SET |
SET Définit une variable comme ayant la valeur de l'expression fournie, ou définit plusieurs variables en même temps en fonction du résultat de plusieurs expressions. |
Gestionnaires de conditions d'erreur
Dans Amazon Redshift, une erreur rencontrée lors de l'exécution d'une procédure stockée interrompt le flux d'exécution, met fin à la transaction et applique un rollback de la transaction.
Ces résultats se produisent car les sous-transactions ne sont pas prises en charge. Dans une procédure stockée dans Amazon Redshift, la seule option handler_statement
prise en charge est RAISE
. Dans BigQuery, la gestion des erreurs est une fonctionnalité essentielle du flux de contrôle principal, semblable à ce que d'autres langages fournissent avec les blocs TRY ... CATCH
.
Amazon Redshift | BigQuery |
---|---|
BEGIN ...
EXCEPTION WHEN OTHERS THEN |
BEGIN ... EXCEPTION WHEN ERROR
THEN |
RAISE |
RAISE |
[ <<label>> ] [ DECLARE declarations ] |
BEGIN |
Déclarations et opérations de curseurs
Étant donné que BigQuery n'accepte pas les curseurs ni les sessions, il n'utilise pas les instructions suivantes :
DECLARE
cursor_name
CURSOR
[FOR] ...
PREPARE
plan_name [ (datatype [, ...] ) ] AS statement
OPEN
cursor_name FOR SELECT ...
FETCH
[ NEXT | ALL | {FORWARD [ count | ALL ] } ] FROM cursor_name
CLOSE
cursor_name;
Si vous utilisez le curseur pour renvoyer un ensemble de résultats, vous pouvez obtenir un comportement similaire en utilisant les tables temporaires dans BigQuery.
Instructions SQL dynamiques
La fonctionnalité de script de BigQuery est compatible avec les instructions SQL dynamiques telles que celles présentées dans le tableau suivant.
Amazon Redshift | BigQuery |
---|---|
EXECUTE |
EXECUTE IMMEDIATE |
Instructions de flux de contrôle
Amazon Redshift | BigQuery |
---|---|
IF..THEN..ELSIF..THEN..ELSE..END
IF |
IF condition |
name CURSOR
[ ( arguments ) ] FOR query |
Les curseurs ou les sessions ne sont pas utilisés dans BigQuery. |
[< |
LOOP |
WHILE
condition LOOP stmts END LOOP |
WHILE condition |
EXIT |
BREAK |
Garanties de cohérence et isolation de transaction
Amazon Redshift et BigQuery sont tous deux atomiques, c'est-à-dire conformes à la norme ACID au niveau de chaque mutation sur de nombreuses lignes.
Transactions
Par défaut, Amazon Redshift accepte l'isolation sérialisable pour les transactions. Amazon Redshift vous permet de spécifier l'un des quatre niveaux d'isolation standards des transactions SQL, mais traite tous les niveaux d'isolation comme sérialisables.
BigQuery est également compatible avec les transactions. BigQuery permet d'assurer un contrôle de simultanéité optimiste (le premier à effectuer un commit a la priorité) avec isolation d'instantané, où une requête lit les dernières données validées avant le démarrage de la requête. Cette approche garantit le même niveau de cohérence par ligne, par mutation et entre les lignes d'une même instruction LMD, tout en évitant les interblocages. Si plusieurs mises à jour LMD sont effectuées sur la même table, BigQuery bascule vers le contrôle de simultanéité pessimiste. Les jobs de chargement peuvent s'exécuter complètement indépendamment et ajouter des données aux tables.
Rollback
Si Amazon Redshift rencontre une erreur lors de l'exécution d'une procédure stockée, il annule toutes les modifications effectuées dans le cadre de la transaction. Vous pouvez également utiliser l'instruction de contrôle des transactions ROLLBACK
dans une procédure stockée pour supprimer toutes les modifications.
Dans BigQuery, vous pouvez utiliser l'instruction ROLLBACK TRANSACTION
.
Limites des bases de données
Vérifiez les derniers quotas et les dernières limites dans la documentation publique BigQuery. Les utilisateurs ayant un volume de requêtes important peuvent demander l'augmentation de nombreux quotas en contactant l'équipe d'assistance Cloud. Le tableau suivant présente une comparaison des limites des base de données Amazon Redshift et BigQuery.
Limite | Amazon Redshift | BigQuery |
---|---|---|
Tables dans chaque base de données pour les types de nœuds de cluster "large" et "xlarge" | 9 900 | Pas de restriction |
Tables de chaque base de données pour les types de nœuds de cluster 8x plus larges | 20 000 | Pas de restriction |
Bases de données définies par l'utilisateur que vous pouvez créer pour chaque cluster | 60 | Pas de restriction |
Taille maximale des lignes | 4 Mo | 100 Mo |