Home
Blog
Hören Sie auf, für kalte Daten zu bezahlen: 80 % Kostenreduzierung mit On-Demand Hot-Cold Data Loading in Milvus Tiered Storage

Hören Sie auf, für kalte Daten zu bezahlen: 80 % Kostenreduzierung mit On-Demand Hot-Cold Data Loading in Milvus Tiered Storage

Engineering

December 15, 2025

Buqian Zheng

Wie viele von Ihnen zahlen immer noch hohe Infrastrukturrechnungen für Daten, die Ihr System kaum berührt? Seien Sie ehrlich - die meisten Teams tun das.

Wenn Sie die Vektorsuche in der Produktion betreiben, haben Sie das wahrscheinlich schon selbst erlebt. Sie stellen große Mengen an Arbeitsspeicher und SSDs bereit, damit alles "abfragebereit" bleibt, obwohl nur ein kleiner Teil Ihres Datensatzes tatsächlich aktiv ist. Und Sie sind nicht allein. Wir haben schon viele ähnliche Fälle erlebt:

SaaS-Plattformen mit mehreren Mandanten: Hunderte von Teilnehmern, aber nur 10-15 % sind an einem bestimmten Tag aktiv. Der Rest liegt brach, belegt aber weiterhin Ressourcen.
E-Commerce-Empfehlungssysteme: Eine Million SKUs, doch die obersten 8 % der Produkte generieren den größten Teil der Empfehlungen und des Suchverkehrs.
KI-Suche: Riesige Archive mit Einbettungen, obwohl 90 % der Nutzeranfragen auf Artikel der letzten Woche treffen.

Die Geschichte ist in allen Branchen gleich: Weniger als 10 % Ihrer Daten werden häufig abgefragt, aber sie verbrauchen oft 80 % Ihres Speicherplatzes und Ihrer Speicherkapazität. Jeder weiß, dass dieses Ungleichgewicht besteht - aber bis vor kurzem gab es keine saubere architektonische Lösung, um es zu beheben.

Das ändert sich mit Milvus 2.6.

Vor dieser Version basierte Milvus (wie die meisten Vektordatenbanken) auf einem Full-Load-Modell: Wenn Daten durchsuchbar sein sollten, mussten sie auf lokale Knoten geladen werden. Dabei spielte es keine Rolle, ob die Daten tausendmal pro Minute oder einmal im Quartal abgefragt wurden - sie mussten alle heiß bleiben. Diese Design-Entscheidung sorgte für eine vorhersehbare Leistung, bedeutete aber auch, dass Cluster überdimensioniert wurden und für Ressourcen bezahlt werden musste, die kalte Daten einfach nicht verdienten.

Tiered Storage ist unsere Antwort.

Milvus 2.6 führt eine neue Tiered-Storage-Architektur mit echtem On-Demand-Laden ein, die es dem System ermöglicht, automatisch zwischen heißen und kalten Daten zu unterscheiden:

Heiße Segmente bleiben in der Nähe des Rechners zwischengespeichert.
Kalte Segmente leben kostengünstig in einem entfernten Objektspeicher
Daten werden nur dann auf lokale Knoten gezogen , wenn eine Abfrage sie tatsächlich benötigt.

Dadurch verschiebt sich die Kostenstruktur von "wie viele Daten Sie haben" zu "wie viele Daten Sie tatsächlich nutzen". Und in frühen Produktionsimplementierungen führt diese einfache Umstellung zu einer Senkung der Speicher- und Arbeitsspeicherkosten um bis zu 80 %.

Im weiteren Verlauf dieses Beitrags werden wir die Funktionsweise von Tiered Storage erläutern, echte Leistungsergebnisse vorstellen und zeigen, wo diese Änderung die größten Auswirkungen hat.

Warum Full Loading bei der Skalierung zusammenbricht

Bevor wir uns mit der Lösung befassen, lohnt es sich, einen genaueren Blick darauf zu werfen, warum der Volllastmodus, der in Milvus 2.5 und früheren Versionen verwendet wurde, bei der Skalierung von Workloads zu einem limitierenden Faktor wurde.

In Milvus 2.5 und früheren Versionen hat jeder QueryNode bei einer Collection.load() -Anfrage die gesamte Sammlung lokal zwischengespeichert, einschließlich Metadaten, Felddaten und Indizes. Diese Komponenten werden aus dem Objektspeicher heruntergeladen und entweder vollständig im Speicher oder als Memory-Mapping (mmap) auf der lokalen Festplatte abgelegt. Erst wenn alle diese Daten lokal verfügbar sind, wird die Sammlung als geladen und abfragebereit markiert.

Mit anderen Worten, die Sammlung ist erst abfragbar, wenn der vollständige Datensatz - warm oder kalt - auf dem Knoten vorhanden ist.

Hinweis: Bei Indextypen, die Rohvektordaten einbetten, lädt Milvus nur die Indexdateien und nicht das Vektorfeld separat. Trotzdem muss der Index vollständig geladen werden, um Abfragen zu bedienen, unabhängig davon, auf wie viele der Daten tatsächlich zugegriffen wird.

Um zu sehen, warum dies problematisch wird, betrachten Sie ein konkretes Beispiel:

Angenommen, Sie haben einen mittelgroßen Vektordatensatz mit:

100 Millionen Vektoren
768 Dimensionen (BERT-Einbettungen)
Float32-Präzision (4 Byte pro Dimension)
Ein HNSW-Index

In diesem Fall benötigt allein der HNSW-Index - einschließlich der eingebetteten Rohvektoren - etwa 430 GB Speicherplatz. Nach dem Hinzufügen allgemeiner skalarer Felder wie Benutzer-IDs, Zeitstempel oder Kategoriebezeichnungen übersteigt die gesamte lokale Ressourcennutzung leicht 500 GB.

Das bedeutet, dass das System selbst dann, wenn 80 % der Daten selten oder nie abgefragt werden, mehr als 500 GB an lokalem Speicher oder Festplatte bereitstellen und vorhalten muss, nur um die Sammlung online zu halten.

Für einige Arbeitslasten ist dieses Verhalten akzeptabel:

Wenn auf fast alle Daten häufig zugegriffen wird, liefert das vollständige Laden aller Daten die geringstmögliche Abfragelatenz - zu den höchsten Kosten.
Wenn die Daten in heiße und warme Teilmengen unterteilt werden können, kann die Speicherzuordnung warmer Daten auf die Festplatte den Speicherdruck teilweise reduzieren.

Bei Arbeitslasten, bei denen sich 80 % oder mehr der Daten im Long Tail befinden, werden die Nachteile des vollständigen Ladens jedoch schnell deutlich, und zwar sowohl bei der Leistung als auch bei den Kosten.

Engpässe bei der Leistung

In der Praxis wirkt sich das vollständige Laden nicht nur auf die Abfrageleistung aus, sondern verlangsamt häufig auch die routinemäßigen Arbeitsabläufe:

Längere Rolling Upgrades: In großen Clustern können Rolling Upgrades Stunden oder sogar einen ganzen Tag dauern, da jeder Knoten den gesamten Datensatz neu laden muss, bevor er wieder verfügbar ist.
Langsamere Wiederherstellung nach Ausfällen: Wenn ein QueryNode neu startet, kann er den Datenverkehr nicht bedienen, bis alle Daten neu geladen sind, was die Wiederherstellungszeit erheblich verlängert und die Auswirkungen von Knotenausfällen verstärkt.
Langsamere Iterationen und Experimente: Das vollständige Laden verlangsamt die Entwicklungsabläufe und zwingt KI-Teams dazu, beim Testen neuer Datensätze oder Indexkonfigurationen stundenlang auf das Laden der Daten zu warten.

Kostenineffizienzen

Vollständiges Laden treibt auch die Infrastrukturkosten in die Höhe. Bei speicheroptimierten Mainstream-Cloud-Instanzen kostet die lokale Speicherung von 1 TB Daten beispielsweise etwa $**70 . 000 pro Jahr **, basierend auf konservativer Preisgestaltung (AWSr6i :$ $70.000 pro Jahr**, basierend auf konservativer Preisgestaltung (AWS r6i: ~$ $*, basierend auf konservativer Preisgestaltung (AWSr6i$ : $5.74 / GB / Monat; GCP n4-highmem: ~5$ $, 68/GB/Monat; AzureE-series :$ 5 $,68 / GB / Monat; Azure E-series: ~$ 5 $, 68/GB/Monat; AzureE -$ $series$ : $5,67 / GB / Monat).$

Betrachten wir nun ein realistischeres Zugriffsmuster, bei dem 80 % dieser Daten "kalt" sind und stattdessen in einem Objektspeicher gespeichert werden könnten (zu etwa 0,023 $ / GB / Monat):

200 GB heiße Daten × $5,68
800 GB kalte Daten × $0,023

Jährliche Kosten: (200×5,68+800×0,023)×12≈$14.000

Das bedeutet eine Senkung der Gesamtspeicherkosten um 80 %, ohne Einbußen bei der Leistung in den Bereichen, auf die es wirklich ankommt.

Was ist der Tiered Storage und wie funktioniert er?

Um diesen Zielkonflikt zu beseitigen, wurde mit Milvus 2.6 Tiered Storage eingeführt, das ein Gleichgewicht zwischen Leistung und Kosten herstellt, indem der lokale Speicher als Cache und nicht als Container für den gesamten Datensatz behandelt wird.

In diesem Modell laden die QueryNodes beim Start nur leichte Metadaten. Felddaten und Indizes werden bei Bedarf aus dem entfernten Objektspeicher abgerufen, wenn eine Abfrage sie benötigt, und lokal zwischengespeichert, wenn häufig auf sie zugegriffen wird. Inaktive Daten können verdrängt werden, um Speicherplatz freizugeben.

Dadurch bleiben heiße Daten für Abfragen mit geringer Latenz in der Nähe der Berechnungsschicht, während kalte Daten im Objektspeicher verbleiben, bis sie benötigt werden. Dies verkürzt die Ladezeit, verbessert die Ressourceneffizienz und ermöglicht QueryNodes die Abfrage von Datensätzen, die weit größer sind als ihre lokale Speicher- oder Festplattenkapazität.

In der Praxis funktioniert Tiered Storage wie folgt:

Halten Sie heiße Daten lokal: Etwa 20 % der Daten, auf die häufig zugegriffen wird, verbleiben auf den lokalen Knoten, wodurch eine geringe Latenz für die 80 % der wichtigsten Abfragen gewährleistet wird.
Laden Sie kalte Daten bei Bedarf: Die verbleibenden 80 % der Daten, auf die nur selten zugegriffen wird, werden nur bei Bedarf abgerufen, wodurch ein Großteil der lokalen Speicher- und Festplattenressourcen frei wird.
Dynamische Anpassung mit LRU-basierter Auslagerung: Milvus verwendet eine LRU (Least Recently Used) Verdrängungsstrategie, um kontinuierlich anzupassen, welche Daten als heiß oder kalt eingestuft werden. Inaktive Daten werden automatisch verdrängt, um Platz für neu zugreifende Daten zu schaffen.

Mit diesem Design ist Milvus nicht mehr an die feste Kapazität des lokalen Speichers und der Festplatte gebunden. Stattdessen fungieren die lokalen Ressourcen als dynamisch verwalteter Cache, in dem kontinuierlich Platz von inaktiven Daten zurückgewonnen und aktiven Arbeitslasten neu zugewiesen wird.

Dieses Verhalten wird durch drei technische Kernmechanismen ermöglicht:

1. Lazy Load

Bei der Initialisierung lädt Milvus nur minimale Metadaten auf Segmentebene, so dass die Sammlungen fast sofort nach dem Start abfragbar werden. Felddaten und Indexdateien verbleiben im entfernten Speicher und werden bei Bedarf während der Abfrageausführung abgerufen, wodurch der lokale Speicher- und Festplattenverbrauch niedrig gehalten wird.

Wie das Laden von Sammlungen in Milvus 2.5 funktioniert

Wie das träge Laden in Milvus 2.6 und später funktioniert

Die während der Initialisierung geladenen Metadaten fallen in vier Hauptkategorien:

Segmentstatistiken (grundlegende Informationen wie Zeilenzahl, Segmentgröße und Schema-Metadaten)
Zeitstempel (werden zur Unterstützung von Zeitreiseabfragen verwendet)
Einfüge- und Löschdatensätze (erforderlich, um die Datenkonsistenz während der Ausführung von Abfragen aufrechtzuerhalten)
Bloom-Filter (für eine schnelle Vorfilterung zur schnellen Eliminierung irrelevanter Segmente)

2. Partielles Laden

Während Lazy Loading steuert, wann Daten geladen werden, steuert Partial Loading, wie viele Daten geladen werden. Sobald Abfragen oder Suchvorgänge beginnen, führt der QueryNode ein partielles Laden durch, wobei er nur die erforderlichen Datenchunks oder Indexdateien aus dem Objektspeicher abruft.

Vektor-Indizes: Mieterorientiertes Laden

Eine der wichtigsten Funktionen, die in Milvus 2.6+ eingeführt wurden, ist das mandantenfähige Laden von Vektorindizes, das speziell für mandantenfähige Arbeitslasten entwickelt wurde.

Wenn eine Abfrage auf Daten eines einzelnen Mandanten zugreift, lädt Milvus nur den Teil des Vektorindexes, der zu diesem Mandanten gehört, und überspringt die Indexdaten für alle anderen Mandanten. Dadurch bleiben die lokalen Ressourcen auf die aktiven Mandanten konzentriert.

Dieses Design bietet mehrere Vorteile:

Vektorindizes für inaktive Tenants verbrauchen keinen lokalen Speicher oder Festplatte
Indexdaten für aktive Tenants bleiben im Cache für einen Zugriff mit geringer Latenz
Eine LRU-Räumungsrichtlinie auf Mandantenebene gewährleistet eine faire Cache-Nutzung über alle Mandanten hinweg.

Skalare Felder: Partielles Laden auf Spaltenebene

Partielles Laden gilt auch für skalare Felder, wodurch Milvus nur die Spalten laden kann, auf die eine Abfrage explizit verweist.

Stellen Sie sich eine Sammlung mit 50 Schemafeldern vor, wie id, vector, title, description, category, price, stock und tags, und Sie müssen nur drei Felder zurückgeben -id, title und price.

In Milvus 2.5 werden alle 50 skalaren Felder unabhängig von den Abfrageanforderungen geladen.
In Milvus 2.6+ werden nur die drei angeforderten Felder geladen. Die restlichen 47 Felder bleiben ungeladen und werden nur dann abgerufen, wenn später auf sie zugegriffen wird.

Die Ressourceneinsparungen können erheblich sein. Wenn jedes skalare Feld 20 GB belegt:

Das Laden aller Felder erfordert 1.000 GB (50 × 20 GB)
Das Laden nur der drei benötigten Felder benötigt 60 GB

Dies entspricht einer Reduzierung des Ladens skalarer Daten um 94 %, ohne die Korrektheit der Abfrage oder die Ergebnisse zu beeinträchtigen.

Hinweis: Tenant-aware partielles Laden für skalare Felder und Vektorindizes wird offiziell in einer der nächsten Versionen eingeführt. Sobald diese verfügbar ist, wird sie die Ladelatenz weiter reduzieren und die Leistung von Cold-Queries in großen mandantenfähigen Implementierungen verbessern.

3. LRU-basierte Cache-Evakuierung

Durch Lazy Loading und Partial Loading wird die Menge der Daten, die in den lokalen Speicher und auf die Festplatte gebracht werden, erheblich reduziert. In Systemen, die lange laufen, wächst der Cache jedoch weiter an, da im Laufe der Zeit auf neue Daten zugegriffen wird. Wenn die lokale Kapazität erreicht ist, tritt die LRU-basierte Cache-Evakuierung in Kraft.

Die LRU-Auslagerung (Least Recently Used) folgt einer einfachen Regel: Daten, auf die in letzter Zeit nicht zugegriffen wurde, werden zuerst ausgelagert. Dadurch wird lokaler Speicherplatz für neu aufgerufene Daten frei, während häufig verwendete Daten im Cache verbleiben.

Leistungsbewertung: Tiered Storage vs. Full Loading

Um die Auswirkungen von Tiered Storage in der Praxis zu bewerten, haben wir eine Testumgebung eingerichtet, die den Arbeitslasten in der Produktion sehr ähnlich ist. Wir verglichen Milvus mit und ohne Tiered Storage in fünf Dimensionen: Ladezeit, Ressourcenverbrauch, Abfrageleistung, effektive Kapazität und Kosteneffizienz.

Experimenteller Aufbau

Datensatz

100 Millionen Vektoren mit 768 Dimensionen (BERT-Einbettungen)
Vektorindexgröße: ca. 430 GB
10 skalare Felder, einschließlich ID, Zeitstempel und Kategorie

Hardware-Konfiguration

1 QueryNode mit 4 vCPUs, 32 GB Speicher und 1 TB NVMe SSD
10 Gbps Netzwerk
MinIO-Objektspeichercluster als entferntes Speicher-Backend

Zugriffsmuster

Abfragen folgen einer realistischen Hot-Cold-Zugriffsverteilung:

80% der Abfragen zielen auf Daten der letzten 30 Tage (≈20% der Gesamtdaten)
15% zielen auf Daten aus 30-90 Tagen (≈30% der Gesamtdaten)
5% zielen auf Daten, die älter als 90 Tage sind (≈50% der Gesamtdaten)

Wichtigste Ergebnisse

1. 33× schnellere Ladezeit

Stufe	Milvus 2.5	Milvus 2.6+ (gestaffelter Speicher)	Beschleunigung
Herunterladen von Daten	22 Minuten	28 Sekunden	47×
Laden des Index	3 Minuten	17 Sekunden	10.5×
Insgesamt	25 Minuten	45 Sekunden	33×

In Milvus 2.5 dauerte das Laden der Sammlung 25 Minuten. Mit Tiered Storage in Milvus 2.6+ wird dieselbe Arbeitslast in nur 45 Sekunden abgeschlossen, was eine deutliche Verbesserung der Ladeeffizienz darstellt.

2. 80%ige Reduzierung des lokalen Ressourcenverbrauchs

Stufe	Milvus 2.5	Milvus 2.6+ (Tiered Storage)	Reduktion
Nach Belastung	430 GB	12 GB	-97%
Nach 1 Stunde	430 GB	68 GB	-84%
Nach 24 Stunden	430 GB	85 GB	-80%
Ständiger Zustand	430 GB	85-95 GB	~80%

In Milvus 2.5 bleibt die lokale Ressourcennutzung konstant bei 430 GB, unabhängig von Arbeitslast oder Laufzeit. Im Gegensatz dazu startet Milvus 2.6+ mit nur 12 GB direkt nach dem Laden.

Während der Ausführung von Abfragen werden häufig abgerufene Daten lokal zwischengespeichert, und die Ressourcennutzung steigt allmählich an. Nach etwa 24 Stunden stabilisiert sich das System bei 85-95 GB, was den Arbeitsbestand an heißen Daten widerspiegelt. Langfristig führt dies zu einer Verringerung des lokalen Arbeitsspeichers und der Festplattennutzung um ca. 80 %, ohne die Verfügbarkeit der Abfragen zu beeinträchtigen.

3. Nahezu keine Auswirkungen auf die Hot-Data-Leistung

Abfragetyp	Milvus 2.5 P99 Latenzzeit	Milvus 2.6+ P99-Latenzzeit	Änderung
Hot-Data-Abfragen	15 ms	16 ms	+6.7%
Warme Datenabfragen	15 ms	28 ms	+86%
Kalte Datenabfragen (erster Zugriff)	15 ms	120 ms	+700%
Abfragen von kalten Daten (im Cache)	15 ms	18 ms	+20%

Bei Hot Data, die etwa 80 % aller Abfragen ausmachen, erhöht sich die P99-Latenz nur um 6,7 %, was in der Produktion praktisch keine spürbaren Auswirkungen hat.

Abfragen von kalten Daten weisen aufgrund des bedarfsgesteuerten Ladens aus dem Objektspeicher beim ersten Zugriff eine höhere Latenz auf. Nach dem Zwischenspeichern steigt die Latenz jedoch nur noch um 20 %. Angesichts der geringen Zugriffshäufigkeit von Cold Data ist dieser Kompromiss für die meisten realen Arbeitslasten akzeptabel.

4. 4,3× größere effektive Kapazität

Bei gleichem Hardware-Budget - acht Server mit je 64 GB Speicher (insgesamt 512 GB) - kann Milvus 2.5 maximal 512 GB Daten laden, was etwa 136 Millionen Vektoren entspricht.

Mit der in Milvus 2.6+ aktivierten Tiered Storage-Funktion kann dieselbe Hardware 2,2 TB an Daten oder etwa 590 Millionen Vektoren unterstützen. Dies stellt eine 4,3-fache Steigerung der effektiven Kapazität dar und ermöglicht es, wesentlich größere Datensätze zu verarbeiten, ohne den lokalen Speicher zu erweitern.

5. 80,1 % Kostenreduzierung

Am Beispiel eines 2-TB-Vektordatensatzes in einer AWS-Umgebung und unter der Annahme, dass 20 % der Daten heiß sind (400 GB), ergibt sich der folgende Kostenvergleich:

Artikel	Milvus 2.5	Milvus 2.6+ (gestaffelter Speicher)	Einsparungen
Monatliche Kosten	$11,802	$2,343	$9,459
Jährliche Kosten	$141,624	$28,116	$113,508
Ersparnis	-	-	80.1%

Benchmark-Zusammenfassung

Über alle Tests hinweg liefert Tiered Storage konsistente und messbare Verbesserungen:

33× schnellere Ladezeiten: Die Ladezeit der Sammlung wurde von 25 Minuten auf 45 Sekunden reduziert.
80% geringere lokale Ressourcennutzung: Im Dauerbetrieb sinken Arbeitsspeicher und lokale Festplattennutzung um etwa 80 %.
Nahezu keine Auswirkungen auf die Leistung bei heißen Daten: Die P99-Latenz für heiße Daten erhöht sich um weniger als 10 %, so dass die Abfrageleistung mit niedriger Latenz erhalten bleibt.
Kontrollierte Latenz für kalte Daten: Bei kalten Daten entsteht beim ersten Zugriff eine höhere Latenz, die jedoch angesichts der geringen Zugriffshäufigkeit akzeptabel ist.
4,3× höhere effektive Kapazität: Dieselbe Hardware kann ohne zusätzlichen Speicher 4-5x mehr Daten verarbeiten.
Über 80 % Kostenreduzierung: Die jährlichen Infrastrukturkosten werden um mehr als 80 % gesenkt.

Wann wird Tiered Storage in Milvus verwendet?

Auf der Grundlage von Benchmark-Ergebnissen und realen Produktionsfällen haben wir Tiered-Storage-Anwendungsfälle in drei Kategorien eingeteilt, um Ihnen die Entscheidung zu erleichtern, ob es für Ihre Arbeitslast geeignet ist.

Best-Fit-Anwendungsfälle

1. Multimandanten-Vektorsuchplattformen

Merkmale: Große Anzahl von Mandanten mit sehr ungleichmäßiger Aktivität; Vektorsuche ist die Hauptarbeitslast.
Zugriffsmuster: Weniger als 20 % der Mieter generieren mehr als 80 % der Vektorsuchanfragen.
Erwartete Vorteile: 70-80%ige Kostensenkung; 3-5fache Kapazitätserweiterung.

2. Empfehlungssysteme für den elektronischen Handel (Vektorsuchlasten)

Merkmale: Starke Beliebtheitsskala zwischen Top-Produkten und dem Long Tail.
Zugriffsmuster: Die obersten 10% der Produkte machen ~80% des Vektorsuchverkehrs aus.
Erwartete Vorteile: Kein Bedarf an zusätzlicher Kapazität bei Spitzenereignissen; 60-70 % Kostenreduzierung

3. Große Datensätze mit klarer Heiß-Kalt-Trennung (vektordominant)

Merkmale: TB-große oder größere Datensätze, bei denen der Zugriff stark auf aktuelle Daten ausgerichtet ist.
Zugriffsmuster: Eine klassische 80/20-Verteilung: 20 % der Daten dienen 80 % der Abfragen
Erwartete Vorteile: 75-85 % Kostenreduzierung

Gut geeignete Anwendungsfälle

1. Kostenempfindliche Arbeitslasten

Merkmale: Knappe Budgets mit einer gewissen Toleranz für geringfügige Leistungsabstriche.
Zugriffsmuster: Vektorielle Abfragen sind relativ konzentriert.
Erwartete Vorteile: 50-70 % Kostenreduzierung; bei kalten Daten kann beim ersten Zugriff eine Latenz von ~500 ms auftreten, die anhand der SLA-Anforderungen bewertet werden sollte.

2. Historische Datenspeicherung und Archivierungssuche

Merkmale: Große Mengen an historischen Vektoren mit sehr geringer Abfragehäufigkeit.
Zugriffsmuster: Etwa 90 % der Abfragen zielen auf aktuelle Daten ab.
Erwartete Vorteile: Beibehaltung vollständiger historischer Datensätze; Vorhersehbarkeit und Kontrolle der Infrastrukturkosten

Schlecht geeignete Anwendungsfälle

1. Gleichmäßig heiße Daten-Workloads

Merkmale: Auf alle Daten wird mit ähnlicher Häufigkeit zugegriffen, ohne klare Unterscheidung zwischen heiß und kalt.
Warum ungeeignet: Begrenzter Cache-Nutzen; zusätzliche Systemkomplexität ohne nennenswerte Vorteile

2. Workloads mit extrem niedriger Latenz

Merkmale: Extrem latenzempfindliche Systeme, z. B. Finanzhandel oder Bieterverfahren in Echtzeit
Warum ungeeignet: Selbst kleine Latenzschwankungen sind inakzeptabel; Volllast bietet besser vorhersehbare Leistung

Schnellstart: Testen Sie Tiered Storage in Milvus 2.6+

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

Schlussfolgerung:

Tiered Storage in Milvus 2.6 behebt eine häufige Diskrepanz zwischen der Art und Weise, wie Vektordaten gespeichert werden und wie auf sie tatsächlich zugegriffen wird. In den meisten Produktionssystemen wird nur ein kleiner Teil der Daten häufig abgefragt, doch die traditionellen Lademodelle behandeln alle Daten als gleich heiß. Durch die Umstellung auf bedarfsgesteuertes Laden und die Verwaltung des lokalen Speichers und der Festplatte als Cache passt Milvus den Ressourcenverbrauch an das tatsächliche Abfrageverhalten an und nicht an Worst-Case-Annahmen.

Mit diesem Ansatz können Systeme auf größere Datensätze skaliert werden, ohne dass die lokalen Ressourcen proportional ansteigen, während die Leistung bei heißen Abfragen weitgehend unverändert bleibt. Kalte Daten bleiben bei Bedarf zugänglich, mit vorhersehbaren und begrenzten Latenzzeiten, so dass der Kompromiss eindeutig und kontrollierbar ist. Da die Vektorsuche immer mehr in kostensensitive, mandantenfähige und langlaufende Produktionsumgebungen vordringt, bietet Tiered Storage eine praktische Grundlage für einen effizienten Betrieb in großem Maßstab.

Weitere Informationen über Tiered Storage finden Sie in der unten stehenden Dokumentation:

Tiered Storage | Milvus-Dokumentation

Haben Sie Fragen oder möchten Sie einen tieferen Einblick in eine Funktion des neuesten Milvus? Treten Sie unserem Discord-Kanal bei oder stellen Sie Fragen auf GitHub. Sie können auch eine 20-minütige Einzelsitzung buchen, um Einblicke, Anleitung und Antworten auf Ihre Fragen über die Milvus Office Hours zu erhalten.