Discussion :

[dkmix]

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

[DonQuiche]

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.

[dkmix]

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.

[DonQuiche]

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.