Discussion :

[Rototo912]

Bonjour à tous !

Je poste aujourd'hui dans une démarche purement informative, car je m'intéresse beaucoup au phénomène Big Data, et beaucoup des questions que je me pose restent sans réponse !

Je m'informe tout particulièrement en ce moment sur les bases de données NoSQL. On trouve pas mal de ressources sur internet expliquant les différences entre les bases de données key/value, colonnes, documents ou graphes.
Beaucoup de solutions existent pour chacune d'entre elles, par exemple HBase (colonnes), MongoDB (document), Riak (key/value) etc...

Au travers de mes recherches, j'ai également pu me rendre compte que beaucoup d'architectures physiques de stockage et de traitement étaient disponibles.
On retrouve :

• Les clusters, soit l'archi la plus utilisée pour du traitement Big Data, avec plein de machines clones qui bossent ensemble à la réalisation d'une même tâche
• Les Grids, soit un cluster de machines hétérogènes. Donc il faut bien coordonner le tout.
• MPP. Une même machine, plein de processeurs qui travaillent en même temps à la réalisation d'une tache. Mémoire non partagée
• SMP. pareil que le MPP, mais la mémoire est commune à tous les processeurs, du coup y'a une limite à la capacité de traitement
• Le cloud, soit tout ce qu'il y a au dessus, sans choisir une archi spécifique, vu qu'on sait pas ce qu'il se passe derrière.

Voici enfin ma question : Les bases de données NoSQL sont-elles dépendantes d'architectures en particulier? Si ce n'est pas le cas, les solutions (HBase, mongo, tout ca), qu'elles soient open source ou propriétaires sont elles dépendantes d'architectures en particulier?
Les comparatifs que l'on trouve ne sont jamais clair la dessus, enfin, ceux que j'ai pu trouver.
Existe-t-il selon vous d'autres architectures physiques pouvant acceuillir des solutions Big Data?
Connaissez-vous des solutions Big Data adaptées à des architectures de type SMP, MPP, ou adaptées à du Grid computing?

Si vous avez des sources à faire partager, je suis preneur, j'aime la lecture =)

Je vous remercie d'avance pour toute information que vous voudrez bien partager.
N'hésitez pas à me reprendre si j'ai dis des bêtises, c'est en faisant des erreurs qu'on apprend!

Cordialement,

[hugo123]

Ca dépend

Toutes les bases Nosql ont des prérequis différents.
Certaines peuvent être utilisés à partir de 1 serveur (mongo par exemple), d'autres non (HBase par exemple a plutot vocation à tourner en cluster).
Certaines bases acceptent l'utilisation de machines hétérogènes (cassandra par exemple), d'autre moins (un cluster Hadoop utilise en principe des noeuds assez similaires).

Malheureusement il faut un peu se pencher sur chaque base pour bien comprendre ces prérequis. Souvent le choix se fait déjà en fonction de ces cas d'usage et ensuite on essaie de comparer les bases pouvant répondre à ces cas d'usage. Le grand nombre de base n'aide cependant pas et il faut faire quelques choix car on ne peut pas toutes les tester.

[Rototo912]

Merci pour ta réponse Hugo123,

Je vais essayer de me pencher sur les différentes solutions, qu'elles soient open-source ou non

Cependant, j'aurai une autre question. De part leur nature, les BDD NoSQL sont flexibles, quant aux données qu'elles peuvent stocker.
Une BDD clé/valeur pourra avoir n'importe quel type de données dans la valeur associé à une clef, et dans une BDD graphe c'est pareil pour chaque noeud.
Mais tout cela, c'est de la théorie. En pratique, est-ce toujours le cas ? Stocke t-on n'importe quel type de données n'importe ou? Cela ne pose t-il pas de problème lors des traitements des données?
Certaines BDD NoSQL sont-elles plus appropriées pour le traitement de données à très haute flexibilité?

Merci d'avance pour vos réponses,

Cordialement,

[hugo123]

Dans mongo on ne stocke pas n'importe quoi dans la même collection. En général on utilise différentes collections pour des objets ayant des "buts" communs.
Dans cassandra t'as des notions de famille ou de table (je ne suis pas spécialiste).

Bref, assez souvent si le schéma est flexible cela ne veut pas dire pour autant qu'on mélange des choux et des carottes. Parfois ca sera le cas mais dans ce cas toute la responsabilité repose côté programmation pour faire correctement le tri.

[forrestdg]

De manière générale, le monde du NoSQL n'est pas aussi homogène que celui du relationnel.

Pour moi, une des raisons principales vient du CAP theorem:

- RDBMS: on sacrifie le P, donc tous les systèmes sont CA
- NoSQL: on garde presque obligatoirement le P, les systèmes sont soit CP, soit AP, soit entre les deux --> ils ne sont plus homogènes --> des design donc des stockages differents.

[hugo123]

Je me permets de citer un article qui résume assez bien ma pensée concernant les systèmes soi disant CA (ca n'existe pas):

http://codahale.com/you-cant-sacrifi...ion-tolerance/

[Rototo912]

Re-bonjour =)

Ahh, je me disais bien que la théorie ne pouvait pas s'appliquer à la lettre. Malgré le fait que les BDD NoSQL soient flexibles au niveau de leur structure de données, j'avais du mal à imaginer une BDD sans aucune structure...

Oui effectivement, Cassandra utilise une BDD de type colonnes il me semble, donc avec des familles de colonnes, et des super-colonnes, pour modéliser les jointures que l'on pourrait trouver dans une BDD relationnelle classique. (Arrêtez moi si je dis des bêtises, je n'ai que des connaissances théoriques la dessus)

Ahh, donc pas ou peu de structure dans la base demande un effort de programmation derrière, pour simuler ce que fait un SGBD classique en somme... Difficile d'imaginer choisir cette solution, si des alternatives plus sympas existent.

Je suis d'accord avec toi forest, j'ai pu lire par-ci par la que les SGBD classiques se basaient sur le théorème CAP de Brewer, et plus précisément sur les principes ACID, tandis que les BDD NoSQL se reposaient sur les principes BASE. On préfère la disponibilité à la cohérence en somme, d'après ce que j'ai compris.

Merci pour la source, je la lierai dans un de mes moments d’intense réflexion... prochainement sur le trône :p

J'aurai une dernière question à vous poser! Cela concerne la scalabilité des solutions NoSQL
On entend beaucoup parler de scalabilité pour toutes ces BDD, mais j'ai du mal à me représenter son importance du point de vue sémantique des modèles de données NoSQL.

La scalabilité horizontale, ou verticale, ca s'exprime par l'ajout de nœuds à notre archi réseau, soit des serveur/ordi, ou des processeurs en plus.
Donc c'est intimement lié à la solution propriétaire ou open-source.

Par contre, une BDD NoSQL au sens strictement théorique est-elle liée à la notion de scalabilité? Je veux dire, on a besoin de pouvoir monter en performance, à mesure que la volumétrie augmente, en faisant du parallélisme, mais ca c'est lié à l'architecture physique de réseau, pas à la BDD non?
Théoriquement, toutes les BDD NoSQL s'adaptent à n'importe quelle archi? C'est l'implémentation qu'on en fera qui changera, non?

Merci encore à tous ceux qui voudront bien m'éclairer

Cordialement,

[hugo123]

Beaucoup de questions intéressantes, ce sera dur de répondre à tout sans oublier quelque chose.

Les bases Nosql est un terme marketing qui regroupe des tas de bases n'ayant pourtant pas forcément de points communs. Beaucoup de bases proposent plus ou moins de fonctionnalités au détriment d'autre.
Certaines proposent peu de fonctionnalités pour se concentrer sur la vitesse et la scalabilité, d'autres au contraire propose plus de fonctionnalités au détriment de la vitesse et de la scalabilité.
Toutes les bases Nosql ne reposent pas sur les principes BASE.
L'un des principes de BASE c'est la cohérence à terme (eventually consistency), or un système comme mongodb est cohérent par défaut. Il y a une atomicité au niveau du document (mais pas multi document, ce n'est donc pas ACID non plus).
Sur certains systèmes comme Cassandra ou Couchbase tu as plusieurs noeuds sur lesquels tu peux lire, et tu peux jouer sur certains paramétrages (le nombre de noeuds nécessaires pour accepter une lecture ou une écriture) pour déplacer le curseur entre une plus grande cohérence ou une cohérence à terme.

Concernant la scalabilité

Donc c'est intimement lié à la solution propriétaire ou open-source.

=> j'ai pas compris le rapport avec l'open source

On associe souvent Nosql à BigData et à la scalabilité horizontale mais il existe des bases qui fonctionnent très bien en environnement NoBigData (mongo, redis, couchbase) avec un seul noeud. Dans l'ensemble c'est cependant assez vrai que ces bases sont apparues avec l'idée qu'il était plus facile d'exploiter des clusters constitué de plusieurs serveurs de bases plutot qu'un gros serveur très cher.
Cela soulevait cependant plusieurs soucis, la coordination entre les différents membres du cluster et la tolérance aux pannes. On peut dire que certaines bases Nosql ont été penchés particulièrement pour ces points (absence de transaction pour limiter les besoins de coordinations par exemple chez mongodb, sharding automatique chez elasticsearch, gestion des conflits avec vector clock pour riak etc...).
En tout cas on ne peut pas dire que chaque base fonctionne avec n'importe quel type d'architecture. Par exemple Hbase est fait pour tourner sur un cluster Hadoop avec un minimum de machine. HBase sur un seul noeud n'a pas de sens. Neo4j à l'inverse a un panel de fonctionnalités riche mais qui l'handicapent pour la scalabilité.
Une fois qu'on a bien compris les compromis entre fonctionnalités et scalabilité ainsi que les architectures types on s'y retrouve pas trop difficilement malgré tout.

[Rototo912]

Coucou =)

Humm ca doit être pour ca que mes questions ne sont pas très claires. En fait c'est comme beaucoup de choses, il y a la théorie sur les BDD NoSQL, et ensuite les implémentations qu'en font les éditeurs, pour faire des solutions, qu'elles soient propriétaires et payantes, ou open-source.

Je comprends bien comme tu me l'expliques que certaines implémentations sont dépendantes d'une infrastructure réseau, de type cluster pour certains, ou de type MPP pour d'autres (une machine, des processeurs etc...).

En fait, je suis en master en alternance, et je suis tombé sur un mémoire intéressant d'un ancien alternant. Il parle dedans de la théorie concernant les BDD NoSQL, et seulement de la théorie, en dehors de la pratique. Pas de mongo, pas de Cassandra ni rien de tout ca.
Et quand il parle des BDD NoSQL, il dit qu'un critère important est la scalabilité dans le choix d'une solution. Mais je ne trouve pas ça cohérent. Toutes les BDD NoSQL dans leur concept, ont été pensé pour faire de la performance, pour être distribuées, pour faire du Big Data en somme. En théorie, je les vois donc toutes scalables verticalement ou horizontalement.

Et ensuite, une fois que j'ai choisis une BDD colonnes par exemples, alors je dois m'intéresser aux implémentations qui en sont faites. Par exemple, Cassandra est une implémentation d'une base de données orientée colonnes. Je crois que Cassandra utilise un cluster, et donc favorise une scalabilité horizontale plutôt que verticale. Mais ça c'est propre à la solution Cassandra, et non au concept de BDD orientée colonnes. Non? Qu'en pensez vous?

Cordialement,

[forrestdg]

Je me permets de citer un article qui résume assez bien ma pensée concernant les systèmes soi disant CA (ca n'existe pas):

http://codahale.com/you-cant-sacrifi...ion-tolerance/

Du distribue CA ca n'existe pas je suis d'accord. Je dit bien que les RDBMS sont CA, Oracle est fortement consistent et rapide (si l'on fait des choses correctement et si on peut acheter des tours infiniment puissantes (vertically scalable ).

[forrestdg]

Il parle dedans de la théorie concernant les BDD NoSQL, et seulement de la théorie, en dehors de la pratique. Pas de mongo, pas de Cassandra ni rien de tout ca.

Je veux bien voir cette mémoire car comme disait hugo, ces databases sont tellement différentes que c'est quasi-impossible de trouver une architecture commune

Toutes les BDD NoSQL dans leur concept, ont été pensé pour faire de la performance, pour être distribuées, pour faire du Big Data en somme. En théorie, je les vois donc toutes scalables verticalement ou horizontalement.

Si performance=rapidité c'est non. Il y a tout en tas de systèmes qui sont la pour faire de l'OLAP, ou meme avec un systeme donne, tu peux le tunner selon ton utilisation.

La majorite des nosql se veut etre horizontalement scalable, pas verticalement.

[hugo123]

Et quand il parle des BDD NoSQL, il dit qu'un critère important est la scalabilité dans le choix d'une solution

A ca je répondrais que le critère le plus important c'est le cas d'usage. Neo4j pour ne citer que lui a des cas d'usage qui n'ont rien à voir avec une base clé valeur.
Faire le choix d'une base pour sa scalabilité c'est intéressant quand on a problème de... scalabilité. Je sais j'enfonce des portes ouvertes mais beaucoup choisissent des solutions scalables alors qu'ils n'en ont pas le besoin.
Et pour être honnête, identifier ces cas d'usage et le bon système pour y répondre est pour moi la partie la plus difficile. L'implémentation ensuite peut aussi être difficile, mais un mauvais choix conceptuel à l'origine est difficile à rattraper.

Je crois que Cassandra utilise un cluster, et donc favorise une scalabilité horizontale plutôt que verticale. Mais ça c'est propre à la solution Cassandra, et non au concept de BDD orientée colonnes. Non? Qu'en pensez vous?

Effectivement, le choix d'implémentations sous forme de cluster n'est pas propre au concept d'orientée colonne, enfin je ne pense pas. Cela dit, dans les faits, ce type de solution (Hbase, Cassandra, BigTable...) sont toutes faites pour être horizontalement scalable.

Du distribue CA ca n'existe pas je suis d'accord. Je dit bien que les RDBMS sont CA

Justement, le A voulant dire "disponible" il est impossible d'être "Available" sur un seul noeud. Ce que dit l'article c'est justement ca.

Soit on a un noeud, et dans ce cas il est facile de garantir la cohérence. Mais la disponibilité n'est pas garantie.
Soit on a x noeud, et dans ce cas, tenant compte des problématiques de partitionnement réseau (le fameux P de CAP), on va avoir des cas ou les x noeuds ne peuvent communiquer entre eux. Soit ils refusent les écriture pour conserver la cohérence en sacrifiant la dispo, soit ils acceptent les écriture pour conserver la dispo mais les données ne sont plus cohérentes.
Mais nombre de présentations sur le sujet font ce raccourci pour opposer RDBMS et Nosql. Ca fait partie du rituel

Cela dit je ne connais pas les solutions hautes dispo d'Oracle. As tu des précisions dessus ? Est-ce que Oracle accepte du multi maitre ? Et si oui, comment-fait-il la synchro pour garder la cohérence et comment gère-t'il le partitionnement réseau ?

[forrestdg]

Justement, le A voulant dire "disponible" il est impossible d'être "Available" sur un seul noeud. Ce que dit l'article c'est justement ca.

Soit on a un noeud, et dans ce cas il est facile de garantir la cohérence. Mais la disponibilité n'est pas garantie.

huh? tu melanges la disponibilite et la tolerance aux panne, si tu as un noeud et ce noeud n'est pas en panne, quelle est la probabilite que ton systeme soit indisponible?

[hugo123]

A priori je ne confonds pas :

http://en.wikipedia.org/wiki/Availability

For example, a unit that is capable of being used 100 hours per week (168 hours) would have an availability of 100/168. However, typical availability values are specified in decimal (such as 0.9998). In high availability applications, a metric known as nines, corresponding to the number of nines following the decimal point, is used. In this system, "five nines" equals 0.99999 (or 99.999%) availability.

http://whatis.techtarget.com/definit...iceability-RAS

Availability is the ratio of time a system or component is functional to the total time it is required or expected to function.

http://fr.wikipedia.org/wiki/Th%C3%A9or%C3%A8me_CAP

Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse;

Tiens d'ailleurs un autre article qui indique que les systèmes distribués CA n'existent pas :
http://blog.cloudera.com/blog/2010/0...ion-tolerance/

[forrestdg]

Tiens d'ailleurs un autre article qui indique que les systèmes distribués CA n'existent pas :
http://blog.cloudera.com/blog/2010/0...ion-tolerance/

On est toujours d'accord sur ce point depuis le debut :-)