Vector ist das neue JSON von PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

Vektoren sind gut erforschte mathematische Strukturen, JSON ist ein Format für den Datenaustausch In der Welt der Datenspeicherung und -suche sind beide Arten der Datenrepräsentation jedoch zu einer gemeinsamen Sprache geworden und werden bei der Entwicklung moderner Anwendungen bald unverzichtbare Elemente sein Wenn sich der aktuelle Trend fortsetzt, werden Vektoren beim Bau von Anwendungen ebenso wichtig wie JSON PostgreSQL wurde zur natürlichen Wahl, um die Ergebnisse generativer KI zu speichern und abzufragen Das ist jedoch kein neues Datenmuster. Vektoren als mathematisches Konzept existieren bereits seit Jahrhunderten Arrays als grundlegende Datenstruktur von Vektoren werden in den meisten Einführungskursen der Informatik gelehrt. PostgreSQL unterstützt seit über 20 Jahren Vector-Operationen Was ist also neu? Es geht darum, wie "zugänglich" diese KI/ML-Algorithmen sind und wie "leicht möglich" es ist, bestimmte Strukturen der "realen Welt" (Text, Bilder, Video) als Vektoren darzustellen und später in Anwendungen zu verwenden Auch das Speichern der Ausgaben solcher Systeme ("Embeddings") in einem Datenspeicher ist streng genommen nicht neu, aber das neue Muster ist die "Zugänglichkeit", diese Daten in fast Echtzeit in allen Anwendungen abzufragen und zurückzugeben Was hat das also mit PostgreSQL zu tun? Ein gemeinsames Muster zur effizienten Speicherung und Suche von Datentypen hat die App-Entwicklung stark vereinfacht und es Menschen ermöglicht, Daten im gleichen System zu speichern und mit vorhandenen Tools zu bearbeiten Vor 10 Jahren haben wir das mit JSON gesehen, und jetzt beobachten wir dieses Muster bei Vektordaten Eine kurze Geschichte von JSON in PostgreSQL (Siehe Originalartikel) Der Aufstieg der Vektoren als "neue Art von JSON" Die Popularität steigt derzeit stark an Ein typischer Anwendungsfall ist, auf gespeicherten Daten ein Modell aufzubauen, diese in ein Vektorformat umzuwandeln und dann für die "semantische Suche" zu nutzen In diesem Fall wird eine neue Suchanfrage in ein Vektorformat umgewandelt und dann in der Datenbank nach dem ähnlichsten Eintrag gesucht Die Ähnlichkeit wird mit Distanzfunktionen wie euklidischer Distanz oder Kosinusdistanz berechnet; die Ergebnisse werden oft auf k-NN (Nearest Neighbors) oder die k ähnlichsten Objekte begrenzt Da das Kodieren des Trainingssatzes von Vektoren viel Zeit kosten kann, ist es sinnvoll, ihn an einem Ort wie einer Datenbank zu cachen und dort k-NN-Abfragen auszuführen Da es für Nutzer in der Regel eine bessere Erfahrung bietet, eine Menge von Vektoren bereitzuhalten, die für semantische Suche sofort abfragbar sind, entstand der Bedarf an einer "Vektordatenbank" Die Speicherung von Vektoren ist für PostgreSQL nichts Neues Tatsächlich ist der Begriff etwas irreführend, da PostgreSQL mehrdimensionale Daten (z. B. Matrizen) speichern kann Standardmäßig enthalten die Arrays von PostgreSQL zwar nur begrenzte Funktionen für Vektoren, etwa die Berechnung der "Distanz" zwischen zwei Arrays Man kann Stored Procedures schreiben, aber das erfordert etwas mehr Arbeit von Entwicklern Glücklicherweise überwindet der Datentyp cube diese Einschränkungen cube wird seit über 20 Jahren verwendet und wurde dafür entworfen, Operationen auf hochdimensionalen Vektoren auszuführen cube enthält die meisten gängigen Distanzfunktionen, die für die Suche nach Vektorähnlichkeit verwendet werden, einschließlich euklidischer Distanz Mit GiST-Indizes lassen sich auch effiziente K-NN-Abfragen ausführen Allerdings kann cube nur Vektoren mit bis zu 100 Dimensionen speichern, während moderne KI/ML-Systeme mehr verlangen pgvector: Open-Source-Erweiterung zum Speichern und Suchen von Vektoren in PostgreSQL Mit pgvector lassen sich Vektoren speichern und k-NN-Abfragen mit verschiedenen Distanzmetriken ausführen (euklidisch, Kosinus, inneres Produkt usw.) Derzeit wird pvector zusammen mit einem Index ivfflat ausgeliefert, der die IVR-FLAT-Methode für die Vektorindizierung implementiert Das Abfragen indizierter Vektordaten kann sich von der Abfrage gewöhnlicher Daten unterscheiden Wegen der Kosten einer Nearest-Neighbor-Suche in hochdimensionalen Vektoren liefern viele Methoden zur Vektorindizierung "annähernde" Antworten, die der korrekten Antwort "nahe genug" sind Daraus entstand der Bereich der "ANN (Approximate Nearest Neighbor)"-Suche Bei ANN-Abfragen betrachten Nutzer meist zwei Dimensionen: Leistung und "Recall" (der Prozentsatz relevanter Ergebnisse, die zurückgegeben werden) Am Beispiel von ivfflat: Beim Erstellen eines ivfflat-Index wird entschieden, wie viele Listen enthalten sein sollen Jede Liste repräsentiert ein "Zentrum", das mit dem k-means-Algorithmus berechnet wird Sobald alle Zentren bestimmt sind, ermittelt ivfflat für jeden Vektor das nächstgelegene Zentrum und fügt ihn dem Index hinzu Wenn Vektordaten abgefragt werden, wird über die Variable ivfflat.probes festgelegt, wie viele Zentren geprüft werden sollen Hier zeigt sich der Trade-off zwischen ANN-Leistung und Recall: Je mehr Zentren besucht werden, desto genauer ist das Ergebnis, aber die Performance sinkt Nächste Schritte für bessere Vektorunterstützung in PostgreSQL Ähnlich wie bei PostgreSQL 9.2, als der JSON-Typ offiziell unterstützt wurde, befinden wir uns noch in einer frühen Phase der Speicherung von Vektordaten in PostgreSQL PostgreSQL und pgvector sind bereits gut, werden aber noch deutlich besser werden pgvector kann schon heute allgemeine KI/ML-Datenanwendungsfälle abdecken. Viele Nutzer haben es bereits produktiv im Einsatz Der nächste Schritt besteht darin, Verbesserungen und Erweiterungen zu unterstützen, von denen die meisten bereits in Arbeit sind Mehr Parallelisierung hinzufügen Unterstützung für Vektoren mit mehr als 2.000 Dimensionen Nutzung von Hardwarebeschleunigung zur Erhöhung der Rechengeschwindigkeit Es gibt große Erwartungen an die Nutzung von PostgreSQL als Vektor-"Datenbank" Wie die Geschichte von JSON zeigt, wird die PostgreSQL-Community Wege finden, diese Unterstützung auf erweiterbare und sichere Weise bereitzustellen

(jkatz05.com)

26 Punkte von xguru 2023-06-28 | 7 Kommentare | Auf WhatsApp teilen

Vektoren sind gut erforschte mathematische Strukturen, JSON ist ein Format für den Datenaustausch
In der Welt der Datenspeicherung und -suche sind beide Arten der Datenrepräsentation jedoch zu einer gemeinsamen Sprache geworden und werden bei der Entwicklung moderner Anwendungen bald unverzichtbare Elemente sein
Wenn sich der aktuelle Trend fortsetzt, werden Vektoren beim Bau von Anwendungen ebenso wichtig wie JSON
PostgreSQL wurde zur natürlichen Wahl, um die Ergebnisse generativer KI zu speichern und abzufragen
Das ist jedoch kein neues Datenmuster. Vektoren als mathematisches Konzept existieren bereits seit Jahrhunderten
Arrays als grundlegende Datenstruktur von Vektoren werden in den meisten Einführungskursen der Informatik gelehrt. PostgreSQL unterstützt seit über 20 Jahren Vector-Operationen
Was ist also neu? Es geht darum, wie "zugänglich" diese KI/ML-Algorithmen sind und wie "leicht möglich" es ist, bestimmte Strukturen der "realen Welt" (Text, Bilder, Video) als Vektoren darzustellen und später in Anwendungen zu verwenden
Auch das Speichern der Ausgaben solcher Systeme ("Embeddings") in einem Datenspeicher ist streng genommen nicht neu, aber das neue Muster ist die "Zugänglichkeit", diese Daten in fast Echtzeit in allen Anwendungen abzufragen und zurückzugeben
Was hat das also mit PostgreSQL zu tun?
- Ein gemeinsames Muster zur effizienten Speicherung und Suche von Datentypen hat die App-Entwicklung stark vereinfacht und es Menschen ermöglicht, Daten im gleichen System zu speichern und mit vorhandenen Tools zu bearbeiten
- Vor 10 Jahren haben wir das mit JSON gesehen, und jetzt beobachten wir dieses Muster bei Vektordaten

Eine kurze Geschichte von JSON in PostgreSQL

(Siehe Originalartikel)

Der Aufstieg der Vektoren als "neue Art von JSON"

Die Popularität steigt derzeit stark an
Ein typischer Anwendungsfall ist, auf gespeicherten Daten ein Modell aufzubauen, diese in ein Vektorformat umzuwandeln und dann für die "semantische Suche" zu nutzen
- In diesem Fall wird eine neue Suchanfrage in ein Vektorformat umgewandelt und dann in der Datenbank nach dem ähnlichsten Eintrag gesucht
- Die Ähnlichkeit wird mit Distanzfunktionen wie euklidischer Distanz oder Kosinusdistanz berechnet; die Ergebnisse werden oft auf k-NN (Nearest Neighbors) oder die k ähnlichsten Objekte begrenzt
- Da das Kodieren des Trainingssatzes von Vektoren viel Zeit kosten kann, ist es sinnvoll, ihn an einem Ort wie einer Datenbank zu cachen und dort k-NN-Abfragen auszuführen
- Da es für Nutzer in der Regel eine bessere Erfahrung bietet, eine Menge von Vektoren bereitzuhalten, die für semantische Suche sofort abfragbar sind, entstand der Bedarf an einer "Vektordatenbank"
Die Speicherung von Vektoren ist für PostgreSQL nichts Neues
- Tatsächlich ist der Begriff etwas irreführend, da PostgreSQL mehrdimensionale Daten (z. B. Matrizen) speichern kann
- Standardmäßig enthalten die Arrays von PostgreSQL zwar nur begrenzte Funktionen für Vektoren, etwa die Berechnung der "Distanz" zwischen zwei Arrays
- Man kann Stored Procedures schreiben, aber das erfordert etwas mehr Arbeit von Entwicklern
Glücklicherweise überwindet der Datentyp cube diese Einschränkungen
- cube wird seit über 20 Jahren verwendet und wurde dafür entworfen, Operationen auf hochdimensionalen Vektoren auszuführen
- cube enthält die meisten gängigen Distanzfunktionen, die für die Suche nach Vektorähnlichkeit verwendet werden, einschließlich euklidischer Distanz
- Mit GiST-Indizes lassen sich auch effiziente K-NN-Abfragen ausführen
- Allerdings kann cube nur Vektoren mit bis zu 100 Dimensionen speichern, während moderne KI/ML-Systeme mehr verlangen

pgvector: Open-Source-Erweiterung zum Speichern und Suchen von Vektoren in PostgreSQL

Mit pgvector lassen sich Vektoren speichern und k-NN-Abfragen mit verschiedenen Distanzmetriken ausführen (euklidisch, Kosinus, inneres Produkt usw.)
Derzeit wird pvector zusammen mit einem Index ivfflat ausgeliefert, der die IVR-FLAT-Methode für die Vektorindizierung implementiert
Das Abfragen indizierter Vektordaten kann sich von der Abfrage gewöhnlicher Daten unterscheiden
Wegen der Kosten einer Nearest-Neighbor-Suche in hochdimensionalen Vektoren liefern viele Methoden zur Vektorindizierung "annähernde" Antworten, die der korrekten Antwort "nahe genug" sind
Daraus entstand der Bereich der "ANN (Approximate Nearest Neighbor)"-Suche
Bei ANN-Abfragen betrachten Nutzer meist zwei Dimensionen: Leistung und "Recall" (der Prozentsatz relevanter Ergebnisse, die zurückgegeben werden)
- Am Beispiel von ivfflat: Beim Erstellen eines ivfflat-Index wird entschieden, wie viele Listen enthalten sein sollen
- Jede Liste repräsentiert ein "Zentrum", das mit dem k-means-Algorithmus berechnet wird
- Sobald alle Zentren bestimmt sind, ermittelt ivfflat für jeden Vektor das nächstgelegene Zentrum und fügt ihn dem Index hinzu
- Wenn Vektordaten abgefragt werden, wird über die Variable ivfflat.probes festgelegt, wie viele Zentren geprüft werden sollen
- Hier zeigt sich der Trade-off zwischen ANN-Leistung und Recall: Je mehr Zentren besucht werden, desto genauer ist das Ergebnis, aber die Performance sinkt

Nächste Schritte für bessere Vektorunterstützung in PostgreSQL

Ähnlich wie bei PostgreSQL 9.2, als der JSON-Typ offiziell unterstützt wurde, befinden wir uns noch in einer frühen Phase der Speicherung von Vektordaten in PostgreSQL
PostgreSQL und pgvector sind bereits gut, werden aber noch deutlich besser werden
pgvector kann schon heute allgemeine KI/ML-Datenanwendungsfälle abdecken. Viele Nutzer haben es bereits produktiv im Einsatz
Der nächste Schritt besteht darin, Verbesserungen und Erweiterungen zu unterstützen, von denen die meisten bereits in Arbeit sind
- Mehr Parallelisierung hinzufügen
- Unterstützung für Vektoren mit mehr als 2.000 Dimensionen
- Nutzung von Hardwarebeschleunigung zur Erhöhung der Rechengeschwindigkeit
Es gibt große Erwartungen an die Nutzung von PostgreSQL als Vektor-"Datenbank"
Wie die Geschichte von JSON zeigt, wird die PostgreSQL-Community Wege finden, diese Unterstützung auf erweiterbare und sichere Weise bereitzustellen

7 Kommentare

atempest 2025-05-07

Die Vielseitigkeit ist zwar hoch, aber am Ende kommt es wohl doch auf die Geschwindigkeit an.
Im Vergleich zu echten Vector-DBs dürfte es wohl kaum erträglich langsam sein....

nicewook 2023-06-28

Ich frage mich, warum PostgreSQL so große Erwartungen geweckt werden, obwohl es Vektor-Datenbanken wie Pinecone gibt. @@

tkwlsrl 2023-06-28

Meiner Erfahrung nach war PostgreSQL am zugänglichsten.

Wenn man Dinge wie Pinecone, ChromaDB oder Weaviate verwendet hat, war das nicht so standardisiert, dass man jede Datenbank auf die gleiche Weise nutzen konnte.

Das heißt, man musste je nach Datenbank unterschiedliche SDKs verwenden, und auch deren Nutzung war verschieden, sodass der Code für jede Datenbank neu geschrieben werden musste. Außerdem war die Auswahl der Sprachen, für die offizielle SDKs bereitgestellt wurden, begrenzt, sodass man teils sogar die Sprache wechseln musste.

Natürlich ist es ähnlich, wenn man Vektoren in PostgreSQL nutzen will, aber zumindest ist der Einstieg einfacher, weil man zur bestehenden SQL-Syntax nur ein wenig zusätzliches Wissen braucht.

Wenn man sich derzeit die Geschwindigkeit von Vektor-Datenbanken ansieht, ist PostgreSQL eher ziemlich langsam. Hoffentlich wird das bald etwas verbessert, haha.

xguru 2023-06-28

„Es ist wohl einfach praktisch, nur eine einzige DB zu installieren und zu verwalten, die alles unterstützt“ + „die Integration mit anderen Funktionen ist einfacher“, oder?
Wenn die Zahl der Instanzen steigt, wird es nach und nach ziemlich lästig..

nicewook 2023-06-28

Aha, verstanden.
Deshalb hängt Redis wohl auch dies und das an. nickt zustimmend

iolothebard 2023-06-28

Letztlich … Tensor …