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

C# Discussion :

Persistance des données


Sujet :

C#

  1. #1
    Membre éprouvé
    Avatar de dkmix
    Profil pro
    Inscrit en
    septembre 2007
    Messages
    619
    Détails du profil
    Informations personnelles :
    Localisation : Jamaïque

    Informations forums :
    Inscription : septembre 2007
    Messages : 619
    Points : 924
    Points
    924
    Par défaut Persistance des données
    Bonjour,

    Pour une appli serveur, je dois implémenter un système de sauvegarde de données transparent (qui n'ai pas d'impacte pour les clients).
    Aujourd'hui, l'appli n'a pas besoin de base de donnée.
    Le but est simplement d'obtenir une sauvegarde (pour le chargement initial, ou en cas de crash).
    Précisions techniques : l'appli sera probablement migré en mono pour des serveur linux.
    L'enregistrement peut (doit?) être asynchrone, Le client n'attends pas de validation de l'enregistrement des données. (éventuellement un système de log serveur en cas de pb d'enregistrement).

    Je pense utiliser des threads pour les updates. Est-ce une bonne idée ?
    Avez-vous des exemples de pattern à utiliser ?
    SQL ? NoSQL ?

    Merci

  2. #2
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Mon conseil dépend des complexifications du problème.

    * D'abord une DB est-elle le meilleur choix ? Un simple arbre XML (automatiquement écrit via XmlSerializer) ne ferait-il pas l'affaire ? Si c'est pertinent et que tu peux tout réécrire à chaque fois ça simplifierait de beaucoup le code et tu n'aurais pas à gérer un système de mise à jour. Ton graphe d'objets est-il réductible à un arbre ? Peux-tu tout réécrire à chaque fois ?

    * Je te conseille de créer sur le thread UI une copie des données à écrire, puis d'écrire cette copie depuis un autre thread. Ou alternativement, si tu optes pour une écriture XML, de générer un MemoryStream depuis le thread UI si c'est très rapide et de seulement déférer l'écriture sur le disque de ce MemoryStream sur un autre thread.

    * Met en place une minuterie pour ne pas écrire plus d'une fois toutes les N secondes, ce qui ferait travailler inutilement l'ordinateur et userait le disque prématurément. Typiquement expose une méthode "InvalidateData" qui décidera d'écrire immédiatement ou d'attendre. Expose également une méthode "SaveImmediately" pour la fermeture de l'application.

    * Question détails, ThreadPool et ThreadPoolTimer feront très bien l'affaire.

  3. #3
    Membre éprouvé
    Avatar de dkmix
    Profil pro
    Inscrit en
    septembre 2007
    Messages
    619
    Détails du profil
    Informations personnelles :
    Localisation : Jamaïque

    Informations forums :
    Inscription : septembre 2007
    Messages : 619
    Points : 924
    Points
    924
    Par défaut
    DonQuiche, merci pour la réponse

    Un simple arbre XML (automatiquement écrit via XmlSerializer) ne ferait-il pas l'affaire ? Ton graphe d'objets est-il réductible à un arbre ? Peux-tu tout réécrire à chaque fois ?
    Le graphe d'objet est réductible à un arbre. Actuellement le chargement s'effectue à partir de fichiers json (un fichier de structure, et un fichier de données).
    Par contre, je travaille avec une notion de "contexte", chaque contexte est identique, hormis le paramétrage, les clients connectés et les données.
    Je peux utiliser un fichier de structure et un fichier données par contexte, par contre je me demande comment anticiper la montée en charge ?
    Mettons par exemple 500 contextes; chaque contexte contient 500 à 5000 objets (avec moins de 10 propriétés).
    Est-ce toujours viable ?

    Je te conseille de créer sur le thread UI une copie des données à écrire, puis d'écrire cette copie depuis un autre thread.
    Pas sur de comprendre ?

    si tu optes pour une écriture XML, de générer un MemoryStream depuis le thread UI si c'est très rapide et de seulement déférer l'écriture sur le disque de ce MemoryStream sur un autre thread.
    Intéressant, si j'opte pour une écriture de fichier j’essaierai de mettre en place ce pattern.

    Met en place une minuterie pour ne pas écrire plus d'une fois toutes les N secondes, ce qui ferait travailler inutilement l'ordinateur et userait le disque prématurément. Typiquement expose une méthode "InvalidateData" qui décidera d'écrire immédiatement ou d'attendre. Expose également une méthode "SaveImmediately" pour la fermeture de l'application.
    Dans le cas ou j'écris tout, ça me va. Après tout dépends du premier point.

  4. #4
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    En fait je dois m'excuser, je n'avais pas vu que c'était pour un serveur. Ça change pas mal la donne :

    * L'avantage de la sérialisation XML était de simplifier le code en vous évitant toute la plomberie avec la DB à chaque modification de l'état. Mais dans la mesure où vous êtes de toute façon obligés de mettre en place une plomberie pour gérer la concurrence sur ces écritures, cet avantage tend à disparaître et autant utiliser le système de transactions de la DB. Qui plus est celle-ci offrira déjà les autres services dont vous avez besoin : durabilité (il aurait fallu sauvegarder les fichiers à chaque écriture ou créer un log), temporisation des écritures, etc.

    * Les volumes sont tout de suite plus imposants. Avec la sérialisation XML automatique on se limite à quelques Mo par seconde dans mes souvenirs (ça date : on doit faire dix fois mieux aujourd'hui). On peut aller bien plus loin avec une sérialisation à la main, surtout s'il y a du SSD derrière, mais puisque le but était la simplicité ce n'est pas l'idéal. Vous pourriez toujours mettre en oeuvre une sauvegarde incrémentale mais là aussi à quoi bon : une DB semble plus simple.

    * Avec une appli cliente desktop le temps de chargement primait sur le temps d'écriture. Avec un serveur c'est plutôt l'inverse.


    Du coup, bof, un bon vieux SQL. En l'absence d'un problème de perfs, je ne vois pas trop l’intérêt de faire du NoSQL : s'il y a des avantages ils seront minces et vous amputeriez votre portabilité, vous pénaliseriez vos futurs mainteneurs et recrutements, et vous devrez faire une croix sur les riches outils disponibles pour des solutions éprouvées. D'où la multiplication d'objets immutables dans un peu toutes les API.



    PS : pour ta seconde question, si par exemple tu as une liste de clients, un motif fréquent est de cloner la liste et les clients de façon à avoir deux jeux de données distincts - un par thread. Ainsi le premier thread peut modifier sa liste pendant que l'autre lit la sienne et l'écrit sur un fichier, sans risque de conflit. Dupliquer les données est un moyen commode d'éviter d'avoir à mettre en oeuvre des mécanismes de synchronisation.

Discussions similaires

  1. PL/SQL - Cuseur / Persistance des données
    Par greg75 dans le forum PL/SQL
    Réponses: 0
    Dernier message: 20/08/2007, 15h52
  2. Persistance des données
    Par gdnico dans le forum Général Dotnet
    Réponses: 2
    Dernier message: 16/05/2007, 18h31
  3. Réponses: 2
    Dernier message: 19/04/2007, 17h59
  4. Persistance des données en mémoire
    Par giviz dans le forum Architecture
    Réponses: 13
    Dernier message: 21/12/2004, 10h44
  5. [Strategie]persistance des données
    Par altropus dans le forum Persistance des données
    Réponses: 6
    Dernier message: 04/11/2004, 05h36

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