Guide de traduction SQL d'IBM Netezza
L'entreposage de données d'IBM Netezza est conçu pour fonctionner avec la syntaxe SQL propre à Netezza. Le langage SQL de Netezza est basé sur Postgres 7.2. Les scripts SQL écrits pour Netezza ne peuvent pas être utilisés dans un entrepôt de données BigQuery sans être modifiés, car les dialectes SQL varient.
Ce document décrit les similitudes et les différences de syntaxe SQL entre Netezza et BigQuery dans les domaines suivants :
- Types de données
- Éléments de langage SQL
- Syntaxe des requêtes
- Langage de manipulation de données (LMD)
- Langage de définition de données (LDD)
- Procédures stockées
- Fonctions
Vous pouvez également utiliser 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. Le langage SQL/NZPLSQL d'IBM Netezza est compatible avec les deux outils en version bêta.
Types de données
Netezza | BigQuery | Remarques |
---|---|---|
INTEGER/INT/INT4 |
INT64 |
|
SMALLINT/INT2 |
INT64 |
|
BYTEINT/INT1 |
INT64 |
|
BIGINT/INT8 |
INT64 |
|
DECIMAL
|
NUMERIC
|
Le type de données DECIMAL dans Netezza est un alias du type de données NUMERIC . |
NUMERIC
|
NUMERIC
INT64 |
|
NUMERIC(p,s)
|
NUMERIC
|
Le type NUMERIC dans BigQuery n'applique pas de limites de chiffres ou d'échelles personnalisées (contraintes) comme Netezza. BigQuery a fixé 9 chiffres après la virgule, tandis que Netezza permet une configuration personnalisée. Dans Netezza, la précision p peut aller de 1 à 38, et s peut aller de 0 à la précision. |
FLOAT(p) |
FLOAT64 |
|
REAL/FLOAT(6) |
FLOAT64 |
|
DOUBLE PRECISION/FLOAT(14) |
FLOAT64 |
|
CHAR/CHARACTER
|
STRING
|
Le type STRING dans BigQuery est de longueur variable et ne nécessite pas de définir manuellement un nombre maximal de caractères comme l'exigent les CHARACTER et VARCHAR de Netezza. La valeur par défaut de n dans CHAR(n) est 1. La taille maximale de la chaîne de caractères est de 64 000. |
VARCHAR
|
STRING
|
Le type STRING dans BigQuery est de longueur variable et ne nécessite pas de définir manuellement un nombre maximal de caractères comme l'exigent les CHARACTER et VARCHAR de Netezza. La taille maximale de la chaîne de caractères est de 64 000. |
NCHAR
|
STRING
|
Dans BigQuery, le type STRING est stocké sous la forme d'un Unicode encodé UTF-8 de longueur variable. La longueur ne doit pas dépasser 16 000 caractères. |
NVARCHAR
|
STRING
|
Dans BigQuery, le type STRING est stocké sous la forme d'un Unicode encodé UTF-8 de longueur variable.
La longueur ne doit pas dépasser 16 000 caractères. |
VARBINARY |
BYTES |
|
ST_GEOMETRY |
GEOGRAPHY |
|
BOOLEAN/BOOL
|
BOOL
|
Dans BigQuery, le type BOOL n'accepte que TRUE/FALSE , contrairement au type BOOL dans Netezza, qui peut accepter des valeurs diverses telles que 0/1 , yes/no , true/false,
on/off . |
DATE |
DATE |
|
TIME |
TIME |
|
TIMETZ/TIME WITH TIME ZONE
|
TIME
|
Netezza stocke le type de données TIME au format UTC et vous permet de transmettre un décalage par rapport à l'heure UTC à l'aide de la syntaxe WITH TIME
ZONE . Le type de données TIME de BigQuery représente une heure indépendante de toute date ou de tout fuseau horaire. |
TIMESTAMP
|
DATETIME
|
Le type TIMESTAMP de Netezza n'inclut pas de fuseau horaire, tout comme le type DATETIME de BigQuery. |
ARRAY
|
Il n'y a pas de type de données "tableau" dans Netezza. À la place, le type de tableau est stocké dans un champ varchar. |
Mise en forme des types d'horodatage et de date
Pour en savoir plus sur le formatage du type de date utilisé par Netezza SQL, consultez la documentation sur les modèles de modèles de date et heure Netezza. Pour en savoir plus sur les fonctions de date et d'heure, consultez la documentation sur les fonctions de date/heure de Netezza.
Lorsque vous convertissez des éléments de mise en forme de type de date de Netezza vers GoogleSQL, vous devez être particulièrement attentif aux différences de fuseau horaire entre TIMESTAMP
et DATETIME
, comme résumé dans le tableau suivant :
Netezza | BigQuery |
---|---|
CURRENT_TIMESTAMP CURRENT_TIME Les informations TIME de Netezza peuvent contenir des informations de fuseau horaire différentes, définies à l'aide de la syntaxe WITH TIME ZONE .
|
Si possible, utilisez la fonction CURRENT_TIMESTAMP , qui est correctement mise en forme. Toutefois, le format de sortie n'affiche pas toujours le fuseau horaire UTC (en interne, BigQuery n'a pas de fuseau horaire).
L'objet DATETIME de l'outil de ligne de commande bq, et la console Google Cloud est formaté à l'aide d'un séparateur T conformément à la norme RFC 3339. Toutefois, dans Python et Java JDBC, un espace est utilisé comme séparateur.
Utilisez la fonction FORMAT_DATETIME explicite pour définir correctement le format de la date.
Sinon, un casting explicite est créé dans une chaîne, par exemple :CAST(CURRENT_DATETIME() AS STRING) (Renvoie également un séparateur d'espace). |
CURRENT_DATE |
CURRENT_DATE |
CURRENT_DATE-3
|
BigQuery n'est pas compatible avec les opérations arithmétiques sur les données.
À la place, utilisez la fonction DATE_ADD . |
Instruction SELECT
En général, l'instruction SELECT
Netezza est compatible avec BigQuery. Le tableau suivant contient la liste des exceptions :
Netezza | BigQuery |
---|---|
Une instruction SELECT sans clause FROM |
Compatibilité avec les cas particuliers, tels que les suivants :
|
SELECT (subquery) AS flag, CASE WHEN flag = 1 THEN ... |
Dans BigQuery, les colonnes ne peuvent pas faire référence à la sortie d'autres colonnes définies dans la même requête. Vous devez dupliquer la logique ou la déplacer dans une requête imbriquée.
Option 1 SELECT (subquery) AS flag, CASE WHEN (subquery) = 1 THEN ... Option 2 SELECT q.*, CASE WHEN flag = 1 THEN ... FROM ( SELECT (subquery) AS flag, ... ) AS q |
Opérateurs de comparaison
Netezza | BigQuery | Description |
---|---|---|
exp = exp2 |
exp = exp2 |
Égal à |
exp <= exp2 |
exp <= exp2 |
Inférieur ou égal à |
exp < exp2 |
exp < exp2 |
Inférieur à |
exp <> exp2 exp != exp2 |
exp <> exp2 exp != exp2 |
Not Equal (Non égal à) |
exp >= exp2
|
exp >= exp2
|
Supérieur ou égal à |
exp > exp2 |
exp > exp2 |
Supérieur à |
Fonctions SQL intégrées
Netezza | BigQuery | Description |
---|---|---|
CURRENT_DATE
|
CURRENT_DATE
|
Obtenir la date actuelle (année, mois et jour). |
CURRENT_TIME
|
CURRENT_TIME
|
Obtenir l'heure actuelle avec une fraction. |
CURRENT_TIMESTAMP
|
CURRENT_TIMESTAMP
|
Obtenir la date et l'heure système actuelles, à la seconde près la plus proche |
NOW
|
CURRENT_TIMESTAMP
|
Obtenir la date et l'heure système actuelles, à la seconde près la plus proche |
COALESCE(exp, 0)
|
COALESCE(exp, 0)
|
Remplacer NULL par zéro. |
NVL(exp, 0)
|
IFNULL(exp, 0)
|
Remplacer NULL par zéro. |
EXTRACT(DOY FROM
timestamp_expression)
|
EXTRACT(DAYOFYEAR FROM
timestamp_expression)
|
Renvoyer le nombre de jours depuis le début de l'année. |
ADD_MONTHS(date_expr,
num_expr) |
DATE_ADD(date,
INTERVAL k MONTH) |
Ajouter des mois à une date |
DURATION_ADD(date,
k) |
DATE_ADD(date,
INTERVAL k DAY) |
Effectuer une ajout sur les dates. |
DURATION_SUBTRACT(date,
k) |
DATE_SUB(date,
INTERVAL k DAY) |
Effectuer des soustractions aux dates. |
str1 || str2 |
CONCAT(str1,
str2) |
Concaténer les chaînes. |
Fonctions
Cette section compare les fonctions Netezza et BigQuery.
Fonctions d'agrégation
Fonctions analytiques
Fonctions de date et heure
Fonctions de chaîne
Fonctions mathématiques
Netezza | BigQuery |
---|---|
ABS |
ABS |
ACOS |
ACOS |
ACOSH |
|
ASIN |
ASIN |
ASINH |
|
ATAN |
ATAN |
ATAN2 |
ATAN2 |
ATANH |
|
CEIL DCEIL |
CEIL
|
CEILING |
|
COS |
COS |
COSH |
|
COT |
COT |
DEGREES |
|
DIV |
|
EXP |
EXP |
FLOOR DFLOOR |
FLOOR
|
GREATEST |
GREATEST |
IEEE_DIVIDE |
|
IS_INF |
|
IS_NAN |
|
LEAST |
LEAST |
LN |
LN |
LOG |
LOG |
LOG10 |
|
MOD |
MOD |
NULLIF (expr, 0) |
|
PI |
ACOS (-1) |
POW FPOW |
POWER POW |
RADIANS |
|
RANDOM |
RAND |
ROUND |
ROUND |
SAFE_DIVIDE |
|
SETSEED |
|
SIGN |
SIGN |
SIN |
SIN |
SINH |
|
SQRT NUMERIC_SQRT |
SQRT
|
TAN |
TAN |
TANH |
|
TRUNC |
TRUNC |
IFNULL (expr, 0) |
Syntaxe LMD
Cette section compare la syntaxe LMD de Netezza et de BigQuery.
Instruction INSERT
Netezza | BigQuery |
---|---|
INSERT INTO table VALUES (...); |
INSERT INTO table (...) VALUES (...); Netezza propose un mot clé DEFAULT et d'autres contraintes pour les colonnes. Dans BigQuery, l'omission des noms de colonnes dans l'instruction INSERT n'est valide que si toutes les colonnes sont indiquées. |
INSERT INTO table (...) VALUES (...); INSERT INTO table (...) VALUES (...); |
INSERT INTO table VALUES (), (); BigQuery impose des quotas LMD qui limitent le nombre d'instructions LMD que vous pouvez exécuter quotidiennement. Pour utiliser au mieux votre quota, envisagez les approches suivantes :
|
Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Netezza. Notez également que BigQuery n'offre pas de contraintes autres que NOT
NULL
.
Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la page Garanties de cohérence et isolation de transaction.
Instruction UPDATE
Dans Netezza, la clause WHERE
est facultative, mais dans BigQuery, elle est obligatoire.
Netezza | BigQuery |
---|---|
UPDATE tbl SET tbl.col1=val1; |
Non compatible sans la clause WHERE .
Utilisez une clause WHERE true pour mettre à jour toutes les lignes. |
UPDATE A SET y = B.y, z = B.z + 1 FROM B WHERE A.x = B.x AND A.y IS NULL; |
UPDATE A SET y = B.y, z = B.z + 1 FROM B WHERE A.x = B.x AND A.y IS NULL; |
UPDATE A alias SET x = x + 1 WHERE f(x) IN (0, 1) |
UPDATE A SET x = x + 1 WHERE f(x) IN (0, 1); |
UPDATE A SET z = B.z FROM B WHERE A.x = B.x AND A.y = B.y |
UPDATE A SET z = B.z FROM B WHERE A.x = B.x AND A.y = B.y; |
Pour obtenir des exemples, consultez Exemples de UPDATE
.
En raison des quotas LMD, nous vous recommandons d'utiliser des instructions MERGE
plus volumineuses plutôt que plusieurs instructions UPDATE
et INSERT
uniques. Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Netezza.
Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la page Garanties de cohérence et isolation de transaction.
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. L'instruction TRUNCATE
a le même effet que l'instruction DELETE
, mais elle est beaucoup plus rapide que l'instruction DELETE
pour les grandes tables. L'instruction TRUNCATE
est compatible avec Netezza, mais pas avec BigQuery. Toutefois, vous pouvez utiliser des instructions DELETE
dans Netezza et BigQuery.
Dans BigQuery, l'instruction DELETE
doit comporter une clause WHERE
.
Dans Netezza, la clause WHERE
est facultative. Si la clause WHERE
n'est pas spécifiée, toutes les lignes de la table Netezza sont supprimées.
Netezza | BigQuery | Description |
---|---|---|
BEGIN; LOCK TABLE A IN EXCLUSIVE MODE; DELETE FROM A; INSERT INTO A SELECT * FROM B; COMMIT; |
Le remplacement du contenu d'une table par un résultat de requête équivaut à une transaction. Pour ce faire, vous pouvez utiliser une opération de query ou une copie (cp ). bq query \ bq cp \ |
Remplacez le contenu d'une table par les résultats d'une requête. |
DELETE FROM database.table |
DELETE FROM table WHERE TRUE; |
Dans Netezza, lorsqu'une instruction de suppression est exécutée, les lignes ne sont pas supprimées physiquement, mais seulement marquées pour suppression. L'exécution des commandes GROOM TABLE ou nzreclaim supprime par la suite les lignes marquées pour suppression et récupère l'espace disque correspondant.
|
GROOM
TABLE |
Netezza utilise la commande GROOM TABLE pour récupérer de l'espace disque en supprimant les lignes marquées pour suppression. |
Instruction MERGE
Une instruction MERGE
doit correspondre à une ligne source au maximum pour chaque ligne cible. Les scripts LMD dans BigQuery présentent une sémantique de cohérence légèrement différente de celle des instructions équivalentes dans Netezza. Pour obtenir une présentation de l'isolation d'instantané et de la gestion des sessions et des transactions, consultez la page Garanties de cohérence et isolation de transaction.
Pour obtenir des exemples, consultez les exemples BigQuery MERGE
et les exemples Netezza MERGE
.
Syntaxe LDD
Cette section compare la syntaxe LDD de Netezza et de BigQuery.
Instruction CREATE TABLE
Netezza | BigQuery | Description |
---|---|---|
TEMP TEMPORARY
|
Grâce à la compatibilité LDD de BigQuery, vous pouvez créer une table à partir des résultats d'une requête et spécifier son expiration au moment de sa création. Par exemple, pour trois jours :CREATE TABLE
'fh-bigquery.public_dump.vtemp' OPTIONS (expiration_timestamp=TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 3 DAY)) |
Créez des tables temporaires pour une session. |
ZONE MAPS
|
Non compatible. | Recherche rapide de la condition WHERE . |
DISTRIBUTE ON
|
PARTITION BY
|
Partitionnement
Il ne s'agit pas d'une traduction directe. DISTRIBUTE ON partage les données entre les nœuds, généralement avec une clé unique pour une distribution uniforme, tandis que PARTITION BY répartit les données en segments. |
ORGANIZE ON
|
CLUSTER BY
|
Netezza et BigQuery acceptent jusqu'à quatre clés pour le clustering. Les tables de base en cluster Netezza (CBT) offrent une priorité égale à chacune des colonnes de clustering. BigQuery donne la priorité à la première colonne sur laquelle la table est regroupée, suivie de la deuxième colonne, et ainsi de suite. |
ROW SECURITY |
Authorized View |
Sécurité au niveau des lignes |
CONSTRAINT |
Non compatible | Vérifier les contraintes |
Instruction DROP
Netezza | BigQuery | Description |
---|---|---|
DROP TABLE |
DROP TABLE |
|
DROP DATABASE |
DROP DATABASE |
|
DROP VIEW |
DROP VIEW |
Attributs et options de colonne
Netezza | BigQuery | Description |
---|---|---|
NULL NOT NULL
|
NULLABLE REQUIRED
|
Indique si la colonne peut contenir des valeurs NULL . |
REFERENCES
|
Non compatible | Spécifiez la contrainte de colonne. |
UNIQUE
|
Non compatible | Chaque valeur de la colonne doit être unique. |
DEFAULT
|
Non compatible | Valeur par défaut pour toutes les valeurs de la colonne. |
Tables temporaires
Netezza accepte les tables TEMPORARY
qui existent pendant la durée d'une session.
Pour créer une table temporaire dans BigQuery, procédez comme suit :
- Créez un ensemble de données ayant une durée de vie courte (par exemple, 12 heures).
Créez la table temporaire dans l'ensemble de données, avec le préfixe de nom de table
temp
. Par exemple, pour créer une table qui expire dans une heure, procédez comme suit :CREATE TABLE temp.name (col1, col2, ...) OPTIONS(expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR));
Commencez à lire et à écrire dans la table temporaire.
Vous pouvez également supprimer les doublons indépendamment afin de détecter les erreurs dans les systèmes en aval.
Notez que BigQuery n'est pas compatible avec les colonnes DEFAULT
et IDENTITY
(séquences).
Instructions SQL procédurales
Netezza utilise le langage de script NZPLSQL pour travailler avec des procédures stockées. NZPLSQL est basé sur le langage PL/pgSQL de Postgres. Cette section explique comment convertir les instructions SQL procédurales utilisées dans des procédures stockées, des fonctions et des déclencheurs de Netezza en BigQuery.
Instruction CREATE PROCEDURE
Netezza et BigQuery sont tous les deux compatibles avec la création de procédures stockées à l'aide de l'instruction CREATE PROCEDURE
. Pour en savoir plus, consultez la page Utiliser des procédures SQL stockées.
Déclaration et attribution de variables
Netezza | BigQuery | Description |
---|---|---|
DECLARE var
datatype(len) [DEFAULT
value]; |
DECLARE
|
Déclarez une variable. |
SET var = value; |
SET |
Attribuez une valeur à la variable. |
Gestionnaires d'exceptions
Netezza accepte les gestionnaires d'exceptions qui peuvent être déclenchés pour certaines conditions d'erreur. BigQuery n'accepte pas les gestionnaires de conditions.
Netezza | BigQuery | Description |
---|---|---|
EXCEPTION
|
Non compatible | Déclarez le gestionnaire d'exceptions SQL pour les erreurs générales. |
Instructions SQL dynamiques
Netezza accepte les requêtes SQL dynamiques dans les procédures stockées. BigQuery n'accepte pas les instructions SQL dynamiques.
Netezza | BigQuery | Description |
---|---|---|
EXECUTE IMMEDIATE sql_str; |
EXECUTE IMMEDIATE sql_str; |
Exécuter du code SQL dynamique. |
Instructions de flux de contrôle
Netezza | BigQuery | Description |
---|---|---|
IF THEN ELSE STATEMENT IF conditionTHEN ... ELSE ... END IF; |
IF conditionTHEN ... ELSE ... END IF;
|
Exécuter de manière conditionnelle |
Contrôle itératifFOR var AS SELECT ... DO stmts END FOR; FOR var AS cur CURSOR FOR SELECT ... DO stmts END FOR; |
Non compatible | Itérer sur une collection de lignes |
Contrôle itératifLOOP stmts END LOOP; |
LOOP sql_statement_list END LOOP; |
Bloc de boucles d'instructions |
EXIT WHEN |
BREAK |
Quitter une procédure |
WHILE *condition* LOOP
|
WHILE conditionDO ... END WHILE |
Exécuter une boucle d'instructions jusqu'à ce qu'une condition while échoue. |
Autres instructions et éléments de langage procédural
Netezza | BigQuery | Description |
---|---|---|
CALL proc(param,...) |
Non compatible | Exécuter une procédure |
EXEC proc(param,...) |
Non compatible | Exécuter une procédure |
EXECUTE proc(param,...) |
Non compatible | Exécuter une procédure |
Instructions SQL multi-instructions et multilignes
Teradata 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.
Autres instructions SQL
Netezza | BigQuery | Description |
---|---|---|
GENERATE
STATISTICS
|
Générer des statistiques pour toutes les tables de la base de données actuelle | |
GENERATE
STATISTICS ON
table_name |
Générer des statistiques pour une table spécifique | |
GENERATE
STATISTICS ON
table_name(col1,col4)
|
Utilisez des fonctions statistiques telles que MIN, MAX, AVG, , etc., ou l'UI ou encore l'API Cloud Data Loss Prevention. |
Générer des statistiques pour des colonnes spécifiques d'une table |
GENERATE
STATISTICS ON
table_name |
APPROX_COUNT_DISTINCT(col) |
Affichez le nombre de valeurs uniques pour les colonnes. |
INSERT INTO
table_name |
INSERT INTO
table_name |
Insérer une ligne |
LOCK TABLE
table_name FOR
EXCLUSIVE; |
Non compatible | Verrouiller la ligne |
SET SESSION
CHARACTERISTICS AS
TRANSACTION ISOLATION
LEVEL ...
|
BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence et isolation de transaction. | Définir le niveau d'isolation de la transaction |
BEGIN TRANSACTION END TRANSACTION COMMIT |
BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence et isolation de transaction. | Définir la limite de transaction pour les requêtes multi-instructions |
EXPLAIN ...
|
Non compatible Fonctionnalités similaires dans le plan de requête et la chronologie | Afficher le plan de requête pour une instruction SELECT
|
Métadonnées Consultations utilisateur Consultations système |
SELECT * EXCEPT(is_typed) FROM mydataset.INFORMATION_SCHEMA.TABLES; BigQuery Schéma d'informations |
Interroger des objets dans la base de données |
Garanties de cohérence et isolation de transaction
Netezza et BigQuery sont tous deux atomiques, c'est-à-dire conformes à la norme ACID au niveau de chaque mutation sur de nombreuses lignes. Par exemple, une opération MERGE
est complètement atomique, même avec plusieurs valeurs insérées.
Transactions
Netezza accepte automatiquement les quatre modes d'isolation de transaction ANSI SQL.
Toutefois, quel que soit le mode spécifié, seul le mode SERIALIZABLE
est utilisé, ce qui fournit le niveau de cohérence le plus élevé possible. Ce mode permet également d'éviter les lectures non répétables, fantômes et non valides entre les transactions simultanées.
Netezza n'utilise pas de verrouillage classique pour assurer la cohérence. Au lieu de cela, il utilise le contrôle de dépendance de sérialisation, une forme de contrôle de simultanéité positive, pour restaurer automatiquement la dernière transaction lorsque deux transactions tentent de modifier les mêmes données.
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
Netezza est compatible avec l'instruction ROLLBACK
pour annuler la transaction en cours et effectuer un rollback de toutes les modifications effectuées dans la transaction.
Dans BigQuery, vous pouvez utiliser l'instruction ROLLBACK TRANSACTION
.
Limites des bases de données
Limite | Netezza | BigQuery |
---|---|---|
Tables par base de données | 32 000 | Pas de restriction |
Colonnes par table | 1600 | 10000 |
Taille maximale des lignes | 64 Ko | 100 Mo |
Longueur des noms de colonnes et de tables | 128 octets | 16 384 caractères Unicode |
Nombre de lignes par table | Illimité | Illimité |
Longueur maximale des requêtes SQL | 1 Mo (longueur maximale des requêtes non résolues en SQL standard) 12 Mo (longueur maximale des requêtes résolues en ancien SQ et en SQL standard) Flux : 10 Mo (taille maximale des requêtes HTTP) 10 000 (nombre maximal de lignes par requête) |
|
Taille maximale des requêtes et des réponses | 10 Mo (requête) et 10 Go (réponse) ou virtuellement illimitée si vous utilisez la pagination ou l'API Cloud Storage | |
Nombre maximal de sessions simultanées | 63 transactions en lecture/écriture simultanées. 2 000 connexions simultanées au serveur. | 100 requêtes simultanées (ce nombre peut être augmenté avec une réservation d'emplacement), 300 requêtes API simultanées par utilisateur |
Étapes suivantes
- Obtenez des instructions détaillées sur la migration d'IBM Netezza vers BigQuery.