Une fois que vous avez sécurisé et configuré votre base de données, vous pouvez la connecter à Looker.
Sélectionnez Connexions dans la section Base de données du panneau Administration. Sur la page Connexions, cliquez sur le bouton Ajouter une connexion. Looker affiche la page Paramètres de connexion.
Pour en savoir plus sur l'application d'attributs utilisateur aux paramètres de connexion, consultez la section Connexions de la page de documentation sur les attributs utilisateur.
Cette page décrit les champs courants que Looker affiche sur la page Paramètres de connexion. Les champs exacts qui s'affichent sur la page Paramètres de connexion dépendent du paramètre de votre dialecte.
Cliquez ici pour consulter les liens vers les instructions spécifiques à chaque dialecte dans la documentation Looker.
- Actian Avalanche
- AlloyDB pour PostgreSQL
- Amazon Aurora PostgreSQL
- Amazon Athena
- Amazon Aurora MySQL
- Amazon RDS pour MySQL
- Amazon RDS pour PostgreSQL
- Amazon Redshift
- Apache Druid
- Apache Hive 2.3 et 3.1.2+
- Apache Spark 3 et versions ultérieures
- ClickHouse
- Cloudera Impala version 3.1 ou ultérieure
- Databricks
- DataVirtuality
- Dénodo
- Dremio
- Exasol
- Éclair
- Ancien SQL Google BigQuery
- Google BigQuery Standard SQL
- Google Cloud SQL pour MySQL
- Google Cloud SQL pour PostgreSQL
- Google Spanner
- Greenplum
- IBM DB2 sur AS400
- IBM DB2 sur LUW
- MariaDB
- Microsoft Azure Synapse Analytics
- Base de données Microsoft Azure SQL
- Microsoft Azure PostgreSQL
- Microsoft SQL Server (MSSQL)
- Connecteur MongoDB pour l'informatique décisionnelle
- MySQL
- Oracle
- Oracle ADWC
- PostgreSQL
- PrestoDB
- SAP HANA
- SingleStore (anciennement MemSQL)
- Snowflake
- Teradata
- Trino
- Vecteur
- Vertica
Une fois que vous avez saisi les paramètres de connexion à la base de données, vous pouvez sélectionner le bouton Test sur la page Paramètres de connexion pour tester la connexion et vous assurer qu'elle est correctement configurée. Cliquez sur Tester pour vérifier que la connexion est établie. Consultez la page de documentation Tester la connectivité de la base de données pour obtenir des informations de dépannage. Si Looker affiche Connexion autorisée, appuyez sur Se connecter pour créer la connexion. Votre connexion à la base de données est ensuite ajoutée à la liste de la page d'administration Connexions de Looker.
Paramètres généraux
Nom
Le nom de la connexion tel que vous souhaitez y faire référence. Vous aurez besoin de ce nom de connexion à la base de données pour l'utiliser dans le paramètre connection
de votre modèle LookML. Le nom de la connexion à la base de données est également utilisé pour identifier la connexion sur la page Connexions Administration de Looker. N'utilisez pas le nom d'un dossier pour ce paramètre. Cette valeur n'a pas besoin de correspondre à un élément de votre base de données. Name
est une étiquette qui identifie cette connexion dans l'UI Looker.
Champ d'application de la connexion
Indiquez si la connexion peut être utilisée avec tous les projets ou avec un seul projet.
Utilisez cette option avec les autorisations suivantes pour déléguer la gestion des connexions et la configuration du modèle:
Dialecte
Dialecte SQL correspondant à votre connexion. Il est important de choisir la valeur correcte afin que les options de connexion appropriées vous soient présentées et que Looker puisse traduire correctement votre LookML en SQL.
ID du projet de facturation
Pour les connexions Google BigQuery uniquement, l'ID du projet de facturation est l'ID du projet Google Cloud.
Hôte
Nom d'hôte de votre base de données que Looker doit utiliser pour se connecter à l'hôte de la base de données.
Si vous avez configuré un tunnel SSH vers votre base de données avec un analyste Looker, saisissez "localhost"
dans le champ Host (Hôte).
Port
Port de base de données que Looker doit utiliser pour se connecter à l'hôte de la base de données.
Si vous avez configuré un tunnel SSH vers votre base de données avec l'aide d'un analyste Looker, saisissez dans le champ Port le numéro de port qui redirige vers votre base de données, que votre analyste Looker aurait dû indiquer.
Base de données
Nom de la base de données de votre hôte. Par exemple, vous pouvez avoir le nom d'hôte my-instance.us-east-1.redshift.amazonaws.com
sur lequel se trouve une base de données appelée sales_info
. Vous devez saisir sales_info
dans ce champ. Si vous avez plusieurs bases de données sur le même hôte, vous devrez peut-être créer plusieurs connexions pour les utiliser (à l'exception de MySQL, dans lequel le mot base de données signifie quelque chose de légèrement différent de celui de la plupart des dialectes SQL).
Schéma
Le schéma par défaut que Looker utilise lorsqu'aucun schéma n'est indiqué. Cela s'applique lorsque vous utilisez SQL Runner, pendant la génération d'un projet LookML et lorsque vous interrogez des tables.
Authentification
Pour les connexions Google BigQuery, Snowflake, Trino et Databricks, sélectionnez le type d'authentification que Looker doit utiliser pour accéder à votre base de données:
- Pour les connexions Google BigQuery, vous avez la possibilité de configurer OAuth ou un compte de service que Looker utilisera pour s'authentifier auprès de votre base de données.
- Pour les connexions Snowflake, Trino et Databricks, vous pouvez configurer OAuth ou un compte de base de données que Looker utilisera pour s'authentifier auprès de votre base de données.
Lorsque vous utilisez OAuth, vos utilisateurs doivent se connecter à votre base de données pour émettre des requêtes depuis Looker. Pour en savoir plus sur la configuration d'OAuth lors d'une connexion à Looker, consultez les procédures de connexion Google BigQuery, Snowflake, Trino ou Databricks.
Nom d'utilisateur
Nom d'utilisateur d'un compte utilisateur de votre base de données que Looker peut utiliser pour se connecter à votre base de données.
Mot de passe
Mot de passe d'un compte utilisateur de votre base de données que Looker peut utiliser pour se connecter à votre base de données.
Paramètres facultatifs
Serveur SSH
L'option Serveur SSH n'est disponible que si l'instance est déployée sur l'infrastructure Kubernetes, et uniquement si la possibilité d'ajouter des informations de configuration de serveur SSH à votre instance Looker a été activée. Si cette option n'est pas activée sur votre instance Looker et que vous souhaitez l'activer, contactez un spécialiste des ventes Google Cloud ou ouvrez une demande d'assistance.
Le serveur SSH choisit automatiquement le port localhost pour vous et il n'est pas possible de spécifier le port localhost. Si vous devez créer une connexion SSH nécessitant la spécification d'un port localhost, ouvrez une demande d'assistance.
Pour vous connecter à votre base de données à l'aide d'un tunnel SSH, activez le bouton et sélectionnez une configuration de serveur SSH dans la liste déroulante.
Port local
Par défaut, Looker sélectionne automatiquement un port local disponible pour le tunnel SSH. Pour choisir manuellement un port local, sélectionnez Saisie manuelle et saisissez un numéro de port dans le champ Port local personnalisé. Assurez-vous que le port local est disponible sur votre instance.
Tables dérivées persistantes (PDT)
Activer les PDT
Activez l'option Activer les tables PDT pour activer les tables dérivées persistantes. Lorsque les tables PDT sont activées, la fenêtre Connexion affiche des champs PDT supplémentaires ainsi que la section Remplacements PDT. Looker affiche le bouton Activer les tables PDT uniquement si le dialecte de la base de données permet l'utilisation des tables PDT.
Remarques à propos des PDT :
- Les tables PDT ne sont pas compatibles avec les connexions Snowflake qui utilisent OAuth.
- La désactivation des tables PDT sur une connexion ne désactive pas les groupes de données associés à vos tables PDT. Même si vous désactivez les tables PDT, les groupes de données existants continuent d'exécuter leurs requêtes
sql_trigger
sur la base de données. Si vous souhaitez empêcher un groupe de données d'exécuter sa requêtesql_trigger
sur votre base de données, vous devez supprimer ou mettre en commentaire le paramètredatagroup
de votre projet LookML. Vous pouvez également mettre à jour le paramètre Datagroup and PDT Maintenance Schedule pour la connexion afin que Looker vérifie les tables PDT et les groupes de données très rarement, voire jamais. - Pour les connexions à Snowflake, Looker définit la valeur du paramètre
AUTOCOMMIT
surTRUE
(valeur par défaut de Snowflake).AUTOCOMMIT
est requis pour les commandes SQL que Looker exécute afin de gérer son système d'enregistrement de tables PDT.
Temp Database
Bien qu'il soit intitulé Temp Database (Base de données temporaire), saisissez le nom de la base de données ou le nom du schéma (selon votre dialecte SQL) que Looker doit utiliser pour créer des tables dérivées persistantes. Vous devez configurer cette base de données ou ce schéma à l'avance en utilisant les autorisations en écriture appropriées. Sur la page de documentation Instructions pour la configuration de la base de données, sélectionnez votre dialecte de base de données pour afficher les instructions relatives à ce dialecte.
Chaque connexion doit avoir sa propre base de données temporaire ou son propre schéma. Ils ne peuvent pas être partagés entre les connexions.
Nombre maximum de connexions de PDT builder
Le paramètre Nombre maximal de connexions au générateur de tables PDT vous permet de spécifier le nombre de compilations de tables simultanées que le régénérateur Looker peut lancer sur votre connexion à la base de données. Le paramètre Nombre maximal de connexions au générateur de tables PDT ne s'applique qu'aux types de tables pour lesquels le régénérateur Looker lance des recompilations:
- Les tables persistantes déclenchées (tables dérivées persistantes et tables agrégées qui utilisent la stratégie de persistance
datagroup_trigger
ousql_trigger_value
) - Tables persistantes qui utilisent la stratégie
persist_for
, mais uniquement lorsque la tablepersist_for
fait partie d'une cascade de tables dérivées où elle dépend d'une table qui utilise la stratégie de persistancedatagroup_trigger
ousql_trigger_value
. Dans ce cas, le régénérateur Looker reconstruira une tablepersist_for
, car celle-ci est nécessaire pour recréer une autre table dans la cascade. Sinon, le régénérateur ne lance pas de compilation pour les tablespersist_for
.
Le paramètre Nombre maximal de connexions au générateur de tables PDT est défini par défaut sur 1, mais peut être jusqu'à 10. Toutefois, la valeur ne peut pas être supérieure à celle définie dans le champ Nombre maximal de connexions par nœud ou dans le per-user-query-limit
défini dans les options de démarrage de Looker.
Vous devez configurer cette valeur attentivement. Si cette valeur est trop élevée, vous risquez de submerger votre base de données. Si cette valeur est faible, les tables PDT ou agrégées de grande taille peuvent retarder la création d'autres tables persistantes ou ralentir les autres requêtes sur la connexion. Les bases de données prenant en charge l'architecture mutualisée, telles que BigQuery, Snowflake et Redshift, peuvent être plus performantes pour gérer des compilations de requêtes parallèles.
En règle générale, si vous souhaitez augmenter le nombre maximal de connexions au générateur de tables PDT, nous vous recommandons de l'augmenter par incréments de 1. Si un comportement inattendu se produit, rétablissez la valeur par défaut (1). Sinon, si les performances de la requête ne sont pas affectées, vous pouvez augmenter progressivement la valeur d'une unité et vérifier les performances à chaque incrément avant d'augmenter davantage le paramètre.
Notez les points suivants à propos du paramètre Nombre maximal de connexions du générateur de tables PDT:
- Le paramètre Nombre maximal de connexions au générateur de tables PDT s'applique uniquement aux connexions requises pour la recréation des tables, et non aux connexions nécessaires aux vérifications des déclencheurs. Une vérification de déclenchement est une requête qui vérifie si la stratégie de persistance de la table est déclenchée. Étant donné que ces requêtes de vérification du déclencheur sont toujours exécutées de manière séquentielle, le paramètre Nombre maximal de connexions via le générateur de PDT persistantes ne s'applique pas.
- Dans une instance Looker en cluster, le régénérateur ne s'exécute que sur le nœud principal. Le paramètre Nombre maximal de connexions au générateur de tables PDT s'applique uniquement au nœud principal, et définit donc la limite pour l'ensemble du cluster.
- Le paramètre Nombre maximal de connexions au générateur de tables PDT ne s'applique pas aux types de tables suivants. Ces types de tables sont créés de manière consécutive :
- Tables persistantes via le paramètre
persist_for
(sauf si la table dépend de tables utilisant les stratégiesdatagroup_trigger
ousql_trigger_value
). - Tableaux en mode Développement.
- Tables recréées avec l'option Rebuild Derived Tables & Run (Recompiler les tables dérivées et exécuter les tables dérivées)
- Tables où l'une dépend d'une autre dans une cascade de dépendances Une table ne peut pas être créée en même temps qu'une table dont elle dépend. Par exemple, si
table_B
dépend detable_A
,table_A
doit terminer la recompilation pour quetable_B
puisse commencer à se recompiler.
- Tables persistantes via le paramètre
Calendrier de maintenance des groupes de données et des tables dérivées persistantes
Le régénérateur Looker vérifie les groupes de données et les tables persistantes (tables agrégées et tables dérivées persistantes) basées sur sql_trigger_value
. En fonction de ces vérifications, le régénérateur Looker régénère ou supprime les tables persistantes du schéma entièrement nouveau de votre base de données.
La valeur Planification de la maintenance des groupes de données et des tables PDT définit l'intervalle cron
pour le régénérateur Looker. Le régénérateur Looker lance un cycle pour vérifier les groupes de données et les tables persistantes sur l'intervalle cron
. Si un cycle de régénérateur Looker est toujours en cours à l'intervalle cron
suivant, celui-ci termine ce cycle, puis attend l'intervalle cron
suivant pour commencer le cycle suivant.
Le paramètre Planification de la maintenance des groupes de données et des tables PDT accepte une expression cron
. La valeur par défaut est */5 * * * *
, ce qui signifie que le cycle de régénérateur Looker commencera un cycle tous les cinq minutes, si le précédent cycle de régénérateur est terminé. Si le cycle précédent n'est pas terminé, le régénérateur Looker démarre cinq minutes après la fin de son cycle.
La valeur par défaut de cinq minutes est également l'intervalle le plus fréquent pris en charge pour la planification de maintenance des groupes de données et des tables PDT. Looker n'applique pas d'intervalle maximal pour la planification de maintenance des groupes de données et des tables PDT, ce qui signifie que vous pouvez prolonger l'intervalle entre les cycles de régénérateur Looker aussi longtemps que peut être spécifié par une expression cron
. N'oubliez pas que les cycles plus longs du régénérateur Looker peuvent nuire à la fraîcheur des données dans votre cache et dans vos tables persistantes.
Une fois que le régénérateur Looker a effectué toutes les vérifications et régénéré la table PDT dans un cycle, il attend que l'intervalle cron
suivant lance le cycle suivant. Si vous avez des compilations de tables PDT de longue durée, il peut s'écouler de longues périodes entre les cycles de régénérateur Looker. D'autres facteurs peuvent affecter le temps nécessaire à la régénération de vos tables, comme décrit dans la section Éléments importants à prendre en compte pour implémenter des tables persistantes de la page Tables dérivées dans Looker.
Si votre base de données n'est pas active 24h/24, 7j/7, vous pouvez limiter les vérifications aux moments où elle est opérationnelle. Voici quelques expressions cron
supplémentaires:
Expression cron |
Définition |
---|---|
*/5 8-17 * * MON-FRI |
Vérifier les groupes de données et les tables PDT toutes les 5 minutes pendant les heures de travail, du lundi au vendredi |
*/5 8-17 * * * |
Vérifier les groupes de données et les tables PDT toutes les 5 minutes pendant les heures de travail, au quotidien |
0 8-17 * * MON-FRI |
Vérifier les groupes de données et les tables PDT toutes les heures pendant les heures de travail, du lundi au vendredi |
1 3 * * * |
Vérifier les groupes de données et les tables PDT tous les jours à 3 h 01 |
Voici quelques points à noter lorsque vous créez une expression cron
:
- Looker utilise parse-cron v0.1.3, qui n'accepte pas
?
dans les expressionscron
. - L'expression
cron
utilise le fuseau horaire de l'application Looker pour déterminer quand les vérifications sont effectuées. - Si aucune table PDT n'est créée, rétablissez la valeur par défaut de la chaîne Cron (
*/5 * * * *
).
Vous trouverez ci-dessous des ressources pour vous aider à créer des chaînes cron
:
- https://crontab.guru : permet de modifier et de tester des chaînes
cron
. - http://www.crontab-generator.org : sélectionnez les paramètres d'heure, et le générateur crée la chaîne
cron
correspondante.
Relancer les générations de tables dérivées persistantes en échec
L'option Relancer les générations de tables PDT ayant échoué configure la manière dont le régénérateur Looker tente de régénérer les tables persistantes avec déclencheur qui ont échoué dans le cycle de régénérateur précédent. Le régénérateur Looker est le processus qui régénère les tables persistantes à déclenchement (PDT et tables agrégées) selon l'intervalle configuré dans le paramètre de connexion Planification de maintenance des groupes de données et des tables PDT. Lorsque l'option Relancer les générations de tables PDT ayant échoué est activée, le régénérateur Looker tente de régénérer une table PDT ayant échoué dans le cycle précédent, même si la condition de déclenchement de la table PDT n'est pas remplie. Lorsque ce paramètre est désactivé, le régénérateur Looker tente de régénérer une table PDT ayant échoué uniquement lorsque la condition de déclenchement de la table PDT est remplie. L'option Relancer les compilations de tables PDT ayant échoué est désactivée par défaut.
Consultez la page de documentation Tables dérivées dans Looker pour en savoir plus sur le régénérateur Looker.
Contrôle des tables dérivées persistantes via l'API
Le bouton Commande API PDT détermine si les appels d'API start_pdt_build
, check_pdt_build
et stop_pdt_build
peuvent être utilisés pour cette connexion. Lorsque l'option Contrôle des API PDT est désactivée, ces appels d'API échouent lorsqu'ils font référence à des tables PDT sur cette connexion. L'option Contrôle des API PDT est désactivée par défaut.
Remplacements pour les PDT
Si votre base de données prend en charge les tables dérivées persistantes et que vous avez activé l'option Activer les tables PDT dans les paramètres de connexion, Looker affiche la section Remplacements PDT. Dans la section PDT Overrides (Remplacements PTP), vous pouvez saisir des paramètres JDBC distincts (host, port, base de données, nom d'utilisateur, mot de passe, schéma, paramètres supplémentaires et instructions de connexion après connexion) spécifiques aux processus PDT. Cette possibilité est précieuse pour plusieurs raisons :
- En créant un utilisateur de base de données distinct pour les processus de table PDT, vous pouvez utiliser les tables PDT dans votre projet Looker, même si vous attribuez des attributs utilisateur aux identifiants de connexion à votre base de données ou si vous utilisez OAuth pour votre connexion à la base de données.
- Les processus PDT peuvent s'authentifier par l'intermédiaire d'un utilisateur de base de données distinct dont la priorité est plus élevée. La base de données peut ainsi placer les jobs PDT en priorité au détriment des requêtes de moindre importance des utilisateurs.
- L'accès en écriture peut être révoqué pour la connexion standard à la base de données Looker, et être octroyé seulement à un utilisateur spécifique que les processus PDT utiliseront pour s'authentifier. Il s'agit d'une meilleure stratégie de sécurité pour la plupart des organisations.
- Pour les bases de données telles que Snowflake, les processus de PDT peuvent être acheminés vers du matériel plus puissant qui n'est pas partagé avec le reste des utilisateurs de Looker. Les tables PDT peuvent ainsi être créées rapidement en évitant les coûts inhérents à l'exécution d'un matériel onéreux à temps plein.
Par exemple, la configuration suivante illustre une connexion dans laquelle les champs « username » et « password » sont définis avec des attributs utilisateur. Chaque utilisateur peut ainsi accéder à la base de données avec ses propres identifiants. La section Remplacements PTP crée un utilisateur distinct (pdt_user
) avec son propre mot de passe. Le compte pdt_user
sera utilisé pour tous les processus de PDT, avec des niveaux d'accès adaptés à la création et à la mise à jour des tables PDT.
Fuseau horaire
Fuseau horaire de la base de données
Le fuseau horaire dans lequel votre base de données stocke les informations temporelles. Looker doit connaître cette information afin de convertir les valeurs de date/heure pour les utilisateurs et ainsi simplifier la compréhension et l'utilisation des données temporelles. Pour en savoir plus, consultez la page de documentation Utiliser les paramètres de fuseau horaire.
Requête Fuseau horaire
L'option Interroger le fuseau horaire n'est visible que si vous avez désactivé User Specific Time Zones (Fuseaux horaires spécifiques à l'utilisateur).
Lorsque l'option User Specific Time Zones (Fuseau horaire spécifique à l'utilisateur) est désactivée, le Query Time Zone (Fuseau horaire de la requête) correspond au fuseau horaire qui s'affiche lorsque vos utilisateurs interrogent des données basées sur l'heure, et au fuseau horaire dans lequel Looker convertira ces données à partir du fuseau horaire de la base de données.
Pour en savoir plus, consultez la page de documentation Utiliser les paramètres de fuseau horaire.
Autres paramètres
Paramètres JDBC supplémentaires
Si nécessaire, vous pouvez inclure d'autres paramètres JDBC (Java Database Connectivity) dans vos requêtes.
Pour référencer un attribut utilisateur dans un paramètre JDBC, utilisez la syntaxe de création de modèles Liquid: _user_attributes['name_of_attribute']
. Exemple :
my_jdbc_param={{ _user_attributes['name_of_attribute'] }}
Max Connections per node
Ici, vous pouvez configurer le nombre maximal de connexions que Looker peut établir avec votre base de données. Dans la majorité des cas, vous configurez le nombre de requêtes simultanées que Looker peut exécuter sur votre base de données. Looker consacre également jusqu'à trois connexions à la suppression des requêtes. Si le pool de connexions est de taille très restreinte, Looker consacrera moins de connexions.
Vous devez configurer cette valeur attentivement. Si cette valeur est trop élevée, vous risquez de submerger votre base de données. Si cette valeur est trop faible, les requêtes devront partager une petite quantité de connexions. Chaque requête devant attendre le retour des autres requêtes précédemment exécutées, il se peut donc que de nombreuses requêtes semblent lentes aux utilisateurs.
La valeur par défaut (qui varie en fonction de votre dialecte SQL) constitue généralement un point de départ raisonnable. Pour ce qui est du nombre maximal de connexions qu'elles acceptent, la plupart des bases de données disposent également de leur propre configuration. Si la configuration de votre base de données limite les connexions, assurez-vous que la valeur Nombre maximal de connexions par nœud est inférieure ou égale à la limite de votre base de données.
Connection Pool Timeout
Si vos utilisateurs demandent plus de connexions que le paramètre Nombre maximal de connexions par nœud, les requêtes attendent que les autres aient terminé avant d'être exécutées. Le temps d'attente maximal d'une requête se configure à cet endroit. Le paramètre par défaut est de 120 secondes.
Vous devez configurer cette valeur attentivement. S'il est trop faible, les utilisateurs peuvent constater que leur requête est annulée, car il n'y a pas assez de temps pour terminer les requêtes des autres utilisateurs. S'il est trop élevé, un grand nombre de requêtes peut s'accumuler et entraîner un délai d'attente très long pour les utilisateurs. La valeur par défaut constitue généralement un point de départ raisonnable.
SSL
Choisissez si vous souhaitez, ou non, utiliser le chiffrement SSL pour protéger vos données pendant leur transition entre Looker et votre base de données. SSL n'est qu'une option parmi d'autres pour protéger vos données. D'autres options sécurisées sont décrites dans la page de documentation Activer l'accès sécurisé à la base de données.
Vérifier le protocole SSL
Choisissez si vous souhaitez demander une vérification du certificat SSL utilisé par la connexion. Si la validation est requise, l'autorité de certification SSL qui a signé le certificat SSL doit provenir de la liste des sources de confiance du client. Si l'AC n'est pas une source fiable, la connexion de base de données n'est pas établie.
Si cette case n'est pas cochée, le chiffrement SSL est toujours utilisé sur la connexion, mais la vérification de la connexion SSL n'est pas requise. Une connexion peut donc être établie lorsque l'autorité de certification ne figure pas sur la liste des sources de confiance du client.
Effectuer une mise en cache préalable de l'exécuteur SQL
Dans SQL Runner, toutes les informations de la table sont préchargées dès que vous sélectionnez une connexion et un schéma. Cela permet à SQL Runner d'afficher rapidement les colonnes de la table dès que vous cliquez sur un nom de table. Néanmoins, pour les connexions et les schémas comportant de nombreuses tables ou des tables très volumineuses, il se peut que vous ne souhaitiez pas que SQL Runner précharge l'ensemble des informations.
Si vous préférez que SQL Runner ne charge les informations d'une table que lorsqu'une table est sélectionnée, vous pouvez désélectionner l'option SQL Runner Precache (Précache pour l'exécuteur SQL) afin de désactiver le préchargement de SQL Runner pour la connexion.
Télécharger un schéma d'informations pour l'écriture SQL
Pour certaines fonctionnalités d'écriture SQL telles que la reconnaissance d'agrégats, Looker utilise le schéma d'informations de votre base de données afin d'optimiser l'écriture SQL. Si le schéma d'informations n'est pas mis en cache, Looker peut parfois être amené à bloquer l'écriture SQL dans la base de données pour pouvoir extraire le schéma d'informations. Pour les dialectes qui utilisent HDFS (Hadoop Distributed File System), la récupération du schéma d'informations peut prendre suffisamment de temps pour affecter significativement les performances de vos requêtes Looker. Si vous savez que votre schéma d'informations est lent, vous pouvez désactiver l'option Récupérer un schéma d'informations pour l'écriture SQL pour votre connexion. La désactivation de cette fonctionnalité empêche certaines optimisations SQL de Looker pour certaines d'entre elles. Vous devez donc activer l'option Extraire un schéma d'informations pour l'écriture SQL, sauf si vous savez que le schéma d'informations de votre connexion est particulièrement lent.
Estimation du coût
L'option Estimation des coûts ne s'applique qu'aux connexions de base de données suivantes:
- Snowflake
- Amazon Redshift
- Amazon Aurora
- PostgreSQL, Google Cloud SQL pour PostgreSQL et Microsoft Azure PostgreSQL
L'option Estimation des coûts active les fonctionnalités suivantes sur la connexion:
- Estimations des coûts pour les requêtes d'exploration
- Estimations des coûts pour les requêtes SQL Runner
- Estimation des économies de calcul pour les requêtes de notoriété agrégées
Pour en savoir plus, consultez la page de documentation Explorer les données dans Looker.
Database Connection Pooling
Pour les dialectes compatibles avec le regroupement de connexions de base de données, cette fonctionnalité permet à Looker d'utiliser des pools de connexions via le pilote JDBC. Le regroupement des connexions de base de données permet d'accélérer les performances des requêtes. Il n'est pas nécessaire de créer une nouvelle connexion à la base de données, mais vous pouvez utiliser une connexion existante du pool de connexions. La fonctionnalité de pooling de connexions garantit qu'une connexion est nettoyée après l'exécution d'une requête et qu'elle peut être réutilisée une fois l'exécution de la requête terminée. Pour en savoir plus, consultez la page de documentation Pooling des connexions de base de données.
Test de vos paramètres de connexion
Vous pouvez tester vos paramètres de connexion à partir de plusieurs endroits dans l'interface utilisateur de Looker:
- Sélectionnez le bouton Test en bas de la page Connections Settings (Paramètres de connexion).
- Sélectionnez le bouton Tester à côté de la connexion sur la page d'administration Connexions, comme décrit sur la page de documentation Connexions.
Une fois que vous avez saisi les paramètres de connexion, cliquez sur Tester pour vérifier que les informations sont correctes et que la base de données peut se connecter.
Si votre connexion ne réussit pas un ou plusieurs tests, voici quelques options de dépannage:
- Essayez certaines procédures de dépannage de la page de documentation Tester la connectivité de la base de données.
- Si vous exécutez Mongo 3.6 ou une version antérieure sur Atlas et que vous rencontrez un échec de liaison de communication, consultez la page de documentation du connecteur Mongo.
- Pour recevoir des messages indiquant une connexion réussie concernant le schéma et les tables PDT temporaires, vous devrez avoir activé cette fonctionnalité au moment du paramétrage de votre base de données Looker. Pour savoir comment procéder, consultez la page Instructions de configuration de la base de données.
Si vous rencontrez encore des difficultés, contactez le support Looker pour obtenir de l'aide.
Tester en tant qu'utilisateur
Si vous avez défini une ou plusieurs valeurs de paramètre de connexion sur un attribut utilisateur, l'option Tester en tant qu'utilisateur s'affiche. Sélectionnez un utilisateur, puis cliquez sur Tester pour vérifier que la base de données peut se connecter et exécuter des requêtes avec cet utilisateur.
Étapes suivantes
Une fois votre base de données connectée à Looker, vous pouvez configurer les options de connexion de vos utilisateurs.