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 source
Réponses:
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:
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:
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.
la source
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.
la source
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.
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.
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.
la source
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.
la source
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.
la source