Παρακολουθώντας την ανάπτυξη εταιρικού λογισμικού από την πρώτη σειρά για δύο δεκαετίες, είναι ξεκάθαρη η αναμφισβήτητη τάση των τελευταίων ετών – η μεταφορά βάσεων δεδομένων στο cloud.
Είχα ήδη συμμετάσχει σε μερικά έργα μετάβασης, όπου ο στόχος ήταν να φέρω την υπάρχουσα βάση δεδομένων εσωτερικής εγκατάστασης στη βάση δεδομένων Cloud των Υπηρεσιών Ιστού του Amazon (AWS). Ενώ από τα υλικά τεκμηρίωσης του AWS, θα μάθετε πόσο εύκολο μπορεί να είναι αυτό, είμαι εδώ για να σας πω ότι η εκτέλεση ενός τέτοιου σχεδίου δεν είναι πάντα εύκολη και υπάρχουν περιπτώσεις όπου μπορεί να αποτύχει.
Σε αυτήν την ανάρτηση, θα καλύψω την εμπειρία του πραγματικού κόσμου για την ακόλουθη περίπτωση:
- Η πηγή: Ενώ θεωρητικά, δεν έχει σημασία ποια είναι η πηγή σας (μπορείτε να χρησιμοποιήσετε μια πολύ παρόμοια προσέγγιση για την πλειονότητα των πιο δημοφιλών DB), η Oracle ήταν το σύστημα βάσης δεδομένων της επιλογής σε μεγάλες εταιρικές εταιρείες για πολλά χρόνια, και εκεί θα είναι η εστίασή μου.
- Ο στόχος: Δεν υπάρχει λόγος να είμαι συγκεκριμένος σε αυτήν την πλευρά. Μπορείτε να επιλέξετε οποιαδήποτε βάση δεδομένων στόχου στο AWS και η προσέγγιση θα εξακολουθεί να ταιριάζει.
- Λειτουργία: Μπορείτε να έχετε πλήρη ανανέωση ή σταδιακή ανανέωση. Φόρτωση δεδομένων παρτίδας (οι καταστάσεις πηγής και στόχου καθυστερούν) ή (σχεδόν) φόρτωση δεδομένων σε πραγματικό χρόνο. Και τα δύο θα θιγούν εδώ.
- Η Συχνότητα: Μπορεί να θέλετε εφάπαξ μετεγκατάσταση ακολουθούμενη από πλήρη μετάβαση στο cloud ή να χρειάζεστε κάποια μεταβατική περίοδο και να έχετε τα δεδομένα ενημερωμένα και στις δύο πλευρές ταυτόχρονα, κάτι που συνεπάγεται την ανάπτυξη καθημερινού συγχρονισμού μεταξύ εσωτερικής εγκατάστασης και AWS. Το πρώτο είναι πιο απλό και έχει πολύ πιο νόημα, αλλά το δεύτερο ζητείται πιο συχνά και έχει πολύ περισσότερα σημεία διακοπής. Θα καλύψω και τα δύο εδώ.
Πίνακας περιεχομένων
Περιγραφή Προβλήματος
Η απαίτηση είναι συχνά απλή:
Θέλουμε να ξεκινήσουμε την ανάπτυξη υπηρεσιών μέσα στο AWS, επομένως αντιγράψτε όλα τα δεδομένα μας στη βάση δεδομένων “ABC”. Γρήγορα και απλά. Πρέπει να χρησιμοποιήσουμε τα δεδομένα μέσα στο AWS τώρα. Αργότερα, θα καταλάβουμε ποια μέρη των σχεδίων DB πρέπει να αλλάξουμε ώστε να ταιριάζουν με τις δραστηριότητές μας.
Πριν προχωρήσετε περαιτέρω, πρέπει να λάβετε υπόψη κάτι:
- Μην πηδήξετε στην ιδέα «απλώς να αντιγράψετε αυτό που έχουμε και να το αντιμετωπίσετε αργότερα» πολύ γρήγορα. Εννοώ, ναι, αυτό είναι το πιο εύκολο που μπορείτε να κάνετε, και θα γίνει γρήγορα, αλλά αυτό έχει τη δυνατότητα να δημιουργήσει ένα τόσο θεμελιώδες αρχιτεκτονικό πρόβλημα που θα είναι αδύνατο να επιλυθεί αργότερα χωρίς σοβαρή ανακατασκευή της πλειοψηφίας της νέας πλατφόρμας cloud . Απλώς φανταστείτε ότι το οικοσύστημα cloud είναι εντελώς διαφορετικό από το επί τόπου. Αρκετές νέες υπηρεσίες θα εισαχθούν με την πάροδο του χρόνου. Φυσικά, οι άνθρωποι θα αρχίσουν να χρησιμοποιούν το ίδιο πολύ διαφορετικά. Δεν είναι σχεδόν ποτέ καλή ιδέα να αναπαράγετε την κατάσταση εσωτερικής εγκατάστασης στο cloud με τρόπο 1:1. Μπορεί να είναι στη δική σας περίπτωση, αλλά φροντίστε να το ελέγξετε ξανά.
- Αμφισβητήστε την απαίτηση με ορισμένες ουσιαστικές αμφιβολίες όπως:
- Ποιος θα είναι ο τυπικός χρήστης που θα χρησιμοποιεί τη νέα πλατφόρμα; Ενώ είναι on-premise, μπορεί να είναι συναλλακτικός επιχειρηματικός χρήστης. στο cloud, μπορεί να είναι ένας επιστήμονας δεδομένων ή ένας αναλυτής αποθήκης δεδομένων ή ο κύριος χρήστης των δεδομένων μπορεί να είναι μια υπηρεσία (π.χ. Databricks, Glue, μοντέλα μηχανικής εκμάθησης κ.λπ.).
- Οι κανονικές καθημερινές εργασίες αναμένεται να παραμείνουν ακόμα και μετά τη μετάβαση στο cloud; Εάν όχι, πώς αναμένεται να αλλάξουν;
- Σχεδιάζετε σημαντική αύξηση των δεδομένων με την πάροδο του χρόνου; Πιθανότατα, η απάντηση είναι ναι, καθώς αυτός είναι συχνά ο πιο σημαντικός λόγος για να μεταναστεύσετε στο cloud. Ένα νέο μοντέλο δεδομένων θα είναι έτοιμο για αυτό.
- Αναμένετε από τον τελικό χρήστη να σκεφτεί κάποια γενικά, αναμενόμενα ερωτήματα που θα λάβει η νέα βάση δεδομένων από τους χρήστες. Αυτό θα καθορίσει πόσο θα αλλάξει το υπάρχον μοντέλο δεδομένων για να παραμείνει σχετικό με την απόδοση.
Ρύθμιση της μετανάστευσης
Μόλις επιλεγεί η βάση δεδομένων στόχος και συζητηθεί ικανοποιητικά το μοντέλο δεδομένων, το επόμενο βήμα είναι να εξοικειωθείτε με το Εργαλείο μετατροπής σχήματος AWS. Υπάρχουν αρκετοί τομείς στους οποίους μπορεί να εξυπηρετήσει αυτό το εργαλείο:
Παραπομπή: Τεκμηρίωση AWS
Τώρα υπάρχουν μερικές συμβουλές για τη χρήση του Εργαλείου μετατροπής σχήματος.
Πρώτον, δεν θα έπρεπε σχεδόν ποτέ να χρησιμοποιείται απευθείας η έξοδος. Θα το θεωρούσα περισσότερο σαν αποτελέσματα αναφοράς, από όπου θα κάνετε τις προσαρμογές σας με βάση την κατανόηση και τον σκοπό των δεδομένων και τον τρόπο με τον οποίο θα χρησιμοποιηθούν τα δεδομένα στο cloud.
Δεύτερον, νωρίτερα, οι πίνακες πιθανώς επιλέχθηκαν από χρήστες που περίμεναν γρήγορα σύντομα αποτελέσματα σχετικά με κάποια συγκεκριμένη οντότητα τομέα δεδομένων. Αλλά τώρα, τα δεδομένα ενδέχεται να επιλέγονται για αναλυτικούς σκοπούς. Για παράδειγμα, τα ευρετήρια βάσεων δεδομένων που λειτουργούσαν προηγουμένως στη βάση δεδομένων εσωτερικής εγκατάστασης θα είναι πλέον άχρηστα και σίγουρα δεν θα βελτιώσουν την απόδοση του συστήματος DB που σχετίζεται με αυτήν τη νέα χρήση. Ομοίως, μπορεί να θέλετε να χωρίσετε τα δεδομένα διαφορετικά στο σύστημα προορισμού, όπως ήταν πριν στο σύστημα προέλευσης.
Επίσης, ίσως είναι καλό να εξετάσετε το ενδεχόμενο να κάνετε μερικούς μετασχηματισμούς δεδομένων κατά τη διαδικασία μετεγκατάστασης, κάτι που ουσιαστικά σημαίνει αλλαγή του μοντέλου δεδομένων στόχου για ορισμένους πίνακες (ώστε να μην είναι πλέον αντίγραφα 1:1). Αργότερα, οι κανόνες μετασχηματισμού θα πρέπει να εφαρμοστούν στο εργαλείο μετεγκατάστασης.
Εάν οι βάσεις δεδομένων προέλευσης και προορισμού είναι του ίδιου τύπου (π.χ. Oracle on-premise έναντι Oracle στο AWS, PostgreSQL έναντι Aurora Postgresql, κ.λπ.), τότε είναι καλύτερο να χρησιμοποιήσετε ένα αποκλειστικό εργαλείο μετεγκατάστασης που υποστηρίζει εγγενώς συγκεκριμένη βάση δεδομένων ( π.χ. εξαγωγές και εισαγωγές αντλιών δεδομένων, Oracle Goldengate, κ.λπ.).
Ωστόσο, στις περισσότερες περιπτώσεις, η βάση δεδομένων προέλευσης και προορισμού δεν θα είναι συμβατές και τότε το προφανές εργαλείο επιλογής θα είναι η υπηρεσία μετεγκατάστασης βάσεων δεδομένων AWS.
Παραπομπή: Τεκμηρίωση AWS
Το AWS DMS επιτρέπει βασικά τη διαμόρφωση μιας λίστας εργασιών σε επίπεδο πίνακα, η οποία θα ορίζει:
- Ποια είναι η ακριβής πηγή DB και πίνακας για σύνδεση;
- Προδιαγραφές δήλωσης που θα χρησιμοποιηθούν για τη λήψη των δεδομένων για τον πίνακα προορισμού.
- Εργαλεία μετασχηματισμού (εάν υπάρχουν), που καθορίζουν τον τρόπο με τον οποίο τα δεδομένα προέλευσης θα αντιστοιχιστούν σε δεδομένα πίνακα στόχου (αν όχι 1:1).
- Ποια είναι η ακριβής βάση δεδομένων στόχος και ο πίνακας για τη φόρτωση των δεδομένων;
Η διαμόρφωση εργασιών DMS γίνεται σε κάποια φιλική προς το χρήστη μορφή όπως το JSON.
Τώρα στο απλούστερο σενάριο, το μόνο που χρειάζεται να κάνετε είναι να εκτελέσετε τα σενάρια ανάπτυξης στη βάση δεδομένων προορισμού και να ξεκινήσετε την εργασία DMS. Αλλά υπάρχουν πολύ περισσότερα σε αυτό.
Εφάπαξ πλήρης μετεγκατάσταση δεδομένων
Η πιο εύκολη περίπτωση να εκτελεστεί είναι όταν το αίτημα είναι να μετακινήσετε ολόκληρη τη βάση δεδομένων μία φορά στη βάση δεδομένων του cloud στόχου. Στη συνέχεια, βασικά, το μόνο που χρειάζεται να κάνετε θα είναι το εξής:
Εάν η διαμόρφωση του DMS γίνει σωστά, δεν θα συμβεί τίποτα κακό σε αυτό το σενάριο. Κάθε πίνακας προέλευσης θα παραληφθεί και θα αντιγραφεί στη βάση δεδομένων στόχου AWS. Οι μόνες ανησυχίες θα είναι η απόδοση της δραστηριότητας και η διασφάλιση του κατάλληλου μεγέθους σε κάθε βήμα, ώστε να μην αποτύχει λόγω ανεπαρκούς αποθηκευτικού χώρου.
Αυξητικός ημερήσιος συγχρονισμός
Εδώ είναι που τα πράγματα αρχίζουν να περιπλέκονται. Θέλω να πω, αν ο κόσμος θα ήταν ιδανικός, τότε μάλλον θα λειτουργούσε μια χαρά όλη την ώρα. Όμως ο κόσμος δεν είναι ποτέ ιδανικός.
Το DMS μπορεί να ρυθμιστεί ώστε να λειτουργεί σε δύο λειτουργίες:
- Πλήρες φορτίο – η προεπιλεγμένη λειτουργία που περιγράφεται και χρησιμοποιείται παραπάνω. Οι εργασίες DMS ξεκινούν είτε όταν τις ξεκινάτε είτε όταν είναι προγραμματισμένη να ξεκινήσουν. Μόλις ολοκληρωθούν, οι εργασίες DMS έχουν ολοκληρωθεί.
- Αλλαγή λήψης δεδομένων (CDC) – σε αυτήν τη λειτουργία, η εργασία DMS εκτελείται συνεχώς. Το DMS σαρώνει τη βάση δεδομένων προέλευσης για μια αλλαγή σε επίπεδο πίνακα. Εάν συμβεί η αλλαγή, προσπαθεί αμέσως να αναπαραγάγει την αλλαγή στη βάση δεδομένων προορισμού με βάση τη διαμόρφωση εντός της εργασίας DMS που σχετίζεται με τον αλλαγμένο πίνακα.
Όταν πηγαίνετε για CDC, πρέπει να κάνετε μια ακόμη επιλογή – δηλαδή, πώς το CDC θα εξαγάγει τις αλλαγές δέλτα από το DB πηγής.
#1. Oracle Redo Logs Reader
Μια επιλογή είναι να επιλέξετε τον εγγενή αναγνώστη αρχείων καταγραφής επανάληψης της βάσης δεδομένων από την Oracle, τον οποίο το CDC μπορεί να χρησιμοποιήσει για να λάβει τα αλλαγμένα δεδομένα και, με βάση τις τελευταίες αλλαγές, να αναπαράγει τις ίδιες αλλαγές στη βάση δεδομένων προορισμού.
Αν και αυτό μπορεί να φαίνεται σαν μια προφανής επιλογή εάν ασχολείστε με την Oracle ως πηγή, υπάρχει μια σύλληψη: ο αναγνώστης αρχείων καταγραφής επανάληψης της Oracle χρησιμοποιεί το πηγαίο σύμπλεγμα Oracle και έτσι επηρεάζει άμεσα όλες τις άλλες δραστηριότητες που εκτελούνται στη βάση δεδομένων (στην πραγματικότητα δημιουργεί απευθείας ενεργές περιόδους σύνδεσης στο τη βάση δεδομένων).
Όσο περισσότερες εργασίες DMS έχετε διαμορφώσει (ή περισσότερα συμπλέγματα DMS παράλληλα), τόσο περισσότερο πιθανότατα θα χρειαστεί να αναβαθμίσετε το σύμπλεγμα Oracle – βασικά, προσαρμόστε την κατακόρυφη κλιμάκωση του πρωτεύοντος συμπλέγματος βάσεων δεδομένων Oracle. Αυτό σίγουρα θα επηρεάσει το συνολικό κόστος της λύσης, ακόμη περισσότερο εάν ο ημερήσιος συγχρονισμός πρόκειται να παραμείνει στο έργο για μεγάλο χρονικό διάστημα.
#2. AWS DMS Log Miner
Σε αντίθεση με την παραπάνω επιλογή, αυτή είναι μια εγγενής λύση AWS για το ίδιο πρόβλημα. Σε αυτήν την περίπτωση, το DMS δεν επηρεάζει την πηγή Oracle DB. Αντίθετα, αντιγράφει τα αρχεία καταγραφής επανάληψης της Oracle στο σύμπλεγμα DMS και κάνει όλη την επεξεργασία εκεί. Ενώ εξοικονομεί πόρους της Oracle, είναι η πιο αργή λύση, καθώς εμπλέκονται περισσότερες λειτουργίες. Και επίσης, όπως μπορεί εύκολα να υποθέσει κανείς, ο προσαρμοσμένος αναγνώστης για τα αρχεία καταγραφής επανάληψης της Oracle είναι πιθανώς πιο αργός στη δουλειά του ως εγγενής αναγνώστης από την Oracle.
Ανάλογα με το μέγεθος της βάσης δεδομένων πηγής και τον αριθμό των ημερήσιων αλλαγών εκεί, στην καλύτερη περίπτωση, μπορεί να καταλήξετε σε σχεδόν σε πραγματικό χρόνο αυξητικό συγχρονισμό των δεδομένων από την εσωτερική βάση δεδομένων Oracle στη βάση δεδομένων cloud AWS.
Σε οποιοδήποτε άλλο σενάριο, εξακολουθεί να μην είναι σχεδόν ο συγχρονισμός σε πραγματικό χρόνο, αλλά μπορείτε να προσπαθήσετε να πλησιάσετε όσο το δυνατόν πιο κοντά στην αποδεκτή καθυστέρηση (μεταξύ πηγής και στόχου) ρυθμίζοντας τη διαμόρφωση απόδοσης και τον παραλληλισμό των συμπλεγμάτων πηγής και στόχου ή πειραματίζοντας με ο αριθμός των εργασιών DMS και η κατανομή τους μεταξύ των παρουσιών του CDC.
Και ίσως θέλετε να μάθετε ποιες αλλαγές στον πίνακα προέλευσης υποστηρίζονται από το CDC (όπως η προσθήκη μιας στήλης, για παράδειγμα), επειδή δεν υποστηρίζονται όλες οι πιθανές αλλαγές. Σε ορισμένες περιπτώσεις, ο μόνος τρόπος είναι να αλλάξετε τον πίνακα προορισμού με μη αυτόματο τρόπο και να επανεκκινήσετε την εργασία CDC από την αρχή (χάνοντας στην πορεία όλα τα υπάρχοντα δεδομένα στη βάση δεδομένων προορισμού).
Όταν τα πράγματα πάνε στραβά, ανεξάρτητα από το τι
Το έμαθα με τον δύσκολο τρόπο, αλλά υπάρχει ένα συγκεκριμένο σενάριο που συνδέεται με το DMS όπου η υπόσχεση της καθημερινής αναπαραγωγής είναι δύσκολο να επιτευχθεί.
Το DMS μπορεί να επεξεργαστεί τα αρχεία καταγραφής επανάληψης μόνο με κάποια καθορισμένη ταχύτητα. Δεν έχει σημασία αν υπάρχουν περισσότερες περιπτώσεις DMS που εκτελούν τις εργασίες σας. Ωστόσο, κάθε στιγμιότυπο DMS διαβάζει τα αρχεία καταγραφής επανάληψης μόνο με μία μόνο καθορισμένη ταχύτητα και κάθε ένα από αυτά πρέπει να τα διαβάσει ολόκληρα. Δεν έχει σημασία ακόμη και αν χρησιμοποιείτε αρχεία καταγραφής επανάληψης Oracle ή AWS log miner. Και τα δύο έχουν αυτό το όριο.
Εάν η βάση δεδομένων προέλευσης περιλαμβάνει μεγάλο αριθμό αλλαγών μέσα σε μια μέρα που τα αρχεία καταγραφής επανάληψης της Oracle γίνονται πολύ μεγάλα (όπως 500 GB+) κάθε μέρα, το CDC απλά δεν πρόκειται να λειτουργήσει. Η αναπαραγωγή δεν θα ολοκληρωθεί πριν από το τέλος της ημέρας. Θα φέρει κάποιες μη επεξεργασμένες εργασίες στην επόμενη μέρα, όπου περιμένει ήδη ένα νέο σύνολο αλλαγών που πρέπει να αναπαραχθούν. Ο όγκος των μη επεξεργασμένων δεδομένων θα αυξάνεται μόνο από μέρα σε μέρα.
Στη συγκεκριμένη περίπτωση, το CDC δεν ήταν επιλογή (μετά από πολλές δοκιμές απόδοσης και προσπάθειες που εκτελέσαμε). Ο μόνος τρόπος για να διασφαλίσετε ότι τουλάχιστον όλες οι αλλαγές δέλτα από την τρέχουσα ημέρα θα επαναληφθούν την ίδια ημέρα ήταν να το προσεγγίσετε ως εξής:
- Διαχωρίστε πραγματικά μεγάλα τραπέζια που δεν χρησιμοποιούνται τόσο συχνά και επαναλάβετε τα μόνο μία φορά την εβδομάδα (π.χ. τα Σαββατοκύριακα).
- Ρυθμίστε την αναπαραγωγή όχι και τόσο μεγάλων, αλλά ακόμα μεγάλων πινάκων για διαχωρισμό μεταξύ πολλών εργασιών DMS. Ένας πίνακας τελικά μετεγκαταστάθηκε από 10 ή περισσότερες ξεχωριστές εργασίες DMS παράλληλα, διασφαλίζοντας ότι ο διαχωρισμός δεδομένων μεταξύ των εργασιών DMS είναι διακριτός (εδώ εμπλέκεται η προσαρμοσμένη κωδικοποίηση) και να εκτελούνται καθημερινά.
- Προσθέστε περισσότερες (έως 4 σε αυτήν την περίπτωση) περιπτώσεις DMS και διαχωρίστε τις εργασίες DMS μεταξύ τους ομοιόμορφα, πράγμα που σημαίνει όχι μόνο από τον αριθμό των πινάκων αλλά και από το μέγεθος.
Βασικά, χρησιμοποιήσαμε τη λειτουργία πλήρους φόρτωσης του DMS για την αναπαραγωγή ημερήσιων δεδομένων, επειδή αυτός ήταν ο μόνος τρόπος για να επιτύχουμε τουλάχιστον την ολοκλήρωση της αναπαραγωγής δεδομένων την ίδια ημέρα.
Δεν είναι τέλεια λύση, αλλά εξακολουθεί να υπάρχει, και ακόμη και μετά από πολλά χρόνια, εξακολουθεί να λειτουργεί με τον ίδιο τρόπο. Οπότε, ίσως όχι και τόσο κακή λύση τελικά. 😃