Des développeurs vous offrent une méthode d'utilisation de NoSQL, cette technologie est un must ou une mode ?

[pseudocode]

Envoyé par Michael REMY

je pense qu'avant d'envisager de passer à nosql pour un souci de performance, il faut déjà 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 problèmes de CRUD.

Bien sur, on peut toujours utiliser un SGBDR pour faire cela, mais ce n'est pas toujours nécessaire. Par exemple, les systèmes de fichiers (ext/ntfs) fonctionnent très 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]

Envoyé par pseudocode

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é.

[unBonGars]

Selon moi, noSql est un "anti hégémonie sql" qui se nourrit de nos (trop confortables) certitudes

Dans les temps imémoriaux où je commençais ce métier, sql vivait ses premières heures et oracle tournait sur des systèmes 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 complètement ratée et des copies concurrentes très réussies : Clipper et Foxpro

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

Sql a résumé la base de données à 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 critère qui se trouve dans la commande de création d'index et non pas dans l'index lui même. De même l'optimisation sur index sql est laissée au moteur de données et relativement difficile à forcer.
Pour conclure : les indexes Xbase sont plus précis et potentiellement plus rapides.

Merci aux rois d'Oracle de ne pas argumenter sur le schéma 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 cornéliens et parvenir à une relative inter opérabilité entre data engines. NoSql remet ça sur le tapis.

S'agit-il du vieux rêve 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'empêche :
les bases de données sont tellement stratégiques dans certaines productions qu'on peut estimer leur valeur à plusieurs millénaires/homme, cela fait réfléchir car ça ne risque pas de diminuer ! On va bien finir par centraliser des sommes de connaissances universelles telles que contester le modèle 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 sociétés apprécient mais pour un gars qui veut produire de grandes choses dans ce métier, le challenge actuel est : SQL ou rien ! c'est sans doute la raison de ce mouvement anti sql : l'hégémonie n'est pas plaisante

Enfin, il faudrait parler de la base objet : j'ai écrit trois programmes basés là dessus, je crois que ZOPE utilise une telle architecture... Mais pour géniale 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 intéressante.

[unBonGars]

Envoyé par pseudocode

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 tâche ? J'ai utilisé sqlite dans un projet industriel où sql n'est pas maitrisé par la plupart des intervenants (la faute à la formation des ingés me semble-t-il)

En 92 j'ai aussi écrit mon propre moteur en C très rapide (et très limité) mais :

Combien de temps pour développer un outil crédible 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 séquenciel indexé ? le parser SQL ? le système d'optimisation? DDL ?

Arbres binaires ?

matrices ?

Quoi concrètement ?

[pseudocode]

Envoyé par unBonGars

Mais ccombien de vies humaines comptes-tu consacrer à une telle tâche ? JU'ai utilisé sqlite dans un projet industriel où sql n'est pas maitrisé par la plupart des intervenants (la faute à la formation des ingés me semble-t-il)

En 92 j'ai aussi écrit mon propre moteur en C très rapide (et très limité) mais :

Combien de temps pour développer un outil crédible 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 séquenciel indexé ? le parser SQL ? le système 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 spécifiques des SGBDR, comme le schéma relationnel ou le langage de query.

- Si la réponse est OUI, alors il faut bien-sur prendre un SGBDR.
- Si la réponse 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]

Envoyé par unBonGars

Mais ccombien de vies humaines comptes-tu consacrer à une telle tâche ? JU'ai utilisé sqlite dans un projet industriel où sql n'est pas maitrisé par la plupart des intervenants (la faute à la formation des ingés me semble-t-il)

En 92 j'ai aussi écrit mon propre moteur en C très rapide (et très limité) mais :

Combien de temps pour développer un outil crédible 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 séquenciel indexé ? le parser SQL ? le système d'optimisation? DDL ?

Arbres binaires ?

matrices ?

Quoi concrètement ?

Peu importe, il y a bien un jour où il faut se poser la question, sinon c'est refuser le principe même 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 dérange dans le NoSQL... C'est le "No SQL".

Si c'est avant tout une méthode différente de stockage et de recherche des données (distribution des données sur plusieurs systèmes, 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 étalés sur plusieurs disques, mais du partitionnement dans plusieurs machines.

Cela dit, étant responsable informatique dans une entreprise qui change actuellement de logiciel métier, je dois dire que je suis surpris qu'on se pose aujourd'hui la question du découpage des données sur plusieurs machines.

Aujourd'hui, SGBD ou pas, c'est actuellement totalement transparent chez les hébergeurs. Les baies de disque font pour nous ce travail de distribution des données sur plusieurs systèmes. 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 complètement transparent pour les logiciels qui accèdent aux données, 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 répartition des données sur plusieurs PC) je ne vois pas où il y a de l'avenir pour une telle chose : si au niveau du matériel on le gère déjà très bien, à quoi bon s'emmerder à le gérer dans le programme, et encore plus dans la philosophie de programmation ?

Pour en revenir au développement sur PDA, on a de plus en plus la possibilité d'utiliser un SGBD. Les CPU embarqués sont de plus en plus performants, la quantité de mémoire de moins en moins limité, et on a de loin des performances supérieures à un serveur NT4 d'il y a 10 ans... Qui faisait tourner sans problème Oracle ou SQL Server ! Donc si l'avenir du NoSQL c'est ce genre de plateformes, c'est une mode morte-née

[deadalnix]

Si tu veux avoir les caractéristiques ACID, te faut un maitre, qui lui ne peut pas "scaler" indéfiniment.

[vosaray]

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

Il n'y a pas d'argumentaire technique, simplement l'ouverture d'un débat assez stérile 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 défendent les bases relationelles à tout prix.

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

Dans certains cas les bases "nosql" peuvent apporter une altérnative voire un complément 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 intéressante à lire, mais la je dois dire que franchement je ne vois pas le point ...

[pseudocode]

Envoyé par vosaray

Un billet un minimum argumenté aurait pu être intéressante à lire, mais la je dois dire que franchement je ne vois pas le point ...

Regarde celui du post #27, cité par deadalnix.

[B.AF]

Envoyé par vosaray

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

Il n'y a pas d'argumentaire technique, simplement l'ouverture d'un débat assez stérile 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 défendent les bases relationelles à tout prix.

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

Dans certains cas les bases "nosql" peuvent apporter une altérnative voire un complément 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 intéressante à lire, mais la je dois dire que franchement je ne vois pas le point ...

D'accord avec toi de A à Z.

[popovitch130]

Envoyé par Michael REMY

je pense qu'avant d'envisager de passer à nosql pour un souci de performance, il faut déjà 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 idée ? (MySQL->PostGreSQL)
Concrètement, il se passe quoi quand un SGBD ne tient pas la charge ?
Ça m'intéresse car j'ai développé un robot qui enregistre un gros volume de pages web et de liens (plus de 700 000 entrées sur certaines tables).
Et lorsque je crawl un site de plus de 100 000 pages, au bout de 4h-5h environ je script s'arrête et comme je ne suis pas un boss des BDD ... quelques explications sur ton dernier post m'interessent vivement

[deadalnix]

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

Même si tu as une grosse charge le SQL est surement une bonne solution. Le NoSQL est une solution pour les systèmes ENORMES comme digg twitter ou autres. Sinon oublie, ce n'est pas pour toi.

[B.AF]

Envoyé par deadalnix

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

Même si tu as une grosse charge le SQL est surement une bonne solution. Le NoSQL est une solution pour les systèmes 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 même qu'un file system.

Le but du jeu n'est pas de faire des comparaisons de scalabilités. C'est de se poser la question suivante :

Est-ce que dans une logique de meileure qualité logicielle (optimisation performance/utilisabilité/maintenance=), le recours systèmatique actuel à la base de données 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 coût; nombreux sont les posts et débats ici qui parle de techniques plus ou moins évoluées pour permettre à une équipe de dév 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 données, qui en forçant finalement la normalisation de tout deviennent complexes et difficiles à maintenir.
Le problème est cette "gray zone" (entre le langage et la db) qui aujourd'hui pose les porblèmes de maintenance.

En outre, on trouve de plus en plus souvent des logiques multi tenants dans les applications, avec des cloisonnements logiques forts, des méta données, 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 développer plus, mais je crois qu'il y une frontiére d'usage. On est pas en train de se dire : C# ou Java ; il s'agit d'outils fondamentalement différents.

[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'empêche d'utiliser du SQL ET du NoSQL dans une même application.

[ezmac]

Envoyé par Patriarch24

Je trouve quand même incroyable que certains pensent encore et toujours que SQL (et les bases de données relationnelles) seront la solution ultime de manière éternelle.
Il existe des domaines où ce n'est pas la panacée, et il existe des solutions bien plus performantes, n'en déplaisent aux fanatiques : déjà citée, la gestion de documents notamment. Pour autant, ces alternatives spécifiques à des métiers seront-elles généralisées ? Non SQL, ne disparaitra pas de sitôt, 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 lumière 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 problèmes, n'est-ce pas là une de nos compétence ?

ou je suis débile, mais si je ne me trompe pas SQL est un dinosaure du '92, et rien n'a changé depuis, sauf un petit soupçon 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 fourmilière 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 données (analytiques) ramenée par un moteur nosql non ?

[Lung]

Envoyé par ezmac

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.