L'utilisation des bases de données NoSQL n'est-elle pas pratique pour les grands ensembles de données où vous devez rechercher par contenu?
J'apprends les bases de données NoSQL depuis une semaine maintenant.
Je comprends vraiment les avantages des bases de données NoSQL et les nombreux cas d'utilisation pour lesquels ils sont parfaits.
Mais souvent, les gens écrivent leurs articles comme si NoSQL pouvait remplacer Bases de données relationnelles. Et il y a le point que je ne peux pas comprendre:
Les bases de données NoSQL sont (souvent) des magasins de valeurs-clés.
Bien sûr, il est possible de tout stocker dans un magasin de valeurs-clés (en encodant les données en JSON, XML, peu importe), mais le problème que je vois est que vous devez obtenir une certaine quantité de données qui correspond à un critère spécifique, dans de nombreux 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 dans la ligne de données.
Les bases de données NoSQL ne sont donc pas vraiment un choix pour les données persistantes 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 table users, avec un ID, le nom, son pays, etc.
Dans une base de données NoSQL, vous stockeriez chaque utilisateur avec son ID comme clé et toutes ses données (encodées en JSON, etc.) comme valeur.
Donc, si vous devez obtenir tous les utilisateurs d'un pays spécifique (pour une raison quelconque, les responsables marketing doivent 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 tous les utilisateurs, analyser tous les données et filtrer.
Je ne dis pas que c'est impossible , mais cela devient beaucoup plus délicat et je suppose que ce n'est pas efficace si vous voulez rechercher 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 qui vit dans ce pays, et obtenir les utilisateurs d'un pays spécifique en obtenant toutes les clés qui sont 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 l'interrogation d'une base de données SQL. Je pense donc que ce n'est pas une façon que vous utiliseriez dans la production. Ou est-ce?
Je ne sais pas vraiment si j'ai mal compris quelque chose ou oublié certains concepts ou meilleures pratiques pour gérer de tels cas d'utilisation. Vous pourriez peut-être corriger mes déclarations et répondre à mes questions.
Bien que je sois d'accord avec votre prémisse selon laquelle NoSQL n'est pas une panacée pour tous les problèmes de base 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. (depuis 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 collection, c'est-à-dire analyser chaque document d'une collection, pour sélectionner les documents qui correspondent à l'instruction de requête. S'il existe un index approprié pour une requête, MongoDB peut utiliser l'index pour limiter le nombre de documents qu'il doit inspecter.
Les index sont des structures de données spéciales [1] qui stockent une petite partie de l'ensemble de données de la collection sous une forme facile à parcourir. L'index stocke la valeur d'un champ spécifique ou d'un ensemble de champs, triée par la valeur du champ. L'ordre des entrées d'index prend en charge des correspondances d'égalité efficaces et des opérations de requête basées sur une plage. De plus, MongoDB peut retourner des résultats triés en utilisant l'ordre dans l'index.
Tout comme couchbase (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 selon le format et la structure définis. La vue se compose de champs spécifiques et d'informations extraites des objets dans Couchbase.
En fait, tout ce qui s'appelle une base de données NoSQL plutôt qu'un magasin de valeurs-clés devrait vraiment prendre en charge une sorte de schémas d'indexation.
En fait, c'est souvent la flexibilité de ces schémas d'index qui fait briller NoSQL. À mon avis, le langage utilisé pour définir les indices NoSQL est souvent plus expressif ou naturel que 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. (Pour ne pas dire que vous ne pouvez pas faire des choses similaires en SQL, mais pour moi, il semble qu'il y ait beaucoup plus de sauts de cerceau impliqués).
De manière générale, si votre flux de travail correspond parfaitement aux requêtes de bases de données relationnelles, vous constaterez que les bases de données relationnelles sont l'approche la plus efficace. C'est un peu tautologique, mais c'est vrai.
L'affirmation que de nombreux défenseurs de NoSQL feraient serait que de nombreux workflows étaient en fait massés sous une forme relationnelle, et auraient été plus efficaces avant un tel massage. La validité de cette affirmation est compliquée à vérifier. Il est clair que certains travaux sont très bien décrits par les requêtes SQL. Je peux dire de mon expérience que mon des tâches de programmation relationnelle particulières auraient pu être effectuées en utilisant NoSQL avec presque le même niveau d'efficacité, sinon plus. Cependant, c'est une déclaration très subjective basée sur une expérience étroite.
J'ai le sentiment qu'une grande partie de la vente de l'approche NoSQL vient de l'hypothèse de grandes bases de données. Plus la base de données est grande, plus vous devez améliorer votre flux de travail pour prendre en charge les ensembles de données plus volumineux. NoSQL semble mieux soutenir cet effort de toilettage. Ainsi, plus la base de données est grande, plus les fonctionnalités de NoSQL peuvent être importantes.
Pour utiliser l'exemple, dans SQL, l'interrogation par pays est tout aussi lente que l'analyse NoSQL de tous les utilisateurs, sauf si vous avez explicitement demandé à SQL d'indexer la table users par pays. NoSQL peut faire de même, où vous créez une collection clé-valeur ordonnée qui est l'index (tout comme SQL le fait sous le capot) et le maintenez.
La différence? Les moteurs SQL avaient le concept d'indexation de la table intégré. Cela signifie que vous devez faire moins de travail (tout ce que vous aviez à faire était d'ajouter un index à la table). Cependant, cela signifie également que vous aviez moins de contrôle. Dans la plupart des cas, cette perte de contrôle est acceptable, en échange du moteur SQL qui fait le travail pour vous. Cependant, dans les ensembles de données massifs, vous souhaiterez peut-être un modèle de cohérence différent du modèle ACID SQL 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, il doit donc être fait 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 assez 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 valeurs-clés , qui est une sorte de base de données où un blob de données est stocké sous une clé, et peut être rapidement consulté si vous connaissez la clé. Ces bases de données sont incroyablement rapides si vous connaissez la clé exacte, mais comme vous le dites vous-même, si vous avez besoin de rechercher ou de filtrer sur plusieurs propriétés des données, cela sera lent et encombrant.
Personne sensé ne prétendrait que les magasins de valeurs-clés peuvent remplacer les bases de données relationnelles en général. Cependant, il peut y avoir des cas d'utilisation particuliers où le magasin de valeurs-clés est un bon ajustement. Les magasins de valeurs-clés sont souvent utilisés pour la mise en cache, car vous mettez généralement les éléments en cache par identifiant, mais vous n'avez pas besoin d'effectuer des requêtes ad hoc sur les caches. Par exemple, le site Stackoverflow lui-même utilise Redis (une valeur-clé db) largement , mais uniquement pour la mise en cache de 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 si vous avez seulement besoin de stocker et de rechercher à l'aide d'une seule clé. Sinon, utilisez un autre type de base de données. Et si vous avez un doute, utilisez une base de données relationnelle, car il s'agit du type de base de données le plus polyvalent, tandis 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 copier une copie sur un seul serveur. Ensuite, vous commencez à rencontrer toutes sortes de problèmes intéressants. Comment répartissez-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 conservez-vous 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 devrait-elle être optimisée géographiquement pour lire des tweets ou écrire des tweets?
Il s'avère que lorsque vous traitez 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 regrouper toutes vos données sur une seule boîte, vous n'obtenez que les restrictions et vous n'avez pas besoin des avantages.
Les bases de données NoSQL ont très peu à voir avec "No SQL".
Ils consistent à 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 n'importe quelle requête.
Dans une base de données NoSQL, le programmeur est responsable de la maintenance de nombreux index et il est supposé que les index seront toujours obsolètes.
Par exemple:
- Un index des personnes par numéro de taxe peut contenir certaines personnes qui ne terminent jamais le processus d'inscription à la taxe.
- Par conséquent, le code qui utilise l'index doit être en mesure de faire face à l'enregistrement incomplet de la taxe
- Une autre option consiste à avoir des moments où une personne qui est inscrite à l'impôt n'est pas dans l'indice. (Ainsi, votre conception doit faire face à l'absence de données cohérentes et décider de la façon dont les données ne seront pas cohérentes.)
Comme un exemple réel, Amazon préfère 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é.
Par conséquent .....
Si une seule base de données relationnelle normale peut contenir toutes vos données et traiter chaque transaction assez rapidement pour que le verrouillage n'empêche pas votre système de faire 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 les transactions pour éviter les erreurs de verrouillage, vous allez devoir faire face au type 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 d'être obligé d'utiliser NoSQL pour stocker vos données. =
Les bases de données relationnelles sont optimisées pour rechercher efficacement toute valeur dans la file de données.
Ne confondez pas la possibilité de rechercher "n'importe quelle valeur" dans une ligne avec "chaque" valeur dans une ligne. Pour ce faire, la manière la plus efficace nécessite un ou plusieurs index. Vous pouvez avoir des index incluant tous les champs, mais vous venez de gêner votre capacité à apporter des modifications qui nécessitent de modifier l'index (insertions, mises à jour, suppressions). Vous (ou votre DBA) devez comprendre les données, l'utilisation, les goulots d'étranglement, etc.