Wir haben 8 Jahre damit verbracht, Vektordatenbanken schneller zu machen. Dann haben wir aufgehört.
Kosten sind wichtig. Das war schon immer so. Aber es gibt eine Reihenfolge: Kosten kann man erst senken, nachdem man die Leistungsanforderungen erfüllt hat. Ein System, das billig ist, aber falsche Ergebnisse liefert, ist nicht nützlich. Ebenso wenig eines, das die Latenz unter Last nicht niedrig halten kann.
Milvus wurde 2019 mit einer einfachen Überzeugung als Open Source veröffentlicht: Vektordatenbanken würden zu zentraler Dateninfrastruktur werden, nicht zu einer Funktion, die in einer Anwendung verborgen ist. Mehr als acht Jahre lang führte uns diese Überzeugung in eine Richtung: Vektorsuche schneller und vorhersehbarer machen. Indexkomprimierung, Segment-Scheduling, HNSW-Tuning, Prefetch-Strategien — fast jede größere Optimierung zielte auf dasselbe ab: Daten in den lokalen Cache bringen und schneller suchen.
Diese Arbeit ist nach wie vor die Grundlage. Always-on Serving ist die richtige Architektur für Vektorsuch-Workloads mit hohem QPS und niedriger Latenz. Wenn eine Collection ständig abgefragt wird, ist es keine Verschwendung, Indizes im Speicher vorzuhalten — es sind die Kosten dafür, das Produkterlebnis bereitzustellen.
Dann haben wir uns den Kosten zugewandt. Tiered Storage half — heiße Segmente im Speicher, kalte Daten auf Festplatte und in Object Storage, echte Einsparungen. Aber die Nodes wurden nie abgeschaltet. Für einen Workload, der fünf Stunden im Monat läuft, zahlte man trotzdem für die anderen 715.
Diese Lücke ist eines der Probleme, die die neue Zilliz Vector Lakebase lösen soll. Der größere Wandel besteht nicht einfach darin, „Vektorsuche billiger zu machen“. Es geht darum, persistenten semantischen Daten mehr als einen Compute-Lebenszyklus zu ermöglichen: Always-on Serving, wenn Latenz und Durchsatz wichtig sind, und On-Demand-Compute, wenn die Daten abfragbar bleiben müssen, aber keine dedizierten Maschinen benötigen, die den ganzen Monat laufen.
Die Physik hinter dem Always-on-Serving-Modell
Die Leselatenz von S3 liegt bei 20–50 ms pro Anfrage. HNSW-Graph-Traversal berührt pro Abfrage Hunderte von Nodes. Wenn man diese beiden Zahlen zusammenbringt, ist die Schlussfolgerung offensichtlich: Vektorindizes müssen im lokalen Speicher liegen, um Abfragen zu bedienen. Kein Designfehler — Physik.
Um das konkret zu machen: 100M Vektoren, 768 Dimensionen, float32. Die Rohvektordaten umfassen ~286 GB; der HNSW-Graph (M=48) fügt weitere ~55 GB an Nachbar-Links hinzu — insgesamt etwa 340 GB.
Traditionelles Milvus-QueryNode-Modell:
┌──────────────────────────────────────────────────────────────┐
│ Traditionelle Milvus-Architektur │
│ │
│ 100M × 768-dim float32 → ~340 GB auf 3 QueryNodes verteilt │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ QueryNode 1 │ │ QueryNode 2 │ │ QueryNode 3 │ │
│ │ 128GB RAM │ │ 128GB RAM │ │ 128GB RAM │ │
│ │ + NVMe │ │ + NVMe │ │ + NVMe │ │
│ │ seg 0-99 │ │ seg 100-199 │ │ seg 200-299 │ │
│ │ (~113 GB) │ │ (~113 GB) │ │ (~113 GB) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ load() │ load() │ load() │
│ └─────────────────┼─────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ S3 (Source of Truth) │ │
│ │ 340 GB Gesamtdaten │ │
│ └───────────────────────┘ │
│ Collection nur abfragbar, wenn alle 340 GB geladen sind │
│ Node fällt aus → ihre Segmente werden dunkel → Reload aus S3│
└──────────────────────────────────────────────────────────────┘
Jedes Segment benötigt einen residenten Node, bevor die Collection abfragbar ist. 340 GB Daten, drei Maschinen mit 128 GB, rund um die Uhr im Betrieb. Für häufig abgefragte Collections funktioniert das gut. Dann veränderte KI das Nachfragemuster.
Produktteams führen zweiwöchige A/B-Experimente durch, danach werden diese Embeddings nie wieder abgefragt. In SaaS-Produkten haben sich 90 % der Nutzer letzte Woche nicht eingeloggt. In RAG-Wissensdatenbanken wurden 80 % der Dokumente im letzten Monat nicht abgerufen. Die Daten sind nicht nutzlos — sie könnten jederzeit abgefragt werden —, aber sie werden selten abgefragt. Traditionelle Datenbanken lösen das mit Tiering: heiße Daten im Arbeitsspeicher, kalte Daten auf der Festplatte und Pages werden bei Bedarf eingelesen. Vektordatenbanken kannten ein solches Konzept nicht. Entweder man lud die gesamte Collection, oder sie war nicht abfragbar.
Bevor KI-generierte Embeddings weit verbreitet wurden, war diese binäre Unterscheidung kein Problem. Die meisten Vektor-Workloads waren entweder klar Online-Serving-Systeme, bei denen es sinnvoll war, Indizes im Arbeitsspeicher resident zu halten, oder Offline-Experimente, die maßgeschneiderte Pipelines tolerieren konnten. KI hat diesen Mittelbereich verändert.
Wir begannen, diese Verschiebung in Kundengesprächen zu sehen. Embeddings betrieben nicht mehr nur produktive RAG-Chatbots. Ein weltweit führender GPU-Anbieter bettete Daten zum autonomen Fahren ein — Kamerabilder, Fahrtsitzungen, Wetter, Standort, Zeitstempel und andere Metadaten —, damit Ingenieure seltene Fahrszenarien über zig Milliarden Vektoren hinweg auffinden konnten. Ein Bildungstechnologieunternehmen nutzte semantische Suche zur mehrsprachigen Plagiatserkennung, bei der Workloads von einer Handvoll Dokumenten bis zu 10.000+ Dokumenten in einem Batch während Prüfungszeiten schwanken konnten.
Das ist der Kontext für Vector Lakebase. KI-Teams sammeln unstrukturierte Daten an, die persistent und auffindbar bleiben müssen, aber das Zugriffsmuster ist ungleichmäßig. Einige Pfade benötigen kontinuierliches Serving. Andere benötigen gelegentliche Suche, Exploration oder Batch-Discovery über dieselben zugrunde liegenden Daten. All diese Pfade als Always-on-Serving zu behandeln, lässt zu viel Infrastruktur ungenutzt.
Ein Nutzer schrieb in unserem Community-Slack:
"Meine Embeddings liegen bereits in S3. Sie sagen mir, ich müsse drei Stunden damit verbringen, sie zu importieren, drei Maschinen mit 128 GB RAM rund um die Uhr laufen lassen und $24.000 pro Jahr bezahlen — nur um gelegentliche Abfragen auszuführen?"
Er hatte recht. Das Problem war nicht, wo die Daten lagen oder ob der Index schnell genug war. Er zahlte Hot-Data-Preise für ein Cold-Data-Zugriffsmuster: 0,7 % aktiv, 100 % abgerechnet.
Der Markt hatte bereits begonnen zu beweisen, dass Object-Storage-First-Ökonomie für Vektor-Workloads wichtig war. Und zustandslose Compute auf Objektspeicher zu halten, war eine Richtung, die viele Nutzer wollten. Aber die schwierigere Frage für uns war, wie wir dieses Kostenmodell in eine vollständige Vektordatenbank bringen konnten: mit gefilterter Suche, Datenbanksemantik, operativer Isolation und einem Weg, der weiterhin zurück zum Always-on-Serving führt, wenn Workloads heiß werden.
Das ist unsere Vector-Lakebase-These: Semantische Daten persistent halten und die Compute-Schicht an den Workload anpassen lassen. On-Demand-Suche ist eine Ausprägung dieser Architektur. Sie richtig umzusetzen erforderte, vier technische Hindernisse zu überwinden.
Vier Barrieren für die Lakebase-On-Demand-Suche
Im Lakebase-On-Demand-Suchmodell starten QueryNodes bei Bedarf, bedienen Abfragen und werden dann wieder freigegeben. Daten bleiben im Objektspeicher als Source of Truth. Compute skaliert zwischen Abfragesitzungen auf null. Das klingt einfach, aber um es nutzbar zu machen, mussten Cold-Start-Latenz, Scan-Volumen, I/O-Verstärkung während des Retrievals und fixe Kosten der Control Plane adressiert werden.
Cold Start war zu langsam
340 GB HNSW-Index. Laden aus S3: über vier Minuten. Vier Minuten Cold Start töten jeden On-Demand-Anwendungsfall. Ein Nutzer startet eine Abfrage und wartet vier Minuten — das ist keine Verzögerung, das ist ein kaputtes Produkt.
Die Lösung bestand darin, den Index zu komprimieren und ihn dabei nutzbar zu halten. Wir entwickelten eine 1+3-Bit-Matryoshka-Quantisierung auf Basis von RabitQ (Gao & Long, 2024). Zwei Schichten, ineinander verschachtelt wie Matroschka-Puppen.
Die 1-Bit-Schicht wird zuerst geladen — 13 GB statt 340 GB. Die Suche läuft sofort darauf: RabitQ liefert eine beweisbare Fehlergrenze für 1-Bit-Distanzen, sodass Kandidaten sicher verworfen werden können und garantiert nichts aus den echten Top-k herausfällt. 85–90 % Recall bei der ersten Abfrage.
Die 3-Bit-Schicht wird im Hintergrund heruntergeladen, während die 1-Bit-Suche läuft. Sobald sie bereit ist, wird sie als Verfeinerungsdurchlauf verwendet — Überlebende aus der 1-Bit-Phase werden mit voller 1+3-Bit-Präzision neu bewertet. Der Recall steigt auf 95%+. Die beiden Schichten sind keine Alternativen; die innere übernimmt das Filtern, und die äußere verbessert die Ergebnisse.
Der Rohdurchsatz der Quantisierung ist im großen Maßstab ein Engpass. GPU-beschleunigter Indexaufbau und AVX512- / ARM-SVE-Abfrage-Kernels bringen den Durchsatz der Distanzberechnung an den Punkt, an dem der Quantisierungs-Overhead vernachlässigbar ist. Zwei weitere Verbesserungen erhöhen den Recall: optimale Skalierung pro Vektor, bei der für jeden Vektor sein eigener Quantisierungsfehler minimiert wird, statt einen globalen Faktor zu teilen; und ungleichmäßige Bit-Zuweisung über Dimensionen hinweg basierend auf Varianz, sodass informationsdichte Dimensionen mehr Bits erhalten. Beide reduzieren direkt den Quantisierungsfehler, ohne die Indexgröße zu erhöhen.
Erstes Hindernis überwunden. Aber selbst mit vollständiger Quantisierung ist das Scannen von 100M Vektoren immer noch teuer.
Scannen von 100M Vektoren
Der 1-Bit-Index ist klein, aber die Distanzberechnung über 100M Vektoren ist weiterhin linear. In einem On-Demand-Modell verstärkt sich das: Längere Rechenzeit bedeutet, dass die QueryNode länger resident bleibt, wodurch sich das Fenster für elastische Freigabe verkleinert.
IVF-Clustering mit globalem Index-Pruning (Bucket-Anzahl skaliert mit Datenvolumen):
┌──────────────────────────────────────────────────────────────┐
│ Global Index + IVF pruning │
│ │
│ 100M Vektoren → IVF-Clustering (N Buckets, N skaliert mit │
│ Datenvolumen) │
│ │
│ ┌───┬───┬───┬───┬───┬───┬───┬───┬─── ··· ───┬───┐ │
│ │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │ 8 │ │ N │ │
│ └───┴───┴───┴───┴───┴───┴───┴───┴─── ··· ───┴───┘ │
│ ▲ ▲ ▲ │
│ █ █ █ ← nur ~3% scannen │
│ │
│ Abfrage q → nächste Zentroiden finden → diese Buckets durchsuchen │
│ │
│ Gescannte Daten: ~3% der Gesamtmenge │
│ S3-I/O: ~3% der Daten abrufen │
│ Compute: Distanzberechnung nur auf ~3% │
└──────────────────────────────────────────────────────────────┘
IVF ist nicht neu, aber zwei Dinge machen unseres anders.
Erstens: Skalierung. Die meisten IVF-Implementierungen brechen im Maßstab von Milliarden Vektoren zusammen, weil der Indexaufbau erfordert, alles auf einmal in den Speicher zu laden. Wir haben eine verteilte Indexkonstruktion entwickelt, die die Clustering-Arbeit über Nodes shardet — IVF in jeder Größenordnung, einschließlich Milliarden von Vektoren.
Zweitens: die Lakebase-Interaktion. Zur Abfragezeit werden nur die relevanten Buckets aus S3 abgerufen. Probe von ~3% der Cluster, Abruf von ~3% der Daten, Halten von ~3% im QueryNode-Speicher. Ein Node, der nur 3% des Datensatzes geladen hat, kann fast unmittelbar nach Abschluss der Abfrage wieder freigegeben werden.
Zusammen mit 1-Bit-Quantisierung verstärken sich die beiden Barrieren: 340 GB → 13 GB (Quantisierung) → ~400 MB pro Abfrage (IVF-Pruning). Kaltstart lädt nur die Cluster-Zentroiden und die 1-Bit-Index-Metadaten — 5–10 Sekunden. Jede nachfolgende Abfrage ruft nur die relevanten Buckets ab, nicht die vollen 13 GB.
Zweites Hindernis überwunden.
Retrieve verstärkte S3-I/O
Die Vektorsuche gibt IDs zurück, keine Rohdaten. Originalvektoren oder Skalarfelder abzurufen bedeutet eine zweite Leserunde, und in einem storage-nativen Abfragepfad ist jede davon ein S3-Punkt-Read.
Das Problem war das Speicherformat. Standard-Parquet-Dateien verwenden 64-MB-Row-Groups. Ein einzelner Vektordatensatz ist etwa 3 KB groß. Ihn zu lesen bedeutet, die gesamte Row-Group herunterzuladen: 3 KB nützliche Daten, 64 MB tatsächlicher I/O — etwa 20.000-fache Verstärkung. Auf lokaler Festplatte tolerierbar. Auf S3 brutal.
Storage V2 hat die Hälfte davon gelöst: getrennte breite und schmale Spalten, wobei Vektoren und skalare Felder unabhängig voneinander gespeichert werden, und Row Groups wurden auf 1 MB verkleinert — 64x weniger Amplifikation. Der Haken: Parquets Komprimierung auf Blockebene beruht auf großen Row Groups. Verkleinert man sie, verschlechtert sich die Komprimierung; Dateien werden größer. Kleine Row Groups und gute Komprimierung schließen sich in Parquet gegenseitig aus. Genau hier kommt Vortex ins Spiel.
Vortex, entwickelt von Spiral und gehostet von der Linux Foundation, verfügt über ein vollständig konfigurierbares Layout ohne erzwungene Row-Group-Struktur; direkte Punktabfragen auf komprimierten Daten durch verschachtelte Delta → RLE → BitPacking-Codierung, ohne dass eine Dekomprimierung erforderlich ist; und automatische Codierungsauswahl auf Basis des BtrBlocks-Algorithmus, der Komprimierungsrate, Codiergeschwindigkeit und Decodiergeschwindigkeit ausbalanciert.
Benchmarks: 3M Zeilen, 128-dimensionale Vektoren, S3, 256 gleichzeitige Leser, 10-Zeilen-Batch pro Lesevorgang.
| Metrik | Parquet | Lance | Vortex |
|---|---|---|---|
| Durchsatz bei Punktlesevorgängen (Lesevorgänge/s) | 162 | 464 | 620 |
| S3-Bytes pro Lesevorgang (MB) | 9.44 | 0.006 | 0.07 |
| S3 GETs pro Zeile | ~2 | ~5 | ~2 |
| Durchsatz bei vollständigem Scan (MB/s) | 638 | 730 | 1,548 |
| Schreibdurchsatz (MB/s) | 216 | 247 | 244 |
Parquet lädt 9.44 MB pro Lesevorgang herunter — die gesamte Row Group. Lance reduziert das auf 0.006 MB, indem es mit 512-Byte-Granularität liest, zahlt dafür aber bei den IOPS: ~5 S3 GETs pro Zeile gegenüber ~2 bei den anderen. Vortex landet bei 0.07 MB mit ~2 GETs pro Zeile — 135x weniger Traffic als Parquet, ohne IOPS-Strafe. Der Durchsatz bei vollständigen Scans ist 2.4x höher als bei Parquet; Schreibvorgänge sind vergleichbar.
Drittes Hindernis beseitigt.
Control-Plane-Kosten skalierten nicht auf null
Die ersten drei Änderungen lagen im Query-Pfad. Die vierte war in der Control Plane verborgen.
Selbst wenn alle QueryNodes im Leerlauf sind, hält jede Milvus-Instanz ihren Coordinator und etcd am Leben. N Mandanten bedeuten N Sets. QueryNodes konnten auf null skalieren; diese beiden Komponenten konnten es nicht — sie sind zustandsbehaftet und müssen resident bleiben. Bei einer Million Mandanten übersteigt der Overhead der Control Plane die QueryNode-Kosten.
Die Lakebase-Control-Plane ändert dies von O(N) zu O(1):
Traditionelles Milvus: Control-Plane-Kosten O(N)
┌──────────────────────────────────────────────────────────────┐
│ Gemeinsame Infrastruktur │
│ Kafka / Pulsar (geteilt) Index Pool (geteilt) │
└──────────────────────────────────────────────────────────────┘
| | |
Mandant A Mandant B Mandant C
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Coordinator │ │ Coordinator │ │ Coordinator │
│ etcd │ │ etcd │ │ etcd │
├──────────────────┤ ├──────────────────┤ ├──────────────────┤
│ QueryNode │ │ QueryNode │ │ QueryNode │
│ (dediziert) │ │ (dediziert) │ │ (dediziert) │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
└─────────────────────┼─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase: Control-Plane-Kosten O(1)
┌───────────────────────────────────────────────────────────────┐
│ Gemeinsame Steuerungsebene (pro Region) │
│ │
│ ┌──────────────────┐ ┌──────────┐ ┌───────────────────┐ │
│ │ Gemeinsamer │ │ Katalog │ │ WAL Service │ │
│ │ Koordinator │ │ ≠ etcd │ │ → S3, ≠ Kafka │ │
│ │ │ │ │ │ │ │
│ └──────────────────┘ └──────────┘ └───────────────────┘ │
│ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Indexdienst (GPU-Build-Pool) │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────┬─────────────────────────────────┘
┌────────────────────┼─────────────────────┐
Tenant A NS Tenant B NS Tenant C NS
┌────────────┐ ┌────────────┐ ┌───────────┐
│ QueryNode │ │ (inaktiv) │ │ QueryNode │
│ QueryNode │ │ scale = 0 │ └────┬──────┘
└──────┬─────┘ └────────────┘ │
└─────────────────────┬─────────────────────┘
↓
┌──────┐
│ S3 │
└──────┘
Lakebase ersetzt jedes Element des alten mandantenbezogenen Modells. Der Koordinator wird gemeinsam von mehreren Mandanten genutzt und ersetzt mandantenspezifische Koordinatoren. Catalog ersetzt etcd pro Instanz und beseitigt die Speicherbegrenzung von 2 GB. WAL Service schreibt direkt in S3 ohne lokale Festplatte — gemessener Durchsatz von 750 MB/s, 5,8x Kafka — und ersetzt Kafka/Pulsar. Index Service ist ein mandantenübergreifend gemeinsam genutzter GPU-Build-Pool und ersetzt die GPU-Zuweisung pro Instanz.
„Scale to zero“ bedeutet nicht mehr „QueryNodes können freigegeben werden“, sondern „die gesamte Instanz verursacht im Leerlauf nahezu keine Kosten.“
┌──────────────────────────────────────────────────────────────┐
│ Multi-Tenant × Lakebase On-demand Search │
│ │
│ S3-Speicherschicht Compute (on demand) │
│ ┌──────────────┐ │
│ │Tenant-A-Daten│ ◄──── Abfrage ── QueryNode A (aktiv) │
│ ├──────────────┤ │
│ │Tenant-B-Daten│ (inaktiv, kein QueryNode) │
│ ├──────────────┤ │
│ │Tenant-C-Daten│ (inaktiv, kein QueryNode) │
│ ├──────────────┤ │
│ │Tenant-N-Daten│ ◄──── Abfrage ── QueryNode N (aktiv) │
│ └──────────────┘ │
│ │
│ 1 Mio. Mandanten, 1 % aktiv → 99 % der Daten haben null Compute-Kosten │
└──────────────────────────────────────────────────────────────┘
Traditionell bedeutete Multi-Tenancy, einen Cluster über separate Collections oder Partitionen mandantenübergreifend zu teilen — doch dieser Cluster hatte harte Obergrenzen: das 2-GB-Metadatenlimit von etcd, den Durchsatz des Koordinators und eine feste QueryNode-Kapazität. Skalierung über diese Grenzen hinaus bedeutete mehr Cluster, und das bedeutete mehr Overhead.
Lakebase verändert diese Obergrenze. Catalog ersetzt etcd durch einen skalierbaren Metadatenspeicher, und der gemeinsame Koordinator verarbeitet deutlich mehr Mandanten ohne mandantenspezifischen Overhead. S3 bietet Speicherelastizität. Das Ergebnis ist ein einzelner Cluster, der viel mehr isolierte Mandanten bedienen kann — und nur die Mandanten, die aktiv Abfragen erhalten, verbrauchen Compute. Der Rest zahlt nur für Speicher.
Zurück zu diesem Slack-Nutzer
Gleiches Szenario: 100 Mio. Vektoren, 768-dimensionale float32, 10 Abfragen pro Tag, jeweils eine Minute. Aktiv ~5 Stunden pro Monat.
Bei diesem Workload besteht der wichtige Unterschied nicht nur darin, wo die Bytes liegen. Sondern darin, ob Compute an diese Bytes gebunden bleiben muss, während niemand sie abfragt.
Sowohl die Cold-Start-Zeiten von selbst gehostetem Milvus als auch das Tiered-Storage-Modell von Zilliz Cloud sind einmalige Ladekosten — sobald sie warm sind, sind Abfragen schnell. Der On-Demand-Cold-Start von Lakebase erfolgt zu Beginn jeder Sitzung, nachdem der Node wieder auf null skaliert wurde, was bei diesem Workload im Grunde jedes Mal der Fall ist. 5–10 Sekunden pro Sitzung sind der Kompromiss dafür, zwischen den Sitzungen nichts zu bezahlen.
Die Kosten für Self-hosting bestehen größtenteils aus EC2 im Dauerbetrieb, mit 3 × r6g.4xlarge on-demand für ungefähr $2,073/Monat, plus Kafka. Das Tiered-Storage-Modell von Zilliz Cloud nimmt den Betriebsaufwand ab, aber das Abrechnungsmodell bleibt gleich. Lakebase On-demand Search verändert das Modell: Bezahle nur für die fünf Stunden, die du tatsächlich nutzt.
| Selbst gehostetes Milvus | Zilliz Cloud Tiered Storage Model | Lakebase On-demand Search | |
|---|---|---|---|
| Compute-Lebenszyklus | Immer eingeschaltet | Immer eingeschaltet | On demand |
| Kosten für inaktive Compute-Ressourcen | Voller Satz | Voller Satz | $0 |
| Cold-Start-Muster | Einmaliges Laden, dann warm | Einmaliges Laden, dann warm | 5–10s zu Sitzungsbeginn |
| Beste Eignung | Hot-Serving-Workloads | Verwaltetes Hot/Cold-Tiering | Selten abgefragte semantische Daten |
~$240/Jahr. Null Compute-Kosten in 99% der Zeit. Vier Hindernisse, vier Ebenen der Veränderung.
Die Physik hat sich nicht verändert. S3 liegt immer noch bei 20–50 ms pro Lesevorgang.
Verändert hat sich das Compute-Modell rund um diese Physik: Tiered Storage hat die Kosten für die Speicherung kälterer Daten reduziert, aber Lakebase On-demand Search beseitigt die Always-on-Compute-Untergrenze für Workloads, die die meiste Zeit inaktiv sind.
Diese Lücke ist wichtiger als die Einsparungen. Der Slack-Nutzer, der $24,000/Jahr nicht rechtfertigen konnte, hat beim Wechsel nicht nur Geld gespart — er begann, mehr Daten zu indexieren, weil Suche günstig genug war, um mehr davon zu machen. Niedrigerer Preis, höhere Nachfrage.
Das ist die größere Geschichte von Vector Lakebase. Sobald semantische Daten unabhängig von einem einzelnen Always-on-Serving-Cluster bestehen können, können Teams die Compute-Form wählen, die zum Workload passt: kontinuierliches Serving für Hot Paths, On-Demand-Suche für selten abgefragte Daten und Batch-Compute für Discovery- oder Processing-Jobs.
Zilliz Vector Lakebase ist als Public Preview verfügbar
Wir haben die Public Preview von Zilliz Vector Lakebase gestartet — eine bedeutende Weiterentwicklung von Zilliz Cloud von einer verwalteten Vektordatenbank zu einer einheitlichen Plattform für semantische Daten, die latenzarmes Vector Serving mit der Offenheit, Skalierbarkeit und Wirtschaftlichkeit eines Data Lake kombiniert.
Kernfunktionen von Vector Lakebase:
- Tiered Serving, optimiert für verschiedene Echtzeit-Performance-Kosten-Kompromisse
- On-demand Search für großskalige oder explorative Workloads ohne Always-on-Compute
- External Data Lake Search — indiziere und durchsuche direkt deine bestehenden Lake-Daten
- Full-spectrum Search über Vektoren, Text, JSON und Geodaten hinweg mit hybrider Retrieval- und Reranking-Funktion
- Einheitlicher lake-nativer Speicher, aufgebaut auf Vortex, einem offenen Format mit schnelleren und günstigeren Random Reads als Lance oder Parquet
Wenn dein aktueller Stack Serving und Discovery auf separate Systeme aufteilt, könnte Vector Lakebase einen Blick wert sein. Probiere es auf Zilliz Cloud aus — neue Registrierungen mit beruflicher E-Mail-Adresse erhalten $100 kostenlose Credits — oder sprich mit uns über deinen Anwendungsfall.
Weiterlesen
Zilliz Cloud On-Demand Compute: Pay Only for What You Use
The customer case behind Zilliz Cloud On-Demand: how a $10K vector search bill came down to under $500, and the engineering changes that made it possible.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.
DeepRAG: Thinking to Retrieval Step by Step for Large Language Models
Discover DeepRAG, an advanced retrieval-augmented generation (RAG) model that improves LLM accuracy by retrieving only essential data through step-by-step reasoning.