Siguiendo con la serie de artículos sobre BBDD NoSQL, hoy vamos a ver los tipos de estás que hay. Para realizar la clasificación nos basaremos, como suelen hacer todas las clasificaciones que podemos encontrar en Internet, en el modo en que las distintas BBDD almacenan la información.

Cabe decir, antes de empezar, que aunque encontraréis listados de clasificaciones muy extensas y con muchos tipos, principalmente hay cuatro tipos. Estos cuatro tipos son los más extendidos y los que más se utilizan a día de hoy. El resto de tipos, parecen más extensiones, pequeñas modificaciones o adaptaciones a entornos concretos que tipos en si. Así que por esta razón solo nos vamos a centrar en describir estos cuatro tipos. Si queréis un listado más completo podéis echarle un ojo por ejemplo a la página “nosql-database” donde veréis hasta once tipos, y una pequeña descripción de BBDD asociadas a cada uno de los tipos.

Clave-valor (Key-Value)

Por hacer una similitud fácil de entender para desarrolladores, seguirían el mismo modo de almacenar información que utiliza un HashMap. Es decir, asocian a una clave a un valor.

Como ejemplo, nosotros hemos visto Redis en las mini demos que hicimos en los primeros artículos de esta serie.

Familia de columnas (Wide Column Store/Column Family)

Este tipo sigue un modelo de familia de columnas, es decir, es un modelo tabular donde cada fila puede tener una configuración diferente de columnas. En este modelo, cada clave está asociada a uno o varios atributos.

Este tipo de BBDD se consideran buenas para realizar tareas de MapReduce, alta disponibilidad y gestión de tamaño.

Como ejemplo, nosotros hemos visto Cassandra en las mini demos que hicimos en los primeros artículos de esta serie.

Documentos (Document Store)

Este tipo sique un modelo de datos que consiste en almacenar colecciones de datos (documentos) que a su vez contienen colecciones de claves-valor.

Este tipo de BBDD se consideran buenas para el desarrollo rápido, implementación de operaciones de CRUD, lo cual las hace útiles para entornos web, y además son amigables de cara al desarrollador porque permiten un modelado natural de los datos, es decir, un modelo de datos muy cercano a la realidad.

Como ejemplo de estas, en nuestras pequeñas demos nosotros hemos visto MongoDB.

Grafos (Graph Databases)

Este tipo de BBDD se basan en las teorías de grafos. El modelo de datos que siguen son diferentes nodos relacionados entre si a través de pares clave-valor.

A pesar de estar incluidos en la categoría de BBDD NoSQL, no cumple exactamente con las propiedades que CAE (Cost-efficiency, High Availability and Elasticity) que aplican en este tipo de BBDD.

De este tipo no hemos visto ninguna en nuestras mini demos, ya que yo personalmente no he utilizado ninguna, y solo las conocía de oídas, pero como ejemplo diremos Neo4J, que es la única que me suena el nombre. Si queréis alguno más, os remito al enlace que he puesto al inicio de este post.

En principio, la serie de post sobre NoSQL estaba pensada para terminar aquí, pero por motivos que ahora no vienen mucho al caso y si tengo tiempo, me estoy planteando hacer uno artículo más sobre recomendaciones de seguridad para entornos NoSQL. Pero este de llegar será sorpresa, ya que doy la serie por terminada aquí. Nos vemos.

Antes de entrar en profundidad en la parte más teórica sobre bases de datos NoSQL, vamos a recordar que existen otros tipos de bases de datos.

En primer lugar las BBDD relacionales que yo diría que son las más utilizadas hoy en día. Este tipo de BBDD son con las que, si os dedicáis al mundo del desarrollo, ya habréis trabajado. Un ejemplo de este tipo de BBDD son Oracle o MySQL. Estas BBDD basan su funcionamiento en un modelo relacional que permite establecer relaciones entre los datos alojados en las diferentes tablas. Estas BBDD se componen de tablas con campos definidos a la hora de la creación de la tabla, y utilizan claves primarias o ajenas para las relaciones. Además, poseen un lenguaje relacional para la manipulación de la información. Uno de los lenguajes relacionales más extendido es SQL.

Luego, aunque menos utilizadas o menos conocidas, están:

• Jerárquicas: Donde la información se almacena en forma de nodos de un árbol
• Transaccionales: Muy poco usadas, se centrar en el envío y recepción de grandes cantidades de datos, en ellas no importa la duplicidad de datos, sino que las operaciones se hagan a la mayor velocidad posible.

En algunos sitios hacen más separaciones y añaden más tipos, pero no creo que sea necesario entrar más en detalle aquí ya que el artículo no trata e BBDD en general, sino de BBDD NoSQL.

Ahora bien, ¿por qué las BBDD NoSQL? ¿De donde nace la necesidad de un nuevo paradigma para BBDD? Hasta hoy el mundo, en mayor o menor medida, a funcionado muy bien con BBDD relacionales, estas son las más utilizadas y nos ofrecen multitud de herramientas para trabajar con ellas y asegurar que todas las operaciones han ido correctamente o advertirnos de que han fallado para que podamos poner remedio o tomar medidas en consecuencia.

Entonces, ¿de donde ha salido todo esto? Pues bien la respuesta corta es de Internet. La respuesta larga, sería la proliferación y expansión de Internet que ha hecho que hoy en día haya compañías que exclusivamente tienen sus negocios en la nube, y que poseen millones y millones de usuarios que generan billones y billones de datos e información que necesita ser procesada. Véase como ejemplo Google, Facebook, Amazon, Twitter o simplemente cualquier startup que tenga éxito en Internet. Todas estas compañías tiene una necesidad de procesamiento de datos que una BBDD relacional no puede aportar o al menos no lo puede hacer de una forma sencilla. En el caso de estás compañías necesitan realizar un tratamiento de cantidades ingentes de datos en tiempo real y a una velocidad que no les permitían las BBDD relacionales. En este caso, la mayoría de las BBDD NoSQL están altamente optimizadas para el almacenamiento y recuperación de datos.

Como supongo que ya habréis ido perfilando a partir de las lineas anteriores las BBDD NoSQL se caracterizan por:

• Ausencia de esquema: Los datos no se definen con una estructura de atributos fija, o lo que viene siendo lo mismo, cada registro o documento almacenado en una tabla puede contener diferente información según su necesidad.
• Escalabilidad: Cada vez más usuarios, cada vez más información a procesar, si algo está claro es que la infraestructura inicial ha tenido que ir creciendo a la vez que estás dos cosas lo hacían. Las BBDD NoSQL tienen mecanismos para facilitar la escalabilidad horizontal (mucho más fácil y barata que la vertical) haciendo así posible aumentar el número de nodos de que disponemos para procesar la información según aumenten nuestras necesidades. Dos de estos mecanismos son Map-Reduce y Sharding, que veremos más adelante o quizás en una serie dedicada a Big Data y Web Intelligence (está por decidir aún).
• Velocidad: Como ya hemos dicho, mucha de esta información es procesada en tiempo real, con lo cual una de las cosas más importante es la velocidad, velocidad que nos aporta este tipo de BBDD. Muchas de estas BBDD incluso almacenan información únicamente en memoria y simplemente la vuelcan cada cierto tiempo en el disco duro, dandonos unas tasas de velocidad inimaginables para una BBDD relacional.

Con todo esto, tenemos unas BBDD capaces de manejar enormes cantidades de información, que podemos escalar fácilmente ejecutándolas en clusters de servidores de PCs baratos y que además, no tienen problemas de rendimiento ni cuellos de botellas como las BBDD relacionales.

Entonces, ¿estamos antes la BBDD definitiva? Aquella que va a desplazar y a hacer desaparecer las BBDD relacionales. Ni muchísimo menos. Como hemos podido observar a lo largo del artículo, este tipo de BBDD se crearon para resolver un tipo de necesidades muy específicas, pero para poder enfrentarse a estas necesidades, hubo que dejar de lado otras cosas que nos aportan las BBDD relacionales.

Este tipo de BBDD no permite sin ayuda externa el control de transacciones de datos únicos, la información es más volátil que en sistemas relacionales, no permite la realización de operaciones complejas entre tablas como el producto cartesiano (JOIN). En definitiva, sacrifican algo de fiabilidad y operatividad en beneficio de la velocidad. Por poner un ejemplo para que se vea esto claramente, imaginemos un banco, que al día tiene cientos de transferencias de dinero, para un banco la velocidad no es necesaria, recordemos que las transferencias suelen tardar entre uno y dos días, pero perder una sola de estas transferencias sería un gran problema. El banco necesita un sistema relacional, con sus transacciones, con su control de errores y con su persistencia de datos.

Como siempre, hay que decidir las herramientas que vamos a utilizar en función de las necesidades concretas de nuestro proyecto y no porque algo esté de moda o parezca muy bueno. Puede ser lo mejor, pero no para nuestro escenario.

Hasta aquí hemos llegado por hoy, en el próximo artículo de la serie veremos los tipos de BBDD NoSQL que existen y como trabajan. Nos vemos.

La tercer de las demos que vamos a realizar en esta serie de artículos y la última antes de empezar con la parte más teórica, es la de Redis. Podéis encontrar la página del proyecto en este enlace. Redi es una base de datos de “clave-valor”, como en las ocasiones anteriores, ya veremos que es esto más adelante. Como dato curioso, parece ser que analizando el conjunto de habilidades de muestra la red social profesional de Linkedin, parece ser que Redis es la segunda base de datos NoSQL que más sale por detrás de MongoDB. No se si creérmelo o no, pero hay está el dato. He visto algunas otras gráficas y suele ser la cuarta o quinta, lo que me parece más acorde con la idea predefinida que tenía yo antes de empezar a investigar sobre NoSQL. Como todo, si uno busca lo suficiente, es capaz de encontrar análisis que apoyen casi cualquier cosa.

Instalando Redit

Al igual que en las dos demos anteriores, yo estoy trabajando sobre un Windows 7, y para mi desilusión, los únicos instalables para este sistema (win32/win64) que he encontrado en la página del proyecto Redis parecen no oficiales,  siendo los instalables de la versión oficial solo para sistemas Linux (supongo que Unix también). Así que, aquí me he enfrentado a dos opciones, o instalar una máquina virtual para desplegar la base de datos o intentarlo con algún sistema tipo cygwin o similar (Nota: No se así funcionará, es solo una idea). Yo por mi parte como tengo varias máquinas virtuales ya montadas y en ejecución, me he inclinado por la primera opción. Vosotros elegid con la que más cómodos os sintáis.

Tras tener clara la opción elegida, lo único que tenemos que hacer es descargar de la página del proyecto la última versión estable de Redis que deberemos compilar siguiendo las siguientes instrucciones (figuran en la página del proyecto):

promt> tar –xzf redis-x.x.x.tar.gz

promt> cd redis-x.x.x

promt> make

Con esto compilaremos el código fuente y obtendremos los ejecutables que nos permitirán empezar a trabajar con Redis (estarán alojados en src). Al igual que pasó anteriormente con Cassandra, no he visto en la página del proyecto ninguna referencia a un interfaz de administración web, es más, leyendo la documentación da la impresión de que todas las tareas de administración se realizan bajo consola. Además, en este caso, no conozco ninguna interfaz web de terceros que podamos instalar y utilizar. Por este tipo de cosas, es por lo que me cuesta un poco creer que en Linkedin sea la segunda clasificada.

Una vez compilados los ficheros fuentes vamos a probar la base de datos a ver si la hacemos funcionar. Para ello solo tenemos que ejecutar el servidor, el cliente y tratar de insertar algún dato en la base de datos.

promt> src/redis-server

El resultado tras la ejecución será algo así:

0 clients connected (0 slaves), xxxxxxxx bytes in use

Luego accedemos al cliente, el cual nos mostrará el promt de Redis, y ejecutamos una inserción y una consulta:

promt> src/redis-cli

redis-promt> set firstvar “Hello World!”

redis-promt> get firstvar

Si hasta aquí todo ha ido bien, vamos a pasar a implementar nuestra primera clase Java.

Conectando desde Java

Al igual que el otro día vamos a crear una nueva clase Java para realizar nuestra implementación y después a añadir la librería que nos permitirá conectar, algo así como el Driver. En este caso, en la propio página del proyecto, el la sección de Clients, tenemos una gran cantidad de clientes en muchísimos lenguajes (quizás por esto sea la segunda en Linkedin). En concreto, para Java hay cuatro diferentes, yo he decidido coger el de Jedis, entre otras cosas, porque parece el recomendado por la propia página del proyecto (tiene la estrellita al lado). No tenemos más que descargarlo y añadirlo a nuestro proyecto como hemos hecho las veces anteriores. Tras esto, solo restará incluir nuestro código.

public static void main(String[] args) {
Jedis jedis = new Jedis("mytestserver");
jedis.connect();
// Store value
jedis.set("hellovar", "Hello World!");
// Recover and print value
System.out.println(jedis.get("hellovar"));
}

El código como podéis ver es el más simple de todos hasta ahora.

Tras su ejecución veremos el siguiente resultado:

Hello World!

Fácil, ¿no? Como podéis ver este tipo de clave valor, es el más simple e intuitivo de todos.

Bueno, hasta aquí hemos llegado con las demos previas a la teoría. Después de la teoría ya haremos algunos ejemplos más complejos y hablaremos un poco de como administrar las bases de datos, desplegar varias y demás. Id cogiendo fuerzas para la parte teórica. Nos vemos.

La segunda de las demos que vamos a realizar en esta serie de artículos es la de Cassandra DB. Podéis encontrar la página del proyecto en este enlace. Cassandra DB es una base de datos hibrida entre una de “clave-valor” y una “orientada a fila”, ya veremos que es esto más adelante. De momento, no nos preocupemos. Como dato curioso comentar simplemente que, aunque ahora es un proyecto de Apache, el inicio de este desarrollo lo realizo Facebook, si los mismos de la red social.

Instalando Cassandra DB

Lo primero que tenemos que hacer es ir a la página del proyecto y descargarnos la última versión que en el momento de escribir este artículo es la 1.1.4. El fichero comprimido que nos descargamos contiene todo lo necesario para trabajar con Cassandra, en este caso no hace falta descargarse ningún Driver aparte. De nuevo, decir que estoy haciendo esto sobre Windows 7 y no sobre Linux, aunque espero que al igual que en la demo anterior, los procesos no sean muy diferentes y no tengáis problemas para seguir la demo. He mirado el directorio de ejecutables de Cassandra y los ficheros de configuración vienen preparados para Linux también.

En este caso, como ya he comentado no hay Driver de conexión propiamente dicho en la página web para descargar, o al menos yo no lo he visto. La ventaja de estar haciendo esto en Java es que Cassandra está desarrollado sobre Java, con lo cual solo vamos a necesitar las librerías que vienen en el fichero que hemos descargado. Para el resto de lenguajes, ahora mismo no tengo ni idea, de nuevo si alguien lo esta haciendo en un lenguaje distinto a Java y se anima a mandar la contribución, esta será publicada tras una breve revisión. Como único dato importante que puedo aportar sobre esto, os dejo el enlace a una de las páginas del Wiki oficial del proyecto con ejemplo de diferentes lenguajes.

Una vez descargado el fichero con la base de datos, solo tendréis que descomprimirlo donde deseéis y ya tendréis instalada la bases de datos Cassandra. En este caso, al igual que en el anterior, el directorio que había dentro del zip, lleva todos los ejecutables necesarios para poder trabajar con Cassandra. Además, tiene un directorio con ficheros de configuración y uno con las librerías.

Así que, lo primero de todo como siempre, vamos a probar la base de datos a ver si conseguimos arrancarla y verla funcionando. Lo primero que tendremos que hacer es definir dos variables globales en nuestro sistema.

• JAVA_HOME: Ruta donde se aloja nuestra instalación de Java.
• CASSANDRA_HOME: Ruta donde tendremos alojada la instalación de Cassandra.

Al contrario que con MongoDB que solo era una sugerencia aquí es obligatorio definirlas ya que los scripts de arranque chequean si están definidas o no. En el caso de JAVA_HOME, si no está definida nos mostrará un error, pero en el caso de CASSANDRA_HOME, tiene una definida por defecto.

Tras esto simplemente nos dirigimos a la ruta donde hayamos puesto nuestro directorio Cassandra y entramos en el directorio bin para ejecutar la base de datos.

promt> cd %CASSANDRA_HOME%\bin

promt> cassandra.bat

Con esto obtendremos un mensaje similar a este, lo que nos confirmará que el arranque ha ido bien:

Listening for thrift clients…

Ahora vamos a tratar de conectar a la base de datos con el cliente que está en la misma ruta

promt> cassandra-cli.bat

Esto ejecutará un cliente de conexión para acceder a Cassandra, en el promt que nos aparece tenemos a nuestra disposición la instrucción help que nos mostrará diferentes opciones, en nuestro caso vamos a utilizar la de connect. Remarcar que las instrucciones se ejecutan con un punto y coma al final (ej. help;) si no el promt no reaccionará al texto que hayamos introducido. Para conectar a nuestro servidor Cassandra, vamos a ejecutar la siguiente instrucción:

promt> connect localhost/9160;

Que nos mostrará algo similar a:

Connected to: “Test Cluster” on localhost/9160

En este punto os animo a que juguéis un poco con los comandos disponibles, al menos echadle un ojo a los show y daros cuenta de los create existentes.

No he encontrado, quizás la haya pero lo desconozco, que Cassandra venga con una consola de administración web como lo hacía, por ejemplo, MongoDB. Lo que si sé que hay es un proyecto alojado en Google Code con un proyecto de interfaz web. Os dejo aquí el enlace por si queréis probarlo: CassUI.

Previamente a empezar a escribir el código Java, vamos a crear nuestro esquema (keyspace) en la base de datos y nuestra tabla (column family). Para ello en el promt escribiremos lo siguiente:

promt> create keyspace helloks;

promt> use helloks;

promt> create column family hcolumn;

Conectando desde Java

Para empezar, de nuevo, lo primero que tendremos que hacer es crear un proyecto Java básico, también podéis utilizar el mismo proyecto que creamos para la demo de MongoDB, simplemente cread una clase nueva y ya está.

Del mismo modo que lo hicimos para añadir el Driver en MondoDB, aquí tendremos que añadir las librerías de Cassandra a nuestro proyecto. Dichas librerías están en el directorio de Cassandra en lib (%CASSANDRA_HOME%\lib). Las librarías a añadir serán:

• apache-cassandra-thrift-x.x.x.jar
• libthrift-x.x.x.jar
• sl4j-api-x.x.x.jar

Tras esto escribiremos el código de nuestro primer ejemplo. En este caso el código lo vamos a coger del wiki mencionado anteriormente ya que está bastante bien, y solo tendremos que hacerle unos pequeños cambios para adaptarlos a nuestra bases de datos:

public static void main(String[] args) throws TException,
InvalidRequestException, UnavailableException,
UnsupportedEncodingException, NotFoundException, TimedOutException {
TTransport tr = new TFramedTransport(new TSocket("localhost", 9160));
TProtocol proto = new TBinaryProtocol(tr);
Cassandra.Client client = new Cassandra.Client(proto);
tr.open();

String key_user_id = "1";

// insert data
long timestamp = System.currentTimeMillis();
client.set_keyspace("helloks");
ColumnParent parent = new ColumnParent("hcolumn");

Column nameColumn = new Column(toByteBuffer("name"));
nameColumn.setValue(toByteBuffer("svoboda"));
nameColumn.setTimestamp(timestamp);
client.insert(toByteBuffer(key_user_id), parent, nameColumn,
ConsistencyLevel.ONE);

Column ageColumn = new Column(toByteBuffer("age"));
ageColumn.setValue(toByteBuffer("99"));
ageColumn.setTimestamp(timestamp);
client.insert(toByteBuffer(key_user_id), parent, ageColumn,
ConsistencyLevel.ONE);

ColumnPath path = new ColumnPath("hcolumn");

// read single column
path.setColumn(toByteBuffer("name"));
System.out.println(client.get(toByteBuffer(key_user_id), path,
ConsistencyLevel.ONE));

// read entire row
SlicePredicate predicate = new SlicePredicate();
SliceRange sliceRange = new SliceRange(toByteBuffer(""),
toByteBuffer(""), false, 10);
predicate.setSlice_range(sliceRange);

List<ColumnOrSuperColumn> results = client.get_slice(
toByteBuffer(key_user_id), parent, predicate,
ConsistencyLevel.ONE);
for (ColumnOrSuperColumn result : results) {
Column column = result.column;
System.out.println(toString(column.name) + " -> "
+ toString(column.value));
}

tr.close();
}

public static ByteBuffer toByteBuffer(String value)
throws UnsupportedEncodingException {
return ByteBuffer.wrap(value.getBytes("UTF-8"));
}

public static String toString(ByteBuffer buffer)
throws UnsupportedEncodingException {
byte[] bytes = new byte[buffer.remaining()];
buffer.get(bytes);
return new String(bytes, "UTF-8");
}

Tras ejecutar este pequeño programita, veremos el siguiente resultado:

ColumnOrSuperColumn(column:Column(name:80 01 00 02 00 00 00 03 67 65 74 00 00 00 04 0C 00 00 0C 00 01 0B 00 01 00 00 00 04 6E 61 6D 65, value:80 01 00 02 00 00 00 03 67 65 74 00 00 00 04 0C 00 00 0C 00 01 0B 00 01 00 00 00 04 6E 61 6D 65 0B 00 02 00 00 00 07 73 76 6F 62 6F 64 61, timestamp:1346925753115))
age -> 99
name -> svoboda

Como podéis ver, aunque quizás el resultado obtenido tras la ejecución al leer la columna completa y mostrarla no es muy intuitivo, el manejo de la base de datos y el acceso de almacenamiento y lectura de los datos concretos si lo es, y además, muy fácil. Espero que hayáis conseguido llegar hasta aquí con éxito y que os haya servido para familiarizaros con Cassandra. Nos vemos.

La primera de las demos que vamos a realizar en esta serie de artículos es la de MongoDB. Podéis encontrar la página del proyecto en este enlace. MongoDB es una base de datos orientada a documentos. ¿Qué es esto? Pues bien, como dijimos, ya iremos explicando este tipo de términos en el apartado de teoría, id apuntando todas las dudas y al final, veremos si están todas las preguntas respondidas o no (dadme un voto de confianza sobre la metodología de aprendizaje expuesta en esta serie de artículos y al final la discutimos).

Instalando MongoDB

Lo primero que tenemos que hacer es ir a la página del proyecto y descargar dos cosas. La primera de ellas es la base de datos MongoDB en si, sus ejecutables para nuestro sistema. Decir que está vez, estoy haciendo esto sobre Windows 7 y no sobre Linux, pero las diferencias entre una y otra instalación, salvando las distancias, son mínimas.

Lo segundo que tenemos que descargar aunque no vamos a utilizarlo inmediatamente, es el driver para realizar la conexión de base de datos. En este caso, obviamente, descargaremos el de Java si vais a seguir los pasos de las demos que yo voy a realizar. Si algún desarrollador de otro lenguaje está siguiendo las demos, pero implementándolas en otro lenguaje, tendrá que descargar la que corresponda. Si alguno de los que está intentando hacerlo con otro lenguaje se anima con que me envíe el documento con los pasos para la demo terminada la publicaré con mucho gusto tras una pequeña revisión.

Una vez descargado el fichero de bases de datos, solo tendréis que descomprimirlo donde deseéis y ya tendréis instalada la bases de datos MongoDB. En este caso, el directorio que había dentro del zip, lleva todos los ejecutables necesarios para poder trabajar con MongoDB.

Como nunca deberíamos fiamos de nada que no hayamos probado, vamos a ello. Para ello abriremos una consola y nos iremos a la ruta donde estén los ejecutables de MongoDB. Un paso previo interesante suele ser añadir una variable de entorno al sistema para llegar rápidamente o incluso añadir la ruta al path del sistema, algo del estilo de MONGODB_HOME.

Tras llegar a la ruta correcta con un simple listado de ficheros, veremos varios ejecutable con unos nombres bastante claros para hacernos una idea de la tarea que desempeña cada uno de ellos. En nuestro caso, el primero que nos interesa es “mongod.exe”. Este será el encargado de lanzar el demonio con la base de datos que se quedará a la escucha de peticiones. Antes de lanzarlo, simplemente comentar que tiene un argumento “--dbpath” que será el directorio donde almacenará nuestras bases de datos. Por defecto, la ruta será “C:\data\db”, pero podemos especificar cualquier otra a través de dicho argumento. Algo muy importante es que, sea la ruta que sea, la por defecto o una especificada por nosotros, la vemos a tener que crear previamente a mano, MongoDB no lo hará por nosotros. Así de esta formar para la primera ejecución haremos algo de este estilo:

cd <path_mongoDB>\bin

mongod --dbpath “<path_to_store_db>”

Con esto obtendremos un mensaje similar a este, lo que nos confirmará que el arranque ha ido bien:

[websvr] admin web console waiting for connections on port 28017

Tras esto, también podremos comprobar desde el navegador que se ha ejecutado correctamente accediendo a la ruta:

localhost:28017 (Adaptadla según el servidor donde estéis probando)

Para conecta a MongoDB desde la consola bastará ejecutar en esta el comando “mongo test” para conectar a la base de datos “test” que se crea inicialmente.

Conectando desde Java

Para empezar, lo primero que tendremos que hacer es crear un proyecto Java. Un proyecto básico, lo podéis crear desde Eclipse, con maven, como os de la gana, no deberíais tener ningún problema. Si alguien lo crea con maven, que se acuerde añadir al pom.xml la dependencia correspondiente.

Lo segundo que deberemos hacer es añadir el Driver de conexión a la base de datos, el cual además, nos permitirá tener autocompletado a la hora de escribir el código. Aquí ya que cada uno utilice el método que más le guste, yo personalmente, he seguido los siguientes pasos:

1. Crear un directorio “lib” en el proyecto.
2. Copiar el .jar correspondiente al Driver en el directorio.
3. Click con el botón derecho sobre el proyecto e ir a:  Build Path -> Configure Build Path…
4. En la pestaña Libraries necesitamos añadir un nuevo jar que será el de nuestro Driver.

A partir de aquí, solo tenemos que escribir el código correspondiente a nuestro primer ejemplo:

public static void main(String[] args) {
try {
// Remember 28017 is web admin console
Mongo conn = new Mongo("localhost", 27017);
// if db doesn't exist, mongodb will create it
DB db = conn.getDB("helloDB");
// if collection doesn't exist, mongodb will create it
DBCollection coll = db.getCollection("helloCollection");
// Create document
BasicDBObject doc = new BasicDBObject();
doc.put("id", 1001);
doc.put("message", "Hello World!");
// Store
coll.insert(doc);
// Search document in db
BasicDBObject query = new BasicDBObject();
query.put("id", 1001);
// Launch query
DBCursor cursor = coll.find(query);
// Show records
while (cursor.hasNext()) {
System.out.println(cursor.next());
}
} catch (UnknownHostException e) {
e.printStackTrace();
} catch (MongoException  e) {
e.printStackTrace();
}
}

Tras ejecutar este pequeño programita, varemos el siguiente resultado:

{ "_id" : { "$oid" : "50472f062b9d17af147c97d1"} , "id" : 1001 , "message" : "Hello World!"}

Vamos a añadir un par de líneas más porque para el siguiente documento quiero tener un par de propiedades adicionales:

doc.put("id", 1002);
doc.put("title", "helloWorld");
oc.put("message", "Hello World!");
doc.put("language", "en");

Y tras volver a ejecutar obtenemos el siguiente resultado:

{ "_id" : { "$oid" : "50472f062b9d17af147c97d1"} , "id" : 1001 , "message" : "Hello World!"}
{ "_id" : { "$oid" : "50472f902b9dd6981ebb68d6"} , "id" : 1001 , "title" : "helloWorld" , "message" : "Hello World!" , "language" : "en"}

¿No habéis observado nada extraño? Hemos podido añadir en la misma colección documentos con diferentes propiedades y la base de datos no se a quejado ni nada, cosa que jamás podríamos hacer en una tabla de base de datos. Además, si os dais cuenta, no hemos necesitado hacer ninguna definición de estructura ni tablas ni nada similar.

Bueno, hasta aquí la primera de las demos. Espero que no hayáis tenido ningún problema para seguirla. Si tenéis alguna duda preguntad. Nos vemos.

Hola a todos de nuevo. A partir de hoy, vamos a introducirnos de nuevo en el mundo del desarrollo, y más específicamente vamos a introducirnos en el mundo de las bases de datos NoSQL. En principio, mi idea es realizar a partir de hoy y en adelante una serie de artículos sobre NoSQL. La idea es realizar unas pequeñas demos con diferentes bases de datos NoSQL, una con cada tipo (Wide Column store / Column families, Document Store, Key Value / Tupla Store, quizás alguno más) y luego una serie de artículos entrando más en profundidad a explicar lo que son este tipo de bases de datos, utilidades a día de hoy y algunas curiosidades.

Seguro que más de uno, ya se está preguntando porque no hago todo esto al revés, primero la teoría y luego las demos. Sinceramente, creo que este método de primero la teoría y luego la práctica no siempre es bueno, y sobre todo, si ya se poseen conocimientos de antemano sobre la práctica puede hacer que no se preste suficiente atención a la teoría. Voy a intentar explicar esto, porque me lo acabo de releer y así del tirón suena algo raro. Parto de la idea de que muchos de los lectores (entre los que me incluyo), ya tenéis tanto conocimientos como desarrolladores como conocimientos en Java y, que muchos de vosotros, ya habréis trabajado con bases de datos relacionales y montado entornos con este tipo de bases de datos. A partir de estos conocimientos que ya poseemos, montar diferentes entornos y hacer una pequeña demo, debería ser bastante trivial. Sin embargo, si que las demos nos van a servir para ver el acercamiento que hace este paradigma al mundo de las bases de datos, alguno de los tipos de bases de datos NoSQL que hay y como realizan cada uno de ellos el manejo de datos, con lo cual, a la hora de ver la teoría nuestra mente ya estará un poco más abierta y probablemente tengamos dos o tres preguntas en mente que de haberlo hecho en el orden “normal” (véase teoría, práctica) no tendríamos.

Si no poseéis conocimientos sobre Java, no es ningún problema ya que un lenguaje es solo un lenguaje y aquí lo importante es el paradigma. Si no sois desarrolladores, quizás la parte práctica no os aporte demasiado, pero espero que la parte teórica os sirva como introducción y base para continuar investigando. De todas formas, que nadie se preocupe, porque como siempre, vamos a intentar hacerlo simple, fácil y entendible, vamos, como se suele decir “para todos los públicos”. De hecho, si alguno se dedica al campo de la seguridad y se ve capaz de escribir algún artículo sobre seguridad en bases de datos NoSQL será bienvenida la colaboración. Personalmente, yo a día de hoy, no he metido la cabeza en este campo aún, todo llegará. Nos vemos.