Ακόμα από την ταινία "Our Secret Universe: The Hidden Life of the Cell"

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

Πρόσφατα, παρατηρήσαμε αύξηση της οικονομικής παιδείας του πληθυσμού. Όλο και περισσότεροι άνθρωποι ασχολούνται με τις συναλλαγές στις αγορές κινητών αξιών. Οι ατομικοί επενδυτικοί λογαριασμοί εμφανίστηκαν όχι πολύ καιρό πριν. Σας επιτρέπουν να διαπραγματεύεστε τις αγορές τίτλων και είτε να λαμβάνετε φορολογικές εκπτώσεις είτε να αποφεύγετε να πληρώνετε φόρους. Και όλοι οι πελάτες που έρχονται σε εμάς θέλουν να διαχειρίζονται το χαρτοφυλάκιό τους και να βλέπουν αναφορές σε πραγματικό χρόνο. Επιπλέον, τις περισσότερες φορές αυτό το χαρτοφυλάκιο είναι πολλαπλών προϊόντων, δηλαδή, οι άνθρωποι είναι πελάτες διαφόρων επιχειρηματικών γραμμών.

Επιπλέον, οι ανάγκες των ρυθμιστικών αρχών, τόσο Ρώσων όσο και ξένων, αυξάνονται.

Чтобы соответствовать текущим потребностям и заложить фундамент для будущих модернизаций, мы разработали ядро инвест-бизнеса на основе Tarantool.

Μερικά στατιστικά στοιχεία. Η επενδυτική δραστηριότητα της Alfa-Bank παρέχει υπηρεσίες μεσιτείας σε φυσικά και νομικά πρόσωπα για την παροχή ευκαιρίας συναλλαγών σε διάφορες αγορές τίτλων, υπηρεσίες αποθετηρίου για την αποθήκευση τίτλων, υπηρεσίες διαχείρισης καταπιστεύματος για ιδιώτες με ιδιωτικό και μεγάλο κεφάλαιο, υπηρεσίες έκδοσης τίτλων για άλλες εταιρείες . Η επενδυτική δραστηριότητα της Alfa-Bank περιλαμβάνει περισσότερες από 3 χιλιάδες προσφορές ανά δευτερόλεπτο, οι οποίες κατεβαίνουν από διάφορες πλατφόρμες συναλλαγών. Κατά τη διάρκεια της εργάσιμης ημέρας, πραγματοποιούνται στις αγορές περισσότερες από 300 χιλιάδες συναλλαγές για λογαριασμό της τράπεζας ή των πελατών της. Έως και 5 χιλιάδες εκτελέσεις παραγγελιών ανά δευτερόλεπτο συμβαίνουν σε εξωτερικές και εσωτερικές πλατφόρμες. Ταυτόχρονα, όλοι οι πελάτες, εσωτερικοί και εξωτερικοί, θέλουν να βλέπουν τις θέσεις τους σε πραγματικό χρόνο.

Ιστορικό

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

Επιπλέον, η βάση κωδικών των συστημάτων είναι ήδη αρκετά ξεπερασμένη, επειδή ορισμένα προϊόντα προέρχονται από τα μέσα της δεκαετίας του 1990. Και σε ορισμένους τομείς αυτό επιβράδυνε τη διαδικασία ανάπτυξης και υπήρχαν προβλήματα απόδοσης.

Απαιτήσεις για μια νέα λύση

Οι επιχειρήσεις έχουν συνειδητοποιήσει ότι ο τεχνολογικός μετασχηματισμός είναι ζωτικής σημασίας για περαιτέρω ανάπτυξη. Μας δόθηκαν καθήκοντα:

1. Συλλέξτε όλα τα επιχειρηματικά δεδομένα σε μια ενιαία, γρήγορη αποθήκευση και σε ένα ενιαίο μοντέλο δεδομένων.
2. Δεν πρέπει να χάσουμε ή να αλλάξουμε αυτές τις πληροφορίες.
3. Είναι απαραίτητη η έκδοση των δεδομένων, διότι ανά πάσα στιγμή η ρυθμιστική αρχή μπορεί να ζητήσει στατιστικά στοιχεία για τα προηγούμενα έτη.
4. Δεν πρέπει απλώς να φέρουμε μερικά νέα, μοντέρνα DBMS, αλλά να δημιουργήσουμε μια πλατφόρμα για την επίλυση επιχειρηματικών προβλημάτων.

Επιπλέον, οι αρχιτέκτονές μας θέτουν τους δικούς τους όρους:

1. Η νέα λύση πρέπει να είναι business-class, δηλαδή να έχει ήδη δοκιμαστεί σε κάποιες μεγάλες εταιρείες.
2. Ο τρόπος λειτουργίας της λύσης θα πρέπει να είναι κρίσιμος για την αποστολή. Αυτό σημαίνει ότι πρέπει να είμαστε παρόντες σε πολλά κέντρα δεδομένων ταυτόχρονα και να επιβιώσουμε ήρεμα από τη διακοπή λειτουργίας ενός κέντρου δεδομένων.
3. Το σύστημα πρέπει να είναι οριζόντια κλιμακούμενο. Γεγονός είναι ότι όλα τα τρέχοντα συστήματά μας είναι μόνο κατακόρυφα κλιμακούμενα και ήδη φτάνουμε στο ανώτατο όριο λόγω της χαμηλής αύξησης της ισχύος υλικού. Ως εκ τούτου, έχει έρθει η στιγμή που πρέπει να έχουμε ένα οριζόντια επεκτάσιμο σύστημα για να επιβιώσουμε.
4. Μεταξύ άλλων, μας είπαν ότι η λύση έπρεπε να είναι φθηνή.

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

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

Δεν θα σας πω πώς δοκιμάσαμε τα πάντα και πόσο χρόνο χρειάστηκε, απλώς θα συνοψίσω: η καλύτερη απόδοση στις δοκιμές φόρτωσης έδειξε μια πρωτότυπη λύση βασισμένη στο Tarantool από την ομάδα ανάπτυξης του Mail.ru Group. Υπογράψαμε μια συμφωνία και ξεκινήσαμε την ανάπτυξη. Υπήρχαν τέσσερα άτομα από τον Όμιλο Mail.ru και από την Alfa-Bank υπήρχαν τρεις προγραμματιστές, τρεις αναλυτές συστημάτων, ένας αρχιτέκτονας λύσεων, ένας ιδιοκτήτης προϊόντος και ένας κύριος Scrum.

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

Ανάπτυξη

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

Χρησιμοποιούμε τον ενσωματωμένο διακομιστή HTTP στο Tarantool επειδή δεν χρειάζεται να τερματίσουμε τις συνεδρίες SSL και η απόδοσή του είναι αρκετή για εμάς.

Όπως είπα ήδη, όλα τα συστήματά μας ζουν σε διαφορετικά μοντέλα δεδομένων και στην είσοδο πρέπει να φέρουμε το αντικείμενο στο μοντέλο που περιγράφουμε οι ίδιοι. Χρειαζόταν μια γλώσσα που να επιτρέπει τη μετατροπή των δεδομένων. Επιλέξαμε επιτακτικό Lua. Εκτελούμε όλο τον κώδικα μετατροπής δεδομένων σε ένα sandbox - αυτό είναι ένα ασφαλές μέρος πέρα ​​από το οποίο ο τρέχων κώδικας δεν πηγαίνει. Για να γίνει αυτό, απλώς φορτώνουμε τον απαιτούμενο κώδικα, δημιουργώντας ένα περιβάλλον με συναρτήσεις που δεν μπορούν να αποκλείσουν ή να απορρίψουν τίποτα.

Μετά τη μετατροπή, τα δεδομένα πρέπει να ελεγχθούν για συμμόρφωση με το μοντέλο που δημιουργούμε. Συζητήσαμε για αρκετή ώρα ποιο πρέπει να είναι το μοντέλο και ποια γλώσσα να χρησιμοποιήσουμε για να το περιγράψουμε. Επιλέξαμε το Apache Avro γιατί η γλώσσα είναι απλή και έχει υποστήριξη από το Tarantool. Οι νέες εκδόσεις του μοντέλου και του προσαρμοσμένου κώδικα μπορούν να τεθούν σε λειτουργία πολλές φορές την ημέρα, ακόμη και υπό φορτίο ή χωρίς, οποιαδήποτε στιγμή της ημέρας, και να προσαρμοστούν στις αλλαγές πολύ γρήγορα.

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

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

Τώρα πρέπει να μάθετε πώς να ανακτάτε αποθηκευμένα δεδομένα. Αναλύσαμε προσεκτικά τα συστήματά μας και είδαμε ότι η κλασική στοίβα Java και Oracle περιέχει απαραίτητα κάποιο είδος ORM που μετατρέπει δεδομένα από σχεσιακά σε αντικείμενο. Γιατί λοιπόν να μην δώσουμε αμέσως αντικείμενα σε συστήματα με τη μορφή γραφήματος; Έτσι υιοθετήσαμε με χαρά το GraphQL, το οποίο κάλυπτε όλες τις ανάγκες μας. Σας επιτρέπει να λαμβάνετε δεδομένα με τη μορφή γραφημάτων και να βγάζετε μόνο ό,τι χρειάζεστε αυτήν τη στιγμή. Μπορείτε ακόμη και να εκδώσετε το API με αρκετή ευελιξία.

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

Εφάρμοσε ένα σύστημα ελέγχου ταυτότητας.

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

• T-Connect: χειρίζεται τις εισερχόμενες συνδέσεις, περιορισμένη CPU, χαμηλή κατανάλωση μνήμης, ανικανότητα.
• IB-Core: μετατρέπει τα δεδομένα που λαμβάνει μέσω του πρωτοκόλλου Tarantool, λειτουργεί δηλαδή με πίνακες. Επίσης, δεν αποθηκεύει κατάσταση και είναι επεκτάσιμο.
• Αποθήκευση: αποθηκεύει μόνο δεδομένα, δεν χρησιμοποιεί καμία λογική. Αυτός ο ρόλος υλοποιεί τις απλούστερες διεπαφές. Επεκτάσιμο χάρη στο vshard.

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

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

Δοκιμές

С самого начала проекта решили, что будем пытаться насаждать test driven development. Модульные тесты мы пишем на Lua с помощью фреймворка tarantool/tap, интеграционные — на Python с помощью фреймворка pytest. При этом в написание интеграционных тестов у нас вовлечены и разработчики, и аналитики.

Πώς χρησιμοποιούμε τη δοκιμαστική ανάπτυξη;

Αν θέλουμε κάποιο νέο χαρακτηριστικό, προσπαθούμε να γράψουμε πρώτα μια δοκιμή για αυτό. Όταν ανακαλύπτουμε ένα σφάλμα, φροντίζουμε πρώτα να γράψουμε ένα τεστ και μόνο μετά να το διορθώσουμε. Στην αρχή είναι δύσκολο να δουλεύεις έτσι, υπάρχει παρεξήγηση από την πλευρά των εργαζομένων, ακόμη και δολιοφθορά: «Ας το διορθώσουμε γρήγορα τώρα, ας κάνουμε κάτι νέο και μετά το καλύψουμε με δοκιμές». Μόνο που αυτό το «αργότερα» σχεδόν ποτέ δεν έρχεται.

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

Ωστόσο, αυτό που αγαπάμε περισσότερο είναι η δοκιμή φορτίου· τη θεωρούμε την πιο σημαντική και την εκτελούμε τακτικά.

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

Ήμασταν πολύ λυπημένοι. Εξετάζουμε τη φόρτωση του διακομιστή, αλλά αποδεικνύεται ότι είναι αδρανείς.

Звоним разработчикам, а они объясняют нам, людям, пришедшим из мира Java, что Tarantool однопоточный. Его может эффективно использовать только одно ядро процессора под нагрузкой. Тогда мы развернули на каждом сервере максимально возможное количество инстансов Tarantool, включили нагрузку и получили уже 14,5 тыс. транзакций в секунду.

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

Σε αυτήν την περίπτωση, η μνήμη χρησιμοποιήθηκε μόνο για την επεξεργασία εισερχόμενων συνδέσεων και προσωρινών αντικειμένων.

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

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

Υπηρεσίες

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

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

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

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

Παλιά συστήματα

Δεν μπορούν όλα τα παλαιού τύπου μας συστήματα να μας καλούν μέσω HTTP και να χρησιμοποιούν GraphQL, αν και υποστηρίζουν το πρωτόκολλο. Επομένως, δημιουργήσαμε έναν μηχανισμό που επιτρέπει την αναπαραγωγή δεδομένων σε αυτά τα συστήματα.

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

Νέες βελτιώσεις

Όπως θυμάστε, από επιχειρηματικής πλευράς, κάναμε ασύγχρονη ηχογράφηση. Στη συνέχεια όμως συνειδητοποίησαν ότι δεν θα ήταν αρκετό, γιατί υπάρχει μια κατηγορία συστημάτων που πρέπει να λάβουν αμέσως απάντηση σχετικά με την κατάσταση της λειτουργίας. Έτσι επεκτείναμε το GraphQL μας και προσθέσαμε μεταλλάξεις. Ταιριάζουν οργανικά στο υπάρχον παράδειγμα εργασίας με δεδομένα. Για εμάς, αυτό είναι ένα μόνο σημείο ανάγνωσης και γραφής για μια άλλη κατηγορία συστημάτων.

Καταλάβαμε επίσης ότι οι υπηρεσίες από μόνες τους δεν θα ήταν αρκετές για εμάς, γιατί υπάρχουν αρκετά βαριές αναφορές που πρέπει να φτιάχνονται μία φορά την ημέρα, την εβδομάδα, το μήνα. Αυτό μπορεί να διαρκέσει πολύ και οι αναφορές μπορούν ακόμη και να αποκλείσουν τον βρόχο συμβάντων του Tarantool. Επομένως, δημιουργήσαμε ξεχωριστούς ρόλους: χρονοπρογραμματιστή και δρομέα. Οι δρομείς δεν αποθηκεύουν κατάσταση. Εκτελούν βαριές εργασίες που δεν μπορούμε να υπολογίσουμε εν κινήσει. Και ο ρόλος του χρονοπρογραμματιστή παρακολουθεί το χρονοδιάγραμμα εκκίνησης αυτών των εργασιών, το οποίο περιγράφεται στη διαμόρφωση. Οι ίδιες οι εργασίες αποθηκεύονται στον ίδιο χώρο με τα επιχειρηματικά δεδομένα. Όταν έρθει η κατάλληλη ώρα, ο προγραμματιστής αναλαμβάνει την εργασία, τη δίνει σε κάποιον δρομέα, ο οποίος τη μετράει και αποθηκεύει το αποτέλεσμα.

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

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

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

Συμπέρασμα

Ξεκινήσαμε με το έργο της φόρτωσης δεδομένων σε ένα ενιαίο μοντέλο και αφιερώσαμε τρεις μήνες για να το αναπτύξουμε. Είχαμε έξι συστήματα παροχής δεδομένων. Ολόκληρος ο κωδικός μετατροπής σε ένα μόνο μοντέλο είναι περίπου 30 χιλιάδες γραμμές στο Lua. Και το μεγαλύτερο μέρος της δουλειάς είναι ακόμα μπροστά. Μερικές φορές υπάρχει έλλειψη κινήτρων από γειτονικές ομάδες και υπάρχουν πολλές συνθήκες που περιπλέκουν τη δουλειά. Εάν αντιμετωπίσετε ποτέ μια παρόμοια εργασία, τότε πολλαπλασιάστε τον χρόνο που σας φαίνεται φυσιολογικός για την υλοποίησή του επί τρεις ή και τέσσερις.

Θυμηθείτε επίσης ότι τα υπάρχοντα προβλήματα στις επιχειρηματικές διαδικασίες δεν μπορούν να επιλυθούν χρησιμοποιώντας ένα νέο ΣΔΒΔ, ακόμη και ένα πολύ παραγωγικό. Τι εννοώ? Στην αρχή του έργου μας, δημιουργήσαμε την εντύπωση στους πελάτες ότι τώρα θα φέρουμε μια νέα γρήγορη βάση δεδομένων και θα ζήσουμε! Οι διαδικασίες θα πάνε πιο γρήγορα, όλα θα πάνε καλά. Στην πραγματικότητα, η τεχνολογία δεν λύνει τα προβλήματα που έχουν οι επιχειρηματικές διαδικασίες, γιατί οι επιχειρηματικές διαδικασίες είναι άνθρωποι. Και πρέπει να συνεργαστείς με ανθρώπους, όχι με τεχνολογία.

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

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

Δεν υπάρχει τίποτα κακό με τον Λούα. Οποιοσδήποτε μπορεί να μάθει να γράφει σε αυτό: προγραμματιστής Java, προγραμματιστής JavaScript, προγραμματιστής Python, front-end ή back-end. Ακόμη και οι αναλυτές μας γράφουν σε αυτό.

Όταν μιλάμε για το γεγονός ότι δεν έχουμε SQL, τρομάζει τους ανθρώπους. «Πώς λαμβάνετε δεδομένα χωρίς SQL; Είναι αυτό εφικτό? Σίγουρα. Σε ένα σύστημα κλάσης OLTP, δεν απαιτείται SQL. Υπάρχει μια εναλλακτική με τη μορφή κάποιας γλώσσας που σας επιστρέφει αμέσως σε μια προβολή προσανατολισμένη στα έγγραφα. Για παράδειγμα, GraphQL. Και υπάρχει μια εναλλακτική με τη μορφή κατανεμημένων υπολογιστών.

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

Πηγή: www.habr.com