Aufbau von Zilliz Cloud in 18 Monaten: Erkenntnisse aus der Erstellung eines skalierbaren Vektorsuchdienstes in der Public Cloud
Vorwort
Vektordatenbanken haben sich 2023 als ein führender Trend in der Datenbankbranche herauskristallisiert. Dieser Beitrag beschreibt die Entwicklung von Zilliz Cloud, einem vollständig verwalteten Service auf Basis von Milvus, der am weitesten verbreiteten Open-Source-Vektordatenbank, die über achtzehn Monate hinweg von Grund auf entwickelt wurde. Während dieser Zeit entwickelten wir einen umfassenden Cloud-Service von Grund auf und bewältigten einen zehnfachen Anstieg des Traffics, angetrieben durch die rasante Verbreitung von Large Language Models (LLM). Dieser Rückblick konzentriert sich darauf, die entscheidenden Designentscheidungen und wertvollen Erkenntnisse zu teilen, die wir auf unserem Weg gewonnen haben.
Zilliz Cloud Dedicated Cluster - Die Reise beginnt
Drehen wir die Uhr zurück auf Mai 2022: Die Open-Source-Vektordatenbank Milvus 2.0 begann nach mehreren großen Iterationen endlich, sich zu stabilisieren. In Gesprächen mit unseren Nutzern zeigte sich der Bedarf an einer stabilen, kommerziell gehosteten Version als wiederkehrende Anfrage. Für Zilliz, das kommerzielle Unternehmen hinter Milvus, schien der Zeitpunkt perfekt, um die Kommerzialisierung anzugehen—wir hatten ein erfahrenes Entwicklerteam, ein reifendes Produkt und eine engagierte Nutzerbasis mit dringenden Bedürfnissen. Vor diesem Hintergrund setzten wir uns ein ehrgeiziges Ziel: unser Produkt innerhalb von sechs Monaten auf den Markt zu bringen.
Als wir das Projekt starteten, bewerteten wir unsere aktuellen Fähigkeiten und Ziele:
- Unsere Kerntechnologie, eine cloud-native Open-Source-Vektordatenbank, die mit Speicher-Rechen-Entkopplung und einem Microservices-Framework entwickelt wurde, ist für die nahtlose Integration in einen Kubernetes (K8s)-Cluster konzipiert. Dieses cloud-native Framework ermöglicht es uns, uns schnell an Cloud-Produktionsumgebungen anzupassen.
Figure 1: Milvus Architecture
Da wir den Kubernetes Operator nutzten, waren wir in der Lage, Services schnell über große Public-Cloud-Plattformen wie AWS und GCP hinweg bereitzustellen; dies wurde von mehreren Nutzern bestätigt, die ihre Produktionsservices erfolgreich in der Public Cloud implementiert haben.
Unsere Plattform umfasste grundlegende Observability-Funktionen wie Monitoring und Logging, benötigte jedoch entscheidende Alerting-Funktionen für die Produktion.
Zusätzlich zu den zuvor genannten Elementen fehlten uns als Service mehrere kritische Komponenten, darunter unter anderem Benutzerauthentifizierung beim Login, Metering und Billing, Zahlungsmechanismen, Networking, Sicherheit, eine Webkonsole, OpenAPI-Unterstützung, Ressourcenplanung und Workflow-Management.
Die Eingrenzung, welche essenziellen Module innerhalb von sechs Monaten gebaut werden sollten, stellte eine gewaltige Aufgabe dar. Als Reaktion darauf führten wir eine kritische Selbstbewertung durch: Wie könnten wir verfügbare Ressourcen am effizientesten nutzen? Könnten wir unseren Ansatz so verdichten, dass eine schlanke, aber voll funktionsfähige Version entsteht? Diese zentralen Fragen lenkten unsere Überlegungen und formten letztlich eine Reihe grundlegender Designprinzipien:
Die Nutzung ausgereifter Drittanbieterprodukte maximieren, um das Rad nicht neu zu erfinden:
Mit dem Fokus auf eine schnelle Marktreife stützten wir uns strategisch auf etablierte Cloud- und Drittanbieterdienste. Wir nutzten zentrale AWS-Services wie EKS, EC2, S3, EBS und ALB sowie von AWS verwaltete Kafka- und RDS-Dienste als Rückgrat unserer Infrastruktur. Dieser Ansatz erfüllte nicht nur unsere unmittelbaren Anforderungen, sondern zeigte auch, dass solche Komponenten einen kosteneffizienten Weg für eine zukünftige Anpassung an eine Multi-Cloud-Umgebung bieten und damit unser Innovationstempo beschleunigen. Konfrontiert mit Kompatibilitätsproblemen zwischen GCP/Azure-Message-Queues und verwalteten Kafka-Diensten entwickelten wir unser verteiltes Log-System, verankert auf Apache Bookkeeper. Der Mangel an zuverlässigen, Open-Source- oder cloud-nativen Lösungen für verteiltes Logging trieb dieses Vorhaben voran. Motiviert durch diese Lücke erwägen wir, unsere Lösung als Open Source zu veröffentlichen, in der Hoffnung, dass sie anderen beim Aufbau von Cloud-Services helfen wird.
Drittanbieter-SaaS-Anbieter waren entscheidend dafür, die Entwicklung unserer Plattform zu beschleunigen. Beispielsweise setzten wir Stripe ein, um unsere Zahlungsabwicklung zu verwalten und komplexe Anforderungen an Metering und Besteuerung zu erfüllen. Um Verbindungen mit Multi-Cloud-Marktplätzen zu erleichtern, integrierten wir Sugar.io. Darüber hinaus evaluierten wir Billing-Service-Plattformen wie Orb und Metronome, um unsere Billing-Operationen zu verbessern. Auth0 war unser Produkt der Wahl für Account-Management und Login-Funktionalität; außerdem erweiterten wir unsere Authentifizierungs- und Login-Funktionalität um Unterstützung für Google-Login. Wir etablierten unser operatives Alerting-System auf PagerDuty, das aufgrund seiner schnellen Integration in unsere bestehenden Monitoring-Tools und seiner Vielseitigkeit bei der Anpassung von Benachrichtigungsregeln ausgewählt wurde.
Entitäten sollten nicht unnötig vervielfacht werden
Geleitet von der Philosophie von Occams Razor verfolgten wir einen minimalistischen Designansatz, der sich in verschiedenen Aspekten des Produkts manifestierte:
Architektur-Einfachheit: Anfangs umfasste unser Design über 60 Microservices, was erhebliche Herausforderungen bei der Koordination von Entwicklung und Tests mit sich brachte. Um unsere Architektur zu vereinfachen, reduzierten wir die Anzahl auf weniger als zehn zentrale Microservices, darunter user, billing, CloudService, resources, metadata und scheduling. Diese Reduzierung klärte Abhängigkeiten und verringerte den Testaufwand.
Funktionale Einfachheit: In seiner ersten Iteration lag der Schwerpunkt von Zilliz Cloud auf zentralen Benutzerfunktionen wie Registrierung, Cluster-Bereitstellung und Billing, während wir weniger dringende Funktionen wie Skalierung und Backups bewusst zurückstellten, um die Arbeitslast zu verringern. Bemerkenswert war unser Engagement für die Etablierung einer robusten Feedback-Schleife, die zunächst E-Mail-basiertes Feedback ermöglichte und anschließend durch die Integration von Zendesk erweitert wurde, um sicherzustellen, dass zeitnahes und hochwertiges Feedback uns bei weiteren Verbesserungen leiten konnte.
Design-Einfachheit: Unser Cloud-Service-Design priorisierte effiziente Kommunikation und das Potenzial zur Nutzerbindung und erforderte einen disziplinierten und fokussierten Ansatz. Der Einsatz schneller A/B-Tests ermöglichte es uns, Funktionen rasch zu validieren und sie auf Basis von Kennzahlen zur Nutzerbindung anzupassen.
Antizipieren Sie Day-2-Herausforderungen ab Day 1:
In der dynamischen Landschaft der Cloud-Services ist die Fähigkeit, sich schnell weiterzuentwickeln, ohne die Zuverlässigkeit von Benutzeroberflächen und Services zu opfern, von größter Bedeutung. Dieses komplexe Manöver ähnelt dem „Austauschen der Triebwerke mitten im Flug“. Für den externen Beobachter funktioniert der Service einwandfrei, während intern ein intensiver Zyklus aus Innovation und Verbesserung im Gange ist. Ein Entwicklungsansatz mit dem Endziel vor Augen ist entscheidend.
Multi-Cloud-Support: Anfangs auf AWS fokussiert, hat unser Ansatz stets Cloud-Agnostizismus priorisiert. Wir evaluierten Anbieter wie GCP und Alibaba Cloud umfassend, um Kompatibilität über Public Clouds hinweg sicherzustellen. Durch Anpassungen am Open-Source-Projekt Crossplane entwickelten wir eine „Cloud-Adapter“-Schicht, die die mit Multi-Cloud-Support verbundenen Kosten reduzierte. Dieses Design ermöglichte eine schnelle Integration mit GCP in nur einem Monat und vereinfachte die Integration mit anderen Public-Cloud-Anbietern.
Sicherheit: Während AIGC-Anwendungsentwickler möglicherweise andere Aspekte als Sicherheit priorisieren, misst Zilliz Cloud Services der Datensicherheit höchste Bedeutung bei. Unter strikter Einhaltung von Cloud-IAM-Standards kontrollieren wir Datenzugriffsberechtigungen sorgfältig und setzen Verschlüsselung für alle Daten ein, sowohl während der Übertragung als auch im Ruhezustand. Mit dem Fokus auf Netzwerkisolation für optimale Performance wählten wir die EKS-Netzwerk-Add-ons von AWS aufgrund ihrer Effizienz und Benutzerfreundlichkeit aus. Die Abgrenzung der Interaktionsgrenzen zwischen Daten- und Steuerungsschichten hat während des Rollouts unseres BYOC-Produkts zu erheblichen Kosteneinsparungen geführt.
Ressourcen-Pooling: Zilliz Cloud Services folgt dem „Gesetz der Cloud-Kommutativität“ und priorisiert elastische Skalierbarkeit durch Ressourcen-Pooling. Durch die Trennung von Speicher und Rechenleistung sowie den Einsatz dynamischer Lastverteilung stellen wir eine effiziente Nutzung von Cloud-Ressourcen sicher. Dieser Ansatz ermöglicht es uns, Ressourcen nur bei Bedarf zu reservieren, wodurch die Auslastung von Spot Instances und Lambda functions erheblich verbessert und gleichzeitig Kosten gesenkt werden.
Betriebsfreundlich: Zilliz Cloud wurde im Gegensatz zu anderen Vektordatenbanken mit Blick auf Entwickler und Betriebsteams entwickelt. Mit einer umfassenden GUI und ausgefeilten Monitoring-Funktionen bietet die Plattform Triple-AZ-Disaster-Recovery und hält strenge SLAs ein, wodurch Stabilität und Zuverlässigkeit für Produktionsumgebungen gewährleistet werden.
Geleitet von unseren zentralen Designphilosophien erreichten wir den Meilenstein, unser kommerzielles Vektorsuchprodukt in nur sechs Monaten auf den Markt zu bringen und dabei unsere erste Gruppe von Seed-Kunden zu gewinnen. Unten finden Sie das Architekturdiagramm für unsere erste Veröffentlichung.
Abbildung 2- Zilliz Cloud Architektur
Serverless: Von $300 auf $5 Kosten für die Gewinnung neuer Nutzer
Wachstum tritt oft in unerwarteten Momenten auf. Nachdem unsere SaaS-Dienste drei Monate lang stetig gewachsen waren, erreichte das Wachstum von Zilliz Cloud, befeuert durch die explosionsartige Popularität von AutoGPT, einen Höhepunkt. Die Betrachtung von Vektordatenbanken als Langzeitgedächtnis für Large Language models fand allmählich Akzeptanz, was zu einem raschen Anstieg der Nutzerbasis von Zilliz führte, wobei die Zahl der täglich neu hinzugefügten Cluster schnell in die Hunderte stieg.
Dieses Wachstum brachte Zilliz jedoch zwei zentrale Herausforderungen: Stabilität und Kosten. Obwohl wir uns stets auf Skalierbarkeit konzentrierten, legten die plötzlichen Traffic-Spitzen mit hohem Volumen nahezu alle unsere Dienste lahm, wobei nur die Kerndatenbank unbeschadet blieb. Die von Cloud-Service-Providern bereitgestellten APIs wurden gedrosselt, und unser Logging-Speichersystem Loki war innerhalb weniger Tage zweimal voll, wodurch viele Dienste aufgrund fehlender Ressourcen unterbrochen werden mussten.
Darüber hinaus führte die anfängliche kostenlose Teststrategie von Zilliz Cloud, die neuen Nutzern $300 Credits bot, um alle Funktionen auszuprobieren, zu einem starken Kostenanstieg, als die Zahl der Nutzer sprunghaft anstieg (von denen die meisten den Dienst ausprobierten), was uns zwang, unser Geschäftsmodell zu überdenken. Diese Schmerzpunkte veranlassten uns, Zilliz Cloud Serverless einzuführen, ein Produkt, das flexibler ist, eine niedrigere Einstiegshürde hat und besser für AIGC-Nutzer geeignet ist, die gerade erst mit ihrer Vektordatenbank-Reise beginnen.
Der Heilige Gral ist noch immer da draußen: Skalierbarkeit, Kosten und Latenz für die RAG-Anwendungsentwicklung beherrschen
Für den Anwendungsfall Retrieval-Augmented Generation (RAG) muss die ideale Free-Tier-Lösung Folgendes berücksichtigen:
Abbildung 3: Skalierbarkeit, Kosten und Latenz in RAG-Anwendungen beherrschen
Skalierbarkeit — Dies umfasst zwei zentrale Aspekte:
Auf der Ebene einzelner Mandanten muss das System dynamisch skalieren, um Daten effektiv zu verarbeiten. Diese dynamische Skalierung erfordert, dass die Vektordatenbank vielseitig genug ist, um sich an die schwankenden Datenvolumina verschiedener Mandanten anzupassen, unabhängig davon, ob sie kleine oder große Datensätze verarbeiten. Durchgehend stabile Antwortzeiten für Abfragen müssen unabhängig von der Größe der verarbeiteten Daten gewährleistet bleiben.
Bei der Verwaltung vieler Mandanten muss das System die Skalierbarkeit auf bis zu Millionen von Mandanten effizient unterstützen. Insbesondere sollte es die „heißen“ (hochaktiven) und „kalten“ (weniger aktiven) Nutzungsmuster intelligent unterscheiden und berücksichtigen, um eine optimale Ressourcenzuweisung und konsistente Leistung über die gesamte Plattform hinweg sicherzustellen.
Kosten — Kostenkontrolle für die kostenlose Stufe ist entscheidend. Idealerweise sollten die Kosten unter $1 gehalten werden, während genügend Ressourcen bereitgestellt werden, um 1 Million 768-dimensionale Vektoren zu unterstützen. Bei der Verwendung von In-Memory-Vektorindizierung kann der Preis für die Verarbeitung von 1 Million 768-dimensionalen Vektoren jedoch leicht $10 übersteigen. Während diese Kosten für SaaS-Unternehmen, die auf Enterprise-Services abzielen, akzeptabel sein mögen, sind sie für verbraucherorientierte ToC-Anwendungen übermäßig hoch.
Niedrige Latenz — Obwohl RAG-Anwendungsfälle möglicherweise nicht so latenzempfindlich sind wie die Bereiche Suche und Empfehlung, wirkt sich die Leistung des Vektorabrufs erheblich auf die "Time-to-first-token" aus. Daher ist die Aufrechterhaltung niedriger Latenz entscheidend, um die Benutzererfahrung und die Reaktionsfähigkeit des Systems zu verbessern.
Das ursprüngliche Angebot von Zilliz Cloud zeigte eine herausragende Skalierbarkeit bei der Verarbeitung großer Datenmengen und beim Erreichen niedriger Latenz und übertraf damit die Erwartungen der Benutzer. Selbst bei der Verwaltung zahlreicher Mandanten und der Kostenkontrolle konnte die dedizierte Cluster-Lösung die Benutzeranforderungen nicht vollständig erfüllen. Um dies zu beheben, haben wir die 'Zilliz Serverless Tier' entwickelt, ein Servicemodell, das speziell darauf ausgelegt ist, die Einstiegshürde für einzelne AIGC-Benutzer zu senken. Diese Stufe bietet die kosteneffizientesten Speicherlösungen und Skalierbarkeit, um die oben genannten Herausforderungen wirksam zu bewältigen.
Die Zilliz Cloud Serverless-Architektur
Figure 4- Die Zilliz Cloud Serverless-Architektur
Zilliz Cloud Serverless führt das Konzept logischer Cluster ein, wobei jeder logische Cluster einer Datenbank in einem physischen Cluster entspricht. Wir erreichen eine logische Isolation für alle Mandanten innerhalb eines einzelnen physischen Clusters durch datenbank- und API-Schlüssel-basierte Authentifizierungsmechanismen. Während Abfragen leitet das System Anfragen basierend auf API-Schlüsseln weiter, um die Daten zu bestimmen, auf die Benutzer zugreifen müssen, wobei Proxy-Knoten für das Routing verwendet werden.
Datenschreibvorgänge werden zunächst an einen Pool von Log-Knoten gesendet, die die Daten dann in einen Write-Ahead Logging (WAL)-Dienst schreiben, die Daten regelmäßig neu organisieren und in den Objektspeicher flushen. Der CompactionService ist ein Pooling-Dienst, der dafür verantwortlich ist, kleinere Datensegmente zu größeren zusammenzuführen und gelöschte Einträge zu bereinigen, wodurch Speicherplatz und Zugriffsgeschwindigkeit optimiert werden. Der Index Service ist für den Aufbau von Indizes auf Rohdaten verantwortlich, die anschließend von Query-Knoten geladen werden, um die Abfrageeffizienz sicherzustellen.
Während Abfrageoperationen besteht unsere Strategie darin, alle Daten auf den lokalen Festplatten der Query Nodes zwischenzuspeichern und Memory-to-Disk-Swapping lokal auszuführen. Diese Methodik reduziert die Speicherkosten für Serverless-Benutzer im Vergleich zur speicherbasierten Indizierung um mehr als das Zehnfache erheblich. Eine zentrale Herausforderung liegt jedoch darin, Ressourcen effektiv zu verwalten, um eine Überlastung der Query-Knoten durch Tenant-Hotspot-Probleme und Noisy Neighbors zu verhindern. Dies ist besonders wichtig, da jeder Query Node das Laden von Daten von mehreren Mandanten bewältigen muss.
Um die Systemstabilität zu verbessern, haben wir die folgenden drei wichtigen Mechanismen eingeführt:
Distributed Quota: Dieser Mechanismus, der auf einem zentralisierten Quota-Service basiert, weist Ressourcenkontingente dynamisch zu und passt sie basierend auf der Last der Query-Knoten an. Diese dynamische Zuweisung trägt dazu bei, einen fairen Ressourcenverbrauch für jeden Mandanten sicherzustellen.
Distributed Quota: Dieser Mechanismus, der auf einem zentralisierten Quota-Service basiert, weist Ressourcenkontingente dynamisch zu und passt sie basierend auf der Last der Query-Knoten an. Dies trägt dazu bei, einen fairen Ressourcenverbrauch für jeden Mandanten sicherzustellen.
Dynamische Ressourcenskalierung basierend auf Metriken: Wir haben ein Cloud Resource Scheduler-Modul integriert, das Speicher, Festplatte, CPU-Lasten und Anfragewarteschlangen umfassend verwaltet. Es ermöglicht die dynamische Skalierung physischer Ressourcen, um unterschiedlichen Ressourcenanforderungen in verschiedenen Szenarien gerecht zu werden.
Mehrstufige Planung: Wir haben ein Framework für die Ressourcenplanung etabliert, das über verschiedene Ebenen hinweg arbeitet und physische Isolation durch Ressourcengruppierung, Lastverteilung innerhalb dieser Ressourcengruppen sowie die Verwaltung von Abfragewarteschlangen und Cache-Planung auf Knotenebene umfasst. Dieser Ansatz gewährleistet eine gerechte Ressourcenzuweisung zwischen mehreren Mandanten und mindert gleichzeitig das Risiko, dass ein einzelner Mandant Ressourcen monopolisiert.
Durch unseren Serverless-Dienst haben wir die Testkosten für einzelne Nutzer erfolgreich auf 5 $ reduziert und unterstützen damit Zehntausende von AIGC-Entwicklern. In der kommenden Version von Zilliz Cloud verbessern wir unsere Serverless-Lösung weiter, damit sie noch kosteneffizienter und elastischer wird. In dieser neuen Version wird jeder Serverless-Nutzer in der Lage sein, Daten von Millionen von Mandanten in einer einzigen Collection zu verarbeiten, Datenisolation zu erreichen und gleichzeitig die Speicherkosten im Vergleich zur aktuellen Lösung um den Faktor zehn erheblich zu senken. Wir werden in zukünftigen Artikeln weiterhin auf die technischen Details von Zilliz Cloud Serverless eingehen.
Sechs Lektionen, die wir beim Aufbau eines Cloud-Dienstes aus einer Open-Source-VectorDB gelernt haben
Cloud-Beschränkungen erkennen: Selbst bei cloud-nativen Systemen wie Milvus stellt der Übergang zu Cloud-SaaS erhebliche Herausforderungen dar. Er geht über eine einfache Bereitstellung auf EC2 und EBS hinaus. Im Bereich der Open-Source-Datenbanken müssen Nutzer ein tiefes Verständnis der Produktdetails besitzen, um horizontale Skalierung, Fehlerbehebung und Leistungsoptimierung durch sorgfältiges Knob-Tuning zu erreichen. Die eigentliche Herausforderung bei Cloud-Diensten liegt darin, den Betrieb zu vereinfachen und gleichzeitig hohe Zuverlässigkeit und Elastizität zu gewährleisten. Die Bewältigung spezifischer Einschränkungen der Cloud-Umgebung, wie S3-Ratenlimits und Beschränkungen der OpenAPI-Aufruffrequenz, ist entscheidend, um das Elastizitäts- und Skalierbarkeitspotenzial des Cloud Computing voll auszuschöpfen.
Umsichtige Feature-Einführung: Auch wenn es in den frühen Phasen des Produkts verlockend erscheinen mag, kontinuierlich neue Features hinzuzufügen, um Kunden zu gewinnen, sollten die echten Pain Points der Nutzer priorisiert werden. Eine Vorlaufzeit von etwa sechs Monaten für Open-Source-Produktfeatures gegenüber der SaaS-Version ist ein guter Kompromiss. Diese Vorlaufzeit stellt sicher, dass diese Features gründlich getestet und verbessert werden, bevor sie für die Bereitstellung des Dienstes ausgerollt werden.
Angemessene Grenzen setzen: Kein Produkt ist fehlerfrei. Nehmen wir S3 als Beispiel. Trotz seiner eleganten Schnittstelle und umfassenden Verfeinerung können Entwickler seinen Wert nur in bestimmten Situationen maximieren. Anders als die Freiheit, die Open-Source-Produkte haben, benötigen SaaS-Produkte strengere Einschränkungen, um sich selbst zu schützen. Diese Einschränkungen bilden einen integralen Bestandteil des Produkts und dienen den Nutzern als Orientierung und Aufklärung. Angemessene Begrenzungen können Nutzer zu einer intelligenteren Produktnutzung führen und den Gesamtwert sowie die Nutzererfahrung verbessern.
Entscheidung für cloud-agnostische Abhängigkeitsdienste: Die Erwägung der Einführung cloud-agnostischer Abhängigkeitsdienste wie S3, EC2 und K8s Managed Services, die auf großen Cloud-Plattformen weit verbreitet sind, kann erhebliche Vorteile in Bezug auf Kostensenkung und Vereinfachung der Komplexität bei der Multi-Cloud-Einführung bieten. Alternativ kann die Entscheidung für SaaS-Dienste, die von Natur aus Multi-Cloud-Nutzung unterstützen, den Prozess vereinfachen. Trotz möglicher Unterschiede in der Implementierung zwischen verschiedenen Cloud-Service-Anbietern kann die frühzeitige Einrichtung einer Multi-Cloud-Anpassungsschicht redundante Entwicklungsaufwände effektiv minimieren und die Gesamteffizienz steigern.
Fokus auf Cloud FinOps: In der Public Cloud können scheinbar erschwingliche Ressourcen unerwartet zu hohen Kosten führen. Beispielsweise hatten wir vor der Durchführung einer Rechnungsanalyse noch nicht damit gerechnet, dass die ALB-Netzwerkbandbreitenkosten einen erheblichen Teil der Gesamtausgaben ausmachen könnten. Um Kosten zu optimieren und Leistungsoptimierungen zu maximieren, ist es unerlässlich, die Performance verschiedener Instanztypen und Dienste gründlich zu verstehen. Beispielsweise bietet jede GP3-Cloud-Festplatte 3000 IOPS; durch das Bündeln mehrerer Festplatten auf einer einzelnen Maschine und die Konfiguration von RAID kann der Festplattendurchsatz erheblich gesteigert werden, wodurch hohe Rechnungen für zusätzliche IOPS vermieden werden.
Die Bedeutung von Open API erkennen: Mit der zunehmenden Verbreitung von Agents wird die Rolle von Open API und der zugehörigen Dokumentation immer wichtiger. Traditionelle Cloud-Dienste verlassen sich auf Webkonsolen und grafische Oberflächen, um Funktionalität bereitzustellen, aber die zukünftige Interaktion und Integration von Cloud-Diensten wird zunehmend von OpenAPI abhängen. Der Grad der Serviceautomatisierung, Agent-Freundlichkeit und Observability ist zu entscheidenden Bewertungskriterien für zukünftige Cloud-Dienste geworden.
Epilog
Wenn wir auf die vergangenen 18 Monate zurückblicken, haben wir uns auf eine außergewöhnlich spannende und herausfordernde Reise begeben, bei der die Zeit scheinbar dreimal so schnell verging. Dieser rasche Fortschritt lässt sich auf mehrere Schlüsselfaktoren zurückführen: Erstens hat das Aufkommen von LLMs unsere Coding-Effizienz drastisch verbessert. Zweitens ist die schnelle und einhellige Anerkennung der Nutzer hinsichtlich des Werts von RAG-Anwendungsfällen zum wichtigsten Use Case für die Vektorsuche geworden, um neue Nutzer zu gewinnen. Schließlich müssen wir allen Open-Source-, SaaS- und Cloud-Service-Anbietern danken, von denen wir abhängig sind; ihre außergewöhnlichen Dienste haben dazu beigetragen, diese Reise zu beschleunigen.
Wir schulden den treuen Nutzern von Zilliz Cloud und Milvus besonderen Dank. Ihr sorgfältiges und geduldiges Feedback hat uns unschätzbare Ratschläge und Orientierung geboten. Ob im Bereich SaaS oder Serverless, wir sind fest davon überzeugt, dass alles, was wir getan haben, erst der Anfang ist. Das Streben nach Kosteneffizienz, Performance, Skalierbarkeit und Benutzerfreundlichkeit kennt keine Grenzen.
Danksagungen
Ich möchte unseren engagierten Nutzern von Herzen danken, deren Unterstützung maßgeblich zur Entwicklung von Zilliz Cloud beigetragen hat. Ihre Ermutigung war entscheidend dafür, unsere Reise zum Aufbau von Zilliz Cloud zu teilen und Einblicke zu bieten, die anderen zugutekommen können, die ihren Cloud-Dienst entwickeln möchten. Besondere Anerkennung gilt den über 300 Mitwirkenden der Milvus-Community für ihre unermüdliche Arbeit sowie unserem CEO Charles für seine unerschütterliche Unterstützung unserer innovativen technischen Vorhaben.
Wenn Sie daran interessiert sind, Vektorsuchdienste zu erkunden, laden wir Sie ein, sich für Zilliz Cloud zu registrieren. Neue Registranten erhalten zum Einstieg ein kostenloses Guthaben von 100 $.
Weiterlesen
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
Cosmos World Foundation Model Platform for Physical AI
NVIDIA's Cosmos platform enables safe, digital twin training of GenAI models for physical applications, overcoming data scarcity and safety challenges.