[NoSQL] quel est l'avantage pour nos appli tradionnelles?

[valkeke]

Bonjour,

Je suis développeur en appli J2EE essentiellement et très peu de connaissance en base de données.... pour tout dire si je dois améliorer les performances d'une base de données en lecture, je vais dire mettons des index et puis c'est tout car la connaissance me manque ensuite .....

Je suis en train de m'intéresser aux bases de données NoSQL.
J'ai lu beaucoup d'articles à ce sujet mais je m'y perds....
Mais j'ai du mal à voir l'avantage par rapport aux bases de données relationnelles quand on travaille sur une application web qui n'a pas les besoins(nombre de connexions simultanées, volumétrie...etc...) de Google, Amazon, Twitter...tous les géants du web. On pourrait penser que la BDrelationnelle bien customisée va répondre à tous nos besoins en plus, elles sont de plus en plus clusterisable à ce que je lis.....

Cluster et partitionnement des données : c'est un peu la même chose, non? les base de données relationnelles sont difficiles à partitionner à cause des relations fortes qui peuvent exister entre les tables ??

Est-ce que le seul avantage est de permettre de faire facilement de la scalabilité horizontale en dépit d'autres principse suivant le théorème de CAP et les principes ACID que les SGBDR dignes de ce nom suivent à la lettre ?

J'ai bien compris que les BD NoSQL ont chacune leur spécialité mais si je veux avoir une base de données pour stocker des documents, je vais choisir :
MongoDB, SGBDR traditionnel dont je connais bien les principes par habitude et expérience depuis 10 ans ou un CMS ?

Si vous pouviez m'éclairer sur ces sujets, merci d'avance...

[camus3]

J'aimerais moi aussi comprendre à quoi servent vraiment les bases NoSql , et en quoi elles sont plus efficaces que les bases relationnelles classiques.
Il y a tellement de buzz autour de NoSql , mais à quoi ça sert ?

[SQLpro]

A rien, ou à peu près !!!

NoSQL est un véritable coup monté par un certain nombre d'acteurs de l'informatique qui veulent s'accaparer une part de marché du secteur du stockage des données.

Il faut comprendre que des SGBDR comme IBM DB2, Oracle ou MS SQL Server c'est pas loin de 1000 années hommes de R&D.

Donc des boîtes comme google ou Amazon ont quelques années lumière de retard pour développer de tels outils et arriver au même niveau de performances.
De ce fait elles tentes de présenter des outils qui ne sont que de vieilles ressussées de recettes de bases de données antédiluviennes (genre Google Big table qui utilise le multivalué qui à fait le bonheur de PICK aujourd'hui mourant) en les présentant comme des innovations technologiques majeures.
Vous remarquerez qu'aucune solution NoSQL ne vient des 3 grands éditeurs de SGBDR (IBM, Oracle ou Microsoft), mais que tout cela vient d'entreprise n'ayant pas de SGBD relationnel à leur catalogue et aucun moyen (1000 années de R&D c'est au minimum 10 années de dev avec des moyens gigantesques) pour un réaliser un.

Notez, le silence de quelques grand autres acteurs sur le sujet comme SAP, qui sans le dire à personne, a racheté de nombreux SGBD relationnels (SAP DB, MaxDB...), le dernier en date étant Sybase ("Il y a deux ans, Sybase s'est appuyé sur sa technologie de stockage en colonne Sybase IQ pour créer le plus gros entrepôt de données au monde, d'une capacité de 1 000 To")

Mais comme en matière d'informatique, la population est jeune et que nous avons entamé la prolétarisation de la société des informaticiens, alors beaucoup de jeunes succombent aux sirènes du marketing, tels des fashions victims, pardon des techno victimes !!!

Pour continuer votre lecture : http://img1.lemondeinformatique.fr/f...s-epaisses.pdf

A +

[valkeke]

je pense que tu exagères un peu qd tu dis que c'est un coup montée (pas complétement faux non plus )...

Je pense que les SGBDR ne supportaient plus la charge pour certains gros sites web : Amazon, Google, Facebook, Digg..etc...c'est vrai que cela ne m'arrivera tous les matins, voir jamais(heureusement ou malheureusement ??) d'avoir ces containtes là !

Ce buzz a aussi l'avantage de nous faire réfléchir sur le stockage des données.
Moi, étant développeur, cela me permet d'avoir une offre en stockage de données qui s'étoffe car le modèle relationnel ne peut pas répondre à toutes les modélisations simplement (difficile de faire quelque chose d'universel) : modéliser un arbre de donnée en relationnel c'est possible bien sûr mais pas tjrs très élégant au niveau codage(maintenance difficile ??)......, ne pas avoir de schéma fixe peut être un avantage dans le stockage de données très hétérogènes, gestion documenatire qd on voit la simplicité de MongoDB....etc..
je pense qu'un outil répond à un besoin mais je ne suis pas trop adepte qu'un outil répond à tous les besoins -> syst complexe, usine à gaz, complexe....

Par contre, c'est vrai que les SGBDR s'appuient sur une grosse expérience -> bcp de confiance dans la technologie car bien éprouvé depuis des années et des années....

Mais ce que j'aimerais savoir comme les BD NoSQL ont pris le partie de préférer la disponibilité et la résistance au morcellement plutôt que la cohérence des données(Théorème de Brewer ou CAP) qu'est-ce que cela implique concrètement ?
Ensuite, le principe ACID n'est pas non plus garantie comme dans les SGBDR : qu'est-ce que cela implique concrètement ?

merci d'avance pour vos explications

pas d'inquiétude, je vais encore utiliser les SGBDR car malgré que je ne sois pas un expert dans le domaine, c'est le syst que je connais le mieux ou j'ai le plus de confiance car SQL est tres puissant et les SGBDR sont également trés performant...

[SQLpro]

Vous partez d'un postulat faux : une base de données n'est pas faite pour stocker des données, mais pour les manipuler.

Envoyé par valkeke

je pense que tu exagères un peu qd tu dis que c'est un coup montée (pas complétement faux non plus )...

Je pense que les SGBDR ne supportaient plus la charge pour certains gros sites web : Amazon, Google, Facebook, Digg..etc...c'est vrai que cela ne m'arrivera tous les matins, voir jamais(heureusement ou malheureusement ??) d'avoir ces containtes là !

Comme je l'ai déjà dit des centaines de fois sur les forums de DVP ces exemples, à part celui d'Amazon, sont imbéciles !
En effet, les sites de branlage (appelons un chat un chat...) comme Facebook, n'ont aucune concurrence d'accès en écriture, car seul le propriétaire de la page est seul à la mettre à jour. Et même un lien d'ami ne consiste qu'a rajouter qu'un tuple dans une table de jointure.
Donc aucune transaction.

En revanche dans de vrai sites marchand il est vital d'avoir des transactions, donc des SGBD relationnel qui supportent les principes de l'acidité.

Par exemple les sites marchand à produit unique, comme c'est le cas du tourisme, nécessitent des transactions, longues complexes et couteuses que seul les SGBDR peuvent assurer. Par exemple si vous voulez faire un voyage, il faudra combiner l'achat d'un vol aller + retour + n nuités d'hotel + une éventuelle voiture de location, tout ceci dans un stock fermé et non réassortissable (je ne peut pas construire ni de nouveau hôtel, ni de nouveau avions entre le moment de la demande et la date d'usage du produit !!!!). Donc une transaction qui va devoir encapsuler tout un tas d'insert/update/delete jusqu'à l'ultime commande SQL et tout défaire en cas d'insatisfaction de stock.
Par exemple, la base de données d'Amadeus (réservation mondiales des places d'avions pour les compagnies européennes) fonctionne sous MS SQL Server, TGV.com sous Oracle...

C'est pour cela que vous ne verrez jamais du NoSQL sur des gros sites marchand.

Pour Amazon, le cas est particulier. Bien évidemment la partie commerciale fonctionne avec de gros SGBDR. Mais la partie branlage (noation des bouquins, films et CD... "ma liste à moi"...) fonctionne avec d'autres système, car il n'y a pas de concurrence et c'est mois cher... De plus on peut se permettre de mettre en ligne sans même tester, les utilisateurs étant les bêta testeurs.

Ce buzz a aussi l'avantage de nous faire réfléchir sur le stockage des données.

Si vos besoin sont du stockge, alors les fichiers genre Cobol (ISAM), sont encore ce qu'il y a de plus rapide.
Maintenant si vos besoins sont de manipuler les données, alors il vous faut justement des index et des contraintes :
1) les index accélèrent TOUTES les commandes SQL : SELECT, mais aussi INSERT, UPDATE, DELETE...
2) les contraintes empêchent des saisies erronées et accélère dans bien des cas certaines requêtes.
Le problème c'est qu'un très grand nombre de développeurs n'ayant qu'une culture SGBDR qu'au niveau de 10% de ce que sait faire MySQL ('est à dire à peine 1% de ce que l'on peut trouver dans un SGBDR) sont persuadés du contraire !!!

Moi, étant développeur, cela me permet d'avoir une offre en stockage de données qui s'étoffe car le modèle relationnel ne peut pas répondre à toutes les modélisations simplement (difficile de faire quelque chose d'universel) : modéliser un arbre de donnée en relationnel c'est possible bien sûr mais pas tjrs très élégant au niveau codage(maintenance difficile ??)......,

Visiblement vous ne connaissez pas la représentation en mode intervallaire des arborescences. Je vous invite à lire les nombreux articles que j'ai écrit à ce sujet...

ne pas avoir de schéma fixe peut être un avantage dans le stockage de données très hétérogènes, gestion documenatire qd on voit la simplicité de MongoDB....etc..

Là encore vous manquez de culture. Un SGBDR possède justement l'avantage de la souplesse évolutive du modèle de données. Le problème c'est que peut de gens, dont visiblement vous faites partie, savent l'utiliser proprement.
par exemple vous pouvez modifier la structure d'une table dynamiquement et à tout moment (même en production).
Mais si vous voulez être vraiment souple dans vos développement applicatif, alors vous devez utiliser le modèle externe, ce que très peu de gens utilisent. Dès lors vos applications IHM sont très faiblement impactées par les changement de structure, car il vous suffit de remanier le MED.

En sus l'hétérogénéité des données empêche toute indexation. En effet on index pas de la même manière des données scalaire, vectorisées, composées... Par exemples les gros SGBDR permettent de mettre en œuvre des index sur des données sclalaires, mais aussi géographiques (SIG), textuelles, ou encore XML. Chaque type d'index n'étant pas du tout construit de la même manière

je pense qu'un outil répond à un besoin mais je ne suis pas trop adepte qu'un outil répond à tous les besoins -> syst complexe, usine à gaz, complexe....

Par contre, c'est vrai que les SGBDR s'appuient sur une grosse expérience -> bcp de confiance dans la technologie car bien éprouvé depuis des années et des années....

Mais ce que j'aimerais savoir comme les BD NoSQL ont pris le partie de préférer la disponibilité et la résistance au morcellement plutôt que la cohérence des données(Théorème de Brewer ou CAP) qu'est-ce que cela implique concrètement ?

De la desynchronisation de données ou des temps de réponse catastrophique aux choix... Lisez ceci :
http://dbmsmusings.blogspot.com/2010...os-little.html

Ensuite, le principe ACID n'est pas non plus garantie comme dans les SGBDR : qu'est-ce que cela implique concrètement ?

Des anomalies transactionnelles, donc des données incohérentes.

merci d'avance pour vos explications

pas d'inquiétude, je vais encore utiliser les SGBDR car malgré que je ne sois pas un expert dans le domaine, c'est le syst que je connais le mieux ou j'ai le plus de confiance car SQL est tres puissant et les SGBDR sont également trés performant...

A +

[valkeke]

vos commentaires me permettent d'améliorer mes connaissances...

J'ai l'impression que les bases NoSQL d'après toi, n'ont aucune utilités car les SGBDR avec des experts, des personnes compétentes, le SGBDR digne de ce nom......etc... vont répondre à tous les besoins... même celui de gros volumes de données alors que bcp de gens disent que les SGBDR sont trés difficilement scalable horizontalement dû à leur propriétés : modèle relationnel, ACID....par contre si on a bcp d'argent on peut faire de la scalabilité verticale jusqu'à une certaine limite qu'à atteind Google, Digg, Amazon....
-> j'interprète mal ou pas ?

En lisant différents articles, on comprend assez vite (si je ne me trompe pas ?) que les bases NoSQL ne respectant pas le principe ACID, par conséquent les transactions comme on peut l'entendre n'existe pas ... c'est sûr que pour tout se qui est site marchand, les bases NoSQL ne sont pas faites pour ça car qd on touche à l'argent, on veut bien perdre en performance pour s'assurer que la transaction bancaire soit la plus cohérente possible sans problème ! dans ce cas le principe ACID nous rassure (quoique que il doit y avoir des failles mais ce n'est pas le sujet !)

Bcp de gens pensent qu'on pourrait associer des BD relationnelles et des BD NoSQL pour répondre aux mieux aux besoins fonctionnels de l'application comme un peu Amazon.

Qui a des infos sur : Les technologies « NoSQL » base leur « consistance éventuelle » sur la formule :
Le nombre de réponses de lecture à attendre (R) ajouté au nombre de confirmation d’écriture à attendre (W) doit être supérieur au nombre de réplicas (ou serveur) (N).
En faisant varier R et W, on peut alors paramétrer si on cherche à optimiser la lecture ou l’écriture.
J'ai du mal à comprendre si quelqu'un peut m'éclairer !! merci

[Pierre Fauconnier]

Perso, je suis assez étonné de lire ceci:

Envoyé par SQLpro

...
1) les index accélèrent TOUTES les commandes SQL : SELECT, mais aussi INSERT, UPDATE, DELETE...

Il me semblait que les index accéléraient les opérations de lecture (commandes SELECT) (principe du dictionnaire dans lequel rechercher un mot), mais ralentissaient les opérations d'écritures (Update, insert, delete) puisqu'en plus d'écrire dans la table principale, il y avait une écriture dans une (des) table(s) d'index.

Il me semble étonnant que l'on puisse gagner sur les deux tableaux...

[skuatamad]

Envoyé par Pierre Fauconnier

Il me semblait que les index accéléraient les opérations de lecture (commandes SELECT) (principe du dictionnaire dans lequel rechercher un mot), mais ralentissaient les opérations d'écritures (Update, insert, delete) puisqu'en plus d'écrire dans la table principale, il y avait une écriture dans une (des) table(s) d'index.

Il me semble étonnant que l'on puisse gagner sur les deux tableaux...

C'est simple lorsqu'on veut delete ou update une ligne sur la PK on bénéficie de l'index associé, et c'est aussi vrai lorsque l'update/delete est sur plusieurs lignes recherchées via un index, c'est souvent plus performant que via un full scan, et je ne parle même pas du CASCADE associé aux contraintes FK.

Concernant l'insert, c'est plus lent s'il s'agit d'un insert into values, mais lors d'un besoin assez classique comme insert into select alors les index utilisés par le select auront aussi un impact positif, on peut donc en conclure que généralement les index ont un impact positif sur l'ensemble des DML.

Concernant le NoSql, je n'ai pas lu beaucoup de papier, mais si effectivement le besoin n'est que :

mais si je veux avoir une base de données pour stocker des documents

Et donc s'il n'y a pas de mise en relation d'information, pas de besoin de typage fort... alors NoSql a un sens.

Les SGBD ont tous des indexations textuelles pour permettre des recherches sur des PDF par exemple, mais s'il n'y a pas de droits de visibilité associés aux documents ou autres besoins applicatifs relationnels alors pourquoi pas utiliser une autre techno comme le NoSql.

Concrètement le NoSql me semble intéressant dans très peu de cas, mais, très peu ne voulant pas dire pas votre besoin.

[Pierre Fauconnier]

Salut skuatamad,

Merci pour l'info. Au moins, c'est expliqué...

[Erwy]

Envoyé par skuatamad

Et donc s'il n'y a pas de mise en relation d'information, pas de besoin de typage fort... alors NoSql a un sens.

Les SGBD ont tous des indexations textuelles pour permettre des recherches sur des PDF par exemple, mais s'il n'y a pas de droits de visibilité associés aux documents ou autres besoins applicatifs relationnels alors pourquoi pas utiliser une autre techno comme le NoSql.

Concrètement le NoSql me semble intéressant dans très peu de cas, mais, très peu ne voulant pas dire pas votre besoin.

C'est dans cadre que fonctionne les bases XML ou orienté XML mais elles n'ont rien à voir avec les technos NOSQL qui ont été abordée précédemment.
Elles sont en règle général utilisé pour des bases de type documentaires.

En version pro on trouve par exemple MarKLogic le distributeur français c'est 4dconcept, une société plutôt orienté édition et documentation justement.

Si tu vas sur la liste des gros client de MarkLogic : http://www.marklogic.com/customers.h...59ahc408ppd1p1

Tu t'aperçois que tous les clients ont des profils dans ce sens , plutôt de l'information de type documentaire.

D'ailleurs dans un de ces profils est expliqué la différence avec un moteur de recherche :

A non-profit organization, IEEE is the world's leading professional association for the advancement of technology. IEEE selected the MarkLogic Server to go beyond simple search and combine full-text and granular, structure-aware search to return answers to their users' questions, not just pages of links to documents.

[skuatamad]

Envoyé par Erwy

mais elles n'ont rien à voir avec les technos NOSQL qui ont été abordée précédemment.

Je ne doute pas que MarKLogic soit très différent de BigTable, mais de là à dire que ça n'a rien avoir avec NoSql...
http://developer.marklogic.com/blog/...c-beyond-nosql
http://en.wikipedia.org/wiki/NoSQL

J'ai surtout l'impression que derrière NoSql il y a une miriade d'outils qui répondent à des besoins spécifiques très différents les uns des autres.

[Erwy]

Envoyé par skuatamad

Je ne doute pas que MarKLogic soit très différent de BigTable, mais de là à dire que ça n'a rien avoir avec NoSql...

Tu m'as mal lu je n'ai pas dit que cela n'avait rien à voir avec le NoSQL , mais avec ce qui a été cité précédemment dans la discussion.

Pour ce qui est du mouvement NoSQL, c'est plus ambivalent.
Techniquement ce type de techno en fait partie, mais la dernière fois que j'ai regardé, leurs représentants sont quasiment absent des meeting ou conférence sur le sujet.
De mon point de vue c'est parce que XML ne renie pas du tout l'héritage relationnel, car même si ça structure n'est pas tabulaire (encore qu'un arbre peut être vue comme un ensemble de table), son utilisation et sa modélisation (quand elle est bien faîte mais une bonne analyse ça reste un problème humain) s'inspire de nombreux principes relationnels. En tout cas je fais régulièrement des liens avec les SGBDR pour expliquer certaines notions dans mes formations XML.

Une autre reponse peut être plus technique, toujours du site MarkLogic

What Distinguishes MarkLogic Server from Other NoSQL Alternatives?

While MarkLogic is like these systems in someways, it is quite distinct in others. At a high-level, MarkLogic is distinguished by

* Focus on intra-cluster consistency and ACID transactions
* Use of the XML data model

Fundamentally MarkLogic is designed and optimized to store, index, update, and search XML data. MarkLogic can also store plain text, JSON, and binaries data as well. But MarkLogic is optimized for XML. And as much as JSON is simpler and ideal for interaction with web browsers, XML still reigns supreme when dealing with structured documents that contain lots of text.
* The MarkLogic Universal Index

Because MarkLogic is based on a real-time search-engine core, we index the structure (elements, attributes, hierarchy) of documents as well as the full text. In MarkLogic, you can compose meaningful queries for semi-structured (or un-structured) data - the kind of data that is most prevalent in the real world. And you can do this without having to bolt on separate processes or separate pieces of technology (e.g. Lucene, SOLR). And because MarkLogic is also focused on ACID, every document insert or update results in a fully-transactional update of the index as well. The query results are always based exactly on what's currently in the database.

[iznogoudmc]

Envoyé par SQLpro

Par exemple, la base de données d'Amadeus (réservation mondiales des places d'avions pour les compagnies européennes) fonctionne sous MS SQL Server

C'est marrant ça... quand j'y ai fait une mission, ils m'ont affirmé que pour leur migration actuelle (quitter TPF) ils utilisaient Oracle.... mais cherchaient à s'en débarrasser.... et mieux encore : qu'ils étaient en train de changer le modèle de stockage de leurs données pour se rapprocher très franchement du modèle clef/valeur....

PS: Et le fait qu'ils utiliseraient MS SQL Server me parait d'autant plus étrange que leur plan de migration (quitter TPF) comprend la mise en place de serveurs.... sous Linux (et certainement pas sous Windows, car une de leurs raisons pour quitter TPF est qu'ils ne veulent plus être prisonnier d'un éditeur ou d'un constructeur).

Mais il est vrai que je n'y suis resté qu'à peine plus de 6 mois, mais sources sont peut-être moins bonne que les tiennes ?

[iznogoudmc]

Envoyé par camus3

J'aimerais moi aussi comprendre à quoi servent vraiment les bases NoSql , et en quoi elles sont plus efficaces que les bases relationnelles classiques.
Il y a tellement de buzz autour de NoSql , mais à quoi ça sert ?

A mon avis, si tu te poses la question, c'est que tu ne dois pas les utiliser.

Derrière "NoSQL" ne se cachent pas que les bases permettant de stocker d'immenses quantités de données sur des énormes clusters, en faisant fi d'ACID pour continuer de fonctionner quand il y a un partitionnement du réseau (besoin auquel répond Dynamo). C'est certes un exemple emblématique des tenant de NoSQL et presque le seul connu de ceux qui ne font qu’effleurer le sujet, mais le véritable point commun est (comme son nom l'indique) de proposer autre chose que SQL pour manipuler des données.

A noter que le "No" signifie "not only" : ceux qui proposent NoSQL savent très bien que le modèle des SGBD-R répond à 99,99% des besoins.

Comparer les SGBD-R et NoSQL est pour moi un peu pareil que comparer le prêt à porter et la haute couture : bien rare sont les cas où on a BESOIN de s'habiller en haute couture, mais c'est elle qui a un temps d'avance et définit ce que nous allons porter "demain".

[vanhel]

Bonjour a tous,

Je viens apporter ma pierre a l'édifice déjà âgé de plusieurs mois, car je me pose une question.

Pourquoi cette technologie est elle décrier avec tant de force par les pro SGBDR? Avez vous peur de les voir disparaitre?

Je pense qu'actuellement de plus en plus de données sont stockés alors qu'elles ont de moins en moins d'importances. lorsque qu'une personne met un commentaire sur un produit qu'elle importance a cette donnée? Si cette personne a modifié son commentaire qu'elle importance qu'une autre personne voit la 1er version du commentaire?

La différence entre les pro SGBDR et les pro NOSQL c'est que les pro NOSQL ne remettent pas en cause l'utilisation plus qu'importante des SGBDR classique alors que les pro SGBDR disent tout simplement que NOSQL ça sert a rien sans même chercher un peu ce que propose ces solutions. Je trouve ça triste.

La cohérence des données est importante pour certaines données tout comme la scalabilité horizontal est importante dans certain scenario. Et comme la très bien démontré Eric Brewer, dans une système distribué il est impossible de respecter les contraintes de cohérence, de tolérance a la partition et de disponibilité. donc lorsque la cohérence n'est pas indispensable mais que la scalabilité l'est certaine solution nosql sont adéquat.

Lorsque je vois le nombre de client que possede mongoDB par exemple et le nombre de retours positifs sur cette solution je trouve triste que les pro SGBDR ne s'intéressent pas plus au monde du NOSQL et gardent leur esprit aussi fermé qu'une base de données relationnelle.

Par ailleurs avec l’avènement du cloud computing qui, certes n'est qu'un terme marketing mais néanmoins de plus en plus utilisé, le NOSQL repond efficacement au contrainte de ce genre d'architecture.

Les chose bouge et évolue même dans le domaine de la base de données et le NOSQL ne peut apporter que de bonnes choses au SGBDR.

[olivewood]

qui a dit qu'Oracle n'était pas intéressé au NoSQL ?

http://www.developpez.com/actu/38304...e-des-donnees/

http://siliconangle.com/blog/2011/09...at-open-world/

[benjamin_liens]

Bonjour,
Je viens apporter mon témoignage également. Je ne jugerais pas de la pertinence du NoSQL pour traiter de grands volumes de données n'étant pas directement concerné par ce sujet.

Notre équipe travaille sur un logiciel de gestion de données dont l'une des fonctionnalités essentielles est de permettre de facilement ajouter ou retirer des champs lors de la saisie d'informations pour un utilisateur. Dans une base de donnée relationnelle, nous aurions du nous appuyer sur une modélisation de type Entité-Attribut-Valeur qui pose de nombreux problèmes, principalement en termes de performances. Nous nous sommes donc tournés vers une base NoSQL orientée document (CouchDB) qui nous a permis de répondre à cette problématique avec succès. Nous avons toutefois rencontrés les différentes problématiques cités dans les messages précédents:
- pour le problème des transactions, la base utilisée respecte les propriétés ACID, mais dans certains cas précis nous rencontrons des difficultés pour réaliser différentes opérations de manière atomique.
- pour le requêtage, il n'existe pas de possibilités similaires au SQL, et nous avons donc rencontré un certain nombre de difficulté pour extraire les données souhaitées de manière optimale, notamment pour réaliser des "join" complexes dans les requêtes. Nous nous sommes finalement appuyés sur une indexation par le moteur Lucène qui a répondu à la plupart de nos besoins pour les requêtes.
- il est difficile d'assurer la cohérence des données inter-documents, et cela requiert d'augmenter l'effort du côté applicatif là ou cette cohérence est gérée par le SGBD dans les bases relationnelles

C'est le prix à payer pour passer à cette technologie, mais nous avons ensuite pu bénéficier de fonctionnalités très intéressantes fournies par CouchDB:
- interrogation native des données sous forme de webservices REST
- synchronisation pair à pair avec gestion automatique des conflits (http://wiki.apache.org/couchdb/Replication), ce qui nous a permis en particulier de mettre au point sans difficultés une version hors-ligne de l'application

Le bilan de ce travail est qu'une base NoSQL orientée document est bien adaptée... si vos données respectent la philosophie d'un document:
- pas de liens de plus d'un niveau vers d'autre données (il est possible de pointer un champs vers un document lié mais au delà d'un niveau la récupération des données nous a semblé peu performante)
- pas de besoins forts de respect de la cohérence des données car ce travail sera à réaliser par l'équipe de développement
- accepter la redondance de l'information pour obtenir une application performante

En espérant que ce témoignage pourra vous être utile.

[CARNIBAL]

Je rebondis sur ton témoignage car je vais être amené à développé une solution d'e-commerce.
Se pose la question des attributs personnalisés pour chaque produit (couleur, taille ...).

J'étais partis sur le fameux modèle EAV mais entre temps j'ai découvert le système NoSQL qui permet d'être plus souple à ce niveau là.

En contre-partie, le problème des transactions complexes est apparu (gestion du stock puis du paiement, rollback ...).
Et enfin le soucis aussi de pouvoir requêter sur ces attributs personnalisés pour faire, par exemple, une navigation à facettes.

Du coup, je pense repartir sur un SGBDR.

Vos avis sont les bienvenus

[SQLpro]

Envoyé par benjamin_liens

Notre équipe travaille sur un logiciel de gestion de données dont l'une des fonctionnalités essentielles est de permettre de facilement ajouter ou retirer des champs lors de la saisie d'informations pour un utilisateur. Dans une base de donnée relationnelle, nous aurions du nous appuyer sur une modélisation de type Entité-Attribut-Valeur qui pose de nombreux problèmes, principalement en termes de performances. Nous nous sommes donc tournés vers une base NoSQL orientée document (CouchDB) qui nous a permis de répondre à cette problématique avec succès. Nous avons toutefois rencontrés les différentes problématiques cités dans les messages précédents...

Vous n'avez visiblement pas cherché bien loin... Aujourd'hui la plupart des grands SGBDR permettent de stocker des données de type XML et d'interroger des données XML via XPath et XQuery tout en conservant les propriétés ACID des transactions et avec une extrême vélocité du fait du typage XML Schéma, associée à l'indexation possible des colonnes de type XML auquel on peut ajouter en sus une surcouche d'indexation textuelle.

Il y a quelques années j'ai été le conseil d'un éditeur d'application dans le domaine de la recherche documentaire et nous avons mis en œuvre cette techno sous MS SQL Server. Nous sommes passés de 20 minutes de traitements sous forme purement objet à quelques secondes....

A +

[el_muchacho]

Bonjour,

2 ans après le premier post de SQLPro a pris un sérieux coup de vieux. Force est de constater que le "mouvement" NoSQL est là et n'est pas près de disparaître.
Les grands acteurs traditionnels sont d'ailleurs obligés de suivre, et intègrent eux-mêmes de plus en plus de fonctionnalités qui s'inspirent des technologies associées à des bases de données orientées colonnes ou "en mémoire".
SQL Server par exemple (SQL Pro est bien placé pour en parler).
Sans parler du dernier en date, SAP Hana, qui est une base entièrement en mémoire.

En 2013, le marché des bases de données NoSQL semble gagner en maturité, et pour ma part, je vois deux produits qui tiennent la route: Cassandra et HBase.
Dans le reste du paysage, redis pour les key-value stores est un produit sérieux (mais que je peux difficilement qualifier de base de données, c'est plutôt un memcache amélioré).

Pour répondre à la question initiale, l'avantage des bases de données distribuées orientées colonnes telles que Cassandra et HBase est évident quand on commence à se pencher sur les solutions de sharding pour augmenter le débit: redondance et scalabilité horizontale grandement simplifiées. Les avantages me semblent se situer essentiellement là.