Panorama de Controladores de Base de Datos

En esta página encontrarás una visión general de todos los controladores que Gigantics admite actualmente para los procesos de anonimización de datos.

Controladores soportados

Gigantics puede actuar tanto como origen (tap) como destino (sink) usando los siguientes sistemas:

Bases de datos relacionales

MySQL – Conexión a servidores MySQL
PostgreSQL – Conexión a servidores PostgreSQL
Oracle – Conexión a Oracle, incluido soporte Multitenant
Microsoft SQL Server – Conexión a servidores MSSQL
DB2 for z/OS – Conexión a bases IBM DB2 en mainframe z/OS
DB2 for i (AS/400) – Conexión a IBM DB2 for i (AS/400)
DB2x – Variante DB2 for i que usa SFTP para operaciones de escritura
SQLite – Conexión a ficheros locales SQLite

Bases de datos No-SQL

MongoDB – Conexión a bases de documentos MongoDB
Redis – Conexión a almacenes clave-valor Redis; las claves se agrupan en entidades según su prefijo

Plataformas cloud

Salesforce – Conexión a Salesforce CRM con autenticación JWT OAuth y Bulk API 2.0
Databricks – Conexión a SQL Warehouses y clústeres de Databricks (catálogos y esquemas de Unity Catalog) con un token de acceso personal

Sistemas basados en ficheros

File Storage – Lectura y escritura de ficheros CSV, JSON, YAML, XML, Excel, Parquet y EDI en el disco local, por SSH/SFTP, en Google Drive o en SharePoint
CSV – Lectura y escritura de archivos CSV en un directorio especificado. Ya no se ofrece al crear un tap o un sink: usa File Storage

Métodos de conexión

Conexión directa – TCP/IP estándar con autenticación clásica.
Acceso basado en ficheros – SQLite, CSV y File Storage trabajan con ficheros. File Storage también accede a ficheros por SFTP, en Google Drive y en SharePoint.
Túnel SSH – La mayoría de controladores permite crear un túnel para conexiones seguras a través de bastion hosts.
Enfoques especializados – DB2x emplea plantillas de shell y SFTP para la carga de datos.

Opciones de autenticación

Usuario/Contraseña – Método tradicional.
Autenticación integrada (Windows) – Para MSSQL.
Gestores de contraseñas – Integración con gestores externos.
Tokens de acceso – Para Databricks (token de acceso personal en el campo Contraseña).
Sin autenticación – Sistemas basados en ficheros como SQLite, CSV y File Storage.

Reintentos de escritura (Retry On Fail)

Todos los controladores escriben los datos en lotes. Si Reintentar al fallar está activado y un lote falla, el controlador no se detiene enseguida: divide el lote por la mitad y vuelve a escribir cada mitad, primero la izquierda y después la derecha. Las mitades que fallan se vuelven a dividir, hasta que el lote se escribe o falla un único registro.

falla un lote de 8 registros
        │
        ├── registros 1-4 ── ok, escritos
        └── registros 5-8 ── fallan
               ├── registros 5-6 ── ok, escritos
               └── registros 7-8 ── fallan
                      ├── registro 7 ── ok, escrito
                      └── registro 8 ── falla: el error se informa con este registro

Los registros escritos antes del error se cuentan, y el mensaje de error indica cuántos registros del lote se confirmaron: Error <acción> <tamaño del lote> into <entidad> after committing <n> record(s): <error> (por ejemplo Error inserting 8 into customers after committing 7 record(s): ...)
El registro que falla se informa junto con el error. Lo que pasa después depende de Continuar reportando después de fallar (Continue Streaming On Fail)
Todos los errores de escritura se reintentan así, sin espera entre intentos. No reintenta conexiones ni lecturas
Reintentar al fallar (Retry On Fail) está desactivado por defecto. Está junto a Concurrencia y Continuar reportando después de fallar en las Opciones por defecto de la regla, en los paneles de ejecutar regla y lanzar job, en las Opciones de concurrencia del pipeline y en los paneles de cargar dataset, copiar dataset y cargar sink
Se aplica a los controladores PostgreSQL, MySQL, Microsoft SQL Server, Oracle, Salesforce y Databricks. El resto de controladores lo ignora

Implementación técnica

Cada controlador se implementa como una clase Node.js que cumple una interfaz común e incluye lógica específica para:

Gestión de conexiones
Extracción de esquema
Obtención de metadatos
Lectura de datos
Escritura de datos

Consulta la página de cada controlador para detalles de parámetros, autenticación y notas técnicas.

Dependencias de controladores

Para conocer las bibliotecas Node.js que utiliza cada controlador, visita el documento de Dependencias.

Tabla de Contenidos