CobbleDB: Αναδημιουργία αποθήκευσης αναζήτησης AI για χαμηλότερη καθυστέρηση και κόστος

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

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

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

Με τη βοήθεια ενός νέου εσωτερικού σμήνους πρακτόρων κώδικα, ξαναχτίσαμε αυτό το επίπεδο γύρω από το CobbleDB, ένα hot store ζευγών κλειδιού-τιμής, με υποστήριξη από το Pillar για ανθεκτική κατάσταση εγγράφων και δημοσίευση, και το Lorry για ομαδοποιημένες ενημερώσεις. Ο επανασχεδιασμός διαχωρίζει την επεξεργασία εγγράφων από την εισαγωγή στο hot store και μας επιτρέπει να προσαρμόσουμε την εξυπηρέτηση στο φορτίο εργασίας μας. Οι μετρήσεις παραγωγής πριν και μετά δείχνουν περίπου 5× χαμηλότερη λανθάνουσα διακοπής σε αναγνώσεις batch, και το εσωτερικό μας μοντέλο κόστους εκτιμά τουλάχιστον 20% εξοικονόμηση σε σχέση με το DynamoDB.

Υποδομή αποθήκευσης για αναζήτηση εγγενή στην τεχνητή νοημοσύνη

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

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

Δύο διακριτές ροές εργασίας

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

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

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

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

Πού υστερεί η διαχειριζόμενη βάση δεδομένων

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

Πρώτον, η τιμολόγηση βάσει χρήσης χρεώνει κάθε byte που διαβάζεται ή γράφεται. Ένα μεμονωμένο αίτημα Search API περιέχει 100-120 κλειδιά που αντιστοιχούν σε σελίδες που πρέπει να ανακτήσουμε. Η διαδικασία ανάκτησης δεδομένων χωρίζει ένα αίτημα σε μικρότερες παρτίδες 10-20 κλειδιών σελίδων, με το μέσο μέγεθος στοιχείου να είναι περίπου 50 KB. Η επαναλαμβανόμενη ανάγνωση αυτών των εγγραφών κατανάλωνε ουσιαστική χωρητικότητα, ενώ οι συνεχείς ανιχνεύσεις και οι αλλαγές στα μοντέλα κατακερματισμού ή ενσωμάτωσης παρήγαγαν περισσότερες εγγραφές. Τα οικονομικά εξαρτώνται επίσης από το μέγεθος και τη συχνότητα των εγγραφών, και όχι μόνο από τον αριθμό των κλήσεων API.

Δεύτερον, η διαχειριζόμενη υπηρεσία στερείται της ευελιξίας που χρειαζόμαστε για τη ρύθμιση της απόδοσης. Η λειτουργία που χρειαζόμασταν ήταν στενή: δεδομένης μιας παρτίδας αναγνωριστικών σελίδων, επιστρέψτε τα προετοιμασμένα περιεχόμενά τους γρήγορα. Θέλαμε έλεγχο σχετικά με το ποιο μηχάνημα κατείχε μια κατάτμηση, πόση μνήμη αφιερώθηκε στην προσωρινή μνήμη της και ποιο αντίγραφο χειρίστηκε ένα αίτημα. Αυτά τα στοιχεία ελέγχου έχουν σημασία επειδή μια μη προσωρινά αποθηκευμένη ανάγνωση, ένα πέρασμα μεταξύ ζωνών ή ένα αργό αντίγραφο μπορεί να καθυστερήσει ολόκληρη την παρτίδα. Το DynamoDB διαχειρίζεται τη δική του αποθήκευση και συμπεριφορά αντιγράφων πίσω από το API. Θα μπορούσαμε να διαμορφώσουμε την υπηρεσία, αλλά δεν μπορούσαμε να ρυθμίσουμε την εσωτερική της τοποθέτηση, τις προσωρινές μνήμες της μηχανής αποθήκευσης ή την πολιτική επιλογής αντιγράφων γύρω από τον φόρτο εργασίας μας.

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

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

Ξεχωριστή κατάσταση εγγράφων, παράδοση ενημερώσεων και εξυπηρέτηση

Η νέα αρχιτεκτονική αναθέτει κάθε ευθύνη σε διαφορετικό στοιχειό. Το Pillar διατηρεί μια ανθεκτική κατάσταση εγγράφων και αποφασίζει τι θα δημοσιεύσει. Το Lorry μετατρέπει αυτές τις εξαγωγές σε κατακερματισμένες παρτίδες. Το CobbleDB προσλαμβάνει τις παρτίδες και εξυπηρετεί προετοιμασμένες εγγραφές ανά κλειδί σελίδας.

Μεγέθυνση

CobbleDB: η ρυθμιζόμενη διαδρομή ανάγνωσης

Το CobbleDB είναι ο θερμός χώρος αποθήκευσης μας, βελτιστοποιημένος για την εξυπηρέτηση προετοιμασμένων εγγραφών κατά το χρόνο ερωτήματος. Είναι μια κατανεμημένη αποθήκη ζευγών κλειδιού-τιμής: τα κλειδιά είναι αναγνωριστικά σελίδων (URLs με κατακερματισμό hashing) και οι τιμές είναι η επεξεργασμένη αναπαράσταση της σελίδας (τα προ-κατακερματισμένα αποσπάσματα της και οι διανυσματικές ενσωματώσεις ανά τμήμα).

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

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

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

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

Ένας stateless δρομολογητής ερωτημάτων υποβάλλει σε κατακερματισμό κλειδιά σε κατατμήσεις και δρομολογεί αιτήματα σε κόμβους παράλληλα. Η αρχιτεκτονική περιλαμβάνει επίσης μια υπηρεσία μεταδεδομένων που υποστηρίζεται από PostgreSQL και ανθεκτική αποθήκευση αντικειμένων.

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

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

Μεγέθυνση

Pillar και Lorry: η ανθεκτική διαδρομή εγγραφής

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

Το Pillar υποστηρίζεται από το YTsaurus. Αποθηκεύει στοιχεία σελίδας (όπως μεταδεδομένα, τμήματα και ενσωματώσεις) σε ξεχωριστές οικογένειες πινάκων YTsaurus. Παρακολουθεί επίσης τις εκδόσεις των τμημάτων και των ενσωματώσεων, επιτρέποντας σε πολλαπλές αναπαραστάσεις να συνυπάρχουν χωρίς να αντικαθιστούν η μία την άλλη, ώστε τα υποκείμενα μοντέλα να μπορούν να αλλάζουν. Καθώς το Pillar και το YTsaurus χρησιμοποιούν φθηνή αποθήκευση HDD, μπορούμε να αποθηκεύσουμε πολλά περισσότερα έγγραφα από όσα αποθηκεύαμε προηγουμένως στο DynamoDB.

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

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

Το CobbleDB αναμένει οι ενημερώσεις να ομαδοποιούνται ανά partition. Οι εξαγωγές του Pillar μετατρέπονται σε αυτή τη μορφή από μια stateless υπηρεσία που ονομάζουμε Lorry. Η αποκλειστική της αποστολή είναι να διαβάζει εγγραφές εξαγωγής από μια μόνιμη ουρά ευθυγραμμισμένη με partitions, να τις συγκεντρώνει σε αρχεία batch ανά partition και να τα παραδίδει στο CobbleDB.

Μεταξύ του Lorry και του Cobble, ένα πρόσθετο πρωτόκολλο διαχωρίζει το επίπεδο δεδομένων (S3) από το επίπεδο ελέγχου. Το Lorry γράφει την παρτίδα στο S3 υπό ένα μοναδικό αναγνωριστικό και καταχωρεί την παρτίδα εντός του Cobble. Τα αντίγραφα κατατμήσεων του Cobble υποβάλλουν ανεξάρτητα ερώτημα στην παρτίδα ή στο API του επιπέδου ελέγχου για την επόμενη παρτίδα S3 προς πρόσληψη και εφαρμόζουν ασύγχρονα ενημερώσεις παρτίδων με χρονολογική σειρά. Αυτό σημαίνει ότι ένας αργός ή ανακτώμενος κόμβος μπορεί να προλάβει με τον δικό του ρυθμό, αντί να επιβραδύνει το υπόλοιπο σύστημα.

Μεγέθυνση

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

Επικύρωση

5x ταχύτερο

Μετά τη μετεγκατάσταση του θερμού χώρου αποθήκευσης, η διάμεση καθυστέρηση ανάγνωσης παρτίδας έπεσε από 31,4 ms σε 5,60 ms. Το p90 έπεσε από 56,7 ms σε 9,77 ms και το p99 έπεσε από 123 ms σε 24,2 ms. Οι αναλογίες κυμαίνονται από 5,08× έως 5,80×, με βελτιώσεις τόσο στα τυπικά αιτήματα όσο και στην ουρά.

Μεγέθυνση

Αυτοί οι αριθμοί προέρχονται από αναγνώσεις σε παρτίδες, όπου κάθε ερώτημα ζητά περίπου 10-15 κλειδιά. Το μέσο μέγεθος στοιχείου ωφέλιμου φορτίου είναι 50KB. Και τα δύο συστήματα δέχθηκαν ερωτήματα σε περίπου 200k rps, αν και εκτελέσαμε επίσης δοκιμές φορτίου έως 500k rps χωρίς καμία υποβάθμιση.

Για να απομονωθεί η συμβολή του CobbleDB, όλες οι άλλες πτυχές της εγκατάστασης διατηρήθηκαν σταθερές. Ωστόσο, αυτή παραμένει μια παρατηρητική σύγκριση πριν και μετά· τα συστήματα εξυπηρέτησαν ζωντανή κίνηση παραγωγής σε διαφορετικές χρονικές στιγμές και όχι τα ίδια αιτήματα υπό ελεγχόμενες συνθήκες. Επομένως, μετρήσαμε επίσης την απόδοση και των δύο συστημάτων σε ένα συνθετικό benchmark. Για να προσεγγίσουμε τα αιτήματα που παρατηρούνται στην παραγωγή, υποβάλλαμε ερωτήματα και στα δύο με παρτίδες 10-15 κλειδιών και τιμές που κυμαίνονται από 100B έως 101 KiB.

Μεγέθυνση

Το DynamoDB δυσκολεύεται σε αυτό το πλαίσιο, επειδή η διαχειριζόμενη διαδρομή ανάγνωσης δεν μπορεί να ρυθμιστεί για αναγνώσεις σε batch αυτού του μεγέθους. Αντίθετα, το CobbleDB είναι βελτιστοποιημένο ακριβώς για αυτή την περίπτωση, καθώς εμείς διαχειριζόμαστε την τοποθέτηση, την προσωρινή αποθήκευση και τους ελέγχους των αντιγράφων. Ομαδοποιεί τα κλειδιά ανά partition, εκτελεί αναγνώσεις παράλληλα σε replicas των partitions και μπορεί να αντισταθμίσει αργές αναγνώσεις με άλλα replicas. Τα αποτελέσματά μας δείχνουν ότι αυτές οι σχεδιαστικές επιλογές μεταφράζονται σε ταχύτερες αναγνώσεις σε περιβάλλον παραγωγής.

20% φθηνότερο

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

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

Πώς ένα σμήνος πρακτόρων τεχνητής νοημοσύνης μάς βοηθά να το κατασκευάσουμε

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

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

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

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

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

Συμπέρασμα

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

Καθώς συνεχίζουμε να αναπτύσσουμε εσωτερικά υποδομή εγγενή στην τεχνητή νοημοσύνη (AI-native), μπορούμε να βελτιστοποιήσουμε την απόδοση και το κόστος με τρόπους που δεν είναι δυνατοί όταν είμαστε δεμένοι σε υλοποιήσεις τρίτων και μοντέλα τιμολόγησης. Οι ισχυροί πράκτορες τεχνητής νοημοσύνης μετατοπίζουν τον υπολογισμό ακόμα περισσότερο υπέρ της κατασκευής παρά της αγοράς.

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

Παραπομπή

@online{perplexity2026Cobbledb,
  author = {{Perplexity} and Alexandr Yarats and Marco Montagna and Aleksei Bykov and Alexey Gusev and Ali Abdullaev and Amir Mokhammed-Ali and Andrey Zosimov and Denis Kremko and Gleb Vishnevsky and Micah Zirn and Phi Hoang and Claire Beamer and Jeremy Yang and Jerry Ma and Denis Yarats},
  title = {{CobbleDB: Rebuilding AI search storage for lower latency and cost}},
  date = {2026-09-14},
  url = {https://www.perplexity.ai/hub/blog/cobbledb}
}