Ήταν γενικά η MongoDB η σωστή επιλογή;

Το ανακάλυψα πρόσφατα Η Red Hat αφαιρεί την υποστήριξη MongoDB από το Satellite (ας πούμε, λόγω αλλαγών άδειας). Με έκανε να σκεφτώ ότι τα τελευταία χρόνια έχω δει ένα σωρό άρθρα σχετικά με το πόσο τρομερό είναι το MongoDB και ότι κανείς δεν πρέπει ποτέ να το χρησιμοποιήσει. Αλλά κατά τη διάρκεια αυτής της περιόδου, το MongoDB έχει γίνει ένα πολύ πιο ώριμο προϊόν. Τι συνέβη? Όλο το μίσος οφείλεται πραγματικά σε λάθη στην αρχή του μάρκετινγκ του νέου DBMS; Ή μήπως οι άνθρωποι χρησιμοποιούν απλώς το MongoDB στο λάθος μέρος;

Εάν ξαφνικά αισθάνεστε ότι υπερασπίζομαι το MongoDB, διαβάστε αποποίηση ευθυνών στο τέλος του άρθρου.

Νέα τάση

Είμαι στη βιομηχανία λογισμικού για περισσότερα χρόνια από ό,τι είναι δίκαιο να πούμε, αλλά παρόλα αυτά είμαι μόνο μέρος των τάσεων που έπληξαν τον κλάδο μας. Έχω δει την άνοδο των 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… η λίστα είναι ατελείωτη. Κάθε χρόνο υπάρχουν νέες τάσεις. Ορισμένα εξασθενούν γρήγορα, ενώ άλλα αλλάζουν ριζικά τον τρόπο ανάπτυξης λογισμικού.

Γύρω από κάθε νέα τάση, δημιουργείται ένας ορισμένος γενικός ενθουσιασμός: οι άνθρωποι είτε πηδούν οι ίδιοι στη βάρκα, είτε βλέπουν τον θόρυβο που δημιουργούν οι άλλοι - και ακολουθούν το πλήθος. Αυτή η διαδικασία έχει κωδικοποιηθεί από την Gartner στο Κύκλος Hype. Αν και συζητήσιμο, αυτό το γράφημα περιγράφει χονδρικά τι συμβαίνει με τις τεχνολογίες προτού τελικά γίνουν χρήσιμες για χρήση.

Αλλά από καιρό σε καιρό υπάρχει (ή υπάρχει μια δεύτερη έλευση, όπως στην προκειμένη περίπτωση) μια νέα καινοτομία, που οδηγείται από μία μόνο συγκεκριμένη εφαρμογή της. Στην περίπτωση του NoSQL, η διαφημιστική εκστρατεία προκλήθηκε σε μεγάλο βαθμό από την εμφάνιση και τη μετεωρική άνοδο του MongoDB. Η MongoDB δεν ξεκίνησε αυτή την τάση: στην πραγματικότητα, μεγάλες εταιρείες Διαδικτύου άρχισαν να αντιμετωπίζουν προβλήματα με την επεξεργασία μεγάλων ποσοτήτων δεδομένων, γεγονός που οδήγησε στην επιστροφή μη σχεσιακών βάσεων δεδομένων. Το γενικό κίνημα ξεκίνησε με έργα όπως το Bigtable της Google και το Cassandra του Facebook, αλλά ήταν το MongoDB που έγινε η πιο διάσημη και προσβάσιμη εφαρμογή της βάσης δεδομένων NoSQL στην οποία είχαν πρόσβαση οι περισσότεροι προγραμματιστές.

Σημείωση: Ίσως πιστεύετε ότι μπερδεύω τις βάσεις δεδομένων εγγράφων με βάσεις δεδομένων στηλών, καταστήματα κλειδιών/τιμών ή οποιονδήποτε από τους πολλούς άλλους τύπους αποθήκευσης δεδομένων που εμπίπτουν στον γενικό ορισμό του NoSQL. Και έχεις δίκιο. Όμως εκείνη την εποχή επικρατούσε χάος. Όλοι έχουν εμμονή με το NoSQL, έχει γίνει τα πάντα απολύτως απαραίτητο, αν και πολλοί δεν είδαν τις διαφορές στις διαφορετικές τεχνολογίες. Για πολλούς, το MongoDB έχει γίνει συνώνυμος NoSQL.

Και οι προγραμματιστές το πήδηξαν. Η ιδέα μιας βάσης δεδομένων χωρίς σχήμα που κλιμακώνεται μαγικά για να λύσει οποιοδήποτε πρόβλημα ήταν αρκετά δελεαστική. Γύρω στο 2014, φαινόταν ότι οπουδήποτε χρησιμοποιήθηκε μια σχεσιακή βάση δεδομένων όπως MySQL, Postgres ή SQL Server πριν από ένα χρόνο, οι βάσεις δεδομένων MongoDB αναπτύσσονταν. Όταν ρωτήθηκε γιατί, θα μπορούσατε να λάβετε απαντήσεις από το κοινότυπο "αυτή είναι η κλίμακα του Ιστού" έως το πιο στοχαστικό "τα δεδομένα μου είναι πολύ χαλαρά δομημένα και ταιριάζουν καλά σε μια βάση δεδομένων χωρίς σχήμα".

Είναι σημαντικό να θυμάστε ότι το MongoDB, και γενικά οι βάσεις δεδομένων εγγράφων, επιλύουν ορισμένα προβλήματα με τις παραδοσιακές σχεσιακές βάσεις δεδομένων:

  • Αυστηρό σχέδιο: με μια σχεσιακή βάση δεδομένων, εάν έχετε δημιουργήσει δυναμικά δεδομένα, αναγκάζεστε είτε να δημιουργήσετε μια δέσμη τυχαίων "διαφορετικών" στηλών δεδομένων, να σπρώξετε κυψέλες δεδομένων εκεί ή να χρησιμοποιήσετε μια διαμόρφωση Επέκταση EAV… όλα αυτά έχουν σημαντικά μειονεκτήματα.
  • Δυσκολία κλιμάκωσης: Εάν υπάρχουν τόσα πολλά δεδομένα που δεν χωρούν σε έναν διακομιστή, η MongoDB προσέφερε μηχανισμούς που θα τους επιτρέψουν να κλιμακωθεί σε πολλαπλά μηχανήματα.
  • Σύνθετες τροποποιήσεις κυκλώματος: όχι μεταναστεύσεις! Σε μια σχεσιακή βάση δεδομένων, η αλλαγή της δομής της βάσης δεδομένων μπορεί να είναι τεράστιο πρόβλημα (ειδικά όταν υπάρχουν πολλά δεδομένα). Η MongoDB μπόρεσε να απλοποιήσει σημαντικά τη διαδικασία. Και το έκανε τόσο εύκολο που μπορείτε απλώς να ενημερώσετε το σχήμα εν κινήσει και να προχωρήσετε πολύ γρήγορα.
  • Γράψτε απόδοση: Η απόδοση του MongoDB ήταν καλή, ειδικά όταν ήταν σωστά συντονισμένη. Ακόμη και η εκτός συσκευασίας διαμόρφωση του MongoDB, για την οποία επικρίθηκε συχνά, έδειξε μερικά εντυπωσιακά στοιχεία απόδοσης.

Όλοι οι κίνδυνοι είναι πάνω σου

Τα πιθανά οφέλη του MongoDB ήταν τεράστια, ειδικά για ορισμένες κατηγορίες προβλημάτων. Εάν διαβάσετε την παραπάνω λίστα χωρίς να κατανοήσετε το πλαίσιο και να μην έχετε εμπειρία, τότε μπορεί να έχετε την εντύπωση ότι το MongoDB είναι πραγματικά ένα επαναστατικό DBMS. Το μόνο πρόβλημα ήταν ότι τα οφέλη που αναφέρονται παραπάνω συνοδεύονταν από ορισμένες επιφυλάξεις, μερικές από τις οποίες παρατίθενται παρακάτω.

Για να είμαστε δίκαιοι, κανείς στην 10gen/MongoDB Inc. δεν θα πω ότι τα ακόλουθα δεν είναι αλήθεια, πρόκειται απλώς για συμβιβασμούς.

  • Απώλεια συναλλαγώνΑ: Οι συναλλαγές αποτελούν βασικό χαρακτηριστικό πολλών σχεσιακών βάσεων δεδομένων (όχι όλων, αλλά των περισσότερων). Συναλλαγές σημαίνει ότι μπορείτε να εκτελέσετε πολλαπλές λειτουργίες ατομικά και μπορείτε να διασφαλίσετε ότι τα δεδομένα παραμένουν συνεπή. Φυσικά, με μια βάση δεδομένων NoSQL, η συναλλακτικότητα μπορεί να είναι μέσα σε ένα μόνο έγγραφο ή μπορείτε να χρησιμοποιήσετε δεσμεύσεις δύο φάσεων για να λάβετε σημασιολογία συναλλαγών. Αλλά θα πρέπει να εφαρμόσετε αυτή τη λειτουργικότητα μόνοι σας... που μπορεί να είναι μια δύσκολη και χρονοβόρα εργασία. Συχνά δεν αντιλαμβάνεστε το πρόβλημα έως ότου δείτε ότι τα δεδομένα στη βάση δεδομένων μετατρέπονται σε μη έγκυρες καταστάσεις, επειδή είναι αδύνατο να εγγυηθεί κανείς την ατομικότητα των λειτουργιών. Σημείωση: Πολλοί μου είπαν ότι οι συναλλαγές εισήχθησαν στο MongoDB 4.0 πέρυσι, αλλά με ορισμένους περιορισμούς. Το συμπέρασμα από το άρθρο παραμένει το ίδιο: αξιολογήστε πώς η τεχνολογία ταιριάζει στις ανάγκες σας.
  • Απώλεια σχεσιακής ακεραιότητας (ξένα κλειδιά): εάν τα δεδομένα σας έχουν σχέσεις, τότε θα πρέπει να τις εφαρμόσετε στην εφαρμογή. Έχοντας μια βάση δεδομένων που σέβεται αυτές τις σχέσεις θα χρειαστεί πολλή δουλειά από την εφαρμογή και επομένως από τους προγραμματιστές σας.
  • Αδυναμία εφαρμογής της δομής δεδομένων: Τα αυστηρά σχήματα μπορεί μερικές φορές να είναι μεγάλο πρόβλημα, αλλά είναι επίσης ένας ισχυρός μηχανισμός για καλή δόμηση δεδομένων εάν χρησιμοποιηθούν με σύνεση. Οι βάσεις δεδομένων εγγράφων όπως η MongoDB παρέχουν απίστευτη ευελιξία σχήματος, αλλά αυτή η ευελιξία αφαιρεί την ευθύνη διατήρησης καθαρών δεδομένων. Εάν δεν τα φροντίσετε, θα καταλήξετε να γράψετε πολύ κώδικα στην εφαρμογή σας για να λάβετε υπόψη δεδομένα που δεν είναι αποθηκευμένα στη μορφή που περιμένετε. Όπως λένε συχνά στην εταιρεία μας Simple Thread… η εφαρμογή θα ξαναγραφτεί κάποια μέρα, αλλά τα δεδομένα θα ζουν για πάντα. Σημείωση: Το MongoDB υποστηρίζει επικύρωση σχήματος, η οποία είναι χρήσιμη, αλλά δεν παρέχει τις ίδιες εγγυήσεις με μια σχεσιακή βάση δεδομένων. Πρώτα απ 'όλα, η προσθήκη ή η αλλαγή της επικύρωσης σχήματος δεν επηρεάζει τα υπάρχοντα δεδομένα στη συλλογή. Πρέπει να βεβαιωθείτε ότι ενημερώνετε τα δεδομένα σύμφωνα με το νέο σχήμα. Αποφασίστε μόνοι σας εάν αυτό είναι αρκετό για τις ανάγκες σας.
  • Ίδια γλώσσα ερωτημάτων / απώλεια οικοσυστήματος εργαλείων: Η εμφάνιση της SQL ήταν μια απόλυτη επανάσταση και τίποτα δεν έχει αλλάξει από τότε. Είναι μια απίστευτα δυνατή γλώσσα, αλλά και αρκετά περίπλοκη. Η ανάγκη κατασκευής ερωτημάτων βάσης δεδομένων σε μια νέα γλώσσα, που αποτελείται από τμήματα JSON, θεωρείται ως ένα μεγάλο βήμα πίσω από άτομα που έχουν εμπειρία με την SQL. Υπάρχει ένα ολόκληρο σύμπαν εργαλείων που αλληλεπιδρούν με βάσεις δεδομένων SQL, από IDE έως εργαλεία αναφοράς. Η μετάβαση σε μια βάση δεδομένων που δεν υποστηρίζει SQL σημαίνει ότι δεν μπορείτε να χρησιμοποιήσετε τα περισσότερα από αυτά τα εργαλεία ή πρέπει να μετατρέψετε τα δεδομένα σε SQL για να τα χρησιμοποιήσετε, κάτι που μπορεί να είναι πιο δύσκολο από όσο νομίζετε.

Πολλοί προγραμματιστές που στράφηκαν στο MongoDB δεν καταλάβαιναν πραγματικά τις ανταλλαγές και συχνά βούτηξαν με το κεφάλι στο να το δημιουργήσουν ως το κύριο κατάστημα δεδομένων τους. Μετά από αυτό, ήταν συχνά απίστευτα δύσκολο να επιστρέψω.

Τι θα μπορούσε να είχε γίνει διαφορετικά;

Δεν πήδηξαν όλοι πρώτοι με το κεφάλι και έπεσαν στον πάτο. Αλλά αρκετά έργα έχουν εγκαταστήσει τη βάση MongoDB εκεί που απλά δεν χωρούσε - και θα πρέπει να ζήσουν με αυτήν για πολλά ακόμη χρόνια. Εάν αυτοί οι οργανισμοί είχαν πάρει λίγο χρόνο για να εξετάσουν μεθοδικά τις τεχνολογικές τους επιλογές, πολλοί θα είχαν κάνει μια διαφορετική επιλογή.

Πώς να επιλέξετε τη σωστή τεχνολογία; Έχουν γίνει αρκετές προσπάθειες να δημιουργηθεί ένα συστηματικό πλαίσιο για την αξιολόγηση της τεχνολογίας, όπως π.χ «Πλαίσιο για την εφαρμογή τεχνολογιών σε οργανισμούς λογισμικού» и "Πλαίσιο για την αξιολόγηση τεχνολογιών λογισμικού", αλλά μου φαίνεται ότι αυτό είναι μια περιττή πολυπλοκότητα.

Πολλές τεχνολογίες μπορούν να εκτιμηθούν έξυπνα κάνοντας δύο μόνο βασικές ερωτήσεις. Το πρόβλημα έγκειται στην εύρεση ανθρώπων που μπορούν να τους απαντήσουν υπεύθυνα, αφιερώνοντας χρόνο για να βρουν απαντήσεις και χωρίς προκατάληψη.

Εάν δεν αντιμετωπίζετε κάποιο πρόβλημα, δεν χρειάζεστε νέο εργαλείο. Τελεία.

Ερώτηση 1: Ποια προβλήματα προσπαθώ να λύσω;

Εάν δεν αντιμετωπίζετε κάποιο πρόβλημα, δεν χρειάζεστε νέο εργαλείο. Τελεία. Δεν χρειάζεται να αναζητήσετε μια λύση και μετά να βρείτε ένα πρόβλημα. Αν δεν αντιμετωπίζετε πρόβλημα που η νέα τεχνολογία δεν λύνει σημαντικά καλύτερα από την υπάρχουσα τεχνολογία σας, τότε δεν υπάρχει τίποτα να συζητήσουμε εδώ. Εάν σκέφτεστε να χρησιμοποιήσετε αυτήν την τεχνολογία επειδή έχετε δει άλλους να τη χρησιμοποιούν, σκεφτείτε τα προβλήματα που αντιμετωπίζουν και ρωτήστε εάν αντιμετωπίζετε αυτά τα προβλήματα. Είναι εύκολο να αγκαλιάσεις την τεχνολογία επειδή την χρησιμοποιούν άλλοι, η δυσκολία είναι να ξέρεις αν αντιμετωπίζεις τα ίδια προβλήματα.

Ερώτηση 2: Τι μου λείπει;

Αυτή είναι σίγουρα μια πιο δύσκολη ερώτηση, γιατί πρέπει να σκάψετε και να κατανοήσετε καλά τόσο την παλιά όσο και τη νέα τεχνολογία. Μερικές φορές δεν μπορείτε πραγματικά να καταλάβετε ένα νέο μέχρι να δημιουργήσετε κάτι με αυτό ή να έχετε έναν συνάδελφο με αυτήν την εμπειρία.

Εάν δεν έχετε κανένα από τα δύο, τότε είναι λογικό να σκεφτείτε την ελάχιστη δυνατή επένδυση για να καθορίσετε την αξία αυτού του μέσου. Και αν κάνετε μια επένδυση, πόσο δύσκολο θα είναι να αντιστρέψετε την απόφαση;

Οι άνθρωποι πάντα καταστρέφουν τα πάντα

Προσπαθώντας να απαντήσετε σε αυτές τις ερωτήσεις όσο το δυνατόν πιο αμερόληπτα, θυμηθείτε ένα πράγμα: πρέπει να πολεμήσετε την ανθρώπινη φύση. Υπάρχει μια σειρά από γνωστικές προκαταλήψεις που πρέπει να ξεπεραστούν προκειμένου να αξιολογηθεί αποτελεσματικά η τεχνολογία. Εδώ είναι μόνο μερικά:

  • Το αποτέλεσμα της ένταξης στην πλειοψηφία Όλοι γνωρίζουν γι 'αυτόν, αλλά είναι ακόμα δύσκολο να τον πολεμήσεις. Απλώς βεβαιωθείτε ότι η τεχνολογία ταιριάζει πραγματικά στις πραγματικές σας ανάγκες.
  • εφέ καινοτομίας Πολλοί προγραμματιστές τείνουν να υποτιμούν τις τεχνολογίες με τις οποίες εργάζονται εδώ και πολύ καιρό και να υπερεκτιμούν τα οφέλη μιας νέας τεχνολογίας. Όχι μόνο οι προγραμματιστές, όλοι υπόκεινται σε αυτή τη γνωστική προκατάληψη.
  • Επίδραση θετικού χαρακτηριστικού Έχουμε την τάση να βλέπουμε τι είναι και να χάνουμε τα μάτια μας τι δεν είναι. Αυτό μπορεί να οδηγήσει σε χάος, σε συνδυασμό με το φαινόμενο της καινοτομίας, καθώς όχι μόνο υπερεκτιμάτε εγγενώς τη νέα τεχνολογία, αλλά και αγνοείτε τα μειονεκτήματά της..

Η αντικειμενική αξιολόγηση δεν είναι εύκολη, αλλά η κατανόηση των υποκείμενων γνωστικών προκαταλήψεων θα σας βοηθήσει να πάρετε πιο ορθολογικές αποφάσεις.

Περίληψη

Όταν εμφανίζεται μια καινοτομία, δύο ερωτήματα πρέπει να απαντηθούν με μεγάλη προσοχή:

  • Αυτό το εργαλείο λύνει ένα πραγματικό πρόβλημα;
  • Είμαστε καλοί στην κατανόηση των ανταλλαγών;

Εάν δεν μπορείτε να απαντήσετε με σιγουριά σε αυτές τις δύο ερωτήσεις, κάντε μερικά βήματα πίσω και σκεφτείτε.

Ήταν λοιπόν το la MongoDB γενικά η σωστή επιλογή; Φυσικά ναι; Όπως συμβαίνει με τις περισσότερες τεχνολογίες μηχανικής, εξαρτάται από πολλούς παράγοντες. Μεταξύ εκείνων που απάντησαν σε αυτές τις δύο ερωτήσεις, πολλοί επωφελήθηκαν από το MongoDB και συνεχίζουν να το κάνουν. Για όσους από εσάς δεν το έχετε κάνει, ελπίζω να έχετε μάθει ένα πολύτιμο και όχι πολύ οδυνηρό μάθημα σχετικά με τη μετάβαση στον κύκλο της διαφημιστικής εκστρατείας.

Αποποίηση ευθυνών

Θέλω να διευκρινίσω ότι ούτε αγαπώ ούτε μισώ το MongoDB. Απλώς δεν είχαμε το είδος των προβλημάτων που η MongoDB είναι η καταλληλότερη να λύσει. Γνωρίζω την 10gen/MongoDB Inc. ενήργησε πολύ τολμηρά στην αρχή, θέτοντας ανασφαλείς προεπιλογές και προωθώντας το MongoDB παντού (ιδιαίτερα στα hackathons) ως μια ενιαία λύση για εργασία με οποιαδήποτε δεδομένα. Μάλλον ήταν μια κακή απόφαση. Αλλά επιβεβαιώνει την προσέγγιση που περιγράφεται εδώ: αυτά τα προβλήματα θα μπορούσαν να εντοπιστούν πολύ γρήγορα ακόμη και με μια επιφανειακή αξιολόγηση της τεχνολογίας.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο