Discussion :

[Cocoww]

Bonjour,

J'aurais voulu connaître vos avis concernant l'utilisation du moteur CouchDB pour assurer le stockage des données d'une application pouvant être soumis à une forte charge.
CouchDB est orienté document (grosso modo ça stocke du document json), et c'est justement là que mes doutes commencent. Je n'ai encore jamais utilisé de technologie No-Sql et j'ai du mal à visualiser comment une application pourrait entièrement reposer sur ce genre de techno.

Typiquement un des besoins essentiels dans une application est le contrôle d'accès. Comment stocker intelligemment ça dans des documents json ?
Pour info j'ai lu ça : http://paloit.developpez.com/tutorie...ntee-document/

J'en ai conclut donc qu'il faut un document de type Acl (d'ailleurs comment définir un type de document ?) et que les documents de type "Account/User" définiront un champs "acl" qui contiendra les ids des documents Acls. C'est la bonne voie ou je me fourvoie complètement ?

Second problème, tous les documents sont au même niveau (pas de hiérarchie ni de regroupement (à ma connaissance, et je sais que j'ignore beaucoup de trucs)). N'y a t'il pas un risque de "bordélisation" à long terme ? (Un peu comme le pourquoi on a inventé les dossiers de fichiers)

Qu'en pensez-vous ? Est-ce qu'un système hybride n'est pas mieux adapté (relationnel et non relationnel pour bénéficier de la cohérence des données, et de la performance)
Auriez-vous de la documentation avancée sur les bonnes pratiques du NoSql ?

Merci d'avance

[SQLpro]

Bonjour,

J'aurais voulu connaître vos avis concernant l'utilisation du moteur CouchDB pour assurer le stockage des données d'une application pouvant être soumis à une forte charge.

Qu'estb ce que pour vous une "forte charge" ,
2 000 utilisateurs insérant en parallèle des données ?
Des transactions régulières insérant 100 000 lignes toutes les 10 millisecondes ?
Un volume de données de 1 Go par minute ?

CouchDB est orienté document (grosso modo ça stocke du document json), et c'est justement là que mes doutes commencent. Je n'ai encore jamais utilisé de technologie No-Sql et j'ai du mal à visualiser comment une application pourrait entièrement reposer sur ce genre de techno.

ça, sert à gérer des documents non structurés (par exemple des mails) et faire essentiellement du "text mining"

A +

[Cocoww]

Bonjour,

Merci pour votre réponse

Forte charge..la question qui permet de cerner si la personne a saisi ce qu'était la forte charge :p (et peut-être que ma représentation est faussée!)
Disons que dans un premier temps l'application n'aurait qu'une très très faible sollicitation, et que c'est dans l'optique d'une évolution de ces sollicitations que l'utilisation de CouchDB prendrait son sens.

Il s'agit d'une application qui sollicitera beaucoup la lecture d'informations.
Du coup l'idée c'est d'éviter les sollicitations d'un sgbdr vis à vis jointures entre les tables lorsque la fréquentation des utilisateurs augmentera (moins de calculs..toussa, si en plus il y a en place une technique de meta-data (les champs d'informations dynamiques)). En gros c'est en préventif.

Après ma vision de ce genre d'outils est théorique, d'où mes questions (Et j'ai bien conscience que je peux être totalement à côté de la plaque)!

ça, sert à gérer des documents non structurés (par exemple des mails) et faire essentiellement du "text mining"

Donc du coup pour gérer des systèmes type acls ça serait overkill ? Dans ce cas faudrait-il (notez l'emploi du conditionnel) mettre en place un système hybride (relationnel pour certains systèmes et no-sql pour certaines données) ?

Merci pour vos éclaircissements

[SQLpro]

Dérivez mieux votre demande....

Quels type de doc ?
Sont-ils formatés même par famille ?
Ont-ils des caractéristiques à stocker ?

parce que interroger du JSON ou du XML c'est très notablement plus lent que du pur relationnel et donc vous allez avoir des problèmes de concurrence d'accès. Plus la lecture est longue plus vous limitez le nombre d'utilisateur en parallèle et plus vous diminuez la concurrence d'accès en lecture comme en écriture.

A -