Le monde a changé – Pourquoi les bases de données n’ont-elles pas été conçues?

Il semble qu’une question qu’un enfant se pose: «Pourquoi les choses sont-elles telles qu’elles sont?»

Il est tentant de répondre «parce que c’est ainsi que les choses ont toujours été». Mais ce serait une erreur. Chaque outil, système et pratique que nous rencontrons a été conçu à un moment donné. Ils ont été fabriqués de manière particulière pour des raisons particulières. Et ces conceptions persistent souvent comme des reliques longtemps après que la justification derrière elles ait disparu. Ils vivent – parfois pour le meilleur, parfois pour le pire.

Un exemple célèbre est le clavier QWERTY, conçu par l’inventeur Christopher Latham Sholes dans les années 1870. Selon le récit commun, l’intention de Latham avec la disposition QWERTY n’était pas de rendre les dactylographes plus rapides mais de les ralentir, car les leviers des premières machines à écrire étaient susceptibles de se coincer. D’une certaine manière, c’était une optimisation. Une dactylo plus lente qui n’a jamais bloqué produirait plus qu’une dactylo plus rapide qui le faisait.

Les nouvelles générations de machines à écrire ont rapidement éliminé le brouillage qui affectait les modèles précédents. Mais l’ancienne disposition QWERTY est restée dominante au fil des ans malgré les efforts d’innombrables réformateurs potentiels.

C’est un exemple classique d’effet de réseau au travail. Une fois qu’un nombre suffisant de personnes ont adopté QWERTY, leurs habitudes se sont renforcées. Les dactylographes attendaient QWERTY, et les fabricants ont fabriqué plus de claviers QWERTY pour répondre à la demande. Plus les fabricants de claviers QWERTY créaient, plus les gens apprenaient à taper sur un clavier QWERTY et plus l’effet réseau devenait fort.

La psychologie a également joué un rôle. Nous sommes prêts à aimer les choses familières. Des dictons comme «mieux vaut le diable que tu connais» et «si ce n’est pas cassé, ne le répare pas», reflètent un principe appelé effet de simple exposition, qui déclare que nous avons tendance à être attirés par des choses que nous avons vécues auparavant simplement parce que nous les avons vécus. Les chercheurs ont trouvé que ce principe s’étend à tous les aspects de la vie: les formes que nous trouvons attrayantes, le discours que nous trouvons agréable, la géographie que nous trouvons confortable. Le clavier sur lequel nous aimons taper.

À cette liste, j’ajouterais les conceptions de logiciels que nous utilisons pour créer des applications. Le logiciel est flexible. Il doit évoluer avec le temps. Mais ce n’est pas toujours le cas. Nous sommes toujours en train de concevoir une infrastructure pour le matériel qui existait il y a des décennies, et à certains endroits, la tension commence à se manifester.

La montée et la chute de Hadoop

Hadoop offre un bon exemple de la façon dont ce processus se déroule. Hadoop, vous vous en souvenez peut-être, est un framework open-source pour l’informatique distribuée basé sur des livres blancs publiés par Google au début des années 2000. À l’époque, la RAM était relativement chère, les disques magnétiques étaient le principal support de stockage, la bande passante du réseau était limitée, les fichiers et les ensembles de données étaient volumineux et il était plus efficace d’apporter le calcul aux données que l’inverse. En plus de cela, Hadoop s’attendait à ce que les serveurs vivent dans un certain endroit – dans un rack ou un centre de données particulier.

Une innovation clé de Hadoop a été l’utilisation de matériel de base plutôt que de serveurs spécialisés de niveau entreprise. Cela reste la règle aujourd’hui. Mais entre le moment où Hadoop a été conçu et le moment où il a été déployé dans des applications du monde réel, d’autres «faits sur le terrain» ont changé. Les disques rotatifs ont cédé la place à la mémoire flash SSD. Le prix de la RAM a diminué et la capacité de la RAM a augmenté de façon exponentielle. Les serveurs dédiés ont été remplacés par des instances virtualisées. Débit réseau étendu. Les logiciels ont commencé à migrer vers le cloud.

Pour donner une idée du rythme du changement, en 2003, un serveur typique se serait vanté de 2 Go de RAM et d’un disque dur de 50 Go fonctionnant à 100 Mo / s, et la connexion réseau pouvait transférer 1 Go / s. En 2013, lorsque Hadoop est arrivé sur le marché, le serveur disposerait de 32 Go de RAM, d’un disque dur de 2 To transférant des données à 150 Mo / s et d’un réseau capable de déplacer 10 Gb / s.

Hadoop a été conçu pour un monde qui n’existait plus, et son architecture était déjà obsolète au moment de sa mise sur le marché. Les développeurs l’ont rapidement laissé derrière eux et sont passés à Spark (2009), Impala (2013), Presto (2013) à la place. En peu de temps, Hadoop a engendré plusieurs entreprises publiques et a reçu une presse à bout de souffle. Il a eu un impact substantiel – quoique bref – sur l’industrie de la technologie, même si au moment où il était le plus célèbre, il était déjà obsolète.

Hadoop a été conçu, développé et abandonné en une décennie alors que le matériel évoluait. Il peut donc sembler incroyable qu’un logiciel puisse durer cinquante ans sans changement significatif, et qu’un design conçu à l’ère des ordinateurs centraux et des moniteurs à écran vert puisse encore être avec nous aujourd’hui. Pourtant, c’est exactement ce que nous voyons avec les bases de données relationnelles.

L’étrange persistance de RDMBS

En particulier, la persistance est avec le système de gestion de base de données relationnelle, ou RDBMS pour faire court. Selon les normes technologiques, la conception des SGBDR est assez ancienne, beaucoup plus ancienne que Hadoop, originaire des années 1970 et 1980. La base de données relationnelle est antérieure à Internet. Cela vient d’une époque antérieure à la mise en réseau généralisée, avant le stockage bon marché, avant la possibilité de répartir les charges de travail sur plusieurs machines, avant l’utilisation généralisée des machines virtuelles et avant le cloud.

Pour mettre l’ère du SGBDR en perspective, le populaire open source Postgres est plus ancien que le CD-ROM, sorti à l’origine en 1995. Et Postgres est construit sur un projet qui a débuté en 1986, à peu près. Donc, cette conception est vraiment ancienne. Les idées derrière cela avaient du sens à l’époque, mais beaucoup de choses ont changé depuis, y compris le matériel, les cas d’utilisation et la topologie même du réseau,

Ici encore, la conception de base du SGBDR suppose que le débit est faible, que la RAM est chère et que les grands disques sont d’un coût prohibitif et lents.

Compte tenu de ces facteurs, les concepteurs de RDBM sont arrivés à certaines conclusions. Ils ont décidé que le stockage et le calcul devaient être concentrés en un seul endroit avec du matériel spécialisé et une grande quantité de RAM. Ils ont également réalisé qu’il serait plus efficace pour le client de communiquer avec un serveur distant que de stocker et de traiter les résultats localement.

Les architectures SGBDR incarnent encore aujourd’hui ces anciennes hypothèses sur le matériel sous-jacent. Le problème est que ces hypothèses ne sont plus vraies. La RAM est moins chère que quiconque dans les années 1960 aurait pu l’imaginer. Les SSD Flash sont peu coûteux et incroyablement réactifs, avec une latence d’environ 50 microsecondes, contre environ 10 millisecondes pour les anciens disques rotatifs. La latence du réseau n’a pas autant changé – toujours environ 1 milliseconde – mais la bande passante est 100 fois supérieure.

Le résultat est que même maintenant, à l’ère des conteneurs, des microservices et du cloud, la plupart des architectures SGBDR traitent le cloud comme un centre de données virtuel. Et ce n’est pas seulement un charmant rappel du passé. Cela a de graves implications sur le coût et les performances de la base de données. Les deux sont bien pires qu’ils ne devraient l’être car ils sont soumis à des décisions de conception prises il y a 50 ans à l’ère du mainframe.

Hypothèse obsolète: les bases de données ont besoin d’un stockage fiable

L’une des raisons pour lesquelles les bases de données relationnelles sont plus lentes que leurs homologues NoSQL est qu’elles investissent massivement dans la protection des données. Par exemple, ils évitent la mise en cache sur la couche disque et utilisent la sémantique ACID, écrivant immédiatement sur le disque et conservant les autres requêtes jusqu’à ce que la requête actuelle soit terminée. L’hypothèse sous-jacente est que, avec ces précautions en place, si des problèmes surviennent, l’administrateur peut toujours confier le disque à des services d’investigation et récupérer les données manquantes.

Mais il n’y en a guère besoin maintenant – du moins avec les bases de données fonctionnant dans le cloud. Prenons l’exemple d’Amazon Web Services. Son système standard Elastic Block Storage effectue des sauvegardes automatiquement et se réplique librement. Les architectures SGBDR traditionnelles supposent qu’elles s’exécutent sur un seul serveur avec un seul point de défaillance de stockage, elles se donnent donc beaucoup de mal pour garantir que les données sont stockées correctement. Mais lorsque vous exécutez plusieurs serveurs dans le cloud – comme vous le faites – s’il y a un problème avec l’un, vous basculez simplement vers l’un des serveurs sains.

Les SGBDR font de grands efforts pour soutenir la durabilité des données. Mais avec la préférence moderne pour le basculement instantané, tout cet effort est gaspillé. Ces jours-ci, vous basculerez vers un serveur répliqué au lieu d’attendre un jour pour remettre en ligne celui qui s’est écrasé. Pourtant, le SGBDR persiste à placer la redondance au-dessus de la redondance. Les exigences commerciales et techniques exigent souvent cette capacité même si elle n’est plus nécessaire – un bon exemple de la façon dont les pratiques et les attentes peuvent renforcer des modèles de conception obsolètes.

Hypothèse obsolète: votre stockage est plus lent que votre réseau

Le modèle client / serveur avait beaucoup de sens à l’ère pré-cloud. Si votre réseau était relativement rapide (ce qui était le cas) et votre disque était relativement lent (ce qui était également le cas), il était préférable d’exécuter des données à chaud sur un serveur spécialisé et dérouté qui recevait des requêtes de clients distants.

Pour cette raison, les bases de données relationnelles ont initialement supposé qu’elles avaient des disques physiques fiables attachés. Mais une fois que cette équation a changé et que les disques SSD locaux pouvaient trouver des données plus rapidement qu’elles ne pouvaient être déplacées sur le réseau, il était plus logique que les applications lisent les données localement. Mais pour le moment, nous ne pouvons pas faire cela car ce n’est pas ainsi que les bases de données fonctionnent.

Cela rend très difficile la mise à l’échelle du SGBDR, même avec des ensembles de données relativement petits, et rend les performances avec de grands ensembles de données bien pires qu’elles ne le seraient avec des disques locaux. Cela rend les solutions plus complexes et plus coûteuses, par exemple en exigeant une couche de mise en cache pour fournir la vitesse qui pourrait être obtenue moins cher et plus facile avec un stockage local rapide.

Hypothèse obsolète: la RAM est rare

La RAM était très chère. Seuls les serveurs spécialisés en avaient beaucoup, c’est donc ce sur quoi les bases de données fonctionnaient. Une grande partie de la conception SGBDR classique tournait autour du déplacement de données entre le disque et la RAM.

Mais là encore, le nuage en fait un point discutable. AWS vous offre d’énormes quantités de RAM pour une bouchée de pain. Mais la plupart des personnes exécutant des bases de données traditionnelles ne peuvent pas réellement l’utiliser. Il n’est pas rare de voir des serveurs d’applications avec 8 Go de RAM, alors que le logiciel qui s’exécute sur eux ne peut accéder qu’à 1 Go, ce qui signifie qu’environ 90% de la capacité est gaspillée.

Cela compte car vous pouvez faire beaucoup avec la RAM. Les bases de données ne stockent pas que des données. Ils font également des travaux de traitement. Si vous avez beaucoup de RAM sur le client, vous pouvez l’utiliser pour la mise en cache, ou vous pouvez l’utiliser pour contenir des répliques, ce qui peut effectuer une grande partie du traitement normalement effectué côté serveur. Mais vous ne faites rien de tout cela pour le moment car cela viole la conception du SGBDR.

Comment (et pourquoi) briser une relique

Économiser de l’énergie nécessite de l’énergie. Mais les développeurs de logiciels choisissent souvent de ne pas le dépenser. Après tout, comme aimait à le dire l’inventeur de Perl, la paresse est l’une des vertus du grand programmeur. Nous préférons nous appuyer sur les connaissances existantes plutôt que d’inventer de nouveaux systèmes à partir de rien.

Mais il y a un coût à prendre les principes de conception pour acquis, même s’il ne s’agit pas d’une technologie aussi fondamentale que le SGBDR. Nous aimons penser que la technologie évolue toujours. Le SGBDR nous rappelle que certains modèles persistent en raison de l’inertie. Ils deviennent si familiers que nous ne les voyons plus. Ce sont des reliques qui se cachent à la vue de tous.

Une fois que vous les avez repérés, la question est de savoir quoi faire à leur sujet. Certaines choses persistent pour une raison. La maturité compte. Vous devez mettre le chapeau de votre comptable et faire une analyse de retour sur investissement rigoureuse. Si votre conception est basée sur des hypothèses dépassées, cela vous retient-il? Cela vous coûte-t-il plus d’argent qu’il n’en faudrait pour se moderniser? Pourriez-vous réellement obtenir un rendement positif?

C’est une réelle possibilité. Amazon a créé un tout nouveau produit – la base de données Aurora – en repensant les hypothèses fondamentales derrière l’abstraction du stockage SGBDR.

Vous n’irez peut-être pas aussi loin. Mais là où il y a au moins une perspective de retour sur investissement positif, c’est un bon signe que le changement est stratégique. Et c’est votre meilleur signe que démolir votre propre design vaut le coût de la construction de quelque chose de nouveau à sa place.

Avishai Ish-Shalom est l’avocat des développeurs chez ScyllaDB.