Vektordatenbank-Größe-Rechner
Eingaben
| Vektoranzahl | 1.000.000 |
|---|---|
| Dimensionen | 1.536 |
| Bytes pro Wert | 4 |
| Index-Overhead | 25 % |
Vektordatenbank-Größe-Rechner
Schätzt den Speicherbedarf eines Embedding-Index aus der Vektoranzahl, der Vektordimension, den Bytes pro Wert und dem Index-Overhead, den Strukturen zur approximativen Nächste-Nachbarn-Suche hinzufügen.
Eingaben
Vektoren
Index
Ergebnisse
Geben Sie einen Wert ein, um die Ergebnisse zu sehen.
Details
Die Größe einer Vektordatenbank erklärt
Die Größe einer Vektordatenbank ist der Speicherplatz, der nötig ist, um eine Menge von Embedding-Vektoren zusammen mit dem darüber aufgebauten Suchindex zu halten. Wenn ein Retrieval-System einen Korpus einbettet, wird jeder Dokument-Chunk zu einem Vektor — einer Zahlenliste fester Länge —, und all diese Vektoren müssen an einem Ort liegen, der eine schnelle Ähnlichkeitssuche unterstützt. Der Bedarf wird von drei Dingen bestimmt: wie viele Vektoren es gibt, wie lang jeder Vektor ist und wie viele Bytes jeder Wert belegt.
Wie sich der Bedarf zusammensetzt
Ein einzelner Vektor ist ein Array aus dimensions Zahlen. Jede Zahl wird mit
einer gewählten Genauigkeit gespeichert: 4 Byte für eine 32-Bit-Gleitkommazahl,
2 Byte für eine 16-Bit-Gleitkommazahl oder 1 Byte für eine quantisierte
8-Bit-Ganzzahl. Die Multiplikation der Bytegröße eines Werts mit der Dimension
ergibt die Größe eines Vektors, und die Multiplikation mit der Anzahl der
Vektoren ergibt die rohe Nutzlast.
Über den rohen Vektoren liegt der Index. Eine Abfrage mit jedem gespeicherten Vektor zu vergleichen, ist genau, aber langsam, sobald die Anzahl in die Millionen geht, daher bauen Vektordatenbanken eine Struktur zur approximativen Nächste-Nachbarn-Suche auf — am häufigsten einen HNSW-Graphen —, die der Suche erlaubt, nur einen kleinen Bruchteil der Vektoren zu besuchen. Dieser Graph speichert Nachbarschaftsverknüpfungen für jeden Vektor, und diese Verknüpfungen sind zusätzliche Daten, die meist zwischen einem Fünftel und der Hälfte der rohen Größe ausmachen.
Die Formel
Bei Vektoren der Dimension , bei denen jeder Wert Byte belegt, beträgt der rohe Speicher
Sraw=N⋅d⋅bund mit einem anteiligen Index-Overhead ergibt sich die Gesamtgröße:
S=Sraw⋅(1+o)Rechenbeispiel
Betrachten wir einen Bestand von 2.400.000 Vektoren aus einem Modell mit Dimension 768, in voller Genauigkeit gehalten, sodass jeder Wert 4 Byte belegt, mit einem HNSW-Index, der 35 Prozent Overhead hinzufügt. Die rohe Größe beträgt
Sraw=2400000×768×4=7372800000 Byte≈7,37 GBund mit dem Index
S=7,37 GB×1,35≈9,95 GBWürde man dieselben Vektoren auf 8-Bit-Quantisierung mit 1 Byte pro Wert umstellen, sänke die rohe Größe auf etwa 1,84 GB und die Gesamtgröße auf rund 2,49 GB — eine Reduktion um das Vierfache — zum Preis eines geringen Genauigkeitsverlusts in der Distanzberechnung.
Hinweise und Varianten
Die Schätzung deckt nur Vektoren und den Index ab. Die meisten Datenbanken speichern zusätzlich den ursprünglichen Text-Chunk und Metadaten neben jedem Vektor; bei kurzen Chunks kann diese Nutzlast mit dem Vektor selbst vergleichbar sein, daher sollte sie bei der Dimensionierung des gesamten Speicherplatzes separat hinzugerechnet werden. Dimensionsreduktion und Quantisierung sind die beiden wichtigsten Hebel, um einen Index zu verkleinern: das Halbieren der Dimension oder die Quantisierung auf int8 verringern die rohe Größe jeweils erheblich, bevor überhaupt Index-Overhead hinzukommt.
Anwendung
Die Speichergröße ist die Eingabe für die Hosting-Kosten — sobald bekannt ist, wie viele Gigabyte ein Index belegt, verwandelt der Vektordatenbank-Kosten-Rechner dies in eine monatliche Rechnung. Die hier dimensionierten Vektoren werden vom Embedding-Schritt erzeugt, der im Embedding-Kosten-Rechner bepreist wird, und die Anzahl der Vektoren ergibt sich meist daraus, wie die Quelldokumente aufgeteilt werden.
Häufig gestellte Fragen (FAQ)
Warum fügt der Index Overhead hinzu?
Das Speichern der rohen Vektoren erlaubt es, eine Abfrage mit jedem Vektor zu vergleichen, doch dieser Brute-Force-Scan ist bei großem Umfang langsam. Indizes zur approximativen Nächste-Nachbarn-Suche wie HNSW bauen einen navigierbaren Graphen auf, sodass die Suche nur einen kleinen Bruchteil der Vektoren besucht.
Dieser Graph speichert Nachbarschaftsverknüpfungen für jeden Vektor, was zusätzliche Daten über die Vektoren selbst hinaus bedeutet — häufig 20 bis 50 Prozent mehr, je nachdem, wie dicht der Graph verbunden ist.
Wie viel spart Quantisierung?
Embedding-Werte entstehen als 32-Bit-Gleitkommazahlen mit je 4 Byte. Sie als 16-Bit-Gleitkommazahlen zu speichern, halbiert den Bedarf, und die Quantisierung auf 8-Bit-Ganzzahlen reduziert ihn auf ein Viertel.
Quantisierung führt kleine Rundungsfehler in die Distanzberechnung ein, doch für das Retrieval ist der Verlust an Ranking-Qualität meist gering, sodass int8 ein gängiger Weg ist, einen großen Index zu verkleinern. Das Feld Bytes pro Wert erlaubt es, die drei Optionen direkt zu vergleichen.
Sind Metadaten und Text enthalten?
Nein. Die Schätzung deckt nur die Vektoren und den Suchindex ab. Die meisten Vektordatenbanken speichern zusätzlich den ursprünglichen Text-Chunk sowie Metadaten wie Dokument-IDs, Titel und Tags neben jedem Vektor. Diese Nutzlast kann bei kurzen Chunks die Vektorgröße erreichen oder übersteigen, daher sollte sie bei der Dimensionierung des gesamten Speicherplatzes separat hinzugerechnet werden.
Haftungsausschluss
Dies ist ein ungefährer Bedarf für die Vektoren und den Index. Reale Datenbanken speichern außerdem den Quelltext, Metadaten und interne Verwaltungsdaten, und der Overhead eines bestimmten Index hängt von seiner Konfiguration ab. Behandeln Sie das Ergebnis als Planungsschätzung, nicht als exakte Speichergröße.