À partir d'aujourd'hui,  .   vous pouvez créer des bases de données dynamiques PostgreSQL sur Timescale  Dynamic   est l'évolution naturelle des bases de données cloud, résolvant les problèmes des bases de données provisionnées et des bases de données sans serveur. Il s'appuie sur le calcul dynamique, une innovation Timescale qui met instantanément à l'échelle votre calcul disponible dans une plage min/max prédéfinie en fonction de votre charge. Au lieu de provisionner votre pic (et de le payer à tout moment), vous pouvez désormais choisir une plage de calcul : votre base de données fonctionnera à sa capacité de base et accédera instantanément à son pic uniquement en cas de besoin. Achetez la base, louez le sommet. PostgreSQL  Cela se traduit par un rapport qualité-prix inégalé : les clients exécutant des charges de travail de production économiseront 10 à 20 % lors de la migration depuis AWS RDS pour PostgreSQL et 50 à 70 % lors de la migration depuis AWS Aurora Serverless.  Vous pouvez essayer Dynamic PostgreSQL dès aujourd'hui. Nous proposons un essai gratuit, sans carte de crédit, qui vous donne un accès complet à la plateforme pendant 30 jours.  Pour créer un service Dynamic PostgreSQL, sélectionnez simplement l'option PostgreSQL lors de la connexion à Timescale :   Votre application est toujours active, pourquoi votre base de données ne le serait-elle pas ?  Bienvenue dans le futur.  Problème 1 : les développeurs fournissent bien plus de calcul que ce dont ils ont besoin  Au cours des dernières années, depuis le lancement de Timescale, nous sommes aux premières loges pour comprendre comment les développeurs utilisent les bases de données. Par exemple, au cours des derniers mois,  dans le cadre de notre produit Insights.   nous avons analysé plus d'un billion de requêtes   Une chose que nous avons apprise est que les développeurs fournissent souvent bien plus de calcul que ce dont ils ont réellement besoin.  D'une part, cela a du sens : vous ne voulez jamais vous soucier de votre base de données. La plupart des charges de travail de bases de données sont continues, avec généralement une certaine variabilité ou rafale. Par exemple, un jeu plus utilisé la nuit, une application professionnelle plus utilisée pendant la journée ou un appareil domestique connecté plus utilisé le week-end que pendant la semaine.   Vous ne voulez jamais que votre base de données soit à court de ressources. Si votre base de données est à sa capacité maximale, cela conduit à une expérience client épouvantable (ou à aucune expérience client !). Ainsi, la plupart des développeurs finissent par provisionner le pic, plus un tampon. Cela conduit les développeurs à payer pour beaucoup plus de calcul que ce dont ils ont réellement besoin.  D’un autre côté, cela nous semble fou. Quelle autre ressource commerciale les organisations seraient-elles prêtes à dépenser bien plus que ce dont elles ont besoin ? Un calcul gaspillé équivaut à un gaspillage d’argent.  Problème 2 : les bases de données sans serveur ne répondent pas aux charges de travail de production  Certains d'entre vous se demandent peut-être : « Qu'en est-il des bases de données sans serveur ? »  Le concept sans serveur est né des charges de travail sans état. Après le succès des machines virtuelles dans le cloud, où les utilisateurs pouvaient ne plus avoir à se soucier du matériel, ils se sont ensuite demandé pourquoi s'inquiéter de l'exécution des serveurs d'applications ? Après tout, de nombreux utilisateurs souhaitaient simplement exécuter des fonctions et n'être facturés que pour la durée d'exécution de ces fonctions. Et il est facile et transparent d'activer les fonctions selon les besoins, presque précisément parce qu'elles sont sans état. Le sans serveur et la fonction en tant que service ou FaaS sont devenus un succès, avec AWS Lambda prenant le relais.  Les développeurs se sont alors demandé : « Pourquoi payer pour ma base de données alors que je ne l'utilise pas ? » La vraie question est bonne : le gaspillage des ressources constitue un énorme problème de base de données. Et la pratique consistant à provisionner une base de données AWS RDS sur une instance de serveur spécifique (par exemple, un db.m6gd.2xlarge) ne semble certainement ni moderne ni flexible : processeur fixe, mémoire fixe, disque local fixe. La majeure partie est sous-utilisée la plupart du temps.  Mais c’est là que les choses se compliquent : les bases de données sont très différentes des fonctions Lambda.   Les bases de données sans serveur d'aujourd'hui ne conviennent pas à la plupart des charges de travail de production pour deux raisons principales :  Les bases de données sans serveur se concentrent sur les extrêmes en matière d'évolution vers le haut et vers le bas, voire jusqu'à zéro.  Les bases de données sans serveur introduisent des tarifs beaucoup plus élevés pour tenir compte de la « marge » de ressources réservée pour répondre à l’évolution des demandes (et pire encore, souvent avec des modèles de tarification difficiles à comprendre ou à prévoir).  Commençons par discuter du sujet brûlant de « l’échelle vers zéro ». La réalité est que la plupart des bases de données de production n’ont pas besoin et ne bénéficieront pas d’une mise à l’échelle jusqu’à zéro.  Il existe désormais certains cas d’utilisation dans lesquels « mettre à l’échelle zéro » a du sens. Par exemple, des démonstrations de validation de principe ou des applications plus amateurs. La possibilité d'exécuter occasionnellement une requête ad hoc sur votre ensemble de données (AWS Athena et Google BigQuery plaident en faveur d'un entrepôt de données cloud sans serveur et à faible coût pour une utilisation très intermittente). Un autre cas d'utilisation approprié serait d'éviter d'oublier d'arrêter une instance de développement cloud une fois terminée : il est utile de « mettre en pause automatiquement » une base de données hors production (bien que cela nécessite des fonctionnalités beaucoup plus simples que celles envisagées par le sans serveur).   Mais pour votre base de données de production et dans des contextes plus opérationnels ? Vous ne voulez pas atteindre zéro.  La mise à l'échelle à zéro signifie un « démarrage à froid » au redémarrage : tampons partagés de base de données vides, cache du système d'exploitation vide, caches de catalogue vides (dans le cas de PostgreSQL).  (Oui, certaines bases de données sans serveur réduisent le temps nécessaire au démarrage de la base de données, mais elles le font à partir d'un état vide. Dans une base de données relationnelle comme PostgreSQL, cela peut prendre quelques minutes (ou plus !) pour reconstruire un ensemble de travail à chaud, surtout pour les bases de données plus volumineuses.)  L'impact sur les performances du démarrage à froid est d'autant plus important que de nombreuses bases de données sans serveur adoptent différentes architectures de stockage cloud, où le coût et la latence de récupération des pages de base de données du stockage distant vers la mémoire sont encore plus importants. Ces frais généraux entraînent à nouveau une dégradation des performances ou obligent les fournisseurs de plates-formes à compenser en utilisant davantage de ressources physiques (par exemple, les bases de données Amazon Aurora ont deux fois plus de mémoire que RDS), un coût qui est finalement répercuté sur les utilisateurs.  Ainsi, dans de nombreux scénarios, les bases de données sans serveur se soldent par des prix plus élevés et imprévisibles.  Par exemple, si vous comparez Aurora Serverless à Amazon RDS, vous verrez que le calcul de 8 vCPU et 500 Go de stockage sur Serverless coûte 85 % plus cher que RDS (1 097 $ contre 593 $). Et cela grâce à Aurora I/O Optimized et ses prix de stockage plus prévisibles, lancés il y a à peine six mois. (Bien que, même ici, nous devons encore déduire sa capacité de calcul réelle, car Aurora Serverless prix en confondant les « unités de capacité Aurora » opaques, qui, selon nos estimations les mieux informées, sont 1 ACU = 0,25 vCPU.)    nous publierons bientôt un benchmark complet étayant ces résultats. Restez à l'écoute. Note de l'éditeur :  Auparavant, avec Aurora Standard, les utilisateurs payaient également pour chaque opération d'E/S interne, ce qui était presque impossible à prévoir ou à budgétiser. De nombreuses bases de données sans serveur continuent de facturer ces lectures et écritures. En fait, lorsque nous avons comparé AWS Timestream sans serveur, nous avons constaté  qu'avec Timescale en raison de tous ces coûts marginaux plus élevés. L’imprévisibilité et la variabilité des coûts étaient à l’opposé de l’insouciance.   des coûts qui ont fini par être plus de 100 fois plus élevés  En bref, les bases de données sans serveur sont sujettes à de moins bonnes performances, à des factures imprévisibles et à des coûts élevés à mesure que les charges de travail évoluent. Ils ne conviennent qu'aux charges de travail intermittentes qui n'apparaissent qu'occasionnellement et peuvent tolérer des démarrages à froid grâce à leur manque de mise en cache des données en mémoire.  Le dilemme du développeur   Voilà où nous en sommes arrivés :  De nombreux développeurs choisissent encore les services DBaaS traditionnels avec provisionnement pour les applications de production en raison de leurs performances fiables, de leur contrôle et de leur compréhensibilité, mais détestent le gaspillage résultant de la nécessité d'un surprovisionnement.  Certains développeurs choisissent les bases de données sans serveur pour leurs économies apparentes, leur flexibilité et leur facilité d'utilisation, mais détestent les performances et les prix imprévisibles et obscurs (qui entraînent souvent des factures mystérieusement plus élevées que celles d'une instance provisionnée).  En tant que développeurs nous-mêmes, aucune de ces options n’est très attrayante ! Il existe une possibilité de mieux.  Solution : présentation de PostgreSQL dynamique  C'est pourquoi nous avons développé Dynamic PostgreSQL.  Dynamic PostgreSQL prend en charge systématiquement votre base de référence et fait évoluer le calcul de manière transparente lorsque vous en avez besoin, jusqu'à un maximum défini. Cela le rend parfait pour la gamme de charges de travail continues que vous voyez généralement dans les environnements de production (qu’elles soient uniformes, variables ou en rafale).  Dynamic PostgreSQL est 100 % PostgreSQL, avec tous les avantages de la communauté et de l'écosystème PostgreSQL, plus le  . Pour créer Dynamic PostgreSQL, nous avons innové dans la façon dont nous exploitons notre infrastructure PostgreSQL plutôt que de modifier les composants internes de PostgreSQL. Cela vous donne accès à tout ce que PostgreSQL — et la plateforme Timescale — offrent, sans craindre de fonctionner sur une requête ou un moteur de stockage PostgreSQL forké.   maturité de la plateforme de base de données de Timescale  Avec Dynamic PostgreSQL, vous choisissez une   de calcul (un CPU minimum et maximum) correspondant aux besoins de votre charge de travail. Cette plage de calcul est également dotée d'une mémoire efficace équivalente à ce que la plupart des services DBaaS proposent traditionnellement à l'extrémité « maximale » de la plage de calcul. plage  La base (minimum) de votre gamme de CPU agit exactement comme le modèle DBaaS provisionné : le CPU minimum est à tout moment dédié à votre service pour exécuter votre application. À mesure que votre charge augmente (soit en raison de la demande de votre application externe, soit même en raison de tâches internes occasionnelles de base de données telles que des sauvegardes incrémentielles ou l'aspiration automatique des tables), votre base de données peut utiliser jusqu'au pic (maximum) de la plage de votre processeur sans aucun délai.  Comment atteindre le zéro retard ? Le calcul dynamique fonctionne différemment de certaines autres offres de bases de données sans serveur ou à mise à l'échelle automatique, il n'implique donc pas la lenteur de mise à l'échelle (et l'impact sur les performances) que vous constatez généralement lors des migrations à distance. Au lieu de cela, nos algorithmes de configuration d'infrastructure et de placement de charge de travail garantissent que les bases de données peuvent évoluer sur leur nœud sous-jacent sans redémarrage ni reconfiguration. Votre instance a toujours accès à son calcul maximal selon les besoins.  Et le meilleur, c’est que vous ne payez que pour la base plus ce que vous utilisez au-dessus. Nous appelons ce modèle de choix d'une plage de calcul et de mise à l'échelle entre elle «   ».  acheter la base, louer le sommet  Par exemple, si vous choisissez une option 4 à 8 CPU, vous disposerez toujours de 4 CPU dédiés à votre service et de 32 Go de mémoire effective. Cela garantit à tout moment de bonnes performances de base. Lorsque votre charge augmente, votre application peut utiliser jusqu'à 8 processeurs instantanément selon ses besoins (mesurés et facturés sur une base fractionnée de processeur) et jamais plus de 8 processeurs si telle est votre limite maximale.  Le modèle dynamique vous permet de « dimensionner » votre base de données de manière plus rentable et sans souci. Vous pouvez choisir une plage de calcul dans laquelle votre demande standard correspond au minimum, mais vous pouvez augmenter ou augmenter jusqu'au pic (maximum) selon vos besoins. Ce maximum crée un plafond inhérent à toute utilisation supérieure à votre calcul de base, conduisant à un plafond de coût facile à comprendre. De plus, nous facturons le même tarif par heure CPU (fractionnelle) pour votre base et pour toute utilisation mesurée au-delà de celle-ci : il n'y a aucun supplément pour une utilisation au-dessus de votre base, et donc aucune pénalité de prix pour la mise à l'échelle.  Enfin, si vous réalisez que vous avez provisionné une plage de tailles trop faible ou trop élevée, vous pouvez facilement ajuster votre plage de calcul à une taille mieux adaptée aux besoins de votre application.   Conçu pour vous faire économiser de l'argent  Nous proposons actuellement cinq plages de calcul différentes en fonction de la taille de votre charge de travail, avec la mémoire effective correspondante que vous recevez pour la plage, quelle que soit votre utilisation instantanée.   Dynamic PostgreSQL utilise également le stockage basé sur l'utilisation de Timescale, dans lequel vous ne payez que pour le volume de données stockées (en Go-heures), et non pour la taille du disque provisionné. Ne vous inquiétez pas de gaspiller de l'argent avec un disque surprovisionné ni de craindre de manquer d'espace disque. L'infrastructure cloud dynamique de Timescale garantit que vous disposez d'une capacité de stockage suffisante, lorsque vous en avez besoin, et que vous ne payez que pour ce que vous utilisez.  Nous avons développé Dynamic PostgreSQL intentionnellement pour vous faire économiser de l'argent. Les clients exécutant des charges de travail de production économisent généralement 10 à 20 % lors de la migration depuis AWS RDS pour PostgreSQL et 50 à 70 % lors de la migration depuis AWS Aurora Serverless.  À la fin du mois, votre facture se compose de deux mesures simples et faciles à comprendre : (1) vos coûts de calcul, facturés comme votre calcul de base horaire plus toute utilisation fractionnaire du processeur au-dessus, mais pas plus que votre pic ; et (2) vos coûts de stockage, facturés comme consommation de données en Go-heures. Il n’y a pas de nouvelles mesures ou unités dérivées à mesurer ou à comprendre.  Payez simplement ce que vous utilisez. Zéro frais supplémentaires ou frais cachés.  Calcul : prévisible, basé sur une plage définie  Stockage : ne payez que ce que vous stockez  Pas de ressources gaspillées. Pas de surpayement. Pas de perte de sommeil la nuit. Une facture que vous pouvez expliquer à votre patron.  Essayez-le aujourd'hui  Vous pouvez essayer Dynamic PostgreSQL dès aujourd’hui !  —aucune carte de crédit requise—qui vous donne un accès complet à la plateforme pendant 30 jours. Pour créer un service Dynamic PostgreSQL, sélectionnez simplement l'option PostgreSQL lors de la connexion à Timescale :    Timescale propose un essai gratuit  La plateforme propose désormais deux types de services pour répondre aux besoins spécifiques de vos bases de données :    sont conçus pour augmenter la vitesse des requêtes et l'évolutivité de vos charges de travail les plus exigeantes, offrant des fonctionnalités clés d'échelle de temps telles que les hypertables, la compression en colonnes, les agrégats continus et le stockage hiérarchisé. Utilisez-les pour héberger vos données de capteurs, vos mesures énergétiques, vos données financières, vos événements et autres charges de travail gourmandes en données. Les services de séries temporelles    sont des services Postgres dynamiques optimisés pour la rentabilité et la facilité d'utilisation. Utilisez-les pour vos bases de données uniquement relationnelles, par exemple les dossiers commerciaux. Les services PostgreSQL  Une fois que vous avez sélectionné « PostgreSQL », la configuration de votre service Dynamic PostgreSQL est très simple. Sélectionnez votre région, votre plage de calcul dynamique et vos options de haute disponibilité et de pooling de connexions : boum ! 💥 Vous disposez désormais d'une base de données Dynamic PostgreSQL prête à être utilisée en production.   Si vous avez des questions,  . Nous serions ravis d'entendre vos commentaires et de vous aider avec votre cas d'utilisation de PostgreSQL (séries chronologiques ou non) !   contactez-nous  Ce n'est que le début. Nous sommes au milieu de trois semaines de lancement consécutives, et ce n'est que le début de la semaine 2 : Dynamic Infra Week. Restez à l’écoute pour en savoir plus cette semaine, ce mois-ci, cette année et les nombreuses années à venir. 🙂   - Écrit par Mike Freedman et Grant Godeke.  Également publié  ici.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Get Free Unlimited IP Geo Data With IPinfo Lite

Découvrez Dynamic PostgreSQL : l'évolution naturelle des bases de données cloud

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Télégramme : le pont de Crypto Island vers le continent

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Télégramme : le pont de Crypto Island vers le continent

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps