Discussion :

[FaridM]

Bonjour à tous,

je lis pas mal de chose sur le NoSQL en ce moment et un avantage revient souvent, c'est la scalabilité horizontal des SGBD NoSQL.

Pourtant il me semble que la réplication se fait déja sur du SGBDR non?
Load balancer..., n'est ce pas de la scalabilité horizontale?
Pourquoi c'est plus difficile (impossible) sur des SGBDR?

Merci à tous.

[el_muchacho]

La scalabilité horizontale, c'est l'augmentation de performances par l'ajout de PC de relativement faible coût.

C'est rendu possible grâce aux bases de données open source gratuites, qui ne nécessitent pas une licence/CPU.
Les licences des bases de données commerciales sont tellement élevées (plusieurs dizaines de k€/CPU) que l'offre open source devient très intéressante pour beaucoup d'entreprises.

Ça n'a pas grand chose à voir avec la réplication, si ce n'est que cette dernière implique un 2e CPU, donc une 2e licence pour les produits commerciaux.

[Jester]

La structure de base des NoSQL est en général le MPP et shared nothing. Cela permet de passager à l'échelle en augmentant le nombre de noeud mais à contrario donne des fonctionnalités plus pauvres car la communication entre les deux devient plus complexe. C'est basé sur le sharding MySQL manuel classique, les client pair sur une instance, les clients impair sur une autre. Si vous voulez faire une opération sur des clients pairs et impairs en même temps ... ça ce complique.

Sur les SGBD classiques on a bien souvent que des copies. Donc si les données ne tiennent pas sur un serveur, elles ne tiennent pas sur 2 non plus.

[FaridM]

Sur les SGBD classiques on a bien souvent que des copies. Donc si les données ne tiennent pas sur un serveur, elles ne tiennent pas sur 2 non plus.

Je n'ai pas bien compris cette phrase.
Cela veut dire que les suppréssions et mises à jour ne sont pas reproduites (immédiatement) sur les copies ?

Comment ça les données ne tiennent pas sur un serveur ?


Edit : Je viens de me rendre compte que j'ai confondu 2 termes. En parlant de réplication je voulais parler de load balancing.

[SQLpro]

Non, les copies de données ne sont jamais synchrones dans les bases de données noSQL vu que c'est pas transactionnel par principe. Vous n'avez donc aucune garantie d'aucune sorte. Néanmoins, c'est généralement assez rapide.
par exemple Amazon annonce en moyenne une seconde pour mettre à jour les nœuds.

Le load balancing c'est différent. Certains SGBDR le font très bien. par exemple SQL Server permet de faire du LB, par partitionnement de certaines données. Ce qui est fait sur Fnac.com

A +

[FaridM]

Le load balancing c'est différent. Certains SGBDR le font très bien. par exemple SQL Server permet de faire du LB, par partitionnement de certaines données. Ce qui est fait sur Fnac.com

A +

En quoi est-ce différent?
Le principe est bien de répartir la charge sur plusieurs serveurs non?
Peut-on ici parler de scalabilité horizontale?

[SQLpro]

Non, les concepts diffèrent.
Par exemple sur fnac.com il y a n serveur SGBDR (MS SQL Server) se partageant le front office (clients, commandes...); Tant qu'un client navigue anonymement (il recherche un produit par exemple et lit les commentaires) il est envoyé sur le serveur le moins chargé à l'instant t. Ainsi de hit en hit il passe de serveur en serveur grâce au "load balancing".
Dès qu'il est authentifié (il a donné son mail et son mot de passe) on calcule un hash sur ces informations et un modulo l'envoi sur le serveur adéquat sur lequel il existe, mettons le serveur 7 (c'est le seul serveur sur lequel existe son compte).

Comme vous le voyez il n'est pas utile de répliquer toutes les données sur tous les serveurs :

• Les produits sont répliquées deux fois par jour entre le FO et le BO
• Les commentaires sont répliqués entre les serveurs FO à intervalle régulier dans la journée.
• Les commandes nouvelles sont répliquées toutes les 5 minutes vers le BO.

Cela s’appelle de l'architecture de données !

En tout il doit y avoir une quinzaine de serveurs entre le FO et le BO
+ la redondance.

A +

[FaridM]

Merci, j'ai compris.

J'en reviens au NoSQL.

On associe souvent les termes "Big Data" et "NoSQL" parce que scalabilité horizontale...
Mais si j'ai bien compris, la répartition des données sur plusieurs serveurs est utile uniquement si les demandes de connections sont très nombreuses, peu importe la quantité de données que contiennent ces bases non ?

[SQLpro]

Non. Je dirais que les systèmes NoSQL ne répondent pas du tout aux mêmes besoins que les SGBDR.

• Si besoin de transactions (en général liée à l'informatique de gestion : banque, assurance, compta, ventes...) alors base de données transactionnelle donc SGBD Relationnel.
• Si pas besoin de transactions (en général lié à l'informatique documentaire ou ludique : newsgroup, réseaux sociaux, blogs...) alors pas forcément besoin d'un SSGBDR.

La plupart du temps, les gros sites utilisent les deux (exemple Amazon utilise des SGBDR pour tout ce qui est commandes, paiement, facture et stock).

Les histoire de volumétrie ne sont que des épi phénomènes qui dépendant de la façon dont on compte les données. Par exemple pour Pann Starrs qui utilise une base de données SQL Server répartie sur 8 serveur, il y a à ce jour plus de 4 Peta octets de données dans les bases, sans compter les images numériques stockées en dehors de la base....
Les systèmes NoSQL ayant l'habitude de présenter leurs exploits en comptabilisant aussi ces fichiers externes, sous prétexte que l'information y est "déstructurée" !!!

A +

[FaridM]

Non. Je dirais que les systèmes NoSQL ne répondent pas du tout aux mêmes besoins que les SGBDR.

Ok, donc quels sont pour toi les besoins auquels réponds le NoSQL?

Merci

[SQLpro]

Des besoins de stockage et de listage de données semi structurées (XML par exemple) ou non structurées : document électronique de toute nature, persistance d'objet (JSON par exemple).

A +

[FaridM]

Ok donc NoSQL pour les données semi ou non structurées.

Mais pour pouvoir les stocker ces données, il faut bien les structurer avant.
Par exemple si je récupère des infos et que je veux les stocker dans une base MongoDB, il faut bien qu'à un moment je crée le document qui sera stocké et donc que je structure plus ou moins ces données.
Dans ce cas, pourquoi est-ce que je ne pourrai pas les stocker dans un SQGBR ?

[SQLpro]

Parce que tu n'es pas censé connaître la structure AVANT d'avoir le document.

Si je t’envoie un document XML il est bien structuré, mais de ma manière. Si je ne te donne pas la "grammaire" de ce doc, alors tu ne pourra pas l'atomiser dans tes tables !

A +

[FaridM]

Ok, je comprends.

Merci.