Si vous utilisez une base de données de séries chronologiques (timeseries db, ) comme stockage principal d'un site avec des statistiques, alors au lieu de résoudre le problème, vous pouvez avoir beaucoup de maux de tête. Je travaille sur un projet qui utilise une telle base de données, et parfois InfluxDB, dont nous parlerons, a présenté des surprises complètement inattendues.
Clause de non-responsabilité : Les problèmes répertoriés s'appliquent à InfluxDB version 1.7.4.
Pourquoi des séries chronologiques ?
Le projet consiste à suivre les transactions sur diverses blockchains et à afficher des statistiques. Plus précisément, nous examinons l'émission et la combustion de pièces stables (). Sur la base de ces transactions, vous devez créer des graphiques et afficher des tableaux récapitulatifs.
Lors de l'analyse des transactions, une idée est venue : utiliser la base de données de séries chronologiques InfluxDB comme stockage principal. Les transactions sont des points dans le temps et s’intègrent bien dans le modèle de série chronologique.
Les fonctions d'agrégation semblaient également très pratiques : elles sont idéales pour traiter des graphiques sur une longue période. L'utilisateur a besoin d'un graphique pour un an et la base de données contient un ensemble de données avec une période de cinq minutes. Cela n'a aucun sens de lui envoyer les cent mille points - à part un long traitement, ils ne tiendront même pas à l'écran. Vous pouvez écrire votre propre implémentation pour augmenter le délai ou utiliser les fonctions d'agrégation intégrées à Influx. Avec leur aide, vous pouvez regrouper les données par jour et envoyer les 365 points requis.
Il était un peu déroutant que de telles bases de données soient généralement utilisées dans le but de collecter des mesures. Surveillance des serveurs, des appareils IoT, tout d'où « découlent » des millions de points de la forme : [<temps> - <valeur métrique>]. Mais si la base de données fonctionne bien avec un flux de données important, pourquoi un petit volume devrait-il poser des problèmes ? Dans cet esprit, nous avons mis InfluxDB au travail.
Quoi d'autre est pratique dans InfluxDB
Outre les fonctions d'agrégation mentionnées, il existe une autre fonctionnalité intéressante : requêtes continues (). Il s'agit d'un planificateur intégré à la base de données qui peut traiter les données selon un calendrier. Par exemple, toutes les 24 heures, vous pouvez regrouper tous les records de la journée, calculer la moyenne et enregistrer un nouveau point dans un autre tableau sans écrire vos propres vélos.
il y a également un politiques de rétention () : configuration de la suppression des données après une certaine période. C'est utile lorsque, par exemple, vous devez stocker la charge du processeur pendant une semaine avec des mesures une fois par seconde, mais sur une distance de quelques mois, une telle précision n'est pas nécessaire. Dans une telle situation, vous pouvez faire ceci :
- créer une requête continue pour agréger les données dans une autre table ;
- pour le premier tableau, définissez une politique de suppression des métriques plus anciennes que la même semaine.
Et Influx réduira indépendamment la taille des données et supprimera les éléments inutiles.
À propos des données stockées
Peu de données sont stockées : environ 70 3000 transactions et un autre million de points contenant des informations sur le marché. Ajout de nouvelles entrées - pas plus de XNUMX XNUMX points par jour. Il existe également des métriques pour le site, mais il y a peu de données et, selon la politique de conservation, elles ne sont pas conservées plus d'un mois.
Problèmes
Au cours du développement et des tests ultérieurs du service, de plus en plus de problèmes critiques sont apparus dans le fonctionnement d'InfluxDB.
1. Suppression de données
Il existe une série de données avec les transactions :
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Résultat:
J'envoie une commande pour supprimer des données :
DELETE FROM transactions WHERE symbol=’USDT’Ensuite, je fais une demande pour recevoir les données déjà supprimées. Et au lieu d'une réponse vide, Influx renvoie une partie des données qui doivent être supprimées.
J'essaie de supprimer toute la table :
DROP MEASUREMENT transactionsJe vérifie la suppression de la table :
SHOW MEASUREMENTSJe ne vois pas le tableau dans la liste, mais une nouvelle requête de données renvoie toujours le même ensemble de transactions.
Le problème ne m'est apparu qu'une seule fois, le cas de suppression étant un cas isolé. Mais ce comportement de la base de données ne rentre clairement pas dans le cadre d'un fonctionnement « correct ». Plus tard, je l'ai trouvé ouvert sur github il y a presque un an sur ce sujet.
En conséquence, la suppression puis la restauration de l’intégralité de la base de données ont été utiles.
2. Nombres à virgule flottante
Les calculs mathématiques lors de l'utilisation des fonctions intégrées dans InfluxDB comportent des erreurs de précision. Ce n’est pas inhabituel, mais c’est désagréable.
Dans mon cas, les données ont une composante financière et je souhaite les traiter avec une grande précision. Pour cette raison, nous prévoyons d'abandonner les requêtes continues.
3. Les requêtes continues ne peuvent pas être adaptées aux différents fuseaux horaires
Le service dispose d'un tableau avec des statistiques de transactions quotidiennes. Pour chaque jour, vous devez regrouper toutes les transactions de cette journée. Mais la journée de chaque utilisateur commencera à une heure différente, et donc l’ensemble des transactions sera différent. Par UTC oui les quarts de travail pour lesquels vous devez regrouper des données.
Dans InfluxDB, lors du regroupement par heure, vous pouvez en outre spécifier un décalage, par exemple pour l'heure de Moscou (UTC+3) :
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Mais le résultat de la requête sera incorrect. Pour une raison quelconque, les données regroupées par jour commenceront jusqu'en 1677 (InfluxDB prend officiellement en charge une période à partir de cette année) :
Pour contourner ce problème, nous avons temporairement basculé le service sur UTC+0.
4. Performances
Il existe de nombreux benchmarks sur Internet qui comparent InfluxDB et d'autres bases de données. À première vue, ils ressemblaient à du matériel marketing, mais maintenant je pense qu’ils contiennent une part de vérité.
Je vais vous raconter mon cas.
Le service fournit une méthode API qui renvoie les statistiques du dernier jour. Lors de l'exécution des calculs, la méthode interroge la base de données trois fois avec les requêtes suivantes :
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCExplication:
- Lors de la première requête, nous obtenons les derniers points pour chaque pièce avec les données du marché. Huit points pour huit pièces dans mon cas.
- La deuxième demande obtient l'un des points les plus récents.
- Le troisième demande la liste des transactions des dernières XNUMX heures, il peut y en avoir plusieurs centaines.
Permettez-moi de préciser qu'InfluxDB crée automatiquement un index basé sur les balises et l'heure, ce qui accélère les requêtes. Dans la première demande symbole est une balise.
J'ai effectué un test de stress sur cette méthode API. Pour 25 RPS, le serveur a démontré une charge complète de six processeurs :
Dans le même temps, le processus NodeJs ne fournissait aucune charge.
La vitesse d'exécution s'est déjà dégradée de 7 à 10 RPS : si un client pouvait recevoir une réponse en 200 ms, alors 10 clients devaient attendre une seconde. 25 RPS est la limite à laquelle la stabilité a souffert ; 500 erreurs ont été renvoyées aux clients.
Avec de telles performances, il est impossible d'utiliser Influx dans notre projet. De plus : dans un projet où la surveillance doit être démontrée à de nombreux clients, des problèmes similaires peuvent apparaître et le serveur de métriques sera surchargé.
conclusion
La conclusion la plus importante de l’expérience acquise est qu’on ne peut pas intégrer une technologie inconnue dans un projet sans une analyse suffisante. Un simple examen des problèmes ouverts sur github pourrait fournir des informations permettant d'éviter de choisir InfluxDB comme magasin de données principal.
InfluxDB aurait dû convenir aux tâches de mon projet, mais comme la pratique l'a montré, cette base de données ne répond pas aux besoins et présente de nombreux bugs.
Vous pouvez déjà trouver la version 2.0.0-beta dans le référentiel du projet ; nous ne pouvons qu'espérer que la deuxième version apportera des améliorations significatives. En attendant, je vais aller étudier la documentation de TimescaleDB.
Source: habr.com