Quelle base de données cloud devriez-vous utiliser ?

Le principe de base des systèmes cloud est de se concentrer sur de nombreux fabricants jetables et changeants. Cela a des répercussions directes sur les techniques de mise en œuvre et, pour cette raison, sur les capacités des systèmes de bases de données exécutés dans le cloud.

Les bases de données conventionnelles peuvent être approximativement classées comme parallèles d’abord (par exemple, MongoDB ou Teradata) ou simples -système tout d’abord (par exemple, PostgreSQL ou MySQL), généralement avec une mise à l’échelle plus tard (par exemple, Redshift, Greenplum). Chaque classification a des contraintes inhérentes à son style de base. Le degré de ces contraintes est en partie fonction de la maturité. Pour certains choix architecturaux de base, des fonctionnalités particulières peuvent ne pas être supportées efficacement.

Greenplum a des séquences, mais pas Redshift, même si les deux sont des dérivés de PostgreSQL. BigQuery n’a pas de séries, mais Teradata en a (bien qu’elles ne soient pas véritablement consécutives, au sens conventionnel du terme).

Les bases de données cloud relèvent des mêmes classifications, avec une nette tendance à privilégier le parallèle pour les nouveaux systèmes . Les maisons fondamentales des systèmes cloud sont le parallélisme pour l’évolutivité et la remplaçabilité des fabricants.

Au sein de la classification à système unique, les instanciations cloud ont tendance à se concentrer sur les dépenses gérées, la mise à niveau et la fiabilité (RPO/RTO) de le produit traditionnel à machine unique, tel que Heroku PostgreSQL, Amazon Aurora (PostgreSQL/MySQL), Google Cloud SQL (PostgreSQL/MySQL) et Azure SQL (SQL Server).

Dans la catégorie parallèle, il sont efficacement 2 sous-catégories : la catégorie SQL/relationnelle (BigQuery, Snowflake, Redshift, Glow, Azure Synapse) et la catégorie DHT/NoSQL (BigTable, Eager Beaver, Cassandra, Redis). Cette distinction a moins à voir avec l’existence ou l’absence d’un langage de type SQL et plus avec le fait que la disposition physique des données dans le système est réglée pour un accès à une seule ligne par hachage pour des recherches rapides sur un secret, ou un accès en masse à l’aide d’opérations de tri-fusion et de filtrage.

Les bases de données relationnelles parallèles d’abord comptent souvent sur un ou plusieurs systèmes de stockage cloud natifs. Ces systèmes de stockage sont constamment construits en parallèle d’abord et exposent une API get-object/put-object extrêmement limitée, qui permet normalement le partitionnement des informations, mais ne permet pas un accès aléatoire à haute efficacité. Cela restreint la capacité de la base de données à exécuter des structures de données avancées et implacables telles que des index ou, souvent, des données modifiables.

En conséquence, les implémentations cloud utilisant le stockage natif ont tendance à dépendre sur la lecture et l’écriture séquentielles de micropartitions au lieu d’index. Il y a généralement un seul accès physique pour accéder aux éléments de niveau de stockage, en fonction du nom de l’élément. Les index devraient être exécutés à l’extérieur du stockage sous-jacent, et même lorsque cela est fait, l’API de stockage en nuage sous-jacente peut rendre difficile l’utilisation utile d’une adresse ou d’un décalage d’octets dans des choses au niveau du stockage.

Forces du cloud

L’infrastructure est gérée pour vous. Dans le cloud, la mise en œuvre, la fiabilité et l’administration sont le problème de quelqu’un d’autre. Toutes les couches de la pile, depuis l’alimentation, la configuration des applications logicielles et le matériel jusqu’à la gestion et la sécurité du système en cours d’exécution (du renforcement à la détection des invasions) sont gérées par le fournisseur de cloud.

La commodité des offres d’essai gratuites du fournisseur de cloud pour vous permettre de démarrer les expériences initiales et ensuite avec dignité, une échelle approximativement énorme si nécessaire est quelque chose qui est au mieux difficile dans les systèmes sur site standard.

Un autre avantage est que les fournisseurs de cloud utilisent de nombreuses procédures standardisées à intégrer avec des éléments SaaS tiers. Le résultat est que le fournisseur de cloud fait de l’infrastructure un problème pour quelqu’un d’autre afin que vous puissiez vous concentrer sur votre service principal.

Efficacité. Le cloud vit en tirant le meilleur parti de l’utilisation des ressources. Il est encore plus courant pour un système cloud d’exposer la gestion de l’utilisation des ressources à l’application de base de données que pour un système non cloud. La charge peut être lissée, déplacée vers des créneaux horaires à faible demande, et les tâches interactives et critiques peuvent être hiérarchisées.

Bien sûr, les fournisseurs de cloud peuvent exploiter l’efficacité des achats à grande échelle, du partage de charge et très taux d’utilisation. Ces arguments d’échelle à eux seuls peuvent justifier une relocalisation vers le cloud. Sans parler des avantages de l’utilisation du savoir-faire du fournisseur pour le renforcement et la détection des invasions.

La capacité des fournisseurs de cloud à provisionner à moindre coût un stockage passif, ce qui le rend beaucoup plus facile à conserver plus longtemps, est soigneusement associée à l’évolutivité. des fenêtres historiques de données, que ce soit pour des facteurs expérimentaux ou analytiques, ou pour une sauvegarde ou un audit, et plus économiques pour mettre en œuvre des fonctions comme le voyage dans le temps, où les données peuvent être inspectées d’un point de vue historique.

Et évidemment, les charges de traitement de données lourdes peuvent être résolues en augmentant temporairement l’échelle à l’aide de l’échelle du fournisseur de cloud (au détriment de l’utilisateur, évidemment).

Économie. Outre l’économie d’échelle et efficacité, les mécanismes comptables des fournisseurs de cloud ont tendance à exposer les données de coûts de stockage et de traitement jusqu’au niveau de la demande individuelle. Cela permet à l’utilisateur de faire un choix d’entreprise raisonnable quant au rapport coût-bénéfice de tout élément d’analyse proposé et de prendre des décisions d’optimisation appropriées. En effet, parfois, l’entreprise peut choisir qu’il est moins coûteux d’utiliser l’échelle du cloud pour être plus grande et « simple » dans la façon dont une analyse est structurée plutôt que d’investir du temps et de l’énergie mentale, pour façonner une « analyse robuste » (une qui est moins cher et peut-être plus précis).

Points faibles du cloud

Les installations sont gérées pour vous. Le cloud a un ensemble de domaines de défaillance extrêmement différent à partir, par exemple, d’un ordinateur central de la série Z. Le calcul dispersé sur le cloud, qui est un substrat partagé (calcul, stockage, réseau), est soumis à beaucoup plus de perturbations, et n’importe laquelle d’entre elles peut déclencher une panne d’interactivité ou une panne de travail transitoire. Même la gestion automatisée par un fournisseur de cloud peut, lors de rares célébrations, nuire à l’expérience client en modifiant les propriétés ou les habitudes d’un système.

Performances. La plupart des bases de données cloud sont encore immatures. par rapport aux systèmes traditionnels sur site. Les bases de données cloud n’ont pas les fonctionnalités de produits plus développés. Certaines fonctionnalités peuvent ne jamais être introduites en raison du fait que l’idée d’une plate-forme complètement distribuée et sujette aux défaillances les rend peu pratiques.

De nombreux systèmes relationnels parallèles basés sur le cloud ont en fait une performance considérablement réduite pour certains les opérations de mutation de la base de données (INSERT, UPDATE, ERASE), qui peuvent déclencher un problème dans des cas d’utilisation spécifiques.

Naturellement la latence supplémentaire entre les systèmes cloud et sur site ou les systèmes hébergés dans d’autres clouds aura tendance à forcer la combinaison de l’infrastructure cloud. Les utilisateurs ont tendance à être obligés de sélectionner initialement un lieu géographique et un fournisseur de services, puis ils sont limités avec succès aux services au sein de ce fournisseur.

Économie. Le coût du cloud suit une évolution extrêmement courbe variable à partir de la version sur site : il est extrêmement facile d’élargir les capacités. C’est si simple que le contrôle des coûts finit par être plus difficile. D’un autre côté, si le coût est dépassé, les travaux interactifs envoyés après l’atteinte d’un plafond de dépenses peuvent être rejetés. Cela ajoute une couche de complexité que les administrateurs de bases de données classiques devront apprendre afin de créer un déploiement réussi.

Et, naturellement, le verrouillage du fournisseur est tout simplement aussi courant dans le cloud qu’ailleurs. La migration entre les clouds n’est pas plus simple que la migration entre les systèmes sur site.

Il existe de nombreuses offres parmi lesquelles choisir et aucune offre unique ne possède toutes les fonctionnalités. Les premières étapes les plus cruciales consistent à déterminer les propriétés ou les comportements résidentiels ou commerciaux essentiels de tous les flux de travail requis, et à s’assurer que le fournisseur de cloud choisi a la capacité de les offrir tous – potentiellement chaque comportement d’un différent, mais au moins faiblement incorporé, produit de leur suite. Ne vous attendez pas à voir un seul produit comme Oracle ou Teradata qui fait « tout » pour le prix.

Shevek est CTO de CompilerWorks.

— Nouveau

Le forum technique offre un lieu pour découvrir et discuter des technologies d’entreprise émergentes avec une profondeur et une ampleur inégalées. La sélection est subjective, basée sur notre choix des innovations que notre société considère comme cruciales et qui intéressent le plus les lecteurs d’InfoWorld. InfoWorld décline les supports marketing pour la publication et se réserve le droit de modifier tout le matériel fourni. Envoyez toutes vos demandes à newtechforum@infoworld.com.