IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

NoSQL Discussion :

MemSQL : un SGBD résidant en mémoire


Sujet :

NoSQL

  1. #21
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    A partir du moment où :
    - On doit conserver les données en mémoire
    - Qu'on se moque de la persistance/intégrité des données

    Utiliser un SGBD est une preuve d'incompréhension totale de l'outil qu'on a sous la main.

    Si on veut travailler en mémoire avec des objets mémoire, on travaille pas avec un SGBD.

    D'autant que LINQ de Microsoft permet déjà de "requêter" avec un langage "proche du SQL" des objets en mémoire, et que c'est extrêmement performant. Certainement bien plus que cette infâmie, qui nécessite un outil tierce au logiciel consommateur.
    On ne jouit bien que de ce qu’on partage.

  2. #22
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    MemSQL me semble répondre correctement à une problématique simple. Beaucoup d'application webs sont basé sur MySQL avec MemCache par dessus. Les interfaces étant différentes ce n'était pas super pratique. Ils proposent de remplacer MemCache par MemSQL, voire le couple mySQL+MemCache par MemSQL.

    On remarque que d'autres solutions "à la mode" comme MongoDB ont une durabilité équivalente à MemSQL.

    Ce n'est probablement pas une solution à vos problématiques ou usages usuels de SGBD, mais ça peut servir pour d'autres personnes.

  3. #23
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Je persiste à dire que dans ces cas là, le choix d'un SGBD pour stocker les données étaient une erreur à l'origine.

    Le SGBD peut éventuellement servir à stocker de façon persistante les données "après traitement", ou lors de "milestones", mais en aucun cas pour gérer les données en mémoire. A ce moment, il sera toujours performant et plus logique de tout charger en mémoire dans des objets et utiliser les algo adéquat pour les interroger.
    On ne jouit bien que de ce qu’on partage.

  4. #24
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Comme il est toujours plus performance de faire son propre SGBD spécifique à ses besoins.

    Par exemple dans un cas de service web stateless, le serveur web ne peut stocker aucune donnée dans son espace d'adressage. Il faut bien stocker les données quelques part. MemSQL serait tout indiqué pour ces données, par exemple un panier d'achat en cours de constitution.

    De même dans pas mal de cas perdre la dernière seconde d'enregistrement une fois par an n'est pas dramatique. En général dans les entreprises ils y a des erreurs opérationnelles de coût similaires plusieurs fois par an. Il faut l'éviter mais pas à n'importe quel coût.

  5. #25
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Je maintiens que pour les cas que tu donnes, utiliser un langage orienté objet, implémenter une sérialisation correcte (soit dans des fichiers, soit dans un SGBD), et requêter les objets en mémoire soit avec des algos "maison", soit avec LINQ ou équivalent, ça sera bien plus performant et maintenable que d'utiliser un SGBD mémoire.
    On ne jouit bien que de ce qu’on partage.

  6. #26
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Mémoire dans des fichiers... Mais dites moi ? C'est pas justement pour s'affranchir de cette perte de temps d'accès qu'on part sur de la RAM ?
    Désolé StringBuilder mais je ne suis pas du tout d'accord avec toi, pour ce que j'en conclue cela revient à redévelopper la roue et en moins bien.

    Quand à LINQ que tu nous vends il serait bien intéressant de voir des benchmarks comparatifs sur d'énormes jeux de données justement... Car je ne suis absolument pas convaincu !

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  7. #27
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Juste pour qu'on soit sur la même problématique, je précise un peu de quoi je parle car j'ai du mal à voir en quoi c'est facile d'accéder à de la mémoire sur dans un processus différent sur un serveur distant de façon un peu safe avec plusieurs accès simultané.

    J'entend une application web répartie sur des serveurs web front end et avec une base de données derrière (ou un cluster qu'importe).

    On peu prendre une application de type Wooga décrite ici: [ame="http://www.slideshare.net/wooga/1000000-daily-users-and-no-cache-splash-2011"]1,000,000 daily users and no cache (Splash 2011)@@AMEPARAM@@ssplayer2.swf?doc=2011-10-24-splash-jesper1024x768-111025103448-phpapp01&stripped_title=1000000-daily-users-and-no-cache-splash-2011@@AMEPARAM@@2011-10-24-splash-jesper1024x768-111025103448-phpapp01@@AMEPARAM@@1000000-daily-users-and-no-cache-splash-2011[/ame] qui utilise in fine MySQL + Redis (très similaire à MemSQL).

    On sent bien qu'avoir MemSQL dans ce cas aurait beaucoup de sens, histoire de ne pas avoir une interface type MySQL et une interface type Redi mais deux interface de type MySQL avec des implémentations différentes (basé fichier pour MySQL et mémoire pour MemSQL).

  8. #28
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Et que dire d'une application type MMORPG ?
    Les temps de lantence sont bien plus faibles, et les volumes d'information je pense bien plus importants.
    Pourtant, y'a pas la trace d'un MySQL derrière, et encore moins d'un memSQL.
    Si tu veux de la performance, du massivement multi-threadé/multi-process/cluter, tu t'encombres pas avec un SGBD pour gérer des données PUREMENT MEMOIRE.
    On ne jouit bien que de ce qu’on partage.

  9. #29
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Ensuite, tu me parles d'accès disques avec ce que je préconise...
    Seulement, lorsqu'on sérialise un objet, on n'est pas obligé de le mettre à jour sur le disque comme un porc à chaque modification.

    Habituellement, on va le faire lire sur le disque dans le constructeur de l'objet, et écrire dans le destructeur. Eventuellement, lors de modification de données sensibles, on va flusher manuellement sur le disque une modif, mais ce sera pas le cas la plupart du temps.

    Ensuite, le problème d'un memSQL, c'est que si t'as une base de 100 Go, il faut 100 Go de mémoire.

    Avec la sérialisation, si t'as 100 Go de données et que tu n'as besoin d'utiliser que 2 Go pour tes traitements, t'as besoin que de 2 Go de mémoire.

    Pour un jeu, classiquement, tu vas travailler que sur les utilisateurs qui sont connectés, les autres n'ont rien à faire en mémoire.

    Éventuellement, un démon va traiter les utilisateurs offline de temps à autres, mais à nouveau, il peut le faire de façon séquentielle, pas besoin de tous les charger en mémoire en même temps.

    D'ailleurs, on préférera remplacer ce démon par un traitement "de rattrapage", qui s'occupera de faire toutes les modifications lors de l'initialisation de l'objet, dans la foulée de son chargement. Ça évite de saturer le système à mettre à jour des utilisateurs qui de toute façon ne viendront plus jamais jouer.
    On ne jouit bien que de ce qu’on partage.

  10. #30
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Et que dire d'une application type MMORPG ?
    Les temps de lantence sont bien plus faibles, et les volumes d'information je pense bien plus importants.
    Pourtant, y'a pas la trace d'un MySQL derrière,
    C'est que tu n'as pas bien regardéun premier indice ici Un MMORPG est stateful par contre donc il load sur un serveur de jeu, sauvegarde de temps en temps ou quand le client s'en va. Si le serveur de jeu crashe, bah les dernières modifs sont perdues. Cela reste des bases de données très chargées. Le stockage est souvent sous forme de blob.

    Sur ton 2e post, j'avais bien précisé application stateless, donc la durée de vie de l'object en mémoire est une requête. A chaque requête, y compris Ajax, il faut retrouver les données et les sauvegarder à la fin du traitement si besoin. Chaque requête d'un même utilisateur peut être traité par un autre serveur web.

    Clairement on est d'accord qu'avoir un MemSQL qui saurait aussi utiliser le disque pour des données froide serait la réelle solution. Mais au niveau des algo ça ne semble pas évident à merger disque/mémoire en étant ultra performant dans les deux.

  11. #31
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Je n'ai jamais dit qu'il fallait utiliser ce genre de SGBD pour faire du stockage de données permanent. Ce serait même une belle c*nnerie selon moi. Relis un peu mes interventions, je pense avoir énoncé clairement le contraire et ce dès le début.
    En administration système on vous bourre le chou en insistant sur le fait que tous les SGBD sont là pour les données persistantes, mais certains outils ne sont clairement pas conçus pour cela et il serait bon de faire sortir des idées préconçues cela.
    Après si cela vous gêne tant que cela, libre à vous de ne pas nommer MemSQL comme étant un SGBD.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  12. #32
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Mouais.

    C'est un peu trop abstrait pour moi je pense.

    En tout cas, j'en démord pas : pour les applications qui me viennent en tête, rien ne sera plus rapide qu'une interrogation directement d'objets plutôt que de tables chargées en mémoire.

    D'autant que... juste pour rire... les SGBD sont de plus en plus masqués par des framework qui instancient les lignes des tables par des objets, et qui te font 200 000 requêtes là où une bête jointure ferait le travail correctement. Donc quand on travaille aussi mal (c'est le cas d'une large majorité des applications actuelles) le memSQL sera de toute façon plus lent qu'une application correctement réfléchie.

    Bon, après, il y a toujours des exceptions. Mais une exception reste une exception, on ne peut en tirer une règle générale.

    transgohan > c'est pas moi qui dit que c'est un SGBD, c'est l'outil qui en est un, c'est sa conception qui en fait un SGBD.

    Pour moi, il y a deux intérêts à utiliser un SGBD plutôt que des objets en mémoire :
    - Le clustering/multi-process, qui peut être natif chez le SGBD, et complexe à mettre en place quand c'est manuellement (point sur lequel insiste Jester)
    - Le fait de pouvoir interroger les données en SQL (point sur lequel insiste la publicité de memSQL : et à ça, LINQ répond parfaitement, avec des performances forcément suppérieures, puisqu'il n'y a pas d'intermédiaire entre les données et le programme, contrairement à memSQL.
    On ne jouit bien que de ce qu’on partage.

  13. #33
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    transgohan > c'est pas moi qui dit que c'est un SGBD, c'est l'outil qui en est un, c'est sa conception qui en fait un SGBD.
    Evidement puisque c'en est un.
    Ce que je reproche ce sont ceux qui disent que ce n'en est pas un car il n'est pas adapté pour gérer des données persistantes. La relation SGBD <=> données persistantes est une fausse idée.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  14. #34
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Ben disons que c'est quand même, normalement, fortement lié.
    Je n'irai pas jusqu'à te contredire, mais je serait tenté de dire que ce n'est pas le terme SGBD qui est le plus adapté, mais plutôt un SGD (Système de Gestion de Données -tout court-).
    Car il n'y a plus de concept de "base", qui, d'un point de vue sémantique, implique quand même un minimum de persistance...
    On ne jouit bien que de ce qu’on partage.

  15. #35
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 386
    Points
    9 386
    Par défaut
    En fait l'abus de la terminologie (car tu as tout à fait raison dans le fond) vient de l'utilisation anglaise du terme. A savoir DBMS (DataBase Management System) qui ne peut se décliner en DMS qui veut dire tout autre chose (Document Management System qui est GED - Gestion Electronique des Documents - en français). Du coup les anglophones parlent aussi de DBMS pour cela. Et en français on traduit donc les deux de la même façon.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  16. #36
    Candidat au Club
    Inscrit en
    Novembre 2006
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : Novembre 2006
    Messages : 5
    Points : 2
    Points
    2
    Par défaut Hard / Mémoire / Virtuel
    Effectivement, c'est un début.
    Si l'ACID est respecté, pas de soucis pour l'avenir.
    Ce qui serait intéressant c'est d'en savoir plus sur les machines virtuelles.
    Les sgbd/h/r/o/s (nosql inclus) sont, de fait, en mémoire.
    Quid des performances ?

    Damien Pinçon
    http://about.me/damien.pincon

  17. #37
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Euh... C'est pas parce que la machine est virtualisée qu'elle est en mémoire. Il y a toujours des accès disques, et heureusement.

    Sans compter que la plupart des SGBD ne supportent pas ou mal la virtualisation, donc attention !
    On ne jouit bien que de ce qu’on partage.

  18. #38
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    J'ose espérer qu'ils comparent leur SGBD avec une instance mySQL installée dans un ramdisk ou sur un ssd très performant
    parce que si leur mySQL est installée sur un simple HDD standard en 7200, leur comparaison c'est bullshit

    de plus, en cas de plantage de la machine, la base est perdue ?
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  19. #39
    Expert confirmé
    Avatar de shenron666
    Homme Profil pro
    avancé
    Inscrit en
    Avril 2005
    Messages
    2 519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : avancé

    Informations forums :
    Inscription : Avril 2005
    Messages : 2 519
    Points : 5 168
    Points
    5 168
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    Utiliser un SGBD est une preuve d'incompréhension totale de l'outil qu'on a sous la main.

    Si on veut travailler en mémoire avec des objets mémoire, on travaille pas avec un SGBD.
    à l'heure où le multiprocessing monte en flèche, les accès concurrents au même objet en mémoire est une problématique que l'on peut aborder de manière simple si on a un gestionnaire derrière, comme un SGBD

    en résumé, gérer ses objects en mémoire à l'aide d'un SGBD permet de gérer des accès concurrentiels plus facilement avec une application multitaches
    Tutoriels OpenGL
    Je ne répondrai à aucune question en MP
    - Si c'est simple tu dis que c'est compliqué et tu le fait
    - Si c'est compliqué tu dis que c'est simple et tu le sous-traite ou le fait faire par un stagiaire.

  20. #40
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 146
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    Par défaut
    Utiliser un SGBD pour gérer le multi-process en mémoire, c'est tout bêtement utiliser une moissonneuse batteuse pour tondre ta pelouse.

    Non seulement c'est complètement démesuré comme solution, mais en plus le résultat sera bien en deçà de ce que tu aurais obtenu avec les outils adéquats.

    Alors évidement, la tondeuse, faut la pousser, la démarrer à la main, et y'a pas la clim...
    On ne jouit bien que de ce qu’on partage.

Discussions similaires

  1. MemSQL 4 : le SGBD résidant en mémoire disponible
    Par Olivier Famien dans le forum Autres SGBD
    Réponses: 1
    Dernier message: 22/05/2015, 15h29
  2. MemSQL : un SGBD résidant en mémoire
    Par Hinault Romaric dans le forum Décisions SGBD
    Réponses: 46
    Dernier message: 10/07/2012, 10h23
  3. fichier mappé en mémoire
    Par WinBernardo dans le forum Delphi
    Réponses: 7
    Dernier message: 01/12/2006, 10h38
  4. [Debutant]Problème mémoire et SGBD
    Par ghan77 dans le forum Bases de données
    Réponses: 12
    Dernier message: 12/12/2005, 16h47
  5. Problème avec la mémoire virtuelle
    Par Anonymous dans le forum CORBA
    Réponses: 13
    Dernier message: 16/04/2002, 17h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo