Caractéristiques des bases de données NoSQL

2.1 Émergence du terme NoSQL

Récemment, le terme "NoSQL" est devenu très à la mode et populaire, toutes sortes de solutions logicielles sont activement développées et promues sous ce signe. NoSQL est devenu synonyme d'énormes quantités de données, d'évolutivité linéaire, de clusters, de tolérance aux pannes, de non-relationnalité. Cependant, peu de gens ont une compréhension claire de ce qu'est le stockage NoSQL, comment le terme est apparu et quelles caractéristiques communes ils ont. Essayons de combler cette lacune.

La chose la plus intéressante à propos de ce terme est que malgré le fait qu'il ait été utilisé pour la première fois à la fin des années 90, il n'a acquis un sens réel sous la forme dans laquelle il est utilisé maintenant qu'à la mi-2009. -base de données source créée par Carlo Strozzi, qui stockait toutes les données sous forme de fichiers ASCII et utilisait des scripts shell au lieu de SQL pour accéder aux données. Cela n'avait rien à voir avec "NoSQL" dans sa forme actuelle.

En juin 2009, Johan Oskarsson a organisé une réunion à San Francisco pour discuter des nouvelles tendances du marché du stockage et du traitement informatique. L'impulsion principale de la réunion était de nouveaux produits open source comme BigTable et Dynamo. Pour un signe lumineux pour une réunion, il fallait trouver un terme volumineux et concis qui s'intégrerait parfaitement dans le hashtag Twitter. L'un de ces termes a été proposé par Eric Evans de RackSpace - "NoSQL". Le terme était prévu pour une seule réunion et n'avait pas de charge sémantique profonde, mais il se trouve qu'il s'est répandu sur le réseau mondial comme une publicité virale et est devenu le nom de facto de toute une direction de l'industrie informatique. Au fait, Voldemort (clone Amazon Dynamo), Cassandra, Hbase (analogues de Google BigTable), Hypertable, CouchDB, MongoDB ont pris la parole lors de la conférence.

Il convient de souligner une fois de plus que le terme "NoSQL" est d'origine complètement spontanée et n'a pas de définition généralement acceptée ou d'institution scientifique derrière lui. Cette appellation caractérise plutôt le vecteur de développement informatique loin des bases de données relationnelles. Il signifie Not Only SQL, bien qu'il y ait des partisans de la définition directe de No SQL. Pramod Sadalaj et Martin Fowler ont tenté de regrouper et de systématiser les connaissances sur le monde NoSQL dans leur récent livre "NoSQL Distilled".

2.2 Caractéristiques de base des bases de données NoSQL

Il existe peu de caractéristiques communes à tous les NoSQL, car de nombreux systèmes hétérogènes sont désormais cachés sous le label NoSQL (peut-être que la liste la plus complète se trouve sur http://nosql-database.org/). De nombreuses caractéristiques ne sont propres qu'à certaines bases de données NoSQL, je le mentionnerai certainement lors de la liste.

1. Aucun SQL n'est utilisé

Je veux dire ANSI SQL DML, car de nombreuses bases de données essaient d'utiliser des langages de requête similaires à la syntaxe préférée bien connue, mais personne n'a réussi à l'implémenter complètement et il est peu probable qu'elle réussisse. Bien qu'il y ait des rumeurs selon lesquelles des startups essaient d'implémenter SQL, par exemple dans hadup ( http://www.drawntoscalehq.com/ et http://www.hadapt.com/ ).

2. Non structuré (sans schéma)

Le sens est que dans les bases de données NoSQL, contrairement aux bases de données relationnelles, la structure des données n'est pas réglementée (ou faiblement typée, si nous faisons des analogies avec les langages de programmation) - vous pouvez ajouter un champ arbitraire dans une ligne ou un document séparé sans d'abord modifier de manière déclarative la structure de tout le tableau. Ainsi, s'il est nécessaire de modifier le modèle de données, la seule action suffisante consiste à refléter le changement dans le code de l'application.

Par exemple, lorsque vous renommez un champ dans MongoDB :

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

Si nous modifions la logique d'application, nous attendons également un nouveau champ lors de la lecture. Mais en raison de l'absence de schéma de données, le champ totalSum est absent des autres objets Order déjà existants. Dans cette situation, il existe deux options pour une action ultérieure.

La première consiste à explorer tous les documents et à mettre à jour ce champ dans tous les documents existants. En raison du volume de données, ce processus se produit sans aucun verrou (comparable à la commande alter table rename column), ainsi pendant la mise à jour, les données déjà existantes peuvent être lues par d'autres processus. Par conséquent, la deuxième option - archiver le code de l'application - est inévitable :

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

Et déjà lorsque nous réenregistrerons, nous écrirons ce champ dans la base de données dans un nouveau format.

Une conséquence agréable de l'absence de schéma est l'efficacité du travail avec des données éparses. Si un document a un champ date_published et que le second n'en a pas, aucun champ date_published vide ne sera créé pour le second. Ceci, en principe, est logique, mais un exemple moins évident est celui des bases de données NoSQL à famille de colonnes, qui utilisent les concepts familiers de tables/colonnes. Cependant, en raison de l'absence de schéma, les colonnes ne sont pas déclarées de manière déclarative et peuvent être modifiées/ajoutées pendant la session de base de données d'un utilisateur. Cela permet notamment l'utilisation de colonnes dynamiques pour la mise en place de listes.

Le schéma non structuré a ses inconvénients - en plus de la surcharge mentionnée ci-dessus dans le code de l'application lors du changement de modèle de données - l'absence de toutes sortes de restrictions de la base (non nul, unique, contrainte de vérification, etc.), plus il sont des difficultés supplémentaires pour comprendre et contrôler les données de structure lorsque l'on travaille avec la base de données de différents projets en parallèle (il n'y a pas de dictionnaires du côté de la base de données). Cependant, dans un monde moderne en évolution rapide, une telle flexibilité reste un avantage. Un exemple est Twitter, qui il y a cinq ans, avec le tweet, ne stockait que peu d'informations supplémentaires (heure, identifiant Twitter et quelques octets supplémentaires de méta-informations), mais maintenant, en plus du message lui-même, quelques informations supplémentaires kilo-octets de métadonnées sont stockés dans la base de données.

(Ci-après, nous parlons principalement de bases de données de valeurs-clés, de documents et de familles de colonnes, les bases de données de graphes peuvent ne pas avoir ces propriétés)

2.3. Représentation des données sous forme d'agrégats (agrégats)

Contrairement au modèle relationnel, qui stocke l'entité commerciale logique de l'application dans diverses tables physiques à des fins de normalisation, les magasins NoSQL fonctionnent sur ces entités comme des objets holistiques :

Cet exemple illustre les agrégations pour un modèle relationnel conceptuel de commerce électronique standard "Commande - Articles de commande - Paiements - Produit". Dans les deux cas, la commande est combinée avec des positions dans un objet logique, tandis que chaque position stocke un lien vers le produit et certains de ses attributs, par exemple, le nom (une telle dénormalisation est nécessaire pour ne pas demander un objet produit lors de la récupération un ordre - la règle principale des systèmes distribués est la "jointure" entre objets). Dans un agrégat, les paiements sont combinés à la commande et font partie intégrante de l'objet, dans l'autre ils sont placés dans un objet séparé. Cela démontre la règle principale pour concevoir une structure de données dans les bases de données NoSQL - elle doit obéir aux exigences de l'application et être optimisée autant que possible pour les requêtes les plus fréquentes.

Beaucoup s'y opposeront, notant que travailler avec des objets volumineux, souvent dénormalisés, pose de nombreux problèmes lors de la tentative de requêtes arbitraires sur des données lorsque les requêtes ne rentrent pas dans la structure des agrégats. Que se passe-t-il si nous utilisons des commandes avec des éléments de ligne de commande et des paiements (c'est ainsi que l'application fonctionne), mais que l'entreprise nous demande de compter combien d'unités d'un produit particulier ont été vendues le mois dernier ? Dans ce cas, au lieu de scanner la table OrderItem (dans le cas d'un modèle relationnel), nous devrons récupérer l'intégralité des commandes dans le stockage NoSQL, même si nous n'aurons pas besoin de beaucoup de ces informations. Malheureusement, c'est un compromis qu'il faut faire dans un système distribué : on ne peut pas normaliser les données comme dans un système classique à serveur unique,

J'ai essayé de regrouper les avantages et les inconvénients des deux approches dans un tableau :