Petit état des lieux du NoSQL

Posté par claudex le 07 mai 2012 à 14:16. Édité par Bruno Michel, olivierweb, baud123, Buf, Christophe Turbout, Spack, Benoît Sibaud, mike.simonson, Thomas Douillard et rakoo. Modéré par tuiu pol. Licence CC By‑SA.

Étiquettes :

mai

2012

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
- Définition
- Exemples
Base de données colonnes
- Définition
- Exemples
Base de données documents
- Définition
- Exemples
Base de données graphe
- Définition
- Exemple
Base de données hiérarchique
Base de données objet
- Définition
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

Neo4j : en Java ;
FlockDB : utilisé par Twitter pour stocker son graphe social.

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 (1169 clics)
Tag NoSQL sur LinuxFr.org (292 clics)

# Théorème CAP

Posté par claudex le 07 mai 2012 à 14:59. É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
Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps les trois contraintes suivantes :
- Cohérence : tous les nœuds du système voient exactement les mêmes données au même moment ;
- Disponibilité (Availability en anglais) : la perte de nœuds n'empêche pas les survivants de continuer à fonctionner correctement ;
- Résistance au morcellement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).
D'après ce théorème, un système de calcul distribué ne peut garantir à un instant T que deux de ces contraintes mais pas les trois.
« 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) le 07 mai 2012 à 15:56. É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 le 07 mai 2012 à 19:10. Évalué à -4.
  
  Y a bien Internet d'une certaine façon qui le fait …
  - [^] # Re: Théorème CAP
    
    Posté par Marotte ⛧ le 07 mai 2012 à 19:49. Évalué à 3.
    
    J'ai un doute quand à la cohérence…
    - [^] # Re: Théorème CAP
      
      Posté par Pierre Jarillon (site web personnel) le 07 mai 2012 à 21:00. Évalué à 6.
      
      J'ai un doute quand à la cohérence…
      
      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 le 08 mai 2012 à 17:07. É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 :
        
        Au fig. [Pour admettre son erreur et concéder que l'on va reprendre les choses depuis leur début] Au temps pour moi! Un peu plus tard, il avait fait une erreur dans un raisonnement délicat et il avait dit gaiement: « Au temps pour moi ». C'était une expression qu'il tenait de M. Fleurier et qui l'amusait (SARTRE, Mur, 1939, p. 170).
        Rem. La graph. autant pour moi est plus courante: Autant pour moi! Où donc aussi, Avais-je la cervelle éparse? (PONCHON, Muse cabaret, 1920, p. 157).
        
        [^] # Re: Théorème CAP
        
        Posté par ElectronLibre63 le 09 mai 2012 à 10:39. É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 ⛧ le 09 mai 2012 à 16:05. Évalué à 0.
        
        pas mettre les accents sur les majuscules
        
        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 ? :) le 07 mai 2012 à 21:47. É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 le 07 mai 2012 à 22:49. É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 le 07 mai 2012 à 23:41. É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 le 07 mai 2012 à 23:43. Évalué à 2.
    
    Au sens ça ce démontre vraiment ?
    
    http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
    
    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.
    
    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 le 07 mai 2012 à 15:25. É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]

Notons en particulier que la plupart des plus gros sites web ont quitté le monde relationnel (Google, Facebook, Twitter, Amazon)

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) le 07 mai 2012 à 16:20. Évalué à 2.
  
  Wikipédia aussi utilise principalement MySQL.
- [^] # Re: Budget RAM
  
  Posté par Jux (site web personnel) le 07 mai 2012 à 17:10. É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 le 07 mai 2012 à 19:34. Évalué à 2.
    
    Facebook est aussi à l'origine de Cassandra
    
    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 le 07 mai 2012 à 23:45. Évalué à 10.
    
    c'est comme souvent en informatique: il faut utiliser l'outil adapté, pas le dernier truc à la mode
    
    Quoi ?! Mais comment vont vivre les SSII ?
- [^] # Re: Budget RAM
  
  Posté par Krunch (site web personnel) le 11 mai 2012 à 09:36. Évalué à 4.
  
  Beaucoup de bases NoSQL sont au contraire optimisées pour fonctionner en RAM
  
  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) le 13 mai 2012 à 09:23. É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 le 14 mai 2012 à 16:09. Évalué à 5.
      
      Bravo !
      
      En une phrase, tu l'as mis à poil.
# Et concrètement ?

Posté par rewind (Mastodon) le 07 mai 2012 à 17:22. É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 le 07 mai 2012 à 17:24. É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) le 07 mai 2012 à 17:37. É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 le 09 mai 2012 à 16:57. É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) le 07 mai 2012 à 19:03. Évalué à 5.
Je crois constater à la lecture de cet article qu'une base NoSQL réunit deux conditions:
- Une manière non relationnelle de stocker les données,
- Un code qui gère ces données libéré de certaines contraintes dues au relationnel.
On voit d'emblée qu'il y a d'autres façons d'articuler ces conditions:
- On pourrait imaginer une base relationnelle qui tempère les contraintes de la relation pour privilégier les performances, et accepte un taux de validité faible sur ses données (peut-être qu'il y a des conditions particulières ou cela serait utile).
- On peut aussi imaginer utiliser une base relationnelle et y stocker les données en vrac.
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 le 08 mai 2012 à 10:58. Évalué à 5.
  
  On peut aussi imaginer utiliser une base relationnelle et y stocker les données en vrac.
  
  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) le 08 mai 2012 à 12:49. É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 le 08 mai 2012 à 13:10. Évalué à 4.
  
  On pourrait imaginer une base relationnelle qui tempère les contraintes de la relation pour privilégier les performances, et accepte un taux de validité faible sur ses données
  
  Cf. MySQL et MyISAM. Ça ne date pas d'hier…
- [^] # Re: Intervalle entre SQL et NoSQL
  
  Posté par stopspam le 08 mai 2012 à 14:06. Évalué à 2.
  
  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.
  
  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 le 07 mai 2012 à 22:04. Évalué à 5.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 08 mai 2012 à 14:58. Évalué à 0.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# Livre blanc chez Smile

Posté par fero14041 le 07 mai 2012 à 22:28. É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 le 08 mai 2012 à 13:12. É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 le 08 mai 2012 à 14:24. Évalué à 4.
  
  La question est : vont-ils réécrire voyages-sncf en nosql ? :)
# Elasticsearch

Posté par dadoonet (site web personnel) le 07 mai 2012 à 23:21. É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 le 08 mai 2012 à 10:04. É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) le 08 mai 2012 à 08:47. Évalué à 10.

Pendant longtemps, les bases de données relationnelles ont été l'unique solution pour enregistrer des données

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 le 08 mai 2012 à 15:52. Évalué à 1.
  
  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.
  
  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 le 09 mai 2012 à 12:30. É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 le 09 mai 2012 à 13:49. É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) le 09 mai 2012 à 14:29. É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) le 09 mai 2012 à 14:57. É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 le 16 mai 2012 à 09:54. É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 le 16 mai 2012 à 17:18. É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,…).
    
    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.
    
    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) le 16 mai 2012 à 17:56. Évalué à 2.
      
      c'est une grosse violation du design des système de fichiers (un peut comme le fait FTP avec ses modes passif/actif).
      
      Euh… j'ai du mal à voir le rapport là.
# Et les géants ?

Posté par Barnabé le 08 mai 2012 à 10:27. Évalué à 7.

On a souvent tort d'oublier sur quelles épaules on est juché.

dbm a été le premier d'une famille de moteurs de base de données, à l'origine écrit par Ken Thompson et publié par AT&T en 1979. Son nom est l'acronyme de database manager (gestionnaire de base de données).

dbm stocke des données arbitraires par l'utilisation d'une seule clef (une clé primaire), dans un conteneur en taille fixe et utilise les techniques de hachage pour permettre l'accès rapide aux données via la clé.

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) le 08 mai 2012 à 13:59. Évalué à 3.
  
  On a souvent tort d'oublier sur quelles épaules on est juché.
  
  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) le 10 mai 2012 à 08:57. É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 le 08 mai 2012 à 10:44. É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 :
- On a une relation many2many ("Post"—"Tag") et on recherche les "posts" qui ont le tag "linux" mais pas celui "sql". On se retrouve vite avec des requêtes complexes à écrire et qui ne peuvent pas être lancées en temps réel.
- On gère une liste ordonnée (de "Tag") que l'utilisateur peut réordonner à sa guise. En mode relationnel, cela implique de gérer une table relationnelle où chaque enregistrement a une position numérique qu'il faut recalculer globalement en cas de modification locale. C'est là aussi un calvaire.
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 :
1. séparer la base de stockage (normalisée) de la base de recherche (dénormalisée),
2. sérialiser certaines données stockées.
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 le 08 mai 2012 à 14:14. Évalué à 7.
  
  On a une relation many2many ("Post"—"Tag") et on recherche les "posts" qui ont le tag "linux" mais pas celui "sql". On se retrouve vite avec des requêtes complexes à écrire.
  
  Où est la complexité ?
  
  et qui ne peuvent pas être lancées en temps réel
  
  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 le 09 mai 2012 à 12:52. Évalué à 2.
    Exemple en MySQL, en prenant des tags d'id 22 et 33. La requête suivante est simple, mais fausse :
```
SELECT DISTINCT p.*, GROUP_CONCAT(pt1.tag_id) AS tags_id
FROM Post AS p
  JOIN Post_Tag AS pt1 ON (p.id = pt1.post_id)
  JOIN Post_Tag AS pt2 ON (p.id = pt2.post_id)
WHERE pt1.tag_id = 22
  AND pt2.tag_id != 33 -- cette dernière condition sera toujours remplie si la précédente l'est
```
    On peut s'en sortir avec :
```
SELECT p.*, GROUP_CONCAT(pt.tag_id) AS tags_id
FROM Post AS p
  JOIN Post_Tag AS pt ON (p.id = pt.post_id)
GROUP BY p.id
HAVING MAX(pt.tag_id = 22) = 1 AND MAX(pt.tag_id = 33) = 0
```
    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 le 09 mai 2012 à 13:41. É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 :
      
      SELECT p.* FROM Post AS p JOIN Post_Tag AS pt ON (p.id = pt.post_id) WHERE pt.tag_id = 22 MINUS SELECT p.* FROM Post AS p JOIN Post_Tag AS pt ON (p.id = pt.post_id) WHERE pt.tag_id = 23
      
      Pour cette seconde, je suis à peu près certain que c'est possible mais, je ne suis vraiment pas certain de la syntaxe :
      
      SELECT p.* FROM Post AS p JOIN Post_Tag AS pt ON (p.id = pt.post_id), Post_Tag AS pt2 WHERE pt2.tag_id = 23 AND pt.tag_id = 22 AND pt.post_id NOT IN pt2.post_id
      
      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 le 09 mai 2012 à 14:15. É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 :
        
        SELECT p.* FROM Post AS p JOIN Post_Tag AS pt ON (p.id = pt.post_id) JOIN Post_Tag AS pt2 ON (p.id = pt2.post_id) WHERE pt.tag_id = 22 AND 33 NOT IN (pt2.post_id)
        
        [^] # Re: Séparer stockage (relationnel) et recherche
        
        Posté par barmic le 09 mai 2012 à 14:34. Évalué à 2.
        
        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.
        
        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 le 09 mai 2012 à 14:55. Évalué à 2.
        
        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.
        
        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 le 09 mai 2012 à 16:05. É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 le 18 mai 2012 à 23:47. Évalué à 1.
        
        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.
        
        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 le 09 mai 2012 à 17:52. Évalué à 1.
        
        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).
        
        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 le 08 mai 2012 à 13:28. É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) le 09 mai 2012 à 13:20. É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 le 09 mai 2012 à 13:42. É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 le 09 mai 2012 à 14:40. É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) le 09 mai 2012 à 14:06. Évalué à 1.

Pendant longtemps, les bases de données relationnelles ont été l'unique solution pour enregistrer des données

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 le 09 mai 2012 à 14:11. É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é le 09 mai 2012 à 18:07. Évalué à 4.
    
    Ç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
    
    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 le 10 mai 2012 à 12:10. É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 le 10 mai 2012 à 09:38. É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) le 11 mai 2012 à 22:13. É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) le 14 mai 2012 à 14:13. É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
- [^] # Re: OrientDB - The NoSQL Graph-Document DBMS
  
  Posté par claudex le 14 mai 2012 à 14:22. É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) le 14 mai 2012 à 14:35. É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.
# postgresql 9.2

Posté par wilk le 15 mai 2012 à 10:38. É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 le 16 mai 2012 à 16:31. É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 le 21 mai 2012 à 19:01. É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 le 21 mai 2012 à 19:04. É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 le 21 mai 2012 à 19:21. É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.