TL;DR: Πριν από τέσσερα χρόνια άφησα την Google με μια ιδέα για ένα νέο εργαλείο παρακολούθησης διακομιστή. Η ιδέα ήταν να συνδυαστούν συνήθως απομονωμένες λειτουργίες σε μία υπηρεσία και ανάλυση αρχείων καταγραφής, συλλογή μετρήσεων, και ταμπλό. Μία από τις αρχές είναι ότι η υπηρεσία πρέπει να είναι αληθινή γρήγορα, παρέχοντας στον devop μια εύκολη, διαδραστική, ευχάριστη εμπειρία. Αυτό απαιτεί την επεξεργασία συνόλων δεδομένων πολλών gigabyte σε κλάσματα του δευτερολέπτου, ενώ παραμένει εντός του προϋπολογισμού. Τα υπάρχοντα εργαλεία διαχείρισης αρχείων καταγραφής είναι συχνά αργά και αδέξια, επομένως αντιμετωπίσαμε μια καλή πρόκληση: να σχεδιάσουμε έξυπνα ένα εργαλείο για να προσφέρουμε στους χρήστες μια νέα εμπειρία.
Αυτό το άρθρο περιγράφει πώς εμείς στο Scalyr λύσαμε αυτό το πρόβλημα εφαρμόζοντας μεθόδους παλιάς σχολής, μια προσέγγιση ωμής δύναμης, εξαλείφοντας τα περιττά επίπεδα και αποφεύγοντας πολύπλοκες δομές δεδομένων. Μπορείτε να εφαρμόσετε αυτά τα μαθήματα στα δικά σας προβλήματα μηχανικής.
Old School Power
Η ανάλυση αρχείων καταγραφής συνήθως ξεκινά με μια αναζήτηση: βρείτε όλα τα μηνύματα που ταιριάζουν με ένα συγκεκριμένο μοτίβο. Στο Scalyr, αυτά είναι δεκάδες ή εκατοντάδες gigabyte αρχείων καταγραφής από πολλούς διακομιστές. Οι σύγχρονες προσεγγίσεις, κατά κανόνα, περιλαμβάνουν την κατασκευή κάποιας πολύπλοκης δομής δεδομένων βελτιστοποιημένης για αναζήτηση. Σίγουρα το έχω δει αυτό στο Google, όπου είναι αρκετά καλοί σε κάτι τέτοιο. Αλλά καταλήξαμε σε μια πολύ πιο ωμή προσέγγιση: γραμμική σάρωση κορμών. Και λειτούργησε - παρέχουμε μια διεπαφή με δυνατότητα αναζήτησης που είναι τάξεις μεγέθους ταχύτερη από τους ανταγωνιστές μας (δείτε κινούμενα σχέδια στο τέλος).
Η βασική ιδέα ήταν ότι οι σύγχρονοι επεξεργαστές είναι πράγματι πολύ γρήγοροι σε απλές, απλές λειτουργίες. Αυτό είναι εύκολο να το χάσετε σε πολύπλοκα συστήματα πολλαπλών επιπέδων που βασίζονται στην ταχύτητα I/O και στις λειτουργίες δικτύου, και τέτοια συστήματα είναι πολύ συνηθισμένα σήμερα. Έτσι αναπτύξαμε ένα σχέδιο που ελαχιστοποιεί τα στρώματα και τα υπερβολικά συντρίμμια. Με πολλούς επεξεργαστές και διακομιστές παράλληλα, η ταχύτητα αναζήτησης φτάνει το 1 TB ανά δευτερόλεπτο.
Βασικά στοιχεία από αυτό το άρθρο:
- Η αναζήτηση ωμής βίας είναι μια βιώσιμη προσέγγιση για την επίλυση πραγματικών προβλημάτων μεγάλης κλίμακας.
- Η ωμή δύναμη είναι μια τεχνική σχεδιασμού, όχι μια λύση χωρίς εργασία. Όπως κάθε τεχνική, ταιριάζει καλύτερα σε ορισμένα προβλήματα από άλλα και μπορεί να εφαρμοστεί κακώς ή καλά.
- Η ωμή δύναμη είναι ιδιαίτερα καλή για την επίτευξη σταθερός παραγωγικότητα.
- Η αποτελεσματική χρήση της ωμής βίας απαιτεί βελτιστοποίηση κώδικα και εφαρμογή επαρκών πόρων την κατάλληλη στιγμή. Είναι κατάλληλο εάν οι διακομιστές σας είναι υπό μεγάλο φορτίο μη χρήστη και οι λειτουργίες των χρηστών παραμένουν προτεραιότητα.
- Η απόδοση εξαρτάται από το σχεδιασμό ολόκληρου του συστήματος, όχι μόνο από τον αλγόριθμο του εσωτερικού βρόχου.
(Αυτό το άρθρο περιγράφει την αναζήτηση δεδομένων στη μνήμη. Στις περισσότερες περιπτώσεις, όταν ένας χρήστης πραγματοποιεί αναζήτηση αρχείων καταγραφής, οι διακομιστές Scalyr τα έχουν ήδη αποθηκεύσει στην κρυφή μνήμη. Στο επόμενο άρθρο θα συζητηθεί η αναζήτηση για μη αποθηκευμένα αρχεία καταγραφής. Ισχύουν οι ίδιες αρχές: αποτελεσματικός κώδικας, ωμή δύναμη με μεγάλους υπολογιστικούς πόρους).
Μέθοδος ωμής δύναμης
Παραδοσιακά, ένα μεγάλο σύνολο δεδομένων αναζητείται χρησιμοποιώντας ένα ευρετήριο λέξεων-κλειδιών. Όταν εφαρμόζεται σε αρχεία καταγραφής διακομιστή, αυτό σημαίνει αναζήτηση για κάθε μοναδική λέξη στο αρχείο καταγραφής. Για κάθε λέξη, πρέπει να κάνετε μια λίστα με όλες τις συμπεριλήψεις. Αυτό διευκολύνει την εύρεση όλων των μηνυμάτων με αυτήν τη λέξη, για παράδειγμα «σφάλμα», «firefox» ή «transaction_16851951» - απλώς κοιτάξτε στο ευρετήριο.
Χρησιμοποίησα αυτήν την προσέγγιση στη Google και λειτούργησε καλά. Αλλά στο Scalyr ψάχνουμε τα αρχεία καταγραφής byte byte.
Γιατί; Από μια αφηρημένη αλγοριθμική άποψη, τα ευρετήρια λέξεων-κλειδιών είναι πολύ πιο αποτελεσματικά από τις αναζητήσεις ωμής βίας. Ωστόσο, δεν πουλάμε αλγόριθμους, πουλάμε απόδοση. Και η απόδοση δεν αφορά μόνο τους αλγόριθμους, αλλά και τη μηχανική συστημάτων. Πρέπει να λάβουμε υπόψη τα πάντα: όγκο δεδομένων, τύπο αναζήτησης, διαθέσιμο υλικό και λογισμικό. Αποφασίσαμε ότι για το συγκεκριμένο πρόβλημά μας, κάτι σαν «grep» ταιριάζει καλύτερα από ένα ευρετήριο.
Οι δείκτες είναι υπέροχοι, αλλά έχουν περιορισμούς. Μια λέξη είναι εύκολο να βρεθεί. Αλλά η αναζήτηση μηνυμάτων με πολλές λέξεις, όπως «googlebot» και «404», είναι πολύ πιο δύσκολη. Η αναζήτηση για μια φράση όπως "αιχμάλωτη εξαίρεση" απαιτεί ένα πιο δυσκίνητο ευρετήριο που καταγράφει όχι μόνο όλα τα μηνύματα με αυτήν τη λέξη, αλλά και τη συγκεκριμένη θέση της λέξης.
Η πραγματική δυσκολία έρχεται όταν δεν ψάχνεις λέξεις. Ας υποθέσουμε ότι θέλετε να δείτε πόση επισκεψιμότητα προέρχεται από τα bots. Η πρώτη σκέψη είναι να ψάξετε στα αρχεία καταγραφής για τη λέξη 'bot'. Έτσι θα βρείτε μερικά bots: Googlebot, Bingbot και πολλά άλλα. Αλλά εδώ το «bot» δεν είναι μια λέξη, αλλά ένα μέρος της. Αν αναζητήσουμε "bot" στο ευρετήριο, δεν θα βρούμε αναρτήσεις με τη λέξη "Googlebot". Εάν ελέγξετε κάθε λέξη στο ευρετήριο και στη συνέχεια σαρώσετε το ευρετήριο για τις λέξεις-κλειδιά που βρέθηκαν, η αναζήτηση θα επιβραδυνθεί πολύ. Ως αποτέλεσμα, ορισμένα προγράμματα καταγραφής δεν επιτρέπουν αναζητήσεις μερικών λέξεων ή (στην καλύτερη περίπτωση) επιτρέπουν ειδική σύνταξη με χαμηλότερη απόδοση. Θέλουμε να το αποφύγουμε αυτό.
Ένα άλλο πρόβλημα είναι τα σημεία στίξης. Θέλετε να βρείτε όλα τα αιτήματα από 50.168.29.7? Τι γίνεται με τον εντοπισμό σφαλμάτων που περιέχουν τα αρχεία καταγραφής [error]? Οι συνδρομητές συνήθως παραλείπουν τα σημεία στίξης.
Τέλος, οι μηχανικοί αγαπούν τα ισχυρά εργαλεία και μερικές φορές ένα πρόβλημα μπορεί να λυθεί μόνο με μια κανονική έκφραση. Το ευρετήριο λέξεων-κλειδιών δεν είναι πολύ κατάλληλο για αυτό.
Επιπλέον, οι δείκτες συγκρότημα. Κάθε μήνυμα πρέπει να προστεθεί σε πολλές λίστες λέξεων-κλειδιών. Αυτές οι λίστες θα πρέπει να διατηρούνται σε μορφή εύκολα αναζητήσιμη ανά πάσα στιγμή. Ερωτήματα με φράσεις, θραύσματα λέξεων ή κανονικές εκφράσεις πρέπει να μεταφραστούν σε λειτουργίες πολλών λιστών και τα αποτελέσματα να σαρωθούν και να συνδυαστούν για να παραχθεί ένα σύνολο αποτελεσμάτων. Στο πλαίσιο μιας μεγάλης κλίμακας υπηρεσίας πολλαπλών μισθωτών, αυτή η πολυπλοκότητα δημιουργεί ζητήματα απόδοσης που δεν είναι ορατά κατά την ανάλυση των αλγορίθμων.
Τα ευρετήρια λέξεων-κλειδιών καταλαμβάνουν επίσης πολύ χώρο και η αποθήκευση είναι ένα σημαντικό κόστος σε ένα σύστημα διαχείρισης αρχείων καταγραφής.
Από την άλλη πλευρά, κάθε αναζήτηση μπορεί να καταναλώσει μεγάλη υπολογιστική ισχύ. Οι χρήστες μας εκτιμούν τις αναζητήσεις υψηλής ταχύτητας για μοναδικά ερωτήματα, αλλά τέτοια ερωτήματα γίνονται σχετικά σπάνια. Για τυπικά ερωτήματα αναζήτησης, για παράδειγμα, για έναν πίνακα εργαλείων, χρησιμοποιούμε ειδικές τεχνικές (θα τις περιγράψουμε σε επόμενο άρθρο). Άλλα αιτήματα είναι αρκετά σπάνια που σπάνια χρειάζεται να επεξεργαστείτε περισσότερα από ένα κάθε φορά. Αυτό όμως δεν σημαίνει ότι οι διακομιστές μας δεν είναι απασχολημένοι: είναι απασχολημένοι με το έργο της λήψης, ανάλυσης και συμπίεσης νέων μηνυμάτων, αξιολόγησης ειδοποιήσεων, συμπίεσης παλαιών δεδομένων κ.λπ. Έτσι, έχουμε μια αρκετά σημαντική προσφορά επεξεργαστών που μπορούν να χρησιμοποιηθούν για την εκτέλεση ερωτημάτων.
Η ωμή βία λειτουργεί εάν έχετε ένα άγριο πρόβλημα (και πολλή βία)
Η ωμή δύναμη λειτουργεί καλύτερα σε απλά προβλήματα με μικρούς εσωτερικούς βρόχους. Συχνά μπορείτε να βελτιστοποιήσετε τον εσωτερικό βρόχο ώστε να λειτουργεί σε πολύ υψηλές ταχύτητες. Εάν ο κώδικας είναι περίπλοκος, είναι πολύ πιο δύσκολο να βελτιστοποιηθεί.
Ο κώδικας αναζήτησής μας είχε αρχικά έναν αρκετά μεγάλο εσωτερικό βρόχο. Αποθηκεύουμε μηνύματα σε σελίδες σε ανάλυση 4K. κάθε σελίδα περιέχει ορισμένα μηνύματα (σε UTF-8) και μεταδεδομένα για κάθε μήνυμα. Τα μεταδεδομένα είναι μια δομή που κωδικοποιεί το μήκος της τιμής, το εσωτερικό αναγνωριστικό μηνύματος και άλλα πεδία. Ο κύκλος αναζήτησης φαινόταν ως εξής:
Αυτή είναι μια απλοποιημένη έκδοση του πραγματικού κώδικα. Αλλά ακόμη και εδώ, είναι ορατές πολλαπλές τοποθετήσεις αντικειμένων, αντίγραφα δεδομένων και κλήσεις συναρτήσεων. Το JVM είναι αρκετά καλό στη βελτιστοποίηση κλήσεων συναρτήσεων και στην κατανομή εφήμερων αντικειμένων, επομένως αυτός ο κώδικας λειτούργησε καλύτερα από ό,τι μας άξιζε. Κατά τη διάρκεια των δοκιμών, οι πελάτες το χρησιμοποίησαν με μεγάλη επιτυχία. Αλλά τελικά το πήγαμε στο επόμενο επίπεδο.
(Μπορεί να ρωτήσετε γιατί αποθηκεύουμε μηνύματα σε αυτήν τη μορφή με σελίδες 4K, κείμενο και μεταδεδομένα, αντί να εργαζόμαστε απευθείας με αρχεία καταγραφής. Υπάρχουν πολλοί λόγοι που συνοψίζονται στο γεγονός ότι εσωτερικά ο κινητήρας Scalyr μοιάζει περισσότερο με μια κατανεμημένη βάση δεδομένων παρά με μια Σύστημα αρχείων. Η αναζήτηση κειμένου συχνά συνδυάζεται με φίλτρα τύπου DBMS στα περιθώρια μετά την ανάλυση αρχείων καταγραφής. Μπορούμε ταυτόχρονα να αναζητήσουμε πολλές χιλιάδες αρχεία καταγραφής ταυτόχρονα και τα απλά αρχεία κειμένου δεν είναι κατάλληλα για τη διαχείριση δεδομένων συναλλαγών, αναπαραγωγής και διανομής).
Αρχικά, φαινόταν ότι ένας τέτοιος κώδικας δεν ήταν πολύ κατάλληλος για βελτιστοποίηση ωμής δύναμης. «Πραγματική δουλειά» στο String.indexOf() δεν κυριαρχούσε καν στο προφίλ της CPU. Δηλαδή, η βελτιστοποίηση αυτής της μεθόδου από μόνη της δεν θα είχε σημαντικό αποτέλεσμα.
Συμβαίνει ότι αποθηκεύουμε μεταδεδομένα στην αρχή κάθε σελίδας και το κείμενο όλων των μηνυμάτων στο UTF-8 συσκευάζεται στο άλλο άκρο. Εκμεταλλευόμενοι αυτό, ξαναγράψαμε τον βρόχο για να αναζητήσουμε ολόκληρη τη σελίδα ταυτόχρονα:
Αυτή η έκδοση λειτουργεί απευθείας στην προβολή raw byte[] και πραγματοποιεί αναζήτηση σε όλα τα μηνύματα ταυτόχρονα σε ολόκληρη τη σελίδα 4K.
Αυτό είναι πολύ πιο εύκολο να βελτιστοποιηθεί για τη μέθοδο της ωμής δύναμης. Ο εσωτερικός βρόχος αναζήτησης καλείται ταυτόχρονα για ολόκληρη τη σελίδα 4K, και όχι ξεχωριστά σε κάθε ανάρτηση. Δεν υπάρχει αντιγραφή δεδομένων, δεν υπάρχει κατανομή αντικειμένων. Και πιο σύνθετες λειτουργίες μεταδεδομένων καλούνται μόνο όταν το αποτέλεσμα είναι θετικό και όχι σε κάθε μήνυμα. Με αυτόν τον τρόπο έχουμε εξαλείψει έναν τόνο γενικών εξόδων και το υπόλοιπο φορτίο συγκεντρώνεται σε έναν μικρό εσωτερικό βρόχο αναζήτησης, ο οποίος είναι κατάλληλος για περαιτέρω βελτιστοποίηση.
Ο πραγματικός αλγόριθμος αναζήτησής μας βασίζεται σε . Είναι παρόμοιος με τον αλγόριθμο Boyer-Moore, παρακάμπτοντας περίπου το μήκος της συμβολοσειράς αναζήτησης σε κάθε βήμα. Η κύρια διαφορά είναι ότι ελέγχει δύο byte τη φορά για να ελαχιστοποιήσει τις ψευδείς αντιστοιχίσεις.
Η εφαρμογή μας απαιτεί τη δημιουργία ενός πίνακα αναζήτησης 64K για κάθε αναζήτηση, αλλά αυτό δεν είναι τίποτα σε σύγκριση με τα gigabyte δεδομένων που αναζητούμε. Ο εσωτερικός βρόχος επεξεργάζεται πολλά gigabyte ανά δευτερόλεπτο σε έναν μόνο πυρήνα. Στην πράξη, η σταθερή απόδοση είναι περίπου 1,25 GB ανά δευτερόλεπτο σε κάθε πυρήνα και υπάρχουν περιθώρια βελτίωσης. Είναι δυνατό να εξαλειφθούν μερικά από τα γενικά έξοδα έξω από τον εσωτερικό βρόχο και σκοπεύουμε να πειραματιστούμε με έναν εσωτερικό βρόχο σε C αντί για Java.
Χρησιμοποιούμε βία
Έχουμε συζητήσει ότι η αναζήτηση αρχείων καταγραφής μπορεί να εφαρμοστεί "κατά προσέγγιση", αλλά πόση "δύναμη" έχουμε; Αρκετά.
1 πυρήνας: Όταν χρησιμοποιείται σωστά, ένας μόνος πυρήνας ενός σύγχρονου επεξεργαστή είναι αρκετά ισχυρός από μόνος του.
8 πυρήνες: Αυτήν τη στιγμή τρέχουμε σε διακομιστές Amazon hi1.4xlarge και i2.4xlarge SSD, ο καθένας με 8 πυρήνες (16 νήματα). Όπως αναφέρθηκε παραπάνω, αυτοί οι πυρήνες είναι συνήθως απασχολημένοι με λειτουργίες παρασκηνίου. Όταν ο χρήστης εκτελεί μια αναζήτηση, οι λειτουργίες παρασκηνίου αναστέλλονται, ελευθερώνοντας και τους 8 πυρήνες για αναζήτηση. Η αναζήτηση συνήθως ολοκληρώνεται σε ένα κλάσμα του δευτερολέπτου, μετά από το οποίο συνεχίζεται η εργασία στο παρασκήνιο (το πρόγραμμα περιορισμού διασφαλίζει ότι ο καταιγισμός των ερωτημάτων αναζήτησης δεν παρεμβαίνει σε σημαντική εργασία στο παρασκήνιο).
16 πυρήνες: για αξιοπιστία, οργανώνουμε τους διακομιστές σε ομάδες master/slave. Κάθε κύριος έχει υπό τις εντολές του έναν διακομιστή SSD και έναν διακομιστή EBS. Εάν ο κύριος διακομιστής διακοπεί, ο διακομιστής SSD παίρνει αμέσως τη θέση του. Σχεδόν όλη την ώρα, το master και το slave λειτουργούν μια χαρά, έτσι ώστε κάθε μπλοκ δεδομένων να μπορεί να αναζητηθεί σε δύο διαφορετικούς διακομιστές (ο slave διακομιστής EBS έχει αδύναμο επεξεργαστή, επομένως δεν το λαμβάνουμε υπόψη). Μοιράζουμε την εργασία μεταξύ τους, ώστε να έχουμε διαθέσιμους συνολικά 16 πυρήνες.
Πολλοί πυρήνες: Στο εγγύς μέλλον, θα διανείμουμε δεδομένα σε διακομιστές με τέτοιο τρόπο ώστε όλοι να συμμετέχουν στην επεξεργασία κάθε μη τετριμμένου αιτήματος. Κάθε πυρήνας θα λειτουργήσει. [Σημείωση: εφαρμόσαμε το σχέδιο και αυξήσαμε την ταχύτητα αναζήτησης σε 1 TB/s, βλ. σημείωση στο τέλος του άρθρου].
Η απλότητα εξασφαλίζει αξιοπιστία
Ένα άλλο πλεονέκτημα της μεθόδου της ωμής δύναμης είναι η αρκετά σταθερή απόδοσή της. Συνήθως, η αναζήτηση δεν είναι πολύ ευαίσθητη στις λεπτομέρειες του προβλήματος και του συνόλου δεδομένων (υποθέτω ότι γι' αυτό ονομάζεται "χονδροειδής").
Το ευρετήριο λέξεων-κλειδιών μερικές φορές παράγει απίστευτα γρήγορα αποτελέσματα και άλλες φορές όχι. Ας υποθέσουμε ότι έχετε 50 GB αρχείων καταγραφής στα οποία ο όρος "customer_5987235982" εμφανίζεται ακριβώς τρεις φορές. Μια αναζήτηση για αυτόν τον όρο μετράει τρεις τοποθεσίες απευθείας από το ευρετήριο και θα ολοκληρωθεί αμέσως. Ωστόσο, οι σύνθετες αναζητήσεις με χαρακτήρες μπαλαντέρ μπορούν να σαρώσουν χιλιάδες λέξεις-κλειδιά και να διαρκέσουν πολύ.
Από την άλλη πλευρά, οι αναζητήσεις ωμής βίας εκτελούνται με την ίδια ταχύτητα για οποιοδήποτε ερώτημα. Η αναζήτηση μεγάλων λέξεων είναι καλύτερη, αλλά ακόμη και η αναζήτηση ενός μόνο χαρακτήρα είναι αρκετά γρήγορη.
Η απλότητα της μεθόδου της ωμής δύναμης σημαίνει ότι η απόδοσή της είναι κοντά στο θεωρητικό μέγιστο. Υπάρχουν λιγότερες επιλογές για απροσδόκητες υπερφορτώσεις δίσκου, διαμάχη κλειδώματος, κυνήγι δείκτη και χιλιάδες άλλους λόγους αποτυχίας. Μόλις κοίταξα τα αιτήματα που έκαναν οι χρήστες του Scalyr την περασμένη εβδομάδα στον πιο πολυσύχναστο διακομιστή μας. Υπήρχαν 14 αιτήματα. Ακριβώς οκτώ από αυτούς χρειάστηκαν περισσότερο από ένα δευτερόλεπτο. Το 000% ολοκληρώθηκε μέσα σε 99 χιλιοστά του δευτερολέπτου (αν δεν έχετε χρησιμοποιήσει εργαλεία ανάλυσης αρχείων καταγραφής, εμπιστευτείτε με: είναι γρήγορο).
Η σταθερή, αξιόπιστη απόδοση είναι σημαντική για την ευκολία χρήσης της υπηρεσίας. Εάν καθυστερεί περιοδικά, οι χρήστες θα το αντιληφθούν ως αναξιόπιστο και θα είναι απρόθυμοι να το χρησιμοποιήσουν.
Καταγραφή αναζήτησης σε δράση
Ακολουθεί ένα σύντομο animation που δείχνει την αναζήτηση Scalyr σε δράση. Έχουμε έναν δοκιμαστικό λογαριασμό όπου εισάγουμε κάθε συμβάν σε κάθε δημόσιο αποθετήριο Github. Σε αυτήν την επίδειξη, εξετάζω δεδομένα αξίας μιας εβδομάδας: περίπου 600 MB ακατέργαστων αρχείων καταγραφής.
Το βίντεο ηχογραφήθηκε ζωντανά, χωρίς ιδιαίτερη προετοιμασία, στο desktop μου (περίπου 5000 χιλιόμετρα από τον διακομιστή). Η απόδοση που θα δείτε οφείλεται σε μεγάλο βαθμό , καθώς και ένα γρήγορο και αξιόπιστο backend. Κάθε φορά που υπάρχει παύση χωρίς ένδειξη «φόρτωσης», παύω εγώ, ώστε να μπορείτε να διαβάσετε τι πρόκειται να πατήσω.
Εν κατακλείδι
Κατά την επεξεργασία μεγάλων ποσοτήτων δεδομένων, είναι σημαντικό να επιλέγετε έναν καλό αλγόριθμο, αλλά «καλός» δεν σημαίνει «φανταχτερός». Σκεφτείτε πώς θα λειτουργήσει ο κώδικάς σας στην πράξη. Η θεωρητική ανάλυση των αλγορίθμων αφήνει έξω ορισμένους παράγοντες που μπορεί να έχουν μεγάλη σημασία στον πραγματικό κόσμο. Οι απλούστεροι αλγόριθμοι είναι πιο εύκολο να βελτιστοποιηθούν και είναι πιο σταθεροί σε καταστάσεις αιχμής.
Σκεφτείτε επίσης το πλαίσιο στο οποίο θα εκτελεστεί ο κώδικας. Στην περίπτωσή μας, χρειαζόμαστε αρκετά ισχυρούς διακομιστές για τη διαχείριση εργασιών στο παρασκήνιο. Οι χρήστες ξεκινούν αναζητήσεις σχετικά σπάνια, επομένως μπορούμε να δανειστούμε μια ολόκληρη ομάδα διακομιστών για τη σύντομη περίοδο που απαιτείται για την ολοκλήρωση κάθε αναζήτησης.
Χρησιμοποιώντας μια μέθοδο ωμής βίας, εφαρμόσαμε μια γρήγορη, αξιόπιστη, ευέλικτη αναζήτηση σε ένα σύνολο αρχείων καταγραφής. Ελπίζουμε αυτές οι ιδέες να είναι χρήσιμες για τα έργα σας.
Επεξεργασία: Ο τίτλος και το κείμενο έχουν αλλάξει από "Αναζήτηση με 20 GB ανά δευτερόλεπτο" σε "Αναζήτηση με 1 TB ανά δευτερόλεπτο" για να αντικατοπτρίζουν τις αυξήσεις απόδοσης τα τελευταία χρόνια. Αυτή η αύξηση της ταχύτητας οφείλεται κυρίως στις αλλαγές στον τύπο και τον αριθμό των διακομιστών EC2 που διαθέτουμε σήμερα για να εξυπηρετήσουμε την αυξημένη πελατειακή μας βάση. Έρχονται σύντομα αλλαγές που θα δώσουν άλλη μια δραματική ώθηση στη λειτουργική αποτελεσματικότητα και ανυπομονούμε να τις μοιραστούμε.
Πηγή: www.habr.com