Strategische Datenbankarchitektur für KI – Einheitlich vs. Getrennt

Wichtige Erkenntnisse:

• Eine einheitliche Architektur reduziert die Komplexität der Entwicklung erheblich, da sie Synchronisationsprobleme zwischen separaten Vektor- und operativen Datenbanken beseitigt.

• Die Datenkonsistenz wird durch atomare Transaktionen in einheitlichen Systemen gewährleistet, wodurch „Geisterdokumente“ und andere Fehler aufgrund einer geteilten Architektur verhindert werden.

• Die Gesamtbetriebskosten sind bei einheitlichen Architekturen aufgrund der konsolidierten Infrastruktur und des geringeren Wartungsaufwands in der Regel niedriger.

• Die Entwicklungsgeschwindigkeit steigt durch einheitliche Ansätze, da sich die Teams auf die Entwicklung von Funktionen konzentrieren können, anstatt sich mit Integrationscode und Fehlerbehandlung zu befassen.

• MongoDB Atlas bietet Zukunftssicherheit durch integrierte KI-Funktionen wie Vektorsuche, automatische Quantisierung und vieles mehr.

KI stellt höhere Anforderungen an Datenbanken, und die architektonischen Entscheidungen, die Unternehmen heute treffen, wirken sich unmittelbar auf ihre Markteinführungszeit und ihren Wettbewerbsvorteil aus. Im Zeitalter der generativen KI muss Ihre Datenbank sowohl hochdimensionale Vektorsuchen als auch schnelle Transaktionsvorgänge unterstützen, um mit den rasanten geschäftlichen und technologischen Veränderungen Schritt zu halten.

In diesem Beitrag untersuchen wir die architektonischen Aspekte, die Technologieführer und Architekten berücksichtigen sollten, wenn sie die vielfältigen Datenanforderungen von KI-Anwendungen bewältigen – darunter hochdimensionale Vektor-Einbettungen für die semantische Suche neben herkömmlichen Betriebsdaten (Benutzerprofile, Inhaltsmetadaten usw.). Diese Dichotomie stellt zwei unterschiedliche architektonische Ansätze dar –getrennt versus einheitlich–, die jeweils erhebliche Auswirkungen auf die Anwendungsleistung, Konsistenz und Entwicklererfahrung haben.

Hinweis: Für technische Führungskräfte, die ihre Teams mit den praktischen Details ausstatten möchten – oder die stichhaltige Argumente benötigen, um skeptische Entwickler zu überzeugen –, haben wir einen umfassenden Implementierungsleitfaden veröffentlicht. Während sich dieser Artikel auf die strategischen Überlegungen konzentriert, befasst sich der Leitfaden eingehend mit den praktischen Aspekten auf Code-Ebene, die Ihr Entwicklungsteam zu schätzen wissen wird.

Warum Datenarchitektur wichtig ist

Um erfolgreiche KI-Produkte und -Funktionen zu entwickeln, muss man sich im Voraus Gedanken über die Geschwindigkeit und die Kosten von Intelligenz im großen Maßstab machen. Ganz gleich, ob Sie Semantic Search für eine Wissensdatenbank implementieren oder eine Echtzeit-Empfehlungsmaschine betreiben – Ihre Datenbankarchitektur entscheidet darüber, wie schnell und zuverlässig Sie diese Funktionen auf den Markt bringen können.

Im Zeitalter der KI hängt der Erfolg nicht mehr allein von innovativen Algorithmen ab – er wird vielmehr entscheidend von der Genauigkeit und Relevanz der Ergebnisse bestimmt. Dies stellt einen tiefgreifenden Wandel dar: Die Datenarchitektur, die einst den IT-Abteilungen vorbehalten war, ist mittlerweile zu einem strategischen Anliegen für alle geworden. Dies hat direkten Einfluss darauf, wie schnell Ihre Entwickler Innovationen umsetzen können (Entwicklungsgeschwindigkeit), wie schnell Sie neue Funktionen auf den Markt bringen können (Time-to-Market) und wie zuverlässig Ihre Systeme unter realen Bedingungen funktionieren (Betriebssicherheit).

Im Grunde genommen ist Ihre Datenarchitektur mittlerweile das Fundament, auf dem Ihre gesamte KI-Strategie entweder Erfolg hat oder scheitert. Ihre Datenarchitektur ist die Grundlage Ihrer Daten.

Im Gegensatz zu herkömmlichen Anwendungen, die sich hauptsächlich mit strukturierten Daten und einfachen CRUD-Abfragen befassten, generieren und fragen KI-Anwendungen Vektordarstellungen unstrukturierter Daten (wie Text, Bilder und Audio) ab, um „ähnliche“ Elemente zu finden. Diese Vektoren werden häufig in dedizierten Vector Databases oder Suchmaschinen gespeichert, die für die Ähnlichkeitssuche optimiert sind. Gleichzeitig benötigen Anwendungen weiterhin traditionelle Abfragen (exakte Lookups, Aggregationen, Transaktionen mit Geschäftsdaten). Dies wirft eine zentrale, grundlegende Frage zur Architektur auf:

Nutzen wir diese Gelegenheit auch, um kurz auf das Konzept einer „KI-Datenbank“ einzugehen, das entstanden ist, um ein System zu beschreiben, das sowohl standardmäßige Betriebslasten als auch KI-spezifische Vorgänge wie die Vektorsuche verarbeitet. Kurz gesagt: Hinter den KI-Suchfunktionen moderner KI-Anwendungen stehen KI-basierte Abrufverfahren, die durch für KI-Workloads optimierte Datenbanken ermöglicht werden.

Geteilte Architektur: Integration eines separaten Vektorspeichers

Bei einer geteilten Architektur werden Vektoroperationen und die Verwaltung transaktionaler Daten an separate, spezialisierte Systeme delegiert. Eine Allzweck-Datenbank (z. B. MongoDB, PostgreSQL) verwaltet Betriebsdaten, während ein spezieller Vektorspeicher (z. B. Elasticsearch, Pinecone) Embeddings und Ähnlichkeitssuchen verwaltet. Auf den ersten Blick ermöglicht dieser „Teile und herrsche“-Ansatz, dass jedes System das tut, was es am besten kann.

Die Suchmaschine oder der spezielle Vektor-Speicher kann sich auf Abfragen zur Vektorähnlichkeit spezialisieren, während die operative Datenbank für Aktualisierungen und die dauerhafte Speicherung zuständig ist. Dadurch werden spezielle Optimierungen in den einzelnen Systemen genutzt, es entstehen jedoch Anforderungen an die Synchronisation zwischen den Datenspeichern.

Viele KI-Teams haben Semantic Search und andere KI-Funktionen auf diese Weise implementiert. Dabei verwenden sie einen externen Vektorindex zusätzlich zu ihrer Anwendungsdatenbank. Beide Systeme werden durch benutzerdefinierte Middleware oder Logik auf Anwendungsebene synchron gehalten.

Merkmale einer Split-Architektur:

• Spezialisierte Systeme: Jede Datenbank ist für ihre jeweilige Aufgabe optimiert (z. B. gewährleistet die operative Datenbank schnelle Schreibvorgänge, ACID-Transaktionen und umfangreiche Abfragen; die Vektorsuchmaschine ermöglicht eine effiziente Ähnlichkeitssuche mithilfe von Indizes wie HNSW für Approximate Nearest Neighbor).

• Datenduplizierung: Vektor-Embeddings (und häufig auch einige Identifikatoren oder Metadaten) werden im Vektorspeicher doppelt gespeichert. In beiden Systemen ist die Primär-ID bzw. der Schlüssel vorhanden, um die Ergebnisse miteinander zu verknüpfen.

• Synchronisationslogik: Die Anwendung muss die Synchronisation übernehmen – bei jedem Anlegen, Aktualisieren oder Löschen eines Datensatzes muss auch der entsprechende Vektoreintrag im Suchindex aktualisiert oder gelöscht werden. Dies kann über Event Streams, Change Capture oder im Anwendungscode durch den Aufruf zweier Systeme erfolgen.

• Datenabfrage: Mehrstufige Abfragemuster, die eine systemübergreifende Koordination erfordern

Beispiel-Stack: Ein Beispiel ist die Verwendung von MongoDB als Quelle der Wahrheit für Produktdokumente und Elasticsearch als Vektorsuchmaschine für Embeddings von Produktbeschreibungen. Die App schreibt Daten in MongoDB, indiziert die Einbettung anschließend in Elasticsearch und führt bei einer Abfrage eine Vektorsuche in Elasticsearch durch, um dann das vollständige Dokument anhand der ID aus MongoDB abzurufen.

Dieses Systemmuster hören wir immer wieder von zahlreichen KI-Teams, die MongoDB einsetzen und … nun ja, so ziemlich alles andere, was verspricht, Vektoren schneller tanzen zu lassen.

Das ist das architektonische Äquivalent dazu, sowohl einen Gürtel als auch Hosenträger zu tragen – klar, die Hose rutscht nicht herunter, aber man gibt sich furchtbar viel Mühe, um ein Problem zu lösen, das eigentlich viel einfacher sein könnte. Diese Teams müssen oft mehr Synchronisationscode schreiben als eigentliche Funktionen zu entwickeln, wodurch das, was eigentlich eine KI-Innovation sein sollte, zu einem komplexen Balanceakt der Datenbankkoordination wird.

Abgesehen von allen Sicherheitsvorkehrungen ist der entscheidende Punkt, dass die Aufteilung der Architektur mit Kosten verbunden ist.

Sie verfügen nun über zwei Datenquellen, die miteinander synchronisiert bleiben müssen. Jedes Mal, wenn Sie Daten hinzufügen oder aktualisieren, müssen Sie den Vektor in der Suchmaschine indizieren. Jede Abfrage umfasst mehrere Hin- und Rückläufe – einen zum Suchdienst, um relevante Einträge zu finden, und einen weiteren zur Datenbank, um die vollständigen Details abzurufen.

Diese zusätzliche Komplexität kann die Entwicklung verlangsamen und potenzielle Fehlerquellen mit sich bringen. Der Betrieb eines geteilten Systems bringt, wie wir noch sehen werden, Herausforderungen hinsichtlich der Konsistenz mit sich (z. B. „Ghost“-Datensätze, wenn die beiden Systeme nicht mehr synchron sind) sowie zusätzliche Komplexität bei der Entwicklung und Wartung.

In Anwendungsfällen mit extrem großem Umfang oder extrem geringer Latenz (z. B. >1 Mrd. Vektoren oder <1 ms bei neuronalen Netzen) kann eine dedizierte Vektor-Engine wie FAISS oder Milvus hinsichtlich des reinen Durchsatzes bei der Ähnlichkeitssuche immer noch eine Allzweck-Datenbank übertreffen. Die Suchknoten von MongoDB Atlas isolieren jedoch Vektorsuch-Workloads auf separate, speicheroptimierte Instanzen – so können Sie die Suchleistung unabhängig von Ihren Datenbankknoten skalieren und optimieren und oft die niedrigen Latenzzeiten gewährleisten, die moderne KI-Anwendungen erfordern.

Einheitliche Architektur mit MongoDB Atlas: Eine Plattform für KI-Daten

In einer einheitlichen Architektur übernimmt eine einzige Datenbankplattform sowohl die operativen Daten als auch die Funktionen der Vektorsuche. MongoDB Atlas Vector Search integriert Vektorindizierung und -suche direkt in die MongoDB-Datenbank.

Dieses Architekturmuster vereinfacht das Datenmodell, indem Einbettungen zusammen mit den zugehörigen Daten in derselben Dokumentstruktur gespeichert werden. Das Datenbanksystem verwaltet intern die Vektorindizierung (unter Verwendung von Algorithmen wie HNSW) und bietet integrierte Abfragefunktionen, die sowohl Vektor- als auch herkömmliche Datenmuster abdecken.

In der Praxis bedeutet dies, dass Ihre Anwendung eine einzige Abfrage (an MongoDB) ausführen kann, die Daten anhand der Vektorähnlichkeit filtert und findet, ohne dass ein zweites System erforderlich ist. Das bedeutet, dass alle Daten – die Dokumente Ihrer Anwendung und deren Vektordarstellungen – an einem Ort gespeichert sind, und zwar in einem ACID-konformen Transaktionssystem für Ihre KI-Workloads.

Merkmale einer vereinheitlichten Architektur:

• Single Source of Truth: Sowohl die Rohdaten als auch die Vektorindizes befinden sich in einer einzigen Datenbank. So ermöglicht MongoDB Atlas beispielsweise das Speichern von Vektorfeldern in Dokumenten und deren Abfrage mithilfe integrierter Vektorsuchoperatoren. Es besteht keine Notwendigkeit, Daten zwischen verschiedenen Systemen zu duplizieren oder zu synchronisieren.

• Atomare Operationen: Aktualisierungen eines Dokuments und seiner Vektoreinbettung erfolgen in einer atomaren Transaktion oder einem Schreibvorgang. Dies gewährleistet starke Konsistenz – Ihr Vektorindex kann nicht von Ihren Dokumentdaten abweichen. Wenn eine Transaktion fehlschlägt, werden keine der Änderungen (weder das Dokument noch seine Einbettung) übernommen. Dies verhindert Probleme wie „Geisterdokumente“ (wir werden diesen Begriff gleich näher erläutern), da es unmöglich ist, eine Einbettung zu haben, ohne dass das entsprechende Dokument in derselben Datenbank vorhanden ist.

• Einheitliche Abfragefunktionen: Die Abfragesprache (z. B. MongoDB MQL) kann herkömmliche Filter, Volltextsuche und Vektorähnlichkeitssuche in einer Abfrage kombinieren. Mit dieser Hybridsuchfunktion können Sie beispielsweise Dokumente finden, bei denen die Kategorie „Tech“ lautet und die Einbettung einem Abfragevektor ähnelt – und das alles in einem Schritt. Sie müssen nicht zwei Abfragen in verschiedenen Systemen durchführen und die Ergebnisse anschließend in Ihrer Anwendung zusammenführen.

• Einfache Bedienung: Es gibt nur ein einziges System, das verwaltet, gesichert, skaliert und überwacht werden muss. Bei einer verwalteten Cloud-Plattform wie MongoDB Atlas erhalten Sie einen vollständig verwalteten Dienst, der sowohl operative als auch Vektor-Workloads abwickelt und häufig über Funktionen zur Optimierung der jeweiligen Workloads verfügt (beispielsweise dedizierte „Suchknoten“, die die Suchindizierung und Suchabfragen übernehmen, sodass ressourcenintensive Vektorsuchen die Leistung der transaktionalen Workloads nicht beeinträchtigen).

MongoDB Atlas integriert eine Atlas Vector Search Engine (basierend auf Apache Lucene, derselben Technologie, die auch in einigen speziellen Vektorsuchmaschinen zum Einsatz kommt) direkt in die Datenbank. Dadurch können Entwickler hochdimensionale Vektoren in Dokumenten speichern und Ähnlichkeitssuchen mithilfe von Indizes durchführen, die auf Algorithmen wie HNSW (Hierarchical Navigable Small World Graphs) basieren, um eine „Approximate Nearest Neighbor“-Suche (ANN) durchzuführen.

Zusätzliche Funktionen wie Vektorquantisierung (zur Komprimierung von Vektoren für mehr Effizienz) und Hybridsuche (Kombination von Vektor- und Textsuche) werden von Haus aus unterstützt und mit der MongoDB-Abfragesprache (MQL) erstellt.

All dies geschieht im Rahmen der Transaktions-Engine und der Sicherheitsarchitektur der MongoDB Atlas-Datenbank. Kurz gesagt zielt der einheitliche Ansatz darauf ab, das Beste aus beiden Welten zu bieten – den Funktionsumfang eines spezialisierten Vektorspeichers und die Zuverlässigkeit bzw. Konsistenz eines einzigen operativen Datenspeichers.

Eine strategische Überlegung für Entscheidungsträger

Für technische Führungskräfte, die sowohl für Innovation als auch für die Budgetverwaltung zuständig sind, bietet der einheitliche Ansatz neben seinen technischen Vorteilen auch überzeugende finanzielle Argumente.

Wenn Ihr Unternehmen MongoDB bereits als operative Datenbank einsetzt – wie Tausende von Unternehmen weltweit –, wird der Weg zur KI-Einführung erheblich vereinfacht. Anstatt Mittel für ein komplett neues Vektordatenbanksystem bereitzustellen – mit allen damit verbundenen Kosten für Lizenzen, Infrastruktur und Personal –, können Sie Ihre bestehende MongoDB-Investition erweitern, um Vektor-Workloads zu verarbeiten.

Ihre Teams sind mit der Architektur, dem Sicherheitsmodell und den Betriebseigenschaften von MongoDB bereits vertraut. Das Hinzufügen von Vektorkapazitäten ist eine schrittweise Erweiterung der Fähigkeiten und keine steile Lernkurve für ein völlig neues System. Bei laufenden Projekten kann die Migration von Vektordaten oder die Generierung neuer Einbettungen in Ihrer bestehenden MongoDB-Infrastruktur ohne Unterbrechung des laufenden Betriebs durchgeführt werden.

Technischer Überblick über die Unterschiede zwischen einer geteilten und einer einheitlichen Architektur

Um die praktischen Auswirkungen der einzelnen Architekturen zu veranschaulichen, wollen wir uns die allgemeinen Implementierungs- und Betriebsaspekte einer Wissensdatenbank-Anwendung zur Beantwortung von Fragen ansehen. Beide Ansätze ermöglichen die Vektorähnlichkeitssuche, jedoch mit bemerkenswerten Unterschieden bei der Implementierungskomplexität und den Konsistenzgarantien.

In einer geteilten Architektur (z. B. mit MongoDB + Elasticsearch): Wir speichern den Artikelinhalt und die Metadaten in MongoDB und die Embedding-Vektoren in einem Elasticsearch-Index. Zum Abfragezeitpunkt durchsuchen wir den Elasticsearch-Index nach Vektorähnlichkeit, um eine Liste der besten Artikel-IDs zu erhalten, und rufen diese Artikel dann anhand ihrer IDs aus MongoDB ab.

Es gibt verschiedene Schlüsseloperationen, die bei einer Dual-Datenbankarchitektur eine Rolle spielen:

• Erstellung: Bei der Dokumenterstellung muss die Anwendung die Einfügungen in beiden Systemen koordinieren. Zunächst wird das Dokument in MongoDB gespeichert, anschließend wird seine Vektor-Einbettung generiert und in Elasticsearch gespeichert. Sollte einer der beiden Vorgänge fehlschlagen, ist eine manuelle Rollback-Logik erforderlich, um die Konsistenz zu gewährleisten. Wenn beispielsweise das Einfügen in MongoDB erfolgreich ist, die Indizierung in Elasticsearch jedoch fehlschlägt, müssen Entwickler einen benutzerdefinierten Bereinigungscode implementieren, um das verwaiste MongoDB-Dokument zu löschen.

• Lesen: Die Vektorsuche wird in einer geteilten Architektur zu einem mehrstufigen Prozess. Die Anwendung fragt zunächst Elasticsearch ab, um ähnliche Vektoren zu finden, ruft nur die Dokument-IDs ab und führt dann einen zweiten Roundtrip zu MongoDB durch, um die vollständigen Dokumente abzurufen, die diesen IDs entsprechen. Dies führt zu zusätzlicher Netzwerklatenz und erfordert eine Fehlerbehandlung für Fälle, in denen Dokumente in einem System vorhanden sind, im anderen jedoch nicht.

• Aktualisierung: Die Aktualisierung von Inhalten stellt erhebliche Herausforderungen hinsichtlich der Synchronisation dar. Nach der Aktualisierung eines Dokuments in MongoDB muss die Anwendung auch den entsprechenden Vektor in Elasticsearch aktualisieren. Wenn die Aktualisierung von Elasticsearch fehlschlägt, nachdem die Aktualisierung von MongoDB erfolgreich war, geraten die Systeme aus dem Gleichgewicht, sodass die Vektorsuche veraltete oder falsche Ergebnisse liefert. Es gibt keine atomare Transaktion, die sich über beide Systeme erstreckt, sodass komplexe Wiederherstellungsmechanismen erforderlich sind.

• Löschung: Bei Löschvorgängen treten ähnliche Synchronisierungsprobleme auf. Wenn ein Dokument aus MongoDB gelöscht wird, die entsprechende Löschung in Elasticsearch jedoch fehlschlägt, erscheinen „Geisterdokumente“ in den Suchergebnissen – Vektoren, die auf Dokumente verweisen, die nicht mehr vorhanden sind. Benutzer erhalten Suchergebnisse, auf die sie nicht zugreifen können, was zu Verwirrung und potenziellen Sicherheitsbedenken führt, wenn vertrauliche Informationen durch in Elasticsearch gespeicherte Vorschauinhalte indirekt zugänglich bleiben.

Jeder dieser Vorgänge erfordert eine sorgfältige Fehlerbehandlung, Wiederholungsmechanismen, Überwachungssysteme und Hintergrundabgleichsprozesse, um die Konsistenz zwischen den beiden Datenbanken aufrechtzuerhalten. Bemerkenswert ist zudem, dass die Komplexität mit der Zeit zunimmt, wobei Synchronisierungsprobleme bei wachsendem Datenvolumen schwieriger zu erkennen und zu beheben sind, was sich letztendlich sowohl auf die Produktivität der Entwickler als auch auf die Benutzererfahrung auswirkt.

In einer einheitlichen Architektur (mit MongoDB Atlas Vector Search): Wir speichern sowohl die Artikeldaten als auch deren Einbettungsvektor in einem einzigen MongoDB-Dokument. Ein Atlas Vector Search Index auf dem Einbettungsfeld ermöglicht es uns, eine Ähnlichkeitssuche direkt in MongoDB mit einer einzigen Abfrage durchzuführen. Die Datenbank nutzt intern den Vektorindex, um die nächsten Nachbarn zu finden und die Dokumente zurückzugeben.

Sehen wir uns an, wie sich dieselben Operationen in einer einheitlichen Architektur erheblich vereinfachen lassen:

• Erstellung: Die Erstellung von Dokumenten wird zu einer atomaren Operation. Die Anwendung speichert sowohl das Dokument als auch seine Vektoreinbettung in einem einzigen MongoDB-Dokument mit einem einzigen Einfügevorgang. Entweder wird das gesamte Dokument (mit seiner Einbettung) erfolgreich gespeichert oder es wird gar nichts gespeichert. Es ist keine benutzerdefinierte Rollback-Logik oder Bereinigungscode erforderlich, da die Transaktionsgarantien von MongoDB die Datenintegrität ohne zusätzlichen Anwendungscode gewährleisten.

• Lesen: Die Vektorsuche wird auf einen einzigen Schritt vereinfacht. Mithilfe der Aggregationspipeline von MongoDB in Verbindung mit Atlas Vector Search sucht die Anwendung nach ähnlichen Vektoren und ruft die vollständigen Dokumente in einem einzigen Roundtrip ab. Es ist nicht erforderlich, verschiedene Systeme aufeinander abzustimmen oder Inkonsistenzen zu beheben, da die Vektorsuche direkt in die Dokumentensuche integriert ist, wodurch sowohl die Latenz als auch die Komplexität des Codes erheblich reduziert werden.

• Aktualisierung: Dokumentaktualisierungen gewährleisten eine lückenlose Konsistenz. Bei der Aktualisierung des Inhalts eines Dokuments kann die Anwendung sowohl das Dokument als auch dessen Vektoreinbettung in einem einzigen Vorgang atomar aktualisieren. Die Transaktionsgarantien von MongoDB stellen sicher, dass entweder beide aktualisiert werden oder keines von beiden, wodurch die Möglichkeit nicht synchroner Datendarstellungen ausgeschlossen wird. Entwickler müssen keine komplexen Wiederherstellungsmechanismen für Teilfehler mehr implementieren.

• Löschung: Das Problem mit den „Geisterdokumenten“ verschwindet vollständig. Wenn ein Dokument gelöscht wird, wird auch seine Vektoreinbettung automatisch entfernt, da sie im selben Dokument vorhanden ist. Es besteht keine Gefahr von verwaisten Vektoren oder inkonsistenten Suchergebnissen. Dadurch wird sichergestellt, dass die Suchergebnisse stets den aktuellen Stand der Datenbank widerspiegeln, was sowohl die Zuverlässigkeit als auch die Sicherheit erhöht.

Dieser einheitliche Ansatz beseitigt die gesamte Bandbreite an Synchronisationsproblemen, die bei geteilten Architekturen auftreten. Entwickler können sich auf die Entwicklung von Funktionen konzentrieren, anstatt sich mit Synchronisationsmechanismen, Überwachungstools und Wiederherstellungsprozessen zu befassen. Das System lässt sich nahtlos skalieren, ohne dass die Komplexität zunimmt, und gewährleistet auch bei wachsenden Datenmengen eine gleichbleibende Leistung und Zuverlässigkeit. Abgesehen von den technischen Vorteilen führt dies zu schnelleren Entwicklungszyklen, zuverlässigeren Anwendungen und letztlich zu einer besseren Benutzererfahrung für die Endnutzer, die stets präzise Suchergebnisse erhalten.

Die Vektorsuche und das Abrufen von Dokumenten erfolgen in einem einzigen Datenaustausch mit der Datenbank, was sowohl die Leistungsmerkmale als auch die einfache Handhabung von KI-gestützten Anwendungen grundlegend verändert.

Datensynchronisation: Herausforderungen und „Geisterdokumente“

Eine der größten Herausforderungen bei der geteilten Architektur ist die Datensynchronisation. Da es zwei Informationsquellen gibt (die operative Datenbank und den Vektorindex), muss jede Änderung der Daten auf beide übertragen werden. In der Praxis ist eine perfekte Synchronisation schwierig – Netzwerkfehler, Bugs oder Prozessausfälle können dazu führen, dass ein Speicher aktualisiert wird, der andere jedoch nicht. Dies kann zu Inkonsistenzen führen, die schwer zu erkennen und zu beheben sind.

Ein bekanntes Beispiel für eine geteilte Konfiguration ist das „ Geisterdokument"-Szenario. Ein Geisterdokument bezeichnet eine Situation, in der die Vektorsuche einen Verweis auf ein Dokument zurückgibt, das in der primären Datenbank nicht mehr existiert (oder nicht mehr den Kriterien entspricht).

Angenommen, ein Artikel wurde in MongoDB gelöscht oder als privat markiert, aber seine Einbettung wurde nicht aus Elasticsearch entfernt. Bei einer Vektorsuche könnte die ID dennoch als eines der ersten Ergebnisse angezeigt werden – was dazu führen würde, dass Ihre Anwendung versucht, ein Dokument abzurufen, das nicht vorhanden ist oder nicht angezeigt werden sollte. Aus Sicht des Nutzers könnte dies dazu führen, dass ein fehlerhaftes oder veraltetes Ergebnis angezeigt wird.

Kehren wir zu unserem zuvor beschriebenen Praxisszenario zurück: Stellen Sie sich ein Wissensdatenbank-System für den Kundensupport vor, in dem Artikel ständig aktualisiert und gelegentlich entfernt werden, wenn sie veraltet sind. Wenn ein Support-Mitarbeiter einen Artikel über ein nicht mehr erhältliches Produkt löscht, wird die Löschung in MongoDB erfolgreich durchgeführt, doch aufgrund eines Netzwerk-Timeouts schlägt die entsprechende Vektorlöschung in Elasticsearch fehl. Und ja, das kommt vor, insbesondere bei Anwendungen, die täglich Millionen von Anfragen verarbeiten.

Wenn später ein Kunde nach Lösungen für dieses nicht mehr erhältliche Produkt sucht, identifiziert die Vektorsuche in Elasticsearch den inzwischen gelöschten Artikel als hochrelevant und gibt dessen ID zurück. Wenn die Anwendung versucht, mit dieser ID den vollständigen Inhalt aus MongoDB abzurufen, stellt sie fest, dass das Dokument nicht mehr vorhanden ist.

Der Kunde sieht anstelle von hilfreichen Inhalten einen defekten Link oder eine Fehlermeldung, was zu einem verwirrenden und frustrierenden Erlebnis führt.

Das besonders Tückische an diesem Problem ist, dass es sich auf verschiedene Weise in der gesamten Anwendung äußern kann. Abgesehen von Problemen beim vollständigen Löschen von Dokumenten können folgende Probleme auftreten:

• Veraltete Einbettungen: Ein Dokument wird in MongoDB mit neuen Inhalten aktualisiert, aber der Vektor in Elasticsearch repräsentiert weiterhin die alte Version, was zu Suchergebnissen führt, die nicht mit dem tatsächlichen Inhalt übereinstimmen.

• Inkonsistenzen bei den Zugriffsrechten: Die Zugriffsrechte eines Dokuments ändern sich in MongoDB (z. B. von „öffentlich“ zu „privat“), doch es erscheint weiterhin in den Vektor-Suchergebnissen für Benutzer, die keinen Zugriff darauf haben sollten.

• Partielle Aktualisierungen: Es werden nur einige Felder in den Systemen aktualisiert, was zu nicht übereinstimmenden Metadaten zwischen den Angaben in der Suchvorschau und dem tatsächlichen Dokument führt.

In Produktionsumgebungen greifen Entwicklungsteams häufig auf komplexe Umgehungslösungen zurück, um diese Synchronisationsprobleme zu beheben:

1. Hintergrund-Abgleichsaufträge, die regelmäßig Belege in beiden Systemen vergleichen und Unstimmigkeiten beheben

2. Outbox-Muster, bei denen Vorgänge in einem separaten Speicher protokolliert und so lange wiederholt werden, bis sie erfolgreich sind

3. Maßgeschneiderte Überwachungssysteme, die speziell darauf ausgelegt sind, datenbankübergreifende Inkonsistenzen zu erkennen und zu melden

4. Manuelle Interventionsprozesse für Support-Teams zur Behebung von durch Nutzer gemeldeten Unstimmigkeiten

All diese Mechanismen erfordern einen erheblichen Entwicklungsaufwand, der andernfalls in die Entwicklung von Funktionen fließen könnte, die einen echten geschäftlichen Mehrwert bieten. Außerdem führen sie zusätzliche Fehlerquellen und eine höhere Komplexität im Betrieb mit sich.

Entscheidend ist, dass eine einheitliche Architektur diese ganze Klasse von Problemen vermeidet. Da es nur eine Datenbank gibt, wird ein gelöschtes Dokument automatisch aus allen zugehörigen Indizes innerhalb derselben Transaktion entfernt. Ein einheitliches Datenmodell macht es relativ unmöglich, einen Vektor ohne das dazugehörige Dokument zu haben, da beide eine Einheit bilden und im selben Dokument gespeichert sind. Dadurch entfallen Probleme wie Geisterdokumente, veraltete Vektorreferenzen oder die Notwendigkeit, zwei Datenspeicher zu synchronisieren.

Kompromisse und Überlegungen

Beim Vergleich von geteilten und einheitlichen Architekturen für KI-Daten müssen Sie mehrere wichtige Kompromisse abwägen. Wie bereits erwähnt, wirkt sich Ihre Wahl auf die Komplexität des Systems, die Leistungsmerkmale, die Skalierbarkeit, die Kosten und die Agilität der Entwicklung aus. Für KI-Projektleiter und KI-Führungskräfte in Unternehmen ist es wichtig, diese Aspekte zu verstehen. Nachfolgend sind einige aufgeführt:

Systemkomplexität vs. Datenkonsistenz: Die Aufrechterhaltung der Konsistenz in einer geteilten Konfiguration erfordert zusätzliche Logik und erhöht die Systemkomplexität. Jeder Datensatz wird faktisch zweimal verarbeitet, was zu Inkonsistenzen und komplexen Fehlermöglichkeiten führen kann. In einer einheitlichen Architektur stellen ACID-Transaktionen sicher, dass Aktualisierungen der Daten und ihres Einbettungsvektors entweder gemeinsam oder gar nicht erfolgen, was den Entwurf vereinfacht und den Aufwand für benutzerdefinierten Fehlerbehandlungscode reduziert.

Betrieblicher Aufwand vs. Leistung: Eine geteilte Architektur kann spezialisierte Engines nutzen, die für Ähnlichkeitsabfragen optimiert sind, führt jedoch zu Netzwerklatenz durch mehrere Roundtrips und erhöht den betrieblichen Aufwand, da zwei Systeme überwacht werden müssen. Einheitliche Architekturen eliminieren den zusätzlichen Netzwerk-Hop und können so die Latenz bei Abfragen verringern. MongoDB Atlas bietet Optimierungen wie Vektorquantisierung und dedizierte Suchverarbeitungsknoten, die die Leistung separater Suchmaschinen erreichen oder übertreffen können.

Skalierbarkeit vs. Kosteneffizienz: Geteilte Architekturen ermöglichen eine unabhängige Skalierung der Komponenten, gehen jedoch mit doppelten Infrastrukturkosten und Datenredundanz einher. Eine einheitliche Architektur konsolidiert Ressourcen und ermöglicht gleichzeitig die Workload-Isolierung durch Funktionen wie Atlas Search Nodes. Dies vereinfacht die Kapazitätsplanung und trägt dazu bei, eine Überdimensionierung mehrerer Systeme zu vermeiden.

Wartungsaufwand vs. Entwicklungsgeschwindigkeit: Geteilte Architekturen erfordern umfangreichen „Glue-Code“ für die Integration, doppelte Schreibvorgänge und die Synchronisation, was die Entwicklung verlangsamt und Schemaänderungen erschwert. Dank einheitlicher Architekturen können sich Entwickler auf die Anwendungslogik konzentrieren, da es weniger Komponenten gibt und eine einzige Abfragesprache verwendet wird, was möglicherweise die Markteinführungszeit für KI-Funktionen verkürzt.

Zukunftssicherheit: Einfachere, einheitliche Architekturen erleichtern und beschleunigen die Einführung neuer Funktionen bei der Weiterentwicklung der KI-Technologie. Bei getrennten Systemen häufen sich mit jedem Komponenten-Upgrade technische Schulden an, während einheitliche Plattformen neue Funktionen transparent integrieren können, ohne Integrationspunkte neu gestalten zu müssen.

Zwar entscheiden sich manche Unternehmen aufgrund von Altsystemen oder speziellen Anforderungen zunächst für einen geteilten Ansatz, doch die einheitliche Architektur von MongoDB mit Atlas Vector Search beseitigt nun viele der bisherigen Gründe für separate Suchmaschinen und bietet hybride Suchfunktionen, Genauigkeitsoptionen und Optimierungstools innerhalb einer einzigen Datenbankumgebung.

Die Auswahl der richtigen Architektur für KI-Workloads

Wann sollten Sie sich für eine Split-Architektur entscheiden und wann ist eine einheitliche Architektur sinnvoller? Die Antwort hängt letztendlich von Ihren spezifischen Anforderungen und Einschränkungen ab.

Ziehen Sie eine geteilte Architektur in Betracht, wenn Sie bereits über eine umfangreiche Infrastruktur verfügen, die auf einer spezialisierten Such- oder Vektordatenbank basiert und Ihren Anforderungen entspricht. In manchen Fällen können extrem umfangreiche Suchanwendungen auf einer separaten Suchmaschine detailliert optimiert werden, oder gesetzliche Vorschriften können separate Datenspeicher vorschreiben.

Ein geteilter Ansatz kann auch dann sinnvoll sein, wenn eine Art von Workload die andere bei weitem übertrifft (z. B. wenn Sie Vektorsuchen über Milliarden von Elementen durchführen, aber relativ wenige Transaktionsvorgänge haben – obwohl selbst in diesem Fall eine einheitliche Lösung mit der richtigen Indizierung überraschend große Datenmengen bewältigen kann).

Seien Sie einfach darauf vorbereitet, in die Werkzeuge und den Entwicklungsaufwand zu investieren, um die beiden Systeme aufeinander abzustimmen. Wenn Sie sich für diesen Ansatz entscheiden, sollten Sie Ihre Synchronisierungsprozesse sorgfältig konzipieren und den Einsatz von Change-Streams oder Event-Bussen in Betracht ziehen, um Änderungen zuverlässig weiterzugeben. Berücksichtigen Sie außerdem die Betriebskosten: Die Aufrechterhaltung des Fachwissens für zwei Plattformen und deren Integration ist kein Kinderspiel.

Ziehen Sie eine einheitliche Architektur in Betracht, wenn Sie eine neue KI-gestützte Anwendung entwickeln oder eine bestehende modernisieren und dabei Wert auf Einfachheit, Konsistenz und schnelle Entwicklung legen. Wenn die Vermeidung der Fallstricke bei der Datensynchronisierung und die Reduzierung der betrieblichen Komplexität Priorität haben, ist der einheitliche Ansatz eine gute Wahl.

Eine einheitliche Plattform spielt ihre Stärken besonders dann aus, wenn Ihre Anwendung eine enge Verzahnung von Betriebs- und Vektordaten erfordert – beispielsweise bei der Durchführung einer semantischen Suche mit Laufzeitfiltern für Metadaten oder bei der Aktualisierung von Inhalten, die sich sofort in den Suchergebnissen widerspiegeln.

Mit einer Lösung wie der modernen Datenplattform von MongoDB erhalten Sie eine vollständig verwaltete, cloudfähige Datenbank, die sowohl die Anforderungen Ihrer Online-Anwendungen als auch die Anforderungen der KI-Suche aus einer Hand abdeckt. Dies führt zu schnelleren Entwicklungszyklen (da Ihr Team mit einem einzigen System und einer einzigen Abfragesprache arbeiten kann) und zu größerer Sicherheit, dass Ihre Suchergebnisse zu jedem Zeitpunkt den tatsächlichen Zustand Ihrer Daten widerspiegeln.

Mit Blick auf die Zukunft ist eine einheitliche Architektur wohl der zukunftssicherere Ansatz. Da sich die KI-Fähigkeiten immer schneller weiterentwickeln, können Sie neue Funktionen sofort nutzen, wenn Ihre Daten an einem Ort gespeichert sind.

Wir arbeiten mit KI-Kunden zusammen, die komplexe KI-Anwendungen entwickeln, und eine wichtige Erkenntnis dabei ist die Notwendigkeit, die Datenverarbeitungsprozesse innerhalb von KI-Anwendungen zu optimieren, die RAG-Pipelines oder agentische KI nutzen. Zu den entscheidenden Vorgängen zählen die Chunking-Verarbeitung, die Erzeugung von Embeddings, die Vektorsuche und das Reranking.

Außerdem haben wir die hochmodernen Embedding-Modelle und Reranker von Voyage AI in MongoDB integriert. In Kürze werden diese Modelle in MongoDB Atlas integriert sein und die Umwandlung von Datenobjekten in Embeddings ermöglichen sowie eine zusätzliche Ebene der Datenverwaltung in den Abruf-Pipelines gewährleisten – all dies wird innerhalb von MongoDB Atlas erfolgen. Dieser Schritt ist einer der wichtigsten Wege, auf denen MongoDB die Datenebene weiterhin mit Intelligenz ausstattet und eine wirklich intelligente Datengrundlage für KI-Anwendungen schafft.

Die Atlas-Plattform von MongoDB erweitert kontinuierlich ihre KI-orientierten Funktionen – von Verbesserungen bei der Vektorsuche bis hin zur Integration mit Datenströmen und Echtzeitanalysen –, wobei gleichzeitig sichergestellt wird, dass die grundlegenden Datenbankgarantien (wie ACID-Transaktionen und Hochverfügbarkeit) weiterhin gewährleistet sind. Das bedeutet, dass Sie Ihre Datenschicht nicht neu gestalten müssen, um den nächsten großen Fortschritt im Bereich der KI zu nutzen; Ihre bestehende Plattform wird so erweitert, dass sie diesen unterstützt.

Verständlicherweise ist die Debatte um getrennte versus einheitliche Architektur ein klassisches Beispiel für das Abwägen zwischen Spezialisierung und Einfachheit. Geteilte Systeme bieten zwar für jede Aufgabe die besten Komponenten ihrer Art, allerdings auf Kosten einer höheren Komplexität und möglicher Inkonsistenzen. Einheitliche Systeme zeichnen sich durch Eleganz und Benutzerfreundlichkeit aus, bündeln Funktionen an einem Ort und haben den Rückstand in Bezug auf Funktionen und Leistung rasch aufgeholt.

Lassen Sie uns mit folgendem Gedanken schließen: MongoDB wurde für den Wandel entwickelt, und genau diese Philosophie ist es, die Unternehmen brauchen, um die KI-Revolution zu meistern. Durch die Konsolidierung Ihrer Dateninfrastruktur und den Einsatz von Technologien, die Funktionen bündeln, geben Sie Ihren Teams die Freiheit zum Experimentieren und das Selbstvertrauen zur Umsetzung. Die Zukunft wird denen gehören, die KI und Daten nahtlos miteinander verbinden können. Es ist an der Zeit, Ihre eigene Architektur zu überprüfen und sicherzustellen, dass sie es Ihnen ermöglicht, auf der Welle der KI-Innovation mitzureiten und nicht von ihr hinweggespült zu werden.