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
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.
Aller plus loin
- Comparaison de différentes BD NoSQL (1170 clics)
- Tag NoSQL sur LinuxFr.org (293 clics)
# Théorème CAP
Posté par claudex . Évalué à 10.
On me signale dans l'oreillette que beaucoup d'implémentation de base NoSQL prennent en compte le Théorème CAP qui dit
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Théorème CAP
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Ce théorème s'applique aussi aux bases de données relationnelles. Par exemple, MySQL Cluster garantit la cohérence et la résistance aux pannes réseau, au détriment de la disponibilité. Cf http://messagepassing.blogspot.fr/2012/03/cap-theorem-and-mysql-cluster.html
Les bases de données NoSQL prennent en compte le théorème CAP dans le sens où toutes ces solutions n'ont pas fait les mêmes choix (certaines privilégient la disponibilité à la cohérence) et certaines solutions permettent même de faire ce choix par base de données. Cf http://wiki.basho.com/Tunable-CAP-Controls-in-Riak.html par exemple.
[^] # Re: Théorème CAP
Posté par leovilok . Évalué à -4.
Y a bien Internet d'une certaine façon qui le fait …
[^] # Re: Théorème CAP
Posté par Marotte ⛧ . Évalué à 3.
J'ai un doute quand à la cohérence…
[^] # Re: Théorème CAP
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
C'est : "quant à à la cohérence…". Quand est relatif à une date, une durée et "quant à" signifie "en ce qui concerne". On peut se mémoriser cela en pensant à quantité qui n'est pas un temps.
[^] # Re: Théorème CAP
Posté par sebas . Évalué à 1.
Quant à moi, je suis d'accord, mais quand même, il y a des doutes quant à d'autres expressions de temps : par exemple, doit-on écrire "autant pour moi" (comme je l'ai toujours fait) ou "au temps pour moi" (comme je le lis souvent dans les forums).
Réponse moins nette que pour quant/quand :
http://www.expressio.fr/expressions/autant-au-temps-pour-moi.php
Confirmation sur le dico de l'académie :
[^] # Re: Théorème CAP
Posté par ElectronLibre63 . Évalué à 2.
Le problème est que cette expression est souvent mal employée. Au temps pour moi s’emploie lorsqu'on se rend compte de son erreur à temps avant que quelqu'un nous le fasse remarquer.
Usage correct :
— La distribution Linux, oups, au temps pour moi, je voulais dire le noyau Linux.
Usage incorrect :
— La distribution Linux…
— Linux est un noyau, pas une distribution.
— Ha ouais, au temps pour moi.
En tout cas c'est ce que m'avait dit un de mes prof de français. Mais comme j'ai eu aussi un prof qui disait qu'il ne fallait pas mettre les accents sur les majuscules, ça vaut ce que ça vaut.
[^] # Re: Théorème CAP
Posté par Marotte ⛧ . Évalué à 0.
Je crois que c'est le cas pour l'écriture manuscrite (manuscrite dans le sens pas en caractères d'imprimerie).
[^] # Re: Théorème CAP
Posté par Mais qui suis-je ? :) . Évalué à 2.
Question bête,
Est-ce vraiment un théorème ?
Au sens ça ce démontre vraiment ?
Car par l'absurde, avec une approche de très bas niveau j'ai
Si je vois les mêmes donnée au même moment sur tous les nœuds qui fonctionnent, ça veut dire qu'ils sont synchronisé de manière instantanée, j'ai donc une violation de causalité CQFD.
Dans ces conditions, je trouve que nommer ça un théorème c'est un peu prétentieux, Ce n'est qu'une conséquence pratique des loi de la relativité (et même sans relativité, la bande passante n'est pas infinie)
Où alors y a t'il un truc que j'ai pas saisi. J'imagine que même en informatique théorique on ne peut accepter d'avoir une bande passante infinie, ou de transmettre de l'info plus vite que c
[^] # Re: Théorème CAP
Posté par Batchyx . Évalué à 6.
Cohérence, ce n'est pas vraiment "je vois les mêmes données partout", mais "si je fait une requête sur les mêmes données sur n'importe quel nœuds, au final je récupère les mêmes données (ou rien du tout si le nœuds est indisponible)". Sachant que si un nœud ne possède pas la donnée, il à bien entendu le droit de le demander à ses voisins… S'il peut les joindre.
Bien sûr, ça se démontre, mais c'est quand même assez naturel comme théorème. Prenons un cas simple : deux nœuds qui partagent la même information.
Le lien entre les deux tombe (donc le système se retrouve morcelé). On demande à un des nœuds de modifier une donnée.
1. Si il accepte la modification, alors la cohérence n'est pas vérifiée (si on demande aux deux nœud la valeur de la donnée, ils ne répondront pas la même chose). Mais il reste disponible et il tolère le partitionnement.
2. Si il refuse la modification, alors la disponibilité n'est pas vérifiée. Mais il reste cohérent et tolère le partitionnement.
3. Si le système accepte la modification mais renvoie l'ancienne donnée, ou de manière générale, se comporte autrement que dans le 1) ou le 2), alors il ne marche pas. S'il marchait très bien avant que le lien tombe, alors il ne tolère pas le morcellement. Mais sinon, il reste cohérent et disponible quand il n'est pas morcelé.
[^] # Re: Théorème CAP
Posté par Kerro . Évalué à 2.
La traduction induit en erreur.
Le truc est juste que le point 3 n'est pas traduisible par tolérance de panne, mais par la résistance au morcellement. C'est à dire que si mes 2000 serveurs sont coupés en deux groupes par un panne réseau, chaque moitié continue à fonctionner de manière autonome.
Et là forcément, à la première modification qui passe il n'y a plus de point 1 qui tienne.
[^] # Re: Théorème CAP
Posté par ckyl . Évalué à 2.
http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
Je pense qu'un peu de lecture sur les systèmes distribués pourraient t'être utile pour comprendre la discipline. Y'a de très bons bouquins et cours ;)
# Budget RAM
Posté par __o . Évalué à 10. Dernière modification le 07 mai 2012 à 15:26.
Les SGBD relationnels sont traditionnellement optimisés pour fonctionner dans un environnement où les données et même les indexes sont bien plus gros que la RAM. Ces SGBD font donc tout pour limiter le nombre d'I/O, essayer de lire les données séquentiellement, etc.
Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM (en particulier les BDD clé-valeur et documents), ou assument que les données sont cachées en RAM par le système. Ça peut poser de sérieux problèmes le jour où les performances s'écroulent d'un coup parce que les données sont devenues plus grosses que la RAM.
Au final les SGBD traditionnels sont plus performants qu'un certain nombre de bases NoSQL, lorsque les données doivent être lues sur le disque.
Il y en a qui en reviennent [1]
Les systèmes NoSQL utilisés par ceux là répondent plus à des problèmes de haute disponibilité, de scalabilité et de souplesse que de performances: Fragmentation (sharding) automatique, changement de schema à chaud, etc.
Twitter utilise encore MySQL comme stockage principal [2].
Youtube utilise MySQL également. D'ailleurs ils ont démarré un projet intéressant pour gérer automatiquement le sharding, etc [3].
Facebook aussi utilise MySQL pour beaucoup de choses [4].
Google utilise beaucoup MySQL également.
[1] http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb
[2] http://engineering.twitter.com/2012/04/mysql-at-twitter.html MySQL is the persistent storage technology behind most Twitter data: the interest graph, timelines, user data and the Tweets themselves.
[3] https://code.google.com/p/vitess/wiki/ProjectGoals
[4] http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/ MySQL handles pretty much every user interaction: likes, shares, status updates, alerts, requests, etc.
[^] # Re: Budget RAM
Posté par Artefact2 (site web personnel) . Évalué à 2.
Wikipédia aussi utilise principalement MySQL.
[^] # Re: Budget RAM
Posté par Jux (site web personnel) . Évalué à 10.
Même si Google utilise MySQL, leur index est dans une base NoSQL (BigTable). Facebook est aussi à l'origine de Cassandra (base NoSQL) et ils sont passés à HBase pour leur fonction de recherche.
Donc c'est pas tant que les gens "reviennent" de NoSQL, c'est surtout que NoSQL n'est pas la réponse à tout et quand on a une application réellement relationelle, c'est souvent plus intelligent d'utilsier une base de données… relationelle.
En fait c'est comme souvent en informatique: il faut utiliser l'outil adapté, pas le dernier truc à la mode. Au début NoSQL a été adapté par plein de monde parce que ça permettait de "monter en charge comme Google". Sauf que pour 99% des applications, un serveur MySQL va probablement tenir la charge très bien.
J'avais lu un article (que je ne retrouve plus) d'un ingénieur qui bossait pour une de ces grosses boîtes 2.0 qui relevait qu'en fait pour monter en charge, la base de donnée n'est souvent pas le problème. C'est d'abord le code de l'appli qu'il faut revoir, la configuration des serveurs, du réseau, etc… Bref, à la limite, le jour ou la startup doit vraiment tenir un nombre énorme de connexions à la seconde, ils devront de toute façon tout revoir, même s'ils sont partis sur du NoSQL.
[^] # Re: Budget RAM
Posté par __o . Évalué à 2.
Tout à fait, par contre il semblerait qu'ils utilisent quand même MySQL pour “pretty much every user interaction: likes, shares, status updates, alerts, requests, etc” [1]
[1] http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/
[^] # Re: Budget RAM
Posté par Kerro . Évalué à 10.
Quoi ?! Mais comment vont vivre les SSII ?
[^] # Re: Budget RAM
Posté par Krunch (site web personnel) . Évalué à 4.
Alors chez nous justement on optimise pour les workloads qui tiennent pas en RAM. Il y a du Cassandra dedans mais on a refait toute la couche de storage et il y a une cholie interface de management par dessus pour les gens qui aiment pas le bloat/complexité de Cassandra: http://www.acunu.com/
</pub>
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Budget RAM
Posté par Zenitram (site web personnel) . Évalué à 7.
Tu as oublié un détail qui a son importance ici : Cassandra est libre, mais Acunu pas du tout!
[^] # Re: Budget RAM
Posté par El Titi . Évalué à 5.
Bravo !
En une phrase, tu l'as mis à poil.
# Et concrètement ?
Posté par rewind (Mastodon) . Évalué à 3.
Bon alors concrètement, comment je fais pour choisir ?
Par exemple, je veux faire un réseau social top moumoute jamais vu ailleurs, et bleu. J'utilise quoi ? Si je comprends bien, j'aurais intérêt à me tourner vers FlockDB, mais ça ne gère "que" le graphe. Et pour le reste, je fais comment ? Je mets un PostGreSQL ? Et comment je lie les deux ?
[^] # Re: Et concrètement ?
Posté par claudex . Évalué à 2.
ça dépend beaucoup de ce que tu veux stocker comme données. Mais lier les deux me semble assez simple mais c'est à toi d'écrire la couche de liaison.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et concrètement ?
Posté par rewind (Mastodon) . Évalué à 1.
Dans mon exemple, je veux stocker des messages de 142 caractères par exemple. Et je ne vois absolument pas comment lier les deux simplement.
[^] # Re: Et concrètement ?
Posté par kursus_hc . Évalué à 4.
Ha bah le temps que tu te poses la question c'est trop tard : quelqu'un l'a déjà fait à ta place.
# Intervalle entre SQL et NoSQL
Posté par Sygne (site web personnel) . Évalué à 5.
Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
Fossil, par exemple, utilise étrangement sa base sqlite: il stocke toutes les données, quelles qu'elles soient, en vrac, dans une unique table. Dans un second temps, il génère, à partir de ces données, des vues en relation les unes avec les autres. De fait, si la structure des vues est cassée, ou doit être changée, il suffit de lancer une commande pour reconstituer celles-ci à partir du vrac. Cf les pages Formats de fichiers de fossil et fossil est une base NoSQL.
[^] # Re: Intervalle entre SQL et NoSQL
Posté par rogo . Évalué à 5.
Suite au grand ramdam sur le NoSQL, beaucoup ont eu l'idée d'utiliser les moteurs de stockage des bases relationnelles pour en faire des SGBD non-relationnels de type clé-valeur. Par exemple, PostgreSQL Hstore et son pendant MySQL.
[^] # Re: Intervalle entre SQL et NoSQL
Posté par Sygne (site web personnel) . Évalué à 4.
Je ne suis pas certain que ce ne soit qu'un effet de mode. J'ai au contraire l'impression que cela relève d'une sorte de bonne pratique. Cela ressemble à un usage imprévu mais efficace d'une base SQL.
[^] # Re: Intervalle entre SQL et NoSQL
Posté par Antoine . Évalué à 4.
Cf. MySQL et MyISAM. Ça ne date pas d'hier…
[^] # Re: Intervalle entre SQL et NoSQL
Posté par stopspam . Évalué à 2.
C'est un peu comme si sur une base de données relationnelle tu mettais à jour le schéma. Pourquoi faire simple quand on peut faire compliqué…
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
# Livre blanc chez Smile
Posté par fero14041 . Évalué à 1.
Pour les ceusses et celles qui souhaiteraient un complément à la présente dépêche, en français, il est à noter que Smile a publié un "livre blanc" traitant du NoSQL.
[^] # Re: Livre blanc chez Smile
Posté par Antoine . Évalué à 8.
Il suffit de réunir un peu de doc et d'appeler ça "livre blanc" pour se faire mousser en se donnant l'air important.
[^] # Re: Livre blanc chez Smile
Posté par gemegik . Évalué à 4.
La question est : vont-ils réécrire voyages-sncf en nosql ? :)
# Elasticsearch
Posté par dadoonet (site web personnel) . Évalué à 2.
Bonjour,
A noter qu'on peut ranger déjà Elasticsearch dans les bases NoSQL orientées document. En effet, par configuration, il est possible par exemple de désactiver la recherche dans Elasticsearch et donc de le transformer en un simple système de persistance de documents.
On profite alors de la scalabilité native de ES (partitionnement, réplication, distribution, …). De fait, ES devient très comparable à ce qu'on trouve dans MongoDB.
D'ailleurs, Shay Banon, l'auteur d'Elasticsearch, a annoncé son intention d'investir sur cet axe pour les prochaines versions.
Quelques liens :
Le groupe Elasticsearch France
Présentation Elasticsearch à Devoxx France :
David
Developer | Evangelist at elastic
[^] # Re: Elasticsearch
Posté par rogo . Évalué à 2.
Effectivement, Elastic Search est assez comparable à MongoDB, avec en plus la recherche en texte intégral. Je l'aurais plutôt compaté à CouchDB qui a lui aussi une interface REST.
Par contre, en terme de légèreté et de consommation mémoire, ils ne sont pas dans la même catégorie. Le premier, ES, est une surcouche Java sur Lucene (Java) avec une API REST. Le second, MongoDB, est en C++ avec une API native. En pratique, même avec des petits jeux de données, ES est à l'étroit dans un VPS avec 1 Go de RAM.
A noter que MongoDB prévoit d'ajouter des index en texte intégral en 2012. https://jira.mongodb.org/browse/SERVER-380 : le ticket est dans le "Bucket A" qui désigne les fonctionnalités prévues pour la prochaine version majeure.
# FS
Posté par zerkman (site web personnel) . Évalué à 10.
Sérieusement ? J'utilise le système de fichiers pour cela, et ça marche très bien. En fait, pour enregistrer des données c'est même ce qu'il y a (encore) de mieux.
Après, s'il s'agit de traiter les données, de garantir une cohérence, effectivement on peut commencer à se poser la question d'une base de données.
C'est juste qu'en termes de design d'applications, certains développeurs web ou natif ont la fâcheuse tendance à utiliser une base de données pour tout et n'importe quoi.
[^] # Re: FS
Posté par barmic . Évalué à 1.
Je crois que beaucoup d'hébergeurs interdisent d'écrire sur le système de fichier ou mettent des quota très petits.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FS
Posté par __o . Évalué à 1. Dernière modification le 09 mai 2012 à 12:34.
Tu parles de quel genre d'hébergeur ? Parce que sur les hébergements mutualisés php, ça n'a pas l'air d'être le cas. Par exemple chez OVH l'hébergement à 1.99€ a 25Go d'espace disque ;)
[^] # Re: FS
Posté par ckyl . Évalué à 2.
Sur les hébergeurs low cost tu as quand même un grosse différence entre DB et file system. Les mecs bourrent leurs machines autant que possible, du coup tu as un cache disque en RAM est misérable et tu as des perfs moisies. Les serveurs utilisés pour les DB sont un peu mieux loti et ca marche mieux.
Après si tu paies un poil plus cher chez un hébergeur correct, ca peut être envisageable. Mon hébergeur à 8Go de cache disque pour 16Go de RAM, ca peut être envisageable pour un working set pas trop gros.
[^] # Re: FS
Posté par Buf (Mastodon) . Évalué à 2.
Le système de fichiers, c'est surtout beaucoup d'emmerdes potentielles au niveau des permissions.
En général, pour des raisons de sécurité, on aime bien faire tourner le serveur web avec un utilisateur le moins privilégié possible (et si possible différent de celui qui possède les fichiers de script). Bref, habituellement, on ne peut écrire nulle part (sauf répertoire temporaire)
Si on gère soi-même le serveur, on peut s'en sortir sans trop de mal, mais sur du mutualisé, c'est très souvent tout simplement impossible d'utiliser le système de fichier pour stocker autre chose que des fichiers statiques et les scripts pour les pages.
[^] # Re: FS
Posté par zerkman (site web personnel) . Évalué à 5.
Ce dont tu parles est un exemple pertinent d'utilisation de base de données, et peut se justifier dans beaucoup de cas.
Mais par exemple, tu peux trouver certaines applis web qui ne servent qu'à visualiser des données statiques (par exemple un album photo), mais qui vont quand même nécessiter une BDD.
De même, dans les applis natives (mobiles ou PC) cela se fait de plus en plus, sans réelle nécessité. Un ami s'est quand même vu conseiller par un mec de Microsoft (un organisateur du concours Imagine Cup), de stocker une banque d'images dans une base de données, encodées en base64, pour une appli sur tablette tactile. Pour un vieux routard de la programmation, il y a des choses que l'on n'aimerait jamais entendre.
[^] # Re: FS
Posté par Loïc Ibanez . Évalué à -2.
Je suis d'accord, stocker des données c'est le rôle du système de fichiers. Je ne comprends d'ailleurs que peu l'intérêt des "bases de données orientées documents". De ce que j'en comprends ce doit être assez proche du système de tag ID3 pour les fichiers audio qui est redoutablement efficace. Ces systèmes de tags existent déjà pour tous les types de documents ( pdf, open office, jpeg, etc…). Tout ce qui manque c'est un langage commun pour les interroger, situé au plus bas niveau possible pour la performance, donc dans le système de fichiers.
[^] # Re: FS
Posté par barmic . Évalué à 2.
Oui et non. Pour pouvoir refaire un système aussi efficace que peut l'être une base de données orienté document il faudrait que le système de fichier regarde l'intérieur des fichiers ce qui pose un paquet de problème.
On va vers un rapprochement de ces deux logiciels, mais en principe tu configure ta base en fonction de ton application (car la performance ça dépend du mode d'utilisation) ajouter ce genre de configuration dans le système de fichier ça apporte des dépendances qui ne sont pas forcément souhaitables (tu crée une partition virtuelle pour chaque application, tu as une dépendance forte avec ton système d'exploitation,…).
Pour que ce soit performant, il faut créer des indexes sur le contenu des fichiers. Actuellement les indexes sont créent sur les données des inodes (et c'est pas dans les inodes que l'on trouve les tag dont tu parle), c'est une grosse violation du design des système de fichiers (un peut comme le fait FTP avec ses modes passif/actif).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: FS
Posté par Buf (Mastodon) . Évalué à 2.
Euh… j'ai du mal à voir le rapport là.
# Et les géants ?
Posté par Barnabé . Évalué à 7.
On a souvent tort d'oublier sur quelles épaules on est juché.
Dire que les bases de données relationnelles ont pendant longtemps été l'unique solution pour enregistrer des données est juste faux. Il suffit de regarder dans son gestionnaire de paquet préféré la liste des paquets qui dépendent de libqdbm, libgdbm ou libdb pour s'en convaincre.
[^] # Re: Et les géants ?
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
En ce cas il faut plutôt parler des SGBD d'avant Codd:
AKA les modèles hiérarchiques et réseaux qui datent des années 70 et seront donc un peu plus difficiles à retrouver dans un gestionnaire de paquets. ;)
http://fr.wikipedia.org/wiki/CODASYL
[^] # Re: Et les géants ?
Posté par Franck Routier (Mastodon) . Évalué à 2.
Oui, ou même les bases hiérarchiques basées sur MUMPS (cf. http://en.wikipedia.org/wiki/MUMPS) et leur descendants, libres (http://www.cs.uni.edu/~okane/mumps.html) ou propriétaires (http://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9)
# Séparer stockage (relationnel) et recherche
Posté par rogo . Évalué à 9.
Après des années d'utilisation des SGBD (en fait, surtout MySQL et SQLite avec un peu de PostGreSQL), j'étais convaincu de leurs capacités, mais frustré de leurs limitations. Deux exemples simples :
Autre besoin fréquent, la recherche en texte entier. Les SGDBR sus-cités y ont fait de gros progrès, mais cela reste limité par rapport aux outils spécialisés. J'ai cherché du côté des bases NoSQL orientées documents qui permettent effectivement de résoudre les problèmes ci-dessus. Mais, en plus des problèmes de maturité et de confiance, la perte du modèle relationnel est parfois très pénible pour des données qui suivent bien ce modèle. Et (avant l'apparition d'Elasticsearch) aucune de ces bases NoSQL ne permettait la recherche en texte intégral.
Finalement, j'ai adopté une solution qui me satisfait (presque) totalement :
Pour sérialiser, PostGres propose un type "array". On peut aussi utiliser un texte JSON qui est portable et plus simple à gérer en amont. C'est très pratique à manipuler dans le langage applicatif. On ne peut plus trop faire de recherche SQL dessus, mais ce n'est pas un problème puisque seules les recherches basiques restent en SQL.
Pour la base de recherche, on a le choix entre Lucene/Solr, Sphinx search, Xapian, etc.
La seule difficulté, c'est de gérer l'indexation, c'est-à-dire l'extraction des données stockées pour les indexer, et surtout la synchronisation des données.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par stopspam . Évalué à 7.
Où est la complexité ?
De quelle volume parles-tu pour que le résultat ne sorte pas dans la seconde ?
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . Évalué à 2.
Exemple en MySQL, en prenant des tags d'id 22 et 33. La requête suivante est simple, mais fausse :
On peut s'en sortir avec :
S'il y a plus simple et plus efficace, je suis preneur.
Je n'ai pas testé ces requêtes, je ne garantis pas l'absence de fautes de syntaxe, mais le principe est que les règles "SAUF" sont difficiles sur du many2many.
De mémoire, les tailles de "Post" et "Post_Tag" étaient respectivement de l'ordre de 500k et 800k lignes et le temps de réponse de 4 secondes.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par barmic . Évalué à 1.
Je n'ai jamais eu a faire de benchmark, je ne sais pas quelles optimisations sont faites ou pas, mais je vois deux autres requêtes.
Avec des opérateurs ensemblistes :
Pour cette seconde, je suis à peu près certain que c'est possible mais, je ne suis vraiment pas certain de la syntaxe :
Dans la première le SGBD charge probablement 2 fois les deux tables (ce qui ne pose un problème pour la consommation mémoire mais pas pour les accès disques). Pour la seconde il lit une fois Post et 2 fois Post_Tag, mais il a l'avantage de ne pas faire des partitionnement et des regroupements (je ne sais pas si c'est efficace ou pas).
Ensuite si vraiment tu as trop de données tu peux regarder du coté des partitionnements de table. Ça peut permettre de diviser par 2 ou 3 la taille des données si c'est bien choisi (et si ça s'y prête bien).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . Évalué à 3. Dernière modification le 09 mai 2012 à 14:17.
Je rappelle que le fond de ma remarque n'était pas de critiquer SQL, mais de montrer qu'un stockage relationnel fiable et cohérent n'était pas toujours adapté à la recherche des données.
Les vues matérialisées ou les tables mises à jour par cron peuvent être une solution, mais on n'atteindra pas la puissance d'une solution de recherche dédiée. Il me semble plus "rentable", pour opitmiser la recherche, de greffer Sphinx Search sur sa base relationnelle plutôt que de la partitionner.
Quant aux requêtes proposées, la première n'est pas possible en MySQL (pas de "MINUS"). Je doute qu'elle soit efficace, mais j'admets que je me base sur une impression.
Pour la seconde, AMHA elle me semble complètement fausse en l'état. Ce qui prouverait que la requête nécessaire est complexe. J'aurais écris qqchose comme :
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par barmic . Évalué à 2.
Je ne dis pas le contraire. Pour l'exemple en question c'est plus un problème ensembliste selon moi et SQL a des outils pour le faire (MINUS ou NOT IN). Ta requête a une coquille (il y a une jointure en trop. Pour ma seconde j'avoue y être allé un peu vite. Le principe c'est de créer 2 ensembles dans le FROM un avec les postes qui ont un tag « linux » et un avec tout les identifiants qui ont le tag « sql », puis on fait des opérations ensemblistes entre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . Évalué à 2.
Effectivement, la seconde jointure est inutile pour la recherche. En fait, je l'avais ajoutée pour pouvoir récupérer la liste des tags par un "GROUP_CONCAT", comme je le faisais dans mon premier commentaire. Et après je me suis mélangé les pinceaux.
Je viens de tester sur un serveur MySQL avec une table de relations de 600k lignes. La requête prend 0.8s. Avec les mêmes critères et sur les mêmes données (dénormalisées), Sphinx me répond en 0,01 s. (avec une syntaxe simplissime).
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par Flo . Évalué à 1.
Les bases de données SQL ne se limitent pas à MySQL. Il faudrait voir ce que cela donne avec un moteur moins limité (qui supporte MINUS, avec un optimiseur plus poussé).
Et cette requête particulière peut être écrite de nombreuses manières, ce qui ne donnera pas la même chose en temps de traitement (en fonction de la répartition des données, des index, etc…). Le MINUS n'est pas forcément lent (je me souviens d'une requête de ce style sur 5 millions de lignes, avec une dizaine de tables jointes, que le dba avait réécrite avec MINUS ; elle était passé de plusieurs heures à quelques minutes… il y a 8 ans)
L'exemple de modèle que tu donnes me paraît justement le cas où un SGBD relationnel s'en sort bien en général. Je pense que là où se trouve la faiblesse des SGBDR, c'est qu'il faut les compétences qui vont avec (côté concepteurs, développeurs, DBA). Je ne connais pas les bases NoSQL, donc je ne sais pas du tout si c'est pareil.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par rogo . Évalué à 1.
Pourtant, tout ce que tu as écrit me conforte dans ma position. Pour rappel, elle est de séparer les bases de stockage et de recherche.
Tu dis qu'il faudrait changer de moteur de SGDBR, tester plusieurs syntaxes SQL en fonction d'une multitude de paramètres, et qu'alors on trouvera sans doute une requête plus rapide (avec en exemple une requête qui prenait quelques minutes). Or justement j'écrivais : « On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel. »
La requête optimale pour un cas particulier ne m'intéresse pas souvent. En général, j'ai un formulaire de recherche (web, ou dans un client lourd, voire des paramètres CLI) et je dois générer la requête automatiquement. Oh, rien de bien méchant, ce ne sont souvent que 2 ou 3 champs de recherche textuelle, et 5 ou 6 filtres sur des paramètres numériques. Du genre : les posts contenant les mots [A], avec un tag dans [B], mais sans tag parmi [C], et publiés dans une des catégories [D] mais pas [E], etc, etc. Générer le SQL optimal (en supposant qu'on a déjà les bons indexes et tous les paramètres optimaux du serveur) ne sera pas une mince affaire, surtout si on veut une réponse dans la seconde. Alors que si on stocke les données "cherchables" dans une base NoSQL dénormalisée dédiée à la recherche, type Lucene ou Sphinx Search, la requête sera triviale à construire, et quelques millions d'attributs n'empêcheront pas une réponse en une fraction de seconde.
[^] # Re: Séparer stockage (relationnel) et recherche
Posté par barmic . Évalué à 1.
Je ne nie absolument pas la qualité de Sphinx que je ne connais pas (c'est le moteur full-text dont ils parlent ici ? MySQL) ou d'autres système de base de données. Avec un map-reduce sur des documents (si les tags sont inclus dans les documents) la requête devient triviale (après je ne sais pas comment c'est optimisée, s'il est possible de mettre des indexes sur un champ de documents etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Base de données documents
Posté par Mimoza . Évalué à 2.
Si je ne me trompe pas Lotus Notes utilise ce type de base depuis un certain temps déjà, non ?
[^] # Re: Base de données documents
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 7.
Je ne peux pas affirmer ou infirmer tes dires mais en tout cas je sais que Lotus Notes est une bouse intercidérale depuis bien longtemps.
Alexandre COLLIGNON
[^] # Re: Base de données documents
Posté par barmic . Évalué à 5.
C'est méchant pour les bouses intersidérales.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Base de données documents
Posté par Mimoza . Évalué à 2.
Je ne dit pas le contraire, loin de là, surtout qu'en ce moment je suis obligé de l'utiliser quotidiennement :-(
# Pendant longtemps...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
En fait, ce qui est nouveau, c'est que ce type de solution existe désormais en libre : en propriétaire, des bases telles qu'IP21 d'Aspentech existent depuis longtemps, par ex. pour du contrôle de processus où l'on a des flux simples de données qui arrivent rapidement. En anglais, on appelait ça des historians, et je n'ai jamais trop su comment ça se traduisait en français.
[^] # Re: Pendant longtemps...
Posté par claudex . Évalué à 8.
Je vais faire une réponse groupée à tous les chipoteurs. Ça fait 20 ans que la seule solution envisagée par l'immense majorité (ça veut dire qu'il y a des exceptions) des responsables est une base SQL, mais il y a de plus en plus de gens qui disent que SQL n'est pas l'unique solution pour stocker des données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pendant longtemps...
Posté par Barnabé . Évalué à 4.
Et d'où te viennent cette science et ces certitudes ? On serait pas un peu en présence d'une affirmation non étayée ?
Il y a effectivement du buzz en ce moment autour de ce sujet, mais les gens qui disent que SQL n'est pas l'unique solution pour stocker des données, il y en a depuis longtemps. C'est juste qu'ils le disent plus dans leur code que sur les forums à la mode.
[^] # Re: Pendant longtemps...
Posté par steph1978 . Évalué à 7.
Des gens qui le disent, oui ça fait longtemps.
Des responsables qui l'entendent, non, c'est récent, certainement dû à la pub faite par les gros sites grand publique qui utilisent ces technologies.
# Base De Donnée objet proche de BDD relationnelle??
Posté par reno . Évalué à 6.
Pour moi une BDD relationnelle est une base de donnée optimisée pour l'accès SQL, alors qu'une "base de donnée" objet te permet de conserver simplement l'état de ton programme, les 2 me paraissent très différent, donc je suis surpris que cet article considère les BDD relationnelle et objet comme proche..
# HDF et NetCDF
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Je vois qu'un post a sortis les anciennes base db* (mais qui servent toujours beaucoup). Pour être complet, il ne faut pas oublier les bases de données "matricielles" très utilisés dans le calcul scientifique, notamment NetCDF et HDF (d'ailleurs la dernière version de NetCDF(4) est basée sur HDF(5)).
Ce genre de base est parfait pour stocker des matrices numériques. On peux les attaquer à distance en HTTP via le protocole DAP (exemple de petit serveur qui marche bien : pydap).
Limite hors sujet … mais à connaître tout de même.
# OrientDB - The NoSQL Graph-Document DBMS
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
OrientDB, une base de données orientée graphes et documents ; et qui propose un langage de requêtage mi-sql, mi-autre, qui semble très intéressante et dont j'avais découvert l'existence l'an dernier à Solutions Linux. Je crois que c'est du Java, ça risque d'en freiner plus d'un mais de ce que j'ai testé, ça avait l'air de pas mal marcher (sans pour autant avoir fait des tests exhaustifs).
Le site officiel : http://www.orientdb.org
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: OrientDB - The NoSQL Graph-Document DBMS
Posté par claudex . Évalué à 3.
Qu'est-ce qui la différencie de Neo4j ? S'il y a une différence évidemment.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: OrientDB - The NoSQL Graph-Document DBMS
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Je ne connais pas Neo4j ; les licences sont différentes, néanmoins :
* Neo4j: GPLv3, AGPLv3 et commercial,
* OrientDB : License Apache 2.0
Je peux pas en dire plus ; je souhaitais juste amener un pointeur supplémentaire.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# postgresql 9.2
Posté par wilk . Évalué à 4.
Il semble que postgresql intègre de plus en plus les particularités des nosql.
réplication, parcours des index seuls, champ json, unlogged table…
Un journal vient d'être publié à ce sujet http://linuxfr.org/users/arthurr/journaux/postgresql-9-2-beta-1
# Parfois des migrations retour
Posté par reno . Évalué à 4.
Apparemment un utilisateur de CouchDB insatisfait de sa fiabilité vient de passer à MySQL.
Je n'ai pas trop compris pourquoi MySQL plutôt que PostgrSQL, mais bon..
Le lien: Moving From CouchDB To MySQL: http://developers.slashdot.org/story/12/05/16/1252239/moving-from-couchdb-to-mysql
# NoSQL et SQLite
Posté par mathdatech . Évalué à 1.
existe-t'il des bases nosql qui sont l'équivalent de SQLite, c'est-à-dire par la taille (pour la portabilité), la simplicité et la multitude de connexion avec les différents langage de programmation ?
merci d'avance
[^] # Re: NoSQL et SQLite
Posté par claudex . Évalué à 3.
Les fichiers json et xml font déjà ce boulot là, sinon il y a aussi Bekerley DB qui a déjà été cité. Mais dépendra beaucoup du type de données qui seront stockées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: NoSQL et SQLite
Posté par mathdatech . Évalué à 0.
il s'agit essentiellement de stocker des caractéristiques de produits chimiques pour le fonctionnement du programme
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.