MongoDB es un sistema de bases de datos NoSQL orientado a documentos, a diferencia de MySQL, este no es una base de datos relacional. Es open source, lleva entre nosotros desde el 2009. Está escrito en C++ y tiene intención de aumentar la escalabilidad de un sistema. Es compatible con Linux, OS X, Windows y Solaris.
Además de MongoDB existen otros sistemas NoSQL como por ejemplo Cassandra, CouchDB, Redis, Riak, Membase, Neo4j y HBase.
Considera que mongoDB fue diseñado para ser un motor de búsqueda sobre aplicaciones en la nube, debes de ser bien específico al momento de elegir un sistema NoSQL. Esto porque tienen diferentes funciones o están optimizados para diferentes tareas: Como Cassandra que fue diseñado para búsquedas en Facebook.
Si buscas un framework en PHP para poder utilizar MongoDB inmediatamente puedes probar alguno de los siguientes: CakePHP, Codeigniter, Doctrine, Drupal, Kohana, Lithium, Memcached, Symfony 2, Yii y Zend Framework.
Si buscas utilizarlo con Python prueba con PyMongo.
Conceptos básicos
Una base de datos en MongoDB tiene diferentes conceptos a una base de datos regular como MySQL. Cada registro o unidad básica de datos se le denomina documento. Y cada conjunto de documentos, que formarían una tabla, se le llama colección.
Un documento se podría comprar con el concepto de fila y una colección a una tabla.
Organización y sistema
La ventaja que tiene MongoDB ante las bases de datos racionales es la velocidad de consulta. Esto se logra gracias a que los documentos son almacenados en formato BSON, que es una versión modificada del ya conocido JSON.
BSON pesa un poco más que un JSON regular, pero gracias a que este guarda longitudes de campos, índices de arrays, entre otras cosas, es mucho más rápido (y menos costoso), acceder a la información que se consulta.
Al final del día no vamos a ver el formato BSON, así que no te preocupes, siempre lo leerás como un JSON regular.
Documentos
Los documentos son un conjunto de claves con valores asociados. Sin embargo, cabe destacar que en cada lenguaje es diferente el "output".
Código :
{ "pepito" : "uno" }
Igual cabe destacar que una clave puede contener varios valores asociados como por ejemplo:
Código :
{ "pepito" : "uno", "dos" : 3 }
Notas importantes
- Las claves de un documento son strings.
- No se deben utilizar caracteres como punto y el signo de dólar.
- No deben de comenzar con guión bajo.
- Las claves son sensibles a mayúsculas y minúsculas.
- No debe contener claves duplicadas.
- Cada documento tiene una _id única generada a partir de diversos métodos, así siempre será diferente.
Colecciones
Una colección nos ayuda a organizarnos de manera mucho más fácil y rápida.
Código :
> db.pepito.insert() > db.pepito.find() > db.pepito.drop()
Notas importantes
- Mantener diferentes tipos de documentos en una misma colección es de masoquistas.
- Un string vacío no es un nombre válido, así como no se puede utilizar un string con signo de dolar.
- Es más rápido obtener una lista de documentos que mantengan la misma estructura.
- Siempre planea la estructura de tus colecciones y documentos antes de comenzar.
Manejo de datos desde la shell
Ya que este artículo es únicamente una introducción, no entraré en detalles de cómo instalarlo o utilizarlo con algún lenguaje. Únicamente desde la shell que viene por defecto o desde aquí (haciendo clic en "Try It Out")
Para hacer una inserción y guardarla escribimos lo siguiente para obtener algo parecido a pepito = tontito
Código :
db.pepito.save( { "pepito" : "tontito" } )
Y para imprimir el contenido
Código :
db.pepito.find()
El siguiente script inserta en el documento varios elementos en forma de tags, después usa una función para contar cada elemento con un foreach, separa los elementos y devuelve la cantidad de elementos en otro documento.
Código :
$ ./mongo > db.things.insert( { _id : 1, tags : ['perro', 'gato'] } ); > db.things.insert( { _id : 2, tags : ['gato'] } ); > db.things.insert( { _id : 3, tags : ['raton', 'gato', 'perro'] } ); > db.things.insert( { _id : 4, tags : [] } ); > // función de mapeo > m = function(){ ... this.tags.forEach( ... function(z){ ... emit( z , { count : 1 } ); ... } ... ); ...}; > // función reductora > r = function( key , values ){ ... var total = 0; ... for ( var i=0; i<values.length; i++ ) ... total += values[i].count; ... return { count : total }; ...}; > res = db.things.mapReduce(m, r, { out : "myoutput" } ); > res { "result" : "myoutput", "timeMillis" : 12, "counts" : { "input" : 4, "emit" : 6, "output" : 3 }, "ok" : 1, } > db.myoutput.find() {"_id" : "gato" , "value" : {"count" : 3}} {"_id" : "perro" , "value" : {"count" : 2}} {"_id" : "raton" , "value" : {"count" : 1}} > db.myoutput.drop()
Existen muchos más comandos, todos ellos están en la documentación, con el comando help, documentación o desde la shell de mongodb.org escribiendo tutorial para un rápido pero informativo tutorial.
¿Tienes dudas? Dejame un comentario aquí o sígueme en twitter @kinduff.
En el próximo tutorial les enseñaré como generar bases de datos, leerlas y modificarlas.
Enlaces de interés
- Página principal de mongoDB [link]
- Documentación mongoDB [link]
- Sourcecode + drivers para diferentes lenguajes y sistemas [link]
- NoSQL: If Only It Was That Easy [link]
- Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j [link]
- [NSFW] Relational Database Vs NoSQL Fanbois [link]
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
Por jonasanx el 08 de Abril de 2012
Por jonasanx el 09 de Abril de 2012
Por Freddie el 09 de Abril de 2012
jonasanx :
El motor interno de scripting de MongoDB es Javascript. Aunque eso no significa que no puedas usar MongoDB en cualquier otro lenguaje.
Por NEO_JP el 09 de Abril de 2012
Esto me parece interesante, hay alguna razon real para esto? Recuerdo haber podido usar _user y _tags en mis claves.
Por jonasanx el 09 de Abril de 2012
Freddie :
jonasanx :
El motor interno de scripting de MongoDB es Javascript. Aunque eso no significa que no puedas usar MongoDB en cualquier otro lenguaje.
Estúpido de mi. Entonces puedo usar Coffeescript sin problema.
Por takag el 09 de Abril de 2012
Aún no veo bien cómo pudiera usarlo en un proyecto, pero siempre es bueno estar al tanto de lo que hay.
Ya ando jugando con el mini tutorial que sale en el browser shell de la página de MongoDB
PD: I still love SQL <3
Por alvarogili el 09 de Abril de 2012
Por Jorge el 09 de Abril de 2012
Por NEO_JP el 09 de Abril de 2012
Freddie :
No estoy seguro a que te refieres con esto, en el ejemplo de Kinduff se usa Javascript porque esta mostrandote como usar la consola de MongoDB, ahi no puedes usar nada mas que JS, no CoffeeScript.
Si planeas usarlo con Node.js, eso es distinto, ahi puedes usar Coffee con alguna libreria para conectarte a Mongo y puedes hacer lo que quieras, por ejemplo:
https://github.com/neojp/l4c.me/blob/master/models/tag.coffee
Código :
Por Freddie el 09 de Abril de 2012
takag :
Por Freddie el 09 de Abril de 2012
Jorge-blog :
Por jonasanx el 09 de Abril de 2012
jonasanx :
Freddie :
No estoy seguro a que te refieres con esto, en el ejemplo de Kinduff se usa Javascript porque esta mostrandote como usar la consola de MongoDB, ahi no puedes usar nada mas que JS, no CoffeeScript.
Si planeas usarlo con Node.js, eso es distinto, ahi puedes usar Coffee con alguna libreria para conectarte a Mongo y puedes hacer lo que quieras, por ejemplo:
https://github.com/neojp/l4c.me/blob/master/models/tag.coffee
Código :
Si, fue lo primero que pensé, pero ya estuve leyendo un poco mas y encontré Mongo Mapper y MongoHub y al parecer es todo lo que voy necesitar por el momento para usarlo con Rails.
Por sacrac el 09 de Abril de 2012
aun no soporta base de datos NoSQL Django, python en cambio si usando la libreria pymongo para utilizarlos y puedes utilizar Flask que si soporta mongoDB
saludos
Por edderleonardo el 09 de Abril de 2012
Por JoseAlejandro_Realza el 09 de Abril de 2012
Por lbisaro el 09 de Abril de 2012
Yo actualmente trabajo con php y MySql y estoy con ganas de hacer pruebas con Python y MongoDB como para ir conociendo ambas cosas que para mi son nuevas.
Pero lo que me gustaría comprender es cuando se aconseja utilizar Sql y cuando NoSql ?
Pongo un ejemplo con una estructura de datos como: Cliente, Factura y Lineas de factura
En SQL tengo 3 tablas y para obtener los datos completos de una factura digamos que puedo hacer el siguiente query:
SELECT *
FROM factura
LEFT JOIN cliente ON factura.idcliente = cliente.idcliente
LEFT JOIN linea_de_factura ON linea_de_factura.idfactura = factura.idfactura
Ahora bien, si MongoDB no es relacional, yo debería tener una colección de Clientes, y una de Facturas, y dentro de cada documento de la colección de Facturas debería tener las Lineas de factura? Se me ocurre esto porque los clientes pueden estar relacionados con otras Facturas o con diferentes Colecciones como ser Cuenta Corriente, CRM, etc..., pero las lineas de factura están relacionadas únicamente con una factura especifica.
De ser así, se puede hacer una consulta a la base de datos en la que se incluya o linkee la factura con el cliente, o hay que hacer una consulta a la colección de clientes y la otra a la colección de facturas?
Desde ya te agradezco por compartir tus conocimientos, y te pido disculpas por lo extenso de mi comentario
Leonardo
Por Jorge el 09 de Abril de 2012
Por Jorge el 09 de Abril de 2012
Por NEO_JP el 09 de Abril de 2012
lbisaro :
Siempre puedes crear una relacion artificial, en la que escribes el _id del cliente en la factura y luego puedes crear otro query para obtenerlo, es similar a un JOIN, pero no es por defecto.
Por ejemplo, yo tengo una coleccion para fotos, usuarios y tags. En los documentos de las fotos tengo los datos importantes, una relacion al usuario, porque no tiene sentido estar escribiendo los mismos datos una y otra vez, y otra relacion para los tags.
Como documentos embebidos, tengo comentarios dentro de las fotos, que a su vez tienen una relacion al usuario que lo creo.
Este patron me resulta el mejor y mas flexible hasta ahora, si alguien me da opiniones de como hacerlo mejor en Mongo, bienvenido sea.
Por alvarogili el 09 de Abril de 2012
Por NEO_JP el 09 de Abril de 2012
alvarogili :
Entiendo lo que haces y aunque me parece muy interesante, suena algo lento, no seria mejor crear un preprocesador que convierte todo a json y luego guardarlo tal cual?
Por alvarogili el 09 de Abril de 2012
NEO_JP :
alvarogili :
Entiendo lo que haces y aunque me parece muy interesante, suena algo lento, no seria mejor crear un preprocesador que convierte todo a json y luego guardarlo tal cual?
Si si, exacto, usamos JSon tal cual, pequeño detalle que se me pasó jejeje. Pero mi idea de explicar es que dentro de la BD la estructura del XML se respeta para luego navegarlo.
Por NEO_JP el 09 de Abril de 2012
alvarogili :
Es decir, uds guardan el XML como un string, no? Entiendo, pero siento que seria mas rapido convertirlo a JSON para que puedas navegar el contenido sin usar el DOM.
Por alvarogili el 09 de Abril de 2012
NEO_JP :
alvarogili :
Es decir, uds guardan el XML como un string, no? Entiendo, pero siento que seria mas rapido convertirlo a JSON para que puedas navegar el contenido sin usar el DOM.
No, tal vez me expreso mal, usamos JSon, tomamos el XML lo cargamos en un JSON y eso guardamos.
Lo que traté de explicar antes, es que cuando se quieren manejar XMLS es útil, pero no se si lo es tan útil cuando quieres manejar datos tradicionales, como los de una facturación por ejemplo, que era el ejemplo mencionado antes.
Por NEO_JP el 09 de Abril de 2012
alvarogili :
Ah! Ya veo, entonces suena muy cool.
Por alvarogili el 09 de Abril de 2012
NEO_JP :
alvarogili :
Ah! Ya veo, entonces suena muy cool.
Si, por ahora es cool, somos bastantes nuevos en el tema, veremos cuando hagamos queries grandes si se las aguanta jejejej
Por JAM el 09 de Abril de 2012
Por cadete el 09 de Abril de 2012
"Un documento se podría comprar con el concepto de fila"
Por Kinduff el 09 de Abril de 2012
JAM-blog :
Puedes revisar la documentación para hacer la implementación con java, clic aquí.
Por alvarogili el 09 de Abril de 2012
Por TheCube el 10 de Abril de 2012
Algo que no se menciona en el artículo es que una de las grandes ventajas de MongoDB es que no es transaccional. En realidad también puede ser una desventaja pero eso depende del proyecto.
En mi caso uso MongoDB para una aplicación en tiempo real para ambulancias y en un juego HTML5 que aún está en fase de desarrollo.
MongoDB trabaja muy bien con Node.js y con Socket.io. Es bastante sencillo de usar.
Por Yaraher el 10 de Abril de 2012
Yo he usado una variación de esto para un sitio de ecommerce y funcionó bien.
Como comentario general, una aplicación moderna no tiene por qué usar sólo un sistema de contenedor de datos.
En muchos proyectos uso MySQL que funciona muy bien para elementos de lectura y registro, a la par con Redis para el manejo de data "en caliente" para feeds, muchas escrituras (como logs), etc., y MongoDB para almacenar datos que no necesito relacionar pero es mucho más eficiente mantenerlos anidados (como información de un producto y sus comentarios, fotos y demás incrustados).
La ventaja de separar una arquitectura de la aplicación así, además de ser bastante sencillo de mantener y usar con algo de experiencia (yo en Ruby uso Ohm para Redis y MongoId para MongoDB), tiene la gran ventaja que si algún sistema falla, el resto de la aplicación puede mantenerse activa. Así, un usuario tal vez no podría ver el feed de noticias, pero seguir comprando en una misma aplicación donde la conexión al repositorio de datos ha fallado.
Por leojg el 10 de Abril de 2012
Algun tipo de base de datos NoSQL
Por NEO_JP el 10 de Abril de 2012
TheCube :
Yaraher :
Damn true.
Por cesar el 10 de Abril de 2012
Por alvarogili el 10 de Abril de 2012
cesar-blog :
Este, que está en la lista que puse antes: http://www.mongodb.org/display/DOCS/CSharp+Language+Center
Por cnaucler el 10 de Abril de 2012
Sin embargo, NoSQL es bastante joven y aún hay cosas algo inmaduras que SQL tiene resueltas desde casi sus inicios, como los tipos de relaciones entre tablas, ojo. Y una consulta de unión con joins, subqueries y funciones agregadas, que en SQL puede ser compleja pero entendible, ahora mismo en NoSQL es un infierno, es algo horroroso.
Por otro lado, para XML tenemos XPath, que es un lenguaje de expresiones de consulta potente, simple y elegante. En NoSQL no tenemos nada que llegue a ese nivel ni remotamente, y no estaría de más que lo hicieran algún día.
Finalmente, NoSQL no es un estándar. No hay un ANSI-NoSQL, y las diferencias de filosofía e implementación entre distintos sistemas pueden ser muy amplias. Si trabajas con MySQL y te quieres pasar a PostgreSQL lo puedes hacer con poco esfuerzo. Pero pasar de MongoDB a CouchDB, por poner uno, te puede costar bastante más.
Para mí MongoDB es una maravilla. Sin embargo, estoy esperando a que los fabricantes de sistemas SQL tradicionales implementen el soporte para JSON como más o menos lo están haciendo con el XML. ¿Os imagináis por ejemplo que MySQL soportara de forma nativa un tipo de datos JSON y funciones para hacer consultas sobre su contenido? Ya sé que no sería muy estándar ni portable, y que nos podemos cargar la primera norma formal, pero ¿a que se os ocurren mil aplicaciones y casos de uso para eso?
Por TheCube el 10 de Abril de 2012
Por NEO_JP el 10 de Abril de 2012
TheCube :
Yo creo que estas usando bien cada tecnologia donde corresponde en base a sus fortalezas.
Por Nezsbi_T el 25 de Noviembre de 2012
http://docs.mongodb.org/manual/tutorial/install-mongodb-on-os-x/
Por alvarogili el 26 de Noviembre de 2012
En youtube no hay nada?
Por Nezsbi_T el 26 de Noviembre de 2012
alvarogili :
En youtube no hay nada?
Por Pako el 09 de Octubre de 2014