Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Guía paso a paso para migrar datos relacionales SQL a MongoDB

Aprenda cómo migrar sus datos relacionales SQL a MongoDB con esta guía completa paso a paso. Descubra las mejores prácticas para transformar esquemas tradicionales en estructuras de documentos MongoDB eficientes, incluyendo planificación esencial, estrategias de diseño de esquemas como la incrustación y la referenciación, técnicas de extracción y transformación de datos, y carga en MongoDB. Este tutorial proporciona ejemplos prácticos y consejos accionables para una transición fluida y exitosa a una base de datos NoSQL.

35 vistas

Guía paso a paso para migrar datos relacionales SQL a MongoDB

Migrar de una base de datos relacional como SQL a una base de datos de documentos NoSQL como MongoDB es una tarea común pero a menudo compleja. Las bases de datos relacionales sobresalen en la aplicación de la integridad de los datos a través de tablas estructuradas, claves foráneas y transacciones ACID. MongoDB, por otro lado, ofrece flexibilidad, escalabilidad y beneficios de rendimiento para ciertas cargas de trabajo al utilizar un modelo de datos orientado a documentos. Esta guía proporciona un enfoque práctico, paso a paso, para transformar esquemas relacionales tradicionales en estructuras de documentos MongoDB eficientes, cubriendo consideraciones esenciales de diseño de esquemas y herramientas para una transición fluida.

Comprender las diferencias fundamentales entre estos paradigmas de bases de datos es crucial para una migración exitosa. Los esquemas relacionales suelen estar normalizados, dividiendo los datos en múltiples tablas para reducir la redundancia. El modelo de documentos de MongoDB, sin embargo, fomenta la desnormalización, incrustando datos relacionados dentro de un solo documento para mejorar el rendimiento de lectura y simplificar la lógica de la aplicación. Este cambio requiere una planificación cuidadosa para diseñar documentos que se alineen con los patrones de acceso de su aplicación.

Comprendiendo las diferencias centrales: Modelos relacionales vs. Documentos

Antes de sumergirse en el proceso de migración, es esencial comprender las diferencias conceptuales:

  • Modelo Relacional: Los datos se almacenan en tablas con esquemas predefinidos. Las relaciones se gestionan a través de claves foráneas, lo que requiere operaciones JOIN para recuperar datos relacionados. La normalización es un principio clave.
  • Modelo de Documentos (MongoDB): Los datos se almacenan en documentos flexibles, similares a JSON. Los documentos pueden tener estructuras variables. Los datos relacionados se pueden incrustar dentro de un solo documento (desnormalización) o referenciar mediante uniones a nivel de aplicación o la etapa de agregación $lookup de MongoDB.

Esta diferencia en el modelado de datos afecta directamente cómo diseña sus colecciones y documentos de MongoDB.

Fase 1: Planificación y Diseño de Esquemas

Esta es la fase más crítica. Un esquema de MongoDB bien diseñado es clave para aprovechar sus beneficios. El objetivo es modelar sus datos basándose en los patrones de acceso de la aplicación, no solo en una traducción directa de sus tablas SQL.

1. Analice los patrones de acceso de su aplicación

  • Identifique operaciones de lectura intensiva vs. escritura intensiva: ¿Con qué frecuencia se leen los datos y cómo se consultan típicamente? ¿Qué campos se recuperan juntos con más frecuencia?
  • Determine las rutas de consulta comunes: ¿Cuáles son las sentencias SELECT más frecuentes en su aplicación SQL? ¿Qué tablas se unen normalmente?
  • Comprenda las relaciones de datos: ¿Cómo se relacionan las entidades? ¿Son relaciones uno a uno, uno a muchos o muchos a muchos?

2. Elija su estrategia de desnormalización

El poder de MongoDB radica en su capacidad para incrustar datos relacionados. Considere estas estrategias:

  • Incrustación (Desnormalización): El enfoque más común. Incruste documentos o arreglos de documentos dentro de un documento principal cuando la relación sea uno a muchos o cuando los datos se accedan con frecuencia juntos. Esto reduce la necesidad de uniones.
    • Ejemplo: En lugar de tener tablas separadas de orders y order_items, puede incrustar order_items como un arreglo dentro del documento order.
  • Referencia: Úselo cuando la incrustación conduzca a documentos excesivamente grandes, o cuando los datos se accedan de forma independiente. Almacene el _id de un documento relacionado, similar a las claves foráneas, y realice uniones a nivel de aplicación o utilice $lookup de MongoDB.
    • Ejemplo: Una colección users y una colección posts. Una publicación puede almacenar el user_id de su autor. Luego puede usar $lookup para recuperar los detalles del autor al buscar una publicación.

3. Diseñe sus colecciones y documentos de MongoDB

Basándose en sus patrones de acceso y estrategia de desnormalización, diseñe sus colecciones. Un buen punto de partida es mapear las tablas SQL a las colecciones de MongoDB. Luego, decida qué datos relacionados deben incrustarse y cuáles deben referenciarse.

Ejemplo de esquema SQL:

-- Tabla Customers
CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    FirstName VARCHAR(50),
    LastName VARCHAR(50),
    Email VARCHAR(100)
);

-- Tabla Orders
CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    CustomerID INT,
    OrderDate DATE,
    TotalAmount DECIMAL(10, 2),
    FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);

-- Tabla OrderItems
CREATE TABLE OrderItems (
    OrderItemID INT PRIMARY KEY,
    OrderID INT,
    ProductID INT,
    Quantity INT,
    Price DECIMAL(10, 2),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID)
);

Opciones de diseño de documentos de MongoDB:

  • **Opción A: Cliente con pedidos incrustados (si los clientes tienen un número manejable de pedidos y los pedidos se ven con frecuencia junto con el cliente):
    json { "_id": ObjectId("..."), "customer_id": 1, "first_name": "John", "last_name": "Doe", "email": "[email protected]", "orders": [ { "order_id": 101, "order_date": ISODate("2023-10-26T00:00:00Z"), "total_amount": 50.00, "items": [ { "product_id": 1, "quantity": 2, "price": 25.00 }, { "product_id": 3, "quantity": 1, "price": 0.00 } // Ejemplo de artículo gratuito ] }, // ... más pedidos ] }
  • Opción B: Colecciones separadas con referencia (si los pedidos son numerosos o se consultan con frecuencia de forma independiente):
    Colección Customers:
    json { "_id": ObjectId("..."), "customer_id": 1, "first_name": "John", "last_name": "Doe", "email": "[email protected]" }
    Colección Orders:**
    json { "_id": ObjectId("..."), "order_id": 101, "customer_id": 1, // Referencia a la colección Customers "order_date": ISODate("2023-10-26T00:00:00Z"), "total_amount": 50.00, "items": [ { "product_id": 1, "quantity": 2, "price": 25.00 }, { "product_id": 3, "quantity": 1, "price": 0.00 } ] }

Consideraciones sobre el tamaño del documento: MongoDB tiene un límite de tamaño de documento (16 MB). Evite incrustar arreglos excesivamente grandes que puedan exceder este límite. Si un arreglo crece indefinidamente, considere dividirlo en una colección separada.

Fase 2: Extracción y transformación de datos

Una vez diseñado el esquema de destino, deberá extraer los datos de su base de datos SQL y transformarlos al nuevo formato de documento.

1. Extraer datos de SQL

Utilice consultas SQL estándar para seleccionar los datos que necesite. Puede exportar estos datos a formatos como CSV o JSON.

  • Usando clientes SQL: La mayoría de las herramientas de bases de datos SQL (por ejemplo, DBeaver, SQL Developer, pgAdmin) le permiten exportar los resultados de las consultas a CSV o JSON.
  • Scripting: Escriba scripts (Python, Node.js, etc.) para conectarse a su base de datos SQL, ejecutar consultas y obtener datos.

2. Transformar datos

Aquí es donde implementará el esquema diseñado. Deberá escribir código o utilizar una herramienta para:

  • Agrupar registros relacionados: Por ejemplo, recopilar todos los OrderItems que pertenecen a un Order específico.
  • Reestructurar datos: Convertir filas relacionales en documentos JSON anidados.
  • Manejar tipos de datos: Asegúrese de que los tipos de datos sean compatibles con MongoDB (por ejemplo, fechas, números, cadenas).

Ejemplo usando Python:

Supongamos que ha exportado Customers, Orders y OrderItems a archivos CSV.

import pandas as pd
import json
from bson import ObjectId # Para ObjectId de MongoDB, aunque no es estrictamente necesario para la transformación directa

# Cargar datos desde archivos CSV (suponiendo que están en el mismo directorio)
customers_df = pd.read_csv('customers.csv')
orders_df = pd.read_csv('orders.csv')
order_items_df = pd.read_csv('order_items.csv')

# --- Lógica de transformación de datos ---

# Convertir DataFrame a diccionarios para una manipulación más fácil
customers_list = customers_df.to_dict('records')
orders_list = orders_df.to_dict('records')
order_items_list = order_items_df.to_dict('records')

# Crear un mapeo para pedidos y artículos de pedido para una búsqueda rápida
orders_by_customer = {}
for order in orders_list:
    customer_id = order['CustomerID']
    if customer_id not in orders_by_customer:
        orders_by_customer[customer_id] = []
    orders_by_customer[customer_id].append(order)

order_items_by_order = {}
for item in order_items_list:
    order_id = item['OrderID']
    if order_id not in order_items_by_order:
        order_items_by_order[order_id] = []
    order_items_by_order[order_id].append(item)

# --- Construcción de documentos de MongoDB (Opción A: Cliente con Pedidos Incrustados) ---
mongo_documents = []

for customer in customers_list:
    mongo_doc = {
        "_id": ObjectId(), # MongoDB genera _id automáticamente, pero puedes mapear si es necesario
        "customer_id": customer['CustomerID'],
        "first_name": customer['FirstName'],
        "last_name": customer['LastName'],
        "email": customer['Email'],
        "orders": []
    }

    customer_id = customer['CustomerID']
    if customer_id in orders_by_customer:
        for order in orders_by_customer[customer_id]:
            order_doc = {
                "order_id": order['OrderID'],
                "order_date": order['OrderDate'], # Asegurar el formato de fecha correcto
                "total_amount": order['TotalAmount'],
                "items": []
            }

            order_id = order['OrderID']
            if order_id in order_items_by_order:
                for item in order_items_by_order[order_id]:
                    order_doc['items'].append({
                        "product_id": item['ProductID'],
                        "quantity": item['Quantity'],
                        "price": item['Price']
                    })
            mongo_doc['orders'].append(order_doc)

    mongo_documents.append(mongo_doc)

# Ahora 'mongo_documents' es una lista de diccionarios listos para ser insertados en MongoDB
# print(json.dumps(mongo_documents[0], indent=2, default=str)) # Imprimir el primer documento como JSON

# Para la Opción B (Colecciones Separadas), crearía listas para cada colección:
# customers_mongo = [{'customer_id': c['CustomerID'], ...} for c in customers_list]
# orders_mongo = [{'order_id': o['OrderID'], 'customer_id': o['CustomerID'], ...} for o in orders_list]

# Guardar en JSON para importar (opcional)
# with open('mongo_customer_data.json', 'w') as f:
#     json.dump(mongo_documents, f, indent=2, default=str)

3. Herramientas para la transformación

  • Scripts personalizados: Python con Pandas, Node.js con bibliotecas como csv-parser y mysql/pg son potentes para transformaciones complejas.
  • Herramientas ETL: Herramientas como Apache NiFi, Talend o AWS Glue pueden orquestar canalizaciones de datos complejas, incluida la migración de SQL a MongoDB.
  • Migración en vivo de MongoDB Atlas: Si migra a MongoDB Atlas, su servicio de Migración en vivo puede ayudar a mover datos de varias fuentes, incluidas las bases de datos SQL.

Fase 3: Carga de datos en MongoDB

Una vez que los datos se han transformado, puede cargarlos en su instancia de MongoDB.

1. Conéctese a MongoDB

Utilice el shell de MongoDB (mongosh) o un controlador de MongoDB (para su lenguaje de programación) para conectarse a su base de datos.

2. Importe datos transformados

  • Usando mongosh con mongoimport: Si exportó sus datos transformados a un archivo JSON (como se muestra en el ejemplo de Python), puede usar mongoimport:
    bash # Suponiendo que sus datos están en mongo_customer_data.json y desea importar en la colección 'customers' mongoimport --db nombre_tu_base_de_datos --collection customers --file mongo_customer_data.json --jsonArray

    • --jsonArray: Use esta bandera si su archivo JSON contiene un arreglo de documentos.

  • Usando controladores de MongoDB: Si generó sus estructuras de datos en su lenguaje de programación (como la lista mongo_documents en Python), puede insertarlas directamente:

    **Ejemplo de Python (usando pymongo):
    ```python
    from pymongo import MongoClient

    Suponiendo que la lista 'mongo_documents' está definida en el script de Python anterior

    client = MongoClient('mongodb://localhost:27017/')
    db = client['nombre_tu_base_de_datos']
    customers_collection = db['customers']

    Insertar los documentos transformados

    if mongo_documents:
    insert_result = customers_collection.insert_many(mongo_documents)
    print(f"Insertados {len(insert_result.inserted_ids)} documentos.")
    else:
    print("No hay documentos para insertar.")

    client.close()
    ```

3. Verifique la integridad de los datos

Después de la carga, ejecute consultas en MongoDB para verificar que los datos se han importado correctamente y coinciden con sus expectativas.

// Ejemplo: Contar documentos en la colección 'customers'
use nombre_tu_base_de_datos;
print(db.customers.countDocuments());

// Ejemplo: Encontrar un cliente específico y verificar sus pedidos incrustados
db.customers.findOne({ "customer_id": 1 })

Fase 4: Refactorización de la aplicación

Esta es, posiblemente, la fase que más tiempo consume. El código de su aplicación debe actualizarse para interactuar con MongoDB en lugar de SQL.

  • Actualice las conexiones a la base de datos: Cambie las cadenas de conexión y las bibliotecas.
  • Reescriba las consultas: Reemplace las consultas SQL con el lenguaje de consulta de MongoDB utilizando la API de su controlador elegido.
  • Ajuste la capa de acceso a datos: Modifique su ORM o capa de acceso a datos para trabajar con documentos de MongoDB.
  • Aproveche las características de MongoDB: Adapte su aplicación para aprovechar características como esquemas flexibles, el framework de agregación y consultas geoespaciales si corresponde.

Mejores prácticas y consejos

  • Comience poco a poco: Si es posible, migre primero un subconjunto de sus datos o una aplicación menos crítica para ganar experiencia.
  • Itere en el diseño del esquema: Es posible que su esquema inicial de MongoDB no sea perfecto. Esté preparado para iterar y refinarlo en función de las pruebas de rendimiento y los comentarios de la aplicación.
  • Indexe sabiamente: Al igual que en SQL, la indexación es crucial para el rendimiento en MongoDB. Identifique sus patrones de consulta y cree índices apropiados.
  • Monitoree el rendimiento: Monitoree continuamente su implementación de MongoDB en busca de cuellos de botella de rendimiento y optimice consultas y esquemas según sea necesario.
  • Considere la migración incremental: Para bases de datos grandes, considere una estrategia de migración incremental donde sincroniza los cambios de SQL a MongoDB en tiempo casi real antes de realizar un corte final.

Conclusión

Migrar de SQL a MongoDB es un movimiento estratégico que puede desbloquear beneficios significativos en términos de flexibilidad y escalabilidad. El proceso requiere una planificación cuidadosa, un diseño de esquema reflexivo enfocado en los patrones de acceso de la aplicación y una estrategia robusta de transformación y carga. Siguiendo estos pasos y mejores prácticas, puede navegar por las complejidades de transformar sus datos relacionales en un modelo de documentos MongoDB eficiente y potente, allanando el camino para una arquitectura de aplicación más ágil y escalable.