> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Conceptos centrales de Fetcher > Los objetos con los que trabaja Fetcher — conexiones, descubrimiento de esquemas, jobs de extracción, filtros y resultados firmados. El modelo de Fetcher es pequeño: registras **conexiones** a bases de datos externas, Fetcher **descubre sus esquemas**, y envías **jobs de extracción** que producen **resultados firmados y cifrados**. Esta página recorre cada pieza. ## Conexiones *** Una conexión es una referencia nombrada y almacenada a una base de datos externa — su tipo, host, puerto, nombre de la base y credenciales. Fetcher soporta cinco tipos de conexión: `POSTGRESQL`, `MYSQL`, `ORACLE`, `SQL_SERVER` y `MONGODB`. * **Las credenciales se cifran en reposo** con AES-256-GCM antes de llegar al almacenamiento; las contraseñas en texto claro nunca persisten. * **Las conexiones se pueden probar**: un endpoint dedicado abre una conexión real y reporta la latencia, para que valides una conexión antes de que cualquier job dependa de ella. * **Las conexiones en uso están protegidas**: actualizar o eliminar una conexión con jobs activos se rechaza. Además de las conexiones registradas por la API, los operadores pueden definir **datasources internos** directamente por variables de entorno (`DATASOURCE_{NAME}_*`) — útil para bases fijas, propiedad de la plataforma. Consulta [Configuración](/es/fetcher/fetcher-configuration). ## Descubrimiento de esquemas *** Fetcher detecta automáticamente tablas, columnas y tipos de datos en las bases a las que se conecta — el mismo descubrimiento funciona en los cinco tipos de base de datos. Para bases relacionales lee el catálogo, incluyendo namespaces multi-schema (schemas de PostgreSQL, owners de Oracle, schemas de SQL Server). Para MongoDB, donde las colecciones no tienen esquema declarado, Fetcher infiere uno mediante muestreo estadístico de documentos. Dos cosas se apoyan en el descubrimiento: * **Validación de esquema**: antes de ejecutar un job, puedes validar que las tablas y campos que planeas extraer realmente existen en los datasources. * **Caché de esquemas**: los esquemas descubiertos se guardan en caché (con TTL configurable), para no reintrospectar la base en cada job repetido. ## Jobs de extracción *** Un job es una solicitud asíncrona de extracción de datos. Su corazón es el mapa `mappedFields` — *qué campos, de qué tablas, de qué datasources*: ```json theme={null} { "dataRequest": { "mappedFields": { "mi_postgres": { "accounts": ["id", "email", "created_at"] }, "mi_mongo": { "transactions": ["*"] } } } } ``` * **Proyección de campos**: nombra los campos que quieres, o usa `["*"]` para todos los campos. * **Multi-todo**: un solo job puede abarcar múltiples datasources, múltiples tablas por datasource y múltiples schemas. * **Manejo de JSON**: los campos JSON/JSONB en bases relacionales se interpretan automáticamente. ### Filtros Los jobs pueden filtrar filas por tabla con un conjunto de 10 operadores: `eq`, `ne`, `gt`, `gte`, `lt`, `lte`, `between`, `in`, `nin` y `like`. ```json theme={null} { "dataRequest": { "filters": { "mi_postgres": { "transactions": { "status": { "in": ["completed", "pending"] } } } } } } ``` ### Ciclo de vida del job | Estado | Significado | | ------------ | --------------------------------------------------------- | | `pending` | Aceptado y encolado; aún no tomado por un Worker | | `processing` | Un Worker está extrayendo los datos | | `completed` | Resultados almacenados y evento de finalización publicado | | `failed` | La extracción falló; el evento de fallo fue publicado | Los jobs se **deduplican**: una solicitud idéntica dentro de una ventana de 5 minutos devuelve el job existente en lugar de crear uno nuevo. En estados terminales, el Worker publica eventos de notificación `job.completed` / `job.failed`, para que los consumidores reaccionen sin hacer polling. ## Resultados *** El Worker escribe los resultados de la extracción en object storage — SeaweedFS por defecto, o cualquier servicio compatible con S3: * **Cifrados en reposo**, con TTL de retención configurable. * **Firmados**: cada documento extraído lleva una firma HMAC-SHA256. Los consumidores pueden derivar la clave de verificación a partir de la clave maestra y comprobar la autenticidad de lo que leen — los datos provienen comprobadamente de Fetcher y no fueron alterados. ## Servicios y el Engine *** Dos formas de despliegue comparten un único núcleo: * **Servicios standalone** — el **Manager** (API HTTP, metadatos en MongoDB, despacho de jobs vía RabbitMQ) y el **Worker** (consumidor de cola, extracción, almacenamiento de resultados). Es la forma que ejecuta la [guía de primeros pasos](/es/fetcher/fetcher-getting-started). * **Engine embebido** — el núcleo de extracción (`pkg/engine`) como un módulo Go importable, con cero dependencias de terceros. Las aplicaciones anfitrionas conectan su propia infraestructura a las interfaces del Engine y ejecutan extracciones en su propio proceso. Sin un almacén de resultados, el Engine corre en *modo Direct*: los resultados vuelven inline con un digest de integridad SHA-256. La regla práctica: el Engine es dueño de *qué* significa la extracción — planificación, validación, límites, aislamiento de tenant; el host (Manager/Worker, o tu aplicación) es dueño de *cómo* se ejecuta — colas, almacenamiento, autenticación, ciclo de vida. ## Tenancy *** Fetcher corre single-tenant por defecto. En modo multi-tenant, toda operación se limita a un tenant resuelto a partir del contexto de tenant basado en JWT, y cada tenant recibe bases de metadatos, namespaces de caché y rutas de object storage aisladas. Los caminos de código multi-tenant tienen costo cero cuando el modo está deshabilitado. Consulta [Multi-tenancy](/es/multi-tenancy) para el modelo de la plataforma. ## Próximos pasos *** Ejecuta Fetcher localmente y corre tu primer job de extracción. Las variables de entorno que dan forma a un despliegue de Fetcher.