Mon équipe a peur des entités de bases de données relationnelles avec des relations de clés étrangères et je ne comprends pas pourquoi


12

Je suis relativement fraîchement sorti de l'université, donc la plupart de mes connaissances avec les bases de données relationnelles proviennent de mon cours sur les bases de données où tout ce qui n'est pas en BCNF ou 3NF est une parodie. C'est certainement une extrémité de l'extrême, mais mon équipe au travail semble vraiment aller jusqu'au bout.

Dans nos schémas de base de données de microservices, les entités ont rarement plus d'une seule table. Tout ce que vous normalisez généralement dans une autre table est stocké dans une colonne json. S'il est découvert plus tard qu'une des propriétés de ce json doit être interrogée, une nouvelle colonne est ajoutée et les données sont stockées aux deux endroits (oui, dans deux colonnes différentes dans la même table).

Dans de nombreux cas, ces colonnes json ont certainement un avantage. Si vous n'avez jamais besoin d'interroger ces données et si vous n'avez jamais à apporter de modifications unilatérales à ces données (ce que vous ne pouvez évidemment pas prédire), ce n'est pas une mauvaise idée. De plus, beaucoup de nos services ne voient pas de serveur ou sont hébergés sur des machines avec une quantité d'espace disque obscène pour ce dont ils avaient besoin, donc la duplication des données n'est pas un problème majeur. (Bien que j'aimerais généralement éviter la philosophie)

Actuellement, nous construisons un service qui correspond aux règles en fonction d'un ensemble de conditions dont ils sont propriétaires, puis exécute un ensemble d'actions associé à ces règles lorsque les règles sont vraies (par exemple, toutes les conditions sont vraies). Mon équipe secondaire qui construit le plus immédiatement ce service pense qu'il y a un avantage substantiel à normaliser les actions et les conditions loin des règles du schéma. De toute évidence, ces tables conservent des relations de clé étrangère avec l'ID de règle. De notre point de vue, nous pouvons éviter la duplication des données sur les conditions, ce qui nous permet de garantir qu'elles ne sont évaluées qu'une seule fois et il est facile de trouver les conditions et les règles dont nous avons besoin en cas de besoin sans avoir à extraire chaque règle et à effectuer la recherche en mémoire.

Aujourd'hui, en discutant avec l'un de nos principaux ingénieurs, il a tenté de m'éloigner de ce schéma. Essayer de faire valoir de toutes les manières que nous n'en avons pas réellement besoin va causer des problèmes de performances à l'avenir, en faisant référence à un vieux monolithe que nous possédons qui est une parodie de conception. Il a fait référence à ce que nous faisons comme «à l'ancienne» et aux tables plates avec json comme «à la nouvelle façon». Il a soutenu que dans les endroits où je veux l'atomicité, nous n'en avons pas besoin et qu'au lieu de requêtes, nous devrions faire plus de choses en mémoire. Il s'agit d'un principe de conception que nombre de nos services appliquent actuellement. Nous ne prévoyons pas que le volume de nos données augmentera considérablement, ce qui devrait permettre de garder nos requêtes rapides. Ce que nous prévoyons, c'est beaucoup de temps consacré à l'évaluation des règles et à l'exécution des actions.

Je comprends que les bases de données non relationnelles sont devenues plus populaires ces dernières années, mais même lorsque je recherche activement des informations sur les implications des relations avec les clés étrangères en termes de performances, je ne vois pas beaucoup d'informations pour le défendre. Je suppose qu'ils pourraient avoir tendance à introduire des transactions importantes qui peuvent causer des problèmes, mais cela semble être un problème indépendant de la clé étrangère elle-même.

Est-ce ma naïveté? Ou est-ce vraiment quelque chose qui manque à ma sous-équipe et moi? Je n'ai explicitement pas donné d'informations détaillées sur notre problème car je ne cherche pas nécessairement une solution à cela. Étant donné que c'est une tendance commune dans notre grande équipe, je suis vraiment curieux de savoir s'ils sont sur quelque chose avec ça.


La réponse à votre question dans le titre serait "Ils ont peur à cause du vieux monolithe de votre entreprise". Mais le corps de votre question semble demander quelque chose de complètement différent, c'est-à-dire "Les clés étrangères introduisent-elles des problèmes de performances?"
Christian Hackl

2
Je me demande quel% d'un SGBDR ils ont construit dans le code "app"
Caleth

Que l'approche soit bonne ou non dépend du type d'application que vous construisez, de ses besoins et de la direction qu'elle prend (exigences, contraintes architecturales) - quelque chose que nous ne pouvons pas vraiment évaluer ici. Quant à NoSQL, il s'agissait de prendre en charge la vendabilité horizontale massive et de reconnaître que toutes les applications ne nécessitent pas les contraintes strictes du SGBDR. Pour en savoir plus, utilisez les 3 meilleures réponses ici comme point de départ (les 2e et 3e vont plus en profondeur).
Filip Milovanović

2
Si je peux offrir des conseils non techniques: atténuez-les un peu. Vous portez beaucoup de jugement («oui, dans deux colonnes différentes dans le même tableau», «parodie de conception») sur un travail où vous n'avez eu aucune implication dans les décisions de conception et le faites à partir d'une position d'expérience minimale réelle . Je ne peux pas dire que vous avez raison ou tort parce que je n'ai pas vu le projet, mais les systèmes ont tendance à être une série de compromis résultant en ce que le produit fini est fonctionnel mais moins que conceptuellement pur. Cela deviendra plus clair à mesure que votre carrière progresse et la prise de ces décisions fait partie de votre travail.
Blrfl

@Blrfl Excellemment mis
Robbie Dee

Réponses:


8

Le mot clé ici pour comprendre d'où vient votre équipe est "microservices". Il serait utile de lire d'abord ce concept, en particulier pour les informations suivantes:

  • Comment les données doivent-elles être stockées?
  • Principes de conception?
  • Comment sont-ils conçus pour évoluer?

Comme pour toute façon relativement nouvelle de faire les choses (et 5 à 10 ans est relativement nouveau en matière d'architecture logicielle), vous constaterez que les idéaux et la réalité sont un peu différents.

L'un des idéaux est que chaque microservice devrait avoir son propre magasin de données. REMARQUE: j'ai dit magasin de données, pas base de données. Dans certains cas, vous souhaitez simplement un moteur de recherche, un stockage d'objets blob ou une simple mise en cache par opposition à une base de données standard. Selon qui vous parlez, cet idéal pourrait même aller dans un magasin de données par instance de microservice!

En fin de compte, lorsque vous parlez de passer à l'échelle Internet, la sécurité et la familiarité des transactions ACID (atomicité, cohérence, isolation et durabilité) ne sont tout simplement pas à l'échelle lorsque vous avez des millions d'utilisateurs sur une base de données. Avec l'avènement de NoSQL, le paradigme s'est davantage déplacé vers BASE (Basiquement disponible, état souple, cohérence éventuelle). ( référence )

La modification du PH de la façon dont vous gérez les données a un impact:

  • Les choses dont la base de données s'occupait pour vous doivent maintenant être gérées dans le code
  • Il est plus facile d'évoluer en lançant plus d'instances de microservices sur un problème que d'ajouter des ressources "infinies" à un serveur
  • Vous augmentez la fiabilité au prix d'une complexité accrue

Je ne peux pas répondre aux détails de votre équipe ni à la taille qu'elle souhaite obtenir, mais en règle générale, vous n'avez pas besoin d'une solution tout ou rien. Je ne vais pas m'asseoir ici et juger si l'équipe fait les bons choix. Je vous donne juste un peu de contexte pour que vous puissiez au moins comprendre d'où ils viennent.


+1 Très bien - il y a certainement beaucoup de subtilités autour des microservices qui signifient qu'il ne s'agit pas seulement d'échanger des bases de données.
Robbie Dee

@RobbieDee, d'accord. Il y a beaucoup de complexité dans ce monde, et tout le monde n'est pas d'accord sur les détails.
Berin Loritsch

Ce devrait être la réponse. Le peu de chaque microservice ayant son propre magasin de données est vraiment le facteur de différenciation. Cela apporte un grand changement dans vos besoins et vos solutions de stockage de données, et un magasin de données conforme à ACID n'est plus autant un avantage qu'auparavant.
Greg Burghardt

7
C'est une bonne réponse, et je l'ai votée. Je voudrais seulement souligner que ce que vous appelez «l'échelle Internet» ne s'applique qu'aux plus grandes entreprises; pour la grande majorité des bases de données et des sites Web d'entreprise (je dirais 95% d'entre eux), les bases de données SQL normalisées "conventionnelles" sont toujours parfaitement viables.
Robert Harvey

@RobertHarvey, je suis entièrement d'accord. J'ai lu plusieurs articles sur les microservices qui spécifient ce que j'ai écrit. Dans nos propres projets, nous utilisons une base de données SQL avec une normalisation et des contraintes appropriées. Cela nuirait au cœur du puriste, mais la réalité est que notre base d'utilisateurs est plutôt petite (des centaines ou des utilisateurs) et la base de données n'a pas été un problème de performance pour nous.
Berin Loritsch

3

OK, n'étant pas l'ingénieur principal du projet, vous devez vraiment suivre ses instructions pour ce projet.

Je vous encourage à travailler sur votre propre conception du système et du prototype qu'il est à la maison afin que vous compreniez tous les compromis. Faites cela pour votre propre éducation et ne le mentionnez au travail que lorsque vous pouvez démontrer des exemples de travail.

D'après mon expérience, certains prétendent que les contraintes entraînent un ralentissement des performances de la base de données. Et oui, ça va, vous devez vérifier ces contraintes. Cependant, c'est un problème beaucoup plus important lorsque la base de données est incohérente et cela vous obligera à écrire du code SQL et davantage de code afin de compenser, augmentant souvent la complexité du système ainsi que le ralentissant.

3nf, une fois effectué de manière appropriée, rendra la base de données plus rapide car une plus grande partie de celle-ci peut être mise en cache car il y a moins de données redondantes stockées. Cependant, dans votre travail actuel, il se peut qu'il n'y ait pas un ensemble de données suffisamment grand pour réellement voir la différence de performances entre une base de données normalisée et une base de données non normalisée.


+1 Excellente idée. Et si les volumes sont trop importants pour une machine de développement, un échantillon de 1 sur N peut souvent aussi fournir de grandes informations.
Robbie Dee

2

Je pense qu'ils ont peur de recréer le même vieux "travestissement" qui était là avant, plutôt que l'intégrité référentielle elle-même.

Il a soutenu que dans les endroits où je veux l'atomicité, nous n'en avons pas besoin ...

Si vous pouvez faire un cas solide (alias exigence non fonctionnelle) pour avoir besoin d'atomicité, alors ils auront besoin d'un bon contre-argument solide pour sortir de le fournir.

... au lieu de requêtes, nous devrions faire plus de choses en mémoire. Il s'agit d'un principe de conception ... Nous ne prévoyons pas que le volume de nos données augmentera considérablement ...

Espérons que vous avez raison. Je dirais qu'il est risqué de s'appuyer sur des données qui restent «suffisamment petites» pour rester performantes.

Quel est également le taux de changement de ces règles? Plus vous avez de duplication, plus vous perdrez de temps (aka argent) à mettre à jour la même chose à plusieurs endroits.


1

Les concepts clés derrière les SGBDR ont plus de 40 ans. À l'époque, le stockage était très coûteux et toute sorte de redondance était désapprouvée. Alors que les concepts derrière les SGBDR sont toujours valables, l'idée de dénormalisation des performances (pour réduire les jointures) est devenue communément acceptée au cours des dernières décennies.

Donc, pour un SGBDR d'une taille donnée, vous avez généralement votre conception logique (sans redondance) et votre conception physique (avec redondance) pour les performances.

Avance rapide jusqu'à aujourd'hui où le stockage est bon marché et les processeurs plus rapides que jamais, certaines de ces pressions de conception ne sont pas si importantes. En fin de compte, c'est une question de jugement de savoir si vous vous souciez de la redondance et des enregistrements orphelins. Pour certaines industries comme la banque, l'exactitude des données est vitale, il est donc difficile de voir comment elles s'éloigneront jamais des SGBDR. Pour les autres secteurs, de nouveaux acteurs entrent en permanence sur le marché, les choix sont donc innombrables.

Quant à savoir si votre équipe n'est pas à l'aise avec les restrictions qu'un SGBDR peut apporter - qui sait? Certes, les développeurs juniors que je vois n'ont pas le SGBDR que les développeurs des générations précédentes, mais cela est probablement plus lié à la prolifération des technologies de développement et des plates-formes de bases de données.

Il n'y a pas de fin de technologies qu'un développeur peut apprendre et il peut être difficile de faire le bon coup pour votre carrière. Il est certain que l'époque où les développeurs étaient un cric de tous les métiers est révolue depuis longtemps - il y a tout simplement trop à apprendre.

Mais - à la question en main. De votre propre aveu, vous ne vous attendez pas à ce que les volumes de données augmentent et le système fonctionne bien. Il serait assez difficile pour vous de vendre l'idée de réorganiser les choses sans aucun avantage perceptible. Peut-être que si vous pouviez faire une preuve de concept où une approche SGBDR a récolté des avantages, ce serait une autre histoire.


1
pourquoi est-ce downvoted? c'est une réponse équilibrée. pragmatisme +1
Dirk Boer

Le pragmatisme est bon, mais il faut quand même faire attention. La dénormalisation des données au nom de la performance au début d'un projet pue une optimisation prématurée. Ne pas réorganiser un ancien système qui fonctionne est évidemment un bon choix pragmatique, mais refuser de concevoir un nouveau système aux normes de l'industrie au nom de "nous avons toujours fait le contraire et ça marche" est loin d'être un bon argument .
Vincent Savard

Dénormaliser les données au nom de la performance au début d'un projet ... Astuce: vous ne le faites pas :)
Robbie Dee

1
La valeur d'un SGBDR ne vient pas de l'efficacité du disque.
TehShrike

0

Cela dépend de la base de données que vous utilisez.

Dans un SGBDR traditionnel, vous avez raison. La duplication des données est une abomination. Les colonnes et leur équivalence json vont inévitablement se désynchroniser car il n'y a rien pour l'imposer. Le support de clé étrangère est bien connu, fait un excellent travail pour décrire et appliquer les relations. Et l'atomicité est essentielle pour faire presque n'importe quoi avec des données.

Dans une configuration nosql, c'est moins clair. Puisqu'il n'y a pas de relations solides, l'application des relations devient moins importante. Ce type de contenu json avec index de colonne est beaucoup plus courant sur ces systèmes car aucune relation ne signifie qu'il est moins susceptible de se désynchroniser. Et l'atomicité est limitée à la table unique car c'est ainsi que nosql fonctionne.

Ce qui est mieux dépend de ce que vous faites réellement et de ce dont vous avez réellement besoin.

Mais il semble que vos collègues soient dans un culte du fret. Ils ont été mordus par de vieilles mauvaises choses, alors maintenant les choses doivent être la nouvelle chose brillante. Dans quelques années, une fois qu'ils auront été mordus par la nouvelle chose brillante, ils réaliseront, espérons-le, que SQL vs noSQL est un ensemble de compromis.

Mais ils ne le feront pas. J'espère que vous le ferez.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.