Introducción al mundo noSQL

NoSQL es la nueva palabra de moda. Una solución pensada para el almacenamiento de gran cantidad de datos para su posterior uso. Esto ya nos suena, una base de datos, pero realmente, ¿cual es la diferencia?

NoSQL es un término usado en informática para agrupar una serie de almacenes de datos no relacionales que no proporcionan garantías ACID. Normalmente no tienen esquemas fijos de tablas ni sentencias "join".Wikipedia

La diferencia ya es clara, no es una base de datos como las que conocemos actualmente, es bastante más peculiar y tira por tierra bastantes de los conceptos y formas de trabajar a los que estamos acostumbrados. Y aunque el termino en si sea nuevo, la teoría tiene sus años, bastantes más que las bases de datos relacionales, pero ahora vuelve con fuerza para salvarnos la vida en algunos casos concretos, evitando problemas de escalabilidad o rendimiento a costa de algo de fiabilidad.

Hasta ahora el cuello de botella siempre ha sido el acceso a los datos y la forma de evitarlo la escalabilidad vertical, esto es, añadiendo más memoria, procesamiento y discos rápidos. Pero todo escalado vertical tiene un límite, y es el que pone nuestro bolsillo y la propia tecnología. Por otro lado, las bases de datos relacionales no suelen tender a escalar bien horizontalmente.

  • Normalización o desnormalización
  • Replicación asíncrona y por lo tanto problemática
  • ¿Cómo distribuyes la carga de escrituras?
  • ¿Transacciones distribuidas? Uff... no!

Es importante tener en cuenta que no es un reemplazo a las bases de datos SQL que llevamos usando desde hace años, si no que un complemento que nos ayudará en casos particulares, por lo tanto tened en mente que noSQL es en realidad no(tOnly)SQL :)

A modo introducción vamos a ver el funcionamiento de MongoDB, una de las que más me han impresionado por su facilidad de uso y rapidez.

MongoDB agrupa los datos documentos (y sub-documentos). Esto es, objetos sin ningún tipo de esquema fijo, como por ejemplo un array de PHP o una tupla de Python. Los datos se guardan en BSON (JSON binario) y permite consultas algo más complejas que algunas otras soluciones NoSQL.

BSON [bee · sahn], short for Binary JSON, is a binary-encoded serialization of JSON-like documents. Like JSON, BSON supports the embedding of documents and arrays with in other documents and arrays. BSON also con­tains extensions that allow representation of data types that are not part of the JSON spec. For example, BSON has a Date type and a BinData type.

Además soporta el uso de índices compuestos, simples o geo-espaciales de dos dimensiones, auto particionado de datos y replicación master-slave entre otras muchas cosas. Importante para los desarrolladores, ¡existe módulo de PHP! ;) No en vano, la gente lo empieza a llamar el MySQL de NoSQL.

Después de esta pequeña introducción vamos a jugar un poco con MongoDB :) Para ello nos bajamos el binario de http://www.mongodb.org/display/DOCS/Downloads La instalación es tan sencilla como descomprimir y lanzar el binario del servidor (mongod):

bin # ./mongod
./mongod --help for help and startup options
Fri May  7 21:16:00 Mongo DB : starting : pid = 307 port = 27017 dbpath = /data/db/ 
master = 0 slave = 0  64-bit 
Fri May  7 21:16:00 db version v1.4.1, pdfile version 4.5
Fri May  7 21:16:00 git version: nogitversion
Fri May  7 21:16:00 sys info: Darwin iMac-Punisher.local 10.3.0 Darwin Kernel Version 10.3.0: Fri 
Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 BOOST_LIB_VERSION=1_42
Fri May  7 21:16:00 waiting for connections on port 27017
Fri May  7 21:16:00 web admin interface listening on port 28017

A primera vista ya vemos datos interesantes. Los datos se van a guardar en la ruta /data/db, que debemos crear con antelación o indicar otra mediante parámetro, y que el puerto de escucha será 27017. Si no le indicamos nada, el demonio se lanzará en foreground y la consola se quedará "bloqueada". Podremos parar el demonio con un simple Control+C.

La consola para empezar a usar mongoDB se llama "mongo", que se encuentra en la misma ruta de binarios que el resto.

bin $ ./mongo
MongoDB shell version: 1.4.1
url: test
connecting to: test
type "help" for help
\> 

Vemos las bases de datos existentes y nos creamos la nuestra propia:

> show dbs
admin
local
\> use midb
switched to db midb

Como veis no es necesario crearla antes de usarla, simplemente dile que la quieres usar y si no existe la creará. Ahora vamos a meter una serie de datos:

\>a = { nombre : "Miguel Angel", apellidos : "Nieto Salazar", edad : "27", localidad : "Barakaldo" }
{
    "nombre" : "Miguel Angel",
    "apellidos" : "Nieto Salazar",
    "edad" : "27",
    "localidad" : "Barakaldo"
}
\>b = { nombre : "Estibaliz", apellidos : "Sanchez", Nacimiento : "Logroño", estudio : "Comercio" } 
{
    "nombre" : "Estibaliz",
    "apellidos" : "Sanchez",
    "Nacimiento" : "Logroño",
    "estudio" : "Comercio"
}
\> db.coll.save(a);
\> db.coll.save(b);

Y como ya dije anteriormente, no existen tablas ni esquemas, añades datos según lo vas necesitando, sin necesidad de seguir un patrón o estando obligado a rellenar unos datos en concreto. Todos estos documentos se guardarán en la colección "coll" dentro de la base de datos midb. Una colección no es más que una agrupación de datos BSON que estos a su vez se pueden agrupar en namespaces. Por ejemplo blog.post y blog.comments son dos colecciones que cuelgan del mismo namespace. Esto es solamente a nivel organizativo para el usuario, internamente no afecta en nada.

Una vez que tenemos los datos introducidos, podemos hacer consultas:

\> db.coll.find({edad:"27"});
{ "_id" : ObjectId("4be029e11967ab80a305e1f0"), "nombre" : "Miguel Angel", "apellidos" : "Nieto
Salazar", "edad" : "27", "localidad" : "Barakaldo" }
\> db.coll.find({Nacimiento:"Logroño"});
{ "_id" : ObjectId("4be029e41967ab80a305e1f1"), "nombre" : "Estibaliz", "apellidos" : "Sanchez", 
"Nacimiento" : "Logroño", "estudio" : "Comercio" }

Facil, sencillo y para toda la familia. Cuando lo ves así piensas, "esto es lo lógico, el almacenamiento de datos tendría que ser así siempre" :)

También podemos almacenar datos binarios, esto es, ficheros. Puedes olvidarte de todo lo que has sufrido con los tipos BLOB en otras bases de datos. MongoDB guarda los ficheros en la base de datos haciendo uso de las especificaciones GridFS. BSON solo permite almacenar datos de hasta 4 megas, para saltarnos esta limitación GirdFS divide de forma transparente los ficheros en grupos de documentos (lo cual también nos permitira buscar por rangos de bytes).

Listamos el contenido, de momento no hay ningún fichero:

$ mongofiles list
connected to: 127.0.0.1

Añadimos un fichero, en este caso un documento PDF:

$ mongofiles put /Users/punisher/Documents/High\ Performance\ MySQL\ Second\ Edition.pdf 
connected to: 127.0.0.1
added file: { _id: ObjId(4be46d25a409d73217ca227b), filename: "/Users/punisher/Documents/High
Performance MySQL Second Edition.pdf", length: 5904835, chunkSize: 262144, uploadDate: new 
Date(1273261349209), md5: "082f8333d45d1e3b7bce6323d0da59f0" }
done!

Listamos de nuevo:

$ mongoflist
connected to: 127.0.0.1
/Users/punisher/Documents/High Performance MySQL Second Edition.pdf 5904835

Lo sacamos de la base de datos a nuestro sistema de ficheros:

$ mongofiles get "/Users/punisher/Documents/High Performance MySQL Second Edition.pdf"
connected to: 127.0.0.1
done write to: /Users/punisher/Documents/High Performance MySQL Second Edition.pdf

No lo voy a negar, estoy enamorado de mongoDB y del concepto noSQL. Olvídate de las relaciones, de optimizar queries, normalizar tablas... dedicate a lo que importa, guardar y sacar datos. Una revolución para los que nos guiamos por la filosofía KISS (Keep it simple, stupid)


Comments

  1. Gracias por tu blog Miguel! Yo estoy desarrallando un motor de búsqueda que será utilizado en China, para un sitio que tiene que tiene mas de 1 millon de impresiones diarias, por lo tanto estoy usando Mongo con colas (queue) para registrar los accesos de los visitantes. En estas colas guardo la info, y cada 1 minuto la vulco a la DB de mi servidor. Ahora mi pregunta es la siguiente... Que pasa si el sistema se cae antes de que pase ese minuto? obviamente la información se pierde! Tambien podemos hacerlo cada 10 segundos. Pero el desafio esta en encontrar una forma de volcar los datos a la base de datos sin perderlos en el camino! Tengo terror de hacer una conexion persiste y registrar directo contra la table, auque sean solo inserts.... por eso los guardo en una cola... Alguna idea? Gracias! Sebastian Perez Lacon - perezlacon@gmail.com

    Sebastian Perez Lacon on
  2. No se mucho de MongoDB, pero he leido que en la última versión han sacado una característica llamada journaling que trae la D de ACID a MongoDB (Durable). Si necesitas que tus datos no se pierdan quizás deberías mirar la documentación de dicha opción o si no tirar por una base de datos convencional como PostgreSQL o MySQL.

    Miguel Angel Nieto on
  3. Simplemente esplendido, Gracias por el post em va ser de mucha ayuda.

    Antrax on