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?


51

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.


16
Cela ressemble plus à un coup de gueule qu'à une question. Vous semblez bien comprendre les avantages et les inconvénients du stockage clé-valeur par rapport au stockage relationnel. Alors, quelle est exactement la question?
JacquesB

16
Ce n'est pas du tout une délire :) Les bases de données NoSQL sont géniales, mais je pense que les bases de données relationnelles ne sont pas aussi mauvaises que certaines personnes le disent. Je veux simplement savoir, si ma thèse est bien faite, que les bases de données NoSQL ne sont pas le meilleur choix pour la recherche dans "datarows" ... ou si je n'ai pas compris le sujet correctement.
Leo Lindhorst le


5
Mais MongoDB est Webscale ! [avertissement: comprend un peu de langue NSFW]
Jerry Coffin

5
@DevWurm: Vous ne devez pas associer les magasins de valeurs-clés à NoSQL en général. Par exemple, googles BigTable est considéré comme une base de données NoSQL, mais vous pouvez toujours rechercher et créer des index sur plusieurs champs. Un magasin de valeurs-clés est approprié lorsque vous savez que vous n'avez besoin que de rechercher dans un seul champ (la clé).
JacquesB

Réponses:


40

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).


13
"... puisqu'ils habitent 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." C'est la même situation entre un index non-cluster dans une base de données SQL et un index pour une base de données noSQL, non?
Jirka Hanika

Réponse assez solide. J'ajouterais que NoSQL repose en quelque sorte sur l'idée que si vous voulez aller plus vite, vous devez faire 90% de requêtes ++ par une clé primaire sans jointure, et si vous voulez faire autre chose, vous êtes dans la le monde des balayages de table et des index secondaires, qui ont toujours des limites de performances et d’échelle. Une fois que vous recherchez un index ou que vous en avez créé un groupe, vous n'êtes tout simplement pas dans la zone où la vitesse peut être atteinte (à l'exception de petits ensembles de données de quelques millions de lignes). Si vous codez dans le style où les recherches alternatives sont rares, vous obtenez un système opérationnel très solide.
Brian Bulkowski

40

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.


2
Dans votre exemple, vous affirmez que "l' interrogation SQL par pays est aussi lente que l'analyse NoSQL de tous les utilisateurs ". Avez-vous des preuves pour soutenir cela? NoSQL décrit dans la question est une paire clé-valeur. Vous devez donc analyser la valeur pour obtenir l'emplacement du pays, puis effectuer la comparaison. SQL sait déjà où se trouvent ces données, il peut donc les sélectionner directement sur le disque (en ignorant ce qui n'est pas nécessaire), puis vérifier la valeur. Si le pays est une clé étrangère, il s'agit d'une comparaison rapide en nombres entiers. Wound't, ce sera toujours plus rapide puisque vous tirez moins du disque et que la vérification est plus rapide.
Trisped

1
@Trisped Il est difficile de fournir des preuves, car NoSQL est une approche, pas un produit (idem pour SQL). Cependant, il convient de noter que BigTable, une implémentation NoSQL, a un concept de colonnes, tout comme les tables SQL. C'est le concept de colonnes qui vous permet de sauter des données en sachant où regarder, ce qui peut être appliqué à l'une ou l'autre implémentation.
Cort Ammon

16

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.


2
"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 n'est pas vrai. Il couvre tous les systèmes de base de données qui ne sont pas des bases de données SQL. Certaines bases de données relationnelles n'utilisant pas SQL, telles que Rel et Tutorial D (les bases de données sont conçues pour suivre le modèle relationnel de plus près, sans "adoucir" ce que SQL fait). Il existe des bases de données hyperrelationales. Vraiment, NoSQL signifie "Not Only SQL", ce qui signifie "ne supposez pas automatiquement le SQL, choisissez le modèle de base de données correct qui correspond à la structure de votre date… qui peut très bien être SQL."
Jörg W Mittag

@ JörgWMittag Selon votre définition, si je choisis MySQL parce que c'est la meilleure base de données correspondant à mes données, c'est une solution NoSQL valide.

1
@ JörgWMittag: Il n'y a pas de définition officielle du terme NoSQL, mais elle fait généralement référence à des systèmes de base de données non relationnels. Le backronym "Not Only Sql" est vraiment un système plus récent permettant de contrecarrer le battage médiatique inévitable. Mais généralement, NoSQL est utilisé pour décrire des systèmes tels que MongoDb, Bigtable, etc., mais pas le didacticiel D (qui n'est même pas une base de données).
JacquesB

2
@ JörgWMittag NoSQL signifiait à l'origine "non SQL" ou "non relationnel". Le "Not Only SQL" serait NOSQL puisqu'il s'agit d'un acronyme au lieu de la combinaison du mot "No" et de l'acronyme "SQL". Il est devenu populaire comme un moyen de lutter contre la pratique générale consistant à tout mettre dans une base de données (comme indiqué dans l'article de Wikipedia). Comme vous l'avez dit, le domaine est un peu plus complexe maintenant.
Trisped

Complètement d'accord. Il semble que les principaux modèles de NoSQL soient le magasin de documents (par exemple, Mongo) et le graphique (par exemple, Neo4J). J'aimerais que les gens abandonnent NoSQL et utilisent l'un de ces termes.
mardi

10

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.


Lire 10 To dans la RAM prend un certain temps @Daniel ... Quelques heures seraient un très bon résultat. Il serait relativement désastreux de se remettre d’une catastrophe.
Ben

1
Je dirais que le Big Data est certainement un domaine dans lequel les bases de données NoSQL entrent en jeu, mais ce n’est qu’un seul. Il existe également de nombreuses autres raisons pour lesquelles une base de données NoSQL pourrait mieux convenir à un problème. Si vous avez des graphiques de données, il est judicieux d'utiliser une base de données graphique. Si vous avez des données XML, il est logique d'utiliser une base de données XML. Non seulement le Big Data, mais aussi le modèle de données est un critère important lors de la sélection d'une base de données appropriée (et bien sûr, plusieurs bases de données SQL sont le bon choix, en fonction du problème)
dirkk

5
C'est faux. Le partage en tant qu'approche de programmation est la norme dans les bases de données à grande échelle depuis des années et certaines bases de données prennent en charge les clusters avec un partage de données transparent (Oracle RAC). Comment pensez-vous que toutes les banques fonctionnent? Et avec une configuration appropriée, vous restaurerez rarement les sauvegardes - cela reste comme un vrai scénario "2 centres de données brûlés". Et oui, nous avons déjà travaillé sur une base de données de 30 To - nous n’avons eu aucun problème.
TomTom

Oui, les bases de données relationnelles font un partage de données et une mise en cluster transparents, mais c'est une abstraction très fuyante si vous vous souciez d'optimiser les performances.
Karl Bielefeldt

5

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.


Cette dernière information est très intéressante - avez-vous un lien vers un site méta SO pour que les lecteurs intéressés puissent cliquer sur l’utilisation (non) SO de NoSQL par les SO? Merci!
kcrisman

@kcrisman, voir highscalability.com/stack-overflow-architecture pour un exemple
Ian

2

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.


Un bon exemple consisterait à enregistrer des discussions. Il peut s'avérer nécessaire de les relier à d'autres données et de procéder à toutes sortes d'analyses, mais lors de la session de discussion, les utilisateurs apprécieront quelque chose de plus rapide qui ne présente pas tout le surmenage d'un SGBDR, tel qu'une transaction ou une contrainte.
JeffO

-1

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).


-2

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.

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.