Bonjour, depuis quelques temps on me parle du nosql .. je me suis vaguement renseigné et constaté qu'il existait environ 140 moteurs différents : MongoDb, cassandra et j'en passe ..
 
Chose qui m'a d'ailleurs étonné, c'est que sqlite n'en fait pas partie ..
 
En soit, cela est - il très différent que de stocker des documents sérialisés php ou json avec un registre " clé / valeur " ?
 
Pour une mise en production rapide, quel moteur nosql recommander ?
Quels gains de perf attendre vis à vis de mysql ou sqlite ?
 
Merci pour vos lumières  

Aucun gain significatif de performance à attendre, car toutes les bases de données utilisent en interne des arbres équilibrés, qui est une technique connue depuis longtemps et pour laquelle il n'existe pas d'amélioration significative qui soit possible.
 
Les gains de performance sont à chercher au niveau de la définition par l'utilisateur de la définition de ses tables et de ses index. Par exemple, j'ai souvent vu de mauvaises performances qui venaient du fait que le concepteur n'avait pas suivi les règles de normalisation de E. Codd, qui sont pourtant très utiles et qu'on devrait enseigner dans toutes les écoles d'informatique, ce qui est loin d'être le cas actuellement, malheureusement. Il suffisait pour moi de changer un peu les tables pour me conformer aux règles de normalisation pour obtenir des gains qui pouvaient être assez spectaculaires. Bien sûr ça demande un peu de réflexion et de changements au niveau des tables et des traitements.

olivthill, tu oublies de préciser que dans certains cas, dénormaliser peut aussi être une solution pour améliorer les perfs
Mais d'abord on modélise sa base en respectant la forme 3NF de Codd. Ensuite seulement, si on identifie qu'il y a des requêtes trop lourdes qu'on ne peut optimiser via les index ou une meilleure formulation alors on peut envisager de dénormaliser.

Tiens, un très bon topic sur les BD noSql sur ce forum :  
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

Ok, parfait, merci pour vos lumières
La question sous-jacente est : si l'on utilise un système de fichiers locaux pour stocker tout ce qui n'a pas besoin de mysql,
la RAM du serveur ( debian 6 dans mon cas ) cache t-elle ces fichiers avec un algorythme du genre LFU-R ??
( et rend de facto l'utilisation d'un "ramdisk" complétement non nécessaire )

J'ai lu que mongodb utilisait toute la RAM disponible pour cacher les données qu'elle gère
Dans le cas ou ma debian 6 met en cache les fichiers les plus utilisés sur le disque, puis-je proclamer ne pas en avoir besoin ?

Si ca ne tiens que sur un server, tu n'as pas besoin de nosql.
 
Comme dit plus haut, un bon design est bien plus important que le reste, tu passes a du nosql uniquement quand tu ne sais plus faire de progrès au niveau design et qu'il n'y a plus de hardware suffisamment puissant pour faire tourner ce que tu veux en un temps raisonnable.

Salu à tous les administrateurs et membres de ce forum.Merci de m'avoir accepté parmi vous.
En fait, j'ai le probléme suivant avec la base de données SQL Server:
j'ai créé deux tables réliées dans un base données SQL Server, j'ai fait l'insertion dans les 2 tables sachant que la clé primaire de l'une de table est clé étrangère dans l'autre.
J'aimerai faire la mise à jour des données(modification) dans la table où se trouve la clé primaire et que cette se fait automatiqument dans l'autre table.Mais je reçois ce message:
Aucune ligne n'a été mise à jour !
les données de la ligne 1 n'ont pas été enregistrés
Source d'erreur:Net SQL Client data provider.
Message d'erreur: linstruction update est en conflit avec la contrainte reference FK_Commande_Produit.
Merci

Bonjour,
 
Ouvre un topic pour ta question. Merci d'avance,

Je vais aller à contre-courant:
 
Déjà SQLite n'est fait pas partie, car c'est bien du SQL.
 
Maintenant pour le choix du NoSQL, c'est toujours pareil: ca dépend. Il te suffit de répondre à cette question relativement simple pour avoir une bonne idée:
 
Une fois ton modèle définit, est-ce que ce sont les liaisons entre les tables qui ont de l'importance, ou le contenu des tables elles-mêmes ?
Si ce sont les liaisons, le SQL sera le mieux, si c'est l'opposé, le NoSQL sera le mieux.
Autrement dit: est ce qu'il est question de stocker beaucoup et d'avoir peu d’interactions entre les tables, ou bien générés de très grands nombres d'ids et tables intermédiaires, avec enfin de compte peu de données.
 
Un exemple simple:
Un système de commande (client - commande - ligne de commande - produit/SQL), le SQL sera certainement ton élément de choix principal car en fin de compte c'est la possibilité de transaction et l’interaction entre toutes ces données qui donne du poids à ta réalisation.
Un système de note (utilisateur - note(s)) n'a pas pour centre la liaison entre l'utilisateur et la note, et donc il sera bien plus intéressant d'éviter le SQL ici, car en fin de compte la liaison entre utilisateur et note à une importance faible face aux données brutes (dans le sens ou dans ton code, entre un code SQL et un code NoSQL, la différence sera inexistante: 1) je login le gars, 2) je récup ses infos associées => tu feras, dans l'un comme dans l'autre, 2 étapes).
 
Pour résumer; sur la plupart des systèmes dignes de ce nom, tu trouveras donc... les deux. Car aujourd'hui presque tous les systèmes ont des zones du modèle ou la relation à le plus d'importance, et d'autres zones on c'est en fait 'je peux stocker n'importe quoi n'importe quand n'importe comment' qui donnera l'avantage au NoSQL.
 
 
Pour répondre à tes questions:
En soit, cela est - il très différent que de stocker des documents sérialisés php ou json avec un registre " clé / valeur " ?  
Oui, Redis par exemple ira a l'essentiel face à MySQL par exemple (car il est pensé, et fait pour exclusivement). Les perfs seront supérieurs à du SQL, puisque Redis tente de tout mettre en ram le plus possible, sans aucune relation, et part du principe que la donnée devrait avoir une durée de vie faible (donc il ne va écrire sur le disque que quand il estime que c'est nécessaire), donc pour du clef/valeur volatile, il aura des performances supérieures à du SQL.
Pour la petite histoire d'ailleurs, Redis à été créé justement parce que MySQL ne supportait pas des accès très fréquent en lecture/écriture avec tout en volatile, les performances n'étaient pas à la hauteur (surtout à cause d'une écriture disque incessante). Donc il a dev une sorte de zone de cache qui a plutard donnée Redis, une base faite pour remplacer ce que MySQL ne savait pas faire: une sorte de très grosse zone de cache ou tout est chamboulé tout le temps.
 
Pour une mise en production rapide, quel moteur nosql recommander ?  
Pour du clef/valeur, Redis clairement.
Pour du documents sérialisés, d'une certaine taille, Mongo voir GridFS (un module de mongo), ou Hadoop si tu cherches a faire des traitements dessus.
 
Quels gains de perf attendre vis à vis de mysql ou sqlite ?
Sur Redis, si tu te limites au clef/valeur, de gros gain de performances: il est fait pour après tout, il est prévu et fait pour de la donnée hautement volatile sans structure, soit pour faire simple, l'exact opposé de SQL. Donc pour faire un système volatile sans relation, il sera devant MySQL, pour faire de la relation, cela s'inversera.
Cela dit, c'est toujours à relativisé, Redis a été créé parce que 10k requêtes en moins d'une minute ne passait plus sur SQL, donc t'a une très grosse marge avant de voir apparaitre une quelconque différence, ne pas oublier
Sur du stockage de fichier, ici le soucis est différent, la performance n'est pas vraiment le point clef, c'est beaucoup plus ce qui est offert qui est intéressant. Mongo via GridFS par exemple propose d'office le chunk du fichiers (= découpage de fichiers, pratique pour les très gros fichiers) + metadata associés + redondance et reconstruction des chuncks perdus en cas de perte d'un serveur. Tout ca en natif sans config particulière, si bien sur tu as plusieurs serveurs.
 
 
Morale de l'histoire: arrête d'écouter quelqu'un te dire que SQL c'est mieux, NoSQL c'est mieux, ils ont de toute façon tous tord, a partir du moment ou tu n'expliques pas clairement ce que tu veux AUTOUR de ton système. Une fois que tu auras définit clairement ce qui te parait important (les modèles ACID ? La prise en charge des pannes ? La volatilité des données ?) a ce moment tu choisiras celui qui te convient le mieux Et cela pourra être du SQL ou du NoSQL, chaque cas sera unique .
Cela dit j'espère que tout ce temps passé à écrire t'a fait comprendre ce que chaque base cherchait à apporter Et comme tu peux le voir, ca n'est pas forcément la façon dont on traite la donnée à l'instant T -et encore moins la performance associée- qui peut être intéressante (cf GridFS)

Merci pour cette belle réponse il est vrai en premier lieu que le code compte le plus en perf, j'utilise souvent un registre clé/valeur ( en ram pour temporaire ) sur disque quand persistant et n'eprouve pas plus le besoin a ce jour de changer. Je comprends parfaitement que redis semble le plus adapté à mes besoins mais que je ne verrais pas de suite les gains. De meme que de bons index en mysql sur du myisam a de tres bonnes perfs relativement a l'innodb, en perdant les clés étrangères ..
Plus l'on fait simple, le mieux cela marche

Ah
Bon ben t'a tout compris Pour ton soucis je pense que tu ne verras pas de différence significative entre SQL et NoSQL, car tu n'es pas dans un cas ou tu verras une différence significative, donc choisit celui avec lequel tu es le plus a l'aise, c'est ce qui te donnera la meilleur perf en dev (logique)

Pour te livrer toute ma vision de la chose et pourquoi cette question, voici le htop sur mon serveur on voit bien que les processus sql occupent bien la mémoire et sont de facto efficaces :

Je me demandais si sql occupait moins de mémoire, si la mémoire disponible ( bien que j'en ai la moitié sur le serveur ) s'affecterait toute seule au cache fichier ( pour pécher plus de performances sur mon registre clés/valeurs, pour les occurences les plus utilisées )

Car en utilisant /dev/shm/ Je n'ai pas remarqué de gain de performances significatif .. et là où mon code pêche le plus c'est en output de données, du genre 262ms pour 1 Mo de texte, lorsque j'effectue un readfile sans buffer .. de toutes façons je vois ce temps via firebug quand j'utilise le buffer, la mesure est la même au final

Si je n'ai que 35Mo de données réelles en sql, pourquoi les processus en prennent t-ils bien plus ? Gestion cache/clés/colonnes etc .. ?
Notez : j'ai redémarré le sql pour augmenter le nombre de connexions maximales, car j'étais passé à 34 ..

Explique un peu plus sur la façon dont tes process sont créés ? Est-ce qu'ils sont managés par toi ou un service ?
 
Parce que plusieurs instances sur le même datadir c'est pas toujours conseillé (enfin ca dépend de plein de choses donc c'est ptete une connerie ce que je dis là).
 
Dans ce cas, tu devrais avoir Redis en tête, de souvenir (perso je l'utilisait en link entre du PHP et du Node.JS), je dépassait pas vraiment 15Mo pour quelques milliers de sessions PHP stockées.
 
Par contre mongo tu auras le résultat inverse: il utilise le plus possible de ram pour maximiser la vitesse de réponse (genre il cache de base tous les index possibles et imaginables, et pas que...)

Bonjour
 
Un très bon article sur l'architecture NoSQL est disponible à cette adresse:  
 
http://blog.soat.fr/2015/02/base-d [...] istribuee/
 
 
en plus il est en français.
 
- Il décrit les différente architecture : cassandra, mongoDB et oracle et donne beaucoup d'éléments qui aident à choisir entre les trois.

C'est plutôt un lien à partager ici : http://forum.hardware.fr/forum2.ph [...] ost=134471 !