Pular para o conteúdo
NoSqlStudio
Documentação

Multi-DB Indexes

NoSqlStudio roda features grau Atlas em backends que não as implementam nativamente. $search, $vectorSearch, CSFLE, e time-series funcionam em AWS DocumentDB e Azure Cosmos DB via engines locais.

O que é

Uma tab de workspace que gerencia engines locais de search / vector / CSFLE / time-series layered sobre qualquer backend Mongo-API (Atlas, DocumentDB, Cosmos, self-hosted). Quando você mira DocumentDB ou Cosmos e precisa de $search, o engine local lida com o request e persiste estado em userData/MultiDb/, expondo os mesmos aggregation operators que o MongoDB Atlas teria.

Quando usar

Quando você é forçado a rodar em DocumentDB ou Cosmos por razões de compliance / cloud-vendor mas ainda precisa de full-text search, vector search, encriptação CSFLE, ou collections de time-series — features que esses backends não implementam nativamente. NoSqlStudio traz isso localmente sem mudar o data plane.

Como abrir

  1. No app desktop do NoSqlStudio, abra o menu Tools → Multi-DB Indexes, ou pressione Ctrl+Alt+Shift+U.
  2. O workspace lista engines configurados per connection: Search, Vector Search, CSFLE, Time-Series.
  3. Conecte a um cluster DocumentDB ou Cosmos — o detector de flavour auto-reconhece e flagga quais operators Atlas estão faltando.

Cada engine

  • Search — índice local estilo Lucene construído da sua collection. Suporta $search com text, autocomplete, fuzzy, e filters básicos. Dados do índice vivem sob userData; queries roteiam pelo engine local.
  • Vector Search — índice HNSW local. Suporta $vectorSearch com k-NN e distância cosine / euclidean. Compatível com o mesmo query shape que o Atlas espera.
  • CSFLE — Client-Side Field-Level Encryption. Keystore local + derivação de chave. Documents encriptados no driver; o backend só vê ciphertext.
  • Time-Series — wrapper local de time-series que mimica collections time-series do MongoDB 5.0+ em backends que não as implementam. Granularity, metaField, bucketing todos configuráveis.

Limitações (v1)

  • Engines rodam no processo do app desktop. Para workloads server-side (background jobs lendo o search index), você deve sair via local API ou rodar um sidecar que fala com o mesmo engine local.
  • Tamanho do índice é limitado pelo disco da sua workstation. Para datasets multi-TB, considere se o Atlas-native é o melhor caminho.
  • Re-ranking de search-result e auto-decryption de CSFLE são best-effort interleaved com o pipeline de aggregation do backend upstream. Pipelines complexos misturando $search + $lookup + $facet podem produzir diferenças de ordenação de uma run Atlas pura.