De NoSQL a SQL
Introducción
En este artículo se explica de una manera breve el proceso de migración de una base de datos no relacionales (MongoDB) a una de relacionales (PostgreSQL), en base a nuestra experiencia en nowports.
Incluyo las razones que motivaron a migrar, el proceso de la creación de los modelos y sus nuevas relaciones; así como la gestión de los mismos y población de información por medio de las semillas. Utilizamos el ORM de Nodejs Sequelize, el cual nos ayuda con la estructura lógica de la base de datos relacional, para simplificar y acelerar el desarrollo de nuestra aplicación.
Tecnologías
MongoDB
Es una base de datos NoSQL documental o basada en documentos, lo que significa que almacena datos en forma de tipo JSON. Su documento es un registro compuesto por pares "llave": "valor".
PostgreSQL
Es un gestor de bases de datos relacionales que ofrece una gran cantidad de opciones avanzadas. Al ser extensible, nos permite agregar funcionalidades que no sean veganas; provistas de series que, una vez cargadas, se comportan como si fueran parte de Postgres.
Sequelize
Es un ORM Node.js basado en promesas para base de datos relacionales, el cual nos permite manipular las bases de datos sin utilizar directamente las consultas SQL.
Una de las principales razones por las que se decidió migrar de base de datos es por el manejo de la relación entre las colecciones. MongoDB es una base de datos no relacional que se basa en documentos y al ver que el esquema de los datos usados, se ejecutaban de manera relacional y rompía su paradigma.
Al crear reportes de la información en nuestra base de datos, nos dimos cuenta que los documentos hacían referencias a otras colecciones. Por esto decidimos cambiar de base de datos y a su vez generar una refactorización del código.
A continuación se menciona el procedimiento para esta transición.
Pasos a seguir
Antes de que se empezara a trabajar sobre la nueva estructura, el equipo se detuvo un momento para analizar los modelos que existían dentro de nuestra base de datos de Mongo. Creamos un schema de base de datos con sus relaciones y corroboramos que no existieran datos que se podrían unificar en algún modelo ya establecido.
Una vez ya establecido el schema, utilizamos el ORM Sequelize. Seguimos sus guías de inicio y de migraciones para la generación de los modelos y poblar con datos de prueba generando seeds para nuestra nueva base de datos.
A continuación se muestran los pasos que se siguieron en el desarrollo.
Instalación de sequelize utilizando npm:
npm install — save sequelize
Si se requiere la instalación utilizando yarn, usamos de la siguiente manera:
yarn add sequelize
Y así con las dependencias que sean necesarias.
Se instala manualmente el controlador de la base de datos de nuestra elección, Postgres en este caso:
npm install — save pg pg-hstore
Usamos migraciones para el seguimiento de los cambios de la base de datos. Ya que cada tipo de migración se conserva en un archivo único, para poder cambiarlas a nuestra nueva estructura de la base de datos es necesario instalar el CLI de Sequelize, de la siguiente manera:
npm install — save sequelize-cli
Después de su instalación, creamos la configuración inicial, la cual creará las carpetas donde se guardaran los archivos generados. La carpeta config contiene el archivo de configuración que indica cuál es el ambiente con el que trabajaremos nuestra base de datos.
Ya con la instalación y configuración del ORM, creamos la estructura basada en el schema, generado de la base de datos.
Utilizando el siguiente comando es como generamos los modelos:
npx sequelize-cli model:generate — name User — attributes name:string
Después, generamos sus relaciones como se requerían, utilizando las nomenclaturas conocidas por las bases de datos 1:1, 1:N, N:1 y N:N.
Con nuestros modelos relacionados, creamos nuestras migraciones para secuenciar automáticamente al momento de crear un modelo:
npx sequelize-cli db: migrar
Por último, se respetaron los nombres de los atributos de cada modelo específico en la base de datos de producción. Se traspasa su información dentro de la nueva base de datos generada con Postgres. A su vez, se aprovecha para refactorizar funciones, usar tablas paranoicas para el borrado lógico de los registros y agregar datos ficticios por medio de las semillas que nos proporciona Sequelize.
Conclusión
Realizar la migración, aunque implicó su trabajo, fue una buena decisión. Con SQL, tenemos más posibilidades en la magnitud del detalle, crecimiento a futuro y uso de la base de datos.
