6 points par GN⁺ 2024-05-21 | 1 commentaires | Partager sur WhatsApp

Qu’est-ce qu’une donnée de série temporelle ?

  • Une donnée de série temporelle est un ensemble de données où chaque point de donnée est associé à un horodatage
  • Exemples : cours d’actions, données de température et de disponibilité renvoyées par des appareils et des capteurs, données de trafic d’un site web
  • Les traitements sur les séries temporelles incluent généralement des requêtes de filtrage temporel et des requêtes d’agrégation pour résumer les données

Travailler avec des séries temporelles avec PostgreSQL

  • PostgreSQL peut gérer tous types de traitements de données grâce à son extensibilité et à son écosystème d’outils
  • Tembo s’est donné pour objectif de permettre aux utilisateurs d’exploiter facilement l’écosystème PostgreSQL
  • La principale demande des clients était une stack capable de stocker et de traiter des données de séries temporelles

Les composants de pg_timeseries

  • Exigences pour stocker et interroger efficacement des données de séries temporelles :
    • gérer facilement les données de séries temporelles
    • traiter un débit élevé
    • répondre rapidement aux requêtes sur des plages temporelles
    • stocker efficacement de gros volumes de données
    • exécuter des fonctions d’analyse complexes
  • Fonctionnalités de base de PostgreSQL :
    • partitionnement natif, divers index, vues matérialisées, fonctions de fenêtre et d’analyse
  • Extensions supplémentaires :
    • pg_partman : gestion des partitions
    • pg_cron : planification des tâches
    • columnar : compression
    • pg_ivm : vues matérialisées incrémentales
    • pg_tier : déport longue durée des anciennes partitions

pg_timeseries : la manière la plus simple de gérer des données de séries temporelles dans PostgreSQL

  • pg_timeseries combine les capacités de plusieurs extensions pour fournir une interface unifiée
  • Pour démarrer, il faut une table partitionnée sur une colonne liée au temps
    CREATE TABLE measurements (  
      metric_name text,  
      metric_value numeric,  
      metric_time timestamptz NOT NULL  
    ) PARTITION BY RANGE (metric_time);  
    
    SELECT enable_ts_table('measurements');  
    
  • Inclut différentes vues pour fournir des informations importantes :
    SELECT table_id, table_size_bytes FROM ts_table_info;  
    SELECT * FROM ts_part_info;  
    
  • Il est possible de définir des politiques de compression et de suppression des partitions :
    SELECT set_ts_compression_policy('measurements', '90 days');  
    SELECT set_ts_retention_policy('measurements', '365 days');  
    
  • Fournit également des fonctions supplémentaires :
    SELECT  
      locf(avg(metric_value)) OVER (ORDER BY metric_time) avg_val,  
      last(metric_name, metric_value) highest,  
      metric_time  
    FROM date_bin_table(NULL::measurements, '1 hour', '[2024-05-09,2024-06-07]');  
    

Nous n’en sommes qu’au début

  • Construire une extension de séries temporelles pour PostgreSQL nécessite de nombreux composants
  • Le projet prévoit d’être développé publiquement avec la communauté
  • Feuille de route actuelle :
    • déporter les anciennes partitions vers du stockage à froid comme S3
    • fonctions approximatives pour des analyses efficaces
    • vues matérialisées incrémentales
    • rollup et suppression progressive des anciennes partitions
    • fonctions utilitaires d’analyse supplémentaires
  • La feuille de route complète se trouve dans le README GitHub, et les priorités fonctionnelles seront définies selon la demande des utilisateurs

L’avis de GN⁺

  • Importance des données de séries temporelles : l’importance des données de séries temporelles augmente dans des domaines variés comme l’IoT, la finance et l’analyse web. pg_timeseries fournit un outil permettant de gérer efficacement ces données.
  • Extensibilité de PostgreSQL : les extensions de PostgreSQL permettent de prendre en charge une grande variété de traitements de données. pg_timeseries unifie ces extensions pour améliorer la simplicité d’usage.
  • Collaboration avec la communauté : le projet étant développé en open source, il peut intégrer les retours de la communauté. Cela aide fortement à améliorer les fonctionnalités et à corriger les bugs.
  • Produits concurrents : par rapport à d’autres bases de données de séries temporelles comme TimescaleDB, l’un de ses avantages est de pouvoir être utilisé sans restriction de licence. En revanche, une évaluation comparative reste nécessaire sur les performances et les fonctionnalités.
  • Points à considérer avant adoption : avant d’adopter pg_timeseries, il faut tenir compte de la compatibilité avec la base de données existante, des performances et des coûts de maintenance. De plus, les volumes de données pouvant croître rapidement avec les séries temporelles, une gestion appropriée du stockage est nécessaire.

1 commentaires

 
GN⁺ 2024-05-21
Avis Hacker News

Résumé des commentaires de Hacker News

  • Vues matérialisées incrémentales

    • Les vues matérialisées incrémentales sont la fonctionnalité clé, car elles permettent de rester à jour à mesure que les données arrivent, sans dégradation des performances.
    • On se demande s’ils utiliseront une implémentation comme pg_ivm ou s’ils construiront leur propre solution.
    • Certains espèrent qu’un jour l’IVM sera intégré au cœur de PostgreSQL.
  • Comparaison avec TimescaleDB

    • En raison des restrictions de licence de TimescaleDB, il n’est pas possible d’utiliser des fonctionnalités comme la compression, les vues matérialisées incrémentales ou le stockage infini.
    • Il a été jugé que, sans ces fonctionnalités, il serait impossible de répondre aux besoins des clients en matière de données de séries temporelles, d’où la décision de construire directement une extension sous licence PostgreSQL.
    • Quelqu’un a déjà utilisé la version gratuite de TimescaleDB pour sharder une base contenant 500 millions d’observations. Cela a bien fonctionné, sans gros problème.
    • Des benchmarks et des comparaisons seraient appréciés. Le projet sera suivi de près.
  • Tables append-only

    • Il est temps que PostgreSQL et d’autres bases de données ajoutent des tables append-only natives.
    • Ce n’est pas une base de données de séries temporelles en soi, mais cela pourrait aider sur le plan de la logique et de l’approche en matière de standardisation.
  • Évolution des bases de données de séries temporelles

    • Les bases de données de séries temporelles évoluent actuellement dans les directions suivantes :
      • convergence vers le stockage en colonnes et des formats ouverts comme Parquet et Arrow : InfluxDB 3.0, QuestDB
      • ajout de fonctionnalités de séries temporelles au-dessus de PostgreSQL : Timescale, pg_timeseries
      • plateformes d’observabilité centrées sur l’écosystème Prometheus : Grafana, Victoria Metrics, Chronosphere
  • Nécessité du stockage en colonnes

    • La plupart des requêtes sur les séries temporelles sont des requêtes d’agrégation.
    • Pour cela, il vaut mieux exploiter ou construire un excellent moteur de stockage en colonnes.
    • Certains se demandent pourquoi PostgreSQL ne dispose pas d’un équivalent à ClickHouse.
  • Liens utiles

    • Merci d’avoir permis de découvrir Trunk et pgt.dev.
  • Entrées de logs de load balancer

    • On se demande si cette extension serait utile pour traiter des entrées de logs de load balancer (statut, corps de réponse, en-têtes, etc.).
    • Un stockage en base de données colonnaire semblerait plus efficace qu’une base classique orientée lignes.
    • Les entrées de logs de load balancer peuvent être considérées comme similaires à des événements analytiques.
  • Innovation open source

    • PostgreSQL a toujours été open source et s’est appuyé sur des bibliothèques open source très permissives.
    • Il a existé diverses extensions propriétaires ou source-available, de la réplication à la prise en charge des séries temporelles.
    • Désormais, ces extensions propriétaires sont remises en cause par des alternatives open source appropriées.
  • Licence PostgreSQL

    • Utiliser la licence PostgreSQL est une bonne décision.
  • Design du site et UI de l’application

    • Le design du site est réussi et facile à lire.
    • L’UI de l’application a aussi l’air excellente sur les captures de démonstration. Certains seraient prêts à l’essayer.