Por Isocler Teixeira
Nos últimos anos, quase toda empresa criou algum tipo de data lake ou repositório central de arquivos: logs, documentos, imagens, PDFs, mídias de sistemas legados, dumps de banco de dados, telemetria de sensores em S3 ou Blob Storage … porque guardar tornou-se barato.
O problema é que, na prática, muitos desses data lakes viraram verdadeiros pântanos de dados. Quando alguém precisa encontrar algo específico, o cenário costuma ser caótico.
O dado até está armazenado em algum lugar, mas a experiência de encontrar o que importa é lenta, técnica demais e cara de operacionalizar. Times de dados precisam montar ETLs, sincronizar índices de busca, cuidar de pipelines, pensar no permissionamento, custos transferência de dados, e assim por diante.
É aqui que o MongoDB Atlas se destaca ao unir 3 capacidades. Cada uma com um papel especifico:
- Online Archive – reduz custo do “dado quente” movendo histórico para armazenamento gerenciado pelo Atlas, prevalecendo uma consulta unificada.
- Atlas Data Federation – consulta no local por dados que não estão no cluster do Mongo usando MQL ( Mongo Query ).
- Atlas Search + Vector Search – busca por texto (fuzzy, sinônimos, filtros) e por similaridade semântica (usando embeddings) com indexação moderna e de experiências tipo RAG.
Fique por dentro das últimas notícias
Mas se eu já tenho S3/Blob, por que usar OA?
Vejamos um caso genérico e depois às decisões. Uma plataforma digital com 3 “conjuntos” de dados:
- Transacional/operacional (usuários, pedidos, tickets, catálogos) que precisam de baixa latência para leitura/escrita.
- Arquivos e históricos volumosos (PDFs, imagens, logs, telemetria de sensores) mas com acesso menos frequente.
- Busca e descoberta com acesso rápido e com precisão por palavras, contexto semântico, e por similaridade.
Hoje, boa parte disso já está em S3/Blob (armazenamento mais barato). O problema é a experiência de busca e simplicidade operacional. Qual o impacto de montar ETL, sincronizar o lake com alguns sistemas, manter índices de busca atualizados, evitar custos desnecessários e manter segurança/compliance ?
Uma arquitetura de referência seria:
- Coleções “com dados quentes” no Mongo Atlas para dados operacionais e um índice leve de descoberta por metadados, trechos/resumos.
- Mongo Online Archive (OA) para mover histórico menos acessado das coleções “quentes” para um storage gerenciado.
- Mongo Data Federation para consultar no local por dados que permanecem no S3/Blob da empresa e eventualmente, se queira combinar com dados do Atlas OA.
- Atlas Search + Vector Search para pesquisar as coleções quentes para oferecer relevância por similaridade.
- Quando o usuário clicar num resultado, o serviço irá hidratar o conteúdo completo do OA ou do S3/Blob via Data Federation.
Por que esta arquitetura?
Porque Text + Vector Search rodam sobre o dado quente (no cluster Mongo) já indexado. O conteúdo mais antigo fica barato e de fácil acesso via OA/DF. E o usuário tem a experiencia de uma busca rápida (no índice leve) e acesso sob demanda ao original.
Onde o Online Archive faz diferença
- Automação do ciclo de vida do documento: regras por data ou filtro movem documentos do cluster para o OA sem que você precise orquestrar pipelines e políticas de acesso em um bucket próprio.
- Consulta unificada: a aplicação continua consultando a mesma coleção, mas o Mongo Atlas direciona parte da leitura ao Archive quando necessário. É como se você pedisse em uma biblioteca por um livro em que os livros de 1990 – 2005 estão no depósito enquanto os exemplares de 2006 até 2025 estivessem na estante. O pedido é o mesmo, mas a busca será transparente para o usuário.
- Simplicidade operacional: você não gerencia container, políticas ou chaves no bucket. O custo vem consolidado no Atlas, e dá para limitar consumo em consultas ao histórico.
Quando usar OA:
- Seu dado começa no Mongo Atlas (operacional) mas envelhece.
- Você quer diminuir custo do “dado quente” sem reescrever a aplicação.
- Precisa manter acesso eventual ao histórico.
- Prefere menos componentes para operar (e um único lugar para observar custos, métricas e segurança do acesso).
Onde o Data Federation é imbatível:
- Consultas no local: você já tem S3/Blob e não quer mover nada.
- Combinar fontes: ler numa mesma consulta coleções do Atlas + arquivos em S3/Blob + OA.
- Governança detalhada: quando sua estratégia exige chave de gerenciamento (Key Vault) , camadas Hot/Cool/Archive, ciclo de vida do documento, RBAC do storage.
Quando usar DF (com S3/Blob próprio):
- O dado nasce ou permanece fora do Atlas, e você quer fazer query sem necessidade de ingestão de dados.
- Quer evitar duplicação entre o lake e o cluster e ao mesmo tempo, quer oferecer “visão única” ao usuário.
Custos e Governança
Quando pensamos em FinOps e governança, a primeira pergunta é geográfica: onde esses dados vão ficar? Em muitos casos, manter Atlas/OA e o storage de nuvem na mesma região, além da mesma cloud ajuda a reduzir latência, evitar surpresas de custo de rede e simplificar o desenho da arquitetura.
Depois, pensamos em modelo de custos, ou seja com o Online Archive, você concentra tudo numa fatura do Atlas (armazenamento + consultas, com direito a configurar limites e alertas). Já quando combina Data Federation com S3/Blob, o armazenamento entra na fatura do seu provedor de nuvem, enquanto o processamento das consultas aparece no Atlas. É o clássico “pagar tudo num lugar só” ou “separar infraestrutura e processamento”.
Do lado de segurança e compliance, a escolha também muda de cor. Se o seu time jurídico ou compliance exige controle de chaves gerenciadas, uma definição detalhada do que é ‘Hot/Cool/Archive’ para o ciclo de vida dos documento, e políticas de retenção por objeto, normalmente faz mais sentido usar seu próprio S3/Blob em conjunto com Data Federation, porque você aproveita todos os recursos nativos da cloud.
Agora, se a prioridade é simplificar a arquitetura, reduzir o número de componentes e ter uma governança de acesso mais centralizada dentro do ecossistema MongoDB, o Online Archive tende a ser mais direto e prático: menos peças para gerenciar, tudo integrado ao restante do Atlas e uma experiência mais simples para o time de dados.
Em resumo, você não precisa escolher entre “guardar barato” e “buscar com inteligência”. O MongoDB Atlas permite que o dado quente seja rápido e indexável (Text/Vector), enquanto o histórico fica barato e acessível via OA ou no local com Data Federation. Com isso, dá para reduzir custo, simplificar operações e elevar a experiência de busca sem reescrever tudo. Pense na seguinte analogia em termos de Azure Archive: funciona como um “arquivo morto” (por isso quando alguém requer uma busca, é necessário reidratar o documento e isto tem um SLA e custo) enquanto o OA é visto como “arquivo frio porém vivo”.
