Travailler avec une base de données depuis une application

Au début, je décrirai certains problèmes et fonctionnalités lors de l'utilisation de la base de données, je montrerai des trous dans les abstractions. Ensuite, nous analyserons une abstraction plus simple basée sur l'immunité.

Le lecteur est censé être un peu familier avec les schémas Active Record , Data Maper , Identity Map et Unit of Work .

Les problèmes et les solutions sont envisagés dans le contexte de projets suffisamment importants qui ne peuvent pas être jetés et réécrits rapidement.

Carte d'identité

Le premier problème est le problème du maintien de l'identité. L'identité est quelque chose qui identifie de manière unique une entité. Dans la base de données, il s'agit de la clé primaire et en mémoire, du lien (pointeur). C'est bien lorsque les liens pointent vers un seul objet.

Pour les bibliothèques Ruby ActiveRecord , ce n'est pas le cas:

post_a = Post.find 1 post_b = Post.find 1 post_a.object_id != post_b.object_id # true post_a.title = "foo" post_b.title != "foo" # true 

C'est-à-dire on obtient 2 références à 2 objets différents en mémoire.

Ainsi, nous pouvons perdre des modifications si nous commençons par inadvertance à travailler avec la même entité, mais représentée par des objets différents.

Hibernate a une session, en fait un cache de premier niveau qui stocke le mappage d'un identifiant d'entité à un objet en mémoire. Si nous demandons à nouveau la même entité, nous obtiendrons un lien vers un objet existant. C'est-à-dire Hibernate implémente le modèle de carte d'identité .

Transactions longues

Mais que se passe-t-il si nous ne sélectionnons pas par identifiant? Pour éviter que l'état des objets et l'état de la base de données ne soient désynchronisés, Hibernate vider avant de demander une sélection.
c'est-à-dire vide les objets sales dans la base de données afin que la demande lise les données convenues.

Cette approche vous oblige à garder la transaction de base de données ouverte pendant que la transaction commerciale est en cours.
Si la transaction commerciale est longue, le processus responsable de la connexion dans la base de données elle-même est également inactif. Par exemple, cela peut se produire si une transaction commerciale demande des données sur le réseau ou effectue des calculs complexes.

N + 1

Le plus gros «trou» dans l'abstraction ORM est peut-être le problème de requête N + 1.

Exemple sur ruby ​​pour la bibliothèque ActiveRecord:

 posts = Post.all # select * from posts posts.each do |post| like = post.likes.order(id: :desc).first # SELECT * FROM likes WHERE post_id = ? ORDER BY id DESC LIMIT 1 # ... end 

ORM conduit le programmeur à l'idée qu'il travaille simplement avec des objets en mémoire. Mais cela fonctionne avec un service disponible sur le réseau, et sur l'établissement de connexions et de transfert de données
cela prend du temps. Même si la requête est exécutée 50 ms, 20 requêtes seront exécutées pendant une seconde.

Données supplémentaires

Dites pour éviter le problème N + 1 décrit ci-dessus, vous écrivez
demande :

 SELECT * FROM posts JOIN LATERAL ( SELECT * FROM likes WHERE post_id = posts.id ORDER BY likes.id DESC LIMIT 1 ) as last_like ON true; 

C'est-à-dire en plus des attributs du post, tous les attributs du dernier like sont également sélectionnés. À quelle entité ces données correspondent-elles? Dans ce cas, vous pouvez renvoyer un couple de la poste et aimer, car le résultat contient tous les attributs nécessaires.

Mais que se passe-t-il si nous sélectionnons seulement une partie des champs, ou des champs sélectionnés qui ne sont pas dans le modèle, par exemple, le nombre de publications aiment? Doivent-ils être mappés sur des entités? Peut-être ne leur laisser que des données?

État et identité

Considérez le code js:

 const alice = { id: 0, name: 'Alice' }; 

Ici, la référence à l'objet a reçu le nom d' alice . Parce que c'est une constante, alors il n'y a aucun moyen d'appeler Alice un autre objet. Dans le même temps, l'objet lui-même est resté mutable.

Par exemple, nous pouvons attribuer un identifiant existant:

 const bob = { id: 1, name: 'Bob' }; alice.id = bob.id; 

Permettez-moi de vous rappeler qu'une entité a 2 identités: un lien et une clé primaire dans la base de données. Et les constantes ne peuvent pas arrêter de créer Alice Bob, même après avoir enregistré.

L'objet, le lien auquel nous avons appelé alice , remplit 2 fonctions: il modélise simultanément l'identité et l'état. Un état est une valeur qui décrit une entité à un moment donné.

Mais que se passe-t-il si nous séparons ces 2 responsabilités et utilisons des structures immuables pour l'État?

 function Ref(initialState, validator) { let state = initialState; this.deref = () => state; this.swap = (updater) => { const newState = updater(state); if (! validator(state, newState) ) throw "Invalid state"; state = newState; return newState; }; } const UserState = Immutable.Record({ id: null, name: '' }); const aliceState = new UserState({id: 0, name: 'Alice'}); const alice = new Ref( aliceState, (oldS, newS) => oldS.id === newS.id ); alice.swap( oldS => oldS.set('name', 'Queen Alice') ); alice.swap( oldS => oldS.set('id', 1) ); // BOOM! 

Ref - un conteneur pour un état immuable, permettant son remplacement contrôlé. Ref modèles de Ref identifient tout comme nous nommons des objets. Nous appelons la Volga, mais à chaque instant, elle a un état immuable différent.

Stockage

Considérez l'API suivante:

 storage.tx( t => { const alice = t.get(0); const bobState = new UserState({id: 1, name: 'Bob'}); const bob = t.create(bobState); alice.swap( oldS => oldS.update('friends', old => old.push(bob.deref.id)) ); }); 

t.get et t.create renvoient une instance de Ref .

Nous ouvrons la transaction commerciale, trouvons Alice par son identifiant, créons Bob et indiquons qu'Alice considère Bob son ami.

L'objet t contrôle la création de ref .

t peut stocker en lui-même le mappage des identifiants d'entité à l'état ref les contenant. C'est-à-dire peut implémenter Identity Map. Dans ce cas, t agit comme un cache; à la demande répétée d'Alice, il n'y aura pas de demande à la base de données.

On peut se souvenir de l'état initial des entités afin de suivre à la fin de la transaction les changements qui doivent être écrits dans la base de données. C'est-à-dire peut mettre en œuvre l' unité de travail . Ou, si le support d'observateur est ajouté à Ref , il devient possible de réinitialiser les modifications apportées à la base de données à chaque modification de ref . Ce sont des approches optimistes et pessimistes pour fixer les changements.

Avec une approche optimiste, vous devez suivre les versions d'état des entités.
Lors de la modification de la base de données, nous devons nous souvenir de la version et lors de la validation des modifications, vérifier que la version de l'entité dans la base de données ne diffère pas de la version initiale. Sinon, vous devez répéter la transaction commerciale. Cette approche permet d'utiliser des opérations d'insertion et de suppression de groupe et des transactions de base de données très courtes, ce qui économise des ressources.

Avec une approche pessimiste, une transaction de base de données est entièrement cohérente avec une transaction commerciale. C'est-à-dire nous sommes obligés de retirer la connexion du pool au moment de la conclusion de la transaction commerciale.

L'API vous permet d'extraire des entités une par une, ce qui n'est pas très optimal. Parce que nous avons implémenté le modèle Identity Map , puis nous pouvons entrer la méthode de preload dans l'API:

 storage.tx( t => { t.preload([0, 1, 2, 3]); const alice = t.get(0); // from cache }); 

Requêtes

Si nous ne voulons pas de transactions longues, nous ne pouvons pas effectuer de sélections par une clé arbitraire, car la mémoire peut contenir des objets sales et la sélection renverra un résultat inattendu.

Nous pouvons utiliser Query et récupérer toutes les données (état) en dehors de la transaction et relire les données pendant la transaction.

 const aliceId = userQuery.findByEmail('alice@mail.com'); storage.tx( t => { const alice = t.getOne(aliceId); }); 

Il y a donc une division des responsabilités. Pour les requêtes, nous pouvons utiliser des moteurs de recherche pour mettre à l'échelle la lecture à l'aide de répliques. Et l'API de stockage fonctionne toujours avec le stockage principal (maître). Naturellement, les répliques contiendront des données obsolètes, la relecture des données dans la transaction résout ce problème.

Commandes

Il existe des situations où une opération peut être effectuée sans lire de données. Par exemple, déduisez des frais mensuels des comptes de tous les clients. Ou insérez et mettez à jour les données (upsert) en cas de conflit.

En cas de problèmes de performances, le bundle de Storage and Query peut être remplacé par une telle commande.

Les communications

Si les entités se réfèrent de manière aléatoire, il est difficile d'assurer la cohérence lors de leur modification. Les relations tentent de simplifier, de rationaliser, d'abandonner inutiles.

Les agrégats sont un moyen d'organiser les relations. Chaque agrégat a une entité racine et des entités imbriquées. Toute entité externe ne peut se référer qu'à la racine de l'agrégat. La racine garantit l'intégrité de l'ensemble de l'unité. Une transaction ne peut pas franchir une frontière d'agrégation; en d'autres termes, l'ensemble de l'agrégat est impliqué dans la transaction.

Un agrégat peut, par exemple, être composé du Carême (racine) et de ses traductions. Ou l'Ordre et ses Positions.

Notre API fonctionne avec des agrégats entiers. Dans le même temps, l'intégrité référentielle entre les agrégats dépend de l'application. L'API ne prend pas en charge le chargement paresseux des liens.
Mais nous pouvons choisir la direction des relations. Considérez la relation un à plusieurs Utilisateur - Publication. Nous pouvons stocker l'ID utilisateur dans la publication, mais sera-t-il pratique? Nous obtiendrons beaucoup plus d'informations si nous stockons un tableau d'identificateurs de publication dans l'utilisateur.

Conclusion

J'ai souligné les problèmes lors de l'utilisation de la base de données, montré la possibilité d'utiliser l'immunité.
Le format de l'article ne permet pas de révéler le sujet en détail.

Si vous êtes intéressé par cette approche, alors faites attention à mon application de livre à partir de zéro , qui décrit la création d'une application Web à partir de zéro en mettant l'accent sur l'architecture. Il comprend SOLID, Clean Architecture, les modèles de travail avec la base de données. Les exemples de code dans le livre et l' application elle-même sont écrits dans le langage Clojure, qui est imprégné des idées d'immunité et de la commodité du traitement des données.