Mi experiencia con bases de datos NoSql: MongoDB

Enviado por Carxl el Sáb, 07/07/2012 - 22:52.

Buscando una solución a un problema que agobiaba al equipo; una base de datos relacional con millones de registros y exagerada lentitud en las consultas, decidí echar un vistazo a una nueva tecnología que no conocía hasta la que la escuché unas semanas atrás: Base de datos NoSql.

Aclaro que este artículo no es un manual de bases de datos NoSql, este artículo se trata de mi conclusión acerca de la implementación de esta tecnología.

Revisando su teoría y diversidad de artículos que encontré en internet hablando al respecto, llegué a la conclusión que debía hacer vacuidad en lo que conozco de base de datos: todo lo que te enseñan en la universidad acerca de base de datos se va a la mierda y debes permitirte recibir un nuevo concepto.

He aquí algunas de las enseñanzas:

  1. En las bases de datos Nosql, no existe la integridad referencial, olvídala.
  2. No existe el concepto en bases de datos de atomicidad, olvídala.
  3. Hacerse a la idea que será un “documento gigante". No hay tablas normalizadas.
  4. El lenguaje Sql que se conoce, no sirve para nada, ahora debería aprender un nuevo lenguaje para realizar búsquedas.
  5. Si alguna vez usaste arrays, objetos en un lenguaje de programación, estarás más cerca de entender cómo recorrer los datos.
  6. Las bases de datos relaciones siguen un esquema de datos casi igual, en las NoSql puedes guardar lo que quieras y como quieras.

Luego de tener claro todo lo anterior, seleccioné un motor NoSql: MongoDb.

 

Implementación MongoDb

Aspectos a tener en cuenta:

1. Es probable que tú solo puedas hacer toda la implementación, pero sería mucho mejor que tuvieras un equipo con buenos conocimientos en esta tecnología para tener un apoyo y optimizar tiempos.

2. MongoDb hasta su actual versión (2.0.6 ) no soporta joins entre colecciones, debes solucionarlo desde tu lógica de programación.

 

Terminología MongoDb:

  • Colección = Tabla
  • Documento = registro

 

MongoDb usa Bson para el almacenamiento de los datos, por lo tanto debía exportar la base de datos relacional al formato adecuado para MongoDb.

Procedí a escribir (para aclararme más) mi plan de trabajo:

  1. Crear un script para exportar los datos de la base de datos relacional a formato Bson. El script generó un archivo .json que pesaba 2,9 Gb. Importé ese documento en una sola colección.
  2. Estudiar el lenguaje que usa MongoDb para consultar los datos. Lo que sería en las bases de datos el lenguaje Sql.
  3. Definir e implementar los índices adecuados para optimizar las búsquedas en la nueva base de datos.
  4. Revisar tiempos de ejecución.

Todo lo anterior se ejecutó en un servidor con MongoDb v.2.

Luego de ejecutar los pasos anteriores, observé el comportamiento de la base de datos y para mi sorpresa, las consultas corrían más lentas.

En su documentación oficial se puede leer el siguiente enunciado:

MongoDB limits the data size of individual BSON objects/documents. At the time of this writing the limit is 16MB. This limit is designed as a sanity-check; it is not a technical limit on document sizes. The thinking is that if documents are larger than this size, it is likely the schema is not ideal. Further it allows drivers to make some assumptions on the max size of documents.

Supongo que una de las falencias de mi implementación es que estaba usando una sola colección de 2,9 Gb.

Una opción ideal sería hacer la implementación de GridFS. Por cuestiones de tiempo y de recursos no podía hacer una implementación como esa.

Al ver que esa solución no servía, pensé en otra opción, crear múltiples colecciones (tablas), estilo tablas relacionales, e intentar simular join entre esas colecciones, para distribuir el peso de la información.

Resulta que el gran problema de esa solución es que MongoDb no tiene un método propio para simular joins entre colecciones; por lo tanto, la lógica del sistema (en mi caso lógica Php) es la encargada de hacer esa abstracción y la intersección entre entre colecciones. Ya pueden suponer el problema que salta al intentar esto...

Ya con el presentimiento de lo que iba a pasar, realicé sin problemas la lógica para simular la intersección entre las dos colecciones mediante Php. Qué pasó? simplemente el proceso disparó error de timeout. Ninguna de las consultas que programé funcionaron como esperaba.

Las siguientes ideas que se me ocurrieron fueron una combinación entre la primera y la segunda opción, pero todas con resultados parecidos.

Tras días intentando con MongoDb solamente, con MongoDb combinado con Php, llegué a la conclusión que esta vez MongoDb no aplicaba como solución a mi problema, optando por buscar otras soluciones clásicas para resolverlo.

 

Mi opinión sobre MongoDb

A pesar que MongoDb está muy bien trabajado y desarrollado, siento que aún le falta madurez, siento que aún faltan funcionalidades para que sea más versátil.

Por ejemplo, actualmente, no se puede hacer mucho con las colecciones que tengan múltiples subarrays, es decir, no puedes hacer consultas complejas para obtener resultados relacionados a esos índices, debes manejarlos desde tu lógica.

Otro limitación que noto, es que no puedes trabajar haciendo consultas con múltiples colecciones (estilo joins). También debes solucionarlo desde tu lógica.

Quizás esto último sea hecho a propósito para ganar velocidad, no sé, pero intuitivamente se esperaría poder trabajar con algo parecido a joins.

Espero que este artículo sirva como prólogo a aquellos que quieren conocer esta tecnología, porque son pocos los artículos que se encuentran sobre experiencias.

Espero sus comentarios Wink

Enviar un comentario nuevo

  • Saltos automáticos de líneas y de párrafos.

Más información sobre opciones de formato

CAPTCHA
Esta pregunta se hace para comprobar que es usted una persona real e impedir el envío automatizado de mensajes basura.
CAPTCHA de imagen
Enter the characters shown in the image.