Ir al contenido
NoSqlStudio
Documentación

Multi-DB Indexes

NoSqlStudio corre features grado Atlas en backends que no las implementan nativamente. $search, $vectorSearch, CSFLE, y time-series funcionan en AWS DocumentDB y Azure Cosmos DB vía engines locales.

Qué es

Un tab de workspace que gestiona engines locales de search / vector / CSFLE / time-series layered sobre cualquier backend Mongo-API (Atlas, DocumentDB, Cosmos, self-hosted). Cuando apunta a DocumentDB o Cosmos y necesita $search, el engine local maneja el request y persiste estado bajo userData/MultiDb/, exponiendo los mismos aggregation operators que MongoDB Atlas tendría.

Cuándo usar

Cuando es forzado a correr en DocumentDB o Cosmos por razones de compliance / cloud-vendor pero todavía necesita full-text search, vector search, encriptación CSFLE, o collections de time-series — features que esos backends no implementan nativamente. NoSqlStudio trae esto localmente sin cambiar el data plane.

Cómo abrirlo

  1. En el app desktop del NoSqlStudio, abra el menú Tools → Multi-DB Indexes, o presione Ctrl+Alt+Shift+U.
  2. El workspace lista engines configurados per connection: Search, Vector Search, CSFLE, Time-Series.
  3. Conéctese a un cluster DocumentDB o Cosmos — el detector de flavour auto-reconoce y flagga cuáles operators Atlas están faltando.

Cada engine

  • Search — índice local estilo Lucene construido de su collection. Soporta $search con text, autocomplete, fuzzy, y filters básicos. Datos del índice viven bajo userData; queries rutean por el engine local.
  • Vector Search — índice HNSW local. Soporta $vectorSearch con k-NN y distancia cosine / euclidean. Compatible con el mismo query shape que Atlas espera.
  • CSFLE — Client-Side Field-Level Encryption. Keystore local + derivación de clave. Documents encriptados en el driver; el backend solo ve ciphertext.
  • Time-Series — wrapper local de time-series que mimica collections time-series del MongoDB 5.0+ en backends que no las implementan. Granularity, metaField, bucketing todos configurables.

Limitaciones (v1)

  • Engines corren en el proceso del app desktop. Para workloads server-side (background jobs leyendo el search index), debe salir vía local API o correr un sidecar que habla con el mismo engine local.
  • Tamaño del índice es limitado por el disco de su workstation. Para datasets multi-TB, considere si el Atlas-native es el mejor camino.
  • Re-ranking de search-result y auto-decryption de CSFLE son best-effort interleaved con el pipeline de aggregation del backend upstream. Pipelines complejos mezclando $search + $lookup + $facet pueden producir diferencias de ordenamiento de una run Atlas pura.