Διαχωρισμός ανάγνωσης-εγγραφής
Όταν η επιχείρηση μιας εταιρείας συνεχίζει να επεκτείνεται και ο αριθμός των χρηστών αυξάνεται σημαντικά, η αρχική βάση δεδομένων είναι πιθανό να μην είναι σε θέση να διατηρηθεί. Τότε ναι
- Scale-in, το οποίο επεκτείνει την απόδοση του υλικού, αλλά είναι πιθανό ότι ο αριθμός των χρηστών θα συνεχίσει να αυξάνεται και η αυξημένη απόδοση σύντομα θα καταναλωθεί.
- Διαχωρισμός ανάγνωσης-εγγραφής: Η βάση δεδομένων δεν μπορεί να κρατηθεί, δεν είναι τίποτα άλλο από υπερβολική ανάγνωση και εγγραφή, ειδικά αν υπάρχουν κάποια πολύπλοκα ερωτήματα, όπως τα πιο δημοφιλή προϊόντα τις τελευταίες 24 ώρες. Απαιτεί πολύ περίπλοκες δηλώσεις SQL και φυσικά αργεί να εκτελεστεί.
Ωστόσο, για να διαχωριστούν οι αναγνώσεις και οι εγγραφές, η βάση δεδομένων πρέπει να χωριστεί σε κύριες και υποτελείς βιβλιοθήκες.
Οι κύριες σχεσιακές βάσεις δεδομένων στην αγορά υποστηρίζουν την αναπαραγωγή δεδομένων, ώστε να μπορείτε να χωρίσετε μια βάση δεδομένων σε δύο ρόλους: Master και Slave, να γράψετε λειτουργίες στον κύριο και να συγχρονίσετε τον κύριο διακομιστή με άλλους slave servers.
Οι λειτουργίες εκτός σύνδεσης, όπως οι λειτουργίες ανάγνωσης και η ανάλυση δεδομένων, εκτελούνται στον διακομιστή Slave.
Γνωρίζουμε ότι πολλές εφαρμογές στο Διαδίκτυο διαβάζονται, έτσι ώστε πολλοί slaves να μπορούν να μοιράζονται το φορτίο και να διασφαλίζουν τη διαθεσιμότητα και την ορθότητα των δεδομένων.
Ωστόσο, ο αντίστοιχος αρχικός κώδικας εφαρμογής πρέπει επίσης να τροποποιηθεί και πρέπει να αλλάξει για να χρησιμοποιηθεί η κύρια βιβλιοθήκη για την εγγραφή δεδομένων και να χρησιμοποιηθεί η υποτελής βιβλιοθήκη κατά την ανάγνωση δεδομένων, κάτι που ισοδυναμεί με επανεγγραφή.
Σύνθετα ερωτήματα
Ωστόσο, ακόμη και μετά την επανεγγραφή του κώδικα, διαπίστωσα ότι η απόδοση δεν βελτιώθηκε σημαντικά επειδή χρησιμοποιήθηκαν πάρα πολλά σύνθετα ερωτήματα και έχουμε πει στο στοιχείο της βάσης δεδομένων ότι οι ενώσεις είναι πολύ εντατικές στην απόδοση.
Μπορούμε λοιπόν να χρησιμοποιήσουμε έναν ξεχωριστό πίνακα για να αποθηκεύσουμε τα δημοφιλή προϊόντα των τελευταίων 24 ωρών, έτσι ώστε να χρειάζεται μόνο να χρησιμοποιήσουμε απλή SQL για να το κάνουμε.
Με άλλα λόγια, ένα μόνο σύνολο πινάκων βάσης δεδομένων είναι ακατάλληλο για διαφορετικές συμπεριφορές όπως αναφορές, αναζητήσεις, συναλλαγές κ.λπ.
Ο τρέχων πίνακας έχει σχεδιαστεί για την προσθήκη και την τροποποίηση δεδομένων και δεν είναι κατάλληλος για σύνθετα ερωτήματα.
Αλλά πρέπει επίσης να εξετάσουμε πώς ενημερώνεται αυτή η βάση ερωτημάτων ή αν μπορούμε να ανεχθούμε αυτήν την καθυστέρηση, αν μπορεί να μην ενημερώνεται σε πραγματικό χρόνο.
CQRS
Το αν η καθυστέρηση μπορεί να γίνει ανεκτή πρέπει να εξεταστεί από επιχειρηματική σκοπιά, όπως τα δημοφιλή καλύτερα προϊόντα τις τελευταίες 24 ώρες, λίγο ξεπερασμένες πληροφορίες δεν έχουν μεγάλο αντίκτυπο, απαιτείται μόνο η τελική συνέπεια.
Μπορούμε να χρησιμοποιήσουμε το CQRS (Command Query Responsibility Segregation), δηλαδή τον διαχωρισμό των εντολών για την προσθήκη ή την τροποποίηση εντολών από τις ευθύνες ερωτημάτων.
Στο CQRS, η έμφαση δίνεται στον διαχωρισμό ανάγνωσης (Ερώτημα) και εγγραφής (Εντολή), επειδή τα δεδομένα που διαβάζουν οι χρήστες είναι συνήθως ξεπερασμένα, οπότε γιατί χρειάζεται να διαβάσετε από τη βάση δεδομένων, μπορείτε να δημιουργήσετε απευθείας μια πηγή δεδομένων ανάγνωσης. Μπορεί να είναι Cache, μπορεί να είναι XML, JSON κ.λπ.
Πώς να λύσετε το πρόβλημα του τρόπου ενημέρωσης που αναφέρθηκε προηγουμένως; Μπορείτε να χρησιμοποιήσετε το συμβάν, δηλαδή ένα συμβάν, για παράδειγμα, όταν πωλείται ένα προϊόν, μπορείτε να δημοσιεύσετε ένα συμβάν για να τροποποιήσετε το αρχικό μοντέλο ανάγνωσης.
Με αυτόν τον τρόπο, ο συγχρονισμός γίνεται ασύγχρονος μέσω του μηχανισμού συμβάντων.
Τέλος, αυτή η μέθοδος χρησιμοποιείται καλύτερα μόνο για σύνθετα ερωτήματα και τα αρχικά απλά ερωτήματα εξακολουθούν να λαμβάνονται στη σχεσιακή βάση δεδομένων. Γιατί? Επειδή η εισαγωγή μιας νέας τεχνολογίας απαιτεί ένα τίμημα, όπως βήματα σύγχρονης μετάλλαξης και μηχανισμούς συμβάντων, δεν μπορούμε να δούμε μόνο τα πλεονεκτήματα των νέων τεχνολογιών και όχι τα μειονεκτήματα.
|