El blog de Javier Aranda

¿Qué es mongoDB?

Es una base de datos orientada a documentos de código abierto escrita en C++. A diferencia de otros sistemas de gestión de bases de datos, mongoDB no sigue el modelo relacional. La base de datos gestiona colecciones de documentos en objetos JSON. Está orientada a la web 2.0, la nube y las configuraciones de varios servidores de bases de datos. En la entrada Más allá de las bases de datos relacionales hablamos de la utilidad de este tipo de bases de datos.

Más información:

• http://en.wikipedia.org/wiki/MongoDB
• http://en.wikipedia.org/wiki/Document-oriented_database
• http://www.mongodb.org

Descargando e instalando mongoDB

Existen dos formas de realizar este proceso: podemos descargar el código fuente y compilarlo o bajar directamente los binarios. En este artículo optaremos por lo segundo por la facilidad y comodidad.

En la sección de descargas de la web de mongodb tenemos varias opciones, aunque las que nos interesa es la correspondiente a la versión 1.0.0 para Linux 32 bits (el que use 64 bits deberá escoger su opción). Tras la descarga, tendremos un archivo tar.gz que descomprimiremos con los comandos habituales:

cd Escritorio
tar -zxvf mongodb-linux-i686-1.0.0.tgz
cd mongodb-linux-i686-1.0.0

Si observamos el contenido del directorio vemos que se organiza en los subdirectorios bin, include y lib. En principio ya podríamos ejecutar mongodb desde ese directorio, pero por cuestiones de orden y claridad, copiaremos el contenido de esas subcarpetas en los directorios de igual nombre bajo /usr/local, operación para la que necesitamos adquirir permisos de root.

sudo -s
mv bin/* /usr/local/bin
mv include/* /usr/local/include
mv lib/* /usr/local/lib

De aquí en adelante asumiremos que estamos logueados en la terminal como root. Como ya tenemos los archivos donde nos interesan, podemos eliminar la carpeta descomprimida y el archivo descargado:

cd ../
rm -fr mongodb-linux-i686-1.0.0 mongodb-linux-i686-1.0.0.tgz

Configuración inicial

Antes de iniciar el demonio de mongodb es necesario crear una serie de directorios de trabajo, ya que al no instalarse, estos directorios no se crean. El más fundamental será el directorio donde el gestor almacenará las estructuras necesarias para almacenar en el disco duro los datos. Por defecto la carpeta es /data/db pero en este tutorial guardaremos los datos bajo /var/lib/mongodb (mysql por ejemplo también guarda los datos bajo /var/lib). Para ello creamos el directorio:

mkdir /var/lib/mongodb

Este directorio es propiedad de root. En este tutorial el demonio mongod se ejecutará bajo el usuario root. Podríamos ejecutarlo bajo otro usuario existente o crear uno específico para ello, tras lo que podríamos cambiar la propiedad del directorio de los datos por la del usuario usado por mongod.

El demonio puede configurarse mediante una serie de parámetros (ejecutar mongod –help para una lista) pasados al ejecutable del demonio, pero esta forma es un poco sucia y puede exponer ciertas configuraciones a la vista de cualquier usuario del sistema que explore la lista de procesos. Por ello, mongodb permite ser llamado especificándole la ruta a un archivo de configuración (de tipo conf). Ya que existe esa posibilidad, nosotros la vamos a hacer de esa forma. Para ello creamos un directorio bajo /etc llamado mongodb:

mkdir /etc/mongodb

Y con cualquier editor creamos el archivo mongodb.conf y le asignamos el contenido:

nano /etc/mongodb/mongodb.conf

# Config file for MongoDB

dbpath = /var/lib/mongodb

Como puede observarse, la directiva de configuración dbpath (que podía fijarse como parámetro del demonio) se usa de forma análoga en el archivo de configuración, especificándole a la aplicación dónde se encuentra el directorio con los datos. Existen directivas que no reciben argumentos, por ejemplo –auth no requiere nada a continuación. En estos casos, en el archivo de configuración deberemos igualarlo a true. Continuando con el ejemplo, –auth quedaría como auth = true. Por el momento no usaremos más directivas. En la web oficial existe un apartado dedicado a cada parámetro que podemos usar para configurar mongodb.

Iniciando el demonio

Para ejecutar el demonio escribiremos (le indicamos la ruta al archivo de configuración con -f):

mongod -f /etc/mongodb/mongodb.conf

Y si todo va bien, obtendremos algo como esto:

Tue Oct 13 21:47:02 Mongo DB : starting : pid = 16139 port = 27017 dbpath = /var/lib/mongodb master = 0 slave = 0  32-bit 

** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
**       see http://blog.mongodb.org/post/137788967/32-bit-limitations for more

Tue Oct 13 21:47:02 db version v1.0.0, pdfile version 4.4
Tue Oct 13 21:47:02 git version: afe21e02c11f9a923ab1c95edf6fdd95b9a4a51e
Tue Oct 13 21:47:02 sys info: Linux domU-12-31-39-01-70-B4 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686
Tue Oct 13 21:47:02 waiting for connections on port 27017
Tue Oct 13 21:47:02 web admin interface listening on port 28017

Tras esta operación ya tenemos al demonio listo para atender nuestras peticiones.

Instalar el driver para PHP

Para poder instalar el driver de mongodb para php debemos tener instalado el paquete PEAR y la versión de desarrollo de php. Si no lo tenemos instalado, sólo tenemos que ejecutar:

apt-get install php-pear php5-dev

Y para instalar el driver:

pecl install mongo

Configurar PHP

El siguiente paso y último de la instalación y configuración consiste en indicarle a php que debe cargar la nueva extensión que contiene el driver en sí. Para ello creamos el siguiente archivo:

nano /etc/php5/conf.d/mongodb.ini

Y le asignamos la carga del módulo y sus directivas de configuración:

extension=mongo.so

[mongo]
; If the driver should reconnect to mongo
mongo.auto_reconnect = true

; Whether to allow persistent connections
mongo.allow_persistent = On

; Maximum number of persistent connections (-1 means unlimited)
mongo.max_persistent = -1

; Maximum number of links (persistent and non-persistent, -1 means unlimited)
mongo.max_connections = -1

; Default host for mongo connection
mongo.default_host = www.example.com

; Default port for mongo database
mongo.default_port = 42

; When saving files to the database, size of chunks to split them into
mongo.chunk_size = 1024

; Specify an alternate character to $ to use for special db functions ($set, $push, $exists, etc.)
mongo.cmd = "$"

Tras esta operación debemos reiniciar Apache para que PHP cargue de nuevo la configuración y los módulos (sólo si trabajamos con mod_php).

/etc/init.d/apache2 restart

Si ejecutamos un phpinfo() observamos que la extensión se ha cargado perfectamente.

Las bases de datos relacionales, como MySQL, PostgreSQL y varios productos comerciales, nos han servido bien durante muchos años. Últimamente, sin embargo, ha habido mucha discusión sobre si el modelo relacional está llegando al final de su vida útil, y qué es lo que viene después de él.

¿Qué motor de base de datos debería usar?

Por supuesto, la respuesta es “depende”, pero esto no resulta de mucha ayuda. Déjame hacerte algunas preguntas para ayudarte a averiguar que tecnología es la apropiada para tu aplicación particular. Entonces, podré darte algunos consejos para que puedas conocer más.

Ante todo, calma. Lo más probable es que la base de datos que uses actualmente funcione perfectamente bien por ahora. Pero es posible que quieras estar atento en caso de que note algunos de los síntomas que avisan que el modelo relacional está trabajando al límite. Algunos síntomas relacionados con la estructura de tus datos:

• ¿Tienes tablas con varias columnas, y sólo algunas de ellas son actualmente usadas por una fila en particular?
• ¿Tienes tablas atributo donde cada fila es

(clave foránea a una fila de otra tabla, nombre del atributo, valor del atributo)

y necesitas hacer feos joins en tus consultas para tratar con esas tablas?

• ¿Has dejado de utilizar columnas para los datos estructurados, y en su lugar los serializar (a JSON, YAML, XML y otros) y almacenas la cadena resultante en tu base de datos?
• ¿Tiene tu esquema un gran número de tablas de unión muchos-a-muchos o estructuras tipo árbol (una clave foránea que hace referencia a una fila diferente de la misma tabla)?
• ¿Encuentras que con frecuencia tienes que hacer cambios en tu esquema para poder representar adecuadamente los datos de entrada?

Otros síntomas relacionados con la escalabilidad de tu sistema:

• ¿Estás alcanzando el límite de la capacidad de escritura con un sólo servidor? (Si tu problema es la capacidad de lectura, deberías establecer una replicación maestro-esclavo. Así mismo, asegurate que primero has puesto la base de datos en el servidor mas potente que puedas pagar, de que has optimizado tus consultas y que tu esquema no pueda dividirse fácilmente en fragmentos.
• ¿Tu cantidad de datos es mayor que la que un sólo servidor puede manejar?
• ¿La carga de tus páginas se ralentizan inaceptablemente por procesamientos en lote en segundo plano sobre la inmensa base de datos?

En mi opinión, se pone demasiado énfasis en la escalabilidad, a pesar de ser un problema muy lejano en la mayoría de los proyectos. Es comprensible – los sistemas a gran escala son sexis, y a todo el mundo le gusta pensar que están creando un servicio el cual va a ser muy popular – pero en la mayoría de las veces, los desarrolladores deberían centrarse en las necesidades de sus clientes, y resolver los problemas de escalabilidad sólo si realmente estos aparecen.

Dicho esto, hay una razón más para considerar las bases de datos no relacionales: están de moda. Es una idea tonta basar una decisión técnica en una moda, pero recuerda el aspecto humano de los proyectos de gestión de software. Los desarrolladores en general queremos trabajar con gente guay en un ambiente guay y usando tecnología guay. Eso significa que si quieres contratar desarrolladores y les proporcionas todo este ambiente guay, tendrás una mejor oportunidad de conseguir a los mejores. La moda no debería ser la razón principal, pero si todo lo demás es igual, probablemente puedes tirar por el lado guay. Y ahora voy a dejar de decir guay – no es muy guay.

Bases de datos documentales y la Big Table

Este artículo sobre la BigTable describe cómo Google ha desarrollado su propia base de datos altamente escalable para uso interno, como base de varios de sus servicios. El modelo de datos es un poco diferente del relacional: las columnas no necesitan ser predefinidas, y cada fila se puede agregar con cualquier conjunto de columnas. Las columnas vacías no se almacenan en absoluto.

La BigTable ha inspirado a muchos desarrolladores a escribir su propia implementación de este modelo de datos, dónde los más populares son HBase, Hypertable y Cassandra. La falta de un esquema predefinido pueden hacer atractivas estas bases de datos en aplicaciones dónde los atributos de los objectos no son conocidos de antemano, o cambian con frecuencia.

Las bases de datos documentales poseen un modelo de datos relacionado (aunque la forma en que manejan la concurrencia y los servidores distribuidos puede ser un poco diferente): una fila en la BigTable con un número arbitrario de columnas/atributos se corresponde a un documento en una base de datos documental, que normalmente es un árbol de objetos conteniendo los valores de los atributos y listas, a menudo mapeadas a JSON o XML. Bases de datos documentales de código abierto son Project Voldemort, CouchDB, MongoDB, ThruDB y Jackrabbit.

¿Y cuál es la diferencia con almacenar cadenas JSON en MySQL? Las bases de datos documentales pueden actualmente trabajar con la estructura de los documentos, por ejemplo extrayendo, indexando, añadiendo y filtrando datos basado en el valor de un atributo dentro de los documentos. Alternativamente, tu puedes por supuesto crear la indexación de los atributos por ti mismo, pero yo no lo recomendaría a menos que esto te haga trabajar con tu código antiguo más fácilmente.

La gran limitación de las bases de datos del tipo BigTable y las documentales es que la mayoría de las implementaciones no pueden realizar uniones (joins) u operaciones de expansión entre varias filas o documentos. Esta restricción es deliberada, porque permite a la base de datos el particionado automático, el cual es importante para escalar — véase la sección de almacenamiento distribuido de parejas de clave-valor a continuación. Si la estructura de tus datos es una gran cantidad de documentos independientes, esto no es un problema — pero si tus datos se acojen a un modelo relacional y necesitas hacer uniones, por favor, no intentes forzarlo a un modelo documental.

Bases de datos de gráfos

Las bases de datos de gráfos residen en el extremo contrario del espectro. Mientras las documentales son buenas para almacenar datos estructurados en la forma de muchos documentos independientes, las basadas en gráfos se centran en las relaciones entre los elementos — un mejor ajuste para los modelos de datos altamente conectados.

El SQL estándar no permite consultar las relaciones transitivas, es decir, un encadenamiento de longitud variable entre varias uniones que continúan hasta que algún tipo de condición se cumple. Las bases de datos de gráfos están optimizadas precisamente para este tipo de datos. Estos síntomas indican que sus datos encajarían mejor en un modelo gráfico:

• Escribes grandes cadenas de uniones (unión de la tabla A con la B, B con C, C con D …) en tus consultas.
• Escribe bucles de consultas en tu aplicación para conseguir una cadena de relaciones (particularmente cuando no sabes de antemano la longitud que tomará el encadenamiento).
• Tienes varias uniones muchos-a-muchos o estructuras tipo árbol.
• Tus datos ya están en una forma gráfica (por ejemplo la información sobre quién es amigo de quién en una red social).

Hay menos opciones en las bases de datos gráficas que documentales: Neo4j, AllegroGraph y Sesame (que normalmente utiliza MySQL o PostgreSQL como back-end) son las que mirar. FreeBase y DirectEdge han desarrollado bases de datos gráficas para su uso interno.

Las bases de datos gráficas se asocian a menudo con la web semántica y almacenes de datos RDF, que es una de las aplicaciones para las que son usadas. Realmente creo que muchos datos de otras aplicaciones estarían bien representados en gráfos. Sin embargo, como ántes, no trates de forzar  los datos en un gráfo si encajan mejor en tablas o documentos.

MapReduce

Muy a la ligera: si el procesamiento por lotes en segundo plano es tu problema y no conoce el modelo MapReduce, debería. Popularizado por otro artículo de Google, MapReduce es una forma de escribir trabajos de procesamiento por lotes sin preocuparse por la infraestructura. Diferentes bases de datos se prestan mejor o peor al MapReduce — algo a tener en cuenta al elegir una base de datos para satisfacer nuestras necesidades.

Hadoop es el rey entre las implementaciones de código abierto, aunque también merece la pena mirar Skynet y Disco. CouchDB también incluye algunas ideas de MapReduce en una menor escala.

Almacenamiento distribuido de clave-valor

Un almacenamiento de clave-valor es un concepto muy simple, muy similar a una tabla hash: puedes recuperar un elemento basado en su clave, puedes insertar un par de clave-valor, y puedes borrar un par de clave-valor. El valor puede ser simplemente una lista opaca de bytes, o puede ser un documento estructurado (la mayoría de las implementaciones de bases de datos documentales o basadas en la BigTable se pueden considerar como almacenamientos clave-valor).

Las bases de datos documentales, gráficas y MapReduce introducen nuevos modelos de datos y nuevas formas de pensar que pueden ser útiles incluso en una aplicación de pequeña escala; no necesitas ser Google o Facebook para beneficiarte de ellas. El almacenamiento distribuido de clave-valor, por otra parte, va en realidad acorde con la escalabilidad. Pueden escalar cantidades verdaderamente enormes de datos — muchos más de los que un sólo servidor podría soportar.

Las bases de datos distribuidas pueden transparentemente particionar y replicar tus datos a través de varias máquinas en un clúster. No resulta necesario implementar un sistema de fragmentación para decidir sobre qué determinado servidor se puede encontrar un determinado fragmento de datos; la base de datos lo hace por usted. Si un servidor muere, no hay problema — otros pueden inmediatamente empezar a funcionar. Si necesita más recursos, sólo tiene que añadir los servidores al clúster, y la base de datos le asignará automáticamente una parte de los datos y de la carga.

Al elegir un almacenamiento de clave-valor, debes decidir entre si debe estar optimizado para una baja latencia (para un rápido acceso durante el ciclo de petición-respuesta típico de un servidor web) o para un rendimiento alto (usado en los trabajos de procesamiento por lotes).

Aparte de las basadas en la BigTable y las documentales, Scalaris, Dynomite and Ringo proporcionan cierta garantía en la consistencia de los datos, mientras que se encargan del particionamiento y la distribución del conjunto de datos. MemcacheDB y Tokyo Cabinet (con Tokyo Tyrant para el servicio en red y LightCloud para que sea distribuida) se centran en la latencia.

La advertencia sobre la limitación en las transacciones y las uniones se aplica incluso más fuertemente en las bases de datos distribuidas. Implementaciones diferentes tienen enfoques distintos, pero en general, si necesitas leer varios elementos, manipularlos de alguna manera y luego volver a escribirlos, no existe garantía de que va a terminar en un estado coherente inmediatamente (aunque muchas implementaciones tratan de convertirse eventualmente consistentes resolviendo conflictos de escritura o usando protocolos de transacciones distribuidas; véase el algoritmo de Amazon Dynamo para un ejemplo). Por lo tanto, sólo deberías utilizar estas bases de datos si tus datos son elementos independientes, y si la disponibilidad y performancia son más importantes que las propiedades ACID. Para más información, lea acerca del Teorema CAP de Brewer, que establece que entre la consistencia, la disponibilidad y el particionado, sólo podemos elegir dos, y nunca ninguna base de datos podrá saltarse este hecho.

Richard Jones, co-fundador de Last.fm, ha escrito una excelente visión de conjunto de los almacenamientos de clave-valor. También, Tony Bain ofrece una introducción a las diferencias conceptuales entre las bases de datos relacionales y los almacenamientos de clave-valor, y recientemente hubo un evento NOSQL en San Francisco, donde se presentaron una serie de diferentes bases de datos no relacionales.

Los sistemas distribuidos son poco amistosos… muy poco amistosos. Sugiero que se usen sólo si realmente necesitamos los aspectos de escalado que ofrecen (o sólo por diversión fuera de un entorno de producción).

Resumiendo

En este artículo me he centrado en proyectos de código abierto. Si usted está dispuesto a usar a un determinado proveedor de alojamiento, vale la pena considerar Google Datastore, Amazon SimpleDB, Windows Azure Storage Services o Force.com. Son tecnologías buenas, pero tenga en cuenta el riesgo potencial de los negocios cerrados.

No puedo hacer juicios sobre la idoneidad de determinados proyectos para fines particulares. Hay varias aplicaciones muy decentes, pero también hay algunas aplicaciones nuevas y muy inestables. Si vas a considerar el uso de alguna de ellas, deberás realizar tu propia investigación:

• Buscar en el sitio web del proyecto una lista de sitios que utilizan la base de datos en producción (y en qué aspecto de su servicio lo utilizan).
• Comprobar si tienen una comunidad de código abierto activa, para el caso que el desarrollador original pierda el interés y deje de mantener el software.
• Tratar de encontrar algún punto de referencia (aunque ten en cuenta que muchos puntos de referencia publicados en la web usan métodos defectuosos y/o anticuados, por lo que si buscas seriedad deberás ejecutar tus propias pruebas, usando datos que coinciden con las características de tu aplicación).

Y como pasa con cualquier tema de moda, hay muchas personas con opiniones fuertes, tanto positivas como negativas, no te dejes influenciar por ellos. Espero haberte dado una visión general de los tipos de cosas que puedes hacer con diferentes tipos de bases de datos para que puedas elegir el más adecuado a tu aplicación.

Fotografía por flickr.com/photos/vermininc

Traducción libre del texto original Should you go Beyond Relational Databases? by Martin Kleppmann