Petit état des lieux du NoSQL

64
7
mai
2012
Base de données

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.

Logo nosql

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

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.

  • # Théorème CAP

    Posté par (page perso) . É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 (page perso) . É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 . Évalué à -4.

      Y a bien Internet d'une certaine façon qui le fait …

      • [^] # Re: Théorème CAP

        Posté par . Évalué à 3.

        J'ai un doute quand à la cohérence…

        • [^] # Re: Théorème CAP

          Posté par (page perso) . É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 . É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 . É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 . É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 . É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 . É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 (page perso) . É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 . É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 . Évalué à 10. Dernière modification le 07/05/12 à 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 (page perso) . Évalué à 2.

      Wikipédia aussi utilise principalement MySQL.

    • [^] # Re: Budget RAM

      Posté par (page perso) . É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 (page perso) . É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.

  • # Et concrètement ?

    Posté par . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 . É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 . Évalué à 5.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Livre blanc chez Smile

    Posté par . É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.

  • # Elasticsearch

    Posté par . É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

    • [^] # Re: Elasticsearch

      Posté par . É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 (page perso) . É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 . É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.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: FS

        Posté par . Évalué à 1. Dernière modification le 09/05/12 à 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 . É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 . É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 (page perso) . É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 . É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 . É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).

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: FS

          Posté par . É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 . É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.

  • # Séparer stockage (relationnel) et recherche

    Posté par . É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 . É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 . É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 . É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).

          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: Séparer stockage (relationnel) et recherche

            Posté par . Évalué à 3. Dernière modification le 09/05/12 à 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 . É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.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

              • [^] # Re: Séparer stockage (relationnel) et recherche

                Posté par . É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 . É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 . É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 . É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).

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Base de données documents

    Posté par . É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 (page perso) . É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 . Évalué à 5.

        C'est méchant pour les bouses intersidérales.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Base de données documents

        Posté par . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.