Les concepts sous le capot (partie 2)

Dans la partie 1, L’essor des bases de données sans serveur, de la série « Bases de données pour les développeurs front-end », nous avons parlé des obstacles et des pièges de la mise à l’échelle et de la maintenance de vos bases de données. Nous sommes passés d’alternatives plus simples et spécialisées comme les systèmes de gestion de contenu et les feuilles de calcul aux bases de données auto-hébergées et, enfin, aux bases de données sans serveur.

Aujourd’hui, nous allons plus loin dans le terrier du lapin. Nous explorerons des concepts pour vous permettre d’avoir votre propre opinion sur les types de bases de données qui répondent à vos besoins spécifiques. Et c’est important de souligner dès le départ : il n’y a pas de bonne réponse. Chaque base de données comporte son propre ensemble de compromis et d’avantages. Si quelque chose ressemble à une solution « taille unique », soyez prudent : vous manquez peut-être quelque chose !

Anatomie d’une base de données

Avant de commencer, il est important de souligner que ce que nous appelons vaguement des « bases de données » sont en fait « Systèmes de gestion de base de données (SGBD).” Un SGBD est un logiciel qui permet à l’utilisateur d’écrire, de lire, de supprimer ou de mettre à jour de manière plus ergonomique des informations dans un ensemble de données donné. Pour cette série, nous nous concentrerons principalement sur les SGBD relationnels et non relationnels. Il existe de nombreux autres types, tous classés en fonction de leurs structures de données, mais les relations relationnelles et non relationnelles sont les plus courantes pour le développement Web à tous égards.

Tous les deux Relationnel (R) et SGBD non relationnel (NR) ont des termes différents pour les parties qui les composent. Ces composants sont presque interchangeables dans leur définition, et c’est pourquoi vous pouvez généralement entendre un développeur se référer à un document (terme NR) en tant que « table », qui est sa structure relationnelle équivalente. N’ayez pas peur de les confondre; elles apparaissent assez souvent pour que cette surcharge cognitive disparaisse rapidement à l’usage. De plus, une fois que vous vous serez familiarisé avec les différences de chaque structure de données, vous vous rendrez compte qu’elles sont probablement ne devrait pas être utilisés de manière interchangeable car il existe des différences entre eux. Mais pour l’instant, et par souci de simplicité, concentrons-nous sur les similitudes :

• Schéma
  C’est la description de la base de données (comme un plan), décrivant le paysage de la base de données dans une langue prise en charge. Ceci est requis par les bases de données relationnelles, et bien que non requis par les SGBD non relationnels, de nombreuses interfaces offrent la possibilité de le définir également.
• Tableaux (R/NR), Collections (NR)
  C’est la structure de données logique, non triée. Un exemple pertinent de ceci serait une table de feuille de calcul ou un groupe (collection) d’objets JSON.
• Bases de données (R/NR)
  C’est le regroupement logique des données. Vous regroupez vos tables dans des bases de données (base de données utilisateurs, bases de données factures) et vos documents dans des index en fonction de la manière dont vous comptez les interroger.

Clés et colonnes

Pour utiliser un exemple plus familier, prenons un objet JSON comme exemple :

{
  "name": "Atila"
  "role": "DX Engineer at Xata"
}

Étant donné que JSON, une colonne serait représentée par la paire clé-valeur (colonne Nom a évaluer « Atila »), et la clé a la même signification que la spécification JSON, clé Nom accédera à la valeur « Atila ».

Une table comporte des colonnes et le nom de chaque colonne détermine la clé avec laquelle vous pouvez accéder à une valeur dans un enregistrement.

En plus de la définition ci-dessus, il existe des types spéciaux de clés. Ces clés jouent un rôle particulier dans le schéma de votre base de données et dans la manière dont vous interagirez avec vos données. Définissez-les judicieusement : toute modification minime peut être considérée comme une modification radicale de votre couche de données.

• Clés uniques (Royaume-Uni)
  Les clés qui sont uniques entre les enregistrements d’une table. Ils acceptent également null.
• Clés primaires (PK)
  C’est un type spécial de clé unique. Il ne peut y avoir qu’une seule clé primaire par table, et elle ne peut jamais être null (Les clés primaires sont toujours considérées required). Les clés primaires sont également indexées par défaut, ce qui facilite les requêtes qui souhaitent filtrer sur la valeur.
• Clés étrangères (FK)
  Lorsqu’il existe une relation entre les tables, les clés sont représentées comme des clés étrangères à la table superflue.

Exemple de clé étrangère : si chaque author dans un auteurs le tableau a posts (et des postes est un autre tableau), post.title sera un FK à auteurs. Et la jonction entre auteurs et des postes s’appelle un relation.

Cartographier votre SGBD

Une fois que vous avez examiné les différentes structures de données et choisi votre SGBD, vous êtes prêt à établir la première connexion entre votre couche de données et votre couche d’application. Et soudain, vous avez remarqué qu’il n’est pas très simple d’apporter des données de la base de données à votre côté client (ou même à votre API côté serveur dans certains cas).

Voici venir ORM (Object Relational Mapping) et ODM (Object Document Mapping) pour faciliter votre expérience de développeur. prisme est probablement l’ORM le plus utilisé à l’heure actuelle, tandis que Mangouste a la plus grande base d’utilisateurs ODM. Il est important de noter qu’ils ne sont pas obligatoires pour se connecter aux bases de données. Néanmoins, si vous gardez un œil sur la façon dont ils construisent vos requêtes (certains cas particuliers peuvent présenter des problèmes de performances du fait de l’abstraction), ils ont tendance à vous faciliter la vie et à récupérer ou écrire des données beaucoup plus ergonomiques.

En ce qui concerne les bases de données sans serveur, leur besoin devient un peu plus discutable. Et c’est parce que beaucoup de ces bases de données fournissent aux utilisateurs un kit de développement logiciel (SDK) officiellement pris en charge. Votre kilométrage variera en fonction du SDK, mais ils ont tendance à avoir un grand chevauchement de fonctionnalités avec les ORM et les ODM, en particulier sur les bases de données qui conserveront la couche de données derrière une API (Voler, par exemple). Ainsi, vous n’aurez plus à vous soucier de la traduction de vos requêtes, et vous pourrez exiger une ergonomie équivalente entre le SDK et un ORM.

Concepts communs

Dans cette partie de notre série, nous apprenons ce qu’il faut rechercher lors du choix de la pile pour nos couches de données. Il est essentiel de comprendre les concepts communs autour de la maintenance et du choix d’un SGBD (à partir de maintenant, nous les appelons à nouveau des « bases de données » pour rester cohérents avec le reste du monde).

Les sections suivantes n’iront pas si loin que vous vous lancez et trouvez un emploi d’administrateur de base de données (DBA), mais j’espère qu’elles vous offriront suffisamment de munitions pour engager une conversation avec des experts et identifier la meilleure solution pour vos cas d’utilisation. Ces concepts sont courants pour chaque type de couche de données, d’une feuille de calcul à une base de données auto-hébergée et même à une base de données sans serveur. Ce qui variera, c’est la façon dont chaque solution équilibrera les variables entrelacées dans ces paradigmes.

Les concepts les plus importants, pour commencer, sont la cohérence, la disponibilité et la tolérance de partition. Ils sont mieux compris s’ils sont présentés ensemble, car l’équilibre entre eux déterminera la prévisibilité de vos données dans différents contextes.

Théorème CAP

Ce théorème décrit la relation entre 3 composants dans un système distribué : cohérence, disponibilité et tolérance de partition (CAP). La conclusion générale est facile à résumer : tout système ne peut envisager que 2 de ces composants en même temps. Bien qu’il ne s’agisse que d’une simple phrase, cette idée nécessite un peu de déballage.

Consistance (C)

Dans les contraintes du théorème CAP, la « cohérence » fait directement référence aux données. Lorsque différents clients font la même demande, ils obtiendront la même réponse. Lorsqu’une demande écrite est acceptée et confirmée, tous les utilisateurs auront accès à ces informations mises à jour en même temps.

Disponibilité (A)

Chaque demande recevra une réponse avec des données. Aucune erreur. Cependant, cela ne donne aucune promesse quant à savoir si les données sont à jour ou non. Selon que cela est associé à la cohérence © ou à la tolérance de partition (P), vous obtiendrez un comportement différent.

Tolérance de partition (P)

Une « partition » est lorsque la connexion entre deux nœuds d’un système est interrompue. Le théorème CAP décrit essentiellement comment un système tolérera la partition : imposer la disponibilité (système AP) ou imposer la cohérence (système CP). Quelle que soit la taille d’un système, des partitions peuvent toujours se produire. Il n’existe donc pas de système d’AC.

Pour fournir un exemple plus graphique de chaque système, nous pouvons considérer :

• Système AP
  Un autre nœud a une copie des données. L’utilisateur obtiendra des informations en retour mais sans promesse qu’elles soient 100% correctes (à jour). Il est couramment mis en œuvre avec DynamoDB, Cassandreetc.
• Système CP
  Retourner une erreur et accepter la transaction est impossible. Il est généralement implémenté avec des bases de données partitionnées traditionnelles, Les autrespar exemple.

Bien que populaire et très souvent mentionné, le théorème CAP peut être considéré comme incomplet car il ne prend pas en compte les situations au-delà de la partition du réseau. Surtout aujourd’hui, avec les réseaux de diffusion de contenu (CDN) à haute disponibilité et la connectivité extrême, il est crucial de prendre en compte la latence et les aspects plus profonds de la cohérence (linéarisabilité et sérialisabilité).

Confusion de cohérence

C’est drôle comme « cohérence » est un terme qui change de sens en fonction du contexte. Ainsi, dans le théorème CAP, comme nous venons de le voir, tout est question de données et de la fiabilité avec laquelle un utilisateur obtiendra la même réponse à la même requête, quelle que soit la partition qu’il atteint. Une fois que nous nous éloignons de notre propre système, une nouvelle perspective nous amène à nous demander : « comment régulièrement gérerons-nous des opérations simultanées ? » Et juste comme ça, le théorème CAP ne décrit pas suffisamment les subtilités du fonctionnement à grande échelle.

Il y a une troisième signification de « cohérence », que nous garderons pour plus tard ; il fait partie d’un autre acronyme (ACID). Si le dernier paragraphe vous a laissé perplexe, je ne saurais trop vous recommander « Réflexions incohérentes sur la cohérence de la base de données » par Alex DeBrie.

Théorème PACELC

Les trois premières lettres sont les mêmes que CAP, juste réorganisées. La « cohérence » dans le théorème PACELC va plus loin que dans le théorème CAP. Il suit le Modèle de cohérence, qui détermine le contrat entre un magasin de données et un système. Pour rendre les choses moins compliquées, considérez le PACELC comme un extension du théorème CAP.

En plus de demander au développeur d’élaborer une stratégie pour l’événement d’une partition de réseau, le PACELC considère également ce qui se passe lorsque le système n’a pas de partitions (réseau sain).

CEL représente Sinon : latence ou cohérence ?

• Latence: Pouvez-vous accepter une réponse obsolète occasionnelle pour des raisons de performance ?
• Cohérence:
  • Linéarisabilité : accepterez-vous une latence plus élevée pour synchroniser les données dans tous les nœuds d’un réseau avant de considérer la transaction comme effectuée ?
  • Sérialisabilité : En cas de transactions simultanées sur les mêmes données, les traiterez-vous en parallèle ou en file d’attente ?

Pour cette raison, je considère que le PACELC porte un meilleur modèle mental pour cette nouvelle ère de bases de données sans serveur. Lorsqu’il est sain, ce n’est pas une classification scalaire « AP » ou « CP » ; il accepte un spectre car la latence peut être élevée ou non, et la cohérence peut également avoir différents niveaux.

Une fois que nous commencerons à parler des types de bases de données et de leurs structures de données et des garanties que chacune peut donner, nous parlerons également d’un peu d’architecture système et de la façon dont votre architecture peut réduire les compromis lorsque même en appliquant la cohérence, vous pouvez vous efforcer d’obtenir un faible scénario de latence.

À la prochaine

Avec cela, je pense que nous sommes prêts à commencer à affiner nos discussions sur les différences entre chaque type de base de données. De plus, il est possible de discuter et de niveler les attentes sur chaque solution prise et d’analyser les architectures individuellement. Désormais, nous nous concentrerons sur les bases de données relationnelles et non relationnelles.

Dans quelques jours, sur notre saison finale, nous couvrirons les différences entre NoSQL et SQL : quelles garanties attendre, ce que cela signifie pour vos données et comment cela affecte le flux de travail de développement. Ensuite, nous serons prêts à passer directement aux bases de données sans serveur et à quoi nous attendre à l’avenir. Je ne peux pas attendre !

Comme d’habitude, n’hésitez pas à tendre la main vers moi avec des commentaires, des questions et/ou des demandes pour la partie suivante.

(vf, yk, il)