de.wedoany.com-Bericht: Google hat in der Vorschauversion für AlloyDB eine durch die Columnar Engine beschleunigte HNSW-Funktion eingeführt und gibt an, dass der Durchsatz von Vektorsuchen um bis zu das Vierfache gesteigert werden kann.
AlloyDB ist ein von Google verwalteter, PostgreSQL-kompatibler Datenbankdienst. Die neue Option richtet sich an pgvector-Nutzer – eine PostgreSQL-Erweiterung zum Speichern, Indizieren und Abfragen von Vektoreinbettungen für Künstliche Intelligenz-Anwendungen – insbesondere an Teams, die HNSW (Hierarchical Navigable Small World) für die annähernde Suche nach nächsten Nachbarn in extrem großen Datensätzen verwenden.
Die neue Option nutzt die Columnar Engine von AlloyDB – einen In-Memory-Cache, der häufig abgefragte Daten im Spaltenformat speichert – um HNSW-Indizes im Arbeitsspeicher zu halten und so einige der Overheads des standardmäßigen PostgreSQL-Puffermanagements zu vermeiden. Google gibt an, dass dies den Durchsatz und die Recall-Rate (ein Maß für die Anzahl relevanter Treffer in den Suchergebnissen) verbessert. In Benchmarks mit dem GloVe 100 Angular-Datensatz mit über einer Million Einträgen stieg die Anzahl der Abfragen pro Sekunde um etwa das 4,2- bis 4,9-Fache, wenn die Suche auf 100 Ergebnisse begrenzt und eine Ziel-Recall-Rate von 0,95 angestrebt wurde. Bei gleichem Durchsatz verbesserte sich auch die Recall-Rate: Bei etwa 350 Abfragen pro Sekunde stieg die Recall-Rate mit aktivierter Columnar Engine von etwa 0,78 auf über 0,94, eine Steigerung um 0,163.
Zur Funktionsweise: Standard-PostgreSQL ist für Indexoperationen auf den Shared Buffer Cache angewiesen, selbst wenn die Daten bereits im Arbeitsspeicher sind. Dieser Prozess umfasst immer noch das Fixieren und Entfixieren von Seiten, Lock-Verwaltung, Puffertabellensuche und Least-Recently-Used-Management, was während der Graphdurchquerung zu Latenz und Ineffizienz führen kann. AlloyDB ändert diesen Pfad, indem es den pgvector-HNSW-Index direkt im Speicherbereich der Columnar Engine fixiert und ein speziell für das intensive Zeiger-Traversal-Muster von HNSW optimiertes Speicherlayout verwendet, wodurch die üblichen Engpässe des Puffermanagers umgangen werden. Google betont, dass diese Verbesserung nicht allein durch das Verschieben von Daten von der Festplatte in den RAM erzielt wird; die Basislinie für den Vergleich ging bereits davon aus, dass der Standard-PostgreSQL-Index vollständig im Shared Buffer zwischengespeichert ist, was bedeutet, dass die berichtete Leistungssteigerung auf die unterschiedliche Speicherarchitektur und nicht auf grundlegendes Caching zurückzuführen ist.
Diese Veröffentlichung spiegelt den wachsenden Druck auf Datenbankanbieter wider, Retrieval-Augmented Generation und andere KI-Workloads zu unterstützen, die auf Vektorsuche angewiesen sind. In diesen Systemen müssen Betreiber oft Geschwindigkeit und Genauigkeit beim Durchsuchen von Millionen oder Milliarden von Vektoren abwägen, insbesondere unter Produktionslast. Für PostgreSQL-Nutzer hat sich pgvector zu einem der am weitesten verbreiteten Tools in diesem Bereich entwickelt, da es Vektorfunktionen innerhalb des bestehenden relationalen Datenbank-Stacks ermöglicht. HNSW ist eine beliebte Indexierungsmethode in pgvector, da sie eine annähernde Suche mit geringerer Latenz als exakte k-nächste-Nachbarn-Verfahren bietet, obwohl Betreiber in der Regel einen gewissen Kompromiss bei der Recall-Rate eingehen.
Google positioniert AlloyDB als eine Datenbank, die relationale Transaktionen, Analysen und Vektorsuche im selben System verarbeiten kann. Neben HNSW unterstützt der Dienst auch ScaNN (eine weitere Vektorindex-Option), während die standardmäßige k-nächste-Nachbarn-Suche weiterhin für Nutzer verfügbar ist, die eine vollständige Recall-Rate benötigen.
Hinsichtlich der betrieblichen Abwägungen verbraucht die Columnar Engine Arbeitsspeicher, was für Datenbankbetreiber, die Kosten und Instanzgrößen verwalten, ein praktischer Faktor bleibt. Google gibt an, dass der Speicherverbrauch begrenzt ist, da die Engine Vektordaten in einem komprimierten Spaltenformat speichert. Google ist der Ansicht, dass dieser Kompromiss es ermöglicht, ein bestimmtes Niveau der Vektorsuchleistung mit weniger Rechenressourcen zu erreichen, wodurch der Infrastrukturbedarf reduziert wird. Die Funktion erfordert keine Änderungen am Anwendungscode, da Nutzer weiterhin die standardmäßige pgvector-SQL-Syntax verwenden können. Um die Funktion zu nutzen, müssen AlloyDB-Nutzer auf ihrer Instanz die Flags für die Columnar Engine und den Index-Cache aktivieren, nach der Erstellung eines HNSW-Index über pgvector den Index dann über einen SQL-Befehl zum Cache der Columnar Engine hinzufügen.
Diese Veröffentlichung bietet Google eine weitere Möglichkeit, AlloyDB zu differenzieren, in einem wachsenden Markt für Datenbanken, die an KI-Workloads angepasst sind, wo Cloud-Anbieter und spezialisierte Datenbankteams in Bezug auf Durchsatz, Latenz und Suchqualität konkurrieren. Die von Google zitierten Benchmarks wurden auf einer AlloyDB C4A-Maschine mit 16 virtuellen CPUs durchgeführt.
