Cas d'utilisation: InfluxDB vs Prometheus
Suivant la page Web Prometheus , une des principales différences entre Prometheus et InfluxDB est le cas d'utilisation: alors que Prometheus stocke des séries chronologiques, seul InfluxDB est mieux adapté au stockage d'événements individuels. Étant donné que d'importants travaux ont été effectués sur le moteur de stockage d'InfluxDB, je me demande si cela est toujours vrai.
Je souhaite configurer une base de données de séries chronologiques et, mis à part le modèle Push/Push (et probablement une différence de performances), je ne vois aucune grande différence entre les deux projets. Quelqu'un peut-il expliquer la différence dans les cas d'utilisation?
InfluxDB PDG et développeur ici. La prochaine version d'InfluxDB (0.9.5) aura notre nouveau moteur de stockage. Avec ce moteur, nous pourrons stocker efficacement des données d'événement uniques ou des séries échantillonnées régulièrement. séries chronologiques irrégulières et régulières.
InfluxDB prend en charge les types de données int64, float64, bool et string en utilisant des schémas de compression différents pour chacun. Prométhée ne supporte que float64.
Pour la compression, la version 0.9.5 aura une compression compétitive avec Prometheus. Dans certains cas, nous obtiendrons de meilleurs résultats puisque nous modifions la compression des horodatages en fonction de ce que nous voyons. Le meilleur scénario est une série régulière échantillonnée à des intervalles précis. Par défaut, nous pouvons compresser les horodatages de 1k points en une heure de début de 8 octets, un delta (codé en zig-zag) et un compte (également en zig-zag).
Selon la forme des données, nous avons constaté <2,5 octets par point en moyenne après les compactions.
YMMV en fonction de vos horodatages, du type de données et de la forme des données. Les flotteurs aléatoires avec des horodatages à l'échelle de la nanoseconde avec de grands delt variables seraient les pires, par exemple.
La précision variable des horodatages est une autre fonctionnalité d’InfluxDB. Il peut représenter des échelles de seconde, milliseconde, microseconde ou nanoseconde. Prométhée est fixé à millisecondes.
Une autre différence est que les écritures dans InfluxDB sont durables après l'envoi d'une réponse de succès au client. Les mémoires tampons Prometheus écrivent en mémoire et les vident par défaut toutes les 5 minutes, ce qui ouvre une fenêtre de perte de données potentielle.
Nous espérons qu’une fois la version 0.9.5 d’InfluxDB publiée, les utilisateurs de Prometheus auront un bon choix en tant que stockage de métriques à long terme (en association avec Prometheus). Je suis à peu près sûr que le support est déjà dans Prometheus, mais jusqu'à la parution de la version 0.9.5, il risque d'être un peu cahoteux. Évidemment, nous devrons travailler ensemble et faire un tas de tests, mais c'est ce que j'espère.
Pour les métriques sur un serveur unique, je m'attendrais à ce que Prometheus obtienne de meilleures performances (bien que nous n’ayons ni testé ni programmé ici) en raison de leur modèle de données plus contraint et du fait qu’ils n’ajoutent pas d’écritures sur le disque avant d’écrire l’index. .
Le langage de requête entre les deux est très différent. Je ne suis pas sûr de savoir ce qu'ils soutiennent que nous ne connaissons pas encore ou inversement. Vous devez donc consulter les documents pour voir s'il existe quelque chose que vous pouvez faire et dont vous avez besoin. À plus long terme, notre objectif est de faire en sorte que la fonctionnalité de requête d'InfluxDB soit un sur-ensemble de solutions Graphite, RRD, Prometheus et autres solutions de séries chronologiques. Je dis super ensemble parce que nous voulons couvrir ces fonctions en plus de fonctions analytiques ultérieures. Il nous faudra évidemment du temps pour y arriver.
Enfin, InfluxDB a pour objectif à long terme de prendre en charge la haute disponibilité et l’évolutivité horizontale grâce au clustering. L'implémentation actuelle du clustering n'est pas encore complète et est uniquement en alpha. Cependant, nous y travaillons et c'est un objectif de conception fondamental du projet. Notre conception de regroupement est que les données sont finalement cohérentes.
À ma connaissance, l'approche de Prométhée consiste à utiliser la double écriture pour la HA (afin d'éviter toute garantie de cohérence éventuelle) et d'utiliser la fédération pour une évolutivité horizontale. Je ne sais pas comment fonctionnerait l'interrogation sur des serveurs fédérés.
Dans un cluster InfluxDB, vous pouvez interroger les limites du serveur sans copier toutes les données sur le réseau. En effet, chaque requête est décomposée en une sorte de travail MapReduce qui s'exécute à la volée.
Il y a probablement plus, mais c'est ce que je peux penser pour le moment.
Nous avons le message marketing des deux sociétés dans les autres réponses. Maintenant, ignorons-le et revenons au triste monde des séries de données temporelles.
Un peu d'histoire
InfluxDB et Prometheus ont été conçus pour remplacer les anciens outils de l’ère passée (RRDtool, graphite).
InfluxDB est une base de données de séries chronologiques. Prometheus est une sorte d'outil de collecte de métriques et d'alerte, avec un moteur de stockage spécialement conçu à cet effet. (Je ne suis pas sûr que vous puissiez [ou devriez] réutiliser le moteur de stockage pour autre chose)
Limites
Malheureusement, écrire une base de données est une entreprise très complexe. La seule façon pour ces deux outils de livrer quelque chose consiste à supprimer toutes les fonctionnalités essentielles relatives à la haute disponibilité et au clustering.
Pour parler franchement, est une seule application n'exécutant qu'un seul nœud.
Prometheus n'a pas pour objectif de prendre en charge le regroupement et la réplication, que ce soit . La méthode officielle de prise en charge du basculement consiste à " exécuter 2 nœuds et envoyer des données à chacun d'eux". Aie. (Notez que c’est sérieusement la SEULE façon existante, c’est écrit maintes fois dans la documentation officielle).
InfluxDB parle de clustering depuis des années ... jusqu'à ce qu'il soit officiellement abandonné en mars. Le clustering n'est plus sur la table pour InfluxDB . Oublie ça. Quand cela sera fait (à supposer que ce soit le cas), il ne sera disponible que dans l'édition Enterprise.
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
Dans les prochaines années, nous espérons avoir une base de données chronologique bien conçue qui traite tous les problèmes difficiles liés aux bases de données: réplication, basculement, sécurité des données, évolutivité, sauvegarde, etc.
Pour le moment, il n'y a pas de solution miracle.
Que faire
Évaluez le volume de données attendu.
100 métriques * 100 sources * 1 seconde => 10000 points de données par seconde => 864 méga-points de données par jour.
Le bon côté des bases de données chronologiques est qu’elles utilisent un format compact, qu’elles compressent bien, agrègent des points de données et nettoient les anciennes données. (De plus, ils comportent des fonctionnalités pertinentes pour les séries de données temporelles.)
En supposant qu'un point de donnée soit traité comme 4 octets, cela ne représente que quelques gigaoctets par jour. Heureusement pour nous, il existe des systèmes avec 10 cœurs et 10 disques TB facilement disponibles. Cela pourrait probablement fonctionner sur un seul nœud.
L'alternative consiste à utiliser une base de données NoSQL classique (Cassandra, ElasticSearch ou Riak), puis à manipuler les bits manquants dans l'application. Ces bases de données ne sont peut-être pas optimisées pour ce type de stockage (ou sont-elles? Les bases de données modernes sont si complexes et optimisées qu'il est impossible de savoir avec certitude, sauf si elles sont comparées).
Vous devez évaluer la capacité requise par votre application . Rédigez une preuve de concept avec ces différentes bases de données et mesures.
Voir si cela entre dans les limites d'InfluxDB. Si c'est le cas, c'est probablement le meilleur pari. Sinon, vous devrez créer votre propre solution en plus de quelque chose d'autre.
InfluxDB ne peut tout simplement pas contenir la charge de production (métriques) de 1 000 serveurs. L'ingestion de données pose de réels problèmes et finit par être bloquée/inutilisable. Nous avons essayé de l’utiliser pendant un moment, mais une fois que la quantité de données a atteint un niveau critique, elle ne peut plus être utilisée. Aucune mise à niveau de mémoire ou de processeur n'a aidé. Par conséquent, notre expérience est clairement de l'éviter, ce produit n'est pas mature et pose de sérieux problèmes de conception architecturale. Et je ne parle même pas du passage soudain au commercial par Influx.
Nous avons ensuite fait une recherche sur Prometheus et, même s’il avait besoin de réécrire les requêtes, il ingère maintenant 4 fois plus de métriques sans aucun problème par rapport à ce que nous avons essayé d’alimenter Influx. Et toute cette charge est gérée par un seul serveur Prometheus: elle est rapide, fiable et fiable. C’est notre expérience de gérer une énorme boutique Internet internationale avec une charge assez lourde.
L’implémentation actuelle de Prometheus par l’IIRC est conçue autour de l’ensemble des données s’adaptant sur un seul serveur. Si vous disposez de quantités de données gigantesques, cela n’est peut-être pas tout à fait dans Prométhée.