Γεια σου, Χαμπροβίτες. Παραδοσιακά, συνεχίζουμε να μοιραζόμαστε ενδιαφέρον υλικό την παραμονή της έναρξης νέων μαθημάτων. Σήμερα, ειδικά για εσάς, μεταφράσαμε ένα άρθρο σχετικά με το Google Cloud Spanner, που χρονολογείται για να συμπέσει με την έναρξη του μαθήματος .
Αρχικά δημοσιεύτηκε στο .
Ως εταιρεία που προσφέρει μια ποικιλία λύσεων POS που βασίζονται σε cloud για λιανοπωλητές, εστιάτορες και διαδικτυακούς εμπόρους σε όλο τον κόσμο, η Lightspeed χρησιμοποιεί διάφορους τύπους πλατφορμών βάσεων δεδομένων για μια ποικιλία περιπτώσεων χρήσης συναλλαγών, αναλυτικών στοιχείων και αναζήτησης. Κάθε μία από αυτές τις πλατφόρμες βάσεων δεδομένων έχει τα δικά της δυνατά και αδύνατα σημεία. Ως εκ τούτου, όταν η Google εισήγαγε το Cloud Spanner στην αγορά - πολλά υποσχόμενα χαρακτηριστικά που δεν έχουν ξαναφανεί στον κόσμο των σχεσιακών βάσεων δεδομένων, όπως ουσιαστικά απεριόριστη οριζόντια επεκτασιμότητα και συμφωνία επιπέδου εξυπηρέτησης 99,999% (SLA) , Δεν μπορούσαμε να χάσουμε την ευκαιρία να την έχουμε στα χέρια μας!
Για να δώσουμε μια ολοκληρωμένη επισκόπηση της εμπειρίας μας με το Cloud Spanner, καθώς και των κριτηρίων αξιολόγησης που χρησιμοποιήσαμε, θα καλύψουμε τα ακόλουθα θέματα:
- Τα κριτήρια αξιολόγησης μας
- Cloud Spanner με λίγα λόγια
- Η εκτίμησή μας
- Τα ευρήματά μας
1. Τα κριτήρια αξιολόγησής μας
Προτού εξετάσουμε τις ιδιαιτερότητες του Cloud Spanner, τις ομοιότητες και τις διαφορές του με άλλες λύσεις στην αγορά, ας μιλήσουμε πρώτα για τις κύριες περιπτώσεις χρήσης που είχαμε κατά νου όταν σκεφτήκαμε πού να αναπτύξουμε το Cloud Spanner στην υποδομή μας:
- Ως αντικατάσταση της (επικρατούσας) παραδοσιακής λύσης βάσης δεδομένων SQL
- Ως λύση OLTP με δυνατότητα OLAP
Σημείωση: Για ευκολία σύγκρισης, αυτό το άρθρο συγκρίνει το Cloud Spanner με τις παραλλαγές MySQL των οικογενειών λύσεων GCP Cloud SQL και Amazon AWS RDS.
Χρήση του Cloud Spanner ως αντικατάσταση μιας παραδοσιακής λύσης βάσης δεδομένων SQL
Στο περιβάλλον παραδοσιακός βάσεις δεδομένων, όταν ο χρόνος απόκρισης για ένα ερώτημα βάσης δεδομένων πλησιάζει ή και υπερβαίνει τα προκαθορισμένα όρια εφαρμογής (κυρίως λόγω αύξησης του αριθμού χρηστών ή/και αιτημάτων), υπάρχουν διάφοροι τρόποι μείωσης του χρόνου απόκρισης σε αποδεκτά επίπεδα. Ωστόσο, οι περισσότερες από αυτές τις λύσεις περιλαμβάνουν χειροκίνητη παρέμβαση.
Για παράδειγμα, το πρώτο βήμα που πρέπει να κάνετε είναι να εξετάσετε τις διάφορες ρυθμίσεις βάσης δεδομένων που σχετίζονται με την απόδοση και να τις συντονίσετε ώστε να ταιριάζουν καλύτερα με τα μοτίβα σεναρίων χρήσης εφαρμογών. Εάν αυτό δεν είναι αρκετό, μπορείτε να επιλέξετε να κλιμακώσετε τη βάση δεδομένων κατακόρυφα ή οριζόντια.
Η κλιμάκωση μιας εφαρμογής συνεπάγεται ενημέρωση της παρουσίας διακομιστή, συνήθως προσθέτοντας περισσότερους επεξεργαστές/πυρήνες, περισσότερη μνήμη RAM, ταχύτερη αποθήκευση κ.λπ. Η προσθήκη περισσότερων πόρων υλικού έχει ως αποτέλεσμα αυξημένη απόδοση βάσης δεδομένων, μετρούμενη κυρίως σε συναλλαγές ανά δευτερόλεπτο, και καθυστέρηση συναλλαγής για συστήματα OLTP. Συστήματα σχεσιακών βάσεων δεδομένων (που χρησιμοποιούν προσέγγιση πολλαπλών νημάτων) όπως η MySQL κλιμακώνονται καλά κάθετα.
Υπάρχουν πολλά μειονεκτήματα σε αυτή την προσέγγιση, αλλά το πιο προφανές είναι το μέγιστο μέγεθος διακομιστή στην αγορά. Μόλις επιτευχθεί το μεγαλύτερο όριο παρουσίας διακομιστή, απομένει μόνο μία διαδρομή: μείωση κλίμακας.
Η κλιμάκωση είναι μια προσέγγιση που προσθέτει περισσότερους διακομιστές σε ένα σύμπλεγμα για να αυξάνει ιδανικά την απόδοση γραμμικά καθώς προστίθενται περισσότεροι διακομιστές. Η πλειοψηφία παραδοσιακός Τα συστήματα βάσεων δεδομένων δεν κλιμακώνονται καλά ή δεν κλιμακώνονται καθόλου. Για παράδειγμα, η MySQL μπορεί να μειώσει τις αναγνώσεις προσθέτοντας σκλάβους αναγνώστες, αλλά δεν μπορεί να περιορίσει τις αναγνώσεις.
Από την άλλη πλευρά, λόγω της φύσης του, το Cloud Spanner μπορεί εύκολα να κλιμακωθεί οριζόντια με ελάχιστη παρέμβαση.
Πλήρως χαρακτηρισμένο Το DBMS ως υπηρεσία πρέπει να αξιολογηθεί από διαφορετικές οπτικές γωνίες. Ως βάση, πήραμε τα πιο δημοφιλή DBMS στο cloud - για την Google, το GCP Cloud SQL και για το Amazon, το AWS RDS. Στην αξιολόγησή μας, εστιάσαμε στις ακόλουθες κατηγορίες:
- Αντιστοίχιση χαρακτηριστικών: SQL έκταση, DDL, DML. βιβλιοθήκες/υποδοχές σύνδεσης, υποστήριξη συναλλαγών και ούτω καθεξής.
- Υποστήριξη Ανάπτυξης: Ευκολία ανάπτυξης και δοκιμής.
- Υποστήριξη διαχείρισης: Διαχείριση παρουσιών, όπως κλιμάκωση πάνω/κάτω και αναβάθμιση παρουσιών. SLA, δημιουργία αντιγράφων ασφαλείας και ανάκτηση. ασφάλεια/ελέγχου πρόσβασης.
Χρήση του Cloud Spanner ως λύση OLTP με δυνατότητα OLAP
Αν και η Google δεν δηλώνει ρητά ότι το Cloud Spanner προορίζεται για αναλυτικά στοιχεία, μοιράζεται ορισμένα χαρακτηριστικά με άλλες μηχανές όπως οι Apache Impala & Kudu και YugaByte που έχουν σχεδιαστεί για φόρτους εργασίας OLAP.
Ακόμα κι αν υπήρχε μόνο μια μικρή πιθανότητα ότι το Cloud Spanner περιελάμβανε έναν κινητήρα σταθερής κλιμάκωσης HTAP (Hybrid Transactional/Analytic Processing) με ένα (περισσότερο ή λιγότερο) χρησιμοποιήσιμο σύνολο χαρακτηριστικών OLAP, πιστεύουμε ότι θα άξιζε την προσοχή μας.
Με αυτό κατά νου, εξετάσαμε τις ακόλουθες κατηγορίες:
- Υποστήριξη φόρτωσης δεδομένων, ευρετηρίων και διαμερισμάτων
- Απόδοση ερωτημάτων και DML
2. Κλειδί Cloud με λίγα λόγια
Το Google Spanner είναι ένα σύστημα διαχείρισης σχεσιακών βάσεων δεδομένων (RDBMS) που χρησιμοποιεί η Google για πολλές από τις δικές της υπηρεσίες. Η Google το έκανε δημόσια διαθέσιμο στους χρήστες του Google Cloud Platform στις αρχές του 2017.
Ακολουθούν μερικά από τα χαρακτηριστικά του Cloud Spanner:
- Εξαιρετικά συνεπές, κλιμακούμενο σύμπλεγμα RDBMS: Χρησιμοποιεί συγχρονισμό χρόνου υλικού για να διασφαλίσει τη συνέπεια των δεδομένων.
- Υποστήριξη συναλλαγών μεταξύ πινάκων: Οι συναλλαγές μπορούν να εκτείνονται σε πολλούς πίνακες - δεν περιορίζονται απαραίτητα σε έναν μόνο πίνακα (σε αντίθεση με το Apache HBase ή το Apache Kudu).
- Πίνακες με βάση πρωτεύον κλειδί: Όλοι οι πίνακες πρέπει να έχουν ένα δηλωμένο πρωτεύον κλειδί (PC), το οποίο μπορεί να αποτελείται από πολλές στήλες πίνακα. Τα δεδομένα σε πίνακα αποθηκεύονται με σειρά υπολογιστή, γεγονός που τα καθιστά πολύ αποτελεσματικά και γρήγορα για αναζητήσεις υπολογιστή. Όπως και με άλλα συστήματα που βασίζονται σε Η/Υ, η υλοποίηση πρέπει να διαμορφωθεί με βάση προκαθορισμένες περιπτώσεις χρήσης προκειμένου να επιτευχθεί .
- Ριγέ τραπέζια: Τα τραπέζια μπορεί να έχουν φυσικές εξαρτήσεις μεταξύ τους. Οι σειρές του θυγατρικού πίνακα μπορούν να αντιστοιχιστούν με τις σειρές του γονικού πίνακα. Αυτή η προσέγγιση επιταχύνει την αναζήτηση σχέσεων που μπορούν να προσδιοριστούν στο στάδιο της μοντελοποίησης δεδομένων, για παράδειγμα, όταν τοποθετούνται μαζί οι πελάτες και τα τιμολόγιά τους.
- Ευρετήρια: Το Cloud Spanner υποστηρίζει δευτερεύοντα ευρετήρια. Ένα ευρετήριο αποτελείται από στήλες με ευρετήριο και όλες τις στήλες PC. Προαιρετικά, το ευρετήριο μπορεί επίσης να περιέχει άλλες στήλες χωρίς ευρετήριο. Το ευρετήριο μπορεί να παρεμβληθεί με τον γονικό πίνακα για να επιταχυνθούν τα ερωτήματα. Για τα ευρετήρια ισχύουν αρκετοί περιορισμοί, όπως ο μέγιστος αριθμός πρόσθετων στηλών που μπορούν να αποθηκευτούν σε ένα ευρετήριο. Επίσης, τα ερωτήματα μέσω ευρετηρίων μπορεί να μην είναι τόσο απλά όσο σε άλλα RDBMS.
«Το Cloud Spanner επιλέγει αυτόματα ένα ευρετήριο μόνο σε σπάνιες περιπτώσεις. Συγκεκριμένα, το Cloud Spanner δεν επιλέγει αυτόματα ένα δευτερεύον ευρετήριο εάν το ερώτημα ζητήσει στήλες που δεν είναι αποθηκευμένες σε ».
- Συμφωνία επιπέδου υπηρεσίας (SLA): Ανάπτυξη μιας περιοχής με 99,99% SLA. αναπτύξεις πολλαπλών περιοχών με 99,999% SLA. Ενώ η ίδια η SLA είναι απλώς μια συμφωνία και όχι κανενός είδους εγγύηση, πιστεύω ότι οι άνθρωποι της Google διαθέτουν ορισμένα σκληρά δεδομένα για να υποβάλουν έναν τόσο ισχυρό ισχυρισμό. (Για αναφορά, το 99,999% σημαίνει 26,3 δευτερόλεπτα διακοπής της υπηρεσίας ανά μήνα.)
- Περισσότερα:
Σημείωση: Το έργο Apache Tephra προσθέτει προηγμένη υποστήριξη συναλλαγών στο Apache HBase (επίσης εφαρμόζεται πλέον στο Apache Phoenix ως beta).
3. Η εκτίμησή μας
Έτσι, όλοι έχουμε διαβάσει τις δηλώσεις της Google σχετικά με τα πλεονεκτήματα του Cloud Spanner - ουσιαστικά απεριόριστη οριζόντια κλίμακα, διατηρώντας παράλληλα υψηλή συνέπεια και πολύ υψηλό SLA. Αν και αυτοί οι ισχυρισμοί είναι, σε κάθε περίπτωση, εξαιρετικά δύσκολο να επιτευχθούν, στόχος μας δεν ήταν να τους διαψεύσουμε. Αντίθετα, ας εστιάσουμε σε άλλα πράγματα που ενδιαφέρουν τους περισσότερους χρήστες της βάσης δεδομένων: ισοτιμία και χρηστικότητα.
Αξιολογήσαμε το Cloud Spanner ως αντικατάσταση του Sharded MySQL
Το Google Cloud SQL και το Amazon AWS RDS, δύο από τις πιο δημοφιλείς βάσεις δεδομένων OLTP στην αγορά cloud, διαθέτουν ένα πολύ μεγάλο σύνολο χαρακτηριστικών. Ωστόσο, για να κλιμακώσετε αυτές τις βάσεις δεδομένων πέρα από το μέγεθος ενός μεμονωμένου κόμβου, πρέπει να πραγματοποιήσετε διαχωρισμό εφαρμογών. Αυτή η προσέγγιση δημιουργεί πρόσθετη πολυπλοκότητα τόσο για τις εφαρμογές όσο και για τη διαχείριση. Εξετάσαμε πώς το Spanner ταιριάζει στο σενάριο του συνδυασμού πολλών θραυσμάτων σε ένα στιγμιότυπο και ποια χαρακτηριστικά (εάν υπάρχουν) μπορεί να πρέπει να θυσιαστούν.
Υποστήριξη για SQL, DML και DDL, καθώς και για τη σύνδεση και τις βιβλιοθήκες;
Αρχικά, όταν ξεκινάτε με οποιαδήποτε βάση δεδομένων, πρέπει να δημιουργήσετε ένα μοντέλο δεδομένων. Εάν πιστεύετε ότι μπορείτε να συνδέσετε το JDBC Spanner στο αγαπημένο σας εργαλείο SQL, θα διαπιστώσετε ότι μπορείτε να υποβάλετε ερωτήματα στα δεδομένα σας με αυτό, αλλά δεν μπορείτε να το χρησιμοποιήσετε για να δημιουργήσετε έναν πίνακα ή να ενημερώσετε (DDL) ή οποιαδήποτε εισαγωγή/ενημέρωση/διαγραφή λειτουργίες (DML). Το επίσημο JDBC της Google δεν υποστηρίζει ούτε ένα.
"Τα προγράμματα οδήγησης δεν υποστηρίζουν προς το παρόν δηλώσεις DML ή DDL."
Τεκμηρίωση κλειδιού
Η κατάσταση δεν είναι καλύτερη με την κονσόλα GCP - μπορείτε να στείλετε μόνο ερωτήματα SELECT. Ευτυχώς υπάρχει ένα πρόγραμμα οδήγησης JDBC με υποστήριξη DML και DDL από την κοινότητα, συμπεριλαμβανομένων των συναλλαγών . Αν και αυτό το πρόγραμμα οδήγησης είναι εξαιρετικά χρήσιμο, η απουσία του προγράμματος οδήγησης JDBC της Google προκαλεί έκπληξη. Ευτυχώς, η Google προσφέρει αρκετά ευρεία υποστήριξη βιβλιοθήκης πελατών (με βάση το gRPC): C#, Go, Java, node.js, PHP, Python και Ruby.
Η σχεδόν υποχρεωτική χρήση των προσαρμοσμένων API του Cloud Spanner (λόγω της έλλειψης DDL και DML στο JDBC) έχει ως αποτέλεσμα ορισμένους περιορισμούς για σχετικούς τομείς κώδικα, όπως η συγκέντρωση συνδέσεων ή τα πλαίσια σύνδεσης βάσεων δεδομένων (όπως το Spring MVC). Γενικά, όταν χρησιμοποιείτε το JDBC, είστε ελεύθεροι να επιλέξετε το αγαπημένο σας pool σύνδεσης (π.χ. HikariCP, DBCP, C3PO, κ.λπ.) που είναι ελεγμένο και λειτουργεί καλά. Στην περίπτωση των προσαρμοσμένων API του Spanner, πρέπει να βασιζόμαστε σε πλαίσια/δεσμευτικές/συνεδριακές ομάδες που έχουμε δημιουργήσει μόνοι μας.
Η σχεδίαση προσανατολισμένη στο πρωτεύον κλειδί (PC) επιτρέπει στο Cloud Spanner να είναι πολύ γρήγορο κατά την πρόσβαση σε δεδομένα μέσω του υπολογιστή, αλλά επίσης εισάγει ορισμένα ζητήματα ερωτημάτων.
- Δεν μπορείτε να ενημερώσετε την τιμή ενός πρωτεύοντος κλειδιού. Πρέπει πρώτα να διαγράψετε την αρχική καταχώριση υπολογιστή και να την εισαγάγετε ξανά με τη νέα τιμή. (Αυτό είναι παρόμοιο με άλλες βάσεις δεδομένων/μηχανές αποθήκευσης προσανατολισμένες στον υπολογιστή.)
- Οποιεσδήποτε δηλώσεις ΕΝΗΜΕΡΩΣΗ και ΔΙΑΓΡΑΦΗ πρέπει να προσδιορίζουν τον υπολογιστή στο WHERE, επομένως, δεν μπορεί να είναι άδειο DELETE όλες οι δηλώσεις - πρέπει πάντα να υπάρχει ένα δευτερεύον ερώτημα, για παράδειγμα: UPDATE xxx WHERE IN (SELECT id FROM table1)
- Έλλειψη επιλογής αυτόματης αύξησης ή κάτι παρόμοιο που καθορίζει τη σειρά για το πεδίο PC. Για να λειτουργήσει αυτό, πρέπει να δημιουργηθεί η αντίστοιχη τιμή στην πλευρά της εφαρμογής.
Δευτερογενείς δείκτες;
Το Google Cloud Spanner έχει ενσωματωμένη υποστήριξη για δευτερεύοντα ευρετήρια. Αυτό είναι ένα πολύ ωραίο χαρακτηριστικό που δεν υπάρχει πάντα σε άλλες τεχνολογίες. Το Apache Kudu δεν υποστηρίζει καθόλου δευτερεύοντα ευρετήρια και το Apache HBase δεν υποστηρίζει ευρετήρια απευθείας, αλλά μπορεί να τα προσθέσει μέσω του Apache Phoenix.
Τα ευρετήρια στο Kudu και στο HBase μπορούν να μοντελοποιηθούν ως ξεχωριστός πίνακας με διαφορετική σύνθεση πρωτευόντων κλειδιών, αλλά η ατομικότητα των λειτουργιών που εκτελούνται στον γονικό πίνακα και στους σχετικούς πίνακες ευρετηρίου πρέπει να εκτελούνται σε επίπεδο εφαρμογής και δεν είναι ασήμαντο να εφαρμοστεί σωστά.
Όπως αναφέρθηκε στην κριτική του Cloud Spanner, τα ευρετήρια του μπορεί να διαφέρουν από τα ευρετήρια MySQL. Επομένως, πρέπει να δοθεί ιδιαίτερη προσοχή στη δημιουργία ερωτημάτων και στη διαμόρφωση προφίλ για να διασφαλιστεί ότι χρησιμοποιείται το σωστό ευρετήριο όπου χρειάζεται.
Αναπαράσταση?
Ένα πολύ δημοφιλές και χρήσιμο αντικείμενο σε μια βάση δεδομένων είναι οι προβολές. Μπορούν να είναι χρήσιμα για μεγάλο αριθμό περιπτώσεων χρήσης. Τα δύο αγαπημένα μου είναι το επίπεδο λογικής αφαίρεσης και το επίπεδο ασφάλειας. Δυστυχώς το Cloud Spanner ΔΕΝ υποστηρίζει προβολές. Ωστόσο, αυτό μας περιορίζει μόνο εν μέρει, καθώς δεν υπάρχει ευκρίνεια σε επίπεδο στήλης για τα δικαιώματα πρόσβασης όπου οι προβολές μπορούν να είναι μια αποδεκτή λύση.
Ανατρέξτε στην τεκμηρίωση του Cloud Spanner για μια ενότητα που περιγράφει αναλυτικά τα όρια και τα όρια (), υπάρχει ένα συγκεκριμένα που μπορεί να είναι προβληματικό για ορισμένες εφαρμογές: Το Cloud Spanner out of the box έχει το πολύ 100 βάσεις δεδομένων ανά παρουσία. Προφανώς, αυτό μπορεί να είναι ένα σημαντικό εμπόδιο για μια βάση δεδομένων που έχει σχεδιαστεί να κλιμακώνεται σε περισσότερες από 100 βάσεις δεδομένων. Ευτυχώς, αφού μιλήσαμε με τον τεχνικό μας εκπρόσωπο της Google, ανακαλύψαμε ότι αυτό το όριο μπορεί να αυξηθεί σχεδόν σε οποιαδήποτε τιμή μέσω της Υποστήριξης Google.
Αναπτυξιακή υποστήριξη;
Το Cloud Spanner προσφέρει αρκετά αξιοπρεπή υποστήριξη γλώσσας προγραμματισμού για εργασία με το API του. Οι επίσημα υποστηριζόμενες βιβλιοθήκες βρίσκονται στην περιοχή των C#, Go, Java, node.js, PHP, Python και Ruby. Η τεκμηρίωση είναι αρκετά λεπτομερής, αλλά όπως και με άλλες τεχνολογίες αιχμής, η κοινότητα είναι αρκετά μικρή σε σύγκριση με τις πιο δημοφιλείς τεχνολογίες βάσεων δεδομένων, γεγονός που μπορεί να οδηγήσει σε περισσότερο χρόνο σε περιπτώσεις λιγότερο συνηθισμένων χρήσεων ή προβλημάτων.
Τι γίνεται λοιπόν με την υποστήριξη τοπικής ανάπτυξης;
Δεν βρήκαμε τρόπο να δημιουργήσουμε μια παρουσία του Cloud Spanner στις εγκαταστάσεις. Το πιο κοντινό που έχουμε είναι μια εικόνα Docker που είναι παρόμοιο κατ' αρχήν, αλλά πολύ διαφορετικό στην πράξη. Για παράδειγμα, το CockroachDB μπορεί να χρησιμοποιήσει το PostgreSQL JDBC. Δεδομένου ότι το περιβάλλον ανάπτυξης θα πρέπει να είναι όσο το δυνατόν πιο κοντά στο περιβάλλον παραγωγής, το Cloud Spanner δεν είναι ιδανικό επειδή πρέπει να βασιστείτε σε μια πλήρη παρουσία του Spanner. Για να εξοικονομήσετε κόστος, μπορείτε να επιλέξετε μια παρουσία περιοχής.
Υποστήριξη διοίκησης;
Η δημιουργία μιας παρουσίας Cloud Spanner είναι πολύ απλή. Απλώς πρέπει να επιλέξετε ανάμεσα στη δημιουργία μιας παρουσίας πολλών περιοχών ή μιας παρουσίας μιας περιοχής, να καθορίσετε τις περιοχές και τον αριθμό των κόμβων. Σε λιγότερο από ένα λεπτό, η παρουσία θα είναι σε λειτουργία.
Πολλές στοιχειώδεις μετρήσεις είναι απευθείας διαθέσιμες στη σελίδα του κλειδιού στην Κονσόλα Google. Πιο λεπτομερείς προβολές είναι διαθέσιμες μέσω του Stackdriver, όπου μπορείτε επίσης να ορίσετε όρια μετρήσεων και πολιτικές ειδοποιήσεων.
Πρόσβαση σε πόρους;
Η MySQL προσφέρει εκτεταμένες και πολύ αναλυτικές ρυθμίσεις αδειών χρήστη/ρόλων. Μπορείτε εύκολα να προσαρμόσετε την πρόσβαση σε έναν συγκεκριμένο πίνακα ή ακόμα και μόνο σε ένα υποσύνολο των στηλών του. Το Cloud Spanner χρησιμοποιεί το εργαλείο Google Identity & Access Management (IAM), το οποίο σας επιτρέπει μόνο να ορίσετε πολιτικές και δικαιώματα σε πολύ υψηλό επίπεδο. Η πιο λεπτομερής επιλογή είναι η άδεια σε επίπεδο βάσης δεδομένων, η οποία δεν ταιριάζει στις περισσότερες περιπτώσεις παραγωγής. Αυτός ο περιορισμός σάς αναγκάζει να προσθέσετε πρόσθετα μέτρα ασφαλείας στον κωδικό, την υποδομή ή και τα δύο για να αποτρέψετε τη μη εξουσιοδοτημένη χρήση των πόρων του Spanner.
Αντίγραφα ασφαλείας;
Για να το θέσω απλά, δεν υπάρχουν αντίγραφα ασφαλείας στο Cloud Spanner. Ενώ οι υψηλές απαιτήσεις SLA της Google μπορούν να διασφαλίσουν ότι δεν θα χάσετε δεδομένα λόγω αστοχιών υλικού ή βάσης δεδομένων, ανθρώπινου σφάλματος, ελαττωμάτων εφαρμογής κ.λπ. Όλοι γνωρίζουμε τον κανόνα: η υψηλή διαθεσιμότητα δεν υποκαθιστά μια στρατηγική έξυπνης δημιουργίας αντιγράφων ασφαλείας. Επί του παρόντος, ο μόνος τρόπος για να δημιουργήσετε αντίγραφα ασφαλείας των δεδομένων είναι να τα μεταφέρετε μέσω προγραμματισμού από τη βάση δεδομένων σε ένα ξεχωριστό περιβάλλον αποθήκευσης.
Ερώτηση απόδοσης;
Χρησιμοποιήσαμε το Yahoo! για να φορτώσουμε δεδομένα και να δοκιμάσουμε ερωτήματα. Σημείο αναφοράς παροχής υπηρεσιών Cloud. Ο παρακάτω πίνακας δείχνει τον φόρτο εργασίας B YCSB με αναλογία ανάγνωσης 95% προς 5% εγγραφής.
* Η δοκιμή φόρτωσης εκτελέστηκε σε n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB μνήμη) και το δείγμα δοκιμής δεν ήταν ποτέ το σημείο συμφόρησης στις δοκιμές.
** Ο μέγιστος αριθμός νημάτων σε μία παρουσία YCSB είναι 400. Συνολικά, έπρεπε να εκτελεστούν έξι παράλληλες περιπτώσεις δοκιμών YCSB για να ληφθούν συνολικά 2400 νήματα.
Εξετάζοντας τα αποτελέσματα αναφοράς, ιδίως τον συνδυασμό φόρτου CPU και TPS, μπορούμε να δούμε ξεκάθαρα ότι το Cloud Spanner κλιμακώνεται αρκετά καλά. Το μεγάλο φορτίο που δημιουργείται από μεγάλο αριθμό νημάτων αντισταθμίζεται από μεγάλο αριθμό κόμβων στο σύμπλεγμα Cloud Spanner. Ενώ η καθυστέρηση φαίνεται αρκετά υψηλή, ειδικά όταν εκτελείται σε 2400 νήματα, μπορεί να είναι απαραίτητο να επαναλάβετε τον έλεγχο με 6 μικρότερες περιπτώσεις της μηχανής υπολογισμού για να λάβετε πιο ακριβείς αριθμούς. Κάθε παρουσία θα εκτελεί μία δοκιμή YCSB αντί για μία μεγάλη παρουσία CE με 6 παράλληλες δοκιμές. Αυτό διευκολύνει τη διάκριση μεταξύ των καθυστερήσεων αιτήματος του Cloud Spanner και των καθυστερήσεων που προστίθενται από τη σύνδεση δικτύου μεταξύ του Cloud Spanner και της παρουσίας CE που εκτελεί τη δοκιμή.
Πώς λειτουργεί το Cloud Spanner ως OLAP;
Διαμέριση?
Η διαίρεση των δεδομένων σε φυσικά ή/και λογικά ανεξάρτητα τμήματα, που ονομάζονται partitions, είναι μια πολύ δημοφιλής έννοια που απαντάται στους περισσότερους κινητήρες OLAP. Τα διαμερίσματα μπορούν να βελτιώσουν σημαντικά την απόδοση των ερωτημάτων και τη συντηρησιμότητα της βάσης δεδομένων. Η περαιτέρω εμβάθυνση στη διαμέριση θα ήταν ένα ξεχωριστό άρθρο(α), οπότε ας αναφέρουμε απλώς τη σημασία της ύπαρξης ενός σχήματος διαμερισμάτων και υποδιαμερισμάτων. Η δυνατότητα διαχωρισμού δεδομένων σε διαμερίσματα και ακόμη περισσότερο σε υποδιαιρέσεις είναι το κλειδί για την απόδοση των αναλυτικών ερωτημάτων.
Το Cloud Spanner δεν υποστηρίζει κατατμήσεις από μόνες τους. Διαχωρίζει τα δεδομένα εσωτερικά στα λεγόμενα διαίρεση-s που βασίζονται σε εύρη πρωτευόντων κλειδιών. Η κατάτμηση γίνεται αυτόματα για να εξισορροπηθεί το φορτίο στο σύμπλεγμα Cloud Spanner. Ένα πολύ εύχρηστο χαρακτηριστικό του Cloud Spanner είναι ο διαχωρισμός του βασικού φορτίου ενός γονικού πίνακα (πίνακας που δεν παρεμβάλλεται με άλλο). Το κλειδί εντοπίζει αυτόματα εάν περιέχει διαίρεση δεδομένα που διαβάζονται πιο συχνά από τα δεδομένα σε άλλα διαίρεση-α, και μπορεί να αποφασίσει για έναν περαιτέρω χωρισμό. Έτσι, περισσότεροι κόμβοι μπορούν να εμπλακούν σε ένα αίτημα, το οποίο επίσης αυξάνει αποτελεσματικά την απόδοση.
Τα δεδομένα φορτώνονται?
Η μέθοδος Cloud Spanner για μαζικά δεδομένα είναι η ίδια με την κανονική μεταφόρτωση. Για μέγιστη απόδοση, πρέπει να ακολουθήσετε ορισμένες οδηγίες, όπως:
- Ταξινομήστε τα δεδομένα σας κατά κύριο κλειδί.
- Διαιρέστε τα με το 10*αριθμός κόμβων επιμέρους ενότητες.
- Δημιουργήστε ένα σύνολο εργασιών εργαζομένων που φορτώνουν δεδομένα παράλληλα.
Αυτή η φόρτωση δεδομένων χρησιμοποιεί όλους τους κόμβους Cloud Spanner.
Χρησιμοποιήσαμε το φόρτο εργασίας A YCSB για να δημιουργήσουμε ένα σύνολο δεδομένων σειρών 10 εκατομμυρίων.
* Η δοκιμή φόρτωσης εκτελέστηκε στον υπολογιστικό μηχανισμό n1-standard-32 (32 vCPU, 120 GB μνήμης) και το δείγμα δοκιμής δεν ήταν ποτέ το σημείο συμφόρησης στις δοκιμές.
** Δεν συνιστάται η ρύθμιση 1 κόμβου για οποιοδήποτε φόρτο εργασίας παραγωγής.
Όπως αναφέρθηκε παραπάνω, το Cloud Spanner επεξεργάζεται αυτόματα διαχωρισμούς ανάλογα με το φορτίο τους, έτσι τα αποτελέσματα βελτιώνονται μετά από πολλές διαδοχικές επαναλήψεις της δοκιμής. Τα αποτελέσματα που παρουσιάζονται εδώ είναι τα καλύτερα αποτελέσματα που έχουμε λάβει. Εξετάζοντας τους παραπάνω αριθμούς, μπορούμε να δούμε πώς κλιμακώνεται (καλά) το Cloud Spanner καθώς αυξάνεται ο αριθμός των κόμβων στο σύμπλεγμα. Οι αριθμοί που ξεχωρίζουν είναι εξαιρετικά χαμηλή μέση καθυστέρηση, η οποία έρχεται σε αντίθεση με τα αποτελέσματα από μικτό φόρτο εργασίας (95% ανάγνωση και 5% εγγραφή) όπως περιγράφεται στην παραπάνω ενότητα.
Απολέπιση?
Η αύξηση και η μείωση του αριθμού των κόμβων του Cloud Spanner είναι μια εργασία με ένα κλικ. Εάν θέλετε να φορτώσετε τα δεδομένα γρήγορα, μπορείτε να εξετάσετε το ενδεχόμενο να ενισχύσετε το στιγμιότυπο στο μέγιστο (στην περίπτωσή μας ήταν 25 κόμβοι στην περιοχή ΗΠΑ-Ανατολικής Αμερικής) και στη συνέχεια να μειώσετε τον αριθμό των κόμβων που είναι κατάλληλοι για το κανονικό σας φορτίο μετά από όλα τα δεδομένα στη βάση δεδομένων , έχοντας υπόψη το όριο των 2 TB/κόμβο.
Μας υπενθύμισε αυτό το όριο ακόμη και με μια πολύ μικρότερη βάση δεδομένων. Μετά από αρκετές δοκιμαστικές εκτελέσεις φόρτωσης, η βάση δεδομένων μας είχε μέγεθος περίπου 155 GB και όταν μειώθηκε σε μια παρουσία 1 κόμβου, λάβαμε το ακόλουθο σφάλμα:
Μπορέσαμε να μειώσουμε από 25 σε 2 περιπτώσεις, αλλά έχουμε κολλήσει σε δύο κόμβους.
Η αύξηση και η μείωση του αριθμού των κόμβων σε ένα σύμπλεγμα Cloud Spanner μπορεί να αυτοματοποιηθεί χρησιμοποιώντας το REST API. Αυτό μπορεί να είναι ιδιαίτερα χρήσιμο για τη μείωση του αυξημένου φορτίου στο σύστημα κατά τις ώρες αιχμής.
Απόδοση ερωτήματος OLAP;
Αρχικά σχεδιάζαμε να αφιερώσουμε σημαντικό χρόνο στην αξιολόγηση του Spanner σε αυτό το κομμάτι. Μετά από μερικές SELECT COUNT, συνειδητοποιήσαμε αμέσως ότι η δοκιμή θα ήταν σύντομη και ότι το Spanner ΔΕΝ θα ήταν η κατάλληλη μηχανή για το OLAP. Ανεξάρτητα από τον αριθμό των κόμβων στο σύμπλεγμα, η απλή επιλογή του αριθμού των σειρών σε έναν πίνακα σειρών 10M χρειάστηκε 55 έως 60 δευτερόλεπτα. Επίσης, οποιοδήποτε ερώτημα που απαιτούσε περισσότερη μνήμη για την αποθήκευση των ενδιάμεσων αποτελεσμάτων απέτυχε με σφάλμα OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Μερικοί αριθμοί για ερωτήματα TPC-H μπορούν να βρεθούν στο άρθρο του Todd Lipcon , διαφάνειες 42 και 43. Αυτοί οι αριθμοί είναι συνεπείς με τα δικά μας αποτελέσματα (δυστυχώς).
4. Τα ευρήματά μας
Δεδομένης της τρέχουσας κατάστασης των δυνατοτήτων του Cloud Spanner, είναι δύσκολο να το δούμε ως απλή αντικατάσταση μιας υπάρχουσας λύσης OLTP, ειδικά όταν οι ανάγκες σας ξεπερνούν. Θα πρέπει να αφιερωθεί σημαντικός χρόνος για την οικοδόμηση μιας λύσης γύρω από τις αδυναμίες του Cloud Spanner.
Όταν ξεκινήσαμε να αξιολογούμε το Cloud Spanner, περιμέναμε ότι οι λειτουργίες διαχείρισής του θα ήταν στο ίδιο επίπεδο ή τουλάχιστον όχι πολύ μακριά από άλλες λύσεις Google SQL. Αλλά μας εξέπληξε η παντελής έλλειψη αντιγράφων ασφαλείας και ο πολύ περιορισμένος έλεγχος πρόσβασης στους πόρους. Για να μην αναφέρουμε καμία προβολή, κανένα περιβάλλον τοπικής ανάπτυξης, μη υποστηριζόμενες ακολουθίες, JDBC χωρίς υποστήριξη DML και DDL και ούτω καθεξής.
Λοιπόν, πού να πάει κάποιος που χρειάζεται να κλιμακώσει μια βάση δεδομένων συναλλαγών; Δεν φαίνεται να υπάρχει ακόμη μία λύση στην αγορά που να ταιριάζει σε όλες τις περιπτώσεις χρήσης. Υπάρχουν πολλές λύσεις κλειστού και ανοιχτού κώδικα (μερικές από τις οποίες αναφέρονται σε αυτό το άρθρο), η καθεμία με τα δικά της πλεονεκτήματα και αδυναμίες, αλλά καμία από αυτές δεν προσφέρει SaaS με SLA 99,999% και υψηλό βαθμό συνέπειας. Εάν ένα υψηλό SLA είναι ο πρωταρχικός σας στόχος και δεν έχετε την τάση να δημιουργήσετε τη δική σας λύση για πολλά σύννεφα, το Cloud Spanner μπορεί να είναι η λύση που αναζητάτε. Αλλά θα πρέπει να γνωρίζετε όλους τους περιορισμούς του.
Για να είμαστε δίκαιοι, το Cloud Spanner κυκλοφόρησε στο κοινό μόνο την άνοιξη του 2017, επομένως είναι λογικό να περιμένουμε ότι κάποια από τα τρέχοντα ελαττώματα του μπορεί τελικά να εξαφανιστούν (ελπίζουμε) και όταν το κάνει, θα μπορούσε να αλλάξει το παιχνίδι. Εξάλλου, το Cloud Spanner δεν είναι απλώς ένα δευτερεύον έργο για την Google. Η Google το χρησιμοποιεί ως βάση για άλλα προϊόντα Google. Και όταν η Google αντικατέστησε πρόσφατα το Megastore στο Google Cloud Storage με το Cloud Spanner, επέτρεψε στο Google Cloud Storage να γίνει εξαιρετικά συνεπές για λίστες αντικειμένων σε παγκόσμια κλίμακα (κάτι που εξακολουθεί να μην ισχύει για ).
Οπότε, υπάρχει ακόμα ελπίδα... ελπίζουμε.
Αυτό είναι όλο. Όπως και ο συγγραφέας του άρθρου, συνεχίζουμε να ελπίζουμε, αλλά τι πιστεύετε για αυτό; Γράψτε στα σχόλια
Καλούμε όλους να επισκεφτούν το δικό μας στο οποίο θα σας πούμε αναλυτικά για το μάθημα από το OTUS.
Πηγή: www.habr.com