Mis à jours 18 novembre 2017
Abandonner le modèle relationnel ?
Il y a eu de nombreux produits et services récents offrant le stockage de données mais rejetant le modèle relationnel. Cette tendance a été surnommée par certains comme le mouvement NoSQL. Il y a beaucoup d’enthousiasme à la fois pour et contre cette tendance. Quelques-uns de ceux de la colonne « contre » avancent que les bases de données sans schémas, la vérification de type, la normalisation, etc., jettent 40 ans de progrès dans la base de données. De même, certains promoteurs sont prompts à distribuer le battage médiatique sur la façon dont une solution NoSQL donnée résoudra vos problèmes. Le but de cette section est de présenter un cas pour la valeur d’un service comme SimpleDB qui répond à la critique légitime et évite le battage médiatique et l’exagération.
Une base de données sans schéma
L’un des principaux domaines de discorde autour de SimpleDB et d’autres solutions NoSQL est l’absence d’un schéma de base de données. Les schémas de la base de données s’avèrent être très importants dans le modèle relationnel. Le formalisme de prédéfinir votre modèle de données dans un schéma fournit un certain nombre d’avantages spécifiques, mais il impose également des restrictions.
SimpleDB n’a aucune notion de schéma du tout. La plupart des structures définies dans un schéma de base de données typique n’existent même pas dans SimpleDB. Cela inclut des éléments tels que les procédures stockées, les déclencheurs, les relations et les vues. D’autres éléments d’un schéma de base de données comme les champs et les types existent dans SimpleDB mais sont flexibles et ne sont pas appliqués sur le serveur. D’autres fonctionnalités, comme les index, ne nécessitent aucune définition formelle, car le service SimpleDB les crée et les gère en arrière-plan.
Cependant, l’absence d’une exigence de schéma dans SimpleDB ne vous empêche pas de bénéficier des avantages d’un schéma. Vous pouvez créer votre propre schéma pour la partie de votre modèle de données qui vous convient. Cela vous permet de sélectionner les avantages qui sont utiles à votre application sans les restrictions inutiles.
L’une des choses les plus importantes à tirer de la codification de votre mise en page est la séparation entre celle-ci et l’application. Il s’agit d’une fonctionnalité d’activation pour les plugins des outils et des applications. Les outils tiers peuvent interroger vos données, convertir vos données d’un format à un autre, analyser et générer des rapports sur vos données uniquement en fonction de la définition du schéma. L’alternative est moins attrayante. Les outils et les extensions sont plus limités dans ce qu’ils peuvent faire sans connaissance des formats. Par exemple, vous ne pouvez pas calculer la somme des valeurs dans une colonne numérique si vous ne connaissez pas le format de cette colonne. Dans le cas dégénéré, les développeurs doivent rechercher dans votre code source pour déduire les types de données.
Dans SimpleDB, la plupart des fonctionnalités de base de données les plus courantes ne sont pas disponibles. La requête est cependant une fonctionnalité importante qui a une incidence sur le formatage de vos données. Comme toutes les données que vous stockez dans SimpleDB sont des données de caractères de longueur variable, vous devez appliquer un remplissage aux données numériques pour que les requêtes fonctionnent correctement. Par exemple, si vous souhaitez stocker un attribut nommé “price” avec la valeur “269.94”, vous devez d’abord ajouter des zéros en tête pour le rendre “00000269.94”. Ceci est nécessaire car les comparaisons supérieures et inférieures à SimpleDB comparent chaque caractère de gauche à droite. Le remplissage avec des zéros vous permet d’aligner le point décimal afin que les comparaisons soient correctes pour toutes les valeurs possibles de cet attribut. Les produits de base de données relationnels gèrent cela en coulisse lorsque vous déclarez qu’un type de colonne est de type numérique, tel que int.
C’est un cas dans SimpleDB où un schéma est bénéfique. Le code qui importe initialement les enregistrements dans SimpleDB, le code qui écrit les enregistrements lorsque votre application s’exécute et tout code qui utilise un attribut numérique dans une requête doivent tous utiliser le même format. Le stockage explicite du schéma en externe est une approche beaucoup moins sujette aux erreurs que la définition implicite du format en code dupliqué sur différents modules. Un autre avantage du schéma prédéfini dans le modèle relationnel est qu’il vous oblige à réfléchir sur les relations de données et à prendre des décisions sans ambiguïté concernant la disposition de vos données. Parfois, cependant, les données sont simples, il n’y a pas de relations, et la création d’un modèle de données est exagérée. Parfois, vous pouvez toujours être en train de définir le modèle de données. SimpleDB peut être utilisé dans le cadre du processus de prototypage, vous permettant de faire évoluer votre schéma dynamiquement lorsque des problèmes surgissent qui ne sont peut-être pas connus rapidement. Vous pouvez migrer depuis une base de données différente avec un modèle de données existant. La chose importante à retenir est que SimpleDB est simple par conception. Il peut être utile dans une variété de situations et ne vous empêche pas de créer votre propre schéma externe à SimpleDB.
Zones où les bases de données relationnelles ne sont pas appliquées
On a parlé des bases de données relationnelles depuis un certain temps. Il existe de nombreux produits robustes et matures disponibles. Les produits de base de données modernes offrent une multitude de fonctionnalités et une multitude d’options de configuration.
Un domaine où la difficulté se pose est avec les fonctionnalités de la base de données dont vous n’avez pas besoin ou que vous ne devriez pas utiliser pour une application particulière. Les applications qui ont des exigences de stockage de données simples ne bénéficient pas de la myriade d’options disponibles. En fait, cela peut être préjudiciable de deux façons différentes. Si vous avez besoin d’apprendre les subtilités d’un produit de base de données particulier avant de pouvoir en faire bon usage, le temps passé à apprendre vous enlève du temps que vous auriez pu consacrer à votre application. La connaissance du fonctionnement des produits de la base de données est bonne à avoir. Il serait difficile de prétendre que vous avez perdu votre temps en l’apprenant parce que cette information pourrait vous servir bien loin dans le futur. De même, s’il existe une solution beaucoup plus simple qui répond à vos besoins, vous pouvez choisir celle-ci à la place. Si vous n’aviez pas d’exigence immédiate pour acquérir une expertise de base de données spécifique au produit, il serait difficile d’insister sur le fait que vous avez fait le mauvais choix. Il est difficile de prétendre que la route la plus longue, mais éducative, est toujours meilleure que la route simple et directe. C’est un défi auquel font face les bases de données aujourd’hui, lorsque les problèmes simples ne sont pas résolus avec des solutions simples.
Un autre point difficile avec les bases de données relationnelles est la mise à l’échelle horizontale. Il est facile de dimensionner verticalement une base de données en renforçant votre serveur car la mémoire et les unités de disque sont peu coûteuses. Cependant, la mise à l’échelle d’une base de données sur plusieurs serveurs peut s’avérer extrêmement difficile. Il existe toute une gamme d’options pour la mise à l’échelle horizontale qui inclut la réplication de base maître-esclave ainsi que des stratégies de fragmentation complexes. Ces solutions nécessitent chacune une expertise différente et parfois considérable. Néanmoins, elles ont toutes une chose en commun par rapport aux solutions d’échelle verticale. En plus de la difficulté de mise en œuvre, chaque serveur supplémentaire entraîne une augmentation supplémentaire de la responsabilité de maintenance continue. De plus, ce n’est pas simplement la maintenance du serveur additionnel d’avoir plus de serveurs. Ici, on fait référence aux tâches d’administration de base de données réelles de la gestion des répliques supplémentaires, des sauvegardes et de l’envoi de journaux. Il inclut également les tâches de déploiement des modifications de schéma et de nouveaux index sur tous les serveurs du cluster.
Si vous recherchez une solution de base de données simple ou horizontale, SimpleDB est certainement un service à prendre en compte.
L’évolutivité n’est pas votre problème
Partout, vous pouvez trouver des gens qui mettront des efforts pour une mise à l’échelle horizontale. Au-delà du coût et de la difficulté, il existe un certain degré de résistance aux produits et services qui cherchent à résoudre ces problèmes.
Le conseil typique, et maintenant cliché, tend à être que l’évolutivité n’est pas votre problème, et essayer de résoudre l’évolutivité au départ est un cas d’optimisation prématurée. Ceci est suivi d’une discussion sur le nombre de pages vues quotidiennes qu’un seul serveur de base de données hautes performances peut prendre en charge. Enfin, cela se termine en notant que c’est vraiment un problème lorsque vous atteignez l’échelle de Google ou Amazon.
La prémisse de l’argument est réellement solide, bien que non applicable à toutes les situations. La prémisse est que lorsque vous construisez un site ou un service dont personne n’a encore entendu parler, vous êtes plus soucieux de gérer des tas de gens que de rendre le site remarquable. C’est un bon conseil pour ces situations. De plus, il est particulièrement opportun de considérer qu’il y a un petit segment de commentateurs Internet qui chante avec enthousiasme: “X ne change pas d’échelle”, où X est une alternative à la solution utilisée par le commentateur. Parmi les programmeurs, il y a une préoccupation générale avec l’optimisation des performances qui semble quelque peu déséquilibrée.
La vérité est que pour de nombreux projets, l’évolutivité n’est vraiment pas votre problème, mais la disponibilité peut l’être. La distribution de votre magasin de données sur des serveurs n’est pas une optimisation prématurée lorsque vous pouvez quantifier le coût des temps d’arrêt. Si quelques heures d’arrêt ont un impact sur votre entreprise, la disponibilité est quelque chose qui mérite d’être étudiée. Pour le service informatique qui fournit une application critique, la disponibilité est importante. Même si seulement 20 utilisateurs l’utilisent pendant les heures de bureau normales, quand cela fournit un avantage concurrentiel, il est important de maintenir la disponibilité par des arrêts prévus. Lorsque vous avez un lancement de produit, et votre crédibilité est en jeu autant que vos revenus, vous ne mettez pas le panier avant le cheval lorsque vous vous protégez contre les pannes matérielles.
Il existe de nombreuses situations où la disponibilité est une qualité de système importante. Regardez à quel point il est commun pour un cluster Web multi-serveur d’héberger un site Web. Avant de pouvoir ajouter un deuxième serveur Web, vous devez d’abord résoudre un petit ensemble de problèmes connus. Les sessions utilisateur doivent être gérées correctement. Cependant, les clusters de serveurs Web sont utiles pour plus de gestion de la charge de trafic élevé. Ils sont également bénéfiques car nous savons que le matériel va échouer, et nous voulons maintenir le service pendant la panne. Nous pouvons ajouter un autre serveur web car il n’est ni coûteux ni difficile, et il améliore la disponibilité. Avec l’avènement de systèmes conçus pour fournir une disponibilité de base de données plus élevée, pas coûteuse, la disponibilité devient intéressante pour les projets moins critiques.
Éviter le battage médiatique sur le SimpleDB
Il existe de nombreux scénarios d’application où SimpleDB est une option intéressante. Cela dit, certaines personnes ont surestimé les avantages de l’utilisation de SimpleDB spécifiquement et des bases de données NoSQL hébergées en général. Le raisonnement semble être que les services fonctionnant sur l’infrastructure d’entreprises comme Amazon, Google ou Microsoft auront sans doute une évolutivité automatique presque illimitée. Il n’y a rien de mal à l’enthousiasme pour les produits et les services que vous aimez, cependant, il est bon de baser cet enthousiasme sur la réalité. Ne vous laissez pas berner en pensant que l’une de ces nouvelles bases de données va être une panacée. Assurez-vous de vous renseigner sur les avantages et les inconvénients de chaque solution que vous évaluez. La majorité des services dans cet espace ont un niveau d’utilisation gratuit, et toutes les alternatives opensource sont complètement libres à utiliser.
Profitez-en et testez-les par vous-même. Nous vivons une période incroyable dans l’histoire où la quantité d’informations disponibles au bout de nos doigts est sans précédent. L’accès aux services Web et aux projets open source est une énorme opportunité. La tragédie est celle à une époque où Il n’a jamais été aussi facile d’acquérir une expérience personnelle avec les nouvelles technologies, trop souvent nous sommes tentés d’adopter les opinions des autres au lieu de prendre le temps de former nos propres opinions. Ne croyez pas le battage médiatique, découvrez par vous-même.
Mettre le DBA hors travail
L’un des objectifs déclarés de SimpleDB est de permettre aux clients d’externaliser le temps et les efforts associés à la gestion d’une base de données à l’échelle du Web. La gestion de la base de données est traditionnellement le monde du DBA. Certaines personnes ont supposé que le fait de préconiser l’utilisation de SimpleDB revient à préconiser un monde où l’importance du DBA diminue. Cependant, ce n’est pas du tout le cas.
Une des choses qui sont venues de la popularité répandue de EC2 a été un changement dans le rôle des administrateurs système. Ce que nous avons trouvé est que la gestion des instances virtuelles EC2 représente moins de travail que la gestion d’une instance de serveur physique. Cependant, le résultat n’a pas été une vague de licenciements de l’administrateur du système. Au lieu de cela, le résultat a été que les administrateurs système peuvent devenir plus productifs en gérant un plus grand nombre de serveurs qu’ils ne le pourraient autrement. La facilité d’acquisition et le faible coût d’acquisition et de libération de la puissance de calcul ont conduit dans de nombreux cas à utilisation plus grande et plus dynamique des serveurs. En d’autres termes, les organisations utilisent davantage d’instances de serveur car les différents niveaux de l’organisation peuvent les gérer, du point de vue du coût, du risque et de la main-d’œuvre.
SimpleDB et ses cohortes semblent faciliter un changement similaire mais à plus petite échelle. Premièrement, SimpleDB a une applicabilité moins générale que EC2. C’est une solution appropriée pour un ensemble beaucoup plus petit de problèmes. AWS préconise entièrement l’utilisation des produits de base de données relationnels existants. SimpleDB est une option supplémentaire, pas un remplacement. De plus, SimpleDB trouve un bon usage dans certains domaines où une base de données relationnelle pourrait ne pas être normalement utilisée, comme dans le cas du stockage de données de session d’utilisateur Web. En outre, pour les projets qui choisissent d’utiliser SimpleDB à la place ou avec une base de données relationnelle, cela ne signifie pas qu’il n’y a pas de rôle pour l’administrateur de la base de données. Certaines tâches restent similaires à EC2, ce qui peut augmenter la capacité des départements informatiques à créer des solutions.
Esquiver des copies de C.J. Date
Il y a des puristes de bases de données qui essaient de tout cœur de dissuader les gens d’utiliser n’importe quel type de base de données non relationnelle par principe. Non seulement cela, mais ils font également de grands efforts pour préconiser l’utilisation appropriée des bases de données relationnelles et déplorent le fait qu’aucun produit de base de données actuel n’implémente correctement le modèle relationnel. Ayant trouvé le paradigme du vrai stockage de données, ils croient que le modèle relationnel est « le bon » et le seul qui durera. Les puristes ne se trompent pas dans leur appréciation du modèle relationnel et du SQL. Le modèle relationnel est la pierre angulaire du domaine de la base de données, et plus que cela, une contribution inestimable au monde de l’informatique. C’est l’une des deux meilleures choses qui sortaient de 1969. Inventé par un mathématicien et considéré comme une branche des mathématiques elle-même, il y a une rigueur théorique solide qui sous-tend ses principes. Même si ce n’est pas une branche complète ou terminée, à ce jour, le travail a été solide.
Le monde des mathématiques et de la recherche académique est un endroit intéressant. Lorsque vous y avez passé une grande partie de votre vie et de votre carrière, vous êtes hautement qualifié pour faire des commentaires sur des sujets tels que la correction et la prévisibilité. Quelqu’un qui les tient en haute estime ne dit rien sur votre capacité à offrir de la valeur aux utilisateurs. Il est clair que la modélisation “correcte” de vos données peut fournir des avantages mesurables et que les erreurs dans votre modèle peuvent conduire à certaines classes de problèmes. Cependant, vous pouvez toujours fournir une valeur significative pour l’utilisateur avec un modèle défectueux, et l’exactitude n’est pas une garantie de succès.
C’est comme un XHTML parfaitement généré qui valide toujours. C’est comme programmer avec un style fonctionnel (dans n’importe quel langage de programmation) qui vous permet de prouver que vos programmes sont corrects. C’est comme si vous mainteniez des tests unitaires qui fournissent une couverture de test de 100% pour chaque ligne de code que vous écrivez. En fait, il y a beaucoup de bonnes choses à dire sur eux. Le problème n’est pas un problème technique, c’est un problème de personnes. C’est quand les gens deviennent hyper-concentrés sur des aspects technologiques étroits à l’exclusion des questions plus larges du but de l’application.
Les gens qui mènent des recherches sur les bases de données et ceux qui prennent le temps d’aider à éduquer l’industrie informatique méritent notre respect. Si vous avez un diplôme en informatique, il est probable que vous avez étudié le travail de C.J. Date dans votre classe de base de données. Parmi les programmeurs professionnels, il n’y a pas de bonne excuse pour ne pas connaître les données et les fondamentaux relationnels. Cependant, la personne qui se trouve dans la rangée suivante de cabines et qui ne fait que donner une critique condescendante à votre projet n’est pas une C.J. Date. En outre, l’utilisateur avec 50 fois votre réputation stackoverflow.com qui se moque de la prémisse de vos questions sans fournir de suggestions utiles n’est pas E.F. Codd. Comprendre la théorie est d’une grande importance. Savoir comment offrir de la valeur à vos utilisateurs est d’une plus grande importance. En fin de compte, évitez l’ignorance bruyante et ne laissez personne jeter des copies de C.J. Date sur votre visage.
Autres pièces du puzzle
Dans le monde du cloud computing, il existe un nombre croissant d’entreprises et de services parmi lesquels choisir. Chaque fournisseur de services cherche à aligner ses offres sur une stratégie plus large. Avec Amazon, cette stratégie inclut la mise à disposition de blocs d’infrastructure très basiques permettant aux utilisateurs d’assembler des solutions personnalisées. AWS essaie d’utiliser plusieurs services en rendant les différents services utiles les uns avec les autres et en offrant un transfert de données rapide et gratuit entre les services dans la même région. Cette section décrit trois autres services Web Amazon, ainsi que d’autres façons de les utiliser conjointement avec SimpleDB.
