Mise à l'échelle d'Influxdb (noeud unique) à ~ 200 écritures par seconde

Question

Quel est le nombre maximal de points pouvant être écrits sur influxdb (noeud unique) par seconde? Est-il faisable d'étendre influxdb sans aller vers le cluster payant? Et devrais-je considérer elasticsearch au lieu d'influxdb pour les données de séries temporelles (~ 3000 octets/sec/utilisateur) si j'attends environ 60 utilisateurs simultanés?

Answer 1

Dépend du matériel.

Les facteurs limitants sont

• Cardinalité de la série dans la DB (série totale uniques)
• débit du disque WAL (cela pourrait être mis sur tmpfs si vous n'avez pas SSD)
• disque de données débit (utilisation SSD pour de meilleurs résultats)
• RAM (plus est mieux)
• CPU pour l'ingestion, l'indexation et requêtes

L'éloignement d'un seul nœud dépend en grande partie de ceux-ci et de la charge de travail.

Pour les charges de travail faibles en écriture, la CPU a généralement tendance à s'épuiser plus rapidement qu'auparavant, en supposant que les disques SSD sont utilisés et que les E/S disque ont été optimisées en conséquence.

Ensuite, la cardinalité est le facteur limitant le plus important. Schema design joue un rôle énorme, beaucoup plus grand que le nombre de nœuds. À partir de quelques tests que j'ai effectués, un seul nœud peut facilement évoluer vers ~ 70K séries par seconde, le processeur étant le facteur limitant. C'était sur une ancienne version, probablement plus élevée que maintenant. Encore une fois, dépend largement de la conception de données et de schémas.

Il est possible de le mettre à l'échelle sans cluster payant en ajoutant des nœuds séparés, mais pas si vous souhaitez conserver une vue homogène (source unique de toutes vos données). La mise à l'échelle verticale (plus de CPU, RAM) ne fonctionne que tant que la cardinalité reste cohérente, ce qui signifie plus de points de données pour environ le même nombre de séries.

InfluxDB suggère jusqu'à 250 Ko d'écriture/seconde avec 25 requêtes par seconde sur des requêtes uniques jusqu'à 1M sur un seul nœud. Voir hardware guidelines.

Pour la quantité de données que vous avez un seul noeud est plus que suffisant - la taille des données n'a pas d'importance, le nombre de séries le fait. Évitez les recherches élastiques pour les données de séries temporelles - il faut beaucoup plus d'infrastructure pour gérer la même quantité de données.