Liste de partage de Grorico
En 2006, la Nasa stupéfiait la...
Pendant longtemps, les bases de données relationnelles ont été l'unique solution pour enregistrer des données, ou en tout cas, la solution adoptée par défaut par beaucoup de monde sans plus de réflexion sur le sujet. Pourtant, certaines personnes considèrent que le problème de stockage de données est en fait multiple et qu'il convient de se poser de nombreuses questions :
- Est-ce que les données sont fortement structurées ou non ?
- Quel est le ratio entre les lectures et les écritures ?
- Est-il acceptable de perdre un enregistrement sur un million ? Sur un milliard ?
- Est-ce que les données sont réparties sur plusieurs data-centres ?
- Est-ce que la taille des données peut être multipliée par 10 en l'espace d'un mois ?
- Quelle indisponibilité du service peut-on se permettre ?
- Etc.
Les bases de données relationnelles proposent leurs réponses à ces questions ; elles peuvent paraître raisonnables dans bien des cas, mais pas toujours. Par exemple, les bases de données relationnelles sont très mal adaptées quand on veut privilégier les performances plutôt que la garantie d'écriture des données.
Aussi, pour répondre à ces problématiques différentes, un mouvement, NoSQL, a proposé d'adopter des outils différents, spécialisés pour certains cas d'usage. Certaines bases de données NoSQL sont destinées à traiter d'énormes volumes de données, d'autres sont conçues pour maximiser le nombre de requêtes par seconde qu'un serveur pourra traiter, etc. Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon), ce qui tend à valider le besoin d'avoir d'autres outils que les bases de données relationnelles.
NdA : Merci à Christophe Turbout, Thomas Douillard, Buf, olivierweb, Spack, baud123, Bruno Michel, mike.simonson et rakoo pour leur aide lors de la rédaction de cette dépêche
- lien n°1 : Comparaison de différentes BD NoSQL
- lien n°2 : Tag NoSQL sur LinuxFr.org
Sommaire
- Base de données clef-valeur
- Base de données colonnes
- Base de données documents
- Base de données graphe
- Base de données hiérarchique
- Base de données objet
- Autres bases de données NoSQL
- Avantages des bases de données relationnelles
- UnQL le SQL du NoSQL
Base de données clef-valeur
Définition
C'est une simple correspondance entre une clef et une valeur (comme une table de hachage par exemple). L'intérêt par rapport à une bête table de hachage en mémoire, c'est de pouvoir mutualiser cette table sur le réseau sur un (ou plusieurs) serveur(s) dédié(s) afin de partager les informations sur tous les serveurs applicatifs.
Un autre avantage est la possibilité de gérer l'expiration des données. On rencontre souvent deux stratégies : limiter la taille globale de l'espace mémoire consommé (quand il n'y a plus assez de place pour enregistrer un nouvel élément, on éjecte un ancien selon un algorithme LRU) ou associer un temps de vie aux valeurs.
Pour garantir des performances maximales, ces solutions ne permettent généralement pas de parcourir des clefs mais juste de faire des lectures ou écritures sur une clef connue. Notons toutefois que Redis permet d'aller plus loin en proposant un typage des données en chaîne de caractères, listes, tableaux associatifs et ensembles triés d'éléments, et propose des opérations avancées propres à chaque type.
Les cas d'utilisation typiques sont l'utilisation en tant que cache, pour conserver les sessions d'un site web, comme stockage pour des files d'attentes, accumuler des événements bruts en vue d'en agréger des statistiques, et plus généralement pour toutes les données semi-persistantes (données que l'on conserve que pendant un laps de temps assez réduit pouvant aller de quelques secondes à quelques jours).
Exemples
- Memcached : les données sont stockées uniquement en RAM, lorsque le programme s'arrête, les données sont perdues. On imagine bien que c'est plus utile pour du cache que pour des données importantes.
- CouchBase : la version "compliquée" de memcached, avec cluster, interface d'administration et compagnie.
- Redis : toutes les données sont stockées en RAM mais il existe deux modes pour la persistance, souvent combinés ensemble (écrire dans un journal ou enregistrer régulièrement l'intégralité des données dans un fichier, opération souvent faite sur un nœud esclave).
Base de données colonnes
Définition
C'est un type de base de données fort semblable aux bases SQL, les données sont stockées de manière structurée, par exemple :
| Titre | Auteur | Score |
|---|---|---|
| Actus ACTA en ce début mars | Oumph | 15 |
| Petites brèves Ruby | NoNo | 16 |
| Sortie du noyau Linux 3.3 | patrick_g | 109 |
Cette famille de bases de données provient des gros acteurs et visent donc à répondre à leurs besoins. Elles sont donc capables d'enregistrer des volumes très importants de données, travaillent généralement sur des clusters de quelques dizaines à quelques centaines de serveurs, souvent répartis sur plusieurs datacentres. Elles font souvent le choix de privilégier les performances au détriment du nombre de fonctionnalités supportées.
Exemples
- BigTable : la base de données de Google ;
- HBase : la base de données utilisée par le projet Hadoop ;
- Cassandra : la base de données NoSQL de la fondation Apache, initialement développée par Facebook.
Base de données documents
Définition
C'est un type de base de données destinée à stocker des documents (qui l'aurait cru ?). Assez proche du modèle des bases SQL, les bases de documents n'en offrent pas moins une souplesse bien plus grande. Certains documents d'une collection peuvent avoir des champs supplémentaires. Par exemple, on peut stocker un texte qui a un auteur et un contenu ; un article qui a, en plus du texte, une date, une revue d'origine ; un livre qui a, en plus du texte, un titre, une année de publication, un nombre de pages…
En outre, le contenu d'un document ne se limite pas à des attributs simples, on peut également avoir des tableaux (une liste de tags par exemple), voire inclure un autre document dans celui-ci. Par exemple, il est possible de stocker les commentaires liés à un article directement dans celui-ci, sous forme d'un tableau d'objets dépendants (même si ce n'est pas toujours une bonne idée en pratique ;-) ).
Enfin, il est difficile de caractériser plus précisément les bases de données documents, car c'est la famille de bases NoSQL la plus diversifiée. D'un coté, on peut trouver des solutions dont le requêtage se fait avec du map-reduce et, de l'autre coté, MongoDB cherche "juste" à être un MySQL plus adapté pour les applications web modernes (avec un certain succès !) et à le remplacer.
Exemples
- MongoDB : la base de données documents la plus populaire actuellement ;
- CouchDB : une des toutes premières bases de données NoSQL, dont l'heure de gloire est probablement passée depuis un bout de temps, elle est accessible en HTTP directement (avec
get,put…), ce qui la rend très accessible. Plus de détails dans un commentaire de LinuxFR.org ; - Riak : une base de données documents dont l'une des forces est de pouvoir très simplement ajouter (ou retirer) un serveur.
Base de données graphe
Définition
Ces systèmes sont prévus pour stocker des graphes (dans le sens de la théorie des graphes), il y a donc des nœuds avec des attributs et, surtout, des liens entre les différents nœuds.
Un cas typique d'utilisation est le stockage de graphe RDF. Pour certains, c'est aussi le moyen le plus performant pour stocker des objets du paradigme orienté objet à cause des références entre ces derniers.
L'autre cas d'école des bases de données graphe est le stockage d'un réseau social. Cela permet de parcourir les relations entre utilisateurs. On s'en sert notamment pour faire des moteurs de recommandations : vous êtes sûrement intéressé par tel ou tel objet car beaucoup de vos amis et des amis de vos amis le sont aussi.
Exemple
Base de données hiérarchique
Ces bases sont utilisées pour gérer des ensembles ainsi que des sous ensembles. Les bases de données géographiques utilisent souvent ce modèle.
Base de données objet
Définition
Les bases de données objets permettent de stocker la valeur des attributs objets (au sens de la programmation orienté objet) ainsi que les relations d'héritage et les références entre les objets. Certains systèmes permettent même d'exécuter les méthodes des objets directement dans la base de données.
Ces bases de données sont, en pratique, plutôt proches du modèle relationnel et plusieurs systèmes de gestion de base de données relationnelles permettent d'avoir un système accessible tant en mode relationnel qu'en mode objet.
Autres bases de données NoSQL
Enfin, il existe des bases NoSQL qui ne rentrent pas vraiment dans les cases précédentes. Par exemple, Pincaster est une base de données particulièrement bien adaptée pour les données géographiques, bien qu'elle puisse faire bien plus que ça.
Dans un style différent, Elastic Search propose une interface Rest au-dessus des index Lucene. Cela en fait une solution particulièrement efficace pour faire de la recherche, que celle-ci soit en full-text, avec des facettes, des critères multiples ou un mélange de tout cela.
Avantages des bases de données relationnelles
Il est clair que le NoSQL n'est pas adapté à toutes les situations.
Les bases NoSQL sont généralement assez limitées au niveau du support des transactions. Si l'édition d'un objet se fait en principe de manière atomique, dès qu'il s'agit de modifier plusieurs objets dépendant les uns des autres, la base n'offre plus les garanties qu'on retrouve avec le relationnel.
Plus globalement, les Propriétés ACID ainsi que les contraintes d'intégrité ne sont généralement pas implémentées par les bases de données NoSQL, cela délègue cette gestion à la partie applicative. Les optimistes diront qu'il est souvent plus facile de répartir la charge du côté applicatif que base de données et que cela permet donc d'avoir de meilleurs performances globales.
Le relationnel dispose également d'un langage de requête extrêmement puissant, qui offre des possibilités très larges, avec en particulier la possibilité de lier des tables entre elles, filtrer et trier selon de nombreux critères ou agréger les données. Ceci est particulièrement utile quand il s'agit de générer des rapports complexes, domaine dans le lequel les bases de données relationnelles sont très à l'aise.
Du fait de son langage de requête plus poussé et des optimisations qui peuvent en être tirées, les bases SQL sont souvent plus performantes sur les requêtes complexes qui nécessiteraient de rapatrier plus de données que nécessaire pour les traiter en NoSQL. Sinon, tant qu'on peut conserver les index en cache, les performances sont très bonnes quelque soit le type de bases de données. Par contre, certaines recherches spécifiques sont bien plus performantes avec des systèmes adaptés (par exemple, la recherche full-text avec Lucene via ElasticSearch).
UnQL le SQL du NoSQL
UnQL pour Unstructured Query Language est un langage de requête pour les bases de données NoSQL, il a été créé dans le but de pouvoir interroger des collections de données (et pas uniquement des tables) et ces données contiennent différents champs. En ne tenant pas compte de l'âge des deux langages, on peut voir SQL comme une spécification d'UnQL.
Pour l'instant, il n'y a pas d'équivalent à la partie DDL (data definition language) de SQL, ce qui peut se comprendre vu la grande diversité des conteneurs de stockage et l'absence de schémas pour beaucoup des bases NoSQL
NdM. : le site LinuxFr.org utilise côté NoSQL ElasticSearch et Redis, et côté relationnel MySQL.
« Dites au revoir à votre souris et votre clavier », clament les créateurs de Leap Motion. Cette technologie de détection des mouvements qui...
