Dans quelle mesure le modèle de données affecte-t-il l'évolutivité et les performances dans la base de données dite «NoSQL»?

Vous ne pouvez jamais parler de la base de données dite "NoSQL" sans apporter le théorème CAP (cohérence, disponibilité, partition: choisissez deux). Si vous devez choisir, par exemple, entre MongoDB (partition, cohérence) et CouchDB (disponibilité, partition), le premier auquel vous devez penser est "Ai-je besoin de données correctes ou ai-je besoin d'avoir accès tout le temps?".

Ces nouvelles bases de données ont été conçues pour être partitionnées. Mais si je ne le fais pas ? Et si je pense que c'est plutôt cool d'avoir une clé / valeur, une colonne, un document, quelle que soit la base de données au lieu d'une relationnelle, et de créer une seule instance de serveur et de ne jamais la partager? Dans ce cas, ne serais-je pas à la fois disponible et cohérent? MongoDB n'aurait pas besoin de répliquer quoi que ce soit, il serait donc disponible. Et CouchDB n'aurait qu'une seule source de données, donc ce serait assez cohérent.

Cela signifierait donc que, dans ce cas, MongoDB et CouchDB auraient peu de différence en termes de cas d'utilisation? Eh bien, sauf bien sûr les performances, l'API et autres, mais ce serait plus comme choisir entre PostgreSQL et MySQL que d'avoir deux ensembles d'exigences fondamentalement différents.

Suis-je ici? Puis-je changer une base de données AP ou CP en AC en ne créant pas plus d'une instance? Ou y a-t-il quelque chose qui me manque?

Posons la question à l'envers. Et si je prends une base de données relationnelle, disons MySQL, et la mets dans une configuration maître / esclaves. Je n'utilise pas de transactions ACID Si j'ai besoin qu'une écriture soit synchronisée immédiatement avec l'esclave, cela n'en ferait-il pas une base de données CP? Et si je le synchronise à des intervalles prédéfinis, et peu importe si un client lit les données périmées d'un esclave. Cela n'en ferait-il pas une base de données AP? Cela ne signifierait-il pas que si je renonce à la conformité ACID, je peux toujours utiliser le modèle relationnel pour une base de données partitionnée?

Essentiellement: l'évolutivité de ce que vous êtes prêt à abandonner dans le théorème de CAP, est-elle plus que le modèle de données sous-jacent? Le fait d'avoir Column, Document, Key Value, quoi que ce soit donne un coup de pouce à l'évolutivité sur un modèle relationnel? Pourrions-nous concevoir une base de données relationnelle conçue à partir de zéro pour la tolérance de partition? (Peut-être que cela existe déjà). Pourrions-nous rendre la base de données NoSQL conforme à ACID?

Désolé, c'est beaucoup de questions, mais j'ai lu beaucoup de choses sur la base de données NoSQL récemment et il me semble que le plus grand avantage de les utiliser est qu'elles correspondent mieux à la "forme" de vos données, plutôt qu'à la partition, CAP et renoncer à la conformité ACID. Après tout, tout le monde n'a pas tellement de données qu'il faut les partitionner. Existe-t-il un avantage en termes de performances / d'évolutivité à ne pas utiliser le modèle relationnel avant même de penser à partitionner mes données?

L'utilisation d'une base de données NoSQL donne-t-elle un coup de pouce à l'évolutivité même si vous ne partagez pas les données? Permet bien de définir l'évolutivité. Si vous faites référence à l'évolutivité en ce qui concerne les systèmes de base de données / backend, dans la mesure où vous avez une mise à l'échelle verticale et horizontale où la mise à l'échelle horizontale est le partage des données, cela devient une question triviale car alors la réponse serait absolument non, car la seule option qui vous reste est une mise à l'échelle verticale (c'est-à-dire obtenir un meilleur matériel). Si toutefois vous parlez d'évolutivité au sens large en faisant référence à la flexibilité de l'application, à la valeur des données, etc ... Alors c'est une question complètement différente avec un certain nombre de réponses. Et comme vous l'avez mentionné, cela dépendra souvent de ce que vous faites avec les données et de la façon dont elles doivent être stockées. Permettez-moi de tout préface ici avec la déclaration que dans la plupart des cas, vous devriez toujours utiliser un SGBDR et NoSQL devrait remplir les créneaux. Ce qui suit est une description d'une instance spécifique où une base de données NoSQL serait plus avantageuse compte tenu des exigences spécifiques, et où nous pouvons ignorer la mise à l'échelle horizontale.

Prenez par exemple l'idée que vous créez un système de stockage de fichiers cloud similaire à Google Drive, Dropbox ou Box, mais au lieu d'utiliser un système de fichiers réel, vous décidez qu'il serait plus avantageux pour vous de virtualiser le système de fichiers. Maintenant, vous avez un problème parce que votre modèle de données est soudainement la structure arborescente qui va être horriblement inefficace dans un SGBDR (malgré le fait que tout soit indexé). Parce que maintenant vous avez une table à 3 colonnes avec Nom, Utilisateur et Parent. L'utilisateur est une clé étrangère vers une table d'utilisateurs et le parent est une clé étrangère annulable auto-référencée (nullable car le répertoire racine ne peut pas avoir de parent). Quelle est donc la clé primaire? Dans ce cas, c'est une clé composée dans toutes les colonnes ... Ce qui fait soudainement de Parent notre pire ennemi.

Maintenant, pensez plutôt à la façon dont vous mettriez cela dans une certaine forme de magasin de documents? Au lieu de lutter contre les données, vous pouvez travailler avec elles et les stocker sous forme d'arborescence, ce qui à son tour réduira votre temps de développement ainsi que les coûts de maintenance. Si vous réduisez les coûts, cela ne permet-il pas un autre type d'évolutivité? De plus, dans ce cas, vous créez correctement le système à partir de zéro, ce qui devrait donner plus de flexibilité à l'application elle-même. Actuellement, j'exécute cela sur un seul serveur en utilisant MongoDB, qui, comme vous l'avez expliqué, me donne un modèle disponible et cohérent qui n'est pas très différent de la différence entre MySQL ou Postgres.

Avec MongoDB au moins, vous pouvez définir le nombre de serveurs avec lesquels vous devez communiquer pour qu'une requête réussisse.Vous pouvez donc la convertir en un modèle cohérent et disponible si vous dites à toutes les requêtes de communiquer avec toutes les instances de serveur.

Je pense donc que vous en avez le droit, car la façon dont les données sont stockées présente un grand avantage. Il y a des choses qui ne cadrent pas bien dans un modèle relationnel qui s'intègrent bien dans d'autres modèles (comme un autre bref exemple, Amazon utilise une certaine forme de base de données graphique pour son moteur de recommandation de produits).

Ai-je bien compris votre question?

Edit: Est-ce que plus de données ralentiront les choses? Oui. Combien cela ralentira-t-il les choses? Honnêtement, je n'ai pas assez d'expérience pour donner une réponse adéquate. Clé / valeur: essentiellement une table de recherche avec de grandes quantités de données associées à la clé de recherche. Cela va être vraiment très rapide car vous ne pouvez rechercher les choses qu'à l'aide de la clé. Colonne / Famille: essentiellement un magasin de clés / valeurs beaucoup plus structuré. Vous ne pouvez interroger que sur la base de la colonne et cela devrait donc être très rapide aussi. Document: schéma de style d'agrégation. Ici, vous souhaiterez regrouper des données similaires. La dénormalisation est correcte et attendue pour ce type de base de données. Selon que vous effectuez un grand nombre d'écritures ou de lectures, vous pouvez organiser vos données afin qu'elles soient réparties sur plusieurs fragments pour distribuer les écritures ou les lectures (notez que vous pouvez créer une approche hybride qui est bonne pour les deux mais généralement vous besoin de choisir l'optimisation pour l'un ou l'autre) Graphique: La force de celui-ci est qu'il peut créer et détruire des relations très rapidement. Si vous avez des données dans lesquelles vous avez des relations qui doivent changer entre les données (pensez à une forme de moteur de recommandation), vous devez l'utiliser.

La façon dont vous stockez les données dans l'une de ces bases de données aura une influence sur les performances (similaire au fait que si vous stockez des données de manière incorrecte dans certains SGBDR, cela influencera les performances). Donc, nous espérons que cela soit plus clair: vous devez savoir quel système de base de données vous devez utiliser et comment stocker les données dans ce système de base de données.