# Bases de donnes > NoSQL >  Des dveloppeurs vous offrent une mthode d'utilisation de NoSQL, cette technologie est un must ou une mode ?

## Gordon Fowler

*Mise  jour du 09.07.2010 par Katleen
Des dveloppeurs vous offrent une mthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?*

Une quipe de dveloppeurs passionns (du site DZone) vient de publier une carte de rfrence intitule "Dbuter avec NoSQL et l'extension de donnes". 

Les bases de donnes NoSQL (et les technologies oprationnelles sur les donnes associes) sont en effet dsormais incontournable pour les dveloppeurs web. Elles sont largement utilises pour les grandes boutiques en ligne et commence  se faire une place dans les infrastructures IT.

Donc, cette carte de rfrence est l pour aider les professionnels  se poser les bonnes questions concernant les implmentations spcifiques de NoSQL ; tout en apportant les outils de base pour identifier les diffrentes technologies NoSQL et les utiliser.

Source : Getting Started with NoSQL and Data Scalability (PDF)

 ::fleche::  Trouvez-vous cette refcard utile ?

 ::fleche::  Pensez-vous qu'un dveloppeur doive matriser le NoSQL, ou bien n'est-il qu'une mode passagre ?

*Faut-il en finir avec la mode NoSQL ?*
*Ou est-ce plus qu'une simple mode passagre ?*


La question est volontairement provocante. Elle est pose, en des termes encore plus crus, par Ted Dziuba dans un billet intitul _ I Can't Wait for NoSQL to Die_ .

_ Certains ingnieurs pensent que l'volutivit et l'architecture sont la solution [de tous les problmes]. C'est comme cela qu'est n le mouvement NoSQL_ , y crit-il. _ L'ide dveloppe avec NoSQL est que toutes les bases de donnes relationnelles, telles que MySQL et PostgreSQL, sont caduques et que les bases de donnes fondes sur des documents ou les bases de donnes sans schma reprsentent l'avenir_.

Une position qui irrite visiblement l'auteur pour qui NoSQL est avant tout (pas que, mais avant tout) un effet de mode : _ Peu importe bien sr que MySQL ait t la solution parfaite pour absolument tout jusqu' trs rcemment [] Peu importe que de vritables entreprises stockent toutes leurs donnes dans de vraies bases de donnes SQL, (pour les lecteurs de la Silicon Valley, Walmart (NDR : quivalent de Carrefour) est une vraie entreprise, pas Twitter)_ , aujourd'hui, MySQL serait injustement clips par NoSQL.

Dans le cas d'une monte en charge lie  une forte utilisation, Dziuba  explique que la solution fonde sur MySQL peut rencontrer quelques problmes de performances et qu'_  ce stade, un dveloppeur qui valorise la dernire technologique  la pointe plaidera en faveur de "rcrire le tout en un week-end avec Cassandra" .[...] Et donc, comme par magie, vous avez chang votre stockage de donnes de MySQL  Cassandra_ . 

Tout devrait mieux fonctionner.

_ Eh bien, non ! Saviez-vous que Cassandra ncessite un redmarrage lorsque vous modifiez la dfinition d'une colonne dans une table ? Et oui, les dveloppeurs de MySQL avait effectivement rflchi  la faon de mettre en uvre un ALTER TABLE, mais pour Cassandra c'est un problme difficile car cela reprsente bien peu de cas_ .

Et Ted Dziuba d'en conclure que NoSQL n'est certainement pas la solution miracle que certains voudraient faire croire. Migrer d'une solution MySQL  une solution NoSQL reviendrait plutt  _ changer une liste de limitations et de bugs connus pour [...] une liste de limitations et de bugs inconnus_ . Avec un risque norme pour l'entreprise.

Et c'est bien l o le bt blesse. Car se bercer d'illusions sur NoSQL et mal cibler les besoins de la majorit des socits pourrait tre trs dangereux : _ Dvelopper une application  une chelle comparable  celle de Google est un gaspillage de votre temps. [] Ce n'est pas que vous n'tes pas assez intelligent pour le faire, c'est que vous n'avez pas l'exprience suffisante pour savoir quels problmes vont se poser  cette chelle_ .

Seul Google aurait donc besoin de solutions NoSQL ? A en croire Ted Dziuba, mme pas.

_ [Saviez-vous] que Google AdWords est implment sur une base MySQL ? Le cur de mtier le plus critique de Google[...] n'utilise pas BigTable? Et non. En fait [] Google identifie les problmes avec InnoDB et applique des correctifs au lieu de dire "MySQL n'est pas bon  cette chelle, il faudrait le remplacer par autre chose"_ .

Alors quel avenir pour NoSQL ?

_ NoSQL ne mourra jamais_ , nous rassure Ted Dziuba. Pour mieux r-attaquer : _ mais il finira par devenir marginalis, de la mme manire que Rail a t marginalis par NoSQL_ .

Une prophtie qui, on s'en doute, ne trouvera que peu d'chos positifs dans la communaut NoSQL.

Mais alors, qui croire ?

Le chant prometteur des sirnes du NoSQL ? Ou l'humour doux-amre du trs septique Ted Dziuba ?


*Source* : Le billet de Ted Dziuba


*Lire aussi :*

 ::fleche::  Twitter adopte la base de donnes Cassandra
 ::fleche::  Le mouvement anti-SQL samplifie-t-il ?

*Les rubriques (news, tutos, forums) de Developpez.com :*

 ::fleche::  MySQL
 ::fleche::  PostgreSQL 
 ::fleche::  Et tous les SGBD

----------


## Hayaxx

Personnellement, je n'ai pas encore expriment le NoSql et je me demande encore comment construire une architecture solide sans le modele relationnel  ::?: .

Mais de ce que j'ai pu apprendre sur le mouvement NoSql, il ne vise absolument pas a contrer MySql, mais a proposer des alternatives pour des cas particuliers.

Je ne pense pas que ce soit une menace mais plutot un complment.
a me rappelle un peu Windows vs Linux... J'aimerai croire que Linux prendra le dessus sur windows trs bientt, mais cela reste un systeme en marge face  Windows qui est bien assis sur ses positions. Je trouve que c'est comparable  MySql vs NoSql...

Nanmoins j'espre avoir l'occasion de tester ces bases pour m'en faire une ide plus juste  ::ccool::

----------


## Traroth2

Personnellement, j'ai l'impression que les services qu'on attend de ces nouveaux systmes de persistance, c'est essentiellement des trucs grs en principe par des surcouches de la base, comme la rplication de donnes.
Quant au langage SQL proprement dit, je ne comprends pas ce qu'on lui reproche. Ces nouveaux systmes (pas encore eu le temps de trop regarder) doivent bien avoir un langage d'interrogation eux aussi. SQL marche trs bien et permet de grer tous les cas. a revient  rinventer la roue. Je dis a, car j'ai vu quelque part comme justification au NoSQL que SQL serait "difficile  apprendre". Pas vident qu'un nouveau langage d'interrogation soit plus simple. Personnellement, je fais partie des gens qui pensent que l'informatique, c'est un mtier...

Cela dit, le mouvement NoSQL est intressant dans le sens o il permet peut-tre de faire merger de nouvelles ides de fonctionnalits  intgrer aux SGBD. Toute ide est bonne  prendre. Mais sinon...

----------


## saad.hessane

Moi je pense que la concurrence c'est bien, et que tout le monde aille dans la mme direction c'est mal. Oui SQL est super, oui il est simple  apprendre, oui les bases de donnes modernes offrent des mcanismes d'optimisation du parsage et de l'excution de la requte. Mais il faut laisser la chance  d'autres ides merger.
Et pour info, il y a plusieurs cas o l'utilisation du SQL n'est pas judicieux, comme le dveloppement pour mobile par exemple.

----------


## subzero82

Je suis de l'avis de Hayaxx. Beaucoup prennent NoSQL pour un groupe de nvross qui remet en question les bases de donnes conventionnelles en totalit.

En fait, cela n'est pas vrai. L'objectif est de faire bouger les choses dans le monde des bases de donnes. Ces dernires annes les leaders du march des BDD se sont endormis sur leurs lauriers.

On remarquera une sorte de stagnation d'un point de vue architecture interne et capacits de traitement.

NoSQL tente de faire bouger les choses et rpondre aux nouveaux besoins qui ne sont pas supports sinon de manire bizarre dans les bases de donnes conventionnelles. Exemple :
- interrogation de documents structurs. Beaucoup diront que cela est dj support. Mais dans les faits c'est tout autre chose.

De manire plus gnrale, NoSQL vise  faire avancer les choses sur 2 points :
- Mont en charge  terme totalement synchrone ;
- stockage, indexation et interrogation d'entits complexes ; telles que des images, vidos, cartes routires, etc.

----------


## Emmanuel Lecoester

NoSQL versus SGBDR ? Cest  la mode en effet ! 

Maintenant c'est une mode, les SGBDR existent depuis bien plus longtemps donc attendons que la mode soit passe.

Ces ides ne viendraient-elles pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des donnes totalement dnormalises revient dans l'air du temps (bientt on aura des fichiers texte  ::aie:: )

----------


## hgomez

Pourquoi est-ce que NoSQL serait une mode ?

N'est-ce pas tout simplement une rponse possible dans l'aspect persistance ?

Je me rappelle d'une poque pas si lointaine ou le stockage et la persistance n'utilisaient pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pr-web 1.0, mais de solutions professionnelles utilises par exemple dans des environnements financiers (boursier ou bancaire).

Pendant longtemps on concevait avec des modles mixtes, mlangeant stockage mmoire et disque, par exemple avec des systmes ISAM.

Et puis et arriv le SQL qui permettait de tout stocker et de dfinir,  postriori tout champ comme cl d'accs  l'information, avec bien videmment les drives connues de lazzy indexing.

Et on s'est donc mis  chercher plus seulement par les colonnes principales, mais par tout champ prsent dans une table. 

Pire on a mont ceci en paradigme suprme, le SQL permettait tout.

Je pense sincrement que l'initiative NOSQL est un retour  des sources plus saines et quelque part plus pertinentes. 

A ceux qui doutent de l'applicabilit de NOSQL dans leur environnement de travail de tous les jours, je demanderais juste que se demander qu'elles soient les cls d'accs aux informations que leur processus traitent tous les jours ?

Un identifiant client, un code valeur ISIN, une rfrence d'article ?

Est-ce que ce type d'information ne pourrait tre pas stock en NOSQL avec une rconciliation dans la partie applicative (Java, C/C++, .NET) ?

Il serait bon que les plus gs parmi les rfractaires  NOSQL se rappellent qu'ils ont produits des applications et solutions avant que les SGDBR n'envahissent nos contres et ne se rpandent dans l'esprit des dveloppeurs puis des utilisateurs.

NOSQL est une approche pertinente et efficace dans de trs nombreux cas d'applications, o souvent un SGDBR est sur/sous-utilis par rapport au besoin rel en terme de persistance.


Bien amicalement.

----------


## Hayaxx

Voila un article tres clair sur les principes et les buts du NoSql pour ceux qui n'en auraient pas trouv : http://5.freshminutes.it/2010/02/17/...Java%2B&%2BIT)

----------


## metagoto

a me rappelle un peu ce qui s'est pass avec l'arrive de l'OOP (mme si je n'tais pas n  ), de java, de ruby on rails, etc. (et plus tard, le Cloud).

Beaucoup de hype, des success-stories, des checs et puis finalement les choses se tassent. La raison l'emporte.

Les solutions "NoSQL" ont leur rle  jouer, tout comme le reste.

----------


## pseudocode

> Ces ides ne viendraient-elle pas aussi du fait que l'espace disque coute de moins en moins cher et que donc d'avoir des donnes totalement dnormalises revient dans l'air du temps (bientt on aura des fichiers texte )


Oui, l'espace disque est une des raisons. 

Mais il faut remonter aux origines de ce problme : 

1. la dure de rtention des donnes

et son corolaire : 

2. la volumtrie des donnes stockes

et finalement son impact :

3. la performance d'accs en fonction de la volumtrie

La dure de rtention est gnralement infinie. C'est rare les gens qui acceptent que leurs vieilles donnes soient purement et simplement inaccessibles => on garde tout, que ce soit les pages indexes par Google, les messages du forum, les photos/mp3 sur son PC, ...

Le corolaire c'est que la volumtrie est en augmentation constante. D'ou le problme d'avoir des espaces de stockages de plus en plus gros (et donc ta remarque sur le prix des DD). Et finalement, la performance d'accs a ces grosses quantits de donnes.

Et c'est la que, pour moi, il y a une diffrence entre SGBD et NoSQL :

- Pour amliorer la performance accs/volumtrie d'un stockage SGBD, il faut modifier le SGBD (algos, architecture, schma) 

- Pour amliorer la performance accs/volumtrie d'un stockage NoSql, il faut ajouter de nouvelles machines.

----------


## kervoaz

Bonsoir,
Plus j'essaie de comprendre le NOSQL et moins je le comprends.
En regardant de loin ( Memcached ) le but de redis ou memcached, je ne vois pas de quoi  casser 3 pattes  un canard. Memcached est .. un cache de donnes. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gre le cache avec des algorithmes pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) o le cache est "partag"(echang) entre serveur ou bien TimesTen (Oracle in memory avec fusion de cache pour l'criture). Pourtant, ces produits sont classs dans les SGBDR.
Enfin l'exemple, toujours 
 Memcached, me semble tre simplement de la bonne pratique de dveloppement: je cre trs souvent des tableaux de donnes issues de requtes SQL lorsque je dois accder souvent aux mmes informations. Cependant, lorsque l'on a mis "trop" de donnes en cache sous forme de tableaux/hashmap, on est oblig de faire des boucles, des if pour rechercher la donne pertinente. Il arrive un seuil o il est prfrable(= plus performant) de demander au SGBD de nous trouver lui mme nos donnes, avec ses propres algorithmes optimiss et...avec une bonne vieille requte SQL.

Bon cela dit, les Hashmap ne sont qu'un type de NOSQL, je vais essayer de comprendre les autres.

----------


## pseudocode

> Bonsoir,
> plus j'essaie de comprendre le NOSQL et moins je le comprends.
> En regardant de loin(wikipedia) le but de redis ou memcached, je ne vois pas de quoi  casser 3 pattes  un canard. Memcached est .. un cache de donnes. La belle affaire. Les sgbd dignes de ce nom, Oracle par exemple, gre le cache avec des algo pointus de LRU. Toujours pour Oracle, on trouve RAC(oracle cluster) o le cache est "partag"(echang) entre serveur ou bien TimesTen(Oracle in memory avec fusion de cache pour l'criture). Pourtant ces produits sont classs dans les SGBDR.


 ::arrow::  Memcached's APIs provide a giant hash table *distributed* across multiple machines.

Le mot "distribu" est important. A ne pas confondre avec "partag/chang".

Distribu signifie que chaque machine contient UNE PARTIE seulement des donnes (parfois en doublon avec une autre machine). Et que l'algorithme d'accs au cache permet de trouver les donnes, sans pour autant avoir besoin d'avori la liste exhaustive des machines et des cls prsentes sur ces machines.

----------


## dillinger91

Moi je ne comprend pas trop en quoi le NoSql drange.
On a bien plusieurs paradigme de programmation, encore plus de langages 
Je rejoins donc les quelques avis prcdant en disant que SQL est peut-tre gnial mais que a n'empche pas d'aller voir ailleurs ce qui se passe.
C'est un peu comme a qu'on avance.
Au niveau des entreprises je ne vois pas en quoi NoSql ou tout autres faons d'aborder les donnes serait un risque. 
Aprs tout si l'entreprise n'a pas assez de comptence dans ses rangs pour discerner les effets de modes des vraies solutions qui valent le coup ils finiront par se casser les dents un jour ou l'autre alors que ce soit sur a ou sur autres choses le rsultat ne sera pas forcment trs diffrent.

----------


## B.AF

2010, o l'informatique dcouvre que depuis qu'elle existe, la donne n'a pas fait l'objet exclusif d'une base de donne relationnelle implmentant SQL.


 ::mouarf:: 

a devient un grand nawak cette socit de buzz. 

Lire ce genre de truc sur le noSql, a me fait l'effet d'une polmique sur Eric Zemmour : C'est tellement provocateur qu'on sent que c'est crit pour seulement faire parler de l'auteur.

Mais les tautologies sur la mode est passagre (ouh ouh!), la migration entraine des effets de bords (ah ah!) et un dveloppeur a une tendance a vouloir utiliser les technologies les plus rcentes (eh eh!)...C'est un peu vide de contenu.

----------


## bugsan

Je crois d'avantage aux bases de donnes produisant des rsultats en XML.

Le tout objet n'a pas d'avenir pour les bases de donnes, tout simplement parce que dans 95% des cas les donnes extraites doivent tre resrialises dans un autre format (HTML, XML, PDF, etc...). Dans le cas d'une extraction de donne, l'objet devient donc un intermdiaire contraignant.

Avec un peu de recul on se rend compte que les technologies OXM comme Hibernate, sont une rponse  une problmatique mal formule, surtout en ce qui concerne le Web. Avec la dmocratisation d'ajax, de plus en plus de donnes sont transmises en XML, ce qui oblige les dveloppeurs  utiliser deux technologie : Hibernate + JAXB/Json. On peut facilement virer les deux et remplacer par une base XML.

----------


## deadalnix

C'est vrai, mais XML, c'est massif et lourd. a ne conviendra pas  tous les usages.

----------


## Faiche

L o tout le monde se plante, c'est que NoSQL n'est pas le remplaant de SQL mais le complment (NOSql = Not Only SQL).

D'abord, avant que vous n'ayez  vous poser la question de "oh, mon cluster de mysql comment  devenir compliquer  scaler horizontalement", vous avez de la marge. Seul les plus gros connaissent ce problme et ont d trouver une solution.

Ensuite, la plupart de ces sites ont une partie de leurs bases en sql et d'autres dans diffrentes configurations. Facebook utilise HBase (de hadoop) pour ses logs et ses statistiques !

Evidemment, certains sont all plus loin, comme Digg qui a remplac sa base principale par Cassandra. Mais la grande majorit utilise un mlange des deux mondes.

Voila quelques liens pour vous aider  mieux voir le truc :
Les boites qui utilisent HBase, comment et pourquoi
Un exemple plus prcis de pourquoi et comment Adobe utilise HBase (et le reste des produits hadoop, c'est dont la HStack)
Digg utilise Cassandra

Enfin, une srie d'article pour comprendre comment marche Cassandra, c'est la stack NoSQL la plus avance actuellement

Voila

----------


## saad.hessane

> Je me rappelle d'une poque pas si lointaine o le stockage et la persistance n'utilisait pas des SGBR. Et je ne parle pas d'applications personnelles en environnements pr-web 1.0, mais de solutions professionnelles utilises par exemple dans des environnements financiers (boursier ou banquaire).


Cela est toujours le cas quand il faut maintenir une application vieille de 10 ans en COBOL, qui marche  merveille et qui n'utilise que des fichiers plats.

----------


## clavier12AZQSWX

je pense qu'avant d'envisager de passer  nosql pour un souci de performance, il faut dj passer de mysql  postgres, et de postgres  oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL.

C'est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.

----------


## Patriarch24

Je trouve quand mme incroyable que certains pensent encore et toujours que SQL (et les bases de donnes relationnelles) seront la solution ultime de manire ternelle.
Il existe des domaines o ce n'est pas la panace, et il existe des solutions bien plus performantes, n'en dplaisent aux fanatiques : dj cite, la gestion de documents notamment. Pour autant, ces alternatives spcifiques  des mtiers seront-elles gnralises ? Non SQL, ne disparaitra pas de sitt, et oui, de nouvelles solutions vont continuer d'merger. Et c'est tant mieux.
Je termine par le "buzz" NoSQL : le nom est volontairement provocateur, pour mettre en lumire le fait qu'il existe d'autres solutions, et cela permet aux gens de se poser des questions. Se remettre en cause, chercher des solutions optimales  nos problmes, n'est-ce pas l une de nos comptence ?

----------


## pseudocode

> je pense qu'avant d'envisager de passer  nosql pour un souci de performance, il faut dj passer de mysql  postgres, et de postgres  oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL.
> 
> C'est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.


Le mouvement NoSQL ce n'est pas seulement "remplacemer des SGBDR" pour des raisons de performances. C'est surtout une doctrine qui dit que le relationnel et le langage SQL ne sont pas la solution universelle  tous les problmes de CRUD.

Bien sur, on peut toujours utiliser un SGBDR pour faire cela, mais ce n'est pas toujours ncessaire. Par exemple, les systmes de fichiers (ext/ntfs) fonctionnent trs bien sans passer par un SGBDR. 

Je vois de plus en plus de projets qui remplacent leur stockage "plat" par des bases SQL (sqlite, ...) pour des raisons de performances (genre la gestion du cache dans les browsers web). Je pense qu'on peut faire aussi performant que sqlite sans passer par une base SQL, et que cette solution est surtout choisie pour des raisons de facilit.

----------


## B.AF

> Je pense qu'on peut faire aussi performant que sqlite sans passer par une base SQL, et que cette solution est surtout choisie pour des raisons de facilit.


 ::ccool::

----------


## Invit

Selon moi, noSql est un "anti hgmonie sql" qui se nourrit de nos (trop confortables) certitudes

Dans les temps immoriaux o je commenais ce mtier, sql vivait ses premires heures et oracle tournait sur des systmes unix incroyablement chers (mais aussi sur Xenix, l'unix d'intel relativement bon march)

Sur PC, le standard qui a vraiment lanc la BDD, c'est dBase3 qui connut ensuite une version 4 compltement rate et des copies concurrentes trs russies : Clipper et Foxpro 

Aujourd'hui le standard n'est pas (compltement) mort : rechercher  Xbase++ d'Alaska software sur google.

Sql a rsum la base de donnes  un concept unique. Par rapport  Xbase, je lui reproche une gestion des indexes approximative. Je ne connais pas en sql d'indexes partiels, c'est--dire qui n'indexent qu'une partie d'une table sur un critre qui se trouve dans la commande de cration d'index et non pas dans l'index lui mme. De mme l'optimisation sur index sql est laisse au moteur de donnes et relativement difficile  forcer. 
Pour conclure : les indexes Xbase sont plus prcis et potentiellement plus rapides.

Merci aux rois d'Oracle de ne pas argumenter sur le schma d'execution : celui-ci est vraiment d'une autre philosophie qu'xbase qui rassemble tout dans la syntaxe de son language.  

Quand je me suis mis  SQL, je pensais en avoir termin avec les choix cornliens et parvenir  une relative inter oprabilit entre data engines. NoSql remet a sur le tapis.

S'agit-il du vieux rve de tout remplacer par XML ?  Ce serait peine perdue car XML ne permettra jamais les performances des tables  taille d'enregistrement fixes de nos SGBDR (je ne parle pas des blobs ou des memos) 


Cela n'empche :
les bases de donnes sont tellement stratgiques dans certaines productions qu'on peut estimer leur valeur  plusieurs millnaires/homme, cela fait rflchir car a ne risque pas de diminuer !  On va bien finir par centraliser des sommes de connaissances universelles telles que contester le modle de base est bien le moins qu'on puisse faire.

Plus proche de nous, il y a un ovni du nom de filemaker que certaines socits apprcient mais pour un gars qui veut produire de grandes choses dans ce mtier, le challenge actuel est : SQL ou rien !   c'est sans doute la raison de ce mouvement anti sql : l'hgmonie n'est pas plaisante

Enfin, il faudrait parler de la base objet : j'ai crit trois programmes bass l dessus, je crois que ZOPE utilise une telle architecture... Mais pour gniale qu'elle soit , elle reste relativement lente.

Or j'ai l'impression que le vrai challenge de l'industrie comme du mouvement noSql est d'optimiser les performances. Pour le reste on peut imaginer beaucoup de choses dont la base objet qui est peut-tre la plus intressante.

----------


## Invit

> Je pense qu'on peut faire aussi performant que sqlite sans passer par une base SQL, et que cette solution est surtout choisie pour des raisons de facilit.


Mais combien de vies humaines comptes-tu consacrer  une telle tche ? J'ai utilis sqlite dans un projet industriel o sql n'est pas maitris par la plupart des intervenants (la faute  la formation des ings me semble-t-il)

En 92 j'ai aussi crit mon propre moteur en C trs rapide (et trs limit) mais :

Combien de temps pour dvelopper un outil crdible capable de stocker 100 Go ?????    Comment rentabiliser ce travail alors que les SGBDR actuels fonctionnent bien ?

Quelles technologies envisager, faut-il remplacer le B-Tree, le squenciel index ? le parser SQL ? le systme d'optimisation? DDL ? 

Arbres binaires ?

matrices ?

Quoi concrtement ?

----------


## pseudocode

> Mais ccombien de vies humaines comptes-tu consacrer  une telle tche ? JU'ai utilis sqlite dans un projet industriel o sql n'est pas maitris par la plupart des intervenants (la faute  la formation des ings me semble-t-il)
> 
> En 92 j'ai aussi crit mon propre moteur en C trs rapide (et trs limit) mais :
> 
> Combien de temps pour dvelopper un outil crdible capable de stocker 100 Go ?????    Comment rentabiliser ce travail alors que les SGBDR actuels fonctionnent bien ?
> 
> Quelles technos envisager, faut-il remplacer le B-Tree, le squenciel index ? le parser SQL ? le systme d'optimisation? DDL ?


Il ne s'agit pas de remplacer les technos usuelles des SGBDR par d'autres technos dans le but de faire d'encore meilleurs SGBDR.

Il s'agit de se poser la question de savoir si, dans son contexte, on a besoin des fonctions spcifiques des SGBDR, comme le schma relationnel ou le langage de query.

- Si la rponse est OUI, alors il faut bien-sur prendre un SGBDR.
- Si la rponse est NON, alors le SGBDR n'est pas FORCEMENT la solution. Ca peut l'tre (ca apporte des contraintes), mais il peut y avoir mieux.

Le mouvement NoSQL c'est simplement se poser cette question avant de choisir un SGBDR.

----------


## B.AF

> Mais ccombien de vies humaines comptes-tu consacrer  une telle tche ? JU'ai utilis sqlite dans un projet industriel o sql n'est pas maitris par la plupart des intervenants (la faute  la formation des ings me semble-t-il)
> 
> En 92 j'ai aussi crit mon propre moteur en C trs rapide (et trs limit) mais :
> 
> Combien de temps pour dvelopper un outil crdible capable de stocker 100 Go ?????    Comment rentabiliser ce travail alors que les SGBDR actuels fonctionnent bien ?
> 
> Quelles technos envisager, faut-il remplacer le B-Tree, le squenciel index ? le parser SQL ? le systme d'optimisation? DDL ? 
> 
> Arbres binaires ?
> ...


Peu importe, il y a bien un jour o il faut se poser la question, sinon c'est refuser le principe mme de faire de la r&d et de l'innovation.

----------


## deadalnix

Un peu de lecture sur le sujet : http://www.julianbrowne.com/article/...rs-cap-theorem

----------


## StringBuilder

Moi ce qui me drange dans le NoSQL... C'est le "No SQL".

Si c'est avant tout une mthode diffrente de stockage et de recherche des donnes (distribution des donnes sur plusieurs systmes, avec interrogation universelle de l'ensemble des machines pour retrouver l'information, sans se soucier d'o elle vient), pour moi je ne vois pas en quoi c'est incompatible avec la notion de SGBDR, et encore moins avec le langage SQL.

C'est ni plus ni moins que faire du partitionnement non pas dans plusieurs fichiers tals sur plusieurs disques, mais du partitionnement dans plusieurs machines.

Cela dit, tant responsable informatique dans une entreprise qui change actuellement de logiciel mtier, je dois dire que je suis surpris qu'on se pose aujourd'hui la question du dcoupage des donnes sur plusieurs machines.

Aujourd'hui, SGBD ou pas, c'est actuellement totalement transparent chez les hbergeurs. Les baies de disque font pour nous ce travail de distribution des donnes sur plusieurs systmes. La plupart du temps, on ne rajoute pas de disques, mais bien des serveurs tout entiers, qu'on ajoute  la baie de disque.

C'est alors compltement transparent pour les logiciels qui accdent aux donnes, que ce soit un SGBD ou n'importe quel autre logiciel (GED par exemple, qui ne se baserait pas sur un SGBD).

Bref, sorti du PC de monsieur tout le monde (qui n'a aucune raison de tirer profit de la rpartition des donnes sur plusieurs PC) je ne vois pas o il y a de l'avenir pour une telle chose : si au niveau du matriel on le gre dj trs bien,  quoi bon s'emmerder  le grer dans le programme, et encore plus dans la philosophie de programmation ?

Pour en revenir au dveloppement sur PDA, on a de plus en plus la possibilit d'utiliser un SGBD. Les CPU embarqus sont de plus en plus performants, la quantit de mmoire de moins en moins limit, et on a de loin des performances suprieures  un serveur NT4 d'il y a 10 ans... Qui faisait tourner sans problme Oracle ou SQL Server ! Donc si l'avenir du NoSQL c'est ce genre de plateformes, c'est une mode morte-ne

----------


## deadalnix

Si tu veux avoir les caractristiques ACID, te faut un maitre, qui lui ne peut pas "scaler" indfiniment.

----------


## vosaray

Je ne sais pas ce que vous en pensez, mais personnellement je trouve le billet plutt mauvais.

Il n'y a pas d'argumentaire technique, simplement l'ouverture d'un dbat  assez strile avec un certain parti pris qui rappelle vraiment les campagnes marketing de certains gros diteurs. Sans parler du vecteur jouant sur la peur que peut engendrer l'immaturit d'une techno pourtant  peine emmergeante.

Sur le fond, je ne comprends pas la vague "anti sql", mais j'ai du mal a suivre ceux qui dfendent les bases relationelles  tout prix.

Il existe un tas de contextes dans lesquelles les bases sql et tout particulirement mysql sont aux abois. 

Dans certains cas les bases "nosql" peuvent apporter une altrnative voire un complment assez judicieux.

Ces "technologies" n'ont certes pas encore la maturit des serveurs oracle, mais je ne vois pas quelles seraient les raisons pour qu'elles ne l'atteignent pas dans un proche futur.

Un billet un minimum argument aurait pu tre intressante  lire, mais la je dois dire que franchement je ne vois pas le point ...

----------


## pseudocode

> Un billet un minimum argument aurait pu tre intressante  lire, mais la je dois dire que franchement je ne vois pas le point ...


Regarde celui du post #27, cit par deadalnix.  :;):

----------


## B.AF

> Je ne sais pas ce que vous en pensez, mais personnellement je trouve le billet plutt mauvais.
> 
> Il n'y a pas d'argumentaire technique, simplement l'ouverture d'un dbat  assez strile avec un certain parti pris qui rappelle vraiment les campagnes marketing de certains gros diteurs. Sans parler du vecteur jouant sur la peur que peut engendrer l'immaturit d'une techno pourtant  peine emmergeante.
> 
> Sur le fond, je ne comprends pas la vague "anti sql", mais j'ai du mal a suivre ceux qui dfendent les bases relationelles  tout prix.
> 
> Il existe un tas de contextes dans lesquelles les bases sql et tout particulirement mysql sont aux abois. 
> 
> Dans certains cas les bases "nosql" peuvent apporter une altrnative voire un complment assez judicieux.
> ...


D'accord avec toi de A  Z.

----------


## popovitch130

> je pense qu'avant d'envisager de passer  nosql pour un souci de performance, il faut dj passer de mysql  postgres, et de postgres  oracle/MS server et seulement en dernier recours abandonner le sql pour NoSQL.
> 
> C'est par parce que mysql ne tient pas la charge que les autres sgbrs ne le peuvent pas.


Tu as des statistiques pour appuyer cette ide ? (MySQL->PostGreSQL)
Concrtement, il se passe quoi quand un SGBD ne tient pas la charge ?
a m'intresse car j'ai dvelopp un robot qui enregistre un gros volume de pages web et de liens (plus de 700 000 entres sur certaines tables).
 Et lorsque je crawl un site de plus de 100 000 pages, au bout de 4h-5h environ je script s'arrte et comme je ne suis pas un boss des BDD ... quelques explications sur ton dernier post m'interessent vivement  ::D:

----------


## deadalnix

Quand un SGBD ne tient pas la charge, et bien a rame voir a plante.

Mme si tu as une grosse charge le SQL est surement une bonne solution. Le NoSQL est une solution pour les systmes ENORMES comme digg twitter ou autres. Sinon oublie, ce n'est pas pour toi.

----------


## B.AF

> Quand un SGBD ne tiens pas la charge, et bien a rame voir a plante.
> 
> Mme si tu as une grosse charge le SQL est surement une bonne solution. Le NoSQL est une solution pour les systmes ENORMES comme digg twitter ou autres. Sinon oublie, ce n'est pas pour toi.


Je doute qu'un Oracle en Raw Device plante facilement, de mme qu'un file system.

Le but du jeu n'est pas de faire des comparaisons de scalabilits. C'est de se poser la question suivante : 
*
Est-ce que dans une logique de meileure qualit logicielle (optimisation performance/utilisabilit/maintenance=), le recours systmatique actuel  la base de donnes relationnelle est la meilleure solution ?
*

Moi je pense qu'aujourd'hui, la base relationnel est un outil essentiel, mais difficile  maitriser et qui a un cot; nombreux sont les posts et dbats ici qui parle de techniques plus ou moins volues pour permettre  une quipe de dv et  un environnement relationnel d'interagir sans trop de chocs. 
En revanche, je m'interroge sur l"utilit d'utiliser les bases relationnelles pour "produire". 
Il y a clairement un "sur emploi" des bases de donnes, qui en forant finalement la normalisation de tout deviennent complexes et difficiles  maintenir. 
Le problme est cette "gray zone" (entre le langage et la db) qui aujourd'hui pose les porblmes de maintenance.

En outre, on trouve de plus en plus souvent des logiques multi tenants dans les applications, avec des cloisonnements logiques forts, des mta donnes, et ainsi de suite. 
L aujourd'hui, pour avoir essay les deux solutions, je ne suis plus convaincu par les SGBD.  

Je n'ai pas le temps de dvelopper plus, mais je crois qu'il y une frontire d'usage. On est pas en train de se dire : C# ou Java ; il s'agit d'outils fondamentalement diffrents.

----------


## ZashOne

Ce qui m'tonne c'est qu' il ny as pas encore de modele avec un moteur analytique SQL et un moteur de stockage en colonne comme dans nosql . Je pense que le plus simple soit sur mysql ou l'on pourrait remplacer innodb par un stockage en colonne.

Ce serait un peu plus lent que  cassandra ou Bigtable mais on pourrait avoir les avantages des 2 systemes .

----------


## deadalnix

Non, c'est impossible.

Regarde ce document par exemple pour bien comprendre pourquoi : http://www.julianbrowne.com/article/...rs-cap-theorem

Par contre, rien ne t'empche d'utiliser du SQL ET du NoSQL dans une mme application.

----------


## ezmac

> Je trouve quand mme incroyable que certains pensent encore et toujours que SQL (et les bases de donnes relationnelles) seront la solution ultime de manire ternelle.
> Il existe des domaines o ce n'est pas la panace, et il existe des solutions bien plus performantes, n'en dplaisent aux fanatiques : dj cite, la gestion de documents notamment. Pour autant, ces alternatives spcifiques  des mtiers seront-elles gnralises ? Non SQL, ne disparaitra pas de sitt, et oui, de nouvelles solutions vont continuer d'merger. Et c'est tant mieux.
> Je termine par le "buzz" NoSQL : le nom est volontairement provocateur, pour mettre en lumire le fait qu'il existe d'autres solutions, et cela permet aux gens de se poser des questions. Se remettre en cause, chercher des solutions optimales  nos problmes, n'est-ce pas l une de nos comptence ?


ou je suis dbile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a chang depuis, sauf un petit soupon d'XML et quelques verbes de plus....

Et monsieur SQL reste fig dans le temps (je me revois dans les bancs de physique  l'universit).

Je ne vois pas trop basculer de SQL a noSQL.... mais une chose est sure, il faut un gros coup de pied dans la fourmilire et faire vraiment avancer ce fossile.

Si ce mouvement existe c'est qu'il existe des besoins qui ne sont pas couverts par SQL   !!!!

----------


## ZashOne

faudra bien un language / norme  pour manipuler les donnes (analytiques) ramene par un moteur nosql non ?

----------


## Lung

> si ce mouvement existe c'est qu'il existe des besoins qui ne son t pas couverts par SQL   !!!!


Lesquels par exemple ?
Personne n'a donn d'exemples concrets.

----------


## Shepard

> ou je suis dbile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a chang depuis, sauf un petit soupon d'XML et quelques verbes de plus....
> 
> Et monsieur SQL reste fig dans le temps (je me revois dans les bancs de physique  l'universit).
> 
> Je ne vois pas trop basculer de SQL a noSQL.... mais une chose est sure, il faut un gros coup de pied dans la fourmilire et faire vraiment avancer ce fossile.
> 
> Si ce mouvement existe, c'est qu'il existe des besoins qui ne sont pas couverts par SQL   !!!!


 part MySQL et SQLite qui ne grent pas plus que ce que tu dis, tu es  mon humble avis dans le faux ...

Quelques exemples:

Les requtes rcursives qui permettent une puissance grandement accrue,  des performances inimaginables dans un langage traditionnel (j'ai d transformer un programme qui tournait en 10h avec C# et MS SQL Server en rcuprant les donnes pour les traiter en un programme excutant 7-8 requtes SQL et faisant le mme boulot en 20 secondes)

Les fonctions de fentrage qui permettent de faire des classements statistiques en tous genres, une fois de plus avec des performances qu'on n'ose pas imaginer dans un langage procdural

En vrac, la gestion des tableaux, des objets, l'utilisation des indexes toujours plus rapides, etc.

Et je suis sr d'en oublier beaucoup ! La technologie SQL n'est pas du tout une technologie stagnante, c'est d'ailleurs pourquoi  mon avis (d'tudiant), les dba sont indispensables lorsqu'il s'agit de traiter des applications o la base de donnes est le centre critique ...

----------


## pseudocode

Effectivement, les BdD relationnelles deviennent de plus en plus performantes. Mais cette performance  un prix : la complexit de sa mise en oeuvre. Je m'explique.

Pour tre performant, de plus en plus d'actions doivent tre executes par le moteur de la BdDR ( = plus de code cot SQL, moins de code cot appli ). Ton exemple de requtes rcursives est un exemple.

Corolaire : on enrichit le schma et le langage SQL de nouvelles fonctions. Et donc il faut de plus en plus de connaissances en BdD pour savoir les utiliser. Ta remarque sur le rle essentiel du dba est trs juste.

Plus a va, plus les SGBDR deviennent des environnements complets d'excution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.  ::aie::

----------


## B.AF

> Effectivement, les BdD relationnelles deviennent de plus en plus performantes. Mais cette performance  un prix : la complexit de sa mise en oeuvre. Je m'explique.
> 
> Pour tre performant, de plus en plus d'actions doivent tre executes par le moteur de la BdDR ( = plus de code cot SQL, moins de code cot appli ). Ton exemple de requtes rcursives est un exemple.
> 
> Corolaire : on enrichit le schma et le langage SQL de nouvelles fonctions. Et donc il faut de plus en plus de connaissances en BdD pour savoir les utiliser. Ta remarque sur le rle essentiel du dba est trs juste.
> 
> Plus a va, plus les SGBDR deviennent des environnements complets d'excution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.


 ::ccool::  Je suis tout  fait d'accord avec toi. On est en train de reproduire les erreurs du pass. Des applications peu ou pas volutives, bloques sur des technos anciennes.
L'informatique est un ternel recommencement, comme le cloud et le web 2.0 qui tentent de se rapprocher du mainframe  ::mrgreen::

----------


## ZashOne

> Plus a va, plus les SGBDR deviennent des environnements complets d'excution d'application. Ms-SQL server ressemble de plus a une gigantesque machine virtuelle executant des applications SQL.


Et c'est pas bien ca ?
Selon moi, les temps de dveloppement ct" base de donnes sont plus rapides  mettre en place que du dveloppemnt ct application.

----------


## B.AF

> Et c'est pas bien ca ?
> Selon moi, les temps de dveloppement ct" base de donnes sont plus rapides  mettre en place que du dveloppement ct application


Mouaai...a reste compliqu  tester, trs orient donnes.

----------


## el_slapper

> Et c'est pas bien ca ?
> Selon moi, les temps de dveloppement ct" base de donnes sont plus rapides  mettre en place que du dveloppemnt ct application.


et  maintenir? (je pose la question, je n'ai jamais eu le cas, mais j'ai des doutes)

----------


## B.AF

> et  maintenir? (je pose la question, je n'ai jamais eu le cas, mais j'ai des doutes)


Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le pass quand tu as gout aux joies de langage plus rcents.

----------


## psychadelic

c'est vrai que maintenir du SQL, surtout en procdures stockes est une vraie galre.

Les liens entre celles vraiment  utilises, passes, de test et les appli les utilisant rellement constitue un vrai petit foutoir.

De ce point de vue LINQ est une vraie avance.

Mais si on rsume le mouvement NoSQL  juste une autre manire d'interroger des Bases de Donnes structures autrement que par des tables et des colonnes, on passe largement  cot de ce problme de maintenance.

----------


## ametaireau

NoSQL ne signifie pas "Non au SQL", mais bien "Not Only SQL". _Il existe d'autres solutions, peut tre plus adaptes  nos applications_.

Rien ne sert de fonctionner par dichotomie, et de penser que l'un est  l'inverse de l'autre par ailleurs. Je trouve que l'approche de certaines bases de donnes NoSQL peut tre trs interessante et apporter beaucoup en terme d'volution de nos pratiques de requetage de donnes (je pense par exemple au systme de Map/Reduce).

NoSQL "s'carte du modle relationnel et aurait tout aussi bien pu s'appeller de faon plus approprie le "NoREL", ou quelque chose dans ce sens" (dixit wikipedia).

Mais j'avoue que le terme est un peu fort et provocateur,  tort selon moi.

----------


## SQLpro

Quelques remarques<...




> Et c'est pas bien ca ?
> Selon moi, les temps de dveloppement ct" base de donnes sont plus rapides  mettre en place que du dveloppemnt ct application.


Oui, lisez les tudes de Paul Dorsey et Toons Koopelars sur le sujet. Y'a pas photo.




> Maintenir une appli faites quasi exclusivement de SQL c'est un vrai retour dans le pass quand tu as gout aux joies de langage plus rcents.


Vous oubliez le point noir : les langages itratifs ncessite un dploiement et une interruption de service mme pour des serveurs d'objets, alors qu'avec du SQL toute interruption est inutile puisque le code est strictement dynamique !




> c'est vrai que maintenir du SQL, surtout en procdures stockes est une vraie galre.


L vous plaisantez j'espre, c'est un problme de culture et donc de connaissance et formation...
Le code C#, Java est aussi abscons pour un  nophyte que du SQL !
Mais l'avantage de SQL c'est qu'il est trs richement document, ce qui n'est pas le cas des langages les plus rcents !

Au total, je me demande si vous n'tes pas des techno victimes comme il y a des fashion victimes ???

A +

----------


## B.AF

> Vous oubliez le point noir : les langages itratifs ncessite un dploiement et une interruption de service mme pour des serveurs d'objets, alors qu'avec du SQL toute interruption est inutile puisque le code est strictement dynamique !


Et que dfinissez comme interruption de service ? 
Le fait que toute modification soit prise en charge instantanment ? 

La plupart des langages qui sont supports par des VM permettent de faire cela bien plus facilement qu'on ne le croit. En tous les cas .Net et Java sont trs efficaces sur ce sujet. Il suffit de voir des projets comme Mono Addins, M.E.F, OSGi, RCP....Avec des mcaniques d'activation trs pointues et des fonctionnalits de dploiement intgres.

Les patchs SQL en revanche, c'est un enfer  raliser,  grer,  appliquer...

----------


## Katleen Erna

*Mise  jour du 09.07.2010 par Katleen
Des dveloppeurs vous offrent une mthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?*

Une quipe de dveloppeurs passionns (du site DZone) vient de publier une carte de rfrence intitule "Dbuter avec NoSQL et l'extension de donnes". 

Les bases de donnes NoSQL (et les technologies oprationnelles sur les donnes associes) sont en effet dsormais incontournable pour les dveloppeurs web. Elles sont largement utilises pour les grandes boutiques en ligne et commence  se faire une place dans les infrastructures IT.

Donc, cette carte de rfrence est l pour aider les professionnels  se poser les bonnes questions concernant les implmentations spcifiques de NoSQL ; tout en apportant les outils de base pour identifier les diffrentes technologies NoSQL et les utiliser.

Source : Getting Started with NoSQL and Data Scalability (PDF)

 ::fleche::  Trouvez-vous cette refcard utile ?

 ::fleche::  Pensez-vous qu'un dveloppeur doive matriser le NoSQL, ou bien n'est-il qu'une mode passagre ?

----------


## piklein

> *
> Des dveloppeurs vous offrent une mthode d'utilisation de NoSQL, cette technologie est-elle un must ou un feu de paille ?*



Un peu de failles ?

----------


## Porkepix

> Un peu de failles ?


Joli, joli!  ::mouarf::

----------


## Nathanael Marchand

Il est clair qu'aucun editeur n'a fait du SQL  sa sauce (le PL/SQL et le T-SQL ne sont que des vues de l'esprit). Il est aussi limpide que par exemple pour retourner les trois premires lignes d'une requtes il existe une seule instruction (non sur Oracle ca n'est pas ROWNUM, non sur SQLServer ca n'est pas TOP, non sur MySQL ca n'est pas LIMIT)

----------


## psychadelic

> Citation:Envoy par ezmac
> si ce mouvement existe c'est qu'il existe des besoins qui ne sont pas couverts par SQL !!!!Lesquels par exemple ?
> Personne n'a donn d'exemples concrets.


BigTable de Google par exemple, tu te dbrouillerai comment toi, pour rfrencer, classer, restituer,... des milliards d'informations non structures ??




> [B]Mise  jour du 09.07.2010  Pensez-vous qu'un dveloppeur doive matriser le NoSQL, ou bien n'est-il qu'une mode passagre ?


Mme rponse  :;):

----------


## pseudocode

> Pensez-vous qu'un dveloppeur doive matriser le NoSQL, ou bien n'est-il qu'une mode passagre ?


Hum. Pour moi il n'existe pas de NoSQL  "matriser", sous-entendu il n'y a pas une spcification unique de ce qu'est le NoSQL. Pour moi c'est plus un philosophie consistant  rflchir quelques instants avant de courir vers une solution SGBD.

Je pense aussi que c'est plus qu'une "mode", dans le sens o le problme de font est bien rel : comment grer efficacement des (grandes) quantits de donnes non structures,  la disponibilit changeante, et lies entre elles par des relations floues (non boolennes, temporelles, ...) ?

Je ne sais pas si la solution consiste en une volution des SGBD actuels, o en la cration d'un nouveau concept.

----------


## daedric

Mais est ce qu'il y a quelqu'un qui a *vraiment* regard ce qu'etait une base de donne NoSQL ? Le dbat ici est totalement inutile et  ct de la plaque.

Vous vous contentez de dire pour la majorit:
'SQL c'est bien' et 'NoSQL c'est bien'

La comparaison des deux n'a pas lieu d'tre faite ... C'est fait pour des problmes diffrents ...

Exemples:

Redis peut servir  mettre en cache des donnes, comme memcache.
A la base c'est pour du stockage 'in memory'
Donc a pourrait tre mis en place pour mettre en cache le rsultat d'une requte SQL.

Riak: Bonne distribution. On peut ajouter des nodes les doigts dans le nez, les supprimer. Map-Reduce sur les donnees reu. Deploiement facile.

MongoDB: Base de donnes distribues. Stocke du BSON. peut faire du sharding: stock dans tel ou tel noeud les donnes reu selon la valeur de certaine clefs.

Cassandra: P2P mais trs statique dans sa configuration (et ses super-column), stocke du json de mmoire.

Toutes gerent plus ou moins de la replication, master/slave, etc.


Une base de donnes relationnelles comme son nom l'indique sert  stocker des donnes aillant des relations. Donc je ne vois pas ou est le dbat:

Par exemple: Je veux stocker des metrics d'un pool de serveur, j'utilise un Riak d'autant plus si je veux les traiter a la vole  la reception, (typiquement un retour de collectd).

Je veux faire un blog, donc: utilisateur associs avec des articles, des commentaires ... j'utiliserais un *SQL (postgres, mysql, sqlserver, oracle et j'en passe)

----------


## pseudocode

c'est toi qui a dcid d'en faire "2 problmes diffrents" en segmentant leur utilisation par domaine. Mysql n'est plus spcialement destin aux blogs que Riak aux mtriques.

Rduire le dbat a SQL=relation et NoSQL=indexation est a mon sens trs restrictif.

Exemple :


```

```

Il s'agit donc bien ici de stocker des entits avec relations. Est-ce que SQL est le plus adapt pour grer des requtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?

----------


## daedric

> c'est toi qui a dcid d'en faire "2 problmes diffrents" en segmentant leur utilisation par domaine. Mysql n'est plus spcialement destin aux blogs que Riak aux mtriques.


Malgr tout je pense que si, aprs a dpend evidemment du volume, du traitement et de la manire de les stocker.




> Rduire le dbat a SQL=relation et NoSQL=indexation est  mon sens trs restrictif.


Je le reduis pas a ce point l il est quand mme de faire des requtes assez puissantes en NoSQL.

Simplement ce n'est pas aussi puissant que des requtes SQL avec des jointures entre tables ...




> Exemple :
> 
> 
> ```
> 
> ```
> 
> Il s'agit donc bien ici de stocker des entits avec relations. Est-ce que SQL est le plus adapt pour grer des requtes du genre "quels sont les individus auquel 'A' accorde +50% de confiance" ? Et si on ajoute une notion temporelle dans la relation (valeur de confiance variant en fonction de la date) ?


A ce niveau la je pense que l'architecture rentre en compte. Si le tout doit tre distribu il sera peut-tre plus simple de mettre une db NoSQL qu'une base de donne relationnelle.

----------


## Shepard

Je ne suis pas un pro du domaine, d'ailleurs je suis encore tudiant, mais mon avis est que SQL n'est certainement pas dpass, et pour moi NoSQL n'est simplement pas la bonne solution.

Beaucoup d'tudes ont t faites dans le monde des bases de donnes, et de nombreuses amliorations ont t proposes. Pour n'en citer qu'une, transrelational qui, bien que critiqu, apporte d'importantes amliorations au niveau des performances et rend les index quasiment inutiles. Sans compter le gain au niveau de l'espace disque utilis.

Malheureusement, ce genre d'amliorations n'est pas pris en compte par les SGBDR, certainement  raison, je rpte que je ne suis pas un pro du domaine, toutefois je pense qu'abandonner le relationnel pour de la gestion avec des fichiers, a c'est un vritable retour vers le pass, et si j'ai bien compris, c'est ce que propose NoSQL.

Bien que je pense ne pas tre un dbutant en SQL, je n'aime pas ce langage, il a normment de mrite et l'informatique ne serait certainement pas ce qu'elle est sans lui, mais d'autres langages d'interrogation de DB relationnelles permettent un raisonnement plus logique et gnralement moins verbeux.

Malheureusement les produits ne grent habituellement que le SQL, donc avec des index et une structure qui ne se prte pas  une volution du systme de fichiers sur lequel il repose (encore une fois, je ne citerai que transrelational ici).

C'est n'est que mon humble avis bien sr  ::):

----------


## fkylol

Le modle relationnel a le mrite de proposer un support de qualit et normalis  l'implmentation d'un besoin fonctionnel labor, y compris modlis objet ou hirarchique. La 3me forme normale est un repre rassurant.
Il faut nanmoins rester pragmatique et grer les contraintes avec bon sens. a passe le plus souvent par une dnormalisation du modle, par exemple en pesant le pour et le contre de l'intgrit qu'apporte une clef trangre en regard des contorsions qu'elle impose lors de l'implmentation. a passe galement par l'externalisation de donne pour une raison prcise, par exemple un moteur NoSQL pour des donnes linaires  accder rapidement dans de grands volumes (plein d'autres exemples dans ce lien qui a t fourni ci-dessus http://5.freshminutes.it/2010/02/17/...ql-user-group/)
NoSQL (je dirais plutt NoRelation) ne se peut pas se substituer aux SGBDR et les SGBDR ont un domaine d'application bien plus large.
Il me semble que le cot passionn du dbat NoSQL/SGBDR vient de l'incomprhension entre ceux qui travaillent pour le Web grand public et ceux de l'IT au sens large et plus particulirement l'informatique de gestion qui couvre un spectre technologique plus riche.

----------


## susanoo

Je suis encore tonn que NoSQL fasse couler tant d'encre!
Dire que NoSQL est vers quoi, on reviendrait  dire que les donnes n'auraient plus de relations entre elles! :8O:  du jour au lendemain!
NoSQL devrait se trouver un autre adversaire!! sauf si je me trompe! 
Anyway 


> *Voyageur, si tu n'as pas de chemin, fait ton chemin en marchant!*


  ::):

----------


## pseudocode

> Je suis encore tonn que NoSQL face tend couler d'encre!
> Dire que NoSQL est vers quoi on va reviendrait  dire que les donnes n'auraient plus de relations entre elles! du jour au lendemain!
> NoSQL devrait se trouver un autre adversaire!! sauf si je me trompe! 
> Anyway


 :8O:  ? 

Personne n'a jamais dit que les donnes n'auraient plus de relation. NoSql se propose juste de ne pas devoir dfinir un modle relationnel (donc de ne pas modliser les relations). Un peu ce qui se passe sur ton disque-dur : tu n'as pas besoin de dfinir les relations entre les rpertoires pour y crer des fichiers.

----------


## JeitEmgie

En NoSQL, les relations sont dfinies par le "business case" c'est celui qui interprte les donnes qui
dcident des "relations" qui l'intresse et il n'y a aucune contrainte du ct du repository quand  la validit de ces relations

En RDMS, les relations sont dfinies au niveau du schma (cd un niveau meta), et ces relations deviennent contractuelles

or ce niveau meta n'existe que de manire extrmement tnue en NoSQL et beaucoup de solutions NoSQL ne prvoit mme pas de dfinition d'un niveau meta pour pouvoir insrer des donnes dans d'autres comme Cassandra, c'est vraiment extrmement rduit par rapport  un schma relationnel classique

et cette absence de niveau meta, ne concerne pas que les relations le typage des donnes est aussi totalement libre puisque tout est de toute faon stock sous forme textuelle

le NoSQL n'est probablement que la premire tape dans l'volution de la manire dont l'on considre les donnes
sans remettre en question les usages traditionnels des RDBMS

la suite sera sans doute les Grahp Databases (cd le stockage de triples (S,V,O) au lieu de paires (K,V) avec peut-tre un retour d'un niveau meta un peu plus riche) 
et il n'y aurait rien d'tonnant d'appendre un jour que Google ait fait voluer une version de BigTables dans ce sens pour implmenter le stockage li  leur projet de moteur de recherche smantique

----------


## Tommy31

> la suite sera sans doute les Grahp Databases (cd le stockage de triples (S,V,O) au lieu de paires (K,V) avec peut-tre un retour d'un niveau meta un peu plus riche) 
> et il n'y aurait rien d'tonnant d'appendre un jour que Google ait fait voluer une version de BigTables dans ce sens pour implmenter le stockage li  leur projet de moteur de recherche smantique


Je partage ce point de vue. La reprsentation par triplets est universelle en ce sens qu'elle n'impose pas la nature des relations qui unit les lments. Avec un v unique, on a l'expressivit d'une reprsentation par paires, avec un ensemble de v plus ou moins riche, on a l'expressivit d'un mcd, d'un modle objet ou d'une ontologie.

Si sur le cadre thorique c'est trs allchant, il faut que les systmes de stockage suivent, c'est--dire qu'ils soient performants. Or jusqu' prsent, ) ma connaissance, c'est encore au stade de la recherche.

----------


## JeitEmgie

> JOr jusqu' prsent, ) ma connaissance, c'est encore au stade de la recherche.


FYI

http://java.dzone.com/news/nosql-graph-database-feature

----------


## SQLpro

> mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a chang depuis, sauf un petit soupon d'XML et quelques verbes de plus....
> Et monsieur SQL reste fig dans le temps (je me revois dans les bancs de physique  l'universit).


C'est vrai qu'entre la norme SQL2 de 1992 et celle de 2003 il n'y a presque rien....
Extrait de mon ouvrage sur SQL, 2e dition, page 5:
*"
La deuxime norme (appele SQL92 ouSQL 2 d'un volume de 600 pages)...
"*
quelques paragraphe aprs :
*"
Les rfrences de la norme SQL:2003 sont les suivantes :
[...]
Les parties 1, 2 et 11 (1 650 pages) dcrivent les bases du langage. Les autres parties constituent les extensions (2 136 pages).
"*
Soit une augmentation de 275 % sur la partie "core" et globalement de 631%.
C 'est dire si SQL est dans le formol !!!!

Je ne connais pas de langage qui  dur plus de 30 ans et est l'objet d'untel rajeunissement !!!!

Par exemple aujourd'hui presque tous les SGBDR ont un SIG intgr ainsi qu'un outil d'indexation textuel, tous deux tant normaliss.
http://blog.developpez.com/sqlpro/p9...ext-search-no/
http://blog.developpez.com/sqlpro/p9...n-geographiqu/

Je vous invite donc  lire mes articles, ou mieux, mon ouvrage sur SQL.

A +

----------


## vosaray

Tiens ca fait un bout de temps que j'ai pas vu de notif sur le sujet que je viens de relire. 





> ou je suis dbile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a chang depuis,


Bon je ne vais pas tirer sur l'ambulance, mais que dire du C dans ce cas la ? Faut t'il remplacer toutes les couches natives crites en C par un autre langage juste parce que le C n'a pas volu ? 

Franchement, des fois il y a des paires de cla... pardon accolades qui se perdent  :;):   :

Puis je vous donne une petite info vite fait : aprs 1 an dexprimentation sur les bases noSql, en loccurrence CouchDB, j'ai jet lponge pour plusieurs raisons : 

1. performances mdiocres

Sur un volume de donnes somme tout pas si gros que ca, mais pas ridicule non plus ( 800.000 documents d'environ 30Ko chacun ), les perfs ne sont pas au rdv.

Certains arguent que les perfs seront les mmes pour un volume de donnes gigantesque. Ok,  presque vrai en terme de recherche, mais compltement faux en terme de mise  jour des index.

Donc si votre appli doit prsenter des mises  jour de donnes dans un temps relativement court, il faut trouver autre chose ...

2. consommation disque affolante ! 

Donc 0.8 millions de docs, 6 indexes a fait 45Go sur le disque rien que pour les indexes  :;): .

Chaque index utilisant un (1, uno, one .. ) ficher.  On se retrouve avec des fichiers de l'ordre de 9Go. 

Je vous laisse imaginer la joie de l'append du fichier en question. 

Et aussi mditer sur le fait que cacher les indexes en RAM demande tout de mme un budget plus que considrable.

3. pas adapt  des "requtes applicatives"

Franchement on a beau tourner autour du pot, si votre appli prsente les donnes dans un front-end classique, disons un tableau sortable sur plusieurs colonnes et un pager, le noSql ou en tout cas CouchDB il vaut mieux oublier.

Si vous voulez connecter un tel compo, qui est somme toute un grand classique du web sur une base CouchDb, alors il faut soit utiliser un produit d'indexage (avec le cout cpu/disque inherent) externe, soit crer un index par colonne et gerer un cache des cls (first,last) cot appli. 

Donc plus d'indexes = plus de disque et un temps de mise  jour peu acceptable, tout en consommant pas mal de CPU et d'I/O. De quoi franchement saturer votre systme (linux pour ma part). 

Quant aux produits d'indexation externe, type Lucene, ca marche, mais la prise en compte des changements est assez lente et le tout consomme pas mal de ressources supplmentaires.

4. Scurit ou est tu ? 

Ok on peut scuriser l'accs  la base via un login/mdp. Trs bien mais il n'y a rien pour scuriser les droits sur les documents. Donc en gros vous accdez  la base, et vous pouvez voir tous les docs qui y figurent. 

Acceptable si les donnes n'ont pas de contraintes de "data privacy", compltement  cot de la plaque si jamais une telle contrainte apparait dans votre appli ( ce qui fut mon cas )

Le sujet est effectivement complexe mais je trouve difficilement acceptable de ne pas y songer et de refuser d'avancer dans cette direction. 

Quant aux  "alternatives officielles"  pour bypass cette contrainte elles varient entre la bidouille et le grotesque :  une base par utilisateur rsout le pb. disent les "experts". Non mais franchement ....

5. Equipe de dev, pourrais tu descendre de ton nuage ? 

Euuh, franchement et trs subjectivement : lquipe core est comptente sur plein de sujets, mais compltement borne en terme de comprhension du monde "applicatif", bref de ceux qui souhaiteraient utiliser Couch comme storage. 

Il y a bein eu qq  tentatives de patching  pour aller dans le sens (par exemple le multi-view, une manire de combiner les index/vues pour fournir du multi critre) mais elles ont t isoles jusqu' ce que les contributeurs abandonnent leur ide ou se dsintressent du sujet ...

Ce type de comportement arrive sur pas mal de projets open source, mais je dois avouer qu'il est assez flagrant dans le cas de Couch.

Dommage je pensais que ce projet avait un avenir plus concret et ouvert en terme dutilisation applicative ....

Conclusion :

Pour palier  tout ces maux, j'ai fini sur une solution hybride : 

- tout ce qui concerne l'indexation, la recherche, la scurit & co => SQL
- storage des documents et rplication/fdrations des donnes   => CouchDB

Bref jutilise couchDb comme un disque partag accessible par http  :;): .  Tout mes indexes sont dans une base sql optimise.  

Je commence vraiment  me demander  quoi me sert Couchdb car je pourrais aussi bien avoir des fichiers sur disque et les rpliquer via un rsync ou autre systme du genre et y accder via un banal serveur http ...

Par ailleurs, l'ide tait de partir sur du CouchDB pour viter les rplications de bases SQL pas toujours performantes et pas toujours utilisables dans tous les cas de figure (full meshing par exemple ... ). De ce point de vue c'est rat aussi ....

Bref, tentative peu concluante pour un cout humain toutefois considrable.

Donc le prochain qui me sort que SQL c'est fini je lui colle les deux accolades vite fait bien fait et je compile le tout en %F, nouveau langage driv du Cbmol7 et du Hmaj7 dans une suite A/D/A sur un rythme pseudo binaire ..

----------


## pseudocode

@vosaray: 

De un, je dirais que tu avais simplement besoin d'un indexer et pas d'une base de donnes. De deux, je dirais que tu n'as pas choisi la meilleur base nosql pour ta problmatique. (MongoDB aurait t plus logique, si je ne m'abuse)

NoSql n'est pas un mot magique qui rgle les problmes de volumtrie et de performances. C'est une "alternative" qu'il convient de prendre en compte avant de foncer prendre la premire base SQL qui traine. Ni plus, ni moins.

----------


## vosaray

> De un, je dirais que tu avais simplement besoin d'un indexer et pas d'une base de donnes


Quand on a besoin de stocker, indexer et rechercher des donnes accssibles par plusieurs applications ou entitis, on pense trs souvent  une BD pour ce faire.  

On peut en discuter, mais en dehors de ce contexte je ne vois pas pour quelle raison utliser une bd ....




> MongoDB aurait t plus logique, si je ne m'abuse)


Pas vraiement, Mongo ne supporte pas la rplication "meshed", uniquement le master/slave  la mysql. 

L'avantage de Couch est justement de "fonctionner" dans un environnement largement rparti, chose que Mongo ne fait pas et ne fera pas dans un proche avenir d'aprs l'equipe de dev. 




> NoSql n'est pas un mot magique qui rgle les problmes de volumtrie et de performances


Non certainement pas, mais cela n'empeche pas que les bases NoSQL pourraient faire preuve d'un peu plus de performance et de volumetries plus raisonnables.

Dans mon cas il s'agissait de gerer des documents, en l'occurence des fichiers txt, rpartis sur plusieurs sources, accessibles en http(s) avec possibilit de recoupement et de federation de donnes.

Je continue  penser qu'une base documentaire (comme CouchDB) reste trs adapte  la problematique initiale. Dommage que le reste ne suive pas.

Par la suite une des contraintes du projet tait de faire de la rplication et rpartition et peu de serveurs relationels sont capables de le faire correctement, avec un cout raisonnable.

Pour conclure, je dirais que le NoSQL n'est pas un souci en soi. Raisonner en cls/valeurs est tout  fait accptable.  Cependant il faudrait : 

- pouvoir combiner les vues de manire  effectuer des recoupements ( bref faire de la recherche un minimum multi criteria ) 
- proposer des fichiers index (vues) un minimum plus dimensiones et pas faire de l'append systematique. 

Bref, se rapprocher du monde applicatif et du point de vue intgration plutot que de proposer des solutions, disons intellectuelement valables , mais dont le champ d'application reste trs restreint  :;):

----------


## pseudocode

> Quand on a besoin de stocker, indexer et rechercher des donnes accssibles par plusieurs applications ou entitis, on pense trs souvent  une BD pour ce faire.  
> 
> On peut en discuter, mais en dehors de ce contexte je ne vois pas pour quelle raison utliser une bd ....


J'ai juste fait cette remarque par rapport  ta conclusion sur ta solution hybride.




> Pas vraiement, Mongo ne supporte pas la rplication "meshed", uniquement le master/slave  la mysql.


Effectivement, je ne savais pas que tu avais des contraintes de ce type.




> Pour conclure, je dirais que le NoSQL n'est pas un souci en soi. Raisonner en cls/valeurs est tout  fait accptable.  Cependant il faudrait : 
> 
> - pouvoir combiner les vues de manire  effectuer des recoupements ( bref faire de la recherche un minimum multi criteria ) 
> - proposer des fichiers index (vues) un minimum plus dimensiones et pas faire de l'append systematique. 
> 
> Bref, se rapprocher du monde applicatif et du point de vue intgration plutot que de proposer des solutions, disons intellectuelement valables , mais dont le champ d'application reste trs restreint


Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques ( l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives cl-en-main.

C'est vrai que se construire un DataStore avec du NoSql ca ncessite  l'heure actuelle pas mal de plomberie, et ton systme hybride me semble une bonne approche.

----------


## vosaray

Effectivement , j'ai peut tre fait un petit post, disons  vocation "thrapeutique" histoire que "a" sorte.

Du coup les ides sont peut tre dans le dsordre  :;): 

Au dbut du projet on stait fix les contraintes suivantes

- un accs aux donnes via http
- une base de donnes documentaire avec possibilit de chercher sur les elements de la structure du doc
- une base rpliquable en plusieurs modes, pas seulement le master/slave
- une base permettant de chercher rapidement  travers un jeu de documents relativement consquent ( 800k docs ), quitte  indexer les docs au fur et  mesure de leur cration
- une archivage facile et rapide des donnes

CouchDB semblait, sur papier, taill pour ce type d'utilisation. 

Si on fait sauter la rplication, on peut effectivement considrer le fait dutiliser une base de donnes classique ( avec ou sans file system auxiliaire, le blob peut bien marcher pour des documents courts ). 

Et c'est c'est malheureusement ce qui se passe au final avec notre solution hybride  :;): .




> Il est certain que les base NoSQL sont pour l'instant uniquement des solutions techniques ( l'instar des bases SQL). Il n'y a pas encore vraiment de solutions applicatives cl-en-main.


Disons qu'avec CouchDB tu peux utiliser crire une "CouchApp", un concept d'appli "embarque" dans Couch ! 

L'ide est simple et pas bte : l'appli ntant qu'une suite de docs autant stocker l'appli dans le serveur couch. 

Sur papier c'est sympa. En pratique, dvelopper une couch app veut dire : crire du javascript  gogo, le dispatcher, le grer sur la base & so on ... 

Bref un joli concept technique avec comme preuve dimplmentation l'appli Futon qui administre la BD. 

C'est sympa, mais Futon est une appli dont les traitements et l'ergonomie restent simplissimes voire  spartiates. 

Il est difficile d'imaginer une appli web avec des contraintes mtiers rentrer dans la CouchApp. Et si jamais l'appli doit gerer des droits par doc/page, alors ce n'est mme pas la peine  :;): .

Et ce qui me "tue" c'est que lquipe de dev est prte  claquer du temps de dev et de discussion sur l'histoire de la "CouchApp", mais que les demandes concernant la scurit, les perfs des i/o ou tout simplement plus de fonctionnalits sur le moteur de recherche restent lettre morte ...

HS : dsl pour la longeur des posts, mais je suis de nature bavarde  :;):

----------


## budtucker

Bonjour  tous,

1 an plus tard, je pense que la communaut a du prendre plus de recul sur le noSQL et sa mode. 

1 an plus tard, je relance ce billet pour relancer ce dbat (combat ?) entre le noSQL et le pure SQL. J'aime PostgreSQL et les dernires versions nous montrent qu'il est capable de grer bien des choses. J'ai tent MongoDB et malgr lengouement de certains adeptes, je ne comprends pas comment fonder une architectures convenable et stable avec. Je m'y prends srement mal et ce post n'a pas  vocation  dvaloriser aucune base.

Cependant, j'aimerai que l'on m'explique pourquoi et quand utiliser noSQL. Est ce une question de performance (pourtant certains blog montrent que PostgreSQL serait plus performant,  voir), le clustering, autre...

A+

----------


## pseudocode

1 an plus tard, je pense que le NoSQL a trouv sa place en tant que "Not only SQL". 

SQL reste la solution la plus simple pour des applications raisonnables (donnes structures, jusqu' la centaine de Go, avec peu de modifications).

Le NoSQL reste la solution la plus performante pour grer du "Big Data" (structures variables, +1000 Go, souvent modifies).

Aprs, il y a les cas particuliers o une approche mixte/hybride vaut la peine d'tre envisage.

----------


## rimram31

> Le NoSQL reste la solution la plus performante pour grer du "Big Data" (structures variables, +1000 Go, souvent modifies)...


C'est plutt bien rsum et c'est bien ce qui me gne avec le buzz autour de NoSQL. Il est trop souvent "vendu" par des gens dont les comptences SGBD, en restant gentil, sont assez limites et vont te proposer du NoSQL de n'avoir su utiliser correctement une SGBD et un layer efficace au dessus.

D'autant plus qu'il est le plus souvent propos par des gens du web, qui citent Google, Facebook ... Mais quand on sait qu'une BDD est capable de plusieurs milliers de transactions seconde, comme tu le dis, pour peu qu'on ait du 80/20 voir plus de R/W, on a quand mme une srieuse marge  ::D: 

Aprs un souci de taille pour moi, concrtement, a donne quoi a l'exploitation? Ou trouve-t-on des "DBA" NoSQL? Quel retour d'exprience en comparaison aux dizaines d'annes des SGBD ???

----------


## vosaray

Salut, 

Un an et demi plus tard, je trouve que l'offre "NoSQL" s'est plutt bien toffe et a gagn en maturit. Au point mme de proposer du SQL aux utilisateurs (Apache Hive par exemple ). On peut trouver ca rigolo, schizophrne, mais en fait  bien y regarder tout cela se tient.

Donc pour ma part j'ai investi pas mal de temps sur Cassandra, une des implmentations de BigTable de Google reprise sous Apache. 

Actuellement je travaille sur un proto, qui gre 1T de donnes compresses contenues dans 4 nodes Cassandra et je suis plutt trs agrablement surpris : 

 Les performances de lecture sont trs intressantes (jai plus les chiffres en tte mais ca vaut largement une bd sql bien optimise )
 Les performances d'insertions le sont moins, nanmoins on arrive tout de mme  faire ingurgiter environ 8 Milliards de donnes primitives (strings ou floats)   lheure
 Le systme est vraiment linairement scalable, on ajoute des nodes et on augmente la bande passante en R et W. (en pratique, les clusters Cassandra n'ont jamais t dployes sur plus de 400 nodes .... J'ai de la marge ...)
 Le systme consomme peu d'I/Os (Memory tables, log update, async data flush) et si prend la prcaution de sparer les logs du stockage on obtient un systme trs performant
 L'administration est simple. Plusieurs socits proposent de lexpertise, de la formation et on peut aussi souscrite  du support auprs de Datastax. Notez quil est trs facile dajouter ou de dmissionner un node.
 Le schma est variable et column oriented. On peut altrer le schma de manire dynamique en cours de runtime.
 Laccs peut se faire en Java, mais aussi avec nimporte quel langage
 On peut faire du Map/Reduce Hadoop sur la base car le stockage SSTables est  compatible  HDFS 
 On peut faire des requtes csql , un espce de mini language sql like, avec possibilit de filtrages et de requtes imbriqus ( donc relations applicatives  )
 On peut ordonner les donnes en  cube , en fait du hash de hash , assez adapt pour du  analytics , pardon analyse de donnes multidimensionnelles chre   nos dcideurs et data geeks

Pour les inconvnients je dirais que : 

 La compression n'est pas trs efficace
 Les compactions des tables est longue et consomme pas mal de ressources, pnalisant le systme global
 j'ai not plusieurs instabilits lors de tests aux limites. Malgr un sacr tuning des paramtres de la JVM jarrive  planter les process  Un peu plus de self defense ne ferait pas mal dans le code.
 Les performances sont en grande partie dues a un design pertinent du modle de stockage. C'est certes une gnralit, mais avec Cassandra c'est flagrant. Donc si on utilise les mmes donnes dans des use case diffrents, on a peut tre interret  les dupliquer ( donc plus de place et charge ).

Dans l'ensemble je dirais qu'il s'agit d'un produit prometteur et trs adapte  la distribution, la haute dispo, la rplication et fdration de donnes intra et inter sites !  

Je trouve qu'il lui manque juste un cot un poil plus robuste pour tre proche de la solution idale dans mon cas. Mais cela a encore le temps de samliorer dans les mois qui suivent. 

Voil javoue tre trs trs agrablement surpris par Cassandra. Au moins autant que jai t dcu par Couch et Mongo un an auparavant.

Aprs, si vous me permettez, je trouve qu'il est encore plus difficile de s'y retrouver aujourd'hui avec les nouvelles "tendances marketing" et "keywords" comme "columnar database", "big data", "analytics" et ainsi de suite. 

Tout le monde aime les tartines sans savoir ce qu'on va vraiment manger  :;):

----------


## Chavenay

http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis

----------


## el_muchacho

> http://kkovacs.eu/cassandra-vs-mongo...uchdb-vs-redis


Plus utiles, les comparaisons sur le site de Riak.
http://docs.basho.com/riak/1.2.0/ref...ed-to-MongoDB/

----------


## SQLpro

> Le NoSQL reste la solution la plus performante pour grer du "Big Data" (structures variables, +1000 Go, souvent modifies).


1000 Go cela ne fait qu'un Tera octet... pas vraiment terrible, j'ai plein de client dpassant cette volumtrie dans un seul serveur...

Comme j'en avais marre de voir que les gens pensent que des bases de donnes relationnelles a doit reste  quelques centaines de Go, je me suis fendu d'un article pour vous monter qu'il existe bien des bases de plus de 1 Petoctet sous MS SQL Server et a se porte comme un charme !
J'ai fouill certains document en interne chez MS pour vous donner cette analyse :
http://blog.developpez.com/sqlpro/p1...-en-petaoctets

A +

----------


## pseudocode

> 1000 Go cela ne fait qu'un Tera octet... pas vraiment terrible, j'ai plein de client dpassant cette volumtrie dans un seul serveur...
> 
> Comme j'en avais marre de voir que les gens pensent que des bases de donnes relationnelles a doit reste  quelques centaines de Go, je me suis fendu d'un article pour vous monter qu'il existe bien des bases de plus de 1 Petoctet sous MS SQL Server et a se porte comme un charme !


Je n'ai pas dit qu'il tait _impossible_ de grer des gros volumes de donnes en SGBD-R. Je soutiens juste qu'il est plus performant  (i.e. simple, conomique, rapide, extensible ...) dans ce cas d'utiliser du NoSQL.

Je n'ai pas dit non plus qu'il tait _impossible_ d'utiliser du NoSQL pour grer sa vidothque ou un site de e-commerce. Je soutiens juste qu'il est plus "performant" dans ce cas d'utiliser un SGBD-R.

J'avoue que c'est un avis totalement subjectif. Par exemple, je trouve plus "performant" de stocker les blobs sur le systme de fichier et les metadata dans une BdD SQL plutt que de tout mettre en fichier ou tout en base. Je suis de la vieille cole: prendre l'outil le mieux adapt  la tche.  :;):

----------


## JeitEmgie

> ...prendre l'outil le mieux adapt  la tche.


Entirement d'accord sur ce point, surtout si l'on tend le concept de tche au contexte logistique et financier du client et pas seulement aux aspects purement technologiques.

D'autant plus que tous ceux qui vantent les mrites de leur "machin" favori - quel qu'il soit - ont tous une facheuse tendance  mentir par omission, ne fut-ce que sur le cot oprationnel pour que "tout fonctionne comme un charme"... 
Donc tant qu'on ne vous montre pas les factures, le nombe de personnes derrire, l'infrastructure et les logs d'incidents, (sans parler de l'analyse de risques lie  l'exploitation de telles quantits de donnes)... du "comme un charme" ds que  dpasse les centaines de Tera de donnes vivantes (qui sont consultes alatoirement et exploites de manire "intelligente" - pas des "btes" logs - et par plus d'une personne  la fois ...)  : cela reste du domaine du compte de fes ou du pre Nol, et ceci quelle que soit la technoloqie vante.

Que cela existe : certes, que cela fonctionne : sans doute, mais que cela se passe "comme un charme" :  d'autres...

----------

