La mise à l'échelle des bases de données PostgreSQL est devenue moins chère : le stockage hiérarchisé de Timescale arrive en disponibilité générale

Des produits comme Amazon RDS pour PostgreSQL conviennent aux petits déploiements, mais la mise à l'échelle de PostgreSQL est une autre histoire. Une fois que le projet atteint plusieurs téraoctets, ces bases de données gérées deviennent lentes et coûteuses, ce qui rend la gestion des données beaucoup plus complexe.

Les performances souffrent lorsque les tables atteignent des milliards de lignes, et bien que il existe des moyens de l'améliorer , les données continueront à croître. Sans une bonne gestion des données, les développeurs ne peuvent que voir leurs disques (et leurs factures) augmenter en taille.

Mais plus maintenant. Aujourd'hui, nous sommes heureux d'annoncer la disponibilité générale du stockage hiérarchisé, une architecture de stockage multiniveau conçue pour permettre une évolutivité infinie et à faible coût pour vos séries temporelles et bases de données analytiques dans la plateforme Timescale. Vous pouvez désormais stocker vos données plus anciennes et rarement consultées dans un niveau de stockage à faible coût tout en continuant d'y accéder, sans jamais sacrifier les performances de vos données fréquemment consultées.

C'est ce qui se produit lorsque vous insérez des données dans une base de données de séries temporelles Timescale avec notre nouveau backend de stockage à plusieurs niveaux :

1. Vos données les plus récentes seront écrites dans un niveau de stockage hautes performances optimisé pour les requêtes rapides et les acquisitions élevées.

   
   

2. Une fois que vous n'accédez pas fréquemment à ces données, vous pouvez automatiquement les hiérarchiser vers un niveau de stockage d'objets moins coûteux en configurant une stratégie de hiérarchisation. Les données du niveau de stockage à faible coût restent entièrement interrogeables dans votre base de données, et il n'y a aucune limite à la quantité de données que vous pouvez stocker : jusqu'à des centaines de To ou plus. Notre niveau de stockage à faible coût propose un prix forfaitaire de 0,021 $ par Go/mois pour les données, soit moins cher qu'Amazon S3.

Les développeurs ont besoin d'un moyen peu coûteux de faire évoluer leurs grandes bases de données PostgreSQL dans AWS sans compromettre les performances. Bien que les magasins d'objets soient incroyablement évolutifs et abordables, ils ne sont pas les plus rapides et les développeurs ont également besoin d'obtenir des réponses aux requêtes en millisecondes pour leurs applications.

Cependant, à mesure que les données vieillissent et sont rarement consultées, les performances en temps réel ne sont souvent plus aussi essentielles. Les développeurs doivent toujours pouvoir accéder à ces données historiques pour des requêtes ad hoc, des analyses de données ou la conformité réglementaire, mais ils peuvent supposer une certaine latence pour ce type de requêtes. Désormais, ce que veulent les développeurs, c'est la possibilité de stocker ces données historiques de la manière la plus abordable et la plus efficace possible.

Cette nouvelle architecture de stockage hiérarchisé libère les développeurs du choix entre les coûts de stockage et les compromis en termes de performances pour les applications en temps réel. En conservant leurs données récentes et fréquemment consultées dans le niveau hautes performances, ils tireront parti de la vitesse de requête en millisecondes et des capacités d'ingestion de Timescale, et en hiérarchisant leurs anciennes données, ils pourront conserver autant de To dont ils ont besoin dans leurs bases de données PostgreSQL pour moins.

Gestion des données PostgreSQL avec stockage hiérarchisé : ce que vous devez savoir

L'architecture de stockage hiérarchisé de Timescale exploite la flexibilité de PostgreSQL et hypertables pour une gestion efficace des données. Lors de la création d’une hypertable, elle peut désormais s’étendre de manière transparente sur les deux niveaux de stockage ; lorsque vous exécutez une requête , Timescale détermine de manière transparente à quels niveaux de stockage accéder pour générer la réponse, améliorant ainsi les performances de vos données les plus récentes et réduisant les coûts de stockage des données plus anciennes. Il n'y a pas de frais supplémentaires par requête ou par lecture de données ni de frais cachés, ce qui permet une gestion des données simple et rentable.

Cette architecture de stockage élimine également toute limitation de stockage dans les services Timescale : étant donné que notre niveau de stockage à faible coût est infini, vous pouvez stocker autant de To que vous le souhaitez. Par exemple, nous exploitons le stockage hiérarchisé en interne pour stocker l'énorme base de données Timescale qui alimente notre produit Insights.

Cette base de données Insights collecte et analyse en permanence les statistiques de requêtes de l'ensemble de notre flotte de clients. Elle dépasse aujourd'hui les 350 To et connaît une croissance rapide. Sur ces 350 To, 250 To sont destinés au stockage à faible coût.

Faisons le calcul :

• Nous stockons 5 To dans notre niveau de stockage hautes performances après compression. Bien sûr, la compression est activée et nous obtenons des taux de compression de 20x, ce qui signifie que ce qui était à l'origine 100 To de données Postgres tient désormais dans un disque de 5 To grâce à la compression (!)

  
  

• Les 250 To de données restants sont stockés dans le niveau de stockage à faible coût. Cette hiérarchisation s'effectue automatiquement une fois que les données atteignent un certain âge, qui date actuellement de plusieurs semaines.

  
  

Nos clients ayant de grands déploiements utilisent également déjà le stockage hiérarchisé :

« Nous effectuons de nombreuses analyses sur les données de marché, et le volume considérable de données que nous devons stocker rend une solution de base de données sur disque normale irréalisable (c'est tout simplement trop cher). Le stockage hiérarchisé de Timescale nous permet de déplacer de manière transparente de gros volumes de données vers " La couche de stockage d'objets. C'est une excellente solution pour stocker de gros volumes de données historiques et effectuer une post-analyse. Sans cela, nous serions obligés de développer une solution en interne. "

- Directeur de la technologie dans une société propriétaire de négoce d'actifs numériques

La simplicité est la caractéristique clé du stockage hiérarchisé. Pour déplacer vos données du niveau haute performance vers le niveau objet à faible coût, il vous suffit d'utiliser notre API simple pour définir des politiques permettant de hiérarchiser vos données à mesure qu'elles vieillissent sur une hypertable particulière. Les politiques de hiérarchisation des données fonctionnent sur une base de fragments (la politique hiérarchisera des fragments complets une fois qu'ils auront atteint l'âge défini par la politique). Aucun processus ETL (extraction-transformation-chargement) ni modification de l'infrastructure n'est nécessaire.

Par exemple, cette stratégie déplacerait toutes les données datant de plus d’un mois vers le stockage objet dans votre hypertable events :

 SELECT add_tiering_policy('events', INTERVAL '1 month');

C'est tout ce dont vous avez besoin ! Tout le reste se produit automatiquement, y compris la planification intelligente des requêtes qui exécute uniquement les requêtes SQL au niveau approprié.

Pour supprimer les données actuellement stockées dans le niveau de stockage à faible coût, vous pouvez définir une politique de conservation des données afin que les données soient automatiquement supprimées après une certaine période (par exemple, après cinq ans). Vous pouvez également supprimer manuellement des morceaux spécifiques .

De plus, si vous souhaitez « reculer » une partie particulière du niveau de stockage à faible coût vers le niveau hautes performances ( par exemple, si vous devez remplir ou mettre à jour des données ), vous pouvez facilement le « dissocier ».

 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk');

Vous pouvez suivre la quantité de données hiérarchisées (et combien cela coûtera à la fin du mois) dans la console Timescale :

Et en parlant d’estimations de facturation…

Combien puis-je économiser avec le stockage hiérarchisé ?

Notre niveau de stockage haute performance a un prix effectif de 0,177 $ par Go/mois de données après compression (compte tenu du taux de compression attendu que nous constatons sur notre flotte). À cela s’ajoute désormais une couche de stockage à faible coût avec un tarif forfaitaire de 0,021 $ par Go/mois de données, avec le même prix dans toutes les régions cloud.

Lors de la hiérarchisation des données, vous ne paierez que pour les données que vous stockez , pas pour les requêtes exécutées ou la quantité de données analysées : il s'agit véritablement d'un prix forfaitaire. Notre objectif avec cette structure tarifaire était de fournir un moyen transparent, sans ambiguïté et simple de calculer le coût total du stockage de données, facilitant ainsi la gestion de vos données.

À titre d'exemple rapide, disons que vous disposez d'une hypertable avec 5,2 To de stockage, avec des morceaux d'hypertable récents et d'autres tables Postgres occupant environ 200 Go et environ 5 To de données hypertable datant de plus d'un mois. Vous n’accédez pas ou n’interrogez pas fréquemment ces anciennes données, ce qui signifie que vous n’en avez pas besoin pour les opérations quotidiennes de votre application. Vous souhaitez néanmoins le garder accessible dans votre base de données pour des requêtes ponctuelles ou des exigences de conformité (nous constatons de nombreux cas de ce type chez nos clients).

En tant que stratégie de gestion des données rentable, vous pouvez classer tous les morceaux de plus d'un mois vers le niveau à faible coût et réduire le coût de stockage de ces 5 To de données d'environ 478 $/mois à environ 105 $/mois, soit une diminution de 78 %. dans votre facture de stockage. ( Pour cette estimation, nous supposons que vous avez activé la compression pour votre hypertable et considérons la compression globale médiane dans tous les services Timescale).

Les économies augmenteront parallèlement à vos données : en déplaçant plusieurs téraoctets vers ce niveau à faible coût, votre facture de stockage passera de plusieurs milliers de dollars à quelques centaines. Le tableau de référence suivant illustre à quel point notre niveau de stockage à faible coût est réellement abordable.

Tu obtiens le point!

L’effet multiplicateur des économies du stockage hiérarchisé

Il y a encore une chose qui rend le stockage hiérarchisé encore plus étonnant : lorsque vous conservez des données dans le niveau de stockage à faible coût, vous ne payez ces données qu'une seule fois, indépendamment du fait que vous disposiez d'une réplique à haute disponibilité ou de répliques en lecture exécutées dans votre service. .

La même chose s'applique aux fourches. Dans Timescale, vous pouvez créer des copies de votre base de données principale (nous les appelons forks) en cliquant sur un bouton de l'interface utilisateur, par exemple pour exécuter des tests ou créer des environnements de développement. Lors de la création d'un (ou plusieurs) forks, vous ne serez pas facturé pour les données partagées avec le principal dans le stockage à faible coût . Si vous décidez de hiérarchiser davantage de données qui ne figurent pas dans le niveau principal, vous paierez pour les stocker dans le niveau à faible coût, mais vous bénéficierez toujours d'économies substantielles en les déplaçant du niveau hautes performances du fork vers le niveau le moins cher. .

Pour que cela soit clair, déployons un exemple. Imaginez que vous disposez d'un service principal avec 6,5 To de données et que vous avez également défini :

• Une réplique haute disponibilité pour réduire considérablement le risque de temps d'arrêt et de perte de données dus à des pannes

  
  

• Un réplica en lecture pour répondre à vos requêtes de lecture et permettre au réplica principal de se consacrer entièrement aux écritures

  
  

• Un fork de ce service à des fins de développement et de test

  
  

Du point de vue de la facturation, si vous conserviez les 6,5 To de données dans votre service principal dans le niveau de stockage hautes performances, vous verriez cela reflété [6,5 To x 4] dans votre facture de stockage pour tenir compte des deux réplicas, du fork et le service principal : 26 To au total. En supposant notre taux de compression médian, cela coûterait cher : environ 4 602 $/mois.

Mais que se passe-t-il si votre application doit accéder activement uniquement aux 500 Go de données les plus récents ? Vous pouvez associer 6 To à un stockage à faible coût et ne conserver que 500 Go sur votre niveau de stockage hautes performances. Et comme vous ne payez qu’une seule fois pour les données de votre niveau de stockage à faible coût, voici à quoi ressemblerait votre nouvelle facture de stockage :

• [500 Go x 4] = 2 To de stockage hautes performances (au lieu de 26 To)

  
  

• [6 To x 1] dans le niveau de stockage à faible coût

  
  

La facture de stockage ci-dessus s'élèverait à environ 480 $/mois : vous économiseriez plus de 4 000 $/mois ! Il s’agit de l’effet multiplicateur des économies du stockage hiérarchisé. Surtout si vous utilisez des répliques ou des forks, c'est une excellente idée de profiter du niveau de stockage à faible coût : les économies que vous constaterez sur votre facture globale seront très importantes.

Notre parcours de stockage hiérarchisé

Nous avons publié une première version de notre fonctionnalité de stockage hiérarchisé sur la plateforme Timescale en accès anticipé en mars. Après de nombreuses améliorations, il est désormais disponible en disponibilité générale. Depuis sa première version, nous avons travaillé dur pour rendre le stockage hiérarchisé stable, fiable et plus rapide.

Nous avons également longuement réfléchi à notre modèle de tarification, en répétant constamment plusieurs façons de fixer le prix de notre niveau de stockage à faible coût. Finalement, nous avons penché vers le plus simple : un forfait sur le volume de données pré-compression. Nous avons déjà mentionné à quel point nous apprécions une tarification simple et prévisible, mais il était également important pour nous de proposer un prix par Go/mois aussi bas que possible. Notre prix a atterri à 0,021 $ : à titre de comparaison, le stockage de fichiers sur Amazon S3 coûte 0,023 $ par Go/mois .

Personnellement, je (Yannis) dois admettre qu'après avoir dirigé des équipes créant des solutions cloud natives pendant plus d'une décennie, je dois encore revenir en arrière et revérifier occasionnellement plusieurs tableaux de tarifs sur diverses pages de tarification cloud, en particulier à la recherche de frais supplémentaires, à chaque fois que cela Je souhaite calculer avec précision le coût total de nos services.

Chez Timescale, nous pensons que vous ne devriez pas avoir à créer une feuille de calcul compliquée pour pouvoir exécuter un service de base de données ou faire des choix éclairés concernant les couches de stockage.

Notre engagement à faciliter la vie des développeurs nous a conduit à un tarif forfaitaire de 0,021 $ par Go/mois : sans incertitudes, sans coûts cachés ni frais par requête ou lecture de données.

Fonctionnement du stockage hiérarchisé : dans les coulisses

Toutes les données insérées dans Timescale sont initialement écrites dans notre couche de stockage haute performance. L'utilisation de disques plus rapides pour vos données les plus récentes apportera des performances d'insertion et de requête optimales pour vos valeurs les plus récentes, un modèle d'utilisation qui répond aux besoins des applications gourmandes en données.

Au contraire, le niveau de stockage à faible coût est un magasin d'objets construit sur Amazon S3. Ce magasin d'objets est bien plus qu'un compartiment externe pour archiver vos données : il fait partie intégrante de votre base de données. Lorsque vous déplacez des données vers ce niveau de stockage d'objets, votre base de données restera pleinement consciente de toute la sémantique et des métadonnées, et vous pourrez continuer à interroger comme d'habitude avec le SQL standard (bien qu'avec des performances plus lentes).

En coulisses, nous stockons les données dans un format de colonnes compressé (en particulier Apache Parquet ). Lorsque les données sont hiérarchisées, les morceaux stockés dans le format de base de données interne natif de Timescale (généralement dans notre compression en colonnes native ) sont convertis de manière asynchrone au format Parquet et stockés dans l'objet S3 sous-jacent. Nous avons créé plusieurs mécanismes pour garantir que les fragments hiérarchisés sont stockés de manière durable dans le niveau de stockage à faible coût avant de les supprimer de manière transactionnelle du niveau hautes performances.

Lorsque vous exécutez votre requête SQL, elle extraira de manière transparente les données du niveau de stockage hautes performances, du niveau de stockage d'objets ou des deux, selon les besoins. Lorsque nous disons transparent, nous entendons transparent : Timescale prend en charge les requêtes arbitrairement complexes sur ses données standard et hiérarchisées, y compris les prédicats complexes, les JOIN, les CTE, le fenêtrage, les hyperfonctions, etc.

Dans l'exemple de requête ci-dessous (avec une clause EXPLAIN ), vous pouvez voir comment le plan de requête inclut une Foreign Scan lorsque la base de données accède aux données du niveau de stockage d'objets. Dans cet exemple, devices et sites sont des tables Postgres standard (résidant uniquement dans un stockage haute performance), tandis que metrics sont une hypertable qui s'étend sur les deux niveaux de stockage. Lors de l'exécution de cette requête sur l'hypertable metrics , trois de ses fragments ont été lus à partir du stockage standard et cinq fragments ont été lus à partir du stockage d'objets.

 EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text)

Dans le plan de requête ci-dessus, l' Foreign Scan on osm_chunk_3334 correspond à la récupération des données du niveau de stockage d'objets sans fond.

Pour éviter de traiter des fragments tombant en dehors de la fenêtre temporelle de la requête, nous effectuons une exclusion de fragments pour toucher uniquement les fragments nécessaires à la satisfaction de la requête. La base de données stocke diverses formes de métadonnées pour créer une « carte » des groupes de lignes et des décalages de colonnes au sein du stockage d'objets.

De plus, lorsqu’une requête est exécutée, elle est encore plus sélective quant aux données qu’elle lit. Si votre requête ne touche qu'une plage de lignes et quelques colonnes, seul ce sous-ensemble de données est lu à partir de l'objet S3 derrière le niveau de stockage à faible coût.

Dans ce qui précède, par exemple, seules les colonnes device_id et value sont lues à partir du niveau de stockage d'objets. Si un filtre WHERE temporel supplémentaire avait été inclus, la base de données utiliserait d'abord ses métadonnées (stockées dans un stockage haute performance et mises en cache en mémoire) pour réduire davantage les fichiers Parquet et les groupes de lignes qui doivent être lus pour exécuter la requête. Tout cela pour réduire la latence des requêtes, même lors de l'accès transparent à ce stockage sans fond via PostgreSQL.

Essayez le stockage hiérarchisé

Les décisions de stockage concernant les données historiques ne doivent pas nécessairement être coûteuses. Dans Timescale, vous avez désormais accès à un niveau de stockage infini et à faible coût, sans problème de prix, qui vous permet de faire évoluer le stockage de votre base de données à un prix abordable sans compromettre les performances de votre application.

Si vous vous demandez si c'est une bonne solution pour votre cas d'utilisation, consultez nos documents pour plus d’informations et les cas d’utilisation adaptés. Si vous recherchez une perspective plus pratique, vous pouvez également expérimenter Stockage hiérarchisé vous-même gratuitement sur la plateforme Timescale via notre essai gratuit (aucune carte de crédit requise) .

- Écrit par Yannis Roussos, Carlota Soto et Ana Tavares.