L'utilisation de bases de données NoSQL est-elle impraticable pour les grands ensembles de données où vous devez effectuer une recherche par contenu?

Je connais les bases de données NoSQL depuis une semaine maintenant.

Je comprends vraiment les avantages des bases de données NoSQL et de leurs nombreux cas d'utilisation.

Mais souvent, les gens écrivent leurs articles comme si NoSQL pouvait remplacer les bases de données relationnelles. Et il y a un point sur lequel je ne peux pas comprendre:

Les bases de données NoSQL sont (souvent) des magasins de clé-valeur.

Bien sûr, il est possible de tout stocker dans un magasin de valeurs-clés (en codant les données au format JSON, XML, peu importe), mais le problème que je vois est que vous devez obtenir une quantité de données correspondant à un critère spécifique, dans de nombreux cas. cas d'utilisation. Dans une base de données NoSQL, vous n'avez qu'un seul critère que vous pouvez rechercher efficacement: la clé. Les bases de données relationnelles sont optimisées pour rechercher efficacement toute valeur de la ligne de données.

Ainsi, les bases de données NoSQL ne sont pas vraiment un choix pour la persistance de données qui doivent être recherchées par leur contenu. Ou ai-je mal compris quelque chose?

Un exemple:

Vous devez stocker les données utilisateur pour une boutique en ligne.

Dans une base de données relationnelle, vous stockez chaque utilisateur sous forme de ligne dans la userstable, avec un ID, le nom, son pays, etc.

Dans une base de données NoSQL, vous stockez chaque utilisateur avec son ID en tant que clé et toutes ses données (codées en JSON, etc.) en tant que valeur.

Donc, si vous avez besoin d'obtenir tous les utilisateurs d'un pays spécifique (pour une raison quelconque, les responsables marketing ont besoin de savoir quelque chose à leur sujet), il est facile de le faire dans la base de données relationnelle, mais pas très efficace dans la base de données NoSQL, car vous devez obtenir chaque utilisateur, analyser toutes les données et filtrer.

Je ne dis pas que c'est impossible , mais cela devient beaucoup plus compliqué et je suppose que ce n'est pas aussi efficace si vous voulez chercher dans les données des entrées NoSQL.

Vous pouvez créer une clé pour chaque pays qui stocke les clés de chaque utilisateur résidant dans ce pays et obtenir les utilisateurs d'un pays spécifique en obtenant toutes les clés déposées dans la clé de ce pays. Mais je pense que cette technique rend un ensemble de données complexe encore plus complexe: il est plus difficile à implémenter et moins efficace que d'interroger une base de données SQL. Donc, je pense que ce n'est pas une manière que vous utiliseriez en production. Ou est-ce?

Je ne suis pas vraiment sûr d'avoir mal compris quelque chose ou d'avoir oublié certains concepts ou les meilleures pratiques pour gérer de tels cas d'utilisation. Peut-être pourriez-vous corriger mes propos et répondre à mes questions.

Bien que je convienne avec votre prémisse que NoSQL n'est pas une panacée pour tous les problèmes de bases de données, je pense que vous comprenez mal un point clé.

Dans la base de données NoSQL, vous n'avez qu'un seul critère que vous pouvez rechercher efficacement: la clé.

Ce n'est clairement pas vrai.

Par exemple, MongoDB prend en charge les index. (à partir de https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Les index prennent en charge l'exécution efficace des requêtes dans MongoDB. Sans index, MongoDB doit effectuer une analyse de la collection, c'est-à-dire analyser chaque document d'une collection, afin de sélectionner les documents correspondant à l'instruction de requête. Si un index approprié existe pour une requête, MongoDB peut utiliser cet index pour limiter le nombre de documents à inspecter.

Les index sont des structures de données spéciales [1] qui stockent une petite partie du jeu de données de la collection dans un formulaire facile à parcourir. L'index stocke la valeur d'un champ spécifique ou d'un ensemble de champs, classés par la valeur du champ. L'ordre des entrées d'index prend en charge les correspondances d'égalité efficaces et les opérations de requête basées sur des plages. De plus, MongoDB peut renvoyer des résultats triés en utilisant l'ordre dans l'index.

De même que couchbase (à partir de http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Les vues Couchbase permettent l'indexation et l'interrogation des données.

Une vue crée un index sur les données en fonction du format et de la structure définis. La vue se compose de champs et d'informations spécifiques extraits des objets de Couchbase.

En fait, tout ce qui s'appelle une base de données NoSQL plutôt qu'un magasin de clés-valeurs devrait réellement supporter un certain type de schémas d'indexation.

En fait, c'est souvent la flexibilité de ces systèmes d'index qui fait briller NoSQL. À mon avis, le langage utilisé pour définir les index NoSQL est souvent plus expressif ou naturel que le SQL et, comme ils vivent généralement en dehors de la table, vous n'avez pas besoin de modifier vos schémas de table pour les prendre en charge. (Cela ne veut pas dire que vous ne pouvez pas faire des choses similaires en SQL, mais pour moi, c'est comme s'il y avait beaucoup plus de sauts en cercle impliqués).

En règle générale, si votre flux de travail est parfaitement adapté aux requêtes de bases de données relationnelles, les bases de données relationnelles seront l’approche la plus efficace. C'est un peu tautologique, mais c'est vrai.

L'affirmation de nombreux défenseurs de NoSQL est que beaucoup de workflows ont été réellement massés sous une forme relationnelle et auraient été plus efficaces avant un tel massage. La validité de cette affirmation est compliquée à déterminer. Il est clair qu'il existe des travaux très bien décrits par les requêtes SQL. D'après mon expérience, je peux affirmer que mes tâches de programmation relationnelles particulières auraient pu être réalisées avec NoSQL avec pratiquement le même niveau d'efficacité, voire davantage. Cependant, c'est une déclaration très subjective basée sur une expérience étroite.

J'ai l'impression que la vente de l'approche NoSQL provient en grande partie de l'hypothèse de bases de données volumineuses. Plus la base de données est volumineuse, plus vous devez améliorer votre flux de travail pour prendre en charge les ensembles de données plus volumineux. NoSQL semble mieux supporter cet effort de toilettage. Ainsi, plus la base de données est volumineuse, plus les fonctionnalités de NoSQL peuvent être importantes.

Pour utiliser cet exemple, dans SQL, l'interrogation par pays est aussi lente que l'analyse NoSQL de tous les utilisateurs, sauf si vous indiquez explicitement à SQL d'indexer la userstable par pays. NoSQL peut faire la même chose, en créant une collection clé-valeur ordonnée qui est l'index (comme le fait SQL sous le capot) et en le maintenant.

La différence? Les moteurs SQL avaient le concept d'indexation de la table. Cela signifie que vous devez faire moins de travail (tout ce que vous deviez faire était d'ajouter un index à la table). Cependant, cela signifie également que vous avez moins de contrôle. Dans la plupart des cas, cette perte de contrôle est acceptable si le moteur SQL effectue le travail à votre place. Toutefois, dans le cas d'ensembles de données volumineux, vous souhaiterez peut-être un modèle de cohérence différent du modèle SQL ACID typique. Vous souhaiterez peut-être utiliser le modèle BASE qui prend en charge la cohérence éventuelle. Cela pourrait être très difficile en SQL, car le moteur SQL fait le travail pour vous et doit donc être effectué selon les règles du moteur SQL. Dans NoSQL, ces couches sont généralement exposées, ce qui vous permet de les pirater.

NoSQL est un terme plutôt vague, car il couvre essentiellement tous les systèmes de base de données qui ne sont pas relationnels.

Ce que vous décrivez est un magasin de clé-valeur , qui est une sorte de base de données dans laquelle un blob de données est stocké sous une clé et peut être rapidement recherché si vous connaissez la clé. Ces bases de données sont extrêmement rapides si vous connaissez la clé exacte, mais comme vous le dites vous-même, si vous devez rechercher ou filtrer plusieurs propriétés sur les données, elles seront lentes et fastidieuses.

Personne de sensé ne prétendrait que les magasins de clés-valeur peuvent remplacer les bases de données relationnelles en général. Cependant, il peut y avoir des cas d'utilisation particuliers où la clé-valeur est un bon choix. Les magasins de clé-valeur sont souvent utilisés pour la mise en cache, car vous mettez généralement les éléments en cache par ID, mais vous n'avez pas besoin d'effectuer de requêtes ad-hoc sur des caches. Par exemple, le site Stackoverflow lui-même utilise largement Redis (une base de données clé-valeur) , mais uniquement pour la mise en cache de la sortie. Les données canoniques sous-jacentes sont toujours conservées dans une base de données relationnelle.

La réponse est donc assez évidente: utilisez un magasin de valeurs-clés s'il vous suffit de stocker et de rechercher à l'aide d'une seule clé. Sinon, utilisez un type de base de données différent. Et si vous avez des doutes, utilisez une base de données relationnelle, car il s'agit du type de base de données le plus polyvalent, alors que les bases de données NoSQL sont souvent optimisées pour des cas d'utilisation très particuliers.

Vos affirmations sur les bases de données relationnelles sont toutes vraies, jusqu'au point où vous avez tellement de données que vous ne pouvez plus en conserver une copie sur un seul serveur. Ensuite, vous commencez à rencontrer toutes sortes de problèmes intéressants. Comment divisez-vous vos tables afin que la plupart de vos requêtes puissent s'exécuter sur un seul serveur? Combien de copies des données faites-vous? Comment gérez-vous les incohérences entre ces copies? Comment conserver les données d'un utilisateur dans un centre de données relativement proche de lui géographiquement?

Ces objectifs sont souvent en conflit les uns avec les autres. De nombreux utilisateurs de Twitter suivent des personnes du monde entier. La base de données de twitter doit-elle être optimisée géographiquement pour la lecture de tweets ou la rédaction de tweets?

Il s'avère que lorsque vous travaillez avec ce type d'échelle, vous commencez à inventer des solutions, à ajouter des redondances et à imposer des restrictions qui ressemblent beaucoup à une base de données NoSQL. Si vous pouvez adapter toutes vos données sur une boîte, vous n’obtenez que les restrictions et n’avez plus besoin des avantages.

Les bases de données NoSQL ont très peu à voir avec « No SQL».

Ils sont sur le point d' admettre que vous ne pouvez pas avoir une base de données à l' échelle qui est toujours cohérente et prend en charge les transactions complexes et a une durabilité.

Dans une base de données relationnelle normale, tous les index sont automatiquement mis à jour dans le cadre d'une transaction. Ils peuvent donc être utilisés pour toute requête.

Dans une base de données NoSQL, le programmeur est responsable de la gestion d'un grand nombre d'index et il est supposé que les index seront toujours obsolètes.

Par exemple:

• Un index de personnes par numéro de taxe peut contenir des personnes qui ne terminent jamais le processus d’enregistrement de la taxe.
• Par conséquent, le code qui utilise l’index doit pouvoir traiter un enregistrement incomplet à des fins fiscales.
• Une autre option consiste à avoir des moments où une personne inscrite aux fins de l'impôt ne figure pas dans l'index. (Votre conception doit donc gérer l'absence de données cohérentes et décider de la non-cohérence des données.)

En guise d'exemple, Amazon préférerait me montrer la description obsolète d'un livre plutôt que de retarder l'affichage de la page Web en attendant que 106 ordinateurs confirment que le verrou correct a été retiré.

Donc.....

Si une seule base de données relationnelle normale peut contenir toutes vos données et traiter chaque transaction suffisamment rapidement pour que le verrouillage n’empêche pas votre système d’effectuer un travail utile, une base de données relationnelle est la meilleure option.

Mais dès que vous devez commencer à penser à utiliser plusieurs bases de données relationnelles ou à fractionner des transactions pour éviter les erreurs de verrouillage, vous vous retrouvez face au genre de problèmes que vous rencontrez lorsque vous utilisez des bases de données «NoSQL».

Comme les bases de données «NoSQL» ne cachent pas ces problèmes, elles peuvent devenir la meilleure option lorsque vous mettez à l'échelle un système. Mais rappelez-vous que Stackoverflow utilise toujours une base de données relationnelle pour stocker toutes ses données, avec une utilisation limitée de NoSQL dans la couche de mise en cache - vous devez donc être TRÈS gros avant de devoir utiliser NoSQL pour stocker vos données.

Les bases de données relationnelles sont optimisées pour rechercher efficacement toute valeur dans la base de données.

Ne confondez pas la possibilité de rechercher "n'importe quelle" valeur dans une ligne avec "chaque" valeur dans une ligne. Le moyen le plus efficace de le faire nécessite un ou plusieurs index. Vous pouvez faire en sorte que les index incluent tous les champs, mais vous empêchez alors la possibilité d’apporter des modifications nécessitant une modification de l’index (insertions, mises à jour, suppressions). Vous (ou votre DBA) devez comprendre les données, l'utilisation, les goulots d'étranglement, etc.

Il y a déjà beaucoup de réponses, mais je voulais juste ajouter mon résumé.

Clairement, le concept NoSQL couvre une variété d'approches différentes pour organiser les données sur disque, en mémoire et les exposer via un langage de requête (certaines sont même du type SQL!). À mon avis, la force provient de cette variété de systèmes vous permettant de choisir le meilleur outil pour le travail. Néanmoins, il est à espérer que vous pourrez couvrir une douzaine de besoins différents avec juste quelques solutions différentes. Vous ne voudriez pas gérer une douzaine de systèmes différents.

Les bases de données relationnelles peuvent aller très loin et sont une technologie éprouvée, mais tout comme la base de données, vous pouvez choisir le langage de programmation en fonction des besoins de chaque projet (tout en tenant compte de l'expérience de l'équipe).

J'utilise couchdb depuis deux ans maintenant. Il est principalement utilisé pour la gestion et la configuration du contenu.

Car les relations hiérarchiques sont beaucoup plus faciles à gérer lorsque vous pouvez les visualiser. Pour les données principalement en lecture, il est plus facile de modifier JSON que d'écrire une instruction UPDATE dans de nombreux cas. En fait, il ne faut pas un programmeur pour éditer JSON. Et SQL vous donne des lignes et des colonnes, que vous devez ensuite mapper dans une sorte de structure d'objet.

Vous bénéficiez également d'une amélioration des performances car vous ne joignez pas 10 à 20 tables sur des requêtes complexes. Les vues Couchdb sont très rapides car le javascript sur lequel elles sont basées n'est pas exécuté au moment de la requête.

La plupart des programmeurs comprennent le langage Javascript et la plupart d'entre eux ont des difficultés avec SQL.

Dans Couchdb, une vue peut être considérée comme un résumé d'un document JSON. C'est vous qui décidez de la structure des données de la vue (vous n'êtes pas contraint par la hiérarchie d'origine).

Je n'utiliserais pas Couchdb pour les données hautement transactionnelles, mais pour les données semi-statiques avec une structure de type explosion de pièces, il est BEAUCOUP plus facile de travailler qu'avec SQL.

Notez cependant qu’il n’ya pas de «normalisation» claire qui puisse être appliquée (bien qu’éviter la duplication de données soit un objectif louable), et qu’il existe une stratégie de mise à jour «optimiste» qui s'apparente à un verrouillage optimiste.