human
Mouvement MongoDB et NoSQL . Qu'est-ce qui est cassé avec les bases de données basées sur SQL, et quel problème Mongo et ses amis résolvent-ils ? Explique comme si j'avais cinq ans.
gpt
Du point de vue du design, parfois les tables ne sont pas toujours le meilleur outil pour le travail. Par exemple, disons que vous avez un profil d'utilisateur qui stocke toutes les choses préférées d'une personne. À moins que votre profil utilisateur ne stocke * uniquement * ses éléments préférés , vous aurez besoin de plusieurs tables pour stocker les données utilisateur : Favoris : [ i d ] [ film ] [ nourriture ] [ livre ] [ émission de télévision ] Métadonnées : [ i d ] [ dernière connexion ] [ lieu à 5h24 ce matin ] [ lat / long de la dernière pipe ] Messages [ i d ] [ post - id ] Et ainsi de suite . Avec un système NoSQL, vous pouvez organiser les choses comme les humains pensent réellement. Voici un exemple de la façon dont j'organiserais ces mêmes informations : user.[id].favorites { map of favorite things } user.[id].metadata { map of metadata } user.[id].posts [ [ set of post-ids]] C'est une manière beaucoup plus intuitive d'organiser l'information, et permet une dimension supplémentaire qui est plus difficile à visualiser avec des tableaux 2-D. Cela facilite également l'extraction d'un bloc entier de toutes les données utilisateur en un seul paquet dans un pipeline, au lieu d'avoir exécuté des requêtes sur plusieurs tables, et les données sont déjà organisées d'une manière qui peut être facilement "envoyée" (via JSON , ou autre , par exemple ) . Vous n'avez pas non plus nécessairement à gérer autant les types de données. Par exemple, dans Redis, tout est stocké sous forme de chaîne. Cela signifie , bien sûr , que la base de données ne peut pas nécessairement s'occuper de votre logique pour vous : ` select ( select age from user where i d = 100 ) * 7 ` ( full divulgation : I have n't used a SQL système depuis des années , il s'agit donc probablement d' une syntaxe incorrecte ) . Avec NoSQL , beaucoup plus de responsabilité incombe au programme lui - même qui interroge les données . Il y a bien sûr des pièges inhérents aux systèmes NoSQL : en n'étant pas limité aux tables , il est vraiment facile d' avoir des données vraiment bâclées ( il est facile de créer des " raccourcis " parce que vous avez oublié cette dimension de données dont vous aviez besoin , et cela crée un effet boule de neige qui devient un clusterfuck géant ) . Beaucoup de gens ne réalisent pas que vous devez toujours créer un schéma, même s'il n'est pas appliqué par la base de données elle-même, il doit être facilement reflété dans la programmation et la documentation. Sans vérification du type de données du côté de la base de données, cela doit être fait dans la programmation, sinon les données inutiles peuvent se répandre car les données ne seront pas nécessairement rejetées par la base de données, provoquant une exception d'écriture - elles ne feront que s'infecter à l'intérieur jusqu'au jour où tu réalises que tu t'es fait baiser. Cela dit, il y a aussi des avantages à utiliser les systèmes NoSQL. L'ajout de nouvelles dimensions aux données est trivial, ou l'ajout d'un autre niveau de hiérarchie aux informations. Si vous souhaitez maintenant stocker le restaurant préféré d'un utilisateur, il vous suffit d'ajouter une nouvelle clé à cette carte, vous n'avez pas besoin de modifier une table entière. Si vous souhaitez maintenant ajouter une nouvelle section au site où un utilisateur peut suivre chaque repas qu'il a déjà mangé , vous n'avez pas besoin de modifier une base de données fondamentale , il vous suffit d' écrire dans les nouvelles clés de votre conception ` user.[id].meals [ [ ensemble d'identifiants de repas ] ] -> user.[id].meals.[meal - id ] { carte des attributs de repas } ` . Il y a souvent moins de frais généraux associés aux trucs NoSQL aussi , puisque la base de données elle - même ne fait pas beaucoup de vérification , et elle est élastique dans la mesure où lorsque vous ajoutez un nouvel utilisateur , vous ne lui réservez que de l' espace en mémoire ou sur disque selon les besoins , plutôt que de les configurer avec des lignes sur chaque table , ce qui occupe immédiatement de l' espace pour être rempli plus tard . Bien que cela réduise l'empreinte globale, cela présente des problèmes de mise à l'échelle potentiels, car il est plus difficile de savoir * quand * et * comment * vous devrez effectuer la mise à l'échelle. Dans un système SQL strictement typé, vous savez exactement combien d'octets seront réservés à un utilisateur lors de la création et pouvez travailler avec cela en conséquence ; vous n'avez pas ce contrôle dans un système NoSQL. Comme avec n'importe quel élément technologique, choisir l'un plutôt que l'autre a des coûts et des avantages, et parfois l'un est un meilleur outil que l'autre.