Présentation des transferts de données Microsoft SQL Server
Vous pouvez charger des données de Microsoft SQL Server dans BigQuery à l'aide du Service de transfert de données BigQuery pour Microsoft SQL Server. Le connecteur est compatible avec les instances Microsoft SQL Server hébergées dans votre environnement sur site, Cloud SQL et d'autres fournisseurs de cloud public tels qu'Amazon Web Services (AWS) et Microsoft Azure. Ce document présente les options d'ingestion de données pour votre transfert Microsoft SQL Server, ainsi que des informations sur le mappage des types de données et la tarification.
Pour savoir comment planifier un transfert Microsoft SQL Server, consultez Charger des données Microsoft SQL Server dans BigQuery.
Options d'ingestion de données
Les sections suivantes fournissent des informations sur les options d'ingestion de données lorsque vous configurez un transfert de données Microsoft SQL Server.
Configuration TLS
Le connecteur Microsoft SQL Server est compatible avec la configuration de la sécurité au niveau du transport (TLS) pour chiffrer vos transferts de données vers BigQuery. Le connecteur Microsoft SQL Server prend en charge les configurations TLS suivantes :
Mode Chiffrer les données, et valider la CA et le nom d'hôte. Ce mode effectue une validation complète du serveur à l'aide du protocole TLS sur TCPS. Il chiffre toutes les données en transit et vérifie que le certificat du serveur de base de données est signé par une autorité de certification (CA) de confiance. Ce mode vérifie également que le nom d'hôte auquel vous vous connectez correspond exactement au nom commun (CN) ou à un autre nom de l'objet (SAN) sur le certificat du serveur. Ce mode empêche les pirates d'utiliser un certificat valide pour un autre domaine afin d'usurper l'identité de votre serveur de base de données.
Si votre nom d'hôte ne correspond pas au CN ou au SAN du certificat, la connexion échoue. Vous devez configurer une résolution DNS pour qu'elle corresponde au certificat ou utiliser un autre mode de sécurité. Utilisez ce mode pour l'option la plus sécurisée afin d'éviter les attaques de l'intercepteur.
Mode Chiffrer les données, et valider uniquement la CA. Ce mode chiffre toutes les données à l'aide du protocole TLS sur TCPS et vérifie que le certificat du serveur est signé par une CA à laquelle le client fait confiance. Toutefois, ce mode ne valide pas le nom d'hôte du serveur. Ce mode se connecte tant que le certificat est valide et émis par une CA de confiance, que le nom d'hôte du certificat corresponde ou non à celui auquel vous vous connectez.
Utilisez ce mode si vous souhaitez vous assurer que vous vous connectez à un serveur dont le certificat est signé par une CA de confiance, mais que le nom d'hôte n'est pas vérifiable ou que vous n'avez pas le contrôle sur la configuration du nom d'hôte.
Mode Chiffrement uniquement. Ce mode chiffre toutes les données transférées entre le client et le serveur. Il n'effectue aucune validation de certificat ni de nom d'hôte.
Ce mode offre un certain niveau de sécurité en protégeant les données en transit, mais il peut être vulnérable aux attaques de l'intercepteur.
Utilisez ce mode si vous devez vous assurer que toutes les données sont chiffrées, mais que vous ne pouvez pas ou ne voulez pas vérifier l'identité du serveur. Nous vous recommandons d'utiliser ce mode lorsque vous travaillez avec des VPC privés.
Mode Aucun chiffrement ni aucune validation. Ce mode ne chiffre aucune donnée et n'effectue aucune validation de certificat ni de nom d'hôte. Toutes les données sont envoyées en texte brut.
Nous vous déconseillons d'utiliser ce mode dans un environnement où des données sensibles sont traitées. Nous vous recommandons de l'utiliser uniquement à des fins de test sur un réseau isolé où la sécurité n'est pas un problème.
Certificat de serveur fiable (PEM)
Si vous utilisez le mode Chiffrer les données, et valider la CA et le nom d'hôte ou le mode Chiffrer les données, et valider la CA, vous pouvez également fournir un ou plusieurs certificats encodés au format PEM. Ces certificats sont requis dans certains cas où le service de transfert de données BigQuery doit vérifier l'identité de votre serveur de base de données lors de la connexion TLS :
- Si vous utilisez un certificat signé par une CA privée au sein de votre organisation ou un certificat autosigné, vous devez fournir la chaîne de certificats complète ou le certificat autosigné unique. Cela est obligatoire pour les certificats émis par les CA internes des services de fournisseurs de cloud gérés, tels qu'Amazon Relational Database Service (RDS).
- Si le certificat de votre serveur de base de données est signé par une CA publique (par exemple, Let's Encrypt, DigiCert ou GlobalSign), vous n'avez pas besoin de fournir de certificat. Les certificats racines de ces CA publiques sont préinstallés et approuvés par le service de transfert de données BigQuery.
Vous pouvez spécifier des certificats encodés au format PEM dans le champ Certificat PEM fiable de la configuration de transfert, en respectant les exigences suivantes :
- Le certificat doit être une chaîne de certificats valide encodée au format PEM.
- Le certificat doit être entièrement correct. Tout certificat manquant dans la chaîne ou tout contenu incorrect entraîne l'échec de la connexion TLS.
- Pour un seul certificat, vous pouvez fournir un certificat autosigné unique à partir du serveur de base de données.
- Pour une chaîne de certificats complète émise par une CA privée, vous devez fournir la chaîne de confiance complète. Cela inclut le certificat du serveur de base de données, ainsi que tous les certificats CA intermédiaires et racines.
Transferts complets ou incrémentiels
Vous pouvez spécifier comment les données sont chargées dans BigQuery en sélectionnant la préférence d'écriture Complète ou Incrémentielle dans la configuration du transfert lorsque vous configurez un transfert Microsoft SQL Server. Les transferts incrémentiels sont compatibles avec la version preview.
Vous pouvez configurer un transfert de données complet pour transférer toutes les données de vos ensembles de données Microsoft SQL Server à chaque transfert de données.Vous pouvez également configurer un transfert de données incrémentiel (version preview) pour ne transférer que les données qui ont été modifiées depuis le dernier transfert de données, au lieu de charger l’ensemble de données à chaque transfert de données. Si vous sélectionnez Incrémentiel pour votre transfert de données, vous devez spécifier les modes d'écriture Ajouter ou Faire un upsert pour définir comment les données sont écrites dans BigQuery lors d'un transfert de données incrémentiel. Les sections suivantes décrivent les modes d'écriture disponibles.
Mode d'écriture "Ajouter"
Le mode d'écriture "Ajouter" n'insère que de nouvelles lignes dans votre table de destination. Cette option ajoute strictement les données transférées sans vérifier les enregistrements existants. Ce mode peut donc entraîner une duplication des données dans la table de destination.
Lorsque vous sélectionnez le mode "Ajouter", vous devez sélectionner une colonne de filigrane. Une colonne de filigrane est requise pour que le connecteur Microsoft SQL Server puisse suivre les modifications apportées à la table source.
Pour les transferts Microsoft SQL Server, nous vous recommandons de sélectionner une colonne qui n'est mise à jour que lorsque l'enregistrement a été créé et qui ne changera pas lors des mises à jour ultérieures, par exemple la colonneCREATED_AT.
Mode d'écriture "Faire un upsert"
Le mode d'écriture "Faire un upsert" met à jour une ligne ou en insère une nouvelle dans votre table de destination en vérifiant une clé primaire. Vous pouvez spécifier une clé primaire pour permettre au connecteur Microsoft SQL Server de déterminer les modifications nécessaires pour que votre table de destination soit à jour par rapport à votre table source. Si la clé primaire spécifiée est présente dans la table BigQuery de destination lors d'un transfert de données, le connecteur Microsoft SQL Server met à jour cette ligne avec les nouvelles données de la table source. Si une clé primaire n'est pas présente lors d'un transfert de données, le connecteur Microsoft SQL Server insère une nouvelle ligne.
Lorsque vous sélectionnez le mode "Faire un upsert", vous devez sélectionner une colonne de filigrane et une clé primaire :
- Une colonne de filigrane est requise pour que le connecteur Microsoft SQL Server puisse suivre les modifications apportées à la table source.
- Sélectionnez une colonne de filigrane qui se met à jour chaque fois qu'une ligne est modifiée. Nous vous recommandons d'utiliser des colonnes semblables aux colonnes
UPDATED_ATouLAST_MODIFIED.
- Sélectionnez une colonne de filigrane qui se met à jour chaque fois qu'une ligne est modifiée. Nous vous recommandons d'utiliser des colonnes semblables aux colonnes
La clé primaire peut être une ou plusieurs colonnes de votre table qui sont requises pour que le connecteur Microsoft SQL Server puisse déterminer s'il doit insérer ou mettre à jour une ligne.
Sélectionnez des colonnes contenant des valeurs non nulles uniques dans toutes les lignes de la table. Nous vous recommandons d'utiliser des colonnes qui incluent des identifiants générés par le système, des codes de référence uniques (par exemple, des ID à incrémentation automatique) ou des ID de séquence immuables basés sur le temps.
Pour éviter toute perte ou corruption de données, les colonnes de clé primaire que vous sélectionnez doivent avoir des valeurs uniques. Si vous avez des doutes sur l'unicité de la colonne de clé primaire que vous avez choisie, nous vous recommandons d'utiliser le mode d'écriture "Ajouter" à la place.
Comportement d'ingestion incrémentielle
Lorsque vous apportez des modifications au schéma de table dans votre source de données, les transferts de données incrémentiels à partir de ces tables sont reflétés dans BigQuery de la manière suivante :
| Modifications apportées à la source de données | Comportement d'ingestion incrémentielle |
|---|---|
| Ajout d'une colonne | Une nouvelle colonne est ajoutée à la table BigQuery de destination. Tous les enregistrements précédents de cette colonne auront des valeurs nulles. |
| Suppression d'une colonne | La colonne supprimée reste dans la table BigQuery de destination. Les nouvelles entrées de cette colonne supprimée sont remplies avec des valeurs nulles. |
| Modification du type de données dans une colonne | Le connecteur n'est compatible qu'avec
les conversions de types de données compatibles avec l'LDD ALTER COLUMN.
Toute autre conversion de type de données entraîne l'échec du transfert de données.
Si vous rencontrez des problèmes, nous vous recommandons de créer une configuration de transfert. |
| Renommage d'une colonne | La colonne d'origine reste telle quelle dans la table BigQuery de destination, tandis qu'une nouvelle colonne est ajoutée à la table de destination avec le nom mis à jour. |
Mappage des types de données
Le tableau suivant mappe les types de données Microsoft SQL Server aux types de données BigQuery correspondants :
| Type de données Microsoft SQL Server | Type de données BigQuery | Type de données BigQuery mis à jour |
|---|---|---|
tinyint |
INTEGER |
|
smallint |
INTEGER |
|
int |
INTEGER |
|
bigint |
BIGNUMERIC |
|
bit |
BOOLEAN |
|
decimal |
BIGNUMERIC |
|
numeric |
NUMERIC |
|
money |
BIGNUMERIC |
|
smallmoney |
BIGNUMERIC |
|
float |
FLOAT |
|
real |
FLOAT |
|
date |
DATE |
|
time |
TIME |
|
datetime2 |
TIMESTAMP |
DATETIME |
datetimeoffset |
TIMESTAMP |
|
datetime |
TIMESTAMP |
DATETIME |
smalldatetime |
TIMESTAMP |
DATETIME |
char |
STRING |
|
varchar |
STRING |
|
text |
STRING |
|
nchar |
STRING |
|
nvarchar |
STRING |
|
ntext |
STRING |
|
binary |
BYTES |
|
varbinary |
BYTES |
|
image |
BYTES |
|
geography |
STRING |
|
geometry |
STRING |
|
hierarchyid |
BYTES |
|
rowversion |
BYTES |
|
sql_variant |
BYTES |
|
uniqueidentifier |
STRING |
|
xml |
STRING |
|
json |
STRING |
|
vector |
STRING |
Les types de données json et vector ne sont compatibles qu'avec Azure.
Le type de données JSON est compatible avec les bases de données SQL Azure et les instances gérées SQL Azure configurées avec la stratégie de mise à jour "Toujours à jour". Le type de données JSON n'est pas compatible avec les instances gérées SQL Azure configurées avec la stratégie de mise à jour Microsoft SQL Server 2022.
Microsoft SQL Server stocke JSON en tant que NVARCHAR(MAX), et non en tant que type JSON. Nous vous recommandons d'utiliser CHECK (ISJSON(json_col) = 1) pour la validation et JSON_VALUE() pour l'interrogation.
Microsoft SQL Server n'est pas compatible avec les vecteurs pour le type de données vector. Nous vous recommandons de stocker les vecteurs en tant que tableaux JSON dans NVARCHAR(MAX) et d'utiliser JSON_VALUE() pour l'extraction, avec des calculs FLOAT manuels pour la similarité.
Tarifs
Le transfert de données Microsoft SQL Server vers BigQuery est sans frais pendant la version preview de cette fonctionnalité.
Étape suivante
- Découvrez comment configurer un transfert Microsoft SQL Server.
- Découvrez comment utiliser le service de transfert de données BigQuery.