Γεια σε όλους! Το όνομά μου είναι Golov Nikolay. Προηγουμένως, δούλευα στην Avito και διαχειριζόμουν την πλατφόρμα δεδομένων για έξι χρόνια, δηλαδή δούλευα σε όλες τις βάσεις δεδομένων: αναλυτικές (Vertica, ClickHouse), streaming και OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Κατά τη διάρκεια αυτής της περιόδου, ασχολήθηκα με μεγάλο αριθμό βάσεων δεδομένων - πολύ διαφορετικές και ασυνήθιστες, και με μη τυπικές περιπτώσεις χρήσης τους.
Αυτήν τη στιγμή εργάζομαι στο ManyChat. Στην ουσία, πρόκειται για μια startup - νέα, φιλόδοξη και ταχέως αναπτυσσόμενη. Και όταν μπήκα για πρώτη φορά στην εταιρεία, προέκυψε μια κλασική ερώτηση: «Τι πρέπει να πάρει τώρα μια νέα startup από την αγορά DBMS και βάσεων δεδομένων;»
Σε αυτό το άρθρο, με βάση την έκθεσή μου στο , θα απαντήσω σε αυτή την ερώτηση. Μια έκδοση βίντεο της αναφοράς είναι διαθέσιμη στη διεύθυνση .
Κοινώς γνωστές βάσεις δεδομένων 2020
Είναι 2020, κοίταξα τριγύρω και είδα τρεις τύπους βάσεων δεδομένων.
Πρώτος τύπος - κλασικές βάσεις δεδομένων OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Έχουν γραφτεί πριν από πολύ καιρό, αλλά εξακολουθούν να είναι σχετικά επειδή είναι τόσο γνωστά στην κοινότητα προγραμματιστών.
Ο δεύτερος τύπος είναι βάσεις από το "μηδέν". Προσπάθησαν να απομακρυνθούν από τα κλασικά μοτίβα, εγκαταλείποντας την SQL, τις παραδοσιακές δομές και το ACID, προσθέτοντας ενσωματωμένο Sharding και άλλα ελκυστικά χαρακτηριστικά. Για παράδειγμα, αυτό είναι το Cassandra, το MongoDB, το Redis ή το Tarantool. Όλες αυτές οι λύσεις ήθελαν να προσφέρουν στην αγορά κάτι θεμελιωδώς νέο και κατέλαβαν τη θέση τους επειδή αποδείχθηκαν εξαιρετικά βολικές για ορισμένες εργασίες. Θα υποδηλώσω αυτές τις βάσεις δεδομένων με τον όρο ομπρέλα NOSQL.
Τα «μηδενικά» τελείωσαν, συνηθίσαμε στις βάσεις δεδομένων NOSQL και ο κόσμος, κατά την άποψή μου, έκανε το επόμενο βήμα - να διαχειριζόμενες βάσεις δεδομένων. Αυτές οι βάσεις δεδομένων έχουν τον ίδιο πυρήνα με τις κλασικές βάσεις δεδομένων OLTP ή τις νέες NoSQL. Αλλά δεν χρειάζονται DBA και DevOps και τρέχουν σε διαχειριζόμενο υλικό στα σύννεφα. Για έναν προγραμματιστή, αυτό είναι «απλώς μια βάση» που λειτουργεί κάπου, αλλά κανείς δεν ενδιαφέρεται πώς εγκαθίσταται στον διακομιστή, ποιος έχει ρυθμίσει τον διακομιστή και ποιος τον ενημερώνει.
Παραδείγματα τέτοιων βάσεων δεδομένων:
- Το AWS RDS είναι ένα διαχειριζόμενο περιτύλιγμα για PostgreSQL/MySQL.
- Το DynamoDB είναι ένα ανάλογο AWS μιας βάσης δεδομένων που βασίζεται σε έγγραφα, παρόμοια με τα Redis και MongoDB.
- Το Amazon Redshift είναι μια διαχειριζόμενη αναλυτική βάση δεδομένων.
Αυτές είναι βασικά παλιές βάσεις δεδομένων, αλλά έχουν αναπτυχθεί σε ένα διαχειριζόμενο περιβάλλον, χωρίς την ανάγκη εργασίας με υλικό.
Σημείωση. Τα παραδείγματα λαμβάνονται για το περιβάλλον AWS, αλλά τα ανάλογα τους υπάρχουν επίσης στο Microsoft Azure, στο Google Cloud ή στο Yandex.Cloud.
Τι νέο υπάρχει σε αυτό; Το 2020, τίποτα από όλα αυτά.
Έννοια χωρίς διακομιστή
Αυτό που είναι πραγματικά νέο στην αγορά το 2020 είναι λύσεις χωρίς διακομιστή ή χωρίς διακομιστή.
Θα προσπαθήσω να εξηγήσω τι σημαίνει αυτό χρησιμοποιώντας το παράδειγμα μιας κανονικής υπηρεσίας ή μιας εφαρμογής υποστήριξης.
Για να αναπτύξουμε μια κανονική εφαρμογή υποστήριξης, αγοράζουμε ή νοικιάζουμε έναν διακομιστή, αντιγράφουμε τον κώδικα σε αυτόν, δημοσιεύουμε το τελικό σημείο έξω και πληρώνουμε τακτικά για ενοίκιο, ηλεκτρισμό και υπηρεσίες κέντρου δεδομένων. Αυτό είναι το τυπικό σχήμα.
Υπάρχει άλλος τρόπος; Με υπηρεσίες χωρίς διακομιστή μπορείτε.
Ποιο είναι το επίκεντρο αυτής της προσέγγισης: δεν υπάρχει διακομιστής, δεν υπάρχει καν ενοικίαση εικονικής παρουσίας στο cloud. Για να αναπτύξετε την υπηρεσία, αντιγράψτε τον κώδικα (συναρτήσεις) στο αποθετήριο και δημοσιεύστε τον στο τελικό σημείο. Στη συνέχεια, απλώς πληρώνουμε για κάθε κλήση σε αυτήν τη λειτουργία, αγνοώντας εντελώς το υλικό όπου εκτελείται.
Θα προσπαθήσω να επεξηγήσω αυτή την προσέγγιση με εικόνες.
Κλασική ανάπτυξη. Έχουμε μια υπηρεσία με συγκεκριμένο φορτίο. Αναφέρουμε δύο περιπτώσεις: φυσικούς διακομιστές ή παρουσίες στο AWS. Τα εξωτερικά αιτήματα αποστέλλονται σε αυτές τις περιπτώσεις και υποβάλλονται σε επεξεργασία εκεί.
Όπως μπορείτε να δείτε στην εικόνα, οι διακομιστές δεν απορρίπτονται εξίσου. Το ένα χρησιμοποιείται 100%, υπάρχουν δύο αιτήματα και το ένα είναι μόνο 50% - μερικώς αδρανές. Εάν δεν φτάσουν τρία αιτήματα, αλλά 30, τότε ολόκληρο το σύστημα δεν θα μπορέσει να αντιμετωπίσει το φορτίο και θα αρχίσει να επιβραδύνεται.
Ανάπτυξη χωρίς διακομιστή. Σε περιβάλλον χωρίς διακομιστή, μια τέτοια υπηρεσία δεν έχει παρουσίες ή διακομιστές. Υπάρχει μια συγκεκριμένη δεξαμενή θερμαινόμενων πόρων - μικρά προετοιμασμένα δοχεία Docker με αναπτυγμένο κωδικό λειτουργίας. Το σύστημα λαμβάνει εξωτερικά αιτήματα και για καθένα από αυτά το πλαίσιο χωρίς διακομιστή σηκώνει ένα μικρό κοντέινερ με κώδικα: επεξεργάζεται αυτό το συγκεκριμένο αίτημα και σκοτώνει το κοντέινερ.
Ένα αίτημα - υποβλήθηκε ένα κοντέινερ, 1000 αιτήματα - 1000 κοντέινερ. Και η ανάπτυξη σε διακομιστές υλικού είναι ήδη έργο του παρόχου cloud. Είναι εντελώς κρυμμένο από το πλαίσιο χωρίς διακομιστή. Σε αυτό το concept πληρώνουμε για κάθε κλήση. Για παράδειγμα, μια κλήση ερχόταν την ημέρα - πληρώσαμε για μια κλήση, ένα εκατομμύριο ήρθε το λεπτό - πληρώσαμε για ένα εκατομμύριο. Ή σε ένα δευτερόλεπτο, συμβαίνει και αυτό.
Η ιδέα της δημοσίευσης μιας συνάρτησης χωρίς διακομιστή είναι κατάλληλη για μια υπηρεσία χωρίς κράτος. Και αν χρειάζεστε μια υπηρεσία (statefull), τότε προσθέτουμε μια βάση δεδομένων στην υπηρεσία. Σε αυτήν την περίπτωση, όταν πρόκειται για εργασία με κατάσταση, κάθε συνάρτηση statefull απλώς γράφει και διαβάζει από τη βάση δεδομένων. Επιπλέον, από μια βάση δεδομένων οποιουδήποτε από τους τρεις τύπους που περιγράφονται στην αρχή του άρθρου.
Ποιος είναι ο κοινός περιορισμός όλων αυτών των βάσεων δεδομένων; Αυτά είναι τα κόστη ενός διαρκώς χρησιμοποιούμενου διακομιστή cloud ή υλικού (ή πολλών διακομιστών). Δεν έχει σημασία αν χρησιμοποιούμε μια κλασική ή διαχειριζόμενη βάση δεδομένων, είτε έχουμε Devops και διαχειριστή είτε όχι, εξακολουθούμε να πληρώνουμε για ενοικίαση υλικού, ηλεκτρικού ρεύματος και κέντρου δεδομένων 24/7. Αν έχουμε κλασική βάση, πληρώνουμε κύριο και σκλάβο. Εάν πρόκειται για μια πολύ φορτωμένη κοινόχρηστη βάση δεδομένων, πληρώνουμε για 10, 20 ή 30 διακομιστές και πληρώνουμε συνεχώς.
Η παρουσία μόνιμα δεσμευμένων διακομιστών στη δομή του κόστους θεωρούνταν στο παρελθόν ως αναγκαίο κακό. Οι συμβατικές βάσεις δεδομένων έχουν επίσης άλλες δυσκολίες, όπως περιορισμούς στον αριθμό των συνδέσεων, περιορισμούς κλίμακας, γεω-κατανεμημένη συναίνεση - μπορούν με κάποιο τρόπο να επιλυθούν σε ορισμένες βάσεις δεδομένων, αλλά όχι όλες ταυτόχρονα και όχι ιδανικά.
Βάση δεδομένων χωρίς διακομιστή - θεωρία
Ερώτηση 2020: είναι δυνατόν να γίνει και μια βάση δεδομένων χωρίς διακομιστή; Όλοι έχουν ακούσει για το backend χωρίς διακομιστή... ας προσπαθήσουμε να κάνουμε τη βάση δεδομένων χωρίς διακομιστή;
Αυτό ακούγεται περίεργο, επειδή η βάση δεδομένων είναι μια υπηρεσία με πλήρη κατάσταση, όχι πολύ κατάλληλη για υποδομές χωρίς διακομιστή. Ταυτόχρονα, η κατάσταση της βάσης δεδομένων είναι πολύ μεγάλη: gigabyte, terabyte, και στις αναλυτικές βάσεις δεδομένων ακόμη και petabyte. Δεν είναι τόσο εύκολο να το μεγαλώσετε σε ελαφριά δοχεία Docker.
Από την άλλη πλευρά, σχεδόν όλες οι σύγχρονες βάσεις δεδομένων περιέχουν μια τεράστια ποσότητα λογικής και στοιχείων: συναλλαγές, συντονισμό ακεραιότητας, διαδικασίες, σχεσιακές εξαρτήσεις και πολλή λογική. Για πολλή λογική βάσης δεδομένων, αρκεί μια μικρή κατάσταση. Τα Gigabytes και τα Terabytes χρησιμοποιούνται άμεσα μόνο από ένα μικρό μέρος της λογικής της βάσης δεδομένων που εμπλέκεται στην απευθείας εκτέλεση ερωτημάτων.
Αντίστοιχα, η ιδέα είναι: εάν μέρος της λογικής επιτρέπει την εκτέλεση χωρίς ιθαγένεια, γιατί να μην χωριστεί η βάση σε Stateful και Stateless μέρη.
Χωρίς διακομιστή για λύσεις OLAP
Ας δούμε πώς μπορεί να μοιάζει η κοπή μιας βάσης δεδομένων σε μέρη Stateful και Stateless χρησιμοποιώντας πρακτικά παραδείγματα.
Για παράδειγμα, έχουμε μια αναλυτική βάση δεδομένων: εξωτερικά δεδομένα (κόκκινος κύλινδρος στα αριστερά), μια διαδικασία ETL που φορτώνει δεδομένα στη βάση δεδομένων και ένας αναλυτής που στέλνει ερωτήματα SQL στη βάση δεδομένων. Αυτό είναι ένα κλασικό σχήμα λειτουργίας αποθήκης δεδομένων.
Σε αυτό το σχήμα, το ETL εκτελείται υπό όρους μία φορά. Στη συνέχεια, πρέπει να πληρώνετε συνεχώς για τους διακομιστές στους οποίους εκτελείται η βάση δεδομένων με δεδομένα γεμάτα με ETL, ώστε να υπάρχει κάτι για να στείλετε ερωτήματα.
Ας δούμε μια εναλλακτική προσέγγιση που εφαρμόζεται στο AWS Athena Serverless. Δεν υπάρχει μόνιμα αποκλειστικό υλικό στο οποίο αποθηκεύονται τα δεδομένα λήψης. Αντί για αυτό:
- Ο χρήστης υποβάλλει ένα ερώτημα SQL στην Athena. Το Athena optimizer αναλύει το ερώτημα SQL και πραγματοποιεί αναζήτηση στο χώρο αποθήκευσης μεταδεδομένων (Metadata) για τα συγκεκριμένα δεδομένα που απαιτούνται για την εκτέλεση του ερωτήματος.
- Ο βελτιστοποιητής, με βάση τα δεδομένα που συλλέγει, πραγματοποιεί λήψη των απαραίτητων δεδομένων από εξωτερικές πηγές σε προσωρινή αποθήκευση (προσωρινή βάση δεδομένων).
- Ένα ερώτημα SQL από τον χρήστη εκτελείται σε προσωρινή αποθήκευση και το αποτέλεσμα επιστρέφεται στον χρήστη.
- Η προσωρινή αποθήκευση διαγράφεται και οι πόροι απελευθερώνονται.
Σε αυτήν την αρχιτεκτονική, πληρώνουμε μόνο για τη διαδικασία εκτέλεσης του αιτήματος. Χωρίς αιτήματα - χωρίς κόστος.
Αυτή είναι μια προσέγγιση εργασίας και εφαρμόζεται όχι μόνο στο Athena Serverless, αλλά και στο Redshift Spectrum (στο AWS).
Το παράδειγμα Athena δείχνει ότι η βάση δεδομένων χωρίς διακομιστή λειτουργεί σε πραγματικά ερωτήματα με δεκάδες και εκατοντάδες Terabyte δεδομένων. Εκατοντάδες Terabytes θα απαιτήσουν εκατοντάδες διακομιστές, αλλά δεν χρειάζεται να πληρώσουμε για αυτούς - πληρώνουμε για τα αιτήματα. Η ταχύτητα κάθε αιτήματος είναι (πολύ) χαμηλή σε σύγκριση με εξειδικευμένες αναλυτικές βάσεις δεδομένων όπως η Vertica, αλλά δεν πληρώνουμε για περιόδους διακοπής λειτουργίας.
Μια τέτοια βάση δεδομένων είναι εφαρμόσιμη για σπάνια αναλυτικά ad-hoc ερωτήματα. Για παράδειγμα, όταν αποφασίζουμε αυθόρμητα να δοκιμάσουμε μια υπόθεση σε κάποια τεράστια ποσότητα δεδομένων. Η Αθηνά είναι τέλεια για αυτές τις περιπτώσεις. Για τακτικά αιτήματα, ένα τέτοιο σύστημα είναι ακριβό. Σε αυτήν την περίπτωση, αποθηκεύστε προσωρινά τα δεδομένα σε κάποια εξειδικευμένη λύση.
Χωρίς διακομιστή για λύσεις OLTP
Το προηγούμενο παράδειγμα εξέτασε τις εργασίες OLAP (αναλυτικές). Τώρα ας δούμε τις εργασίες OLTP.
Ας φανταστούμε επεκτάσιμη PostgreSQL ή MySQL. Ας δημιουργήσουμε μια κανονική διαχειριζόμενη παρουσία PostgreSQL ή MySQL με ελάχιστους πόρους. Όταν το στιγμιότυπο λάβει περισσότερο φορτίο, θα συνδέσουμε επιπλέον αντίγραφα στα οποία θα διανείμουμε μέρος του φορτίου ανάγνωσης. Εάν δεν υπάρχουν αιτήματα ή φόρτωση, απενεργοποιούμε τα αντίγραφα. Η πρώτη περίπτωση είναι ο κύριος και τα υπόλοιπα είναι αντίγραφα.
Αυτή η ιδέα υλοποιείται σε μια βάση δεδομένων που ονομάζεται Aurora Serverless AWS. Η αρχή είναι απλή: αιτήματα από εξωτερικές εφαρμογές γίνονται δεκτά από το στόλο μεσολάβησης. Βλέποντας το φορτίο να αυξάνεται, κατανέμει υπολογιστικούς πόρους από ελάχιστες προθερμασμένες περιπτώσεις - η σύνδεση γίνεται όσο το δυνατόν γρηγορότερα. Η απενεργοποίηση των περιπτώσεων εμφανίζεται με τον ίδιο τρόπο.
Μέσα στο Aurora υπάρχει η έννοια του Aurora Capacity Unit, ACU. Αυτό είναι (υπό όρους) μια παρουσία (διακομιστής). Κάθε συγκεκριμένο ACU μπορεί να είναι master ή slave. Κάθε μονάδα χωρητικότητας έχει τη δική της μνήμη RAM, επεξεργαστή και ελάχιστο δίσκο. Κατά συνέπεια, ο ένας είναι κύριος, τα υπόλοιπα είναι αντίγραφα μόνο για ανάγνωση.
Ο αριθμός αυτών των μονάδων χωρητικότητας Aurora που εκτελούνται είναι μια παραμετροποιήσιμη παράμετρος. Η ελάχιστη ποσότητα μπορεί να είναι ένα ή μηδέν (σε αυτήν την περίπτωση, η βάση δεδομένων δεν λειτουργεί εάν δεν υπάρχουν αιτήματα).
Όταν η βάση λαμβάνει αιτήματα, ο στόλος μεσολάβησης αυξάνει τις μονάδες χωρητικότητας Aurora, αυξάνοντας τους πόρους απόδοσης του συστήματος. Η δυνατότητα αύξησης και μείωσης πόρων επιτρέπει στο σύστημα να «ζυγκλάρει» τους πόρους: εμφανίζει αυτόματα μεμονωμένες μονάδες ACU (αντικαθιστώντας τις με νέες) και διανέμει όλες τις τρέχουσες ενημερώσεις στους πόρους που αποσύρονται.
Η βάση χωρίς διακομιστή Aurora μπορεί να κλιμακώσει το φορτίο ανάγνωσης. Αλλά η τεκμηρίωση δεν το λέει ευθέως. Μπορεί να αισθάνονται σαν να μπορούν να σηκώσουν ένα multi-master. Δεν υπάρχει μαγεία.
Αυτή η βάση δεδομένων είναι κατάλληλη για την αποφυγή δαπανών τεράστιων ποσών χρημάτων σε συστήματα με απρόβλεπτη πρόσβαση. Για παράδειγμα, όταν δημιουργούμε τοποθεσίες MVP ή μάρκετινγκ επαγγελματικών καρτών, συνήθως δεν περιμένουμε σταθερό φορτίο. Αντίστοιχα, εάν δεν υπάρχει πρόσβαση, δεν πληρώνουμε για περιπτώσεις. Όταν συμβαίνει απροσδόκητη φόρτωση, για παράδειγμα μετά από μια διάσκεψη ή διαφημιστική καμπάνια, πλήθος ανθρώπων επισκέπτονται τον ιστότοπο και το φορτίο αυξάνεται δραματικά, το Aurora Serverless αναλαμβάνει αυτόματα αυτό το φορτίο και συνδέει γρήγορα τους πόρους που λείπουν (ACU). Στη συνέχεια, το συνέδριο περνά, όλοι ξεχνούν το πρωτότυπο, οι διακομιστές (ACU) σκοτεινιάζουν και το κόστος πέφτει στο μηδέν - βολικό.
Αυτή η λύση δεν είναι κατάλληλη για σταθερή φόρτωση επειδή δεν κλιμακώνει το φορτίο γραφής. Όλες αυτές οι συνδέσεις και αποσυνδέσεις πόρων συμβαίνουν στο λεγόμενο «σημείο κλίμακας» - ένα χρονικό σημείο όπου η βάση δεδομένων δεν υποστηρίζεται από μια συναλλαγή ή από προσωρινούς πίνακες. Για παράδειγμα, μέσα σε μια εβδομάδα το σημείο κλίμακας μπορεί να μην συμβεί και η βάση λειτουργεί με τους ίδιους πόρους και απλά δεν μπορεί να επεκταθεί ή να συστέλλεται.
Δεν υπάρχει μαγεία - είναι κανονική PostgreSQL. Αλλά η διαδικασία προσθήκης μηχανών και αποσύνδεσής τους είναι εν μέρει αυτοματοποιημένη.
Σχεδιασμός χωρίς διακομιστή
Το Aurora Serverless είναι μια παλιά βάση δεδομένων που έχει ξαναγραφτεί για το cloud για να εκμεταλλευτεί ορισμένα από τα οφέλη του Serverless. Και τώρα θα σας πω για τη βάση, η οποία γράφτηκε αρχικά για το cloud, για την προσέγγιση χωρίς διακομιστή - Serverless-by-design. Αναπτύχθηκε αμέσως χωρίς την υπόθεση ότι θα λειτουργούσε σε φυσικούς διακομιστές.
Αυτή η βάση ονομάζεται Snowflake. Έχει τρία βασικά μπλοκ.
Το πρώτο είναι ένα μπλοκ μεταδεδομένων. Αυτή είναι μια γρήγορη υπηρεσία μνήμης που επιλύει ζητήματα ασφάλειας, μεταδεδομένων, συναλλαγών και βελτιστοποίησης ερωτημάτων (που φαίνεται στην εικόνα στα αριστερά).
Το δεύτερο μπλοκ είναι ένα σύνολο εικονικών συμπλεγμάτων υπολογιστών για υπολογισμούς (στην εικόνα υπάρχει ένα σύνολο μπλε κύκλων).
Το τρίτο μπλοκ είναι ένα σύστημα αποθήκευσης δεδομένων που βασίζεται στο S3. Το S3 είναι αποθήκευση αντικειμένων χωρίς διαστάσεις στο AWS, κάτι σαν αδιάστατο Dropbox για επιχειρήσεις.
Ας δούμε πώς λειτουργεί το Snowflake, υποθέτοντας ένα κρύο ξεκίνημα. Δηλαδή, υπάρχει μια βάση δεδομένων, τα δεδομένα φορτώνονται σε αυτήν, δεν υπάρχουν ερωτήματα που εκτελούνται. Αντίστοιχα, εάν δεν υπάρχουν αιτήματα στη βάση δεδομένων, τότε έχουμε αυξήσει την υπηρεσία μεταδεδομένων γρήγορης μνήμης (πρώτο μπλοκ). Και έχουμε αποθήκευση S3, όπου αποθηκεύονται τα δεδομένα πίνακα, χωρισμένα σε λεγόμενα μικροδιαμερίσματα. Για απλότητα: εάν ο πίνακας περιέχει συναλλαγές, τότε τα μικροδιαμερίσματα είναι οι ημέρες των συναλλαγών. Κάθε μέρα είναι ένα ξεχωριστό micropartition, ένα ξεχωριστό αρχείο. Και όταν η βάση δεδομένων λειτουργεί σε αυτήν τη λειτουργία, πληρώνετε μόνο για τον χώρο που καταλαμβάνουν τα δεδομένα. Επιπλέον, ο ρυθμός ανά θέση είναι πολύ χαμηλός (ειδικά λαμβάνοντας υπόψη τη σημαντική συμπίεση). Η υπηρεσία μεταδεδομένων λειτουργεί επίσης συνεχώς, αλλά δεν χρειάζεστε πολλούς πόρους για τη βελτιστοποίηση των ερωτημάτων και η υπηρεσία μπορεί να θεωρηθεί ως κοινόχρηστο λογισμικό.
Τώρα ας φανταστούμε ότι ένας χρήστης ήρθε στη βάση δεδομένων μας και έστειλε ένα ερώτημα SQL. Το ερώτημα SQL αποστέλλεται αμέσως στην υπηρεσία Μεταδεδομένων για επεξεργασία. Αντίστοιχα, μόλις λάβει ένα αίτημα, αυτή η υπηρεσία αναλύει το αίτημα, τα διαθέσιμα δεδομένα, τις άδειες χρήστη και, εάν όλα πάνε καλά, καταρτίζει ένα σχέδιο για την επεξεργασία του αιτήματος.
Στη συνέχεια, η υπηρεσία ξεκινά την εκκίνηση του συμπλέγματος υπολογιστών. Ένα υπολογιστικό σύμπλεγμα είναι ένα σύμπλεγμα διακομιστών που εκτελούν υπολογισμούς. Δηλαδή, αυτό είναι ένα σύμπλεγμα που μπορεί να περιέχει 1 διακομιστή, 2 διακομιστές, 4, 8, 16, 32 - όσους θέλετε. Ρίχνεις ένα αίτημα και ξεκινά αμέσως η εκκίνηση αυτού του συμπλέγματος. Χρειάζονται πραγματικά δευτερόλεπτα.
Στη συνέχεια, αφού ξεκινήσει το σύμπλεγμα, τα μικροδιαμερίσματα που απαιτούνται για την επεξεργασία του αιτήματός σας αρχίζουν να αντιγράφονται στο σύμπλεγμα από το S3. Δηλαδή, ας φανταστούμε ότι για να εκτελέσετε ένα ερώτημα SQL χρειάζεστε δύο διαμερίσματα από έναν πίνακα και ένα από τον δεύτερο. Σε αυτήν την περίπτωση, μόνο τα τρία απαραίτητα διαμερίσματα θα αντιγραφούν στο σύμπλεγμα και όχι όλοι οι πίνακες εξ ολοκλήρου. Γι' αυτό, και ακριβώς επειδή όλα βρίσκονται σε ένα κέντρο δεδομένων και συνδέονται με πολύ γρήγορα κανάλια, ολόκληρη η διαδικασία μεταφοράς πραγματοποιείται πολύ γρήγορα: σε δευτερόλεπτα, πολύ σπάνια σε λεπτά, εκτός και αν μιλάμε για κάποια τερατώδη αιτήματα . Αντίστοιχα, τα μικροδιαμερίσματα αντιγράφονται στο υπολογιστικό σύμπλεγμα και, μετά την ολοκλήρωση, το ερώτημα SQL εκτελείται σε αυτό το υπολογιστικό σύμπλεγμα. Το αποτέλεσμα αυτού του αιτήματος μπορεί να είναι μία γραμμή, πολλές γραμμές ή ένας πίνακας - αποστέλλονται εξωτερικά στον χρήστη, ώστε να μπορεί να το κατεβάσει, να το εμφανίσει στο εργαλείο BI του ή να το χρησιμοποιήσει με κάποιον άλλο τρόπο.
Κάθε ερώτημα SQL μπορεί όχι μόνο να διαβάσει συγκεντρωτικά στοιχεία από δεδομένα που έχουν φορτωθεί προηγουμένως, αλλά και να φορτώσει/δημιουργήσει νέα δεδομένα στη βάση δεδομένων. Δηλαδή, μπορεί να είναι ένα ερώτημα που, για παράδειγμα, εισάγει νέες εγγραφές σε έναν άλλο πίνακα, το οποίο οδηγεί στην εμφάνιση ενός νέου διαμερίσματος στο υπολογιστικό σύμπλεγμα, το οποίο, με τη σειρά του, αποθηκεύεται αυτόματα σε ένα ενιαίο χώρο αποθήκευσης S3.
Το σενάριο που περιγράφεται παραπάνω, από την άφιξη του χρήστη έως την ανύψωση του συμπλέγματος, τη φόρτωση δεδομένων, την εκτέλεση ερωτημάτων, τη λήψη αποτελεσμάτων, πληρώνεται με την τιμή για λεπτά χρήσης του αυξημένου εικονικού συμπλέγματος υπολογιστών, εικονικής αποθήκης. Η τιμή ποικίλλει ανάλογα με τη ζώνη AWS και το μέγεθος του συμπλέγματος, αλλά κατά μέσο όρο είναι μερικά δολάρια την ώρα. Ένα σύμπλεγμα τεσσάρων μηχανών είναι δύο φορές πιο ακριβό από ένα σύμπλεγμα δύο μηχανών και ένα σύμπλεγμα οκτώ μηχανών εξακολουθεί να είναι διπλάσιο. Διατίθενται επιλογές 16, 32 μηχανών, ανάλογα με την πολυπλοκότητα των αιτημάτων. Πληρώνετε όμως μόνο για εκείνα τα λεπτά όταν το σύμπλεγμα εκτελείται πραγματικά, γιατί όταν δεν υπάρχουν αιτήματα, κάπως βγάζετε τα χέρια σας και μετά από 5-10 λεπτά αναμονής (μια παραμετροποιήσιμη παράμετρος) θα σβήσει μόνο του, ελευθερώστε πόρους και γίνετε ελεύθεροι.
Ένα εντελώς ρεαλιστικό σενάριο είναι όταν στέλνετε ένα αίτημα, το σύμπλεγμα εμφανίζεται, σχετικά μιλώντας, σε ένα λεπτό, μετράει άλλο ένα λεπτό, μετά πέντε λεπτά για να τερματιστεί, και καταλήγετε να πληρώνετε για επτά λεπτά λειτουργίας αυτού του συμπλέγματος, και όχι για μήνες και χρόνια.
Το πρώτο σενάριο περιγράφεται χρησιμοποιώντας το Snowflake σε μια ρύθμιση ενός χρήστη. Τώρα ας φανταστούμε ότι υπάρχουν πολλοί χρήστες, κάτι που είναι πιο κοντά στο πραγματικό σενάριο.
Ας υποθέσουμε ότι έχουμε πολλούς αναλυτές και αναφορές Tableau που βομβαρδίζουν συνεχώς τη βάση δεδομένων μας με μεγάλο αριθμό απλών αναλυτικών ερωτημάτων SQL.
Επιπλέον, ας πούμε ότι έχουμε εφευρετικούς Επιστήμονες Δεδομένων που προσπαθούν να κάνουν τερατώδη πράγματα με δεδομένα, λειτουργούν με δεκάδες Terabyte, αναλύουν δισεκατομμύρια και τρισεκατομμύρια σειρές δεδομένων.
Για τους δύο τύπους φόρτου εργασίας που περιγράφονται παραπάνω, το Snowflake σάς επιτρέπει να δημιουργήσετε πολλά ανεξάρτητα συμπλέγματα υπολογιστών διαφορετικών χωρητικοτήτων. Επιπλέον, αυτά τα συμπλέγματα υπολογιστών λειτουργούν ανεξάρτητα, αλλά με κοινά συνεπή δεδομένα.
Για μεγάλο αριθμό ελαφρών ερωτημάτων, μπορείτε να δημιουργήσετε 2-3 μικρά συμπλέγματα, περίπου 2 μηχανές το καθένα. Αυτή η συμπεριφορά μπορεί να εφαρμοστεί, μεταξύ άλλων, χρησιμοποιώντας αυτόματες ρυθμίσεις. Λοιπόν, λέτε, «Νιφάδα χιονιού, σήκωσε ένα μικρό σύμπλεγμα. Εάν το φορτίο σε αυτό αυξάνεται πάνω από μια συγκεκριμένη παράμετρο, σηκώστε ένα παρόμοιο δεύτερο, τρίτο. Όταν το φορτίο αρχίσει να υποχωρεί, σβήστε το πλεόνασμα.» Ώστε όσοι αναλυτές κι αν έρθουν και αρχίσουν να κοιτάζουν αναφορές, όλοι έχουν αρκετούς πόρους.
Ταυτόχρονα, εάν οι αναλυτές κοιμούνται και κανείς δεν κοιτάξει τις αναφορές, τα cluster μπορεί να σκοτεινιάσουν εντελώς και να σταματήσετε να πληρώνετε για αυτά.
Ταυτόχρονα, για βαριά ερωτήματα (από τους Data Scientists), μπορείτε να δημιουργήσετε ένα πολύ μεγάλο σύμπλεγμα για 32 μηχανές. Αυτό το σύμπλεγμα θα πληρωθεί επίσης μόνο για εκείνα τα λεπτά και τις ώρες που εκτελείται εκεί το τεράστιο αίτημά σας.
Η ευκαιρία που περιγράφεται παραπάνω σάς επιτρέπει να διαιρέσετε όχι μόνο 2, αλλά και περισσότερους τύπους φόρτου εργασίας σε ομάδες (ETL, παρακολούθηση, υλοποίηση αναφορών,...).
Ας συνοψίσουμε το Snowflake. Η βάση συνδυάζει μια όμορφη ιδέα και μια εφαρμόσιμη εφαρμογή. Στο ManyChat, χρησιμοποιούμε το Snowflake για να αναλύσουμε όλα τα δεδομένα που έχουμε. Δεν έχουμε τρία συμπλέγματα, όπως στο παράδειγμα, αλλά από 5 έως 9, διαφορετικών μεγεθών. Έχουμε συμβατικά 16-μηχανή, 2-μηχανή, καθώς και εξαιρετικά μικρά 1-μηχανή για ορισμένες εργασίες. Κατανέμουν με επιτυχία το φορτίο και μας επιτρέπουν να εξοικονομήσουμε πολλά.
Η βάση δεδομένων κλιμακώνει με επιτυχία το φορτίο ανάγνωσης και γραφής. Αυτή είναι μια τεράστια διαφορά και μια τεράστια ανακάλυψη σε σύγκριση με το ίδιο "Aurora", το οποίο έφερε μόνο το φορτίο ανάγνωσης. Το Snowflake σάς επιτρέπει να κλιμακώσετε τον φόρτο εργασίας σας με αυτά τα συμπλέγματα υπολογιστών. Δηλαδή, όπως ανέφερα, χρησιμοποιούμε αρκετά cluster στο ManyChat, μικρά και υπερμικρά cluster χρησιμοποιούνται κυρίως για ETL, για φόρτωση δεδομένων. Και οι αναλυτές ζουν ήδη σε μεσαίες συστάδες, οι οποίες δεν επηρεάζονται απολύτως από το φορτίο ETL, επομένως λειτουργούν πολύ γρήγορα.
Συνεπώς, η βάση δεδομένων είναι κατάλληλη για εργασίες OLAP. Ωστόσο, δυστυχώς, δεν είναι ακόμη εφαρμόσιμο για φόρτους εργασίας OLTP. Πρώτον, αυτή η βάση δεδομένων είναι στηλοειδής, με όλες τις επακόλουθες συνέπειες. Δεύτερον, η ίδια η προσέγγιση, όταν για κάθε αίτημα, εάν είναι απαραίτητο, δημιουργείτε ένα σύμπλεγμα υπολογιστών και το πλημμυρίζετε με δεδομένα, δυστυχώς, δεν είναι ακόμη αρκετά γρήγορη για φορτία OLTP. Η αναμονή δευτερολέπτων για εργασίες OLAP είναι φυσιολογική, αλλά για εργασίες OLTP είναι απαράδεκτη· 100 ms θα ήταν καλύτερα ή 10 ms θα ήταν ακόμα καλύτερα.
Σύνολο
Μια βάση δεδομένων χωρίς διακομιστή είναι δυνατή με τη διαίρεση της βάσης δεδομένων σε μέρη Χωρίς Πολιτεία και Κράτους. Ίσως έχετε παρατηρήσει ότι σε όλα τα παραπάνω παραδείγματα, το τμήμα Stateful αποθηκεύει, σχετικά, μικρο-διαμερίσματα στο S3 και το Stateless είναι ο βελτιστοποιητής, που εργάζεται με μεταδεδομένα, χειρίζεται ζητήματα ασφάλειας που μπορούν να τεθούν ως ανεξάρτητες ελαφριές υπηρεσίες Χωρίς Πολιτεία.
Η εκτέλεση ερωτημάτων SQL μπορεί επίσης να γίνει αντιληπτή ως υπηρεσίες φωτεινής κατάστασης που μπορούν να εμφανιστούν σε λειτουργία χωρίς διακομιστή, όπως συμπλέγματα υπολογιστών Snowflake, να κατεβάσουν μόνο τα απαραίτητα δεδομένα, να εκτελέσουν το ερώτημα και να "σβήσουν".
Οι βάσεις δεδομένων επιπέδου παραγωγής χωρίς διακομιστή είναι ήδη διαθέσιμες για χρήση, λειτουργούν. Αυτές οι βάσεις δεδομένων χωρίς διακομιστή είναι ήδη έτοιμες να χειριστούν εργασίες OLAP. Δυστυχώς, για εργασίες OLTP χρησιμοποιούνται... με αποχρώσεις, αφού υπάρχουν περιορισμοί. Από τη μία πλευρά, αυτό είναι ένα μείον. Αλλά, από την άλλη, αυτή είναι μια ευκαιρία. Ίσως κάποιος από τους αναγνώστες να βρει έναν τρόπο να κάνει μια βάση δεδομένων OLTP εντελώς χωρίς διακομιστή, χωρίς τους περιορισμούς του Aurora.
Ελπίζω να το βρήκατε ενδιαφέρον. Χωρίς διακομιστή είναι το μέλλον :)
Πηγή: www.habr.com