Οι χρήστες μας γράφουν μηνύματα ο ένας στον άλλο χωρίς να γνωρίζουν την κούραση.
Αυτό είναι πολύ. Εάν ξεκινούσατε να διαβάζετε όλα τα μηνύματα όλων των χρηστών, θα χρειάζονταν περισσότερα από 150 χιλιάδες χρόνια. Με την προϋπόθεση ότι είστε αρκετά προχωρημένος αναγνώστης και δεν ξοδεύετε περισσότερο από ένα δευτερόλεπτο σε κάθε μήνυμα.
Με έναν τέτοιο όγκο δεδομένων, είναι κρίσιμο η λογική για την αποθήκευση και την πρόσβαση σε αυτά να χτιστεί βέλτιστα. Διαφορετικά, σε μια όχι και τόσο υπέροχη στιγμή, μπορεί να γίνει σαφές ότι σύντομα όλα θα πάνε στραβά.
Για εμάς αυτή η στιγμή ήρθε πριν από ενάμιση χρόνο. Πώς φτάσαμε σε αυτό και τι συνέβη τελικά - σας το λέμε με τη σειρά.
ιατρικό ιστορικό ασθενούς
Στην πρώτη εφαρμογή, τα μηνύματα VKontakte λειτουργούσαν σε συνδυασμό PHP backend και MySQL. Αυτή είναι μια απολύτως φυσιολογική λύση για μια μικρή φοιτητική ιστοσελίδα. Ωστόσο, αυτός ο ιστότοπος αναπτύχθηκε ανεξέλεγκτα και άρχισε να απαιτεί τη βελτιστοποίηση των δομών δεδομένων για τον εαυτό του.
Στα τέλη του 2009 γράφτηκε το πρώτο αποθετήριο της μηχανής κειμένου και το 2010 μεταφέρθηκαν μηνύματα σε αυτό.
Στη μηχανή κειμένου, τα μηνύματα αποθηκεύονταν σε λίστες - ένα είδος "ταχυδρομικών θυρίδων". Κάθε τέτοια λίστα καθορίζεται από ένα uid - τον χρήστη που κατέχει όλα αυτά τα μηνύματα. Ένα μήνυμα έχει ένα σύνολο χαρακτηριστικών: αναγνωριστικό συνομιλητή, κείμενο, συνημμένα και ούτω καθεξής. Το αναγνωριστικό μηνύματος μέσα στο "box" είναι local_id, δεν αλλάζει ποτέ και εκχωρείται διαδοχικά για νέα μηνύματα. Τα «κουτιά» είναι ανεξάρτητα και δεν συγχρονίζονται μεταξύ τους μέσα στον κινητήρα· η επικοινωνία μεταξύ τους γίνεται σε επίπεδο PHP. Μπορείτε να δείτε τη δομή δεδομένων και τις δυνατότητες της μηχανής κειμένου από μέσα .
Αυτό ήταν αρκετό για αλληλογραφία μεταξύ δύο χρηστών. Μαντέψτε τι έγινε μετά;
Τον Μάιο του 2011, το VKontakte εισήγαγε συνομιλίες με πολλούς συμμετέχοντες — multi-chat. Για να συνεργαστούμε μαζί τους, δημιουργήσαμε δύο νέα clusters - μέλη-chats και chat-members. Το πρώτο αποθηκεύει δεδομένα σχετικά με τις συνομιλίες από χρήστες, το δεύτερο αποθηκεύει δεδομένα σχετικά με τους χρήστες ανά συνομιλίες. Εκτός από τις ίδιες τις λίστες, αυτό περιλαμβάνει, για παράδειγμα, τον προσκαλούντα χρήστη και την ώρα που προστέθηκαν στη συνομιλία.
"PHP, ας στείλουμε ένα μήνυμα στη συνομιλία", λέει ο χρήστης.
"Έλα, {username}", λέει η PHP.
Υπάρχουν μειονεκτήματα σε αυτό το σχήμα. Ο συγχρονισμός εξακολουθεί να είναι ευθύνη της PHP. Οι μεγάλες συνομιλίες και οι χρήστες που τους στέλνουν μηνύματα ταυτόχρονα είναι μια επικίνδυνη ιστορία. Δεδομένου ότι η παρουσία της μηχανής κειμένου εξαρτάται από το uid, οι συμμετέχοντες στη συνομιλία θα μπορούσαν να λάβουν το ίδιο μήνυμα σε διαφορετικές ώρες. Θα μπορούσε κανείς να ζήσει με αυτό εάν η πρόοδος σταματούσε. Αλλά αυτό δεν θα συμβεί.
Στα τέλη του 2015, κυκλοφορήσαμε μηνύματα κοινότητας και στις αρχές του 2016 ξεκινήσαμε ένα API για αυτά. Με την εμφάνιση μεγάλων chatbots στις κοινότητες, ήταν δυνατό να ξεχάσουμε την ομοιόμορφη κατανομή φορτίου.
Ένα καλό bot δημιουργεί πολλά εκατομμύρια μηνύματα την ημέρα - ακόμη και οι πιο ομιλητικοί χρήστες δεν μπορούν να καυχηθούν γι' αυτό. Αυτό σημαίνει ότι ορισμένες περιπτώσεις της μηχανής κειμένου, στις οποίες ζούσαν τέτοια ρομπότ, άρχισαν να υποφέρουν στο έπακρο.
Οι μηχανές μηνυμάτων το 2016 είναι 100 περιπτώσεις μελών συνομιλίας και συνομιλιών μελών και 8000 μηχανές κειμένου. Φιλοξενήθηκαν σε χίλιους διακομιστές, ο καθένας με 64 GB μνήμης. Ως πρώτο μέτρο έκτακτης ανάγκης, αυξήσαμε τη μνήμη κατά άλλα 32 GB. Υπολογίσαμε τις προβλέψεις. Χωρίς δραστικές αλλαγές, αυτό θα ήταν αρκετό για περίπου ακόμη έναν χρόνο. Πρέπει είτε να αποκτήσετε το υλικό είτε να βελτιστοποιήσετε τις ίδιες τις βάσεις δεδομένων.
Λόγω της φύσης της αρχιτεκτονικής, έχει νόημα η αύξηση του υλικού μόνο σε πολλαπλάσια. Δηλαδή, τουλάχιστον διπλασιασμός του αριθμού των αυτοκινήτων - προφανώς, πρόκειται για μια αρκετά ακριβή διαδρομή. Θα βελτιστοποιήσουμε.
Νέα ιδέα
Η κεντρική ουσία της νέας προσέγγισης είναι η συνομιλία. Μια συνομιλία έχει μια λίστα με μηνύματα που σχετίζονται με αυτήν. Ο χρήστης έχει μια λίστα συνομιλιών.
Το ελάχιστο απαιτούμενο είναι δύο νέες βάσεις δεδομένων:
- chat-μηχανή. Αυτό είναι ένα αποθετήριο διανυσμάτων συνομιλίας. Κάθε συνομιλία έχει ένα διάνυσμα μηνυμάτων που σχετίζονται με αυτήν. Κάθε μήνυμα έχει ένα κείμενο και ένα μοναδικό αναγνωριστικό μηνύματος μέσα στη συνομιλία - chat_local_id.
- χρήστης-μηχανής. Αυτή είναι μια αποθήκευση διανυσμάτων χρηστών - συνδέσμων προς χρήστες. Κάθε χρήστης έχει ένα διάνυσμα peer_id (συνομιλητές - άλλοι χρήστες, multi-chat ή κοινότητες) και ένα διάνυσμα μηνυμάτων. Κάθε peer_id έχει ένα διάνυσμα μηνυμάτων που σχετίζονται με αυτό. Κάθε μήνυμα έχει ένα chat_local_id και ένα μοναδικό αναγνωριστικό μηνύματος για αυτόν τον χρήστη - user_local_id.
Τα νέα συμπλέγματα επικοινωνούν μεταξύ τους χρησιμοποιώντας TCP - αυτό διασφαλίζει ότι η σειρά των αιτημάτων δεν αλλάζει. Τα ίδια τα αιτήματα και οι επιβεβαιώσεις για αυτά καταγράφονται στον σκληρό δίσκο - έτσι μπορούμε να επαναφέρουμε την κατάσταση της ουράς ανά πάσα στιγμή μετά από βλάβη ή επανεκκίνηση του κινητήρα. Δεδομένου ότι η μηχανή χρήστη και η μηχανή συνομιλίας είναι 4 χιλιάδες θραύσματα το καθένα, η ουρά αιτημάτων μεταξύ των συστάδων θα κατανεμηθεί ομοιόμορφα (αλλά στην πραγματικότητα δεν υπάρχει καθόλου - και λειτουργεί πολύ γρήγορα).
Η εργασία με δίσκο στις βάσεις δεδομένων μας στις περισσότερες περιπτώσεις βασίζεται σε συνδυασμό ενός δυαδικού αρχείου καταγραφής αλλαγών (binlog), στατικών στιγμιότυπων και μιας μερικής εικόνας στη μνήμη. Οι αλλαγές κατά τη διάρκεια της ημέρας εγγράφονται σε ένα binlog και δημιουργείται περιοδικά ένα στιγμιότυπο της τρέχουσας κατάστασης. Ένα στιγμιότυπο είναι μια συλλογή δομών δεδομένων που έχουν βελτιστοποιηθεί για τους σκοπούς μας. Αποτελείται από μια κεφαλίδα (μεταδείκτης της εικόνας) και ένα σύνολο μετααρχείων. Η κεφαλίδα αποθηκεύεται μόνιμα στη μνήμη RAM και υποδεικνύει πού να αναζητήσετε δεδομένα από το στιγμιότυπο. Κάθε μετααρχείο περιλαμβάνει δεδομένα που είναι πιθανό να χρειαστούν σε κοντινά χρονικά σημεία — για παράδειγμα, που σχετίζονται με έναν μεμονωμένο χρήστη. Όταν υποβάλλετε ερώτημα στη βάση δεδομένων χρησιμοποιώντας την κεφαλίδα στιγμιότυπου, διαβάζεται το απαιτούμενο μετααρχείο και, στη συνέχεια, λαμβάνονται υπόψη οι αλλαγές στο binlog που προέκυψαν μετά τη δημιουργία του στιγμιότυπου. Μπορείτε να διαβάσετε περισσότερα για τα οφέλη αυτής της προσέγγισης .
Ταυτόχρονα, τα δεδομένα στον ίδιο τον σκληρό δίσκο αλλάζουν μόνο μία φορά την ημέρα - αργά το βράδυ στη Μόσχα, όταν το φορτίο είναι ελάχιστο. Χάρη σε αυτό (γνωρίζοντας ότι η δομή του δίσκου είναι σταθερή κατά τη διάρκεια της ημέρας), μπορούμε να αντέξουμε οικονομικά να αντικαταστήσουμε διανύσματα με πίνακες σταθερού μεγέθους - και λόγω αυτού, να κερδίσουμε στη μνήμη.
Η αποστολή μηνύματος στο νέο σχήμα μοιάζει με αυτό:
- Το backend της PHP έρχεται σε επαφή με τη μηχανή χρήστη ζητώντας να στείλει ένα μήνυμα.
- user-engine διαμεσολαβεί το αίτημα στην επιθυμητή παρουσία μηχανής συνομιλίας, η οποία επιστρέφει στο user-engine chat_local_id - ένα μοναδικό αναγνωριστικό ενός νέου μηνύματος σε αυτήν τη συνομιλία. Στη συνέχεια, το chat_engine μεταδίδει το μήνυμα σε όλους τους παραλήπτες στη συνομιλία.
- Το user-engine λαμβάνει το chat_local_id από το chat-engine και επιστρέφει το user_local_id στην PHP - ένα μοναδικό αναγνωριστικό μηνύματος για αυτόν τον χρήστη. Αυτό το αναγνωριστικό χρησιμοποιείται στη συνέχεια, για παράδειγμα, για εργασία με μηνύματα μέσω του API.
Αλλά εκτός από την πραγματική αποστολή μηνυμάτων, πρέπει να εφαρμόσετε μερικά ακόμη σημαντικά πράγματα:
- Οι δευτερεύουσες λίστες είναι, για παράδειγμα, τα πιο πρόσφατα μηνύματα που βλέπετε όταν ανοίγετε τη λίστα συνομιλιών. Μη αναγνωσμένα μηνύματα, μηνύματα με ετικέτες ("Σημαντικό", "Ανεπιθύμητα", κ.λπ.).
- Συμπίεση μηνυμάτων στη μηχανή συνομιλίας
- Αποθήκευση μηνυμάτων στη μηχανή χρήστη
- Αναζήτηση (μέσα από όλους τους διαλόγους και μέσα σε ένα συγκεκριμένο).
- Ενημέρωση σε πραγματικό χρόνο (Longpolling).
- Αποθήκευση ιστορικού για την εφαρμογή προσωρινής αποθήκευσης σε πελάτες για κινητές συσκευές.
Όλες οι υπολίστες αλλάζουν ταχέως δομές. Για να δουλέψουμε μαζί τους χρησιμοποιούμε . Αυτή η επιλογή εξηγείται από το γεγονός ότι στην κορυφή του δέντρου μερικές φορές αποθηκεύουμε ένα ολόκληρο τμήμα μηνυμάτων από ένα στιγμιότυπο - για παράδειγμα, μετά τη νυχτερινή αναπροσαρμογή, το δέντρο αποτελείται από μια κορυφή, η οποία περιέχει όλα τα μηνύματα της υπολίστας. Το δέντρο Splay διευκολύνει την εισαγωγή στη μέση μιας τέτοιας κορυφής χωρίς να χρειάζεται να σκεφτείτε την εξισορρόπηση. Επιπλέον, το Splay δεν αποθηκεύει περιττά δεδομένα, κάτι που μας εξοικονομεί μνήμη.
Τα μηνύματα περιλαμβάνουν μεγάλο όγκο πληροφοριών, κυρίως κείμενο, που είναι χρήσιμο για τη συμπίεση. Είναι σημαντικό να μπορούμε να καταργήσουμε με ακρίβεια ακόμη και ένα μεμονωμένο μήνυμα. Χρησιμοποιείται για τη συμπίεση μηνυμάτων με τη δική μας ευρετική - για παράδειγμα, γνωρίζουμε ότι στα μηνύματα οι λέξεις εναλλάσσονται με "μη λέξεις" - κενά, σημεία στίξης - και θυμόμαστε επίσης μερικές από τις ιδιαιτερότητες της χρήσης συμβόλων για τη ρωσική γλώσσα.
Δεδομένου ότι υπάρχουν πολύ λιγότεροι χρήστες από τις συνομιλίες, για να αποθηκεύσουμε αιτήματα δίσκου τυχαίας πρόσβασης στη μηχανή συνομιλίας, αποθηκεύουμε τα μηνύματα στην κρυφή μνήμη στη μηχανή χρήστη.
Η αναζήτηση μηνυμάτων υλοποιείται ως διαγώνιο ερώτημα από τη μηχανή χρήστη σε όλες τις παρουσίες της μηχανής συνομιλίας που περιέχουν συνομιλίες αυτού του χρήστη. Τα αποτελέσματα συνδυάζονται στην ίδια τη μηχανή χρήστη.
Λοιπόν, όλες οι λεπτομέρειες έχουν ληφθεί υπόψη, το μόνο που μένει είναι να μεταβείτε σε ένα νέο σχήμα - και κατά προτίμηση χωρίς να το προσέξουν οι χρήστες.
Μετανάστευση δεδομένων
Έτσι, έχουμε μια μηχανή κειμένου που αποθηκεύει μηνύματα ανά χρήστη και δύο συμπλέγματα μελών συνομιλίας και συνομιλιών μελών που αποθηκεύουν δεδομένα σχετικά με τα δωμάτια πολλαπλών συνομιλιών και τους χρήστες σε αυτά. Πώς να μεταβείτε από αυτό στη νέα μηχανή χρήστη και μηχανή συνομιλίας;
Οι συνομιλίες μελών στο παλιό σχήμα χρησιμοποιούνταν κυρίως για βελτιστοποίηση. Μεταφέραμε γρήγορα τα απαραίτητα δεδομένα από αυτό σε μέλη συνομιλίας και, στη συνέχεια, δεν συμμετείχε πλέον στη διαδικασία μετεγκατάστασης.
Ουρά για μέλη συνομιλίας. Περιλαμβάνει 100 περιπτώσεις, ενώ το chat-engine έχει 4 χιλιάδες. Για να μεταφέρετε τα δεδομένα, πρέπει να τα φέρετε σε συμμόρφωση - για αυτό, τα μέλη συνομιλίας χωρίστηκαν στα ίδια 4 χιλιάδες αντίγραφα και στη συνέχεια ενεργοποιήθηκε η ανάγνωση του binlog μελών συνομιλίας στη μηχανή συνομιλίας.
Τώρα το chat-engine γνωρίζει για multi-chat από μέλη συνομιλίας, αλλά δεν γνωρίζει ακόμη τίποτα για διαλόγους με δύο συνομιλητές. Τέτοιοι διάλογοι βρίσκονται στη μηχανή κειμένου με αναφορά στους χρήστες. Εδώ πήραμε τα δεδομένα "προκαταβολικά": κάθε περίπτωση μηχανής συνομιλίας ρωτούσε όλες τις περιπτώσεις μηχανής κειμένου εάν είχαν τον διάλογο που χρειαζόταν.
Εξαιρετική - η μηχανή συνομιλίας γνωρίζει ποιες συνομιλίες πολλαπλών συνομιλιών υπάρχουν και γνωρίζει τι διάλογοι υπάρχουν.
Πρέπει να συνδυάσετε μηνύματα σε συνομιλίες πολλαπλών συνομιλιών, ώστε να καταλήγετε σε μια λίστα μηνυμάτων σε κάθε συνομιλία. Πρώτον, η μηχανή συνομιλίας ανακτά από τη μηχανή κειμένου όλα τα μηνύματα χρήστη από αυτήν τη συνομιλία. Σε ορισμένες περιπτώσεις υπάρχουν αρκετά από αυτά (έως και εκατοντάδες εκατομμύρια), αλλά με πολύ σπάνιες εξαιρέσεις η συνομιλία ταιριάζει εξ ολοκλήρου στη μνήμη RAM. Έχουμε μη διατεταγμένα μηνύματα, το καθένα σε πολλά αντίγραφα - σε τελική ανάλυση, όλα προέρχονται από διαφορετικές περιπτώσεις μηχανών κειμένου που αντιστοιχούν στους χρήστες. Ο στόχος είναι να ταξινομήσετε τα μηνύματα και να απαλλαγείτε από αντίγραφα που καταλαμβάνουν περιττό χώρο.
Κάθε μήνυμα έχει μια χρονική σήμανση που περιέχει την ώρα που στάλθηκε και κείμενο. Χρησιμοποιούμε χρόνο για ταξινόμηση - τοποθετούμε δείκτες στα παλαιότερα μηνύματα συμμετεχόντων σε πολυσυζητήσεις και συγκρίνουμε κατακερματισμούς από το κείμενο των προβλεπόμενων αντιγράφων, προχωρώντας προς την αύξηση της χρονικής σήμανσης. Είναι λογικό τα αντίγραφα να έχουν τον ίδιο κατακερματισμό και χρονική σήμανση, αλλά στην πράξη αυτό δεν συμβαίνει πάντα. Όπως θυμάστε, ο συγχρονισμός στο παλιό σχήμα γινόταν από την PHP - και σε σπάνιες περιπτώσεις, ο χρόνος αποστολής του ίδιου μηνύματος διέφερε μεταξύ διαφορετικών χρηστών. Σε αυτές τις περιπτώσεις, επιτρέψαμε στον εαυτό μας να επεξεργαστεί τη χρονική σήμανση - συνήθως μέσα σε ένα δευτερόλεπτο. Το δεύτερο πρόβλημα είναι η διαφορετική σειρά των μηνυμάτων για διαφορετικούς παραλήπτες. Σε τέτοιες περιπτώσεις, επιτρέψαμε τη δημιουργία ενός επιπλέον αντιγράφου, με διαφορετικές επιλογές παραγγελίας για διαφορετικούς χρήστες.
Μετά από αυτό, τα δεδομένα σχετικά με τα μηνύματα σε multichat αποστέλλονται στη μηχανή χρήστη. Και εδώ έρχεται ένα δυσάρεστο χαρακτηριστικό των εισαγόμενων μηνυμάτων. Σε κανονική λειτουργία, τα μηνύματα που έρχονται στον κινητήρα ταξινομούνται αυστηρά σε αύξουσα σειρά από το user_local_id. Τα μηνύματα που εισήχθησαν από τον παλιό κινητήρα στη μηχανή χρήστη έχασαν αυτήν τη χρήσιμη ιδιότητα. Ταυτόχρονα, για τη διευκόλυνση των δοκιμών, πρέπει να μπορείτε να έχετε γρήγορη πρόσβαση σε αυτά, να αναζητάτε κάτι σε αυτά και να προσθέτετε νέα.
Χρησιμοποιούμε μια ειδική δομή δεδομένων για την αποθήκευση των εισαγόμενων μηνυμάτων.
Αντιπροσωπεύει ένα διάνυσμα μεγέθους πού είναι όλοι - είναι διαφορετικά και ταξινομημένα με φθίνουσα σειρά, με ειδική σειρά στοιχείων. Σε κάθε τμήμα με δείκτες τα στοιχεία ταξινομούνται. Η αναζήτηση ενός στοιχείου σε μια τέτοια δομή απαιτεί χρόνο μέσω δυαδικές αναζητήσεις. Η προσθήκη ενός στοιχείου αποσβένεται .
Έτσι, καταλάβαμε πώς να μεταφέρουμε δεδομένα από παλιούς κινητήρες σε νέους. Αλλά αυτή η διαδικασία διαρκεί αρκετές ημέρες - και είναι απίθανο κατά τη διάρκεια αυτών των ημερών οι χρήστες μας να εγκαταλείψουν τη συνήθεια να γράφουν ο ένας στον άλλο. Για να μην χάσουμε μηνύματα κατά τη διάρκεια αυτής της περιόδου, μεταβαίνουμε σε ένα σχήμα εργασίας που χρησιμοποιεί τόσο παλιά όσο και νέα συμπλέγματα.
Τα δεδομένα γράφονται στα μέλη συνομιλίας και στη μηχανή χρήστη (και όχι στη μηχανή κειμένου, όπως στην κανονική λειτουργία σύμφωνα με το παλιό σχήμα). Ο χρήστης-μηχανή διαμεσολαβεί το αίτημα για τη μηχανή συνομιλίας - και εδώ η συμπεριφορά εξαρτάται από το αν αυτή η συνομιλία έχει ήδη συγχωνευθεί ή όχι. Εάν η συνομιλία δεν έχει ακόμη συγχωνευθεί, η μηχανή συνομιλίας δεν γράφει το μήνυμα στον εαυτό της και η επεξεργασία της γίνεται μόνο στη μηχανή κειμένου. Εάν η συνομιλία έχει ήδη συγχωνευθεί στη μηχανή συνομιλίας, επιστρέφει το chat_local_id στη μηχανή χρήστη και στέλνει το μήνυμα σε όλους τους παραλήπτες. Ο χρήστης-μηχανή πραγματοποιεί μεσολάβηση όλων των δεδομένων στη μηχανή κειμένου - έτσι ώστε αν συμβεί κάτι, να μπορούμε πάντα να κάνουμε roll back, έχοντας όλα τα τρέχοντα δεδομένα στον παλιό κινητήρα. text-engine επιστρέφει user_local_id, το οποίο ο χρήστης-μηχανή αποθηκεύει και επιστρέφει στο backend.
Ως αποτέλεσμα, η διαδικασία μετάβασης μοιάζει με αυτό: συνδέουμε κενά συμπλέγματα μηχανής χρήστη και μηχανών συνομιλίας. Η μηχανή συνομιλίας διαβάζει ολόκληρο το binlog των μελών συνομιλίας και, στη συνέχεια, ξεκινά ο διακομιστής μεσολάβησης σύμφωνα με το σχήμα που περιγράφεται παραπάνω. Μεταφέρουμε τα παλιά δεδομένα και παίρνουμε δύο συγχρονισμένα cluster (παλιά και νέα). Το μόνο που μένει είναι να αλλάξετε την ανάγνωση από τη μηχανή κειμένου στη μηχανή χρήστη και να απενεργοποιήσετε το διακομιστή μεσολάβησης.
Ευρήματα
Χάρη στη νέα προσέγγιση, όλες οι μετρήσεις απόδοσης των κινητήρων έχουν βελτιωθεί και τα προβλήματα με τη συνέπεια των δεδομένων έχουν επιλυθεί. Τώρα μπορούμε να εφαρμόσουμε γρήγορα νέες δυνατότητες στα μηνύματα (και έχουμε ήδη αρχίσει να το κάνουμε αυτό - αυξήσαμε τον μέγιστο αριθμό συμμετεχόντων στη συνομιλία, πραγματοποιήσαμε αναζήτηση για προωθημένα μηνύματα, ξεκινήσαμε καρφιτσωμένα μηνύματα και αυξήσαμε το όριο του συνολικού αριθμού μηνυμάτων ανά χρήστη) .
Οι αλλαγές στη λογική είναι πραγματικά τεράστιες. Και θα ήθελα να σημειώσω ότι αυτό δεν σημαίνει πάντα ολόκληρα χρόνια ανάπτυξης από μια τεράστια ομάδα και μυριάδες γραμμές κώδικα. Η μηχανή συνομιλίας και η μηχανή χρήστη μαζί με όλες τις πρόσθετες ιστορίες όπως η Huffman για τη συμπίεση μηνυμάτων, τα δέντρα Splay και η δομή για τα εισαγόμενα μηνύματα είναι λιγότερες από 20 χιλιάδες γραμμές κώδικα. Και γράφτηκαν από 3 προγραμματιστές σε μόλις 10 μήνες (ωστόσο, αξίζει να το έχετε υπόψη σας - παγκόσμιοι πρωταθλητές ).
Επιπλέον, αντί να διπλασιάσουμε τον αριθμό των διακομιστών, μειώσαμε τον αριθμό τους στο μισό - τώρα η μηχανή χρήστη και η μηχανή συνομιλίας ζωντανά σε 500 φυσικές μηχανές, ενώ το νέο σχήμα έχει μεγάλο χώρο φόρτωσης. Εξοικονομήσαμε πολλά χρήματα σε εξοπλισμό - περίπου 5 εκατομμύρια $ + 750 χιλιάδες $ ετησίως σε λειτουργικά έξοδα.
Προσπαθούμε να βρούμε τις καλύτερες λύσεις για τα πιο περίπλοκα και μεγάλης κλίμακας προβλήματα. Έχουμε πολλά από αυτά - και γι' αυτό αναζητούμε ταλαντούχους προγραμματιστές στο τμήμα της βάσης δεδομένων. Εάν αγαπάτε και ξέρετε πώς να λύνετε τέτοια προβλήματα, έχετε άριστη γνώση αλγορίθμων και δομών δεδομένων, σας προσκαλούμε να γίνετε μέλος της ομάδας. Επικοινωνήστε μαζί μας για λεπτομέρειες.
Ακόμα κι αν αυτή η ιστορία δεν σας αφορά, σημειώστε ότι εκτιμούμε τις συστάσεις. Πείτε σε έναν φίλο για , και εάν ολοκληρώσει επιτυχώς τη δοκιμαστική περίοδο, θα λάβετε ένα μπόνους 100 χιλιάδων ρούβλια.
Πηγή: www.habr.com