Análise aprofundada · Cerca de 7 min de leitura
Como a OpenAI redesenhou o Habitat: capacidade compartilhada, caches regionais e leitura 12× mais rápida com ressalvas
A OpenAI detalha a ocupação do Cosmos DB, invalidação por CDC e Rust; a queda da mediana combina várias mudanças.
- Publicado aqui
- Data da fonte
- Fonte verificada
Em um artigo de engenharia de 23 de outubro, a OpenAI explica mudanças no armazenamento Azure Cosmos DB e no caminho de leitura do Habitat. O relato apresenta escolhas operacionais e medições da empresa, não um novo modelo ou serviço público de armazenamento.
Ouça as notícias
Ouça este artigo ou continue ouvindo as notícias.
Preparando a leitura…
Voz do dispositivo
O navegador ou dispositivo processa a voz. O AISubHub não envia o texto a uma API de áudio. As vozes e a reprodução com a tela bloqueada variam conforme o dispositivo.
Ao continuar, uma frase curta pode se repetir.
Resumo
- A OpenAI atribui a redução do p50 global de leitura de cerca de 120 ms para 10 ms à localização dos dados, caches regionais e reescrita em Rust; leituras lentas sem cache ainda acessam armazenamento distante.
- O Habitat passou de contêineres compartilhados para isolados e voltou ao compartilhamento padrão após trabalho conjunto com a Azure. Outro sistema em escala de exabytes continua em desenvolvimento.
Por que o compartilhamento limitava funções diferentes
A OpenAI descreve o Habitat como uma camada com mais de 500 petabytes, atendendo produtos com mais de 1 bilhão de usuários em 40 regiões geográficas. São números do autor, não contagem independente nem novos usuários anunciados agora. O problema é reunir capacidade sem permitir que uma função prejudique outra. Inicialmente, cada conta Cosmos DB tinha um contêiner padrão e os clientes escolhiam suas chaves de partição lógica. Identificadores comuns podiam levar usos distintos a dividir os limites da mesma chave.
RU/s mede unidades de requisição por segundo, não uma quantidade fixa de consultas. O desenho inicial confiava no limite declarado de 10.000 RU/s por chave lógica para gerar contrapressão, mas a aplicação dos limites ocorre nas partições físicas compartilhadas. Chaves sem relação podem disputar recursos. Se o armazenamento cresce e uma partição se divide sem aumento da vazão total do contêiner, cada filha recebe menos capacidade. Assim, objetos volumosos podem provocar restrições mesmo com taxa de requisições estável. Os diagramas explicam mecanismos; suas proporções não são medições de produção.
O isolamento reduziu o impacto e aumentou o planejamento
Contêineres dedicados deram a serviços críticos partições físicas distintas e reduziram o alcance dos vizinhos ruidosos. A equipe também ajustou a vazão provisionada ao número de partições para corrigir partições fracas. Em troca, cada serviço passou a planejar capacidade. Uma passagem de testes internos para tráfego público poderia saturar um contêiner pequeno, enquanto o mesmo aumento pouco afetaria um grande conjunto compartilhado. O isolamento mudou as fronteiras de falha, mas não eliminou a necessidade de prever demanda antes de lançar.
O Habitat voltou a compartilhar por padrão com limitação de chaves quentes, prioridade menor para tarefas em massa e uma variante serverless criada com a Azure. O artigo contrapõe o teto anterior de 5.000 RU/s por partição física a um modo adaptado de até 10.000 RU/s, com divisões por uso de RU e por armazenamento. Trata-se de colaboração específica, não prova de que todos os clientes possam ativar a mesma configuração. Nossa análise: compartilhar volta a ser confiável quando o controle protege requisições interativas e a capacidade acompanha a demanda.
Por que o serviço gerenciado precisou testar falhas em conjunto
A OpenAI diz que sua maior conta Cosmos DB armazena dezenas de petabytes e atende mais de 20 milhões de consultas por segundo. Uma falta de energia no fim de 2024 e um incidente no retorno cerca de um mês depois expuseram pressupostos nessa escala: após falta de energia, as maiores contas levariam horas para mudar para uma região secundária; cerca de um mês depois, o retorno causou uma avalanche de conexões e sobrecarregou o gateway original. Os clientes voltaram antes de todas as partições relevantes retornarem. São dois incidentes em etapas diferentes, não uma interrupção contínua.
A resposta foi além de comprar capacidade. Habitat e Azure monitoram camadas em conjunto, testam em uma conta fora de produção com tamanho comparável, iteram sobre SDK e mantêm escalonamento direto entre engenheiros. O relato também cita cache de metadados do gateway, proteção de carga, reutilização de conexões e separação entre trabalho crítico e offline. Inferimos que outras equipes devem testar tanto a transferência quanto o retorno em escala representativa. O provedor gerenciar o banco não valida automaticamente conexões do cliente, tempo de recuperação ou alcance aceitável de falha.
O que entra na melhora de leitura de 12×
Segundo a OpenAI, mais de 90% das requisições do Habitat são leituras. A estratégia aproxima dados quando a capacidade permite, replica amplamente poucos conjuntos pequenos sensíveis à latência e usa caches Valkey próximos para outros objetos e relações frequentes. Algumas contas críticas replicam nas 40 regiões Azure atendidas; isso não significa que todos os dados estejam em todas as regiões. Armazenamento e computação disputam energia, refrigeração e espaço. A localização permanece uma escolha de produto e capacidade, sem garantia ilimitada de proximidade.
A invalidação usa o fluxo de mudanças do Cosmos DB: consumidores CDC invalidam cópias locais após atualizações e a próxima leitura repõe o conteúdo. A OpenAI relata propagação global em segundos, sem depender só da expiração TTL; isso não é consistência instantânea. A reescrita em Rust também reduziu sobrecarga. Juntas, as mudanças levaram o p50 global de aproximadamente 120 ms a 10 ms. O gráfico distingue replicação próxima, cache na região e Rust. O ganho de 12× não pode ser atribuído só ao Rust, estendido às escritas ou ao tempo total de resposta do ChatGPT para cada usuário.
CDC em escala e a fronteira entre operação e desenvolvimento
CDC também alimenta índices secundários, movimentação e análise. A OpenAI informa milhões de mudanças por segundo em milhares de contêineres e milhões de partições, por mais de cem tópicos Kafka. Um plano de controle distribui regiões e trabalhadores; leitura em réplicas e baixa prioridade protegem tráfego interativo. Isolamento de fluxos, gestão de leases, filas de mensagens com falha e mudança de leitores após falhas regionais tratam problemas distintos. Separar entregas permanentemente falhas evita bloquear o fluxo, mas não prova que todos os consumidores estejam atualizados.
Os limites continuam relevantes: faltas lentas de cache acessam armazenamento remoto, e o artigo não traz comparação controlada separando cada otimização nem garantia universal de latência de cauda. A OpenAI desenvolve um sistema exabyte usando o núcleo RocksDB Cloud da Rockset, replicação Raft e modelo documental compatível com Cosmos. Armazenamento desagregado e replicação física buscam reduzir flash em troca de menor QPS de pico. Continua em desenvolvimento, sem substituir Cosmos. Lemos esta segunda parte e seu gráfico, sem verificar independentemente a primeira, código SDK ou garantias de serviço dos links.
Por que importa
Equipes podem comparar isolamento, folga agregada de capacidade e responsabilidade operacional. Atualidade do cache, recuperação e latência de cauda precisam de critérios próprios.
Limites e disponibilidade
São afirmações da OpenAI, sem reprodução da AISubHub ou garantia da Azure. O artigo não demonstra acesso universal ao modo serverless personalizado, benefícios de assinatura ou ganho de latência de toda a aplicação.
Fontes e evidências
Data da fonte: · Fonte verificada:
Conteúdo editorial com apoio de IA, verificado em fontes primárias. Alegações dos fornecedores são atribuídas; inclusão não é recomendação.