KI SpotlightNewsOpenAI beschreibt Azure Cosmos DB als Speicherbasis von Habitat
Teil II der Habitat-Serie behandelt die Datenbank hinter allen OpenAI-Produkten. Die Größenangaben stammen von OpenAI; technische Details fehlen im vorliegenden Material.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Jon Lee, Hrachya Hakobyan und Chaomin Yu behandeln die Optimierung von Azure Cosmos DB in Habitat.
- Habitat liefert allen OpenAI-Produkten den Datenzugriff.
- Laut OpenAI muss Habitat in Millisekunden auf über 1 Milliarde Nutzer in 40 Regionen antworten.
- Habitat bedient über 500 Petabyte an Daten in einer global verteilten Storage-Plattform.
- Laut Teil I verarbeitet Habitat über 70 Millionen Anfragen pro Sekunde.
OpenAI legt Cosmos DB als Fundament von Habitat offen
In Teil II seiner Habitat-Serie erläutert OpenAI, wie das Unternehmen Azure Cosmos DB in der Application-Storage-Plattform Habitat optimiert hat. Verfasst haben den Beitrag Jon Lee, Hrachya Hakobyan und Chaomin Yu, alle drei Members of Technical Staff bei OpenAI. Nach eigener Darstellung entstand er in enger Zusammenarbeit mit dem Azure-Team.
Habitat stellt allen OpenAI-Produkten den Datenzugriff bereit. Die Plattform muss laut OpenAI Anfragen in Millisekunden beantworten, über 1 Milliarde Nutzer in 40 geografischen Regionen bedienen und mehr als 500 Petabyte an Daten verwalten. Einen Zeitraum für die Nutzerzahl nennt Teil II nicht.
Der Beitrag gibt eine Reihenfolge vor. Die Plattform soll zuerst zuverlässig genug für geschäftskritischen Produktverkehr werden, danach schnell genug für globale Nutzer und zuletzt im Massenmaßstab betreibbar sein. Alle Größenangaben sind Herstellerangaben.
Vom Python-Client zur globalen Storage-Plattform
Teil I zeichnete Habitats Weg vom Python-Client zum Dienst nach. Zur DevDay 2023 startete Habitat für GPTs als einfache Client-Bibliothek, die auf eine einzelne Datenbank zugriff. Laut Teil I verarbeitet die Plattform inzwischen mehr als 70 Millionen Anfragen pro Sekunde für Produkte mit über 1 Milliarde Nutzern pro Woche in fast 40 Regionen.
Dass Teil II von 40 statt von fast 40 Regionen spricht, lässt sich auf Rundung oder den zeitlichen Abstand der Beiträge zurückführen. Das Material klärt es nicht.
Zu den betrieblichen Erkenntnissen zählt Teil I unter anderem Folgendes. Das minütliche Parsen der Statsig-Feature-Flag-JSON erfolgte ohne Jitter. Bei bis zu 8 Python-Prozessen pro Pod führte das zu Latenzspitzen. Hinzu kamen metastabile Fehlerzustände: Verbindungslecks konnten NAT-Gateways sättigen.
Was der Einstieg in Teil II noch offenlässt
Belegen lässt sich aus dem ausgewerteten Material nur die Einleitung von Teil II. Zu Partitionierung, Replikation, Konsistenzmodell, Latenz- und Durchsatzwerten sowie zu den Gründen für Migrationen liegen keine gesicherten Angaben vor.
Die Formulierungen „unprecedented“ für das Wachstum und „extraordinary challenge“ für die Aufgabe sind Selbstauskünfte von OpenAI. Unabhängige Vergleichsdaten fehlen. Für Betreiber großer verteilter Systeme ist der Beitrag als Erfahrungsbericht lesenswert. Wer konkret davon profitiert, geht aus dem Material nicht hervor.
