Caso práctico Almacenamiento e integración de datos

Memoria entrega final - Almacenamiento e Integración de Datos

Ejercicio 1

Se desea diseñar una aplicación que implemente un buscador de ofertas de trabajo. Cada usuario puede configurar qué portales de ofertas de trabajo servirán de fuente para recuperar las ofertas y las características de las ofertas que deben recuperarse. La aplicación se conectará a los portales y generará entradas asociadas a cada usuario. Una entrada será esencialmente el nombre del portal web donde se ha encontrado la oferta, el contenido principal de la oferta, las características que cumple la oferta con respecto a los requisitos impuestos por el usuario y un enlace a la misma (la aplicación guardará una copia de la oferta para asegurarse de que no sea eliminada del portal), de forma que, si el usuario desea consultar la oferta completa, puede pulsar sobre el enlace. Hay que tener en cuenta que las entidades que deberá gestionar en cuanto al número de portales, requisitos de búsqueda, ofertas y usuarios van a ser enormes.

1. Realizar un análisis acerca del modelo de datos y la arquitectura de distribución y replicación de los datos que se adecúen mejor a los requisitos de la aplicación descrita. En cuanto al modelo de datos, hay que argumentar la conveniencia de un modelo relacional o uno NoSQL y, en caso de que se elija este último, qué modelo sería el más adecuado.

En este caso en concreto, convendría utilizar una base de datos no relacional (NoSQL). Los motivos de esta decisión son los siguientes:

• Es muy probable que las fuentes de datos a consultar (en este caso los portales de empleo) presenten la ofertas con estructuras diferentes. Por ejemplo, en el contenido principal de la oferta habrá portales que incluyan más campos que otros.
• La cantidad de datos con la que se espera trabajar es bastante grande, por lo que a la hora de ejecutar las consultas un modelo no relacional tendrá una latencia más baja y a la hora de escalar la aplicación, será más económico optar por el modelo no relacional.
• Otro beneficio del uso de una base de datos no relacional es evitar el problema de la impedancia, puesto que si usásemos una base de datos relacional tendríamos que transformar las entradas que va a generar nuestra aplicación a tipos de datos más simples, para que el modelo relacional pueda asimilarlos correctamente. Esto conlleva un tiempo y uso recursos computacionales considerablemente mayores.
• Además, el uso de una base de datos no relacional nos permitiría implementar la ejecución distribuida de manera mucho más cómoda que un modelo relacional. Debido a la cantidad de datos con los que tenemos previsto trabajar, tarde o temprano tendremos que comenzar a utilizar el procesamiento distribuido puesto que un único servidor sería demasiado costoso y no tendría el nivel de rendimiento que necesitamos.

Las bases de datos de tipo clave - valor se tornan demasiado sencillas para apresar la complejidad de las entradas que necesitamos manejar en nuestra aplicación. El número de claves que habría que definir para recoger adecuadamente todos los aspectos de interés de las ofertas de trabajo y de las entradas que necesitaríamos generar.

Las bases de datos orientadas a columnas tampoco son las más idóneas debido a la variabilidad que nos podemos encontrar en la estructura de los datos. Dicho de otra forma, nada nos asegura que todas nuestras fuentes de datos tengan las mismas columnas, o incluso columnas similares. Por ejemplo, puede que, en algún portal de empleo, se publique el horario laboral, pero en otro portal no, lo mismo con el resto de información referente a una oferta de trabajo (salario, temporalidad, tipo de contrato, etc.).

También podemos descartar las bases de datos orientadas a grafos puesto que la forma en la que podemos extraer valor de nuestros datos no recae en las relaciones que hay entre diferentes ofertas de trabajo, sino en la capacidad de poder gestionar y realizar consultas de un gran pool de ofertas. Este tipo de base de datos está pensado para otros tipos de datos como datos de navegación (GPS), geoespaciales, o de análisis de redes sociales.

Por todos estos motivos, el tipo de base de datos no relacional más conveniente para este proyecto son las bases de datos orientadas a documentos. Esto se debe a que las entradas que generará la aplicación son conjuntos complejos de datos, con estructuras cambiantes dependiendo de qué portales se extraigan. Dentro de esta familia de bases de datos, se optará por la utilización de MongoDB, la cual ofrece compatibilidad con multitud de lenguajes de programación y permite empezar a trabajar con una versión gratuita en la nube (MongoDB Atlas), la cual podremos escalar según las necesidades que vayan surgiendo en base al crecimiento de la aplicación.

1. Describir una colección de MongoDB que almacenará la información sobre las solicitudes realizadas por cada usuario, ilustrándolo con las colecciones y tipos de documentos que serían necesarios.

En primer lugar, necesitamos definir qué tipo de entradas o registros queremos que recoja nuestro buscador de empleo. Según las especificaciones disponibles podemos distinguir dos tipos claros:

• Ofertas de trabajo
• Solicitudes del usuario

Un ejemplo de los esquemas de un documento de cada uno de estos dos tipos sería:

• Ofertas de empleo

{
“_id”: ObjectId(“5af712eff26b29dc5c51c60f”),

“oferta”: “Administrativo/a área comercial”,

“portal”: “Portal ejemplo”

“link”: “https://portalejemplo.com/ofertas/oferta1.html”,

“fechaPublicacion”: ISODate("2020-05-18T14:10:30Z"),

“empresa”: “Business S.L.”,