Η Databricks φέρνει την αναζήτηση πλήρους κειμένου και διανυσματική στο Lakebase Postgres

Databricks στις 28 Σεπτεμβρίου 2026, παρουσίασε το Lakebase Search, μια ενσωματωμένη μηχανή αναζήτησης για τη βάση δεδομένων Lakebase Postgres που παρέχεται μέσω δύο επεκτάσεων: lakebasevector για αναζήτηση προσεγγιστικού πλησιέστερου γειτόνου και lakebasetext για αναζήτηση πλήρους κειμένου BM25. Και οι δύο επεκτάσεις είναι γενικά διαθέσιμες στο AWS και το Azure.

Οι επεκτάσεις επιτρέπουν στους προγραμματιστές να εκτελούν σημασιολογική, λέξη‑κλειδί και υβριδική αναζήτηση απευθείας μέσα στο Postgres παράλληλα με τα λειτουργικά δεδομένα. Η Databricks δήλωσε ότι τα παραδοσιακά συστήματα OLTP δεν έχουν σχεδιαστεί για τις απαιτήσεις αναζήτησης των AI agents, που απαιτούν χαμηλή καθυστέρηση, υψηλή ακρίβεια ανάκτησης και συχνά εκτελούν τεράστιες παράλληλες αναζητήσεις, και ότι η επίλυση αυτού μέχρι τώρα σήμαινε την προσθήκη μιας αυτόνομης μηχανής αναζήτησης στη βασική βάση δεδομένων μέσω μιας ETL pipeline. Η εταιρεία δήλωσε ότι ανέπτυξε το Lakebase Search παράλληλα με τα σχόλια από εκατοντάδες beta πελάτες.

Αποτελέσματα Benchmark και η Ανάπτυξη Conexiom

Η Databricks δήλωσε ότι το lakebase_vector προσφέρει διπλάσια απόδοση από το επόμενο καλύτερο σύστημα στο benchmark VectorDBBench 100M, που χρησιμοποιεί το σύνολο δεδομένων LAION, και ότι είναι τέσσερις φορές φθηνότερο από έναν πάροχο cloud Postgres που χρησιμοποιεί pgvector, πριν από τις πρόσθετες εξοικονομήσεις από την αυτόματη κλιμάκωση. Η εταιρεία ανέφερε καθυστέρηση P99 71 χιλιοστών του δευτερολέπτου με 97 % recall, πράγμα που σημαίνει ότι η μηχανή ανεύρεσε επιτυχώς τους πραγματικούς πλησιέστερους γείτονες το 97 % του χρόνου, και σημείωσε ότι τα pgvector και DiskANN δοκιμάστηκαν μόνο σε μία μεγάλη παρουσία.

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

«Το Lakebase Search μας προσφέρει ένα εντελώς νέο επίπεδο κλιμακωσιμότητας σε σχέση με το pgvector και ανοίγει το BM25 στην ίδια serverless βάση δεδομένων», δήλωσε ο Jordan Voves, αρχιτέκτονας AI/ML στην Conexiom. «Χρησιμοποιούμε το Lakebase για να συνδέσουμε τα δεδομένα με τους πράκτορές μας σε κλίμακα».

Οι περιορισμοί του Pgvector πίσω από το σχεδιασμό

Η Databricks δήλωσε ότι το pgvector είναι η πιο εγκατεστημένη επέκταση στο Lakebase Postgres και περιέγραψε τρία επαναλαμβανόμενα προβλήματα που παρατηρούνται από πελάτες που το χρησιμοποιούν σε κλίμακα.

Το πρώτο είναι το κόστος που κλιμακώνεται με τον όγκο των δεδομένων αντί με τη χρήση. Το pgvector διατηρεί το ευρετήριο HNSW στη μνήμη της βάσης δεδομένων, και επειδή η αναζήτηση HNSW βασίζεται σε τυχαία πρόσβαση στο γράφημα, η απόδοση μειώνεται κατά παράγοντα 10 έως 50 όταν το ευρετήριο μεταφέρεται στο δίσκο και τα ερωτήματα γίνονται αλυσίδες τυχαίων αναγνώσεων. Ένα διανύσμα float32 768‑διάστασης καταλαμβάνει περίπου 3,3 kilobytes μνήμης όταν συμπεριληφθούν οι συνδέσεις του γραφήματος και το κόστος λειτουργίας του Postgres, έτσι ένα ευρετήριο πάνω από 100 εκατομμύρια γραμμές απαιτεί περίπου 330 gigabytes RAM για να παραμείνει ενεργό, προμηθευμένο πλήρως ανεξάρτητα αν τα ερωτήματα το χρησιμοποιούν ή όχι.

Ο δεύτερος είναι η συντήρηση του ευρετηρίου. Όταν μια δημιουργία μεταφέρθηκε στο δίσκο, ένα ευρετήριο pgvector χρειάστηκε σχεδόν 50 ώρες για να κατασκευαστεί σε μια τυπική cloud παρουσία, δήλωσε η Databricks, και οι εγγραφές υφίστανται το ίδιο εμπόδιο επειδή η εισαγωγή ενός διανύσματος απαιτεί τυχαία πρόσβαση και τροποποίηση πολλαπλών επιπέδων του γραφήματος. Δεδομένου ότι το HNSW δεν διαθέτει παγκόσμια εξισορρόπηση, η αποκατάσταση της ποιότητας αναζήτησης σημαίνει εκτέλεση πλήρους REINDEX, μια λειτουργία που κλειδώνει τον πίνακα και σταματά τις παραγωγικές εγγραφές.

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

Πώς κατασκευάζεται το Lakebase_vector

Το Lakebase Postgres διαχωρίζει την αποθήκευση από την επεξεργασία: τα μόνιμα δεδομένα αποθηκεύονται σε οικονομική αποθήκευση αντικειμένων στο cloud, ενώ η RAM και το τοπικό NVMe λειτουργούν ως βραχυπρόθεσμες κρυφές μνήμες που διατηρούν το ενεργό σύνολο εργασίας. Στην βάση αυτή, η Databricks συνδύασε δύο τεχνικές.

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

Επειδή ο σχεδιασμός είναι χωρίς κατάσταση, κλιμακώνεται στο μηδέν και, όταν δεν χρησιμοποιείται, οι χρήστες πληρώνουν μόνο για την αποθήκευση. Η Databricks ανέφερε ότι μετρήθηκε P90 1,13 δευτερόλεπτα για το πρώτο ερώτημα μετά την κλιμάκωση στο μηδέν σε σύνολο δεδομένων 100 εκατομμυρίων διανυσμάτων, 768‑διάστατο, και δήλωσε ότι 100 εκατομμύρια διανύσματα μπορούν να εξυπηρετηθούν από μία Lakebase Compute Unit.

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

BM25 Αναζήτηση Κειμένου και Υβριδικά Ερωτήματα

Η Databricks ανέφερε ότι η τυπική αναζήτηση tsvector του Postgres δεν παρέχει συμφραζόμενα σχετικότητας σε ολόκληρο το σύνολο δεδομένων. Η lakebase_text βαθμολογεί τους όρους χρησιμοποιώντας την παγκόσμια αντίστροφη συχνότητα εγγράφου, δίνοντας μεγαλύτερο βάρος σε σπάνιους, υψηλής πρόθεσης όρους και λιγότερο σε κοινές λέξεις-γέμισμα. Επίσης ελέγχει τα ανώτατα όρια βαθμολογίας καθώς διασχίζει το ευρετήριο, απορρίπτοντας ολόκληρα μπλοκ καταχωρίσεων που δεν μπορούν να επηρεάσουν το αποτέλεσμα top‑K, κάτι που, σύμφωνα με την εταιρεία, το καθιστά ταχύτερο από το tsvector με ευρετήρια GIN.

Ο συνδυασμός των δύο επεκτάσεων επιτρέπει την εγγενή υβριδική αναζήτηση μέσα στο Postgres: ένα μοναδικό ερώτημα μπορεί να εφαρμόσει κανονικές προδιαγραφές φίλτρου SQL, να ενώσει ζωντανά λειτουργικά πίνακες και να συγχωνεύσει τη βαθμολόγηση σημασιολογικών διανυσμάτων με τη σχετικότητα λέξεων-κλειδιών BM25. Η Databricks δήλωσε ότι το σύστημα κλιμακώνεται από μία γραμμή σε ένα δισεκατομμύριο διανύσματα και από ένα ερώτημα ανά δευτερόλεπτο σε χιλιάδες χωρίς χειροκίνητη επαναπροσαρμογή, περιγράφοντας το σχεδιασμό ως προορισμένο για πράκτορες AI των οποίων οι ροές εργασίας μπορούν να προκαλέσουν χιλιάδες ταυτόχρονες αιτήσεις ανάκτησης μέσα σε δευτερόλεπτα.

Η Databricks τοποθετεί το Lakebase Search για χρήστες που επιθυμούν λειτουργικά και δεδομένα αναζήτησης ενοποιημένα σε μία βάση δεδομένων, ενώ το Databricks AI Search παραμένει η διαχειριζόμενη μηχανή ανάκτησης που λειτουργεί έτοιμη για χρήση. Το Lakebase Search είναι γενικά διαθέσιμο σε AWS και Azure· οι υπάρχοντες χρήστες του Lakebase μπορούν να ενεργοποιήσουν τις επεκτάσεις, και νέοι χρήστες μπορούν να εγγραφούν στο Lakebase.