Discussion :

[nathieb]

Les bases orientées graphe sont basées sur la théorie des graphes, les bases clé-valeurs (peu ou prou toutes les autres) sur les théories des calculs distribués : la plupart des algorithmes utilisés dans ces bases sont issus de théories diverses.
Encore une fois, la fédération autour d'un langage est possible car dans ce cas on ne traite qu'un paradigme (relationnel). Je ne vois pas en quoi mon assertion est fausse : les systèmes relationnels ne sont pas devenus du jour au lendemain performants, stables, etc, je persiste et signe. Ils ont beau être basés sur une théorie mathématique, il n'empêche qu'en quarante ans les choses ont évoluées...


Facebook : utilisation de Cassandra pour le système de messaging, d'une base orientée graphe pour la gestion des liens entre relations, entre autres. Google utilise BigTable et d'autres systèmes pour son moteur de recherche. D'autres utilisent Hadoop pour les traitements massifs de données.

ps : il n'y a pas que les applications de gestion qui existe. Et même celles-là peuvent utiliser du NoSQL pour fonctionner.


L'heure est en effet aux divisions d'applications, et non à l'intégration à l'extrême. Le but : utiliser le bon outil pour une tâche donnée (cf : WOA, micro services, architectures hexagonales etc.). Et la présentation de Martin Fowler est très intéressante aussi.

Tout a fait d'accord avec cette dernière phrase ...

Olivier

[landry161]

à l'origine des SGBDR une théorie et non pas le bricolage actuel du NoSQL. Une fédération très rapide autour d'un langage (SQL 1974 avant même les premiers SGBDR) et donc une normalisation très rapide (1986)... Ce qui en a fait le succès ! Cela existe t-il dans le noSQL ???Vous parliez de technologie mature ??? ;-)

Ce bricolage comme tu le dis est quand même utilisé par des géants comme Google,Facebook,Amazon. Donc vas-y doucement.
De toute les manières les bases de données NoSQL ne sont pas là pour combattre les base de données relationnelles.

[iolco51]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.


Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.

Cela n'arrivera pas demain et les bases NoSQL ont de beaux jours devant elles car le volume de données à traiter croit exponentiellement.

[spidetra]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).

Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?

[iberserk]

Tu aurais des exemples de bases hyper-relationnelles ? C'est une notion que je ne connais pas.
Est-ce que tu fait référence aux bases orientés graphes et aux hyper-graphes ?

Je pense qu'il voulais parler de bases fortement normalisées

[spidetra]

Je pense qu'il voulais parler de bases fortement normalisées

Tu parles de la 4° forme normale ? Je n'ai encore jamais croisé un projet qui ai poussé la normalisation jusqu'à cette forme.
Et, je ne vois pas trop l'apport du NoSql sur ce point. Au contraire, dans le NoSql, au moins dans les bases orientées documents, les données sont peu normalisées, redondantes, et pas relationnelles.
C'est pour cela que j'avais associé cette notion d'hyper-relationnelle, plutôt aux bases de types graphes.

[SQLpro]

Vision simpliste.

Les bases NoSQL sont apparues parce que les bases relationnelles ACID classiques ne pouvaient pas répondre aux problématiques (montée en charge, bases hyper-relationnelles, haut volume, disponibilité).
C'est aussi pourquoi le monde NoSQL est si vaste et hétéroclite, chaque solution a été conçue pour un besoin.

Ce que vous dies est faux et participe de l'escroquerie intellectuelle qui est à la base du NoSQL. En effet, dans le fameux théorème de CAP, il est dit que les SGBDR n'était pas capable d'assurer à la fois, le transactionnel, la répartition de charge et la haute dispo... mais les tenants du NoSql ont tronqué la fin de la phrase qui est "...de manière synchrone" Or la plupart des bons SGBDR sont capable de le faire de manière asynchrone (SQL Server, Oracle et DB2).
Et aujourd'hui force est de constater que la plupart des bases NoSQL ne le font pas non plus de manière synchrone. Certes, quelques secondes pour une réplication, c'est rapide, mais c'est aussi une perte importante possible en cas de plantage !

Quand les SGBD relationnels ACID sauront gérer des petaoctets de données de facon performante, efficacement en termes de stockage, et sans un sharding manuel des données, alors le NoSQL sera bien moins intéressant.

Quand à la quantité de Po, il y a longtemps que les SGBDR en ont emmagasiné et que cela est performant. Pour info je donnais une liste de plusieurs bases de données SQL Server en Po donnant toute satisfaction : http://blog.developpez.com/sqlpro/p1...-en-petaoctets. Depuis cet article de nombeux clients ont dépassé le Po

Cela n'arrivera pas demain et les bases NoSQL ont de beaux jours devant elles car le volume de données à traiter croit exponentiellement.

Bref, du grand n'importe quoi....

En fait les bases de données NoSQL ne sont intéressante que pour des données qui ne sont pas dans l'informatique de gestion (ventes, compta, production...) mais dans l'informatique documentaire (blogs, mail...) ou en complément de bases relationnelles.
Or comme la plupart des éditeurs de SGBDR traditionnels (Oracle, MS, IBM...) sont en train d'intégrer cela à leur moteur, les cassandra et autres acteurs de la chose qui ne sont pas encore économiquement rentables sont condamnés d'avance !

A +

[SergioMaster]

Bonjour,

En fait les bases de données NoSQL ne sont intéressante que pour des données qui ne sont pas dans l'informatique de gestion (ventes, compta, production...) mais dans l'informatique documentaire (blogs, mail...) ou en complément de bases relationnelles.

Enfin une remarque que je comprends et pleine de bon sens

[Youkhel]

je sais pas si je suis dans le bon endroit pour poser cette question :/ je m'excuse d'avance, veuillez me rediriger si c'est le cas...
je cherche à faire une analyse lexicale du langage "Hbase", je me demande si quelqu'un peut m'aider à trouver la grammaire de ce langage, ou au moins des programme utilisant ce dernier!! merci beaucoup

[hugo123]

Comme tu l'as pressenti, effectivement ce n'est pas le bon endroit ^^
Il faudrait que tu ouvres un autre topic/post à part de celui-ci pour cette question.
(je te donne qd même un élément de réponse, HBase n'est pas un langage mais une base de données orientée colonnes)

[Youkhel]

merci beaucoup