Une conception de table optimale est le fondement des performances de requêtage et de stockage dans LindormTSDB. Avant d'écrire la moindre requête SQL, analysez vos modèles de requêtes et les caractéristiques de votre source de données : les décisions prises lors de la création du schéma sont difficiles à inverser par la suite.
Cette rubrique utilise les données de surveillance de la qualité de l'air (AQM) comme exemple fil conducteur pour illustrer chaque décision de conception.
Présentation du modèle de données
Chaque enregistrement d'une table de séries temporelles LindormTSDB se compose de quatre éléments :
| Composant | Description |
|---|---|
| Table | Un ensemble de données de séries temporelles de même type. Correspond à une mesure, par exemple aqm pour tous les relevés de qualité de l'air. |
| Tag | Un attribut identifiant l'objet surveillé, stocké sous forme de paire clé-valeur. Par défaut, LindormTSDB indexe chaque paire clé-valeur de tag, ce qui permet un filtrage rapide des séries temporelles. Également appelés labels ou dimensions dans certains systèmes. |
| Timestamp | L'instant auquel l'enregistrement a été généré. |
| Field | Une valeur mesurée. Un enregistrement peut contenir plusieurs champs. LindormTSDB n'indexe pas les champs. |
Le diagramme suivant illustre la relation entre ces composants en utilisant les données AQM :
Déterminer les colonnes devant être des tags
Il s'agit de la décision de schéma la plus critique. Une erreur entraîne une croissance illimitée de l'index des séries temporelles, ce qui dégrade les performances en écriture comme en lecture.
Les tags servent à l'identification ; les champs servent aux mesures.
Définissez une colonne comme tag lorsqu'elle identifie la source ou le contexte des données : ville, ID d'appareil, région, hôte.
Définissez une colonne comme field lorsqu'elle stocke une valeur mesurée évoluant dans le temps : température, utilisation du CPU, concentration de PM2.5.
Éviter les tags à forte volatilité
N'utilisez pas comme tags des attributs dont les valeurs changent fréquemment, tels que les ID de processus ou les attributs liés au temps, même si leur type de données est STRING. Chaque combinaison unique de clé-valeur de tag crée une nouvelle entrée de série temporelle dans l'index. Les attributs à forte volatilité génèrent un grand nombre de séries temporelles distinctes, provoquant une expansion rapide de l'index. Cela ralentit les requêtes reposant sur des recherches basées sur les tags.
Définissez plutôt les attributs à forte volatilité comme des champs.
Créer la table
Nommez la table d'après la mesure qu'elle représente. Utilisez l'instruction CREATE TABLE avec le mot-clé TAG pour marquer les colonnes de tags. Le mot-clé TAG est une extension SQL de LindormTSDB : seules les colonnes déclarées avec TAG peuvent servir de clés primaires.
L'exemple suivant crée une table AQM avec trois colonnes de tags et quatre colonnes de champs :
CREATE TABLE aqm (
city VARCHAR TAG,
district VARCHAR TAG,
id VARCHAR TAG,
time TIMESTAMP,
pm2_5 DOUBLE,
pm10 DOUBLE,
so2 DOUBLE,
no2 DOUBLE,
PRIMARY KEY (id) -- Remove this line for single-node Lindorm instances, which do not support primary keys.
);Après la création de la table, insérez des enregistrements avec INSERT INTO :
INSERT INTO aqm (city, district, id, time, pm2_5, pm10, so2, no2)
VALUES ('hangzhou', 'yuhang', 'HY00001', '2019-04-18 10:00:00', 31.0, 66.0, 10.0, 43.0);
INSERT INTO aqm (city, district, id, time, pm2_5, pm10, so2, no2)
VALUES ('hangzhou', 'yuhang', 'HY00001', '2019-04-18 10:01:00', 31.2, 66.0, 10.5, 43.1);Pour insérer plusieurs enregistrements en une seule instruction :
INSERT INTO aqm (city, district, id, time, pm2_5, pm10, so2, no2)
VALUES
('hangzhou', 'yuhang', 'HY00001', '2019-04-18 10:02:00', 31.3, 66.0, 10.0, 42.9),
('hangzhou', 'yuhang', 'HY00001', '2019-04-18 10:03:00', 31.2, 66.4, 10.3, 43.0);Choisir une clé primaire
LindormTSDB utilise la clé primaire pour partitionner les données et optimiser les requêtes. Les requêtes incluant la clé primaire dans la clause WHERE s'exécutent plus rapidement.
Les tables de séries temporelles diffèrent des tables de bases de données relationnelles. La colonne de clé primaire ne doit pas nécessairement contenir des valeurs uniques. La colonne de clé primaire doit être tagguée (déclarée avec le mot-clé TAG).
Les instances Lindorm à nœud unique ne prennent pas en charge les clés primaires.
Utilisez l'identifiant unique de la source de données comme clé primaire :
| Scénario | Clé primaire recommandée |
|---|---|
| IoT (Internet of Things) / IIoT (Industrial Internet of Things) | ID d'appareil |
| IoV (Internet of Vehicles) | Identifiant unique du véhicule |
| Surveillance d'applications | ID d'application ou host:port |
Dans l'exemple AQM, id identifie de manière unique chaque station de surveillance. Si la plupart des requêtes filtrent par ID de station, utilisez id comme clé primaire :
PRIMARY KEY (id)Choisir les types de données
Colonnes de tags
Les colonnes de tags doivent être de type VARCHAR. Ce type de données ne peut pas être modifié après la création de la table.
Colonnes d'horodatage
LindormTSDB stocke les horodatages en interne sous forme de valeurs BIGINT au format UNIX epoch dans LindormDFS, ce qui optimise la compression des horodatages. Lors de la création de la table, choisissez le type de colonne en fonction de la manière dont votre application gère les horodatages :
| Type | À utiliser lorsque |
|---|---|
TIMESTAMP |
Votre application utilise des chaînes de date et d'heure lisibles et vous souhaitez que la base de données gère la conversion automatiquement. |
BIGINT |
Votre application travaille directement avec des valeurs UNIX epoch, ou vous effectuez des calculs arithmétiques sur les horodatages (par exemple, pour calculer des durées). |
Colonnes de champs
Les colonnes de champs prennent en charge tous les types de données. Évitez VARCHAR pour les colonnes de champs : sa compression est inefficace et il ralentit les requêtes par rapport aux types numériques.
Pour la liste complète des types de données pris en charge, consultez Data types.