«Αυτό είναι απαραίτητο», είπε δυνατά, χωρίς να απευθυνθεί σε κανέναν. - Αυτό είναι απαραίτητο! Αυτό ακριβώς λέει: το κύριο καθήκον μιας εταιρείας είναι να αποκομίζει κέρδος προς το συμφέρον των μετόχων. Λοιπόν, σκεφτείτε το! Δεν φοβούνται τίποτα!
Yuliy Dubov, «Μικρότερο κακό»
Έχοντας δει έναν τέτοιο τίτλο, μάλλον έχετε ήδη αποφασίσει ότι το άρθρο είναι είτε βλακεία είτε πρόκληση. Αλλά μην βιαστείτε να βγάλετε συμπεράσματα: οι υπάλληλοι μεγάλων εταιρειών, ειδικά εταιρειών με κρατική συμμετοχή, αρκετά συχνά πρέπει να συγκρίνουν διαφορετικές πλατφόρμες, συμπεριλαμβανομένων τελείως διαφορετικών - για παράδειγμα, αυτές στον τίτλο.
Φυσικά, κανείς δεν συγκρίνει τα DBMS με αυτόν τον τρόπο, γιατί τα δυνατά και τα αδύνατα σημεία τους είναι γνωστά. Κατά κανόνα, οι πλατφόρμες που επιλύουν κάποιο πρόβλημα εφαρμογής υπόκεινται σε σύγκριση. Στο άρθρο θα δείξω τη μεθοδολογία που χρησιμοποιείται σε αυτήν την περίπτωση, χρησιμοποιώντας το παράδειγμα των βάσεων δεδομένων ως θέμα που είναι οικείο στους αναγνώστες του Habr από πρώτο χέρι. Ετσι,
Κίνητρο
Όταν ξεκινάτε ένα εκπαιδευτικό έργο ή ένα έργο χόμπι, τα κίνητρα για την επιλογή μιας πλατφόρμας μπορεί να είναι πολύ διαφορετικά: «αυτή την πλατφόρμα γνωρίζω καλύτερα», «με ενδιαφέρει να την κατανοήσω», «εδώ είναι η καλύτερη τεκμηρίωση». Στην περίπτωση μιας εμπορικής εταιρείας, το κριτήριο επιλογής είναι το ίδιο: πόσα θα πρέπει να πληρώσω και τι θα πάρω για αυτά τα χρήματα.
Φυσικά, θέλετε να πληρώσετε λιγότερα και να πάρετε περισσότερα. Ωστόσο, πρέπει να αποφασίσετε τι είναι πιο σημαντικό - να πληρώσετε λιγότερα ή να λάβετε περισσότερα, και να ορίσετε ένα βάρος σε κάθε κόμβο. Ας υποθέσουμε ότι μια λύση υψηλής ποιότητας είναι πιο σημαντική για εμάς από μια φθηνή, και αποδίδουμε βάρος 40% στον κόμβο "Κόστος" και 60% στον κόμβο "Ευκαιρίες".
Στις μεγάλες εταιρείες, συνήθως συμβαίνει το αντίθετο - το βάρος κόστους δεν πέφτει κάτω από 50%, και ίσως περισσότερο από 60%. Στο παράδειγμα του μοντέλου, το μόνο που είναι σημαντικό είναι ότι το συνολικό βάρος των θυγατρικών κόμβων οποιουδήποτε γονικού κόμβου πρέπει να είναι 100%.
Συνθήκες αποκοπής
Ιστοσελίδα Υπάρχουν περίπου 500 γνωστά συστήματα διαχείρισης βάσεων δεδομένων. Φυσικά, εάν επιλέξετε μια πλατφόρμα-στόχο από τόσες πολλές επιλογές, μπορεί να καταλήξετε με ένα άρθρο κριτικής, αλλά όχι ένα εμπορικό έργο. Προκειμένου να μειωθεί ο χώρος επιλογής, διαμορφώνονται κριτήρια αποκοπής και εάν η πλατφόρμα δεν πληροί αυτά τα κριτήρια, τότε δεν λαμβάνεται υπόψη.
Τα κριτήρια αποκοπής μπορεί να σχετίζονται με τεχνολογικά χαρακτηριστικά, για παράδειγμα:
- Εγγυήσεις ACID.
- μοντέλο σχεσιακών δεδομένων·
- Υποστήριξη γλώσσας SQL (σημειώστε ότι αυτό δεν είναι το ίδιο με το "σχεσιακό μοντέλο").
- δυνατότητα οριζόντιας κλιμάκωσης.
Μπορεί να υπάρχουν γενικά κριτήρια:
- διαθεσιμότητα εμπορικής υποστήριξης στη Ρωσία·
- ανοιχτή πηγή;
- διαθεσιμότητα της πλατφόρμας στο Μητρώο του Υπουργείου Τηλεπικοινωνιών και Μαζικών Επικοινωνιών.
- παρουσία της πλατφόρμας σε κάποια βαθμολογία (για παράδειγμα, στην πρώτη εκατοντάδα της βαθμολογίας db-engines.com).
- την παρουσία ειδικών στην αγορά (για παράδειγμα, με βάση τα αποτελέσματα αναζήτησης του ονόματος της πλατφόρμας σε ένα βιογραφικό στον ιστότοπο hh.ru).
Σε τελική ανάλυση, μπορεί να υπάρχουν κριτήρια ειδικά για την επιχείρηση:
- διαθεσιμότητα ειδικών στο προσωπικό·
- συμβατότητα με σύστημα παρακολούθησης X ή εφεδρικό σύστημα Υ, στο οποίο βασίζεται όλη η υποστήριξη...
Το πιο σημαντικό είναι ότι υπάρχει μια λίστα κριτηρίων αποκοπής. Διαφορετικά, θα υπάρχει σίγουρα κάποιος ειδικός (ή «ειδικός») που θα χαίρει ιδιαίτερης εμπιστοσύνης από τη διοίκηση που θα πει «γιατί δεν επιλέξατε την πλατφόρμα Z, ξέρω ότι είναι η καλύτερη».
Εκτίμηση κόστους
Το κόστος της λύσης προφανώς αποτελείται από το κόστος των αδειών, το κόστος υποστήριξης και το κόστος του εξοπλισμού.
Εάν τα συστήματα είναι περίπου της ίδιας κατηγορίας (για παράδειγμα, Microsoft SQL Server και PostgreSQL), τότε για λόγους απλότητας μπορούμε να υποθέσουμε ότι η ποσότητα του εξοπλισμού και για τις δύο λύσεις θα είναι περίπου η ίδια. Αυτό θα σας επιτρέψει να μην αξιολογήσετε τον εξοπλισμό, εξοικονομώντας έτσι πολύ χρόνο και προσπάθεια. Εάν πρέπει να συγκρίνετε εντελώς διαφορετικά συστήματα (ας πούμε, Oracle εναντίον Redis), τότε είναι προφανές ότι για μια σωστή αξιολόγηση είναι απαραίτητο να κάνετε sizing (υπολογισμός της ποσότητας του εξοπλισμού). Το μέγεθος ενός ανύπαρκτου συστήματος είναι ένα πολύ άχαρο έργο, επομένως εξακολουθούν να προσπαθούν να αποφύγουν τέτοιες συγκρίσεις. Αυτό είναι εύκολο να γίνει: στις συνθήκες αποκοπής, εγγράφεται μηδενική απώλεια δεδομένων και ένα σχεσιακό μοντέλο ή αντίστροφα - φορτίο 50 χιλιάδων συναλλαγών ανά δευτερόλεπτο.
Για να αξιολογήσετε τις άδειες, αρκεί να ζητήσετε από τον πωλητή ή τους συνεργάτες του το κόστος μιας άδειας για έναν σταθερό αριθμό πυρήνων και την υποστήριξη για μια σταθερή περίοδο. Κατά κανόνα, οι εταιρείες έχουν ήδη ισχυρές σχέσεις με προμηθευτές λογισμικού και εάν το τμήμα λειτουργιών της βάσης δεδομένων δεν μπορεί να απαντήσει από μόνο του στην ερώτηση κόστους, τότε αρκεί ένα γράμμα για να ληφθούν αυτές οι πληροφορίες.
Διαφορετικοί προμηθευτές μπορεί να έχουν διαφορετικές μετρήσεις αδειοδότησης: κατά αριθμό πυρήνων, όγκο δεδομένων ή αριθμό κόμβων. Η βάση αναμονής μπορεί να είναι δωρεάν ή μπορεί να αδειοδοτηθεί με τον ίδιο τρόπο όπως η κύρια. Εάν εντοπιστούν διαφορές στις μετρήσεις, θα πρέπει να περιγράψετε λεπτομερώς το μοντέλο βάσης και να υπολογίσετε το κόστος των αδειών για το περίπτερο.
Ένα σημαντικό σημείο για μια σωστή σύγκριση είναι οι ίδιες συνθήκες υποστήριξης. Για παράδειγμα, η υποστήριξη της Oracle κοστίζει το 22% της τιμής της άδειας χρήσης ανά έτος, αλλά δεν χρειάζεται να πληρώσετε για την υποστήριξη PostgreSQL. Είναι σωστό να συγκρίνουμε έτσι; Όχι, γιατί ένα σφάλμα που δεν μπορεί να διορθωθεί μόνο του έχει εντελώς διαφορετικές συνέπειες: στην πρώτη περίπτωση, οι ειδικοί υποστήριξης θα σας βοηθήσουν γρήγορα να το διορθώσετε, αλλά στη δεύτερη περίπτωση, υπάρχει κίνδυνος καθυστέρησης του έργου ή διακοπής λειτουργίας του τελικού σύστημα για αόριστο χρονικό διάστημα.
Μπορείτε να εξισορροπήσετε τις συνθήκες υπολογισμού με τρεις τρόπους:
- Χρησιμοποιήστε το Oracle χωρίς υποστήριξη (στην πραγματικότητα αυτό δεν συμβαίνει).
- Αγοράστε υποστήριξη για PostgreSQL - για παράδειγμα, από την Postgres Professional.
- Λάβετε υπόψη τους κινδύνους που συνδέονται με την έλλειψη υποστήριξης.
Για παράδειγμα, ένας υπολογισμός κινδύνου μπορεί να μοιάζει με αυτό: σε περίπτωση μοιραίας αποτυχίας της βάσης δεδομένων, ο χρόνος διακοπής λειτουργίας του συστήματος θα είναι 1 εργάσιμη ημέρα. Το προβλεπόμενο κέρδος από τη χρήση του συστήματος είναι 40 δισεκατομμύρια MNT ετησίως, το ποσοστό ατυχημάτων εκτιμάται ότι είναι 1/400, επομένως ο κίνδυνος έλλειψης υποστήριξης υπολογίζεται σε περίπου 100 εκατομμύρια MNT ετησίως. Προφανώς, το «προγραμματισμένο κέρδος» και η «εκτιμώμενη συχνότητα ατυχημάτων» είναι εικονικές αξίες, αλλά είναι πολύ καλύτερο να έχουμε ένα τέτοιο μοντέλο παρά να μην έχουμε.
Στην πραγματικότητα, το σύστημα μπορεί να είναι πολύ σημαντικό για να είναι απαράδεκτο το κόστος φήμης του μακροπρόθεσμου χρόνου διακοπής λειτουργίας, επομένως θα απαιτείται υποστήριξη. Εάν επιτρέπεται η διακοπή λειτουργίας, τότε η άρνηση υποστήριξης μπορεί μερικές φορές να είναι ένας καλός τρόπος εξοικονόμησης χρημάτων.
Ας υποθέσουμε ότι μετά από όλους τους υπολογισμούς, το κόστος λειτουργίας της πλατφόρμας Α για 5 χρόνια αποδεικνύεται ότι είναι 800 εκατομμύρια MNT, το κόστος λειτουργίας της πλατφόρμας Β είναι 650 εκατομμύρια MNT και το κόστος λειτουργίας της πλατφόρμας C είναι 600 εκατομμύρια MNT. Η πλατφόρμα C, ως νικητής, λαμβάνει έναν πλήρη βαθμό για την τιμή, ενώ οι πλατφόρμες Α και Β λαμβάνουν λίγο λιγότερο, ανάλογα με το πόσες φορές είναι ακριβότερες. Σε αυτήν την περίπτωση - 0.75 και 0.92 μονάδες, αντίστοιχα.
Αξιολόγηση ευκαιριών
Η αξιολόγηση των ευκαιριών χωρίζεται σε πολλές ομάδες, ο αριθμός των οποίων περιορίζεται μόνο από τη φαντασία του ατόμου που κάνει την αξιολόγηση. Η βέλτιστη επιλογή φαίνεται να είναι ο διαχωρισμός των δυνατοτήτων σε ομάδες που θα χρησιμοποιήσουν αυτές τις δυνατότητες. στο παράδειγμά μας, αυτοί είναι προγραμματιστές, διαχειριστές και υπεύθυνοι ασφάλειας πληροφοριών. Ας υποθέσουμε ότι τα βάρη αυτών των συναρτήσεων κατανέμονται ως 40:40:20.
Οι λειτουργίες ανάπτυξης περιλαμβάνουν:
- ευκολία χειρισμού δεδομένων.
- απολέπιση;
- παρουσία δευτερευόντων δεικτών.
Η λίστα των κριτηρίων, καθώς και τα βάρη τους, είναι πολύ υποκειμενικά. Ακόμη και όταν λύνετε το ίδιο πρόβλημα, αυτές οι λίστες, τα βάρη των στοιχείων και οι απαντήσεις θα διαφέρουν σημαντικά ανάλογα με τη σύνθεση της ομάδας σας. Για παράδειγμα, το Facebook χρησιμοποιεί MySQL για την αποθήκευση δεδομένων και το Instagram είναι χτισμένο στην Cassandra. Είναι απίθανο οι προγραμματιστές αυτών των εφαρμογών να συμπλήρωσαν τέτοιους πίνακες. Μπορούμε μόνο να μαντέψουμε ότι ο Mark Zuckerberg επέλεξε ένα πλήρες σχεσιακό μοντέλο, πληρώνοντάς το με την ανάγκη εφαρμοσμένου διαμοιρασμού, ενώ ο Kevin Systrom κατασκεύασε την κλίμακα χρησιμοποιώντας την πλατφόρμα, θυσιάζοντας την ευκολία πρόσβασης στα δεδομένα.
Οι λειτουργίες διαχείρισης περιλαμβάνουν:
- δυνατότητες του συστήματος δημιουργίας αντιγράφων ασφαλείας.
- ευκολία παρακολούθησης?
- ευκολία διαχείρισης χωρητικότητας - δίσκοι και κόμβοι.
- δυνατότητες αναπαραγωγής δεδομένων.
Σημειώστε ότι οι ερωτήσεις πρέπει να διατυπώνονται με ποσοτικό τρόπο. Μπορείτε ακόμη να συμφωνήσετε για τον τρόπο αξιολόγησης μιας συγκεκριμένης συνάρτησης. Ας προσπαθήσουμε, για παράδειγμα, να αξιολογήσουμε τα εργαλεία δημιουργίας αντιγράφων ασφαλείας χρησιμοποιώντας το παράδειγμα εργαλείων που παρέχονται με το Oracle DBMS:
Εργαλείο
Σχόλιο
Εκτίμηση
imp/exp
Μεταφόρτωση και φόρτωση δεδομένων
0.1
δημιουργία αντιγράφων ασφαλείας έναρξης/λήξης
Αντιγραφή αρχείων
0.3
RMAN
Δυνατότητα αυξητικής αντιγραφής
0.7
ZDLRA
Μόνο σταδιακή αντιγραφή, ταχύτερη ανάκτηση στο σημείο
1.0
Εάν δεν υπάρχουν σαφή κριτήρια αξιολόγησης, είναι λογικό να ζητήσετε από πολλούς ειδικούς να δώσουν βαθμολογίες και στη συνέχεια να τους δώσετε μέσο όρο.
Τέλος, παραθέτουμε απλώς τις λειτουργίες ασφάλειας πληροφοριών:
- Διαθεσιμότητα πολιτικών διαχείρισης κωδικών πρόσβασης·
- τη δυνατότητα σύνδεσης εξωτερικών εργαλείων ελέγχου ταυτότητας (LDAP, Kerberos).
- πρότυπο πρόσβασης·
- δυνατότητες ελέγχου·
- κρυπτογράφηση δεδομένων στο δίσκο.
- κρυπτογράφηση κατά τη μετάδοση μέσω του δικτύου (TLS)·
- προστασία δεδομένων από τον διαχειριστή.
Δοκιμή απόδοσης
Ξεχωριστά, θα ήθελα να προειδοποιήσω να μην χρησιμοποιούνται ως επιχειρήματα τα αποτελέσματα τυχόν δοκιμών φόρτωσης που δεν έγιναν από εσάς.
Πρώτον, η δομή δεδομένων και το προφίλ φόρτωσης των εφαρμογών που ελέγχονται ενδέχεται να διαφέρουν σημαντικά από το πρόβλημα που πρόκειται να λύσετε. Πριν από περίπου 10-15 χρόνια, οι προμηθευτές βάσεων δεδομένων αγαπούσαν να επιδεικνύουν τα αποτελέσματα που επιτεύχθηκαν στις δοκιμές TPC, αλλά τώρα, όπως φαίνεται, κανείς δεν παίρνει αυτά τα αποτελέσματα στα σοβαρά.
Δεύτερον, η απόδοση του συστήματος εξαρτάται σε μεγάλο βαθμό από την πλατφόρμα για την οποία γράφτηκε αρχικά ο κώδικας και από τον εξοπλισμό που πραγματοποιήθηκε η δοκιμή. Έχω δει πολλές δοκιμές όπου η Oracle συγκρίθηκε με την PostgreSQL. Τα αποτελέσματα κυμαίνονται από την άνευ όρων υπεροχή ενός συστήματος έως την εξίσου άνευ όρων υπεροχή ενός άλλου.
Και τέλος, τρίτον, δεν ξέρεις τίποτα για το ποιος έκανε το τεστ. Και τα δύο προσόντα είναι σημαντικά, επηρεάζοντας την ποιότητα της ρύθμισης του λειτουργικού συστήματος και της πλατφόρμας, καθώς και το κίνητρο, το οποίο επηρεάζει τα αποτελέσματα των δοκιμών περισσότερο από όλους τους άλλους παράγοντες μαζί.
Εάν η απόδοση είναι κρίσιμος παράγοντας, πραγματοποιήστε τη δοκιμή μόνοι σας, κατά προτίμηση με τη βοήθεια των ατόμων που θα διαμορφώσουν και θα συντηρήσουν το σύστημα παραγωγής.
Αποτέλεσμα
Τέλος, το αποτέλεσμα όλης της εργασίας που έχει γίνει θα πρέπει να είναι ένα υπολογιστικό φύλλο όπου όλες οι εκτιμήσεις συνδυάζονται, πολλαπλασιάζονται και συνοψίζονται:
Όπως καταλαβαίνετε, αλλάζοντας τις κλίμακες και προσαρμόζοντας τις βαθμολογίες μπορείτε να επιτύχετε οποιοδήποτε επιθυμητό αποτέλεσμα, αλλά αυτό είναι μια εντελώς διαφορετική ιστορία...
Πηγή: www.habr.com