bluemind

Πρόσφατα χρειάστηκε να ξαναθυμηθώ το Sync Framework προκειμένου να το παρουσιάσω σε ένα τμήμα από developers, και αναρωτήθηκα τι πρόοδος να έχει γίνει στο πολύ κρίσιμο θέμα της ταχύτητας.

Πριν προχωρήσω στη σύγκριση που έκανα, αξίζει να αναφέρω πρώτα ότι πριν από 2 χρόνια περίπου (καλοκαίρι 2009) είχε προκύψει η ανάγκη σε ένα συνεργάτη να κρατά τα δεδομένα μίας κεντρικής SQL Server βάσης συγχρονισμένα με αυτά που υπήρχαν σε client εφαρμογή που είχε φτιάξει για το Windows Mobile 6.5 (με πολλούς SQL Server Compact Edition, δηλαδή). Βρέθηκε, λοιπόν, στο δίλημμα αν έπρεπε να επιλέξει το Merge Replication, που ήταν από παλιά διαθέσιμο για συγχρονισμό μεταξύ βάσεων SQL Server, ή μια νέα (σχετικά) τεχνολογία ονόματι Sync Framework. Υπήρχαν πολλοί παράγοντες που ενδεχομένως θα έπαιζαν ρόλο στην επιλογή, αλλά επειδή στα κινητά οι χρεώσεις για data επικοινωνία γενικά “τσακίζουν”, η ταχύτητα συγχρονισμού θα ήταν ο αποφασιστικός παράγον. Έκανε, λοιπόν δοκιμές και μου έστειλε τα αποτελέσματα, τα οποία παραθέτω εδώ:

Αν και δεν μπορώ να είμαι σίγουρος πως έγινε το test, έχω εμπιστοσύνη ότι ήταν “δίκαιο” και προς τις δύο τεχνολογίες. Είναι, νομίζω, πασιφανές ότι υπήρχε ολόκληρο χάσμα μεταξύ των δύο, με αποτέλεσμα ο συνεργάτης να διαλέξει το Merge. Τελικά, μάλιστα, ούτε αυτό τον βόλεψε (είναι ελάχιστα ευέλικτο όταν το προσεγγίζεις από προγραμματιστικής σκοπιάς – αυτός είναι και ένας από τους λόγους που δημιουργήθηκε το Sync Framework ως εναλλακτική), οπότε κατέληξε να κάνει κάτι custom δικό του.

Έτσι αναρωτήθηκα αν έγινε πρόοδος με τις καινούργιες εκδόσεις του Sync Framework (επί του παρόντος είμαστε στην 2.1 και έχει βγει σε CTP η 4.0). Έπιασα, λοιπόν, να γράψω λίγο κώδικα ώστε να ελέγξω που είμαστε. Έκανα sync και merge από SQL Server σε SQL Server Express, και για να έχω πλήρη εικόνα έκανα και Sync από SQL Server σε SQL Server CE. Όλοι οι servers και ο κώδικας που έτρεξε ήταν στο ίδιο μηχάνημα. Η κατεύθυνση συγχρονισμού ήταν αμφίδρομη (δηλαδή για το Sync είχαμε και download και upload, ενώ για το Merge είχαμε.. merge και όχι one-way transactional replication). Τέλος, να αναφέρω ότι η επεξεργασία του συγχρονισμού καθορίστηκε να γίνεται στον server, αν και επειδή όλα ήταν στο ίδιο μηχάνημα, δεν θεωρώ ότι έπαιξε ρόλο.

Τα αποτελέσματα:

Είναι ξεκάθαρο ότι τα πράγματα έχουν βελτιωθεί κατά πολύ για το Sync Framework. Το αξιοσημείωτο είναι ότι όσες δοκιμές και αν έκανα ο συγχρονισμός με Sync Framework από SQL σε SQL CE έβγαινε πάντα ταχύτερος από τα υπόλοιπα είδη, κάτι που ομολογώ δεν περίμενα, μια και θεωρούσα ότι ο SQL που “κρατάει” πολλά πράγματα στη μνήμη θα ήταν ταχύτερος από τον SQL CE που τα έχει όλα σε ένα αρχείο στο δίσκο. Η απλότητα, όμως, φαίνεται ότι κέρδισε τελικά.

Να σημειώσω ότι και στις δύο περιπτώσεις, το setup που έτρεχα για να θέσω τις παραμέτρους του συγχρονισμού δεν ήταν πάνω από μερικά δευτερόλεπτα. Βέβαια, τα βήματα στην περίπτωση του Merge ήταν τα διπλάσια από αυτά του Sync και ο κώδικας σημαντικά περισσότερος. Τον κώδικα και τα db scripts που χρησιμοποίησα τα έχω επισυνάψει πιο κάτω, αν θέλει κάποιος να επαναλάβει τις δοκιμές ή και να δοκιμάσει άλλες παραλλαγές (π.χ. τι αποτελέσματα έχουμε αν έχουμε τους servers σε διαφορετικά μηχανήματα, ή κάνουμε και upload δεδομένα από τον client). Αν κάνετε δοκιμές ενδιαφέρομαι πολύ να ακούσω από εσάς πως πήγαν.

Τέλος, σε περίπτωση που αναρωτιέστε τι άλλοι παράγοντες υπάρχουν που θα πρέπει να σκεφτείτε πριν διαλέξετε μία από τις δύο τεχνολογίες για συγχρονισμό, τότε προτείνω να διαβάσετε το συγκεκριμένο άρθρο στο MSDN: How to Choose a Data Synchronization Technology – Offline & Collaboration. Θα δείτε ότι η ευελιξία που χαρίζει το Sync Framework σε συνδυασμό με τις λιγότερες γραμμές κώδικα που χρειάζεται συγκριτικά με το Merge Replication, το τοποθετεί σίγουρα μπροστά.