In house simple synchronisation des données

Question

Je sais que le poste est long mais il contient également des solutions suggérées à mon problème. Par conséquent, la question elle-même n'est pas si longue ... n'ayez pas peur. :)

S'il vous plaît aidez-moi avec le scénario suivant:

je vais avoir un serveur SQL où je vais stocker des ensembles de données. Je vais aussi avoir un tas de clients PC (tous avec leur propre serveur SQL local) qui devront être synchronisés avec le serveur. Les PJ seront identifiés de manière unique.

Exemple:

Disons que j'ai 2 clients PC, PC1 et PC2.

Sur le serveur, je les ensembles de données suivants:

DS1 DS2

Sur les PC clients, je ne rien avoir à commencer. Lorsque PC1 se connectera au serveur pour voir si "quelque chose est nouveau", il remarquera qu'il y a deux jeux de données qu'il doit récupérer afin de mettre à jour sa base de données locale avec DS1 et DS2. La même chose se produira avec PC2. Maintenant, disons que PC2, localement, modifie DS2. Lorsque PC2 se connectera au serveur, il mettra à jour DS2 sur le serveur avec les modifications apportées à son DS2 local. Enfin, lorsque PC1 se connectera à nouveau pour voir s'il y a des changements, il remarquera que DS2 a changé et il va le récupérer et écraser son DS2 local avec le DS2 du serveur.

Ne vous inquiétez pas des problèmes de simultanéité car tous les PC ne peuvent pas modifier un ensemble de données. Seul le propriétaire d'un certain ensemble de données peut le modifier (le propriétaire étant défini comme un seul PC).

J'ai pensé à quelques solutions mais elles ne semblent pas très efficaces; peut-être que quelqu'un d'autre aura quelques idées.

1ère solution:

Sur le serveur, je vais créer une table appelée « SyncTable » où je vais écrire toute modification des ensembles de données.

Exemple:

Disons que PC1 a besoin de récupérer DS1 et PC2 a besoin de récupérer DS4 et DS5.

Le tableau de synchronisation contiendra:

PC1 DS1
PC2 DS4
PC2 DS5

Ainsi, lorsque PC2 se connecte au serveur, il regarde ce tableau, note qu'il doit télécharger DS4 et DS5, va de l'avant et fait cela, puis il supprime ses deux entrées de la table du serveur. Ainsi, la table du serveur ne contiendrait que "PC1 DS1" après que PC2 se soit synchronisé. La prochaine fois, quand PC2 se connecte, note qu'il n'y a pas d'entrées et sait donc que c'est "à jour". Lorsque PC1 se connecterait, la même chose se produirait exactement: il devrait noter qu'il doit télécharger DS1, le télécharger et ensuite supprimer l'entrée.

Le problème avec ceci est que s'il y a 10 000 PC, et peut-être 5000 jeux de données modifiés, j'aurais beaucoup d'entrées dans cette table.

La deuxième solution consisterait à stocker un horodatage modifié associé à chaque ensemble de données.Le problème avec ceci est que les PC clients devraient passer par TOUS leurs enregistrements locaux et comparer les horodateurs locaux avec le dernier horodatage sur le serveur pour voir s'il y a des changements. Je ne sais pas à quel point cela est efficace compte tenu d'un grand nombre d'enregistrements. Il semble qu'il serait préférable qu'ils sachent directement où chercher des changements plutôt que de parcourir tous les dossiers à chaque fois ...

Par conséquent, avez-vous des suggestions à ce sujet?

Technologie utilisée: MS SQL Server Compact Edition 3.5 sur les PC clients et MySQL sur le serveur. La communication se ferait via des services Web. Par conséquent, la réplication de fusion/l'accès aux données à distance sont désactivés.

Merci!

Answer 1

Vous envisagez deux options

1. générer une liste des mises à jour nécessaires au moment de la modification, le client demande « ce qui est dans ma liste des mises à jour »?
2. en conservant les horodatages de manière à ce qu'un client puisse demander "Ma dernière heure pour DSx est ..., ai-je besoin d'une mise à jour?"

Je vois l'option 2 comme préférable. Je pense qu'il est plus résilient aux problèmes, à la récupération des plantages de clients etc. C'est parce que chaque participant ne garde que ce qu'il sait: la date de ses données. Le serveur n'a pas besoin de "comprendre" qui a pris quoi.

Je pense que vous pouvez optimiser la détermination de ce qu'il faut télécharger. Vous parlez comme si le client avait besoin de parcourir tous ses ensembles de données, en récupérant chaque fois un tampon à la fois et en décidant de le récupérer. Au lieu de cela, vous pouvez avoir un appel de service Web:

I have DS1=<time>, DS2=<time> ...; which do I need to download? 

La décision réelle est faite par le serveur sur la base des données envoyées par le client, plutôt que le client l'extraction de données pour lui permettre de prendre la décision elle-même.

En passant, je tiens à souligner qu'il existe des produits commerciaux que de gérer tout cela. Avez-vous vraiment besoin de le coder?