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, το τοποθετεί σίγουρα μπροστά.

Δεν ξέρω πόσοι το αντελήφθησαν, αλλά την προηγούμενη εβδομάδα βγήκε ανακοίνωση από τη Microsoft (και πιο συγκεκριμένα από την ομάδα του SQL Native Client) που δήλωσε ότι η εταιρία αποφάσισε να επικεντρωθεί στην ODBC και σταδιακά να εγκαταλείψει την OLEDB. Αυτό αφορά σε πρώτη φάση τον SQL Native Client, αλλά λογικά θα επεκταθεί σύντομα και στα υπόλοιπα κομμάτια που βασίζονται στην OLEDB – μέχρι στιγμής καμία ανακοίνωση για αυτά.

Αν και ακούστηκαν μερικά παράπονα για αυτή τη στροφή, κυρίως από αυτούς που χρησιμοποιούν OLEDB επί του παρόντος, θεωρώ ότι η αλλαγή καλώς έγινε: η ODBC χρησιμοποιείται από όλες τις πλατφόρμες για επαφή με τον SQL Server και είναι ευρύτατα διαδεδομένη σε αντιδιαστολή με την OLEDB που χρησιμοποιείται μόνο από Windows. Οπότε δεν έχει νόημα για τη Microsoft να συντηρεί δύο τρόπους επαφής με τη βάση όταν κάνουν ουσιαστικά το ίδιο πράγμα, ειδικά μάλιστα με την έλευση του Cloud. Η μόνη ένσταση θα μπορούσε να είναι το performance, αλλά σύμφωνα με τα όσα λένε οι ειδικοί της Microsoft που το εξέτασαν, η ODBC υπερτερεί της OLEDB – αντίθετα με την κοινή πεποίθηση.

Περισσότερες λεπτομέρειες από την επίσημη ανακοίνωση μπορείτε να βρείτε και εδώ: http://social.technet.microsoft.com/Forums/en/sqldataaccess/thread/e696d0ac-f8e2-4b19-8a08-7a357d3d780f