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 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. PostgreSQL Les performances souffrent lorsque les tables atteignent des milliards de lignes, et bien que , 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. il existe des moyens de l'améliorer 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 : Vos données les plus récentes seront écrites dans un optimisé pour les requêtes rapides et les acquisitions élevées. niveau de stockage hautes performances Une fois que vous n'accédez pas fréquemment à ces données, vous pouvez automatiquement les hiérarchiser vers un 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. niveau de stockage d'objets moins coûteux 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 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 besoin d'obtenir des réponses aux requêtes en millisecondes pour leurs applications. AWS également 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 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 ; , 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. hypertables lorsque vous exécutez une requête 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 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 (!) après 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 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. API simple les hypertables d'échelle de temps sont des tables PostgreSQL automatiquement partitionnées par temps. Ces partitions sont appelées morceaux. Les morceaux sont l'unité de politiques définies par l'utilisateur dans Timescale : par exemple, lorsque vous définissez une politique de conservation des données, vous supprimez des partitions entières (morceaux) et lorsque vous déplacez des données entre des niveaux de stockage, vous déplacez des morceaux entiers. . Il s'agit d'un moyen très pratique de gérer les données du point de vue de l'utilisation des ressources et de l'expérience du développeur. Note de l'éditeur : 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 ( ), vous pouvez facilement le « dissocier ». par exemple, si vous devez remplir ou mettre à jour des données -- 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 (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. après compression Lors de la hiérarchisation des données, vous , 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. ne paierez que pour les données que vous stockez À 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, . 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. . vous ne serez pas facturé pour les données partagées avec le principal dans le stockage à faible coût 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 : 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. vous économiseriez plus de 4 000 $/mois ! 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. désigne le volume de données avant l'application de la compression Timescale. Par exemple, en raison de la compression Timescale, un volume de 500 Go au niveau de stockage hautes performances peut nécessiter seulement 50 Go d'espace disque une fois compressé. Si vous décidez de transférer ces données vers un stockage à faible coût, votre facture sera calculée sur le volume initial de 500 Go, soit [500 Go * 0,021 $] par mois. La précompression du volume 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 ). 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 ) 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. Apache Parquet compression en colonnes native 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 ), vous pouvez voir comment le plan de requête inclut une lorsque la base de données accède aux données du niveau de stockage d'objets. Dans cet exemple, et sont des tables Postgres standard (résidant uniquement dans un stockage haute performance), tandis que sont une hypertable qui s'étend sur les deux niveaux de stockage. Lors de l'exécution de cette requête sur l'hypertable , trois de ses fragments ont été lus à partir du stockage standard et cinq fragments ont été lus à partir du stockage d'objets. EXPLAIN Foreign Scan devices sites metrics metrics 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' correspond à la récupération des données du niveau de stockage d'objets sans fond. Foreign Scan on osm_chunk_3334 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 et sont lues à partir du niveau de stockage d'objets. Si un filtre 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. device_id value WHERE 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, Si vous recherchez une perspective plus pratique, vous pouvez également expérimenter . consultez nos documents pour plus d’informations et les cas d’utilisation adaptés. 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. Également publié ici.