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
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 que l'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, bon nombre 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.
En parlant avec l'un de nos principaux ingénieurs aujourd'hui, il a tenté de me pousser loin 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 maintenir nos requêtes rapidement. Ce que nous prévoyons, c'est beaucoup de temps consacré à l'évaluation des règles et à l'exécution des actions. Il semble logique de déplacer autant de charge que possible vers SQL.
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.
Le mot clé ici pour comprendre d'où vient votre équipe est "microservices". Il vaudrait la peine 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 à 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 général, vous n'avez pas besoin d'avoir 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.
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 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 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.
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 fait valoir que dans les endroits où je veux l'atomicité, nous n'en avons pas besoin ...
Si vous pouvez faire un cas solide (alias l'exigence non fonctionnelle) pour avoir besoin de l'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 ...
Let's espérons 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 (alias de l'argent) à mettre à jour la même chose à plusieurs endroits.
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 pour la performance (pour réduire les jointures) est devenue courante 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 un jugement pour savoir si vous soins sur la redondance et les 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 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 base 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 fait récolter des avantages, ce serait une autre histoire.
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 des clés étrangères est bien connu, fait un excellent travail pour décrire et appliquer les relations. Et l'atomicité est vitale 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 seule table 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.