Connexion
default.
Notez que nous utilisons le port natif par défaut pour nous connecter.
conn a déjà été créée et est disponible.
Exécution
Exec. Cela est utile pour les DDL et les instructions simples. Elle ne doit pas être utilisée pour des insertions volumineuses ni pour l’itération de requêtes.
Insertion par lot
Send(). Les lots sont conservés en mémoire jusqu’à l’exécution de Send.
Il est recommandé d’appeler Close sur le lot afin d’éviter les fuites de connexions. Cela peut se faire à l’aide du mot-clé defer après la préparation du lot. La connexion sera ainsi libérée si Send n’est jamais appelé. Notez que, si aucune ligne n’a été ajoutée, cela fera apparaître une insertion de 0 ligne dans le journal des requêtes.
Colonnes éphémères
Interroger des lignes
QueryRow, soit obtenir un curseur pour parcourir un jeu de résultats via Query. Alors que la première accepte une destination dans laquelle sérialiser les données, la seconde nécessite d’appeler Scan sur chaque ligne.
SELECT — par défaut, dans le cas d’un SELECT *, c’est l’ordre de déclaration des colonnes qui sera utilisé, comme illustré ci-dessus.
Comme pour l’insertion, la méthode Scan exige que les variables cibles soient d’un type approprié. Là encore, l’objectif est de rester flexible, avec conversion des types lorsque c’est possible, à condition qu’il n’y ait aucune perte de précision. Par exemple, l’exemple ci-dessus montre une colonne UUID lue dans une variable string. Pour la liste complète des types Go pris en charge pour chaque type de colonne, consultez conversion de type.
Enfin, notez qu’il est possible de passer un Context aux méthodes Query et QueryRow. Cela peut être utilisé pour définir des paramètres au niveau de la requête — voir Using Context pour plus de détails.
Insertion asynchrone
Insertion en colonnes
Utilisation des structs
Select avec sérialisation
Lecture d’une struct
ScanStruct permet de mapper une seule ligne d’une requête vers une struct.
Ajout d’une struct
AppendStruct permet d’ajouter une struct à un lot existant et de l’interpréter comme une ligne complète. Pour cela, les colonnes de la struct doivent correspondre à celles de la table, tant par leur nom que par leur type. Toutes les colonnes doivent avoir un champ de struct équivalent, mais certains champs de struct peuvent ne pas avoir de colonne correspondante dans la table. Ils seront alors simplement ignorés.
Liaison des paramètres
Exec, Query et QueryRow. Comme le montre l’exemple ci-dessous, elle est compatible avec les paramètres nommés, numérotés et positionnels. Vous trouverez des exemples ci-dessous.
Cas particuliers
[ ], utilisez ArraySet.
Si vous avez besoin de groupes/tuples, entourés de ( ), par exemple pour les utiliser avec des opérateurs IN, vous pouvez utiliser un GroupSet. Cela est particulièrement utile lorsque plusieurs groupes sont nécessaires, comme dans l’exemple ci-dessous.
Enfin, les champs DateTime64 nécessitent une précision afin de garantir que les paramètres sont correctement rendus. Cependant, le niveau de précision du champ est inconnu du client ; l’utilisateur doit donc le fournir. Pour simplifier cela, nous fournissons le paramètre DateNamed.
Utilisation du contexte
context.Background(), vous pouvez exploiter cette fonctionnalité pour transmettre des paramètres et des échéances, ainsi que pour annuler des requêtes.
Le passage d’un contexte créé avec withDeadline permet d’imposer des limites de temps d’exécution aux requêtes. Notez qu’il s’agit d’un instant absolu et que l’expiration ne fera que libérer la connexion et envoyer un signal d’annulation à ClickHouse. WithCancel peut également être utilisé pour annuler explicitement une requête.
Les fonctions utilitaires clickhouse.WithQueryID et clickhouse.WithQuotaKey permettent de spécifier un identifiant de requête et une clé de quota. Les identifiants de requête peuvent être utiles pour suivre les requêtes dans les logs et à des fins d’annulation. Une clé de quota peut être utilisée pour imposer des limites d’utilisation de ClickHouse en fonction d’une valeur de clé unique — voir Gestion des quotas pour plus de détails.
Vous pouvez également utiliser le contexte pour vous assurer qu’un paramètre n’est appliqué qu’à une requête spécifique, plutôt qu’à l’ensemble de la connexion, comme indiqué dans Paramètres de connexion.
Enfin, vous pouvez contrôler la taille du tampon de blocs via clickhouse.WithBlockSize. Cela remplace le paramètre au niveau de la connexion BlockBufferSize et contrôle le nombre maximal de blocs décodés et conservés en mémoire à tout moment. Des valeurs plus élevées peuvent offrir davantage de parallélisation, au prix d’une consommation mémoire plus importante.
Des exemples de ce qui précède sont présentés ci-dessous.
Informations Progress, profile et log
Analyse dynamique
Tables externes
ext.NewTable avant de la transmettre via le contexte.
OpenTelemetry
clickhouse.WithSpan pour associer un span à une requête via le contexte.
Limitation du transport HTTPBien que le serveur ClickHouse accepte les en-têtes HTTP standard
traceparent / tracestate, le transport HTTP de clickhouse-go ne les envoie pas actuellement — WithSpan n’a donc aucun effet en HTTP. Pour contourner ce problème, vous pouvez définir manuellement l’en-tête via HttpHeaders dans les options de connexion.