Raticos tecnológicos

Conceptos básicos de Ruby

2012-01-11T23:25:00.001+01:00

En el presente post vamos a tomar un barniz del lenguaje de programación Ruby. Para ello, se presupone que el lector ya tiene instalado Ruby en su equipo (Descarga de Ruby). Recomiendo leer mi post anterior (Primera toma de contacto con Ruby), el cual da unas nociones preliminares, y que seguro será útil para el lector.

Para entender los conceptos claramente, lo mejor es ilustrarlo con un ejemplo muy sencillo:

La línea 1 es un comentario. No ejecuta nada. Es un texto que sirve para aclarar qué se va a hacer. El comentario abarca desde que aparece el símbolo pragma (#), hasta el final de la línea.

La línea 2 (print('Escribe tu nombre: '), visualiza en pantalla el texto encerrado entre las comillas, sin realizar un retorno de carro (línea siguiente). Da igual utilizar comillas simples o dobles.

La línea 3 declara una variable (nombre), a la cual se le asigna (mediante el símbolo de "igual") la expresión que hay a la derecha, en este caso, la función gets, la cual captura mediante teclado una cadena texto, hasta que el usuario pulsa Enter. El nombre de la función se debe a "get" (obtener) y "s" ("string" o cadena de texto).

La línea 4 realiza lo mismo que la línea 2, pero con otro texto. La línea 5 define otra variable (edad), a la cual le asigna la cadena capturada por gets, pero cuyo resultado (la cadena), es convertida a un número entero mediante la función to_i ("to integer" o "a entero"). Esta línea es interesante porque se pueden explicar varias cosas interesantes. En primer lugar, las funciones suelen escribirse con paréntesis, aunque no tengan argumentos. En la línea 3 se omitieron los paréntesis, ya que Ruby lo interpreta de la misma manera. Otro punto interesante es que, en Ruby, todo es un objeto. Los objetos tienen propiedades (valores) y acciones (métodos o funciones), a los cuales se accede escribiendo un punto después del objeto, y escribiendo el nombre de la propiedad o de la acción. En este caso, gets retorna una cadena de texto, que en sí es un objeto, por lo que tienen acciones asociadas, en este caso, la acción to_i, la cual retorna un valor numérico entero correspondiente de la conversión de la cadena a número. Si no es posible la conversión, retornará un cero. Resumiendo, la variable edad capturará en un número entero que el usuario introduce por teclado.

La línea 7 muestra un texto, al igual que print, pero puts añade un retorno de carro al final, cambiando de línea para la siguiente impresión. Dentro del texto a imprimir (entre comillas), aparece la expresión #{expr}, la cual sustituye todo por el valor contenido dentro como expr, la cual puede ser una variable, un cálculo o cualquier expresión que retorne un valor. En este caso, sería el valor de la variable nombre.

La línea 8, realiza una operación similar, pero demostrando que la variable nombre es un objeto de tipo string, y accediendo al método length, el cual retorna el número de caracteres de la cadena de texto. En este caso, se observará que retorna la longitud más uno, debido a que también atrapó el carácter de retorno de línea (al pulsar Enter). Para corregir este defecto se podría utilizar la expresión "#{nombre.length-1}"

La línea 13 realiza una evaluación condicional, preguntando si el valor (if (condición) then / si (condición) entonces) de la variable edad es menor de 18, en cuyo caso imprimirá en pantalla el literal "menor", si no (else) imprimirá el literal "mayor". El bloque de condiciones termina en la línea 17, con end.

Este código se guarda en un archivo (por ejemplo: pruebaruby1.rb). Para ejecutarlo, desde la consola de comandos se lanza la siguiente sentencia:

$ ruby pruebaruby1.rb

Escribe tu nombre: Rafael
Escribe tu edad: 40
Hola, Rafael
Tu nombre tiene 7 caracteres
Eres mayor de edad, y te quedan 27 anos para jubilarte
Encantado de conocerte. ADIOS

Reflexiones para el 2012 (HD)

2011-12-20T21:58:00.003+01:00

Liberado Puppy Linux 5.3 'Slacko'

2011-10-31T14:50:00.004+01:00

Ya está disponible versión 5.3 de Puppy Linux, una distribución ligera que ocupa menos de 125 MB, y que comparte compatibilidad binaria con Slackware (de hecho, comparte también el repositorio de paquetes). Esta distribución es idónea para equipos antiguos y/o con pocos recursos.

Las características más novedosas de esta versión son:

- Compatibilidad con Slackware 13.37

- Linux Kernel 2.6.37.6

- PMusic y Pequalizer para organizar y reproducir colecciones de música

- Frisbee Network Manager, para gestionar conexiones a redes inalámbricas

- Seamonkey como suite de navegador web y cliente de correo

- Gestión de paquetes de Slackware, Salix y Slacky, además de los paquetes PET de Puppy

- Ofimática con Abiword (procesador de textos) y GNumeric (hoja de cálculo)

- Soporte multimedia para muchos formatos

Referencias

Puppy Linux | Sitio oficial

Noticias Puppy | Noticias

Notas de la release | Liberación de Slacko

Recursos de Slacko | Blog de Barry Kauler

Una semana de desintoxicación tecnológica

2011-10-18T23:06:00.001+02:00

A continuación se documento un experimento vivido en primera persona, para evaluar hasta qué punto nos afecta la dependencia a la tecnología, acuñada como tecnodependencia. Los datos aquí ilustrados son meramente personales, aunque pueden coincidir con un porcentaje importante de la sociedad.

El reto era vivir durante una semana sin conexión a redes sociales y sin usar el teléfono móvil.

Introducción

En primer lugar, he de describirme como un tecnoadicto desde que a principios de los años 80 me acerqué por vez primera a un ordenador personal de 1KB de memoria RAM (el mítico Spectrum Z80). Mi vida se vió arrastrada a un maravilloso mundo de información interpretada para según que fines, principalmente para el software. He hecho carrera en el mundo del software y la consultoría, siendo activista del software libre desde hace más de una década. No quiero aburrir con mi Currículum ni mis conocimientos. Tan sólo dar una pincelada de un recién estrenado cuarentañero que se crió en el albor de la informática personal y profesional.

Poseo un teléfono móvil de última generación: un Samsung Galaxy ACE. Cuando lo adquirí hace ya seis meses, exigí no tener una tarifa de datos. El motivo de esta decisión es que me paso más de 12 horas al día frente a un ordenador, y la pantalla y el teclado de éste me dan las prestaciones que no me da el teléfono. Asimismo, si he de usar una conexión de datos, prefiero usar la Wifi de casa o las Wifis públicas que encontramos en edificios de la Administración Pública o de los centros comerciales. Tampoco hago uso del correo o de las redes sociales en mi teléfono (por las razones esgrimidas antes), por lo que no tengo instalados programas del tipo What's Up, Twitter, Facebook, etc. Lo que sí utilizo y aprecio de forma adicional es la cámara de fotos y el GPS. Mi uso principal del teléfono es su concepto básico: realizar y recibir llamadas telefónicas, y algún que otro SMS.

En la actualidad, y desde hace mucho tiempo, utilizo las siguientes redes sociales: Facebook, Twitter, LinkedIn, Xing, Tumblr, Picotea y Google+ (hace tiempo abandoné MySpace, Tuenti y hi5). En el trabajo, suelo utilizar Picotea, Tumblr y Google+, ya que el proxy no lo tiene capado, y además, en Picotea y Tumblr me replica los posts a Facebook y Twitter automáticamente y por detrás, sin pasar por el proxy. El uso que le doy es de unos 10-15 minutos cada varias horas de trabajo (unas dos o tres veces al día), devorando rápidamente todos los post que me comparten (principalmente noticias tecnológicas y de actualidad), que después filtro y replico de forma implacable. En casa, puedo tirarme dos o tres horas diarias por la noche actulizando y compartiendo noticias y reflexiones, además de comunicarme por mensajes, eventos o compartiendo álbumes, debido a mi papel de político (voy a omitir publicidad de mi partido en época de precampaña, aunque much@s ya lo conocéis)

Día 1: Lunes 17 de Octubre de 2011
El teléfono móvil está guardado en el cajón del despacho de mi casa, completamente apagado. Tanto en el ordenador de casa como en el del trabajo he cerrado todas las pestañas por defecto asignadas a redes sociales.

A lo largo del día tengo tentaciones de llamadas de teléfono que podría haber recibido, todas ellas importantes, de asuntos pendientes o en el aire, tanto personales como de actividades políticas. He llevado el coche al taller para una revisión y el cambio de pastillas de freno. Doy el teléfono de mi esposa, para contactar cuando acaben. Empiezo a percatarme de la necesidad y utilidad del teléfono, más allá de la dependencia en sí. No es plan dar teléfonos de otros para que me localicen, ya que es molesto para los que han de atender mis llamadas.

En cuanto a redes sociales, sufro de ansiedad. Me muero de ganas por saber qué está pasando en el mundo. Echo de menos las noticias que me vienen en forma de flashes (mensajes cortos de microblogging, con el correspondiente enlace a la noticia). Me molesta tener que buscar en el buscador las noticias o acceder a medios de prensa online. Me cansa mucho y rápidamente, y además me despista.

Sufro también ansiedad por saber quiénes me siguen, me contestan, me dejan comentarios, me replican... Sufro por no seguir a mis contactos principales, saber qué han publicado, dejar comentarios, replicarles, compartir sus enlaces, ver sus fotos...

Estas ansiedades duran todo el día. En casa, por la noche, mi mente se embota por no saber qué hacer fuera de las redes sociales. ¿Qué visito si no puedo compartirlo con mis amigos, ni decir "Me gusta", "+1", Twittear, etc...? Me he vuelto muy cómodo obteniendo en forma de flashes los titulares de todas las noticias que me gustan, en lugar de buscarlas. Empiezo a darme cuenta de la dependencia que tengo a las redes sociales. En realidad no me concentro en tareas realmente importantes para mi. No puedo concentrarme en tareas concretas, y me disperso tanto que termino no haciendo nada.

Día 2: Martes 18 de Octubre de 2011

Gracias a la ausencia de redes sociales, mi concentración en el trabajo ha crecido espectacularmente y mi día laboral ha sido de los más productivo. He podido finiquitar los más de 200 correos electrónicos que tenía pendientes, chequear todas mis tareas pendientes y llevar al día mi trabajo diario. He conseguido quitarme la bola que me agobiaba.

Algunas veces me ha entrado "el mono" de redes sociales, especialmente en los ratos que menos carga de trabajo tenía. La ansiedad persiste, pero lo he controlado y he seguido concentrándome en el trabajo. Sigo teniendo algo de dispersión, pero mi nivel de concentración ha crecido espectacularmente.

Por la tarde, a las 7, he tenido que encender de nuevo el teléfono móvil. Me han bombardeado el correo electrónico con amenazas si no me localizaban. Hay cosas muy urgentes e importantes que me reclaman para el partido de cara a lo que queda de precampaña y para empezar la campaña. Siendo coordinador territorial de 30 localidades es necesario tener conmigo contacto directo y en tiempo real.

La lección de este segundo día es que el teléfono móvil es una herramienta imprescindible para la comunicación, quizá la más importante de todas. Quizá también sea la que mejor uso le damos, pues nos cuesta dinero, y cuando duele en el bolsillo se procura darle sentido y utilidad a su uso. Yo, al menos, no estaba todo el día enganchado al What's Up o al Twitter o al Facebook. Puede llegar incluso a molestar estar reunido o tomando algo o compartiendo algún momento, que uno no haga caso, se aísle por atender al teléfono.

Día 3: Miércoles 19 de Octubre de 2011

Resulta curioso el ruido que deja tanta información y la adición que podemos llegar a tener. Nunca antes hemos podido acceder a tanta, y sin embargo, estamos expuestos al caos de información. Creo que habría que enseñar cómo gestionar la información, clasificar, catalogar, priorizar y, sobre todo, identificar información de calidad, para no ahogarnos en las mareas de datos.

El día de trabajo ha sido muy productivo, y he podido realizar más cosas de las que podía imaginar. Mi concentración ha mejorado, aunque a veces echo de menos poder mirar quién está y qué ha compartido. El impulso es controlable. No tengo un síndrome de abstinencia tan potente.

He reflexionado largo y tendido sobre la verdadera utilidad de las redes sociales y uso eficiente de las mismas. Aún me queda mucho por discernir, por lo que esperaré al último día para escribir mis conclusiones. Sirva como adelanto que deberían existir cursos sobre este asunto, y enfocarlo especialmente en aprovechar las cualidades de las redes sociales y sobre uso. Por poner algún ejemplo: tengo casi 1200 amigos en Facebook, pero, sin embargo, no tengo más contacto que con apenas 30. Deberíamos aprender a poner un límite a nuestra agenda, hacer limpieza de amistades, enfocarnos en foros que vayamos a seguir realmente de forma cotidiana, en lugar de acumular cientos de páginas y temas por curiosidad o por recomendaciones. Otro ejemplo es saber elegir y limitar el número de redes sociales. ¿Para qué tantas? ¿Por qué replicar lo mismo en todas? Lo más importante de nuestras vidas es el tiempo, y hemos de administrarlo muy bien. Dedicar parte del mismo a cultivar amistades o redes de contactos (networking) es un tiempo bien invertido, hasta cierto punto. Hay que saber dónde está ese límite y cómo exprimir la utilidad y la productividad de estas maravillosas herramientas.

Día 4: Jueves 20 de Octubre de 2011

Hoy he tenido el día libre por asuntos propios, por lo que no me he acercado a un ordenador hasta ahora, las 19:44 horas. No he tenido mono de redes sociales, aunque por el chat de Gmail, un amigo me ha comentado la noticia del día: la presunta muerte de Gadafi. En ese momento, el mono se me ha disparado y he corrido a ver la noticia. La adición estaba escondida y ha saltado como un resorte a la mínima oportunidad. Pero lo he hecho sin acceder a ninguna red social, si no por el buscador. He estado tentado de ver esta y otras noticias del día, así como compartir todo. Pero no me ha costado reprimirlo.

En cuanto al teléfono móvil, me he dado cuenta de que hago un uso responsable y productivo del mismo. Hoy he realizado algunas llamadas realmente importantes. El coste de las mismas está bien invertido.

Día 8: Lunes 24 de Octubre de 2011

He estado tres días sin actualizar el blog, ya que he estado completamente desconectado de Internet. El viernes 21 tuve un día muy complicado en el trabajo, lo exigió de mi el 200% de mi concentración. También fue mi cumpleaños, el cual fue celebrado durante del fin de semana y, como podéis imaginar, estuve ocupado en otros quehaceres más cotidianos y físicos. Por tanto, tres días sin tecnología alguna, a excepción, como bien podéis imaginar, del tan útil teléfono móvil.

CONCLUSIONES

Tras esta semana de experimentación, he podido experimentar por mí mismo que generamos nuestra propia dependencia hacia la tecnología, pero no sabemos utilizarla de forma responsable, lo que hace evidente que se generen cursos acerca de entrenar a las personas sobre el uso de de la tecnología.

Vivimos en la era de la información, y nos maravillamos de poder tener acceso inmediato a cuanta información queramos, con tan sólo un clic. Podemos conseguirla desde nuestro teléfono móvil o desde el ordenador de nuestra casa. Pero, ¿realmente esto es bueno? ¿No tenemos demasiada información? ¿No sufrimos gula informativa? ¿No estamos también consumiendo información contaminada? La información es, posiblemente, el mayor poder que tenemos en nuestra sociedad actual, pero también es el poder más manipulado y tóxico que existe. Entre tanta y tanta información hay también desinformación, información falsa, información manipulada, información extraída de contexto y utilizada para inculcar creencias intoxicadas. Tendemos a recopilar información de una forma descontrolada y sin analizarla. Al final tendemos al caos y a la acumulación de basura informativa.

Teniendo en mente este concepto, ¿qué puede estar pasando en las redes sociales? Tenemos cantidades ingentes de amigos a quienes jamás hemos visto, y les confiamos nuestros secretos. Tenemos amigos que publican noticias, blogs e información que puede venir ya intoxicada. ¿Y qué decimos de la seguridad? ¿Sabemos acaso qué hacen con los datos de nuestra actividad en las redes sociales? Formamos parte de estadísticas y de análisis de cuando hacemos y publicamos en las redes sociales. Pueden saber cuántas veces nos conectamos, cuánto tiempo, a qué horas, con qué frecuencia, sobre qué temas leemos o estamos interesados, quiénes son nuestros amigos, qué relaciones tenemos en distintas jerarquías, qué publicamos, qué decimos en los chat... Si nos detenemos a pensarlo, la sangre se nos helaría.

No trato de ser conspiranoico, pero los hechos son evidentes, y Facebook, por ejemplo, ha sido acusada muchas veces de actividades similares, o de políticas de seguridad muy sospechosas.

Las redes sociales son herramientas que son útiles para la sociedad, que incrementan la relación entre individuos y grupos con intereses afines, y además desde la comodidad de casa, sin las limitaciones del espacio o del tiempo.

Sobre este tema se pueden escribir montañas y montañas de libros, pero a la conclusión que quiero llegar es: ¿realmente necesitamos las redes sociales? Pensémoslo detenidamente. Intentemos repetir este experimento y tomar conciencia desde otra perspectiva sobre si las redes sociales son realmente útiles o son un entretenimiento más, una forma de alienar o distraer a las masas de los problemas reales, ya sean los cotidianos o los problemas de calado social, político, económico, mundial...

Creo que las redes sociales pueden ser útiles cuando realmente seamos responsables de su uso, de conocer qué hacen realmente y los peligros que entrañan, así como también qué podemos aprovechar y cómo. Creo que una red social es útil cuando une a grupos e individuos por temáticas concretas y no dispersas, cuando los involucrados en esa red sí se conocen personalmente o se tiene una relación más intensa que la de un simple amigo agregado, cuando esas relaciones funcionan entre sí, fluyendo de uno a otro lado, coordinando ideas y proyectos, tomando acciones para avanzar en objetivos comunes...

¿Cuántos amigos de verdad tienes realmente en tus redes sociales? ¿Con cuántos de ellos sueles comunicarte y con qué frecuencia? ¿Qué haces con esos amigos realmente útil, y o perder el tiempo en vanalidades? Estas tres preguntas son clave para empezar a tomar conciencia de qué uso damos a las redes sociales. A partir de ahí podemos ir planteando más cuestiones y despejando más bulto hasta obtener una red social práctica.

Por mi parte, voy a reducir mis redes sociales a la mínima esencia. Voy a revisar mis amistades y empezar a eliminar lo superfluo para quedarme únicamente con lo que necesito y me interesa. Dejaré de perseguir noticias y replicarlas, para centrarme únicamente a mis pensamientos y reflexiones. Después de esta semana sin redes sociales tengo una conciencia más limpia y menos contaminada.

Ha fallecido Dennis Ritchie, el padre de UNIX y C

2011-10-13T11:26:00.002+02:00

Otra despedida se cierne sobre este mundo tecnológico. Dennis Ritchie, creador de UNIX y el lenguaje C (junto a Ken Thompson) nos ha dejado a la edad de 70 años. Mientras el mundo alimenta la leyenda de Steve Jobs, olvida y mira hacia otro lado para un personaje que ha sido más influyente y determinante en la informática.

UNIX es el sistema operativo sobre el cual está basado Linux y BSD, este último forkeado por Apple para sus ordenadores. El lenguaje C es utilizado en la inmensa mayoría de aplicaciones que se ejecutan en casi cualquier ordenador del mundo, o del cual se han extraído los conceptos para otros lenguajes (como Java o PHP, por poner sólo un ejemplo. La dimensión de su legado es inmensamente influyente y determinante, sin los cuales la tecnología y la informática hoy en día no existirían como lo conocemos ahora.

Descansa en paz, Dennis. Muchas gracias por hacer de este mundo un lugar mejor.

Frases

2011-10-11T08:13:00.002+02:00

"Las cosas que más faltaban en mi vida no se vendían. ¿Por qué buscar más dinero? Estoy muy contento, los lujos no podrían haberme hecho tan feliz como haber logrado algo"

Richard Stallman (Padre del Software Libre)

El espíritu de la manzana se fue

2011-10-06T07:59:00.002+02:00

Dice el cancionero popular que "algo se muere en el alma, cuando un amigo se va". Hay hombres que pasan por el mundo dejando una huella imborrable y duradera, hombres que son grandes por el espacio que ocupan en el mundo, pero sobre todo, por el vacío que dejan cuando ya no están.

Ha fallecido Steve Jobs, un visionario, un genio, un talento portentoso de los negocios, de la tecnología, de hacer todo humano y sencillo. Revolucionó la tecnología, sembrando muchas veces la polémica por su forma de hacer las cosas. Se atrevió a llegar donde nadie imaginó o se atrevió. Por ello, se ganó muchos enemigos envidiosos de su genialidad.

Yo he sido siempre crítico a los productos y a las prácticas de Apple, pero también he sido un admirador de la belleza, de la sencillez y de la innovación que Apple ha plasmado en sus productos. Detrás de todo eso ha estado Steve Jobs, el espíritu de la manzana (Apple). Su mente, su genio, su talento, su visión, su magia... se han desvanecido hace unas pocas horas, tras una larga, agónica y titánica lucha contra el cáncer de páncreas. Pero su recuerdo permanece, señalándonos la senda que podemos seguir hacia un mundo más humano y mejor.

Gracias, Steve, por todo lo que has hecho, por todo lo nos has dejado, por las lecciones que nos has dado, por el calor de ese corazón que ha dejado de latir para siempre. Gracias por decirnos que podemos lograr todo aquello que imaginemos. Te recordaremos siempre. Adiós. Descansa en Paz.

Linux, el resucitador de viejos ordenadores

2011-09-30T08:11:00.000+02:00

Linux, el resucitador viejos ordenadores
Autor: Rafael Hernampérez Martín
Fecha: 18/08/2011

Los ordenadores no envejecen ante los ojos del tiempo, si no ante los ojos de la evolución del hardware y del software. ¿Alguien tiene un viejo PC en lo más recóndito de un cuarto trastero o acumulando polvo en algún oscuro rincón? ¿Por qué se ha jubilado una magnífica máquina que sigue funcionando estupendamente? Aquel flamante PC que con ilusión compramos para adentrarnos en el apasionante mundo de la informática tiene aún mucha vida por delante, y puede darnos un gran servicio y muchas horas de satisfacción. Aún podemos resucitarlo con software actual que aproveche sus humildes limitaciones.

Mientras la evolución natural de la tecnología tiende a ir vertiginosamente“in crescendo” en recursos y capacidades, existen entusiastas que exprimen las posibilidades de aquellas máquinas que unos pocos años han defenestrado ante la imparable tendencia de la industria, de la moda y de las exigencias de un público ávido de funcionalidades que exigen cada vez más velocidad y capacidad de procesamiento, de presentación visual, de memoria y de sistemas de almacenamiento. Y es que, pensándolo fríamente, no se deja tiempo para explotar y aprovechar eficientemente un ordenador. ¿Alguno recuerda la larga vida que tuvo el extinto Spectrum, con apenas unas pocas KBytes de memoria RAM y una vetusta cinta de cassette como medio de almacenamiento? Fue toda una década gloriosa que resistió heróicamente a los inicios del PC, y en donde muchos aprendimos el noble arte de programar en Basic y ensamblador. Ordenadores como el Amstrad, el Commodore y el MSX tuvieron días largos y gloriosos, y fueron idolatrados por legiones de fans que, con ilusión y afán, consiguieron reventar contínuamente sus aparentes limitaciones.

Linux es un sistema operativo muy potente y versátil, cuyo código, al estar abierto y ser libre, permite a millones de desarrolladores de todo el mundo adaptarlo tanto a necesidades genéricas como específicas, y compartir dichas adaptaciones con todo el mundo. Entre estas posibilidades está la de trabajar de forma excelente en viejas máquinas bajas de recursos hasta tales límites de devolverle la vida a primigenios PC ocupando apenas un diskette.

Sin llegar a ese extremo minimalista, la mayoría de los usuarios desearían darle una segunda oportunidad a su viejo PC, que le haga sentir una experiencia de usuario – dentro de lo posible - similar a la que tienen ahora, y para ello es imprescindible una interfaz gráfica de usuario, con un escritorio funcional, facilidad de uso, con aplicaciones actuales y capacidades de conexión a internet. Existen bastantes distribuciones Linux que contemplan estas características, por lo que hablar sobre todas ellas requeriría de varios artículos. Sin embargo, como introducción para conocer estas maravillas del software hemos elaborado una breve lista de cinco de las más populares.

Damn Small Linux

CPU mínima: 486DX
RAM mínima: 16 MB
Tamaño ISO: 50 MB
Arranque: Disco Duro, CD, memoria USB, Compact Flash
Escritorio: Fluxbox (http://fluxbox.org/)
Modo Live: Sí
Enlace: http://www.damnsmalllinux.org/index_es.html

Puppy Linux

CPU mínima: Pentium 166Mhz
RAM mínima: 128 MB
Tamaño ISO: 128 MB
Arranque: Disco Duro, CD, memoria USB, Compact Flash
Escritorio: Fluxbox (http://fluxbox.org/) y XFCE (http://www.xfce.org/)
Modo Live: Sí
Enlace: http://puppylinux.org

Slax

CPU mínima: 486DX
RAM mínima: 96MB
Tamaño ISO: 200 MB
Arranque: Disco Duro, CD, memoria USB
Escritorio: KDE (http://www.kde.org) y Fluxbox (http://fluxbox.org/)
Modo Live: Sí
Módulos software adicional: Sí
Enlace: http://www.slax.org

Vector Linux (Light Edition)

CPU mínima: Pentium 166Mhz
RAM mínima: 64MB
Tamaño ISO: 700MB
Espacio Disco Duro: 1,8 GB
Arranque: Disco Duro, CD
Escritorio: Fluxbox (http://fluxbox.org/) y JWM (http://joewing.net/programs/jwm/)
Modo Live: Sí
Enlace: http://vectorlinux.com/

Zenwalk

CPU mínima: Pentium III
RAM mínima: 256MB
Tamaño ISO: 700MB
Espacio Disco Duro: 1,5 GB
Arranque: Disco Duro, CD
Escritorio: XFCE (http://www.xfce.org/), Openbox (http://openbox.org/) o Gnome (http://www.gnome.org/)
Modo Live: Sí
Enlace: http://www.zenwalk.org

Enlaces de interés:
Distribuciones Linux para equipos modestos: http://rafinguer.blogspot.com/2007/04/distribuciones-linux-para-equipos.html
¿Cómo aprovechar ese viejo ordenador?: http://rafinguer.blogspot.com/2006/11/cmo-aprovechar-ese-viejo-ordenador.html

Linux, el resucitador de viejos ordenadores por Rafael Hernampérez Martín se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported.

Estadísticas de Google+

2011-09-30T08:03:00.002+02:00

Con la aparición de Google+, el gigante de las búsquedas ha vuelto a imponerse como líder indiscutible de internet y del negocio que genera, ocupando uno de los sectores más importantes y acercándose a Facebook. En muy poco tiempo ha conseguido captar millones de usuarios, en mucho menos tiempo que el resto de redes sociales, marcando un record muy difícil de batir.

Si eres bloguero o tienes una página web, quizá te interese promocionar tu perfil, mostrando tus estadísticas. Google ha habilitado un sitio especial llamado Social Statistics para ver las estadísticas de todos sus usuarios:

http://socialstatistics.com

Como dato anecdótico y curioso, en el primer lugar del ranking mundial aparece Mark Zukerberg, el "creador" de Facebook, por delante de Larry Page, fundador de Google.

Pero si realmente quieres promocionar tu perfil de Google+, mostrando tus estadísticas, en cualquier sitio Web, simplemente debes introducir el siguiente código HTML/JavaScript:

<div class="socialstatistics-widget" data-id="111989909116190075662"></div>
<script>(function(d,t){var b=d.createElement(t),c=d.getElementsByTagName(t)[0];b.async=b.src="http://socialstatistics.com/widget/widget.min.js";c.parentNode.insertBefore(b,c);})(document,'script');</script>

El parámetro data-id recoge tu ID en Google+ para que el Script consulte tus estadísticas. Para obtener ese ID, accede a Google+, haz click sobre tu perfil (en tu nombre). Se mostrará la página de tu perfil, y en la barra de dirección de tu navegador aparecerá una URL como ésta:

https://plus.google.com/111989909116190075662/posts 

Copia el código (los números) y pégalos al código anterior. El resultado debería ser el siguiente:

Primera toma de contacto con Ruby

2011-09-19T10:27:00.000+02:00

Hace mucho tiempo que quería tomar contacto con un lenguaje de programación que ha tenido mucho auge en Japón y en EEUU, y que en España está tímidamente haciéndose conocer. En los últimos años, Ruby se está haciendo un hueco importante entre los lenguajes de programación, especialmente para la Web, gracias a su framework Ruby On Rails (RoR).

Ruby es un lenguaje de programación orientado a objetos, reflexivo e interpretado, con una sintaxis inspirada en Python y en Perl, y con una implementación de software libre. El intérprete de este lenguaje está disponible para varias plataformas, tales como Windows, Linux o MacOS. Fue creado en 1995 por Yukihiro "Matz" Matsumoto. La principal característica de este lenguaje es que está pensado para la productividad.

Para empezar a realizar cosas con este lenguaje tenemos una "shell" o consola (como en Python), donde podemos probar antes de generar el código final del programa. En el caso de Ruby, la consola se llama irb (Interface Ruby shell).

Lo más sencillo a probar es una simple operación matemática:

irb(main):001:0> 2+2
=>4

O un literal o cadena de caracteres, escrito entre comillas dobles o simples:

irb(main):002:0> "Soy Rafael"
=>"Soy Rafael"

La diferencia con otros lenguajes de programación es que en Ruby todo es un objeto y, por tanto, se puede acceder directamente a sus métodos y propiedades. Por ejemplo, en el último ejemplo, hemos usado un literal, que es un objeto de tipo String. Por tanto, se puede acceder a los métodos de dicho objeto:

irb(main):003:0> "Soy Rafael".length
=>10 

irb(main):004:0> "Soy Rafael".reverse
=>"leafaR yoS" 

El método length retorna la longitud del literal, mientras que el método reverse retorna el literal invertido.

El operador "+" permite sumar dos números, pero en el caso de los literales, permite concatenar dos literales en 1:

irb(main):005:0> "Soy " + "Rafael"

=>"Soy Rafael" 

El operador "*" permite multiplicar dos números, pero en el caso de los literales permite repetir dicho literal n veces:

irb(main):006:0> "Rafael"*3
=>"RafaelRafaelRafael"

Sin embargo, si se intenta realizar cualquier otro tipo de operación matemática, ésta dará un error, ya que un literal tiene distinta naturaleza de los números. Lo mismo ocurriría si se desea ejecutar un método de literal para un número. Por ejemplo, lo siguiente daría un error:

irb(main):007:0> "El resultado es: " + 2+2                                            

=> TypeError: can't convert Fixnum into String
Para poder llevar a cabo ésto será necesario que los valores sean del mismo tipo, y para ello, disponemos de métodos de conversión o "casting":

irb(main):008:0> "El resultado es: " + (2+2).to_s                                     

=> "El resultado es: 4"

El método to_s (to string), permite convertir un valor numérico a un literal. En el ejemplo se ha utilizado el paréntesis para englobar el resultado del número.

El siguiente ejemplo realiza la operación inversa, es decir, convierte un literal a un número para poder realizar la operación matemática:

irb(main):009:0> 20 + "4".to_i                                                        

=> "24"

El método to_i (to integer), convierte el valor a un número de tipo entero.

Los siguientes ejemplos convierten un número en literal, y después ejecutan un método específico para literales:

irb(main):010:0> 365.to_s.reverse

=> "563" 

irb(main):011:0> 65535.to_s.length                                                    

=> 5

Ruby también trata arrays, que son colecciones de valores. Dichas colecciones se especifican encerrando entre corchetes ([ ]) los valores que lo conforman. El siguiente ejemplo crea un array con una serie de valores numéricos:

irb(main):012:0>  [20, 15, 45, 78, 27]                                                 

=> [20, 15, 45, 78, 27]
Los arrays también son objetos, y como tales, también tienen métodos que realizan acciones:

irb(main):013:0> [20, 15, 45, 27].max                                                 

=> 45                                                                   

irb(main):014:0> [20, 15, 45, 27].min                                                 

=> 15                                                                   

irb(main):015:0> [20, 15, 45, 27].length                                              

=> 4                                                                    

irb(main):016:0> [20, 15, 45, 27].reverse                                             

=> [27, 45, 15, 20]

El método max (maximum) retorna el valor más alto del array. El método min (minimum) retorna el valor más bajo del array. El método length retorna la longitud del array, es decir, el número de valores que contiene. El método reverse retorna los valores del array en orden inverso.

Para facilitar el uso de los valores, Ruby permite almacenar los valores se pueden almacenar variables, las cuales, serán automáticamente del tipo de los valores que contienen. Las variables almacenan los valores bajo un nombre fácil de recordar, y mediante el cual se refiere a dichos valores. Por ejemplo, si la lista anterior se trata de una lista de préstamos, la cual se va a utilizar para varias operaciones, lo mejor es almacenarlo en una variable que repetir la lista constantemente:

irb(main):017:0> prestamos = [20, 15, 45, 27]                                            

=> [20, 15, 45, 27] 

irb(main):018:0> print ticket[1]                                                      
20=> nil

irb(main):019:0> prestamos.sort!                                                         

=> [15, 20, 27, 45]

irb(main):020:0> prestamos.sort!.reverse                                                 

=> [45, 27, 20, 15]

En este ejemplo, se almacena la lista en la variable prestamos. Las siguientes operaciones se realizan sobre la variable. En primer lugar, se visualiza el valor que se encuentra en el array, en la posición 1 (las posiciones dentro del array comienzan en 0 y terminan en longitud-1, y se accede a la misma indicándolo entre corchetes). A continuación, el método sort! ordena la lista de menor a mayor. Por último, ordena la lista y, a continuación, se invierte el orden de la lista (ordenación de mayor a menor).

Un literal es un array de caracteres. Probemos lo siguiente:

irb(main):021:0> texto = "en un lugar de la Mancha, de cuyo nombre no quiero acordarme"

=> "en un lugar de la Mancha, de cuyo nombre no quiero acordarme"

irb(main):022:0> texto['lugar']='sitio'

=> "sitio"

irb(main):023:0> print texto

en un sitio de la Mancha, de cuyo nombre no quiero acordarme=> nil

La variable texto contendrá un literal, que en sí mismo en su array de caracteres. La segunda sentencia, busca la subcadena 'lugar' dentro del array, y reemplaza su valor por 'sitio'. La última sentencia muestra el valor del literal con el resultado, en donde 'lugar' ha sido sustituido por 'sitio'.

El método include? nos permite consultar si una subcadena se encuentra dentro del texto, retornando true (verdadero) o false (falso) en caso afirmativo o negativo.

irb(main):024:0> texto.include? "lugar"                                               
=> false

irb(main):025:0> texto.include? "Mancha"                                              

=> true                                                                 

Recordemos que, aunque sea un literal, seguimos tratando un array, y que algunos de los métodos que estamos probando pueden servirnos para otro tipo de arrays. Así, el método include? también puede aplicarse a nuestro array prestamos:

irb(main):026:0> ticket.include? 20                                                   

=> true                                                                 

irb(main):027:0> ticket.include? 80                                                   

=> false
En el caso de los literales, hay métodos específicos, como, por ejemplo, el poder convertir todos los caracteres del array a minúsculas (con el método downcase) o a mayúsculas (con el método upcase):

irb(main):028:0> texto.downcase                                                       

=> "en un sitio de la mancha, de cuyo nombre no quiero acordarme"       

irb(main):029:0> texto.upcase                                                         

=> "EN UN SITIO DE LA MANCHA, DE CUYO NOMBRE NO QUIERO ACORDARME"

Los arrays son un recurso valioso en la programación con Ruby, pero la complejidad de las necesidades reales con los datos nos van a exigir algo más funcional y avanzado para un tratamiento secuencial y lineal de colecciones de datos. Ruby provee un tipo de dato cuya estructura es un diccionario y funciona como una tabla hash. Esto es, se define una clave o valor único, y un valor, lo que facilita las búsquedas. Las siguientes líneas definen y añaden valores a un diccionario, el cual es una colección de libros, los cuales están catalogados por una valoración. En este caso, el título del libro es la clave (valor único), y la catalogación es el valor (que puede repetirse):

irb(main):030:0> libros = {}

=> {}

irb(main):031:0> libros["Don Quijote de la Mancha"] = :esplendido

=> :esplendido

irb(main):032:0> libros["El Alquimista"] = :esplendido

=> :esplendido

irb(main):033:0> libros["Millenium"] = :muy_bueno

=> :muy_bueno

irb(main):034:0> libros["El angel caido"] = :mediocre

=> :mediocre

irb(main):035:0> libros

=> {"Don Quijote de la Mancha"=>:esplendido, "El Alquimista"=>:esplendido, "Millenium"=>:muy_bueno, "El angel caido"=>:mediocre} 

A continuación, se consulta el tamaño del diccionario y se consulta la valoración de un determinado libro:

irb(main):036:0> libros.length

=> 4

irb(main):037:0> libros["Millenium"]

=> :muy_bueno

Para consultar las claves del diccionario, se utiliza el método key:

irb(main):037:0> libros.keys

=> ["Don Quijote de la Mancha", "El Alquimista", "Millenium", "El angel caido"]

Para consultar los valores del diccionario se utiliza el método values:

irb(main):038:0> libros.values

=> [:esplendido, :esplendido, :muy_bueno, :mediocre]

Conclusiones
Esta pequeña toma de contacto al lenguaje Ruby nos permite echar un vistazo a los tipos de datos básicos que conforman el lenguaje, así como vislumbrar la potencia que tiene al ser tratado todo como objetos, con sus correspondientes métodos. Para conocer los métodos de cualquier objeto, basta con ejecutar el método methods:

irb(main):038:0> 5.methods                                                            

=> [:to_s, :-@, :+, :-, :*, :/, :div, :%, :modulo, :divmod, :fdiv, :**,:abs, :magnitude, :==, :===, :<=>, :>, :>=, :<, :<=, :~, :&, :|, :^, :[], :<<, :>>, :to_f, :size, :zero?, :odd?, :even?, :succ, :integer?, :upto, :downto, :times, :next, :pred, :chr, :ord, :to_i, :to_int, :floor, :ceil, :truncate, :round, :gcd, :lcm, :gcdlcm, :numerator, :denominator, :to_r, :rationalize, :singleton_method_added, :coerce, :i, :+@, :eql?, :quo, :remainder, :real?, :nonzero?, :step, :to_c, :real, :imaginary, :imag, :abs2, :arg, :angle, :phase, :rectangular, :rect, :polar, :conjugate, :conj, :between?, :nil?, :=~, :!~, :hash, :class, :singleton_class, :clone, :dup, :initialize_dup, :initialize_clone, :taint, :tainted?, :untaint, :untrust, :untrusted?, :trust, :freeze, :frozen?, :inspect, :methods,:singleton_methods, :protected_methods, :private_methods, :public_methods, :instance_variables, :instance_variable_get, :instance_variable_set, :instance_variable_defined?, :instance_of?, :kind_of?, :is_a?, :tap, :send, :public_send, :respond_to?, :respond_to_missing?, :extend, :display, :method, :public_method, :define_singleton_method, :__id__, :object_id, :to_enum, :enum_for, :require, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__]

irb(main):039:0> "Soy Rafael".methods                                                 

=> [:<=>, :==, :===, :eql?, :hash, :casecmp, :+, :*, :%, :[], :[]=, :insert, :length, :size, :bytesize, :empty?, :=~, :match, :succ, :succ!, :next, :next!, :upto, :index, :rindex, :replace, :clear, :chr, :getbyte, :setbyte, :to_i, :to_f, :to_s, :to_str, :inspect, :dump, :upcase, :downcase, :capitalize, :swapcase, :upcase!, :downcase!, :capitalize!, :swapcase!, :hex, :oct, :split, :lines, :bytes, :chars, :codepoints, :reverse, :reverse!, :concat, :<<, :crypt, :intern, :to_sym, :ord, :include?, :start_with?, :end_with?, :scan, :ljust, :rjust, :center, :sub, :gsub, :chop,:chomp, :strip, :lstrip, :rstrip, :sub!, :gsub!, :chop!, :chomp!, :strip!, :lstrip!, :rstrip!, :tr, :tr_s, :delete, :squeeze, :count, :tr!, :tr_s!, :delete!, :squeeze!, :each_line, :each_byte, :each_char, :each_codepoint, :sum, :slice, :slice!, :partition, :rpartition, :encoding, :force_encoding, :valid_encoding?, :ascii_only?, :unpack, :encode, :encode!, :to_r, :to_c, :>, :>=, :<, :<=, :between?, :nil?, :!~, :class, :singleton_class, :clone, :dup, :initialize_dup, :initialize_clone, :taint, :tainted?, :untaint, :untrust, :untrusted?, :trust, :freeze, :frozen?, :methods, :singleton_methods, :protected_methods, :private_methods, :public_methods, :instance_variables, :instance_variable_get, :instance_variable_set, :instance_variable_defined?, :instance_of?, :kind_of?, :is_a?, :tap, :send, :public_send, :respond_to?, :respond_to_missing?, :extend, :display, :method, :public_method, :define_singleton_method, :__id__, :object_id, :to_enum, :enum_for, :require, :equal?, :!, :!=, :instance_eval, :instance_exec, :__send__]

Enlaces
Página oficial de Ruby: http://www.ruby-lang.org
Prueba Ruby desde el navegador: http://tryruby.org
Documentación de Ruby: http://www.ruby-lang.org/es/documentation

Los ocho principios de la motivación

2011-07-06T18:46:00.002+02:00

Los 8 principios de la motivación

View more presentations from Albert Garcia

Por la neutralidad en la red

2011-03-14T07:55:00.001+01:00

Red Neutral

Han actuado
0 personas

Nos faltan
0 apoyos

Apúntate ahora

Tu nombre
Tu apellido
Tu correo-e
Cód. Postal
	Acepto las Norm. de Uso y Pol. de Priv.
	Quiero recibir más información de

10 ideas antiSinde

2011-02-13T16:08:00.001+01:00

La democracia y la cultura han sido vilmente profanadas, tomadas por la fuerza a través de una ley paradójicamente ilegal. Suplantar al juez de sus competencias (es lo que hace el comité administrativo que va a instaurar para el cierre de páginas web) viola el artículo 20.5 de la Constitución (es anticonstitucional), viola la neutralidad en la red, el derecho a la intimidad, el derecho a la protección de datos, el derecho a la presunción de inocencia y algunas directivas de la UE, tales como el derecho a la libre prestación de servicios y las relacionadas con el Comercio Electrónico.

La Ley Sinde pasará a engrosar las páginas negras de la historia de España por ser la Inquisición del Siglo XXI, fruto del sometimiento de la soberanía de nuestro país a otro país (EEUU), y a los intereses de un grupo exclusivo de lobbies que dicen defender la cultura, pero que la han pervertido, la han arruinado y la han expoliado para costear sus propios lujos a costa del bolsillo y la vergüenza de todos los ciudadanos de un país. Han doblegado a nuestros débiles y corruptibles gobiernos, han impuesto sus intereses millonarios, han pisoteado las normas fundamentales de la Democracia, han saltado por encima de la Ley, han impuesto su propio impuesto recaudatorio (no sancionador), gestionado por ellos mismos y para ellos mismos, con el que luego han cometido un fraude a los autores que defienden y a la Hacienda Pública. PP y CIU han apoyado la Ley Sinde para imponer sus intereses para reformar este canon declarado ilegal por el Tribunal de Justicia de la Unión Europea, que, presumiblemente, grabará ahora a más dispositivos, e incluso a las comunicaciones.

La Ley Sinde va a ser aprobada, tras la traición de nuestros gobernantes y de nuestra oposición a la confianza de los millones de ciudadanos que les dieron el voto. No han escuchado la voz de aquellos quienes les pusieron donde están. Han creado una generación maldita en la cultura y en la economía de este país, en el momento que más necesitábamos de la cultura y de la innovación tecnológica. Nos han hipotecado y nos han bajado a la cola del desarrollo.

Hoy, más que nunca, hace falta la unión de los españoles y no olvidar esta afrenta. En tres meses tendremos elecciones autonómicas y locales, y dentro de un año las estatales. Ahí es donde los ciudadanos podremos responder e imponer nuestra opinión ante este y otros errores que han cometido tanto PSOE como PP.

He creado diez ideas antiSinde, a modo de protesta ante esta violación de nuestros derechos fundamentales:

1) Dejar comentarios con enlaces en medios de PSOE, PP y CIU. Aplicando su propia ley, deben cerrarlos.
2) Dejar enlaces en emails, tweets y SMS, de candidatos de PSOE, PP y CIU. Aplicando su propia ley, han de cerrarlos.
3) No votar a PSOE, PP y CIU. Votar a partidos que se negaron a esta ley y escucharon a los ciudadanos, como UPyD
4) Darse de baja en las operadoras que apoyen la Ley Sinde.
5) No comprar obras de creadores proSinde. Consumir obras Copyleft, Creative Commons…
6) Usar software libre y redes encriptadas, ubicadas fuera de nuestro país.
7) Aplicar ideas 1 y 2 a medios de gestoras de Derechos de Autor, como SGAE.
8) Crear y usar plataformas culturales atractivas y económicas, como Netflix o Spotify.
9) Abogar por la cultura libre, abierta y sin propietarios. Crear la plataforma eCultura.
10) Convocar 1 huelga general, con desconexión de ordenadores, teléfonos móviles y wifis.

La cultura es de la humanidad, y nadie puede poseerla y aún menos expoliarla. Por la cultura, por la neutralidad en la red, por el derecho a la privacidad, por la libertad, por la tecnología, por internet y por el desarrollo económico, haz valer tus derechos.

El fracaso anunciado de la Ley Sinde

2011-02-02T20:37:00.001+01:00

El título hará reír a más de uno, puesto que la Ley Sinde será aprobada por una mayoría aplastante de parlamentarios, pertenecientes a PSOE, PP y CIU. Pero su aprobación no será un triunfo, si no un rotundo fracaso.

No puede ser un triunfo aprobar una Ley que perjudique a 45 millones de españoles, al desarrollo y a la competitividad de empresas innovadoras, o que la inversión no entre en nuestro país para irse a aguas más tranquilas, cuando la crisis y el paro demandan quitar frenos y lastres.

No puede ser un triunfo que esos parlamentarios den la espalda a los millones de personas que les votaron, pensando únicamente en sus propios intereses o callar ante las directivas de sus partidos.

No puede ser un triunfo que esta Ley se apruebe por un pacto entre adversarios, y que el resultado de dicho pacto sea la reforma del canon digital, declarado ilegal por el Tribunal de Justicia de la Unión Europea, tratando de aplicarlo a más dispositivos o medios, e incluso a las comunicaciones (como la ADSL).

No puede ser un triunfo que esta Ley la proponga el Partido Socialista, cuando en 2002 se opuso a los mismos propósitos de la misma, dentro de la LSSI que pretendía aprobar el PP, entonces en el Gobierno.

No puede ser un triunfo apartar a los jueces de sus competencias para cerrar páginas web que contengan enlaces, o que un comité administrativo afín a los intereses de un gobierno manipulado por los lobbies de la cultura, pueda cerrar cualquier servicio de la red por interpretar (de forma preventiva y ambigua, por simple presunción) pueda causar dolo patrimonial. El motivo de esta aberración es como quitar al árbitro de un partido que siempre ha pitado con juicio e imparcialidad según las leyes de la democracia, la libertad y la justicia, para relegarlo a la banda, y poner un árbitro que pite a favor de sus oscuros intereses.

No puede ser un triunfo aprobar una ley paradójicamente ilegal, pues viola el artículo 20 de la Constitución, al suplantar las funciones de un juez. Asimismo contraviene las directivas europeas del Comercio Electrónico y de la protección de datos.

No puede ser un triunfo una ley que, de aplicarse estrictamente, podría criminalizar a buscadores (como Google), o a servicios Web 2.0, como redes sociales (Facebook, Tuenti…), blogs (Blogger, WordPress…) o microblogging (Twitter). Cualquier usuario que deje un comentario, opinión, respuesta, etc., a otros usuarios, puede dejar un enlace a una obra. ¿Hay que controlar y censurar la participación viral?. La Ley Sinde atenta contra la neutralidad en la red y los derechos fundamentales de la libertad de expresión y de la participación, imponiendo la censura.

No puede ser un triunfo una ley estéril que no puede aplicarse a lo que pretende defender. No tiene jurisdicción sobre servidores ni páginas alojadas fuera del país (más del 90%), ni sobre aplicaciones P2P, las cuales no usan páginas de enlace, si no buscadores. Además, las páginas de enlace no contienen obras, ni reproducen ninguna parte de las obras, ni las difunden públicamente, por lo que no hay delito contra la propiedad intelectual ni contra los derechos de autor, como así han interpretado y fallado todos los jueces hasta el momento, a los que ahora van a despachar por estorbar.

No puede ser un triunfo una ley que va a aprobar un gobierno títere y manipulable, que cede a los caprichos de otro país (EE.UU), menoscabando y poniendo en duda nuestra propia soberanía. Así como tampoco, que ceda ante los chantajes de los lobbies culturales, un grupo exclusivo y privilegiado, anteponiendo los intereses de este sector minoritario a los derechos fundamentales de todo un país.

No puede ser un triunfo una ley que blinda aún más derechos y leyes feudalistas sobre la propiedad intelectual, en lugar de reformarlas, mejorarlas y adecuarlas al Siglo XXI, condenándolas a prolongar su extinción por la vía más agónica y dolorosa, que es la disconformidad y el rechazo de toda la sociedad española, quien tiene el derecho a una cultura libre y abierta.

No puede ser un triunfo una ley que, en lugar de ayudar a la industria cultural a ser más innovadora, competente, solvente y rentable la entierra en un prehistórico y desgastado modelo de más de un siglo. El Siglo XXI está aquí, la sociedad de la información es nuestra sociedad, la tecnología es el trampolín de la cultura y de la empresa. Empresas como iTunes, Netflix, Spotify o Kindle, han demostrado que las nuevas tecnologías abren un mercado mucho más rápido, más directo, más accesible, más económico, más rentable y más lucrativo, siendo, además, más justos en la explotación de las obras y en la remuneración a los autores. Esta ley supone situar a España en la cola cultural y empresarial, algo así como obligar a los taxistas seguir usando una calesa tirada por un caballo, cuando el resto del mundo se mueve con el automóvil.

No puede ser un triunfo una ley que sigue discriminando y sometiendo a los autores y artistas a las normas dictadas por el lobby cultural, que imponen la exclusividad y una pesada hipoteca sobre las obras y los propios autores, en lugar de impulsar y promocionar alternativas más abiertas, libres y respetuosas de derechos de autor, como el Copyleft o la Creative Commons.

A tenor de todo lo anterior, la Ley Sinde, a pesar de que sea aprobada en el Congreso, realmente habrá sentado un precedente de repudia y rechazo en los ya más que hartos ciudadanos, autores y empresarios de la industria cultural, atónitos e impasibles ante las tropelías constantes de los lobbies. Creará más rechazo hacia los partidos políticos que darán el SI a esta ley, al sentirse defraudados y traicionados. Y eso pasará factura en las urnas.

Al final, la Ley Sinde será derogada ante su inutilidad y por el daño ocasionado, para vergüenza de todos. Será un rotundo fracaso.

Feliz Navidad y próspero año 2011

2010-12-23T08:27:00.003+01:00

Os deseo, con todo cariño y agradecimiento, una Feliz Navidad y un próspero, único, entrañable y especial año 2011, en el que deseo que vuestros deseos y vuestros sueños se hagan realidad.

Humor tecnológico

2010-12-22T12:49:00.000+01:00

Fuente: LinuxParty

Gracias, Sinde

2010-12-22T10:25:00.003+01:00

Ayer se extinguió el intento golpista de la ley más polémica y antidemocrática de la última década, en un órdago que el gobierno creyó ganar e imponer con sus cartas marcadas. Poco le sirvió intentar camuflarla dentro de un paquete de leyes diferente. Poco le sirvió intentar presionar y negociar con el resto de partidos políticos. Poco le sirvió los argumentos dóciles intentando convencer de que no hay segundas intenciones y de trasfondo. Al final, PSOE se quedó sólo, con el sabor amargo de una derrota sin precedentes, indicador clave de una crisis de gobierno, condimentado con una tendencia de otras crisis que le han venido grandes y de las que no ha sabido estar a la altura.

La ley Sinde lleva dando bandazos desde su nacimiento (hace ya mucho tiempo), encontrando barreras allá donde va, pues es antipopular. Gracias a Wikileaks nos enteramos de que esta ley viene escrita desde EEUU, cuyo gobierno, simpatizante (o calzonazos) de la industria cinematográfica de Hollywood, ha estado presionando a nuestro gobierno, a pesar de los informes de casos infructuosos de cierres de páginas web en nuestro país. Y es que en nuestras salas de cine, más del 85% de las películas proyectadas son "made in USA", y eso no es suficiente para la infinita codicia de unos magnates anticuados. Hay que acusarnos de ser el país más pirata del mundo, cuando de siempre se ha sabido que nuestros galeones eran asaltados y hundidos por piratas de otros países. La acepción de la palabra pirata, según el diccionario de la Real Academia de la lengua Española, es la siguiente:

"Persona que, junto con otras de igual condición, se dedica al abordaje de barcos en el mar para robar.
Persona cruel y despiadada.
Persona que, bajo amenazas, obliga a la tripulación de un avión a modificar su rumbo."

Sería irónico pensar que una ama de casa, un estudiante adolescente, un señor jubilado, un autónomo, un "currito", o cualquiera de los millones de personas a los que se les acusa de piratas, vayan por la calle sembrando el pánico cruelmente, amenazando despiadadamente al resto de ciudadanos. Es calumnioso, cuanto menos. Se está faltando el respeto de millones de personas y de un país.

Nuestro gobierno ha cedido a las presiones de una industria decadente condenada a la extinción. No digo ésto sin una buena razón. Internet y la sociedad de la información están aquí desde hace casi dos décadas. Es una revolución sin precedentes en la historia, incluso mayor que la revolución industrial. Esta revolución ha calado en la sociedad, en las economías, en los negocios, en las políticas... en todo, salvo la industria de la cultura. Ha revolucionado en la forma de comunicarnos, de expresarnos, de comprar, de consultar información, de planificar nuestras vacaciones, de compartir intereses... Todo se está adaptando y evolucionando en torno a la sociedad de la información, porque es beneficioso y porque cubre las necesidades de los compromisos sociales y económicos. Cualquier empresa hoy en día tiene su página en internet, y ha adaptado su modelo de negocio a la web. Desde hace ya tiempo, los ciudadanos, antes de comprar, consultan productos y precios en internet, se informan bien sobre sus características y ventajas, y, por último compran aquello que mejor se adapta a sus necesidades personales. Sin embargo, la industria cinematográfica y de la música, no quieren evolucionar, y se aferran agónicamente al obsoleto modelo de negocio que tanto beneficio les ha dado durante tantos años antes de la revolución de la información. Es cierto que podemos comprar películas y música a través de internet, pero no aportan ningún valor añadido con respecto al formato tradicional. ¿Por qué pagar el mismo precio por una canción en formato electrónico que en formato físico (precio/canción), si la discográfica se ahorra costes de producción, logística y tienda? Si esta industria no innova, no escucha ni satisface las necesidades de los consumidores de esta época, está condenada a su extinción.

No entraré en más detalles sobre asuntos de los que ya se han discutido y sobre los que se han escrito ríos de tinta. Me concentraré en la polémica ley Sinde y lo que dicha ley ha supuesto estos días. Pero no voy a dar más datos de los que ya se conocen y que se pueden consultar en otros medios, principalmente en http://sindegate.net.

Me gustaría dar las gracias a Sinde y a su ley. No, no me estoy volviendo loco. Lo digo seriamente y con sinceridad. GRACIAS, SINDE. Pero, ¿Por qué? Por que la ley Sinde hay tenido éxito. Pero no el éxito que se esperaba. Si no el éxito de movilización de miles de ciudadanos para expresar libremente su opinión. Las barricadas ya no están en la calle, si no en la red, donde hay un movimiento más multitudinario, más social, más rápido, más interactivo, y más efectivo. Las redes sociales estaban a rebosar de proclamas y activistas. Las redes sociales se convirtieron en cacerolas hirvientes de opiniones ciudadanas.

Donde más ciudadanos se encontraron, donde más ciudadanos expresaron libremente su rechazo a esta ley, donde más ciudadanos coincidieron y lucharon, fue, sin duda alguna, Twitter.

Este medio, nacido de la idea de los SMS, se convirtió en el medio por el cual el interés sobre esta ley se multiplicó viralmente hasta límites incuantificables. Durante el lunes y el martes (anteayer y ayer), seguimos con gran interés los tweets que a cada segundo se recibían en distintos canales, tales como #leysinde o #sindegate. Hubo más canales, sin duda alguna, pero estos fueron los reyes de la batalla de los medios.

Por ello, Ángeles González-Sinde, le quiero dar las gracias por su ley, pues ha despertado el interés de ciudadanos que creíamos dormidos, y que, a pesar de la lluvia y el frío, se han manifestado a través de internet para expresar su repulsa a una ley que no es más que espasmo delirante de una agonizante industria que se muere por no evolucionar. Le quiero dar las gracias por descubrir, sin que lo previese ni quisiese, un movimiento de expresión más popular y efectivo que una manifestación o un referendum. Le quiero dar las gracias por poner de acuerdo y reafirmar las convicciones de la mayor parte de los ciudadanos de este país, de levantarles de su adormecimiento y hacerles dar un puñetazo en la mesa ante un ataque a sus derechos. Le quiero dar las gracias por hacer que millones de españoles tengan interés por informarse, por despertar del letargo de desinformación y engaño. Le quiero dar las gracias por hacer que los ciudadanos españoles sepan algo más sobre internet y sobre la propiedad intelectual, pero, sobre todo, por estimular el interés por la información y por la política (aunque sea en unas circunstancias un poco humillantes). En resumen, GRACIAS, SINDE.

Fuente: http://rhernamperez.wordpress.com/2010/12/22/gracias-sinde

Mapa conceptual del Software Libre

2010-12-20T13:54:00.000+01:00

Fuente: http://www.es.gnu.org/~reneme/fsmap/es

La política y las redes sociales

2010-12-20T10:48:00.001+01:00

Introducción

En apenas cinco meses habrá elecciones municipales y autonómicas en España. Los medios de comunicación y la forma de llegar al electorado ha cambiado mucho en la última década. La era de la información ya está presente en todos los hogares, y la sociedad ha abrazado el ciberespacio como el medio por el cual relacionarse, expresar sus opiniones, hacer negocios, buscar trabajo, divertirse, comprar, reservar las vacaciones, etc. La forma de hacer política también ha cambiado, especialmente en la forma de comunicarse con los posibles votantes.

Medios tradicionales

La televisión, la radio, los diarios y los folletos buzoneados, son medios masivos que llegan fácilmente a muchos ciudadanos, y que se utilizan exclusivamente para informar. Es una comunicación débil, pues únicamente hay un emisor que fuerza el envío de información a un receptor. Es un medio frío, en el que hay que ser creativo para captar la atención del receptor para que se interese por el contenido. El porcentaje de interés suele ser bajo.

Las mesas informativas y los mítines son medios que no llegan a tantos ciudadanos, pero tienen la ventaja de que los ciudadanos contactados ponen cara a sus políticos, pueden (o al menos deberían) poder hablar con ellos, dar opiniones, criticar, recibir el calor de un apretón de manos, de una mirada, captar la intensidad y la pasión del mensaje hablado... es un medio directo, muy humano, y las relaciones son mucho más efectivas. El porcentaje de interés es muy superior al de los medios citados en el párrafo anterior.

Internet no ha cambiado los medios de comunicación tradicionales, si no que ha hecho de pegamento entre la frialdad informativa y la calidez del contacto humano. Es un medio mucho más masivo que el de la prensa, pues no todo el mundo compra un diario, o escucha la radio, a menos que esté realmente interesado en ello. El ciudadano puede acceder a la información sin necesidad de un medio concreto, pues en Internet, la información es replicada en multitud de medios, estén o no asociados a un partido político, o estén o no asociados a un medio de comunicación concreto. La replicación de las noticias es algo sorprendente, y que funciona a modo de marketing viral. Lo más sorprendente, no es cómo una información se extiende exponencialmente, si no la facilidad de cómo los buscadores pueden llevarnos a dicha información.

Por un lado tenemos la facilidad de accesibilidad a la información, y por otro, y quizá el aspecto más importante de Internet, es que la comunicación puede establecerse en ambos sentidos, creando una relación entre el ciudadano y el político mucho más accesible que de forma presencial. En este aspecto, las redes sociales juegan un factor determinante en dicha relación, y un político debería tenerlo muy en cuenta.

¿Qué son las redes sociales?

Una red social es una herramienta o medio, a través del cual se facilita la posibilidad de que personas con intereses similares o comunes se conozcan y se relacionen. Existen redes sociales especializadas en alguna temática, como por ejemplo Xing o LinkeIn, que unen a personas con intereses empresariales o profesionales. Hay también redes científicas, médicas, educativas, informáticas, etc.

Sin embargo, la red más famosa y popular de todos los tiempos es Facebook, con más de 500 millones de usuarios en todo el mundo. La principal característica de esta red es que permite comunicar a personas en cualquier parte del mundo, sobre cualquier interés, o sobre cualquier temática, además de incluir funcionalidades muy útiles y que veremos a continuación.

Antes de proseguir, debo decir que existen más redes sociales de propósito general, como Tuenti o MySpace, e incluso una nueva red social llamada Diaspora, que está basada 100% en software libre y en estándares abiertos. Pueden gustar más o menos, pero en política hay que ser prácticos, y llegar a la mayor cantidad posible de ciudadanos. Y Facebook es el medio más popular y extendido con gran diferencia. También se podría pensar en utilizar varias redes sociales. Es buena idea, pero, como veremos a continuación, las redes sociales, para un político, son un ladrón de tiempo muy importante, que requieren de dedicación y de esfuerzo. Hay que saber dosificar el tiempo útil y productivo en hacer política, y pensar en las redes sociales únicamente como un medio por el cual informar y capturar información.

Perfil

Al iniciar la andadura en una red social, hemos de pensar primero qué perfil crear. Un perfil será lo que el resto de usuarios de la red social verán de nosotros. Recomiendo, como prioridad principal, que el perfil sea del grupo político (comité local, amigos de...), y dar la oportunidad, a través de este medio, que otros compañeros participen y utilicen la red social para el bien común. Habrá quienes tengan un perfil personal, como persona, que quieran también usar la red social para medios políticos. En este sentido, mi recomendación es dar prioridad al perfil del grupo político, y usar el personal de forma independiente. Una opinión personal, por ejemplo, debería darse (normalmente) en el perfil personal, y no en el del grupo. Por otra parte, recomiendo que si se utiliza un perfil personal, utilizarlo única y exclusivamente para fines políticos. Aunque tengamos amigos del colegio, de la Universidad, del club de mus, o en cualquier otra afición, deberíamos dejar nuestros asuntos personales y nuestras aficiones al margen. Un político es una figura pública, y como tal, tendrá fans y detractores, y las cosas personales que se publiquen pueden determinar la simpatía o la antipatía de los electores, y podrían utilizarse para cualquier actividad de desprestigio y, cómo no, para arrancarnos votos.

Una vez creado el perfil, es importante configurar la información inicial, tales como los intereses, quién puede dejarnos comentarios o las notificaciones que deseamos recibir. Si usamos Facebook, hay que tomar en cuenta este último punto, pues por defecto, recibiremos notificaciones para cualquier cosa, lo que puede llevar a desesperarnos de forma improductiva e innecesaria.

Una vez creado el perfil, podemos escribir algo en nuestro muro o en nuestro estado, un mensaje corto para presentarnos y dar la bienvenida a cualquier usuario que nos visite.

Crear relaciones

El siguiente paso obligado es encontrar amigos o personas, con el fin de crear lazos y compartir información. Lo más lógico sería pensar en buscar otros grupos o personas relacionados con nuestro partido político, y, a continuación, solicitar su amistad. Este paso no es obligatorio, ni tampoco ha de hacerse una vez y en este orden. En cualquier momento podemos buscar amigos y solicitar su amistad. Esta es la forma de crear la red.

Generar y consumir información en la red social

¿Y cuál va a ser nuestro uso de la red social, además de encontrar y hacer amigos? Lo más importante es informar y recibir información. Pero, vayamos por partes.

El muro o el estado nos permitirá escribir mensajes cortos, los cuales son visualizados en las sesiones de nuestros amigos, e indexados por los buscadores. Estos mensajes pueden ser noticias u opiniones propias. Una práctica muy habitual, es replicar noticias de otros medios, compartiendo enlaces. Lo normal es dar el título de la noticia, y a continuación pegar la URL (dirección Web) de la noticia. Esto tiene la ventaja de suscitar interés con el titular, de no saturar de texto, y que aquel que esté realmente interesado, hará clic en el enlace para leer el resto de la noticia.

Aquello que se escriba en el muro podrá ser igualmente replicado por otros amigos, creando la comunicación viral, pues los amigos de estos amigos, a su vez podrían nuevamente replicarlo, y así, sucesivamente.

La participación

Los mensajes en el muro también permiten comentarios, por lo que entramos en la parte más interesante y útil, ya que nos permite conocer otros puntos de vista, la aceptación del contenido publicado, la crítica, etc. Esto es retroalimentación de información, y es el poder más grande que tiene la Web 2.0: LA PARTICIPACION.

Imaginemos que publicamos una idea, por ejemplo, un polideportivo de tales características en tal zona. Un ciudadano podría ver la idea, y opinar al respecto. Puede dar nuevas ideas con las que no contábamos y que pueden ser interesantes, o bien puede dar información que no teníamos (por ejemplo que donde se quiere construir el deportivo era antiguamente un acuífero con pozos), o bien criticar por razones que no dimos importancia o cualaquier otra opinión.

Las redes sociales, no nos equivoquemos, no son medios para lanzar únicamente nuestros mensajes, ideas o propuestas. Las redes son medios colaborativos, y nuestra colaboración también determina el grado de que los demás participen. Podemos recibir las opiniones de nuestros amigos, recibir recomendaciones de éstos o buscar información sobre algo específico. Nosotros también somos colaboradores. Podemos interesarnos, por ejemplo, sobre algún problema común con otro municipio, o una iniciativa de otro municipio en otra provincia y en otra comunidad autónoma. Hemos de dejar comentarios, dar nuestra opinión, recomendar, replicar, votar noticias o decir, simplemente, que nos gustan. Estas acciones son actividades que también dicen de nosotros, y el resto de colaboradores de la red lo apreciarán, y responderán hacia nosotros de la misma manera. Hay que cuidar mucho este detalle y no ser egoístas, interesados únicamente en dar publicidad de nosotros sin nada a cambio. ante todo PARTICIPACION Y COLABORACION.

En el caso de que nuestro partido político sea un partido nacional, es muy importante estar presente y dedicar esfuerzos en promocionar y publicitar las ideas del partido a nivel nacional o autonómico, no solamente de nuestro municipio. Estas referencias nos favorecerán mucho, pues damos una imagen de un grupo político que se preocupa y se implica por la ciudadanía en general y a todos los niveles, no únicamente en su municipio.

Contenidos multimedia

Un aspecto bastante importante es la posibilidad de publicar contenidos multimedia. Podemos crear galerías de fotos o de vídeos, de la temática que queramos. Por ejemplo, se pueden crear secciones de fotodenuncia, de monumentos del pueblo, de nuestras actividades (mesas informativas, mítines, visitas a colegios, etc). Al igual que comenté al principio, si usamos nuestro perfil personal, recomiendo no usar fotos personales, y, aún menos, en que aparezcan menores de edad (por razones legales y de falta de privacidad). No quedaría nada bien que publiquemos una foto o un vídeo en la que salgamos con ojos chisposos, descamisado y con una copa en la mano, en mitad de una boda o de una fiesta.

Aplicaciones o utilidades

Otra de las características de las redes sociales son las aplicaciones. En el caso de Facebook, podemos encontrar algunas muy interesantes, como Twitter, donde podemos actualizar los contenidos de este medio en Facebook. Hay otras, como suscripciones a noticias RSS, o incluso juegos. Como recomendación personal, hay que dar una imagen política seria, práctica e íntegra. No hay que pecar de ser infantiles, y aún menos molestar al resto de amigos con aplicaciones del tipo "galleta de la suerte", "bolazos de nieve" y similares.

Grupos

Otra posibilidad que ofrecen las redes sociales, es la suscripción a grupos de usuarios con algún interés común. Sería muy interesante, por imagen y seriedad, suscribirse a grupos que puedan suponer un peso político y social. Recomendaría, por ejemplo, suscribirse a un grupo o asociación de enfermos de tal o cual enfermedad que está en nuestra localidad, alguna ONG, etc. No recomiendo grupos lúdicos, de ocio o impopulares, y, aún menos, que sean de actualidad pero que no estén en comunión con las ideas generales del partido.

Mensajes

Otra funcionalidad importante a tener en cuenta es la posibilidad de dejar mensajes, a modo de correo electrónico. Este medio, aunque primitivo, es el que más se utiliza para comentar cosas directamente a alguien sin que se haga público, como el muro o el estado. Además de privacidad, brinda la posibilidad de establecer una comunicación más estrecha entre ambos.

Chat

Por último, comentaré una funcionalidad que poseen las redes sociales que no hemos de escatimar. Se trata la función de chat, que permite una comunicación directa y privada entre el político y el amigo (o ciudadano, o compañero, etc.), de forma instantánea. Gracias a esta herramienta podemos responder o aclarar cuestiones en el momento, con lo que la cercanía y la presencia se hacen más palpables. El problema que tiene esta funcionalidad es (al menos en mi caso) que suele entrar en acción cuando menos lo necesitas, es decir, por ejemplo, cuando estás trabajando o cuando necesitas tu concentración en otras cuestiones más importantes. No obstante, es un medio de comunicación bastante valioso.

Reflexiones finales

Hay muchos ciudadanos que no tienen tiempo para ver la televisión, para escuchar la radio, o para leer el periódico; o bien tienen un horario que les impide acudir a un mítin o a una mesa informativa. La ventaja que tiene internet es que es descentralizado, es decir, que no se necesita estar presente ni tampoco estar en un momento dado. La comunicación entre ciudadano y político se produce sin barreras geográficas ni de tiempo.

Hemos de ver las redes sociales como un medio de comunicación, pero también como una herramienta de trabajo excelente, que nos da la información (gracias a los ciudadanos) que necesitamos para saber qué, cómo, cuándo y por qué hemos de hacer las cosas. Si importante es informar, más importante es escuchar y, aún más importante, interactuar.

Las redes sociales serán muy importantes en la precampaña y, sobre todo, en la campaña electoral. Serán el medio por el cual nos comunicaremos, colaboraremos y conseguiremos relaciones con ciudadanos, compañeros de partido y amigos. El uso de las redes sociales nos harán ganar o perder votos, dependiendo del uso que les demos. Es muy importante estar presentes, existir e interactuar con nuestros ciudadanos a través de estos medios, informarles, aclararles dudas, recibir críticas y agradecer su colaboración.

Pero no hemos de estar presentes únicamente en momentos de elecciones. Hemos de ser accesibles en cualquier momento, en cualquier lugar y por cualquier razón. No hemos de desconectar con la realidad política y social, porque la realidad no desconecta nunca. Por tanto, tampoco nosotros.

La necesidad de la Administración Electrónica y la transparencia administrativa

2010-12-16T17:01:00.003+01:00

Nota: Este artículo es un poco extenso, pero interesante y ameno, pues capta los factores clave para el éxito de la implementación de la eAdministración

INTRODUCCION

A lo largo de la historia, la vida de los ciudadanos ha estado vinculada a la Administración Pública, donde la comunicación es la clave para que el ciudadano pudiera ejercer sus derechos y que los empleados públicos pudieran ejecutar los trámites con la mayor diligencia posible. Con el tiempo, las comunicaciones y las herramientas de comunicación y de trabajo han ido evolucionando. Se ha pasado de la obligada comunicación presencial, a la correspondencia postal, al teléfono, o, como hemos vivido en las últimas décadas, la telemática.

Conscientes de esta realidad y de los beneficios que la era informática y las comunicaciones por internet ofrecen, en el año 2007, concretamente el 22 de Junio, se aprobó la Ley 11/2007, de acceso electrónico de los ciudadanos a los Servicios Públicos (http://www.boe.es/aeboe/consultas/bases_datos/doc.php?id=BOE-A-2007-12352), con la finalidad de que todo ciudadano pudiera comunicarse con la Administración Pública “de acuerdo a los principios de eficacia, jerarquía, descentralización, desconcentración y coordinación”, según reza en los derechos de nuestra Constitución, concretamente en el Artículo 103 (http://noticias.juridicas.com/base_datos/Admin/constitucion.t4.html). Esta Ley supuso adecuar la realidad de las tecnologías de la información a la Administración Pública y al ciudadano.

VENTAJAS PARA EL CIUDADANO

Para entender un poco mejor ésto, sin sofisticadas fórmulas ni leyes. el ciudadano podrá ejercer su derecho de comunicación con la Administración Pública de forma no presencial a través de las tecnologías. Hoy en día, muchos ciudadanos se deplazan lejos para trabajar y/o los horarios no son compatibles con los horarios de la Administración. Realizar cualquier trámite administrativo de forma presencial puede suponerle la pérdida de uno o varios días a cuenta de días por asuntos personales o a cuenta de sus vacaciones. Otro ejemplo lo encontramos en ciudadanos que tienen una vivienda en otro municipio en otra provincia, y necesita pagar sus impuestos, o pagar multas, etc. También están los casos de ciudadanos impedidos físicamente, ya sea por una enfermedad o una invalidez. También están los casos de ciudadanos que están fuera del país por cualquier asunto (trabajo, viaje, compromisos personales, etc). Todos ellos pueden comunicarse con su Administración desde cualquier lugar (desde casa, desde el trabajo, desde un locutorio, etc.), y a cualquier hora, a través de las tecnologías, sin colas ni esperas. Es, pues, un sistema que funciona las 24 horas del día, todos los días del año, y desde cualquier lugar y medio (hay que tener en cuenta que el trabajo de los empleados públicos está regido por un calendario laboral y un horario, por lo que la gestión de los expedientes no cuenta. Cuenta la operativa de solicitudes y consultas).

Las tecnologías aportan canales de comunicación. El canal más extendido es el ordenador personal con conexión a internet. Otro canal podría ser un teléfono móvil, la TDT o cualquier otro que facilite esta comunicación. A efectos prácticos, el mejor canal para la introducción y aportación de datos es el ordenador, pues tiene un teclado cómodo, así como la posibilidad de conectar diversos periféricos (escáneres, cámaras, etc), para capturar documentos e imágenes que se pueden adjuntar a los expedientes administrativos. El resto de canales, debido a sus características (tamaño de pantalla, periféricos de entrada de datos, etc.), son menos utilizados, pero interesantes para comunicación de información (avisos, estados, ayuda...)

El ciudadano podrá recibir notificaciones a través de su correo electrónico o en su teléfono móvil, cada vez que el expediente cambie de estado. También puede consultarlo accediendo a la ventanilla virtual (o electrónica) de su Administración. Los documentos generados y adjuntados también son accesibles de forma electrónica. Todo ello da una trazabilidad detallada y transparente sobre la gestión de sus expedientes.

El ciudadano también puede pagar tasas, multas, impuestos, etc., mediante una pasarela de pago conectada a la entidad bancaria de la Administración. Este sistema de pago es el utilizado de forma universal en tiendas online, y el banco asociado es garante de su seguridad y de cualquier tipo de incidencia o delito que pudiera ocurrir.

VENTAJAS PARA LA ADMINISTRACION

Para la Administración, la eAdministración supone numerosas ventajas (sólo por citar algunas):

- Ofrecer un servicio desatendido. No es necesario atender a cada ciudadano presencialmente, explicando paso a paso los detalles del expediente. Esto supone un ahorro considerable de tiempo que se transforma en productividad.

- Mejora la eficiencia en la gestión del expediente y aporta transparencia sobre la misma. Los expedientes van pasando directa y automáticamente a los empleados que se encargarán de gestionarlos. La bandeja de tareas, además, aporta visión de los expedientes y de su estado, evitando olvidos accidentales. Cada proceso conlleva un estado visible y trazable para la Administración y para el ciudadano.

- La documentación, al ser electrónica y centralizada en un sistema informático, es más manejable y se evitan pérdidas de documentación.

- El sistema es flexible, pudiendo asignar y delegar tareas a otros empleados públicos, o incluso añadiendo anotaciones en los procesos.

- Si un ciudadano solicita el estado de un expediente, o una copia de un expediente ya antiguo, la búsqueda es instantánea, evitando la tediosa tarea de búsqueda en un archivo físico. La información está disponible en cualquier momento, y no es necesario buscarla en lugares físicos.

- Los expedientes y sus documentos, al estar en formato electrónico y al no ocupar espacio físico, se ahorra costes en infraestructuras y en logística, o se puede aprovechar para instalaciones de otro tipo.

- La documentación en formato electrónico se puede copiar muy fácil y rápidamente.

- La documentacion en formato electrónico supone un ahorro considerable en costes de papel. El papel es susceptible de destrucción en caso de incendio o de cualquier otra catástrofe. El ahorro en papel favorece el desarollo sostenible y la ecología.

- La documentación en formato electrónico, si se utiliza algún sistema de persistencia, de alta disponibilidad o de backups, en caso de que desastre en un servidor o en un cluster, estará a salvo y seguirá funcionando.

- Las gestión administrativa, a través de plataformas de Administración Electrónica, agilizan enormemente el tiempo y el trabajo de los empleados públicos, favoreciendo la eficacia y ahorrando tiempo y costes.

- La integración con otros sistemas internos agilizan y automatizan el trabajo. Por ejemplo, el pago de un impuesto puede conectar y actualizar automáticamente el sistema contable.

UN EJEMPLO PRACTICO

La Administración Electrónica no es un mero canal de comunicación, si no también un medio de trabajo para el empleado público, y un medio de trazabilidad de expedientes para el ciudadano. Para entender mejor ésto, voy a exponer un caso práctico, paso a paso. Aunque el escenario se refiere a la Administración Local (Ayuntamiento), se puede aplicar a cualquier tipo de Administración (Hacienda, Seguridad Social, etc).

Un ciudadano solicita un trámite administrativo, por ejemplo, un certificado de empadronamiento. Accede, mediante su ordenador e internet, a la página de su Ayuntamiento, y se dirige a la ventanilla (virtual). Esto lo puede hacer cualquier día, sea festivo o no, y a cualquier hora del día, incluso de noche. Desde la ventanilla podrá acceder a la lista de trámites administrativos disponibles por la Administración (certificado de empadronamiento, solicitud de placa de vado, pago de multas, pago del IBI, pago del impuesto de vehículos, licencia de obra menor, etc). Una vez selecciona su expediente, deberá identificarse para acreditar quién es. Lo más seguro es hacerlo mediante un certificado digital (puede hacerlo en nombre propio como persona jurídica, a través de su DNI electrónico, o bien, mediante un fichero encriptado y protegido, solicitado a la Casa de Moneda y Timbre u otra Administración, previa identificación acreditada y fehaciente). El expediente solicitará una serie de datos afines al mismo (medio de comunicación, motivo de la solicitud, etc). El expediente podrá presentar una ayuda sobre cómo completar la información, así como la documentación necesaria para ser adjuntada. Si es necesario, podrá adjuntar documentos que sean necesarios para el expediente (documento escaneado, una imagen, un documento en formato PDF o DOC, etc). Una vez que el ciudadano introduce la información, la valida y envía el expediente. Si el expediente tiene una tasa, le solicitará el medio de pago del mismo (PayPal o tarjeta de crédito). Recibirá una notificación del expediente con el registro de entrada y su firma digital (una firma digital es un código único, validado con un sellado de tiempo, asociado a un certificado digital y a un documento oficial, el cual genera automáticamente el sistema con el certificado digital del ciudadano (al enviar el expediente es como si firmara el mismo al entregarlo)). El pago de la tasa se realizará mediante una pasarela de pago segura, garantizada por una entidad bancaria. El ciudadano puede proseguir con su vida normal, mientras el expediente ya está en su Administración.

En el lado de la Administración (en este caso un Ayuntamiento), cuando el empleado municipal correspondiente a dicho expediente (en este caso de Estadística) accede a su puesto de trabajo, verá una lista de tareas pendientes, entre ellas el expediente solicitado por el ciudadano, con su correspondiente registro de entrada y su firma digital. Podrá abrir el expediente, revisarlo y validar la información y documentación aportados. Si los datos no son correctos o falta algún documento, podrá solicitar al ciudadano la rectificación o la documentación pendiente. Si los datos son correctos, puede añadir nueva documentación al expediente. En el proceso de tramitación, se puede generar un documento específico del expediente, el cual será el documento que finalmente se entregará al ciudadano una vez se procese. Finalizado su trabajo, si el expediente requiere la intervención de más empleados públicos para su gestión, firmará digitalmente su proceso, pasando el expediente al siguiente proceso que se asignará a la persona correspondiente. Cuando los procesos de tramitación del expediente terminan, pasará a los procesos de firma, asociados a los responsables correspondientes (Secretario, Concejal, Alcalde...). Estos responsables tendrán un portafolio de los expedientes terminados y pendientes de firma. Tras la revisión, el responsable correspondiente puede firmar los expedientes uno a uno o por lotes. Una vez firmado por todos los responsables, el expediente finaliza, obteniendo un registro de salida, y se mandará al ciudadano mediante los medios de comunicación que ha seleccionado. Cabe decir que, en cualquier proceso, el empleado público puede denegar el expediente, indicando las razones (en nuestro ejemplo, por ejemplo, que el solicitante no está censado en el municipio). También puede solicitar en un determinado proceso el pago de alguna tasa, cuya petición se notificará al ciudadano para que se haga efectiva.

El ciudadano, por su parte, puede recibir notificaciones en su correo electrónico o en su teléfono móvil vía SMS cada vez que el expediente cambia de estado o de proceso. También puede acceder a la ventanilla virtual para consultar el estado de su expediente. Puede ver las notificaciones de cada proceso, conociendo cuándo ha pasado por dicho proceso (fecha y hora), y qué empleado público o responsable lo ha validado. También puede conocer las peticiones, por parte de la Administración, para que aporte documentación pendiente, cosa que podrá realizar y enviar de la misma forma que vimos cuando solicitaba el expediente. También puede recibir requerimientos de pago de tasas, que realizará como se explicó anteriormente. Si el expediente fue rechazado, conocerá quién lo rechazó, cuando y por qué. Si el expediente se completó, obtendrá el documento del expediente final, junto a la documentación generada y adjunta, así como las firmas digitales de los responsables y el registro de salida de dicho expediente.

ADMINISTRACION TRADICIONAL

La Administración tradicional no desaparece, si no que se complementa con la Administración Electrónica. Es lógico pensar – por ejemplo - que en estos inicios, las personas mayores, y especialmente en pueblos pequeños con poco calado tecnológico, prefieran que se lo hagan desde el Ayuntamiento. El ciudadano acudirá presencialmente, como siempre lo ha hecho, y solicitará el expediente. El empleado público accederá, desde su ordenador, a la página del Ayuntamiento y a la ventanilla, exactamente igual a como lo haría el propio ciudadano en modo online. El ordenador de la Administración tendrá conectado un lector de DNI electrónico, por lo que al solicitar la identificación, se le pedirá al ciudadano que introduzca su DNI en el lector, y, a continuación introduzca su PIN. Puede ocurrir que el ciudadano no tenga aún un DNI electrónico, o no recuerde su PIN. Esto se puede salvar adjuntando al expediente una imagen escaneada del DNI o del pasaporte del ciudadano. A partir de ahí, el empleado público solicitará los datos al ciudadano, y los irá completando en el expediente vía ordenador. El proceso sería el mismo que el que tendría el ciudadano en modo online. Una vez finalizado, se le mostrará al ciudadano el expediente antes de ser enviado, para que valide los datos que ha dado. Si es correcto, se enviará, generando la firma digital y el correspondiente registro de entrada. El documento de entrada será impreso y entregado al ciudadano, mientras que aparecerá este nuevo expediente en la bandeja de tareas del empleado correspondiente de atender el expediente.

Mediante este método no hay incongruencias en los registros de entrada de los expedientes solicitados vía online y los solicitados vía presencial.

DIFICULTADES Y PROBLEMAS PARA HACER REALIDAD LA eADMINISTRACION

Todo lo dicho anteriormente parece idílico, y así debería ser. Pero la realidad es muy diferente y no tan halagüeña. Os contaré mi experiencia.

Trabajé durante más de año y medio en el proyecto Municip@, de la Comunidad de Madrid, como Director de Provisión, como coordinador entre los equipos técnicos, soporte y comercial, poniendo en marcha el servicio para casi 130 ayuntamientos. También fui interlocutor entre los Ayuntamientos, la Comunidad de Madrid y la empresa adjudicataria del proyecto. Debo reconocer que la Comunidad de Madrid hizo aquí un esfuerzo muy grande, tanto en lo económico, como en medios, como en recursos y personas, para subvencionar a los ayuntamientos de menos de 20 mil habitantes (con alguna excepción), creando un servicio modélico y referente de Administración Electrónica.

Los problemas que encontré fueron muchos, y no tenían que ver directamente con problemas técnicos, si no más bien del día a día. Estos problemas se encontrarán en cualquier sistema de eAdministración, muchos de ellos inevitables, algunos asumibles y solventables. Por ejemplo, en ayuntamiento pequeños, además de la poca preparación informática de los empleados públicos, aún en el mejor de los casos de que puedan aprender (con mucho esfuerzo para su capacitación, aún siendo unos sistemas informáticos muy sencillos), estaba el tiempo material que necesitaban, pues eran muy pocos y tenían una gran carga de trabajo. La capacitación para adoptarlo era/es un coste muy importante. Otro, era que nuestra eAdministración estaba diseñada para integrarse con sistemas propios de la Comunidad de Madrid, y algunos ayuntamientos tenían otros sistemas, de otros proveedores, por lo que no podían integrarse, por ejemplo, para generar registros en entrada y salida, o para actualizar datos de otros sistemas de forma automática. Otro problema era la infraestructura de ordenadores que tenían (no entraban dentro de la subvención), que era antigua y había que actualizar el parque informático, cosa para la que muchos ayuntamientos no tenían presupuesto. Otro problema era que había que tener encendidos los ordenadores de algunos sistemas (como el del registro de entrada y salida, o el de estadística) las 24 horas del día, cosa que repercutía en el incremento de consumo de energía (con el consiguiente incumplimiento de la Agenda 21 y el desarrollo sostenible). Otro problema importante era la escasa infraestructura y la escasa calidad de las comunicaciones ADSL en pueblos muy retirados y pequeños, en las sierras de la Comunidad. Además de lentitud, había cortes. Además en días de mal tiempo, con tormentas (cosa frecuente), tanto la electricidad como las comunicaciones, se veían interrumpidas y en ocasiones con efecto racimo, dependiendo de si ese pueblo era nodo de distribución. La interrupción de estos servicios afectaba directamente a la disponibilidad del sistema para que pudiera ser usado por los ciudadanos.

Por último, para cerrar esta sección, diré que la ventanilla única es aún una utopía, pues ya partimos de que hay diversos sistemas de eAdministración no estandarizados, y que no comparten muchas (a veces ninguna) funcionalidades, incluso entre Administraciones del mismo nivel. No digo nada entre Administraciones distintas.

¿COMO ABORDAR LA eADMINISTRACION?

El principal problema que veo es el ocultismo comercial de los productos. Cada fabricante de software mira por su exclusividad, vendiendo productos muy buenos, pero cerrados herméticamente, tanto a nivel de licencias, de código, a nivel de formación, de soporte, de mantenimiento o de mejora. No se abren a otros productos. No se estandarizan. No se integran. Quieren tener la exclusividad de todo.

Por ello, el primer punto para llegar a una eAdministración real, coherente, de sentido común y para todos los ciudadanos y empresas que quieran colaborar, es que sea software libre, cuyo código y especificaciones estén a disposición de todos, que puedan estudiarse, y que todos puedan participar para mejorar y evolucionar el producto. No hablo de quimeras. Hablo de una realidad necesaria.

Un producto bajo software libre, creado por una empresa, tendrá el conocimiento más especializado sobre el mismo, por lo que la mayor parte de los contratos de soporte y mantenimiento los tiene casi asegurados. Creando una comunidad en torno a dicho producto, permite que otros entusiastas, sin ánimo de lucro, colaboren en hacer evolucionar y mejorar el producto, sin costes ni nóminas. Eso repercute en el enriquecimiento del producto y de la propia empresa, que ve cómo el producto es mejor y más adoptado por más Administraciones (lo que se traduce en más contratos y más negocio). La participación de desarrolladores altruistas, además, permiten crear documentación, crear foros, resolver dudas, explicar casos, crear parches, etc. Al ser abierto, otros productos podrían crear integraciones con este producto y viceversa. Se resolvería el problema de las incompatibilidades, y se comenzaría a caminar hacia una verdadera integración entre distintas Administraciones, alcanzando, poco a poco, la realidad de la ventanilla única.

Indpendientemente de los beneficios que supondría que los productos de eAdministración fueran libres y abiertos, para la Administración supondría un ahorro de costes inmenso, además de reforzar la confianza en un producto que es transparente y que no oculta puertas traseras, spyware y similares. También daría libertad para que si un día la relación con el proveedor de servicio se rompe, otro proveedor pueda seguir prestando el servicio con el mismo producto. Otra ventaja sería que, si en el caso de que el fabricante quebrara o se disolviera por cualquier razón, la comunidad podría continuar desarrollando y manteniendo el producto.

Por último, daré unos consejos más técnicos y estratégicos sobre mi visión de una eAdministración real.

- Desarrollado bajo estándares probados y populares de código abierto, con una gran comunidad por detrás.

- Las tecnologías y los lenguajes de programación utilizados deberían estar en el TOP 15 mundial, a fin de asegurar el no uso de tecnologías místicas, y que puedan ser abordadas por casi cualquier desarrollador con costes aceptables.

- No usar excesivos frameworks a modo de capas de cebolla. Se deberían analizar realmente las necesidades y el rendimiento, simplificando al máximo su arquitectura, evitando el consumo innecesario de recursos, lo que se traduce en tiempos de respuesta mejores, menos tráfico, más ahorro de energía y más ahorro de recursos físicos (memoria y disco).

- Uso de tecnologías estándar de comunicaciones, como SOAP o REST, bajo conexiones seguras estándar, como OpenSSL

- Uso de bases de datos realmente escalables, tanto horizontal como verticalmente, así como también que tengan un altísima disponibilidad. Ante estas necesidades, bases de datos de tipo NoSQL serían una buena opción. En el caso de los documentos, por su estructura, MongoDB, RavenDB o CouchDB serían idóneas. Si el tipo de expedientes es más estadístico u organizado, Cassandra sería una buena opción. Es una recomendación personal.

- Sólo recomendaría la computación en nube en el caso de que las infraestructuras sean de la Administración, no de un proveedor externo, como una empresa, ya que si no, se pierde el control de los datos, aunque se firmen contratos LOPD. Sería bueno, por ejemplo, para la reducción de costes en caso de mancomunidades entre varios Ayuntamientos, o en el caso de que una Administración de jerarquía superior, financie y de el servicio a las Administraciones de jerarquía inferior, de la cual dependen.

- La dotación y la mejora de infraestructuras (líneas telefónicas, ADSL, electricidad, etc) es un punto clave para que tenga éxito. Hasta entonces, una opción podría ser compartir el servicio en una mancomunidad de municipios, alojándolos en aquel con mayores garantías de disponibilidad (en el caso de las Administraciones Locales).

- Esfuerzo inicial de formación y capacitación para los empleados públicos. Un portal de conocimiento sería interesante para alimentar documentación, experiencias, FAQs, etc.

- Dotación de ordenadores básicos necesarios para las distintas Administraciones. Este sería un esfuerzo económico muy importante, pero si no se invierte en este sentido, muchas Administraciones no lo adoptarían.

- Conseguir acuerdos con entidades de las cuales dependen servicios externos, tales como pasarelas de pago, firma electrónica, sellado de tiempo, etc., para conseguir descuentos y subvenciones en los costes.

- Enfocado a uso en diferentes plataformas, no únicamente en Windows. El uso de herramientas Office para el ciudadano o para el empleado público, debería comprender Microsoft Office, LibreOffice, OpenOffice, AbiWord, etc.

- Enfocado a diferentes navegadores: Internet Explorer, Firefox, Chrome, Safari, Opera, etc.

- Uso de interfaces ricas de usuario estándar, sin necesidad de plugins. La tecnología Flash puede ser muy buena, pero no es una tecnología nativa del navegador, y no todos los navegadores cuentan con un plugin de Flash.

- Interfaces pensadas para la accesibilidad de personas con minusvalías.

- Buscar siempre la forma más sencilla, corta e interactiva posible en la experiencia de usuario, tanto para el ciudadano como para el empleado público.

- Dirigido (las funcionalidades que se puedan de forma eficiente), a todos los canales tecnológicos posibles: ordenadores, tablets, teléfonos móviles 2G y 3G, TDT, Call Center, eTV, etc.

La frase

2010-12-15T12:19:00.002+01:00

La computación en nube es peor que la estupidez, ya que es una pérdida del control de los datos.
Richard Stallman

La frase

2010-12-01T08:39:00.001+01:00

El crecimiento necesita alimento.
Peter Drucker

La frase

2010-12-01T08:37:00.000+01:00

Los negocios (o lo servicios) no ganan por reformar a sus clientes, sino por satisfacerlos.
Peter Drucker

La frase

2010-12-01T08:36:00.000+01:00

Hay que tener presente que un producto o servicio queda definido por el consumidor y no por el productor.
Peter Drucker

La frase

2010-12-01T08:35:00.001+01:00

Uno innova en el campo que entiende.
Peter Drucker

De huevos, gallinas y propietarios con miopía

2010-11-30T09:51:00.000+01:00

Me gustaría compartir con vosotros, una parábola muy bien redactada y enfocada por Michel Henric-Coll, creador de Fractal Teams. (Fuente: http://blog.fractalteams.com/?p=299) ¿A alguno le resulta familiar?

Érase una vez una granja que poseía 50 gallinas. Eran gallinas ponedoras que ponían una media regular de cuatro huevos al día, lo que permitiera que el feliz granjero vendiera en el mercado a diario 200 huevos.
Pero el propietario de la granja quería sacar más beneficios, así que emprendió una cruzada contra el encargado para que consiguiera mayor productividad de las gallinas.

Eran una gallinas bastante felices. Hasta escuchaban música por los altavoces repartidos en la granja. Pero debido a la presión que el propietario aplicaba al granjero para rebajar costes, este vendió el equipo de música y canceló la suscripción a Spotify. Ansioso, en lugar de visitar a las gallinas una vez al día, empezó a visitarlas cada dos horas y a recoger el huevo que habían puesto ya. Pero todo este movimiento perturbaba a las gallinas y como consecuencia del estrés, bajaron su producción en un 25%.

Fueron sólo 150 huevos los que pudieron venderse en el mercado. El propietario se puso furioso exigiendo mayor rendimiento con amenazas de despido. Entonces el granjero apretujado cogió una gallina, la mató y la puso en venta en el mercado junto a los 150 huevos del día. Como una gallina valía como 50 huevos, el propietario estuvo relativamente satisfecho con los ingresos. Una gallina menos representaba un ahorro en comida para animales y esto era muy bueno. Sin embargo, al día siguiente, sólo habían 146 huevos. Preocupado, el granjero mató a otra gallina y así sucesivamente durante 10 días. Al cabo de este plazo, le quedaban 40 gallinas que pusieron 120 huevos. Había conseguir mantener ingresos cercanos al precio de venta de una producción de 200 huevos matando gallinas.

¡Qué demonios! El propietario exigía su rendimiento, así que recortó el presupuesto para granos, mató a otra gallina y fue a venderla junto con los 120 huevos del día. Pero los ingresos totales correspondían a una producción de 170 huevos, nada más. El día siguiente era un martes, las 39 gallinas sólo habían puesto 117 así que aumentó la presión sobre ella, molestándolas cada hora y causando aún más estrés.

El viernes tuvo que matar a dos gallinas. Recogió 100 huevos que las supervivientes habían puesto, bajando el promedio habitual. Con todo, ingresó el equivalente a 200 €, como en los buenos tiempos.
Al finalizar del mes, le quedaba una sola gallina que puso dos huevos. Se hizo una tortilla que degustó con un vaso de tinto y un mendrugo de pan, preparó el petate y se fue por los caminos sin mirar atrás.

MondonGO: Herramienta ODM para MongoDB y PHP

2010-11-29T09:14:00.002+01:00

Las virtudes de MongoDB como base de datos son cada vez más apreciadas por las empresas, ofreciendo servicios Web, Web 2.0 y cloud computing, además de productos basados en las mismas tecnologías o en tecnologías tradicionales. Por otra parte, aparecen herramientas que facilitan la administración de MongoDB, backups, el desarrollo de aplicaciones con MongoDB, etc. En esta ocasión me place presentar una herramienta creada en España, llamada MondonGO, y que seguro será muy apreciada por los desarrolladores de PHP.

MondonGO es un ODM (Object Data Mapper, o un Mapeador de Objetos de Datos), lo que permite mapear la estructura de los documentos de MongoDB automáticamente a objetos en PHP, simplificando enormemente los desarrollos, ya que el acceso, la seguridad y las tareas del mapeo son realizadas automáticamente, optimizando la sencillez y la productividad a la hora de desarrollar aplicaciones PHP usando MongoDB

Mondongo, un ODM para PHP y MongoDB

View more presentations from pablodip.

MondonGO es un desarrollo de código abierto, que se puede descargar libremente desde GitHub.
Enlace a MondonGO: http://mondongo.es

MongoDB: Cómo trabaja una consulta en un entorno fragmentado

2010-11-29T09:13:00.005+01:00

Un servidor pequeño. Queremos más capacidad. ¿Qué hacer? Tradicionalmente, podríamos escalar verticalmente con una caja más grande.

Con la fragmentación, en su lugar, escalamos horizontalmente para conseguir la misma huella computacional/almacenamiento/memoria desde servidores pequeños.

He aquí la comparación gráfica de escalabilidad vertical y horizontal:

Una colección fragmentada de MongoDB tiene una clave de fragmento. La colección es particionada en un orden preservando esta clave. En este ejemplo a es nuestra clave de fragmento:

{a:..., b:..., c:... } a es declarado clave de fragmento para la colección

Los metadatos son mantenidos en trozos, los cuales están representados por rangos de claves de fragmentos. Cada trozo es asignado a un fragmento en particular.

Rango	Fragmento
a en [∞, 2000]	2
a en [2000, 2100]	8
a en [2100, 2500]	3
...	...
a en [88700, ∞]	0

Cuando un trozo se hace demasiado grande, MongoDB automáticamente lo divide, y el balanceador más tarde migrará los trozos cuando sea necesario.

find({a:{$gt:333,$lt:400})

El proceso mongos enruta una consulta a los fragmentos adecuados. Para la consulta anterior, todos los datos posiblemente relevantes están en el fragmento 2, así que la consulta es enviada solamente a aquel nodo, y allí procesada.

A veces, un rango de consulta puede abarcar más de un fragmento, pero muy pocos en total. Esto es razonablemente eficiente.

Las consultas que no involucran las claves de fragmentos serán enviadas a todos los fragmentos como una operación "esparcir/reunir". Esto a veces es correcto. Aquí, tanto en nuestra máquina tradicional como en los fragmentos, haremos una exploracion de tabla igualmente (aproximadamente) costosa en ambas.

De nuevo, una consulta con una clave de fragmento resulta en una operación esparcir/reunir. Sin embargo, en cada fragmento, podemos usar el índice {b:1} para hacer la operación eficiente para dicho fragmento. Tenemos un coste elevado sobre la configuración vertical para el esfuerzo de las comunicaciones desde los procesos mongos para cada fragmento - no demasiado si el número de fragmentos es pequeño (10), pero digamos que muy sustancial en un sistema de 1000 fragmentos.

El término a involucra la clave de fragmento y permite a los procesos mongos enrutar inteligentemente la consulta al fragmento 2. Una vez que la consulta alcanza el fragmento 2, el índice {b:1} puede ser usada para procesar eficientemente la consulta.

Cuando se especifica una ordenación, los fragmentos relevantes ordenan localmente, y los procesos mongos funde los resultados. Así, el uso de recursos de los procesos mongos no es terriblemente alto.

Cuando se usa la replicación (típicamente un conjunto de réplica), simplemente tenemos más de un nodo por fragmento.

Abajo, las flechas indican replicación en entornos tradicionales contra fragmentados.

Fuente original: http://www.mongodb.org/download/attachments/2097354/how+queries+work+with+sharding.pdf

Primeros pasos con Python y MongoDB

2010-11-29T09:13:00.001+01:00

Una de las mejores características de MongoDB es la multitud de drivers existentes para casi cualquier lenguaje de programación (ver Sección Drivers). Para los que amamos Python, tenemos un driver llamado pymongo, y que está soportado por 10gen, la empresa creadora de MongoDB. El site oficial de este driver lo encontramos en: http://api.mongodb.org/python/1.8.1%2B/index.html

Utilizar Python junto a MongoDB es muy sencillo, pues su sintaxis es muy similar a la de la consola mongo.

Instalación
La instalación de pymongo es sencilla. En Linux, procederemos a ejecutar el siguiente comando:

$ easy_install pymongo

O bien, descargamos el código fuente y lo instalamos desde la consola de Python:

$ git clone git://github.com/mongodb/mongo-python-driver.git pymongo
$ cd pymongo/
$ python setup.py install

Abrir conexión
La conexión se realiza de la siguiente manera:

>>> from pymongo import Connection
>>> conn = Connection()  # Conexion local por defecto
>>> conn = Connection('miServidor', 30500)  # Conexion remota a puerto 30500

Usar base de datos
Para obtener un objeto que referencia a la base de datos:

>>> db = conn.miBBDD # metodo 1
>>> db = conn['miBBDD'] # metodo 2

Usar una colección
Para obtener la colección con la que trabajar:

>>> coll = db.miColeccion # metodo 1
>>> coll = db['miColeccion'] # metodo 2

Documentos
Los documentos se mapean en Python como un diccionario:

>>> noticia = {"autor": "Rafael Hernamperez",
...   "cuerpo": "Python y MongoDB",
...   "etiquetas": ["Tutorial","Python","MongoDB"]}

Algunos tipos de datos especiales requieren de alguna librería específica, como datetime:

>>> import datetime
>>> noticia = {"autor": "Rafael Hernamperez",
...   "cuerpo": "Python y MongoDB",
...   "etiquetas": ["Tutorial","Python","MongoDB"],
...   "fecha": datetime.datetime.utcnow()}

Insertar documentos
Para insertar un documento:

>>> coll = db.noticias   # Coleccion "noticias"
>>> coll.insert(noticia)

Recuperar un documento
Para recuperar un único documento simple (el primero):

>>> coll.find_one({"autor": "Rafael Hernamperez"})

Recuperar varios documentos
Para recuperar todos los documentos de una colección:

>>> for noticia in coll.find():
...    print noticia

Para recuperar todos los documentos (noticias, en este caso) de un autor concreto:

>>> for noticia in coll.find({"autor": "Rafael Hernamperez"})
...    print noticia

Contar documentos
Para contar todos los documentos de una colección:

>>> coll.count()

Para contar todos los documentos de un autor concreto:

>>> coll.find({"autor": "Rafael Hernamperez"}).count()

Consultas de rango
Recupera un determinado rango de documentos, delimitados por condiciones. En este caso, recupera aquellas noticias anteriores a una determinada fecha. El resultado se ordenará por autor:

>>> fecha = datetime.datetime(2010, 9, 28, 0, 0) # 2010/09/38 00:00h
... for noticia in coll.find({"fecha": {"$lt":fecha}}).sort(autor):
...    print noticia

Indexación
Para indexar la colección "noticias", por fecha (de la más reciente a la más antigua) y por autor (en orden alfabético):

>>> from pymongo import ASCENDING, DESCENDING
>>> coll.create_index([("fecha", DESCENDING), ("autor", ASCENDING)])Technology IT News



MongoDB: Indexación
2010-11-29T09:12:00.000+01:00
En MongoDB, la indexación permite optimizar el rendimiento de las consultas, de forma muy similar a la de una base de datos relacional. Los índices se aplican a claves (campos) de nuestros documentos, ordenando sus valores para que la búsqueda sea más eficiente, y manteniendo dicha ordenación de forma constante. Tiene mucho sentido si las consultas sobre la clave es muy frecuente, especialmente si sobre la búsqueda se aplican filtros (mayor que, menor que, etc.), o si la consulta es lenta. También tiene sentido si en las consultas se muestra en un orden determinado.

A pesar de las ventajas del uso de índices, hay que tener en cuenta que los índices toman espacio y ralentizan las escrituras.

El siguiente ejemplo, muestra cómo ordenar una colección por la clave nombre:

db.articulos.ensureIndex({"nombre":1})

El valor 1 indica que la ordenación será en orden ascendente (de menor a mayor valor, o alfabéticamente, de la A a la Z). Para indicar que el orden sea descendente, se indicaría el valor -1. El siguiente ejemplo crea un índice compuesto, ordenando por nombre y por , en orden descendente (de más reciente a más antiguo):

db.articulos.ensureIndex({"nombre":1, "fecha":-1})

Si la clave del índice corresponde a un documento embebido, se ha de indicar la ruta del mismo:

db.articulos.ensureIndex({"comentarios.autor":1})

Los índices únicos indican que los valores de la clave no pueden repetirse:

db.articulos.ensureIndex({"titulo":1}, {unique:true})

Los índices toman un tiempo para realizar su cometido. Si la colección posee muchos datos, este tiempo ralentizaría el resto de operaciones de la base de datos. Para evitar este tiempo de demora, se puede indicar que el índice se realice en background o como operación en segundo plano:

db.articulos.ensureIndex({"nombre":1, "fecha":-1}, {background: true})

Si se desea conocer los índices que posee una colección determinada:

db.articulos.getIndexes()

Para eliminar un índice de una colección:

db.articulos.dropIndex({"nombre":1})


Más información: Os recomiendo ver la presentación de Mike Dirolf, de la cual se ha extraído gran parte de la información mostrada aquí: 
IndexingView more presentations from Mike Dirolf.
Technology IT News


MongoDB: Traducir SQL a MapReduce
2010-11-29T09:11:00.001+01:00

Fuente: http://nosql.mypopescu.com/post/392418792/translate-sql-to-mongodb-mapreduceTechnology IT News


MongoDB: Python y MapReduce
2010-11-29T09:10:00.002+01:00
El presente post está inspirado en el artículo "MapReduce with MongoDB and Python", de Marcel Caraciolo, y en el cual veremos cómo implementar la función Map-Reduce mediante Python y MongoDB, donde podremos apreciar su potencial en grandes conjuntos de datos en computación distribuída. 

Como ejemplo sencillo e ilustrativo, contaremos la frecuencia de palabras a través de varios documentos. En primer lugar, veremos cómo funciona map-reduce,utilizando una lista de sentencias simples. Para ello, tenemos el siguiente diagrama, en donde las palabras son divididas y agrupadas por la función map, y después reducidas independientemente (agregación) por la función reduce. Nuestra consulta puede estar distribuída en cuatro ordenadores, por lo que su procesamiento es mucho más rápido en tiempo de ejecución. El ejemplo, además, muestra un árbol balanceado, pero podría estar no balanceado o incluso tener alguna redundancia.
Antes de comenzar a desarrollar las funciones map y reduce debes saber que:
1)  El motor MapReduce puede invocar funciones reduce de forma iterativa, por lo que éstas deben ser idempotentes:
   for all k,vals : reduce( k, [reduce(k,vals)] ) == reduce(k,vals)
1) Actualmente, el retorno de valores de una función reduce no puede ser un array (ha de ser un objeto o un número)
3) Si necesitas realizar una operación una única vez, utiliza la funión finalize.

Para implementar el código debes utilizar el framework Pymongo, el cual tiene soporte para Map/Reduce. Como ejemplo, el discurso de Obama en 2009 tiene muchas palabras repetidas, como puede apreciarse en la siguiente nube de etiquetas, cuyo tamaño de fuente indica la frecuencia de cada palabra:
MongoDB permite a los clientes enviar las implementaciones JavaScript de map y reduce, las cuales se evaluarán y ejecutarán en el servidor. La función map sería la siguiente (wordMap.js):

function wordMap() {
  // Buscar palabras en el texto del documento
  var palabras = this.text.match(/\w+g);

  if (palabras == null) {
     return;
  }

  for (var i = 0; i < palabras.length; i++) {
    // Emitir cada palabra, con contador de uno
    emit(words[i], {count: 1});
  }
}

MongoDB llamará a la función map por cada documento en la colección que está consultando, y apuntará al documento donde tendrá acceso una clave como text mediante this.text. Esta función no retorna una lista, si no que llama a una función emit que espera ser definida. Los parámetros de esta función (clave, valor), serán agrupados con otros resultados intermedios de otras evaluaciones map que tengan la misma clave (clave, [valor1, valor2]) y pasada a la función reduce (wordReduce.js
function wordReduce(key, values) {

  var total = 0;
  for (var i = 0; i < values.length; i++) {
    total += values[i].count;
  }

  return {count: total};
}

La función reduce ha de reducir una lista de un tipo dado a un valor simple del mismo tipo; debe transsitivo para que no tenga problemas sobre cómo están agrupados los elementos mapeados.

A continuación, el código del cliente Pymongo que pasa las funciones map/reduce al servidor:
Technology IT News


MongoDB: Un ejemplo de MapReduce
2010-11-29T09:08:00.001+01:00
Conceptos de MapReduce
MapReduce es una característica importante comprendida por MongoDB. Este framework fue creado por Google para dar solución a la computación paralela sobre grandes colecciones de datos en sistemas distribuídos. El concepto se basa en dos funciones, map y reduce, que se aplican sobre datos estructurados en formato de pares clave-valor. 

La función map (mapeo) toma uno de estos pares en un dominio de datos, y retorna una lista de pares en un dominio diferente. Se aplica en paralelo por cada elemento de la entrada de datos, produciendo la lista de pares por cada llamada, juntando todos los pares con la misma clave de todas las listas y los agrupa, creando un grupo por cada clave.

La función reduce (reducción) se aplica paralelamente a cada grupo, generando una colección de valores para cada dominio, produciendo un valor (o varios) en cada llamada.

Básicamente, MapReduce transforma una lista de pares clave-valor en una lista de valores. 


Un ejemplo
Para comprender cómo funciona MapReduce, vamos a ver un ejemplo práctico. Para ello, voy a utilizar uno ya hecho por Kristina Chodorow, una de las principales creadoras de MongoDB.

Imaginemos que tenemos una colección posts, que almacena los artículos de nuestro blog. Un documento en esta colección podría tener esta estructura:
La clave tags es un array de etiquetas, que permiten categorizar cada artículo. Y sobre esta clave vamos a basar el ejemplo de MapReduce, como por ejemplo, conocer las etiquetas más populares, dando un resultado como éste:
La función map emitirá cada etiqueta (tag), y la contará en la función reduce. 

La función map es la siguiente:
Lo primero que hace es comprobar si existe una clave llamada tags, para evitar errores. A continuación realiza un bucle sobre esta clave (por cada elemento del array), emitiendo su nombre y un contador de 1.

La función reduce inicializa un contador a 0 y le añade cada elemento del array current. Al final retorna el contador final:
Para ejecutar ésto, invocaremos al comando mapreduce:
Los parámetros facilitados son:
- mapreduce: Se facilita la colección sobre la que extraer los datos (posts).
- map: Nombre de la función que realizará el mapeo.
- reduce: Nombre de la función que realizará la reducción.
- out: Colección donde se pondrá el resultado.

Finalmente, consultamos la colección tags para mostrar los resultados:


Fuentes consultadas
Concepto de MapReduce en Wikipedia: http://es.wikipedia.org/wiki/MapReduce
Artículo "Contar etiquetas", por Kristina Chodorow: http://cookbook.mongodb.org/patterns/count_tags/Technology IT News


Comparativa MongoDB con otras Bases de datos NoSQL
2010-11-29T08:23:00.001+01:00
He encontrado en myNoSQL algunas tablas comparativas de MongoDB con respecto a otras bases de datos NoSQL, creadas por Alex Popescu.

Bases de datos orientadas a documento
La primera tabla compara tres bases de datos orientadas a documento: MongoDB, CouchDB y RavenDB (echo en falta una columna para OrientDB).

    MongoDB  CouchDB  RavenDB
Documentos
Formato BSON JSON JSON
Metadata No Sistema Sistema + personalizado
Versionado No Sí Plugin incluído
Adjuntos GridFS Sí Sí
Map/Reduce JavaScript + otros JavaScript LINQ
Carga masiva mongoimport Sí Sí
Consulta Adhoc Sí No No
Almacenamiento
Fragmentación Sí Sí Sí
Durabilidad Servidor simple v1.8 Diseño "crash-only" Escritura previa trazabilidad y aislamiento de instantáneas para garantizar recuperación vía ESE
Transacciones No No Sí
Concurrencia Actualización in-place MVCC (Multi-Version Concurrency Control) Concurrencia optimista
Consistencia Maestro fuerte / Esclavo eventual Nodo fuerte / Cluster eventual Eventual
Replicación Maestro-Maestro con funciones de resolución personalizadas Maestro-Esclavo Plugin incluído
Interfaz
Protocolo Personalizado sobre TCP/IP HTTP/REST HTTP/REST
.NET API Proyectos de terceros Proyectos de terceros Incluído
Otros
Triggers No Validación de actualización, Seguridad Sí
Seguridad Básica Básica Ninguna
Escrito en C++ Erlang C#

Lenguajes de programación
La siguiente tabla muestra el uso de lenguajes de programación en varias bases de datos NoSQL. Yo hubiera añadido también Perl, C/C++, Erlang ó Go, que son lenguajes populares que también comprende MongoDB (entre otros muchos).

    BBDD  Modo durabilidad  java  ruby  python  php  .net  http  
 documento  mongodb  basado en réplica  x  x  x  x  x  x  
    couchdb  nodo simple  x  x  x  x  x  x  
    ravendb  nodo simple  -  -  -  -  x  x  
 clave-valor  redis  en memoria, serializado en disco  x  x  x  x  x  -  
    riak  basado en réplica  x  x  x  x  x  x  
 tabular  cassandra  basado en réplica  x  x  x  x  x  -  
 grafo  neo4j  nodo simple  x  x  x  x  -  x  
    sones  nodo simple  -  -  -  -  x  x  

Fuentes
http://nosql.mypopescu.com/post/1016366403/nosql-guide-for-beginners
http://nosql.mypopescu.com/post/978742866/document-databases-compared-couchdb-mongodb-ravendbTechnology IT News


MongoDB: Ejemplo de configuración de fragmentación
2010-11-29T08:22:00.002+01:00
Este post es una traducción del artículo original "Return to the Mongo Mailbag", de Kristina Chodorow.  


En la lista de correo mongodb-user de la semana pasada, alguien preguntó (básicamente):

"Tengo 4 servidores y quiero dos frgamentos. ¿Cómo lo configuro?"

Mucha gente está preguntando sobre cómo configurar conjuntos de réplica y fragmentación, por lo que que aquí se explicará en detalle.


The Architecture

Prerequisitos. Si no estás familiarizado con los conjuntos de réplica, echa un vistazo a mi post en mi blog. El resto de este post no tendrá mucho sentido a menos que tú sepas qué es un árbitro. Además, deberías conocer los conceptos de la fragmentación.

Cada fragmento debería ser un conjunto de réplica, por lo que necesitaremos dos conjuntos de réplica (los llamaremos "foo" y "bar"). Queremos que nuestro cluster sea correcto si una de las máquinas se cae o se separa de la manada (partición de red), así que extenderemos fuera cada conjunto entre las máquinas disponibles. Los conjuntos de réplica están codificadas por color y las máquinas son nombradas imaginativamente server1-4.

Cada conjunto de replica tiene dos hosts y un árbitro. De esta manera, si un servidor se cae, ninguna funcionalidad se pierde (y ahí no estarán dos maestros en un servidor simple).

Para configurar ésto, ejecuta:

server1

$ mkdir -p ~/dbs/foo ~/dbs/bar
$ ./mongod --dbpath ~/dbs/foo --replSet foo
$ ./mongod --dbpath ~/dbs/bar --port 27019 --replSet bar --oplogSize 1

server2

$ mkdir -p ~/dbs/foo
$ ./mongod --dbpath ~/dbs/foo --replSet foo

server3

$ mkdir -p ~/dbs/foo ~/dbs/bar
$ ./mongod --dbpath ~/dbs/foo --port 27019 --replSet foo --oplogSize 1
$ ./mongod --dbpath ~/dbs/bar --replSet bar

server4

$ mkdir -p ~/dbs/bar
$ ./mongod --dbpath ~/dbs/bar --replSet bar

Los árbitros tienen un tamaño de oplog de 1. Por defecto, el tamaño de oplog es un ~5% de tu disco duro, pero los árbitros no necesitan mantener ningún dato, por lo que esto es un gran desperdicio de espacio.

Poner juntos los conjuntos de réplica

Ahora arrancaremos los dos conjuntos de réplica. Arrancar la consola mongo y escribir:

> db = connect("server1:27017/admin")
connecting to: server1:27017
admin
> rs.initiate({"_id" : "foo", "members" : [
... {"_id" : 0, "host" : "server1:27017"},
... {"_id" : 1, "host" : "server2:27017"},
... {"_id" : 2, "host" : "server3:27019", arbiterOnly : true}]})
{
  "info" : "Config now saved locally.  Should come online in about a minute.",
  "ok" : 1
}
> db = connect("server3:27017/admin")
connecting to: server3:27017
admin
> rs.initiate({"_id" : "bar", "members" : [
... {"_id" : 0, "host" : "server3:27017"},
... {"_id" : 1, "host" : "server4:27017"},
... {"_id" : 2, "host" : "server1:27019", arbiterOnly : true}]})
{
  "info" : "Config now saved locally.  Should come online in about a minute.",
  "ok" : 1
}

Ahora tenemos dos conjuntos de réplica en ejecución. Creemos ahora un cluster.


Configurar la fragmentación

Una vez intentemos configurar un sistema sin puntos simples de fallo, usaremos tres servidores de configuración. Podemos tener tantos procesos mongos como queramos (se recomienda uno en cada appserver), pero empezaremos con uno.

server2

$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000

server3

$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000

server4

$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000
$ ./mongos --configdb server2:20000,server3:20000,server4:20000 --port 30000

Ahora añadiremos nuestros conjuntos de réplica al cluster. Concta los mongos y ejecuta el comando addshard:

> mongos = connect("server4:30000/admin")
connecting to: server4:30000
admin
> mongos.runCommand({addshard : "foo/server1:27017"})
{ "shardAdded" : "foo", "ok" : 1 }
> mongos.runCommand({addshard : "bar/server3:27017"})
{ "shardAdded" : "bar", "ok" : 1 }

Como puedes ver, terminarás con un fragmento "foo" y un fragmento "bar". (si estás usando una versión antigua de MongoDB, tus fragmentos tendrán nombres como “shard0000″ o “shard0001″)

Ahora puedes conectar a “server4:30000″ en tu aplicación y utilizarlo con un simple y “normal” mongod. Si quieres añadir más procesos mongos, simplemente arráncalos con los mismos parámetros configdb utilizados anteriormente.Technology IT News


MongoDB: Conjuntos de réplica. Parte 3
2010-11-29T08:22:00.000+01:00
Este post asume que sabes qué son los conjuntos de réplica y algo de la sintáxis básica.

En la parte 1, configuramos un conjunto de réplica desde cero, pero la vida real es más desordenado: puedes querer migrar servidores de desarrollo a producción, añadir nuevos esclavos, priorizar servidores, cambiar cosas en el momento (on the fly)... y ésto es lo que este post cubre.


Antes de empezar…

A los conjuntos de réplica no les gusta localhost. Son serviciales para secundarlos... más o menos, bastante... pero a menudo provoca discrepancias. Puedes evitar estas discrepancias usando en su lugar el nombre del servidor (hostname). En Linux, puedes buscar tu nombre de servidor ejecutando el comando:

$ hostname
wooster

De aquí en adelante, usaremos mi nombre de servidor en lugar de localhost.


Arrancar con datos

Esto es más o menos que arrancar sin datos, escepto que deberías hacer una copia de seguridad de tus datos antes de arrancar (deberías siempre hacer un backup siempre de tus datos antes de hacer travesuras con tu servidor de configuración).

Si en el pre-conjunto-réplica, arrancaste tu servidor con algo como:

$ ./mongod

...conviértelo en el primer miembro de tu conjunto de réplica, por lo que has de parar y arrancar de nuevo con la opción –replset:

$ ./mongod --replSet unicomplex/wooster:27017

Ahora, inicializa el conjunto con el único servidor:

> rs.initiate()
{
"info" : "Config now saved locally.  Should come online in about a minute.",
"ok" : 1
}


Agregar esclavos

Deberías arrancar MongoDB siempre con esclavos, así que agreguemos alguno.

Arranca tu servidor con las opciones usuales, así como también como –replSet. Así, por ejemplo, podríamos hacer:

$ ./mongod --dbpath ~/dbs/slave1 --port 27018 --replSet unicomplex/wooster:27017

Ahora, agregamos este esclavo al conjunto de réplica. Asegurarse de que db está conectado a wooster:27017 (el servidor primario) y arrancar:

> rs.add("wooster:27018")
{"ok" : 1}

Repetir como sea necesario para agregar más esclavos.


Agregar un árbitro

Esto es muy similar a agregar un esclavo. Cuando arranques el árbitro, deberías darle la opción –oplogSize 1. De esta manera el árbitro no desperdiciará espacio.

$ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/wooster:27017 --oplogSize 1

Ahora agregarlo al conjunto. Puedes especificar que este servidor es un árbitro pasando en un objeto un campo arbiterOnly a rs.add:

> rs.add({"host" : "wooster:27019", "arbiterOnly" : true})
{"ok" : 1}


Degradar un primario

Supongamos que nuestra compañía tiene disponibles los siguientes servidores:

1. Super máquina Gazillion dollar
2. Instancia EC2
3. iMac que encontramos en la calle

A través de un accidente del destino, el iMac se convierte en primario. Podemos forzarle a que se convierta en esclavo ejecutando el comando:

> imac = connect("imac.example.com/admin")
connecting to: imac.example.com/admin
admin
> imac.runCommand({"replSetStepDown" : 1})
{"ok" : 1}

Ahora el iMac será un esclavo.


Establecer prioridades

Podemos indicar que el iMac nunca sea un maestro (queremos usarlo sólo como backup). Puedes forzar ésto estableciendo su prioridad a cero. La más alta prioridad de un servidor es la que hará que se convierta en maestro si el actual maestro falla. Las únicas opciones son 0 (no puede ser maestro) o 1 (puede ser maestro), pero en el futuro serás capaz de tener una buena graduación de prioridades..

Así, cambiaremos la prioridad del iMac a 0. Para cambiar la configuración, conectemos al maestro y editemos su configuración:

> config = rs.conf()
{
"_id" : "unicomplex",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "prod.example.com:27017"
},
{
"_id" : 1,
"host" : "ec2.example.com:27017"
},
{
"_id" : 2,
"host" : "imac.example.com:27017"
}
]
}

Ahora, tenemos que hacer dos cosas: 1) establecer la prioridad del iMac a 0, y 2) actualizar la versión de la configuración. El nuevo número de versión es siempre el anterior más uno

> config.members[2].priority = 0
0
> config.version += 1
2

Finalmente, decimos al conjunto de réplica que tenemos una nueva configuración.

> use admin
switched to db admin
> db.runCommand({"replSetReconfig" : config})
{"ok" : 1}

Todos los cambios de configuración deben ocurrir en el maestro. Éstos se propagarán de éste a los esclavos. Ahora puedes "matar" cualquier servidor y el iMac nunca se convertirá en maestro.

Esta configuración es un poco melindrosa para hacer desde la consola. En el futuro, la gente probablemente utilice una GUI para configurar sus conjuntos y trastear con la configuración del servidor.


Artículo original: http://www.snailinaturtleneck.com/blog/2010/08/03/part-3-replica-sets-in-the-wild/Technology IT News


MongoDB: Conjuntos de réplica. Parte 2
2010-11-29T08:20:00.002+01:00
Los conjuntos de réplica son básicamente maestro-esclavo con failover automático.

La idea es: tienes un esclavo y uno o más esclavos. Si el maestro se cae, uno de los esclavos automáticamente se convertirá en el nuevo maestro. Los drivers de base de datos, siempre encontrarán al maestro, si el maestro que se está usando se cae, ellos (drivers) automáticamente entenderán quién es el nuevo maestro y envía las escrituras a dichos servidor. Esto es mucho más fácil de manejar (y más rápido) que manejar manualmente el fallo sobre un esclavo.

Así, tu tienes un pool de servidores con un primario (el maestro) y N secundarios (esclavos). Si el primario tiene un accidente y desaparece, los otros servidores mantendrán una elección para elegir un nuevo primario.


Elecciones

Un servidor tiene que obtener una mayoría del total de votos para ser elegido, no sólo una mayoría. Esto significa que, si tenemos 50 servidores y cada servidor tiene un voto (por defecto, los últimos post mostrará cómo cambiar el número de votos que un servidor obtiene), un servidor necesita al menos 26 votos para convertirse en primario. Si ninguno obtiene 26 votos, ninguno se convierte en primario. El conjunto puede todavía manejar lecturas, pero no escrituras (ya que no hay maestro).

Si un servidor obtiene 26 o más votos, éste se convertirá en primario. Todas las futuras escrituras serán direccionadas a éste, hasta que pierda una elección, estalle, etc.

El primario original es todavía parte del cojunto. Si lo levantas, éste se convertirá en un servidor secundario (hasta que obtenga nuevamente la mayoría de votos).

Una multitud de tres (de buena manera)

Una complicación con este sistema de votación es que tú no puedes tener sólo un maestro y un esclavo.

Si estableces sólo un maestro y un esclavo, el sistema tiene un total de 2 votos, así que un servidor necesita ambos botos para ser elegido maestro (1 no es mayoría). Si uno de los servidores se cae, el otro servidor sólo tiene un voto de 2, así que ésto lo convierte (o lo conserva) en un esclavo. Si la red está particionada, y repentinamente el maestro no tiene una mayoría de los votosos (sólo tiene su único voto), será degradado a un esclavo. El esclavo además no tiene una mayoría de los votos, po lo que permanecerá siendo esclavo (así que terminarás con dos esclavos hasta que los servidores se puedan alcanzarse el uno al otro de nuevo).

Esto es un desperdicio, aunque, tener dos servidores y ningún maestro levantado, los conjuntos de réplica tienen varias formas de evitar esta situación. Una de las más simples y más versátiles es usar un árbitro, un servidor especial que existe para resolver disputas. Éste no sirve ningún dato al mundo exterior, si no que es simplemente un votante (puede incluso estar en la misma máquina como otro servidor, siendo muy ligero). En la parte 1, el árbitro era localhost:27019.

Así, digamos que establecemos un maestro, un esclavo y un árbitro, cada un con un voto (total 3 votos). Entonces, si tenemos un maestro y un árbitro en un centro de datos y el esclavo en otro, si se produce una partición de red, el maestro todavía tendrá una mayoría de votos (maestro+árbitro). El esclavo tiene sólo 1 voto. Si el maestro falle y la red no se particiona, el árbitro puede votar por el esclavo, promocionándole como maestro.

Con esta configuración de tres servidores, obtenemos un failover sensible y robusto.

Lo próximo: configuración dinámica de tu conjunto de réplica. En la parte 1, confiramos todo completamente al empezar. En el mundo real querremos ser capaces de añadir servidores dinámicamente y cambiar la configuración.


Artículo original: http://www.snailinaturtleneck.com/blog/2010/08/02/replica-sets-part-2-what-are-replica-sets/Technology IT News


MongoDB: Conjuntos de réplica. Parte 1
2010-11-29T08:19:00.003+01:00
Los próximos tres posts están dedicados a los conjuntos de réplica, una de las mejores características de MongoDB para asegurar la alta disponibilidad en un sistema de base de datos. Estos posts los escribió Kristina Chodorow, una de las desarrolladoras más importantes de MongoDB.

Este post muestra cómo hacer el "Hola, mundo" de los conjuntos de réplica. Voy a empezar con un post explicand qué es, pero la codificar es mucho más divertido que leer. Por ahora, todo lo que tienes que saber es que hay maestro-esclavo con failover (a prueba de fallos) automático.

Asegúrate de que tienes la versión 1.5.7 o superior de la base de datos (MongoDB) antes de probar el código que viene a continuación.

Paso 1: Elegir un nombre para tu conjunto

Esto es sólo organizacional, así que puedes elegir el que sea. Yo usaré "unicomplex" para mi ejemplo.

Nota: Kristina hace uso de su buen humor para la elección de un nombre. El nombre "que sea" es un artículo para dar un nombre a un bebé. Unicomplex se refiere a la saga de Startrek.


Paso 2: Crear los directorios de datos

Necesitamos un directorio de datos para cada servidor que vayamos a arrancar:

$ mkdir -p ~/dbs/borg1 ~/dbs/borg2 ~/dbs/arbiter


Paso 3: Arrancar los servidores

Arrancaremos nuestros tres servidores:

$ ./mongod --dbpath ~/dbs/borg1 --port 27017 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/borg2 --port 27018 --replSet unicomplex/
$ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/


Paso 4: Inicializar el conjunto

Ahora tenemos que decirle al conjunto, "¡hey, existes!". Arranca la consola mongo y ejecuta:

MongoDB shell version: 1.5.7
connecting to: test
> rs.initiate({"_id" : "unicomplex", "members" : [
... {"_id" : 0, "host" : "localhost:27017"}, 
... {"_id" : 1, "host" : "localhost:27018"}, 
... {"_id" : 2, "host" : "localhost:27019", "arbiterOnly" : true}]})
{
"info" : "Config now saved locally.  Should come online in about a minute.",
"ok" : 1
}

rs es una variable global que mantiene un racimo de funciones útiles para conjuntos de réplica.

El mensaje dice que estará online en aproximadamente un minuto, pero siempre han sido unos ~5 segundos para mi. Una vez que veas la siguiente línea en uno de los logs (trazas):

replSet PRIMARY

¡…tu conjunto de réplica está listo para funcionar!

Jugar con el conjunto

Uno de los servidores será el maestro (master), el otro es un esclavo (slave). Puedes entender cuál es cuál ejecutando el comando isMaster en la consola:

> db.isMaster()
{
"ismaster" : true,
"secondary" : false,
"hosts" : [
"localhost:27017",
"localhost:27018",
],
"arbiters" : [
"localhost:27019"
],
"ok" : 1
}

Si db no es primario, el servidor que está será listado en el campo "primary" (primario):

> db.isMaster()
{
"ismaster" : false,
"secondary" : true,
"hosts" : [
"localhost:27017",
"localhost:27018",
],
"arbiters" : [
"localhost:27019"
],
"primary" : "localhost:27018",
"ok" : 1
}

Ahora, prueba a "matar" el servidor primario. Espera un par de segundos y verás que el otro servidor (no-árbitro) será elegido primario.

Una vez que haya un nuevo primeraio, rearranca el mongod que acabas de "matar". Verás que se une a la refriega, aunque no se convierte en maestro (ya hay un maestro, así que no mecerá el barco). Después de unos pocos segundos, mata el maestro actual. Ahora, el antiguo maestro se convertirá en maestro de nuevo.

Es bastante divertido jugar con ésto, levantando y cayendo y mirando cómo el maestrazgo va atrás y adelante (o quizá yo me entretenga fácilmente).


Insertar y consultar datos

Por defecto, los esclavos están sólo como respaldo o backup, por lo que puedes usarlo para consultas (lecturas) si estableces el flag "slave ok". Conecta a cada uno de los servidores y establece este flag:

> db.getMongo().setSlaveOk()
> borg2 = connect("localhost:27018/test")
connecting to: localhost:27018/test
test
> borg2.getMongo().setSlaveOk()

Ahora puedes insertar, actualizar y eliminar datos en el maestro y leer los cambios en el esclavo.


Artículo original: http://www.snailinaturtleneck.com/blog/2010/07/30/replica-sets-part-1-master-slave-is-so-2009Technology IT News


MongoDB: Fragmentación y conjuntos de réplica ilustrados
2010-11-29T08:19:00.000+01:00
Este post asume que conoces qué son los conjuntos de réplica y la fragmentación.

Paso 1: No usar fragmentación

En serio. Casi nadie lo necesita. Si estabas en el punto donde necesitabas particionar tu base de datos MySQL, probablemente tengas otras vías de hacerlo antes de que necesites particionar MongoDB (nos burlamos de los billones de filas).

Ejecuta MongoDB como un conjunto de réplica. Cuando necesites realmente capacidad extra, entonce, y sólo entonces, comienza la fragmentación. ¿Por qué?

1. Tienes que elegir una clave de fragmentación. Si conoces las características de tu sistema antes de elegir una clave de fragmentación, puedes ahorrarte a tí mismo un mundo de dolor.
2. La fragmentación añade complejidad.: tienes que mantener trazabilidad de más máquinas y procesos.
3. La optimización prematura es la raíz de todo mal. Si tu aplicación no se ejecuta rápido, ¿está tu CPI o tu red limitadas? ¿Tienes demasiados índices? ¿Demasiados pocos? ¿Están siendo golpeados por tus consultas? Verifica (al menos) todas estas causas primero.


Usar la fragmentación

Un fragmento está definido como uno o más servidores con un maestro. Asi, un fragmento podría ser un simple mongod (mala idea), una configuración maestro-esclavo (mejor idea), o un conjunto de ráplica (mejor idea).

Digamos que renemos tres fragmentos y cada uno de ellos es un conjunto de réplica. Para tres fragmentos, querrás un mínimo de 3 servidores (la regla general es: mínimo de N servidores para N fragmentos). Haremos también el mínimo en los conjuntos de réplica: un maestro, primario y árbitro para cada conjunto. 

Las tazas son procesos MongoDB. Así, tenemos tres conjuntos de réplica:

“M” representa al “maestro” (master), “S” representa al “esclavo” (slave), y “A” representa el "árbitro" (arbiter). Tenemos también los servidores de configuración:

y procesos mongos:

Ahora, soporta estos procesos en servidores (las bandejas son servidores). Cada maestro necesita hacer mucho, así que cada primario toma su propio servidor.

Ahora ponemos también un esclavo y un árbitro en cada caja.

Observar cómo mezclamos las cosas: sin conjunto de réplica está alojado en un servidor simple, así que si un servidor se cae, el conjunto puede recuperarse en un servidor diferente y seguir funcionando.

Ahora podemos añadir tres servidores de configuración y dos procesos mongos. Los procesos mongos son puestos normalmente en el appserver, pero son muy ligeros, así que soportaremos un par de ellos aquí.

Un poco cargado, pero posible

En caso de emergencia...

Digamos que caemos una bandeja. CRASH! Con esta configuración, tus datos están a salvo (mientras estés usando w) y el cluster no pierde funcionalidad (en términos de lecturas y escrituras).

Los trozos no estarán disponibles para migrar (debido a que uno de los servidores de configuración está caído), así que un fragmento puede estar "hinchado" si el servidor de configuración está caído por mucho tiempo.

Las particiones de red y perder dos servidores son problemas grandes, así que deberías tener más de tres servidores si quieres gran disponibilidad.


Fuente original: http://www.snailinaturtleneck.com/blog/2010/08/09/sharding-and-replica-sets-illustrated/Technology IT News


MongoDB: Tres consejos para la consola
2010-11-29T08:17:00.002+01:00
La consola MongoDB es una herramienta administrativa poderosa. Algunas de sus características más útiles no son ampliamente conocidas.

1. Puedes ejecutar ficheros JavaScript

Si tienes una serie de comandos que debes mantener ejecutando, considera ponerlos en un fichero. Por ejemplo, si quieres escribir tu propia versión de mongostat con una única operación de información, puedes crear un fichero llamado myMongoStat.js:

// Impresión de la cabecera
print("inserts\tqueries\ tupdates\tdeletes");

// Impresión constante de las estadísticas
while (true) {
var stats = db.serverStatus();

print(stats.opcounters. insert+"\t"+
stats.opcounters.query+"\t"+
stats.opcounters.update+"\t"+
stats.opcounters['delete']);

sleep(1000);
}

Cosas a anotar: 

* No puedes usar asistentes de la consola: cosas como "use foo" ó "show dbs".  Para hacer ésto, utiliza los comandos equivalentes de la base de datos (db.getSisterDB("foo") ó admin = db.getSisterDB("admin"); admin.runCommand({ listDatabases:1}) , respectivamente.
* "delete" es una palabra reservada en JavaScript, así que no puedes escribir stats.opcounters.delete, si no que tienes que usar un obtenedor de estilo array asociativo (stats.opcounters["delete"]).

Para eje utar este script, abrir un termina y escribir:

$ ./mongo myMongoStat.js

Puedes hacer ésto con cualquier serie de comandos que utilices regularmente.

2. Puedes ver (casi) el código fuente de cualquier función

¿Curioso con lo que find() está haciendo? ¿No puedes recordar los parámetros de update()?  Simplemente ejecuta el comando sin los paréntesis y la consola mostrará su código fuenrte:

> db.foo.update
function (query, obj, upsert, multi) {
assert(query, "need a query");
assert(obj, "need an object");
this._validateObject(obj);
this._mongo.update(this._ fullName, query, obj, upsert ? true : false, multi ? true : false);
}

Por instancia, si intentas imprimir el código de la función nativa Date.parse(), obtendrás lo siguiente:

> Date.parse
function parse() {
[native code]
}

3. Puedes ejecutar cualquier programa

Una característica de la consola poco conocida e indocumentada es que puedes ejecutar cualquier ejecutable desde la consola.

> runProgram("ls", "-l")
sh7056| -rwxr-xr-x  1 root root 41224968 2010-06-01 18:21 mongo
sh7056| -rwxr-xr-x  1 root root 41224968 2010-06-01 18:21 mongod
sh7056| -rwxr-xr-x  1 root root 41224968 2010-06-01 18:21 mongodump
sh7056| -rwxr-xr-x  1 root root 41195810 2010-06-01 18:21 mongoexport
sh7056| -rwxr-xr-x  1 root root 41204267 2010-06-01 18:22 mongofiles
sh7056| -rwxr-xr-x  1 root root 41237850 2010-06-01 18:22 mongoimport
sh7056| -rwxr-xr-x  1 root root 41275461 2010-06-01 18:23 mongorestoreTechnology IT News


MongoDB: Consejos sobre diseño de esquemas
2010-11-29T08:17:00.000+01:00
El diseño de esquemas es una de las tareas más exigentes para nuevos usuarios de MongoDB. A menudo hay más de un modelo de datos viable, dependiendo de las necesidades de la aplicación, y los sacrificios han de ser medidos. Obtener un buen modelo de datos viene con la experiencia, y desde luego algo de experiencia con MongoDB es siempre útil. Pero si estás empezando, he aquí algunas ideas útiles a tener en mente.

Entender las características de MongoDB
Entender el conjunto de características de MongoDB es el primer paso para decidir qué patrones de modelo de datos tienen sentido. Por instancia, la habilidad de indexar claves de array y documentos internos, hacen viable el modelo de riqueza de documento. Si estás teniendo problemas modelando datos, primero asegúrate que entiendes las características de las bases de datos. E incluso si eres un veternao con MongoDB, asegúrate de mantener las últimas actualizaciones. Los operadores $slice y $or, recientemente añadidos, por ejemplo, te permiten mucha más flexibilidad en algunos casos.

Uso de documentos ricos
Parte de la belleza de MongoDB es su capacidad para almacenar estructuras de documentos ricos. Esto permite a los desarrolladores respresentar sus entidades de modelo de datos más holísticamente que lo que podrían hacer con una base de datos relacional. Mientras que en una base de datos relacional, una entidad producto puede ser dividida en docenas de tablas, el mismo producto puede guardarse en un documento simple en MongoDB. Que MongoDB pueda actuar en documentos ricos, usando la notación punto del lenguaje de consulta y una lista creciente de operadores de consulta y actualización, es la razón más convincente para considerar las estructuras ricas de documentos en tus esquemas.

Normalizar cuando sea necesario
Con todo lo dicho, no hay nada malo al migrar hacia una representación más normalizada. Algunos desrrolladores sienten que MongoDB no debería ser usado para almacenar relaciones entre colecciones, pero esto no podría estar más lejos de la verdad. Es una práctica común usar múltiples colecciones cuando las entidades involucradas necesitan la máxima cantidad de flexibilidad. Por instancia, si se representan productos y reseñas, recomendamos normalmente tener una colección separada para cada una. Las reseñas necesitan ser actualizadas y consultadas en una variedad de formas, y usualmente tienen en sí mismas una estructura de documento rica, conteniendo votos y otras bondades, información de perfil de usuario, etc. Podría preocuparte que normalizar algo como esto sin joins es ineficiente, así que será necesaria más de una consulta para visualizar una página de productos y sus reseña. Pero MongoDB es muy rápido; un pequeño benchmarking muestra que múltiples consultas no serán un problema para mayor parte de los casos.

Hay mucho más sobre el diseño de esquemas. La siguiente presentación aporta más información:

The MongoDB Metamorphosis: Data as DocumentsView more presentations from kbanker.
Technology IT News


MongoDB y Ruby
2010-11-29T08:16:00.001+01:00
Estupenda presentación de Kyle Banker en la Mongo France celebrada el pasado día 21 de Junio en París, donde explica la sinergia de MongoDB y el lenguaje de programación Ruby, con multitud de ejemplos y casos. También expone casos de normalización y desnormalización, y cuándo embeber y anidar documentos. Muy interesante.

MongoDB and Ruby - MongoDB France, 22 June, 2010 View more presentations from kbanker.
Technology IT News


MongoDB: Presentación sobre la fragmentación
2010-11-29T08:15:00.001+01:00
Interesante presentación de Eliot Horowitz que esboza en líneas generales cómo será la característica de fragmentación en MongoDB.
Sharding with MongoDB (Eliot Horowitz)View more presentations from MongoSF.
Technology IT News


Minitutorial: Vistazo rápido a MongoDB
2010-11-29T08:14:00.001+01:00
En las próximas líneas se presenta un pequeño y rápido tutorial que abarca las nociones más básicas y elementales de MongoDB y la consola mongo. Este minitutorial está extraído del Tiny MongoDB Browser Shell (http://try.mongodb.org), el cual recomiendo utilizar para una toma de contacto y entender los conceptos.

1. Consola JavaScript
La primera cosa a destacar es que la consola MongoDB está basada en JavaScript.
De esta manera, puedes hacer cosas como éstas:

a = 5; 
a * 10; 
for(i=0; i<10; i++) { print('hello'); };


2. Documentos
MongoDB es una base de datos basada en documentos. Esto significa que almacenamos los datos como documento, lo cual es similar a los objetos JavaScript. A continuación hay algunos objetos JS de muestra:

var a = {age: 25}; 
var n = {name: 'Ed', languages: ['c', 'ruby', 'js']}; 
var student = {name: 'Jim', scores: [75, 99, 87.2]};


3. Guardar
He aquí cómo se guarda un documento en MongoDB:

db.scores.save({a: 99}); 

Esto dice, "guarda el documento '{a: 99}' en la colección 'scores'."

Para ver si el documento fue guardado:

db.scores.find();


4. Guardar y consultar
Lo siguiente añade algunos documentos a la colección scores:

for(i=0; i<10; i++) { db.scores.save({a: i, exam: 5}) }; 

Al escribir 

db.scores.find(); 

Verás si se guardaron correctamente. Desde la consola sólo se visualizan 10 resultados al mismo tiempo, por lo que neceistarás el comando 'it' para iterar sobre el resto.


5. Consultas básicas
Vamos a realizar consultas más específicas, por ejemplo, consultando todos los documentos donde a == 2:

db.scores.find({a: 2});

o todos los documentos donde a > 15:

db.scores.find({a: {'$gt': 15}}); 


6. Operadores de consulta
$gt es uno de los operadores especiales de consulta. He aquí algunos otros:

$lt  - '<',   $lte - '<=', 
$gte - '>=',  $ne  - '!='
$in - 'está en un array',  $nin - '! (no) en array'

db.scores.find({a: {'$in': [2, 3, 4]}}); 
db.scores.find({a: {'$gte': 2, '$lte': 4}}); 


7. Actualizaciones
Vamos a crear un par de documentos para actualizarlos después:

db.users.save({name: 'Johnny', languages: ['ruby', 'c']}); 
db.users.save({name: 'Sue', languages: ['scala', 'lisp']}); 

Asegúrate de que se han guardado llamando a db.users.find()

Actualizaremos el primer documento mediante:

db.users.update({name: 'Johnny'}, {name: 'Cash', languages: ['english']}); 


8. Operadores de actualización
La anterior actualización reemplazó el documento entero, pero MongoDB también soporta actualizaciones parciales en los documentos. Por ejemplo, para establecer un valor:

db.users.update({name: 'Cash'}, {'$set': {'age': 50} }); 

También puedes poner (push) y extraer (pull) elementos de los arrays:

db.users.update({name: 'Sue'}, {'$pull': {'languages': 'scala'} }); 
db.users.update({name: 'Sue'}, {'$push': {'languages': 'ruby'} }); 


9. Eliminar datos
Para eliminar todo en una colección:

db.scores.remove();

Para eliminar sólo los documentos coincidentes, agrega un selector de consulta al método remove:

db.users.remove({name: 'Sue'});


10. ¿Lo siguiente?
Hay mucho más que lo mostrado en este minitutorial. Si te ha interesado, te animo a que te descargues MongoDB (http://www.mongodb.org/display/DOCSES/Descarga) y lo pruebes. También puedes consultar la documentación (http://www.mongodb.org/display/DOCSES/Inicio) para más información.Technology IT News


MongoDB: Consistencia distribuida. Parte 6
2010-11-29T08:13:00.001+01:00
El siguiente diagrama (click para verlo en grande) muestra varios modelos de consistencia que han sido discutidos en esta serie. Los modos de consistencia fuerte generalmente encuentran los requerimientos de los modos débiles, y así de este modo se muestran como subconjuntos en este diagrama tipo Venn.

Ten en mente que para muchos productos, la consistencia es afinable: un producto no pertenece necesariamente a un rectángulo en particular, pero una opración dada ciertamente lo es.



* Consistencia eventual - la consistencia eventual definica por Amazon en el papel dynamo.
* Consistencia de lectura monotónica - Una forma estricta de consistencia eventual.
* Consistencia lee-tus-propias-escrituras - una forma estricta de consistencia eventual.
* MRC + RYOW - un sistema con propiedades lectura monotónica más lee-tus-propias-escrituras. Un sistema de replicación maestro-maestro, donde un cliente dado siempre interactúa con un maestro simple, podría tener estas propiedades.
* Consistencia inmediata - un sistema que es inmediatamente consistente pero que no soporta operaciones atómicas. Los sitemas de quorum stricto, donde R+W>N, conocen este criterio (y teóricamente podrían hacer más, depende del diseño).
* Consistencia fuerte - un sistema que soporta operaciones lectura/escritura atómicas en entidades simples de datos. Este es el modo por defecto de MongoDB.
* Transacciones completas - Oracle

Fuente: http://blog.mongodb.org/post/523516007/on-distributed-consistency-part-6-consistency-chartTechnology IT News


MongoDB: Consistencia distribuida. Parte 5
2010-11-29T08:12:00.002+01:00
En la parte 2 hablamos someramente sobre consistencia eventual de "escritor simple". Aquí discutiremos sobre muchos escritores, y definiremos este término con más precisión.

Por "muchos escritores" nos referimos a un sistema donde diferentes servidores de datos pueden recibir concurrentemente escrituras (y asíncronas). Algunos ejemplos de sistemas que reciben escrituras eventualmente consistentes:

* Amazon Dynamo
* Replicación CouchDB maestro-maestro

Con la consistencia eventual multi-escritora, necesitamos direccionar el fenómeno de conflicto de escrituras. Las escrituras a dos servidores al mismo tiempo pueden actualizar el mismo objeto. Hemos de solucionar el conflicto de una manera que sea aceptable para el caso en cuestión. Algunas soluciones podrían ser:

* Última escritura gana
* Fusión programática
* Operaciones conmutativas


Última escritura gana

Última escritura gana es un popular método por defecto en muchos sistemas. Si recibimos una operación que es antigua, simplemente la ignoramos. En un sistema distribuido, la definición de "último" es tan duro que los relojes no pueden ser sincronizados perfectamente. Así que muchos sistemas utilizan un vector de relojes.

Inserciones

Sorprendentemente, una operación tradicional de inserción es delicada con muchos escritores. Considera estas operaciones realizadas al mismo tiempo en diferentes servidores:

op1: insert( { _id : 'joe', age : 30 } )
op2: insert( { _id : 'joe', age : 33 } )

Si aplicamos nativamente estas dos operaciones en cualquier orden, obtendremos un resultado inconsistente. Insertar significa típicamente:

if( !already_exists(x._id) ) then set( x );
si( !ya_existe(x._id) ) entonces establece( x );

Sin embargo, con la consistencia eventual no tenemos un estado global en tiempo real. Verificar already_exists() es delicado.

La mejor solución no es soportar la inserción, si no más bien set() (establece()) - por ejemplo, "establece un nuevo valor".  A veces, a ésto se le llama un upsert.  Entonces, si tenemos semánticas última-escritura-gana, todo va bien.

Eliminaciones

La eliminaciones requieren de una manipulación especial en caso de objetos renacidos. Considera esta secuencia:

op1: set( { _id : 'joe', age : 40 } }
op2: delete( { _id : 'joe' } )
op3: set( { _id : 'joe', age : 33 } )

Si op2 y op3 invierten el orden de ejecución, podríamos tener un problema. Así que necesitamos recordar el borrado por un momento, y aplicar semánticas de última-operación-gana.  Algunos productos llaman al recuerdo del borrado una lápida.

Actualizaciones

Las actualizaciones tienen un asunto similar a las inserciones, así que para las actualizaciones, usamos la operación set() tal y como se describió anteriormente.

Nótese que las actualizaciones parciales de objeto pueden ser delicadas para replicar de forma eficiente. Considera una operación set() donde deseamos actualizar un simple campo:

  update users set age=40 where _id=’joe’

Esto no es problema con la consistencia eventual si replicamos una copia completa del objeto. Sin embargo, ¿qué ocurre si el objeto del usuario tenía 1MB de tamaño? Esto debería ir bien enviando el campo de la nueva edad y el _id, en lugar del objeto completo. Sin embargo, esto es difícil. Considera:

op1: update users set age=40 where _id='joe'
op2: update users set state='ca' where _id='joe'

No podemos replicar simplemente la actualización parcial y usar el método última-escritura-gana; la base de datos neceitará más sofisticación para manipular ésto de manera eficiente.


Fusión programática

El método última-escritura-gana es buena, pero no siempre es suficiente. Tener que resolver mediante la aplicación cliente el conflico mediante una fusión es una buena alternativa. Consideremos un ejemplo mencionado en el Papel de Amazon Dynamo: manipulaciones de carritos de la compra. Con una consistencia eventual podría no ser seguro hacer algo como:

update cart set this[our_sku].qty=1 where _id='joe'

Si hay múltiples manipulaciones del carrito, algunas podrían perderse utilizando el método última-escritura-gana. En su lugar, el papel de Dynamo habla sobre almacenar las operaciones en el objeto carrito, en lugar del estado actual de los datos. Podríamos almacenar algo como:

update cart append { time : now(), op : 'addToCart', sku : our_sku, qty : 1 }
where _id='joe'

Cuando ocurra un conflicto, los objetos carrito pueden ser fusionados. No perdemos ninguna operación. Cuando llega la hora de comprar (check out), reproducimos todas las operaciones, lo cual podría incluir ajuste de cantidades y eliminaciones desde el carrito. Después de la reproducción tenemos el estado final del carrito.

Los ejemplos anteriores utilizan un campo timestamp - en un sistema real se puede usar un vector para ordenar las operaciones en el carrito.

Es interesante notar que no sólo hemos evitado conflictos, si no que también somos capaces de realizar operaciones donde la atomicidad sería requerida.


Operaciones conmutativas

Si todas las operaciones son conmutativas (más precisamente, plegables), nunca tendremos ningún conflicto. Las operaciones pueden ser aplicadas simplemente en cualquier orden, y el resultado sería el mismo. Por ejemplo:

// x starts as { }
x.increment('a', 1);
x.increment('a', 3);
x.addToSet('b', 'foo');
x.addToSet('b', 'bar');
result: { a : 4, b : {bar,foo} }

// x starts as { }
x.addToSet('b', 'bar');
x.increment('a', 3);
x.increment('a', 1);
x.addToSet('b', 'foo');
result: { a : 4, b : {bar,foo} }

Sin embargo la composición de addToSet e increment podría no ser plegable; de este modo, tenemos que usar sólo uno o el otro para un campo particular del objeto.

Fuente: http://blog.mongodb.org/post/520888030/on-distributed-consistency-part-5-many-writerTechnology IT News


MongoDB: Consistencia distribuida. Parte 4
2010-11-29T08:11:00.003+01:00
La consistencia eventual hace más fácil el almacenamiento de datos en un centro multi-datos. Hay razones por las que la consistencia eventual es útil para centros multi-datos que no están relatados para la disponibilidad y CAP. Como se mencionó en la parte 3, algunos tipos comunes de particiones de red, tales como la pérdida de un centro de datos entero, son actualmente particiones de red triviales y pueden incluso no tener efecto de disponibilidad de todos modos.

Hay algunas arquitecturas para el almacenamiento de datos en un centro multi-datos:

* DR
* Región simple
* Lecturas locales, escrituras remotas
* Búsqueda inteligente
* Consistencia eventual

DR

Por DR nos referimos a una arquitectura tradicional de continuidad desastre recuperación / negocio. Es bastante simple: servimos cualquier cosa desde un centro de datos, con replicación a una facilidad secundaria que está offline. En un fallo transferimos todo de forma sincronizada.

La disponibilidad puede ser muy alta en este modelo, cuando cualquier asunto sobre el primer centro de datos, incluyendo las particiones de red internas, transferimos sincronizadamente, y con todo el primer centro de datos desactivado, la partición es trivial.

Este modelo funciona bien con consistencia fuerte.

Centro multi datos, Región simple

Esta opción es análoga a usar múltiples centros de datos dentro de una región simple. Amazon y DoubleClick han usado este esquema en el pasado. Tenemos múltiples centros de datos, separados físicamente, pero todo dentro de una región (por ejemplo, el Noroeste).  La latencia entre centros de datos es entonces razonable: si permanecemos dentro de un radio de 150 millas, podemos tener transmisiones de cerca de 5 milisegundos. Podríamos tener un anillo de fibra entre digamos, 3 o 4 centros de datos. Como la latencia es razonable, para muchos problemas, una operación WAN aquí está bien. Con una topología de anillo, una partición de red no-trivial es poco probable.

La región simple es útil tanto para arquitecturas de consistencia fuerte como para consistencia eventual. Con un producto del estilo Dynamo, cuando N=W ó N=R, esta es una buena opción, por lo demás cuando se usan múltiples centros de datos tendremos un tiempo de espera grande para confirmar escrituras remotas.

Lecturas locales, Escrituras remotas

Para casos de lectura pesada, esta es una buena opción. Aquí leemos datos eventualmente consistentes (fácil con la mayor parte de productos de base de datos, incluyendo sistemas RDBMS), pero haciendo que todas las escrituras vuelvan a la facilidad maestro sobre la WAN. Un sistema del estilo dynamo en un cento de datos múltiple con un muy alto valor W y un bajo valor R puede ser también considerado de esta manera.

Este patrón debería funciona muy bien para gestión de contenidos tradicionales: publicar no es frecuente, y leer es muy frecuente.

Usar una Red de Entrega de Contenidos (Content Delivery Network (CDN)), con un sitio web origen centralizado sirviendo contenidos dinámicos, es otro ejemplo.

Búsqueda inteligente

Discutimos un poco sobre "Búsqueda Inteligente" (“Intelligent Homing”) en la parte 3. La idea es almacenar la copia maestra de una entidad de datos dada cerca de su usuario.

Esto funciona funciona muy bien si los datos se correlacionan con el usuario, como el perfil del usuario, la bandeja de entrada, etc

Tenemos rápidas escrituras confirmadas localmente. Si un centro de datos se cae completamente, podríamos estar aún a prueba de fallos sobre el estado maestro a cualquier lugar donde haya una réplica.

Consistencia eventual

La consistencia eventual de muchos-escritores nos brinda dos beneficios con centros de datos múltiples:

* altísima disponibilidad en el caso de apagones de red;
* rápidas escrituras confirmadas localmente

En el diagrama de debajo, un cliente de un sistema del estilo dynamo escribe los datos a cuatro servidores (N=4). Sin emabargo, únicamente espera confirmación de las escrituras de dos servidores en su centro de datos local, para mantener la latencia baja en la confirmación de escritura.



Nótese sin embargo que si R+W > N, no podemos tener rápidas lecturas y escrituras locales al mismo tiempo si todos los centros de datos son pares iguales.

Combinaciones

Las combinaciones a menudo tienen sentido. Por ejemplo, es común mezclar DR y Lectura Local / Escritura Remota.

Fuente: http://blog.mongodb.org/post/516567520/on-distributed-consistency-part-4-multi-data-centerTechnology IT News


MongoDB: Consistencia distribuida. Parte 3
2010-11-29T08:11:00.001+01:00
Es fascinante que la sentencia formal del teorema para CAP, en la primera prueba no usa la palabra partición.

Teorema 1. Es imposible en el modelo asíncrono de red para implementar un objeto de datos lectura/escritura que garantice las siguientes propiedades:
• Disponibilidad
• Consistencia atómica en todas las ejecuciones aceptables (incluyendo aquellas en las que los mensajes están perdidos).

Lo dicho, hablemos sobre las particiones, como "mensajes perdidos...en el modelo de red asíncrono" es directamente análogo. 

Echemos un vistazo a un ejemplo:



En el diagrama anterior, la red está particionada. Las mitades izquierda y derecha (quizá éstas correspondan a dos continentes) no se pueden comunicar del todo. Cuatro clientes y cuatro nodos de servidor de datos son mostrados en el diagrama. Así que ¿cuáles son nuestras opciones?

1. Denegar todas las escrituras. Si denegamos todas las escrituras entonces la red está particionada, podemos aún escribir datos completamente consistentes en ambos lados. Así que ésta es una opción. Obtenemos disponibilidad para escribir, y consistencia sostenida.
2. Permitir escrituras en un lado. Mediante algún tipo de mecanismo de consenso, podríamos dejar que un lado de la partición "gane" y tener un maestro (mostrado en el diagrama con "M"). En este caso, las lecturas y escrituras podrían ocurrir en ese lado. En otras particiones no-maestras, podríamos tanto (a) ser estrictos y no permitir operaciones, o (b) permitir lecturas eventualmente consistentes, pero no escrituras. Así, en esta situación tenemos consistencia completa en una partición, y operación parcial en el resto.
3. Permitir lecturas y escrituras en todas las particiones. Aquí, mantenemos disponibilidad, pero debemos sacrificar consistencia fuerte. Una partición no verá las operaciones y el estado de la otra hasta que la red sea restaurada. Una vez restaurada, necesitaremos un método para fusionar las operaciones que ocurrieron mientras estaba desconectado.

Una técnica de mitigación también viene a la mente. Supón que un cliente particular C tenga mucha más probabilidad de necesitar una entidad X que otros clientes. Si almacenamos la copia maestra de X en un servidor dedicado a C, incrementamos la probabilidad de que C pueda leer y escribir X en la anterior opción (2). Llamemos a ésto "buscador inteligente". Un ejemplo del mundo real de ésto podría ser "almacenar copias maestras de datos para los usuarios de la costa este en la costa este". La búsqueda inteligente no soluciona nuestros problemas, pero podría probablemente reducir su frecuencia.

Afortunadamente lo anterior es una buena "prueba" informal de CAP. Es realmente bastante simple. 

Particiones de red triviales

Muchas particiones de red comunes son lo que nosotros podemos denominar triviales. Considerémoslo desde la perspectiva de la anterior opción (2). Definimos que una partición de red trivial es una tal que en todas las particiones no-maestras, no hay  

* clientes vivos en todos, o 
* servidores en todos

Por ejemplo si tenemos muchos centros de datos y nuestros clientes son navegadores web de Internet, y uno de nuestros centros de datos se hace completamente oscuro (y nos quedan más), es una partición de red trivial (asumimos aquí que podemos fallar sobre el estado maestro en tal situación). Asimimismo, perder un estante simple en su integridad es a menudo una partición de red trivial.



En estas situaciones, puede aún ser consistente y disponible. (Bien, para los clientes particionados, estamos no disponibles, pero por supuesto es una certeza si no puede alcanzar ningún servidor en ningún sitio)

Fuente: http://blog.mongodb.org/post/505822180/on-distributed-consistency-part-3-networkTechnology IT News


MongoDB: Consistencia distribuida. Parte 2
2010-11-29T08:10:00.001+01:00
En la parte 1, discutimos los comportamientos de la clase C y la clase A. Para la clase A, necesitamos restriccciones de consistencia débiles. Esto no significa que el sistema necesite estar completamente inconsistente, pero ello significa que necesitaremos relajar el modelo de consistencia a alguna extensión. 

Amazon popularizó el concepto de "Consistencia eventual". Su definición es:

el sistema de almacenamiento garantiza que si no se realizan nuevas actualizaciones al objeto, eventualmente todos los accesos retornarán el último valor actualizado

Esto no es nuevo, pero es grande tener el concepto formalizado/popularizado: Unos pocos ejemplos de sistemas eventualmente consistentes:

1. DNS 
2. Replicación asíncrona maestro/esclavo en un RDBMS (también en MongoDB)
3. memcached en frente de mysql, cacheando lecturas

Muchos (no todos) ejemplos tradicionales que vienen a la mente tienen lecturas eventualmente consistentes, excepto un escritor simple (por "escritor simple" entendemos un servidor de datos, no los clientes). Las cosas se consiguen más interesantes - y complejas - cuando hay muchos escritores. Amazon Dynamo es un ejemplo de sistema de "muchos escritores eventualmente consistentes". Todo lo anterior sea quizás "escritor simple eventualmente consistente".

Cabe destacar otra tecnología tracional que son las colas de mensajes. Estas tienen propiedades reminiscentes de consistencia eventual.

Formas de consistencia

Tomemos un vistazo a un ejemplo particular. Considera un sistema usando MongoDB en la siguiente configuración:



“master” (maestro), “slave” (esclavo), y “slave” podrían ser instancias mongo por ejemplo - u otras bases de datos con replicación asíncrona. Los clientes leen aleatoriamente de cualquier esclavo para una consulta dada, y siempre escribe en el maestro. Dos esclavos y dos clientes son mostrados, pero se asume que cada uno de ellos escalan horizontalmente (scale out)

Este tipo de sistema es lo que calificamos como "escritor simple de consistencia eventual". Así que ¿cuáles son sus propiedades? (1) Un cliente puede leer datos antiguos. (2) El cliente podría ver operaciones de escritura fuera de servicio.

Supongamos que estamos almacenando alguna entidad x en el repositorio. Asumimos que las entidades tienen un valor inicial de cero. Hay una serie de escrituras a x por clientes:

W(x=3), W(x=7), W(x=5)

Debido a que el sistema es eventualmente consistente, si las escrituras a x se detienen en algún punto, sabemos que leeremos eventualmente 5 — que es, R(x==5).  Sin embargo a corto plazo un cliente podría por ejemplo ver:

R(x==7), R(x==0), R(x==5), R(x==3)

(Nota: más nodos que 2 esclavos son necesarios para este ejemplo de comportamiento)

Así que es nuestra forma más débil - eventualmente consistente con lecturas fuera de servicio a corto plazo. 

Podemos hacer ésto más fuerte. considera la configuración mongodb SourceForge  (diagrama grande aquí).  Esta configuración es eventualmente consistente, pero no veremos el resultado de las escrituras fuera de servicio. Esto provee consistencia de lectura monotónica.



Una posible propiedad de consistencia eventual es la consistencia lee-tus-propias-escrituras, lo que significa que un proceso está garantizado para ver que las escrituras se han hecho cuando se han leído. Esta es una propiedad muy útil que hace la programación más fácil. Nótese que ninguno de los ejemplos de arriba proveen consistencia lee-tus-propias-escrituras. También el valor a considerar con este modelo es la definición de "tu". En una aplicación web, que puede ser el usuario. Si el balanceador de carga del sistema envía peticiones a diferentes servidores de aplicaciones, tener consistencia lee-tu-propia-escritura para un servidor de aplicaciones simple no soluciona la necesidad de consistencia en el mundo real.

Caso de uso checklist EC

Así que cuando se usa consistencia eventual, es bueno para la arquitectura preguntarse:

* ¿mi caso de uso puede tolerar lecturas antiguas?
* ¿puede tolerar lectura de valores fuera de servicio? si no, ¿es mi configuración de lectura monotónica consistente?
* ¿puede tolerar no leer mis propias escrituras? si no, ¿es mi configuración lee-tu-propia-escritura consistente?

Fuente: http://blog.mongodb.org/post/498145601/on-distributed-consistency-part-2-some-eventualTechnology IT News


MongoDB: Consistencia distribuida. Parte 1
2010-11-29T08:09:00.001+01:00
Para las bases de datos distribuidas, los modelos de consistencia son un tópico de gran importancia. Nos gustaría hurgar un poco más en profundidad en este tópico con una serie de artículos, discutiendo asuntos tales como qué modelo es correcto para un caso de uso en particular. 

Empezaremos aquí con una introducción básica sobre este tema.

CAP

El teorema de CAP (Capability (Capacidad), Availability (Disponibilidad) y Partitions (Particiones)) plantea que uno puede sólo tener dos características al mismo tiempo de consistencia, disponibilidad y tolerancia a particiones de red. En sistemas distribuidos, el particionamiento de red es inevitable y debe ser torleado, así que el CAP esencial significa que no podemos tener tanto consistencia como disponibilidad al 100%. 

Informalmente, deberíamos resumir el teorema de CAP como:

* Si la red se cae, tu base de datos no funcionará.

Sin embargo, hemos de afinar la definición de "no funcionará". Esto puede significar tanto caída (no disponible) como inconsistencia (datos viejos).

¿Qué queremos decir -más precisamente- con "consistencia"? El trabajo académico en este área se refiere a "una copia de serializabilidad" o "linearizabilidad". Si una serie de operaciones o transacciones son realizadas, éstas son aplicadas en un orden consistente. Una forma menos formal de pensar sobre compensación sería "¿Podría leer y manipular datos viejos/contaminados? ¿Puedo siempre escribir?"

Encarnaciones

Tenemos dos clases de arquitectura: una clase C (fuertemente consistente) y una clase A (alta disponibilidad con pérdida de consistencia). Consideremos algunos sistemas distribuidos del mundo real y dónde están clasificados.

Amazon Dynamo es un repositorio de datos distribuido, el cual implementa hashing consistente y que está en el grupo A. Provee consistencia eventual. Uno puede leer datos antiguos.

CouchDB es típicamente utilizada con replicación asíncrona maestro-maestro, y está en el grupo A. Provee consistencia eventual.

Un cluster MongoDB auto-fragmentación+replicación tiene un servidor maestro y un punto dado en el tiempo para cada fragmento (shard). Éste está en el grupo C. Los sistemas RDBMS tradicionales también tienen consistencia fuerte (como son típicamente utilizadas) - un cluster RDBMS síncrono, por ejemplo.

Cabe destacar que las configuraciones alternativas de estos productos a veces alteran su propiedades de consistencia (y rendimiento). Para nuestra discusión aquí, asumiremos que estos productos están configurados en su caso común, a menos que se indique otra cosa.

Disponibilidad para escritura, no disponibilidad para lectura, es la cuestión principal

Con la mayor parte de las bases de datos actuales, es fácil tener cualquier número de réplicas asíncronas distribuidas en el mundo. Si se particionan las redes, debemos tener entonces acceso a los datos esclavos locales. Cuando la replicación es asíncrona, estos datos son eventualmente consistentes, así que este resultado no es sorprendente - estamos ahora en la clase A de sistemas. Sin embargo, casi todos los diseños, incluso de la clase C, pueden añadir fácilmente capacidades de lectura asíncrona. Así, las decisiones de diseño crítico son sobre la capacidad de escritura.

Las compensaciones

* incluso la distribución de carga es más fácil en sistemas eventualmente consistentes
* el centro de soporte multi-datos es más fácil en sistemas eventualmente consistentes
* algunos problemas no son solucionables con sistemas eventualmente consistentes
* a veces el código es más fácil escribirlo en sistemas fuertemente consistentes

Discutiremos sobre los pros y contras en detalle en los artículos subsecuentes.

Fuente: http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1Technology IT News


MongoDB: El buen uso de los índices
2010-11-29T08:08:00.001+01:00
Los índices son referencias a los documentos Mongo, ordenados de forma eficiente por una clave o campo. Estas referencias están almacenadas en una estructura de árbol, permitiendo una búsqueda rápida y eficiente. Los índices son uno de los recursos más estimados en MongoDB, y saber aprovechar su capacidad nos permitirá optimizar el acceso a los datos. Pero también es un arma de doble filo, que puede darnos problemas si no se sabe utilizar correctamente.

Básicamente, se aplican dos reglas básicas a la hora de aplicar un índice:
- A claves o campos por los que se suele realizar búsquedas.
- A claves o campos que suelene ser ordenados.

CASOS

Vamos a ver algunos casos sobre el uso adecuado de índices. Los ejemplos toman en consideración una colección llamada "col", donde los documentos tienen las claves x e y, y el índice (salvo que se indique otra cosa) está construído sobre x.

Caso 1: Usar db.col.find({$where:"this.x==this.y"})
Los índices no pueden usarse en consultas tipo $where. Sin embargo, en consultas de tipo non-$where, es eficiente usar índices sobre los elementos non-$where.

Caso 2: Rangos usando db.col.find({x:/a/}
La letra 'a' puede aparecer en cualquier parte del campo, por lo que no es eficiente para la ordenación. Sin embargo, sí sería interesante si x es una cadena o x es la expresión irregular /a/.

Caso 3: Actualización usando db.col.update({x:2}, {$inc:{x:3}})
Esta operación no está disponible en versiones antiguas de MongoDB. 

Caso 4: Ordenación rápida usando db.col.find({y:1}).sort({x:1})
El índice asegura la ordenación, pero realizado aquí no es el mejor índice.

Caso 5: Campos perdidos usando db.col.find({x:{$exists:true}})
Actualmente no se usa el índice. En versiones futuras de Mongo será tenido en cuenta.

Caso 6: Búsqueda en arrays usando db.col.find({x:{$all:[2,10]}}) teniendo en cuenta que x es un array con los valores [2,10]
El índice realizará búsquedas rápidas en todos los documentos donde coincida el array [2,10].

Caso 7: Índices compuestos usando db.col.find({y:10}).sort({x:1}), con índice compuesto x e y {x:1,y:1}
El índice asegura la ordenación, pero realizado aquí no es el mejor índice.

CREACION DE INDICES
La creación de índices en MongoDB es sencilla. Por defecto, siempre se crea un índice, de forma automática, sobre la clave _id de los documentos de una colección.

Para crear un índice sobre otras claves, usar el siguiente comando:
db.col.ensureIndex({x:1})

El índice puede ser creado en cualquier momento. Si la colección tiene muchos documentos, esta operación puede tardar mucho, bloqueando otras operaciones. Para evitar ésto, se puede indicar que el índice se cree en background (en segundo plano):

db.col.ensureIndex({x:1},{background:true})

Un índice único asegura que los datos de una clave no se repitan (unicidad) y además que sean obligatorios (si no se especican valores, éstos se asumen null, y no podrían estar repetidos):

db.col.ensureIndex({x:1},{unique:true})

Si a la hora de crear el índice sobre la colección, ya existieran documentos con clave duplicada, se podría indicar que que se eliminaran los documentos duplicados:

db.col.ensureIndex({x:1},{unique:true, dropDups:true})

En este caso, sólo se mantendría el primer documento creado (en el orden natural).


MANTENIMIENTO DE INDICES
Los siguientes comandos permiten realizar algunas operaciones de mantenimiento con índices:

db.system.indexes.find({ns:'db.col'})
Muestra los índices creados en la colección 'col'.

db.col.dropIndex({x:1})
Elimina de la colección 'col' el índice sobre la clave x.

db.col.dropIndexes()
Elimina de la colección 'col' todos los índices creados.

db.col.reIndex()
Reconstruye todos los índices creados en la colección 'col'.

LIMITES DE LOS INDICES
Una pregunta interesante: ¿hay límites en los índices?:
- Máximo de 40 índices por colección
- No se previenen índices lógicamente equivalentes (por ejemplo, {x:1} y {x:-1})
- Lo índices mejoran las consultas pero que crean inserciones lentas.
- Los índices más específicos ({a:1,b:1,c:1}) pueden ser más útiles que tener que los menos específicos ({a:1} , {b:1}), pero la ordenación de los más específicos puede no ser tan rápida como en los menos específicos.

Cualquier cambio en las claves, requerirá actualizar también los índices.


Fuente consultada: http://www.slideshare.net/mongodb/indexing-with-mongodbTechnology IT News


Minitutorial de MongoDB interactivo online
2010-11-29T08:07:00.001+01:00
Ya puedes acceder a un tutorial básico y sencillo (en inglés), donde podrás conocer los comandos básicos a través de una consola online, enseñándote paso a paso cada comando, con su explicación, probando los ejemplos y viendo los resultados.

Podrás acceder al tutorial a través de la siguiente URL: http://try.mongodb.org

 

La traducción de este mini-tutorial se encuentra disponible en este enlace:
http://mongospanish.blogspot.com/2010/04/minitutorial-vistazo-rapido-mongodb.htmlTechnology IT News


JSON y ODBMS
2010-11-29T08:06:00.002+01:00
Las bases de datos orientadas a objetos son filosóficamente más diferentes de lo que uno podría esperar.

Tenemos una representación estandarizada documento/objeto - JSON es actualmente popular para almacenamientos orientados a documentos, quizá ODL en ODBMS. Lo bueno de JSON es que, al menos para programadores Web, es una tecnología que ya utilizan y con la que están familiarizados. No añadimos nada nuevo qué aprender.

En un documento, realmente estamos pensando en "documentos", no en objetos. Los objetos tiene métodos, esquemas predefinidos, jerarquías e herencias. Esto no está presente en una base de datos de documentos; el código no es parte de la base de datos.

Mientras que pueden existir relaciones entre documentos, los punteros entre documentos están desenfatizados. En el almacenamiento de documentos no persisten "grafos" de objetos - ésta no es una base de datos de grafos (las bases de datos de grafos son una nueva categoría NoSQL - ¿qué diferencia hay entre una base de datos de grafos y una ODBMS? Una pregunta interesante)

El diseño de esquema es importante en las bases de datos de documentos. No podemos pensar en términos de "solamente persiste lo que yo trabajo con memoria RAM desde mi programa". Todavía definimos un esquema. Este esquema puede variar con respecto a un "código de esquema" interno de la aplicación. Por ejemplo, en MongoDB tenemos colecciones (análogas a las tablas) de documentos JSON, y una declaración explícita de índices sobre campos específicos de la colección. Podemos pensar que esta aproximación tiene algunos méritos - un desacoplamiento de datos y de código. El código tiende a cambiar rápidamente.

Embeber es un concepto importante en el almacenamiento de documentos. Es mucho más común anidar datos dentro de documentos que tener referencias entre documentos.

¿Por qué desenfatizar las relaciones? Por un par de razones. La primera, con grafos arbitrarios de objetos, es difícil procesar el grafo desde un cliente sin muchos tiempos de espera cliente/servidor. Un objetivo con bases de datos de documentos es mantener el paradigma cliente/servidor y mantener código predispuesto para el cliente (no obstante con algunas excepciones como map/reduce). Segundo, un objetivo clave en el espacio "NoSQL" es la escalabilidad horizontal. Los grafos arbitrarios de objetos dificultarían la partición entre servidores de una manera que garantice el rendimiento.

Fuente: http://blog.10gen.com/post/437029788/json-db-vs-odbmsTechnology IT News


¿Debertía MongoDB utilizar SQL como lenguaje de consulta?
2010-11-29T08:05:00.001+01:00
MongoDB no utiliza SQL como lenguaje de consulta. ¿Por qué no?. Es una buena pregunta y en el proyecto hemos discutido sobre ello durante mucho tiempo. Existen razones para ello.

Dada la naturaleza del almacenamiento orientado a documento, si hiciéramos SQL, el mundo sería una variante, no SQL verdadero. No habría joins, y podríamos necesitar extensiones para gestionar las construcciones anidadas construídas y envueltas elegantemente en el almacenamiento JSON. Estas extensiones no harían mucho y necesitaríamos algo como la notación punto de MongoDB para alcanzar los objetos internos, algo quizá como lo siguiente:

SELECT * FROM users WHERE addr.state = ‘NY’

Para alcanzar los arrays también lo necesitaríamos:

SELECT * FROM posts WHERE comments[].author = ‘fred’

En Mongo, la sintaxis de consulta JSON de arriba, simplemente sería:

{ “comments.author” : “fred” }

El término NoSQL es un poco impreciso - estamos realmente hablando sobre escalabilidad horizontal en almacenamiento postrelacional, no sobre el lenguaje SQL. Debería considerarse la Google App Engine Data Store NoSQL, y utilizar el lenguaje de consulta GQL, similar a SQL.

La principal razón por la decisión que tomamos con el lenguaje de consulta - representando consultas como JSON - era normalizar los datos con el mecanismo de consulta tal como los almacenamos. Si estás almacenando JSON en la base de datos, ¿no podemos representar las consultas de la misma manera? Pensamos que tiene sentido.

Nunca he sido un fan de embeber un lenguaje de programación en otro. Construir cadenas SQL dinámicamente me pareció siempre un poco extraño. Prefiero representar las consultas de un modo conducido a datos.

Fuente: http://blog.mongodb.org/post/447761175/should-mongodb-use-sql-as-a-query-languageTechnology IT News


Análisis entre modelo relacional y modelo documental en bases de datos
2010-11-29T08:04:00.002+01:00
El origen de las bases de datos va ligado a la necesidad de organizar la cada vez más exigente cantidad de datos que se requieren. En los inicios, la información estaba delegada a los ficheros, como meros depósitos de información y a los que se accedía a bajo nivel para las operaciones más elementales de lectura y escritura. Con el tiempo, la información requerida se hacía mayor, y la complejidad de gestionarla también creció. Se comenzó a aplicar técnicas como índices para accesos más rápidos y para la ordenación de la misma. Pero las aplicaciones debían tratar los ficheros de forma artesanal y personalizada.

Surgieron sistemas que automatizaban las operaciones complejas de gestión  de los datos, como los  índices, así como las primeras relaciones entre campos clave entre dos o más tablas. Pioneros en estos sistemas fueron (por citar los más conocidos) fueron dBASE y Clipper, pero también empezaban a gestarse grandes bases de datos profesionales, como Oracle o DB2. Estamos hablando de los años 80.

Los dispositivos de almacenamiento eran limitados, así como la capacidad de los sistemas operativos en almacenar y direccionar información, aunque suficientes para la época. Es por ello que la optimización del espacio fuera un un factor vital, y que el diseño de las tablas contemplase el acotar el almacenamiento de cada campo, tener en cuenta el tamaño de cada fila, y prever el tamaño total de los ficheros junto con la previsión de crecimiento de los mismos.


Bases de datos relacionales

El modelo relacional surge ante estas circunstancias, postulado por Frank Codd en 1970. La normalización de los datos permite organizar la información separando en tablas la información más pequeña posible e independiente, para evitar la repetición de la misma. Para acceder a toda la información, las tablas se relacionan unas y otras mediante campos clave comunes, que suelen ser números con un id único. 

Este modelo de almacenamiento es organizado y óptimo, define unas reglas que evitan la redundancia de la información y facilitan la consistencia de los datos. Este sistema de ingeniería de la información es el que ha regido las bases de datos durante los últimos 40 años.

Para trabajar con este modelo de almacenamiento, surgió el lenguaje SQL, que facilitó el entendimiento de las relaciones a través de una sintaxis sencilla y asimilable.

Este modelo de almacenamiento tiene las siguientes ventajas:
- Sistema de normalización óptimo en almacenamiento. Idóneo para sistemas con requisitos muy claros y poco dado a cambios.
- Sistema fuertemente estructurado e interrelacionado, formando un esquema.
- Sistema unánimente aceptado y estándar, utilizado en más del 90% de las aplicaciones
- La mayor parte de fabricantes de bases de datos utilizan el SQL estándar en sus productos, si bien puede haber alguna pequeña variación fácilmente subsanable. 
- Las migraciones entre bases de datos de diferentes fabricantes  no son excesivamente impactantes
- Las consultas SQL tienen funciones agregadas de cálculo asociadas a columnas en los resultados.
- Los sistemas de bases de datos relacionales asumen el trabajo de las complejidades de la integridad referencial, velando por la consistencia de la información y liberando al desarrollador de estas tareas para que se centre solamente en las consultas.
- Multitud de herramientas productivas construídas en torno a este modelo: business intelligence, datamining, ETL, administración, monitorización, etc.
- Eficiente para gestionar datos para automatizar actividades.

Sin embargo, también conlleva algunos inconvenientes:
- La normalización  en entidades atómicas no es natural y tiende a complicar su entendimiento y los desarrollos.
- Basar la identificación de los registros y relacionar tablas por códigos numéricos es críptico y poco natural.  
- La información, tal y como está almacenada, difiere mucho de cómo es gestionada, y requiere un esfuerzo importante de adaptaciones.
- Sistema rígido y estricto poco tolerante a fallos y que penaliza los cambios. 
- La adición de entidades de relación y de campos clave a una tabla ya existente implica complejidad e impacta en los desarrollos actuales.
- Sistema que gana en complejidad a medida que crece. La escalabilidad de la estructura se torna condicionada.
- El desarrollo de las aplicaciones requiere de capacitación para conocer el modelo entidad-relación.
- El almacenamiento de toda la información requiere dividir la información en entidades atómicas y tratar éstas por separado en varios procesos.
- Las consultas requieren tracear la información separada y reunirla. Las joins suelen ser complejas y pesadas, y a veces no son suficientes, requiriendo varios procesos de consulta adicionales.
- La gestión automatizada de la integridad referencial supone una penalización de tiempo de accesos (lectura y escritura) a la información.
- La gestión automatizada de la integridad referencial no evita que el desarrollador preste atención a errores de integridad y su causa. El desarrollador debe asegurar previamente la integridad y controlar si el sistema le informa de alguna violación de reglas de integridad. Por ejemplo, la creación de una categoría de productos. El sistema informará si se está tratando de crear una categoría ya existente, y el programa debería capturar este aviso para advertir al usuario sobre la causa del problema. Otra forma (sin integridad automatizada) sería consultar previamente cuántas categorías existen con ese nombre. Si es mayor de cero advertir al usuario, y si no guardar la nueva categoría. El trabajo en ambos casos (con y sin integridad automatizada) no difiere mucho.
- La información de cada tabla está limitada a una estructura fija de campos o columnas, sean o no necesarios, y tengan o no valores. Si no se utiliza una columna, ésta se almacena de todas formas en cada fila.
- Poco eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor datos que información).
- Los principales fabricantes de sistemas de bases de datos relacionales las desarrollan de forma propietaria.


Bases de datos documentales

Las bases de datos documentales, a diferencia de las bases de datos relacionales, están libres de esquemas y de estructuras. Por tanto, la información no se divide en columnas fijas y filas, si no en documentos que pueden tener libertad de información, como cualquier cantidad de campos o de tipos de campos, e incluso de contener en el propio campo una lista de valores, un documento o una colección de documentos. La información almacenada en un documento está formado por pares de clave y valor. 

La gran ventaja de no poseer esquema (y la consiguiente rigidez de estructuras y relaciones), es que son muy eficientes al trabajar con grandes cantidades de documentos.

Las principales ventajas de una base documental son las siguientes:
- Libre de esquemas. Al no estar sujeta a estructuras ni relaciones, los cambios de diseño son fáciles de adoptar y con un impacto mínimo.
- Al no tener relaciones se facilita la replicación
- Los sistemas de bases de datos documentales ganan rapidez dedicándose más en exclusiva al almacenamiento y la recuperación de la información (no consumen tiempos en la integridad o en la revisión de las reglas o constraints).
- Poseen un lenguaje de consulta natural.
- Sencillez y potencia en escalabilidad.
- Los campos vacíos no se añaden al documento, optimizando el espacio de almacenamiento.
- Cada documento (o “fila”) puede tener estructuras diferentes (más o menos campos, tipos diferentes de datos, etc.)
- Un documento es un objeto que normalmente es mapeado mediante JSON o XML
- Posibilidad en embeber documentos y colecciones dentro de documentos. Esto solventaría joins entre documentos, aunque agregaría complejidad a la estructura del documento.
Los datos almacenados no necesitan adaptaciones por las aplicaciones (tal como se almacenan se pueden gestionar).
- Muy eficiente a la hora de explotar grandes volúmenes de información textual (maneja mejor información que datos).
- Las migraciones entre bases de datos diferentes tienen muy poco impacto, pues comparten el formato JSON o XML.
- La mayor parte de los fabricantes de sistemas de bases de datos documentales, la desarrollan como open source.
- El auge de la Web está mirando este modelo de datos como clave en sus negocios, por su mayor capacidad de escalabilidad, rendimiento y alta disponibilidad, que los actuales sistemas de bases de datos relacionales.

Los principales inconvenientes serían:
- El sistema de base de datos no contempla realizar joins entre documentos.
- Más peso por parte de las aplicaciones para asumir la integridad y la consistencia.
- No posee funciones agregadas para realizar cálculos sobre la información de las consultas.
- Redundancia de la información. Penaliza el espacio de almacenamiento en aras de una mayor rapidez de acceso y de claridad de la información.
- Menos eficiente para automatizar actividades.
- Aunque este modelo de información es anterior al relacional, aún tiene una aceptación muy baja (menos de un 10% del total de aplicaciones funcionando en el mundo).
- No hay muchas herramientas de productividad en torno a este tipo de bases de datos, como Business Intelligence, monitorización, etc.
- Aunque es posible migrar un sistema relacional a un sistema documental, la potencia de la integridad referencial ha de ser restituida por código en las aplicaciones. No merece la pena esto, y sí una restrospectiva en la que se adapte los conceptos a documentos teniendo siempre en mente las ventajas que podría ganarse en la migración.

Technology IT News


Primeros pasos en MongoDB y Linux
2010-11-29T08:03:00.002+01:00
MongoDB es una base de datos multiplataforma, con lo que no existen problemas ni apenas diferencias funcionales ni técnicas entre éstas. Donde sí puede notarse alguna diferencia es en el rendimiento y la velocidad que la propia plataforma provee. En este punto, Linux tiene algunos puntos de ventaja con respecto a plataformas Windows.

En este artículo intentaré ser lo más claro y sencillo posible para que usuarios noveles puedan entender los conceptos. Se asume que el lector ya tiene una nociones mínimas sobre el sistema operativo Linux (al menos el concepto de directorio).

Este artículo no pretende abarcar muchos conceptos, si no los primeros pasos o los conceptos más básicos para poder funcionar la base de datos y realizar las operaciones más básicas.

Los conceptos aquí explicados se pueden aplicar también a MongoDB Solaris, OS X y Windows (a excepción de la instalación).


Instalación de MongoDB en Linux

Los pasos a seguir para instalar MongoDB en Linux son muy sencillos:

1. Acceder a la página de descargas de  MongoDB en http://www.mongodb.org/display/DOCS/Downloads
2. Seleccionar la versión requerida (32bits o 64 bits)
3. Descargar la versión a nuestro disco duro
4. Abrir una consola o terminal
5. Iniciar una sesión como superusuario o root (mediante el comando “su” e introducir la contraseña del mismo)
6. Crear el directorio de datos: mkdir -p /data/db
7. Acceder al directorio donde se descargó el archivo .tz de MongoDB
8. Descomprimir este archivo en el lugar que deseemos: tar xzf mongodb-linux-i686-1.4.0.tgz

Notas:
1. En sistemas Linux antiguos podría no funcionar MongoDB. En este caso, la versión a descargar sería la legacy-static
2. La versión de 32 bits tiene una limitación de hasta 2GB por fichero de datos (más información en http://blog.mongodb.org/post/137788967/32-bit-limitations).
3. MongoDB es muy ligero. El fichero descargado ocupa apenas 23MB


Arrancar el servidor MongoDB

Una vez instalado MongoDB, acceder al directorio bin (dentro del directorio donde lo instalamos):

$ cd xxx/bin

Para ejecutar el servidor:

$ ./mongodb &

Con “&” el servidor se ejecutará en background. Esto es opcional, y al usarlo damos por hecho que el servidor estará ejecutándose de forma contínua. Si queremos parar el servidor hemos de localizar el proceso con el comando:

$ ps

PID TTY          TIME CMD
12047 pts/1    00:00:00 mongod
12343 pts/1    00:00:00 ps
14633 pts/1    00:00:00 su
14636 pts/1    00:00:00 bash

Una vez localizado, anotar el PID y especificarlo en el comando kill:

$ kill -9 12047

En el caso de no especificar “&”, el servidor de MongoDB se ejecuta de forma exclusiva en primer plano, acaparando la atención de la consola. Para para el servidor, simplemente hay que pulsar las teclas Ctrl y C.


La consola mongo

Una vez arrancado el servidor ya es posible trabajar con la base de datos. MongoDB provee de una consola (o DB Shell), donde podremos interactuar directamente con la misma. Existen también drivers para cualquier lenguaje de programación (Java, .NET, Perl, Phyton, PHP, C, C++, etc.) para su uso en nuestras aplicaciones.

Para arrancar la consola:

$ mongo

MongoDB shell version: 1.4.0
url: test
connecting to: test
Sat Mar 27 08:55:36 connection accepted from 127.0.0.1:39720 #1
type "help" for help
>

El comando “help” nos permitirá conocer un resumen de los comandos posibles:

> help
HELP
show dbs                     show database names
show collections             show collections in current database
show users                   show users in current database
show profile                 show most recent system.profile entries with time >= 1ms
use                 set curent database to 
db.help()                    help on DB methods
db.foo.help()                help on collection methods
db.foo.find()                list objects in collection foo
db.foo.find( { a : 1 } )     list objects in foo where a == 1
it                           result of the last line evaluated; use to further iterate
>

Para mostrar las bases de datos disponibles:

> show dbs
admin
local

Para obtener una ayuda sobre los comandos a utilizar con una base de datos:

> db.help()
DB methods:
db.addUser(username, password[, readOnly=false])
db.auth(username, password)
db.cloneDatabase(fromhost)
db.commandHelp(name) returns the help for the command
db.copyDatabase(fromdb, todb, fromhost)
db.createCollection(name, { size : ..., capped : ..., max : ... } )
db.currentOp() displays the current operation in the db
db.dropDatabase()
db.eval(func, args) run code server-side
db.getCollection(cname) same as db['cname'] or db.cname
db.getCollectionNames()
db.getLastError() - just returns the err msg string
db.getLastErrorObj() - return full status object
db.getMongo() get the server connection object
db.getMongo().setSlaveOk() allow this connection to read from the nonmaster member of a replica pair
db.getName()
db.getPrevError()
db.getProfilingLevel()
db.getReplicationInfo()
db.getSisterDB(name) get the db at the same server as this onew
db.killOp(opid) kills the current operation in the db
db.printCollectionStats()
db.printReplicationInfo()
db.printSlaveReplicationInfo()
db.printShardingStatus()
db.removeUser(username)
db.repairDatabase()
db.resetError()
db.runCommand(cmdObj) run a database command.  if cmdObj is a string, turns it into { cmdObj : 1 }
db.serverStatus()
db.setProfilingLevel(level,) 0=off 1=slow 2=all
db.shutdownServer()
db.stats()
db.version() current version of the server

Para probar algo, utilizaremos la base de datos “prueba”:

> use prueba
switched to db prueba

Esta base de datos aún no existe, pero al especificar este comando, MongDB se prepara para su creación.

Para obtener el nombre de la base de datos en uso:

> db.getName()
prueba

Para conocer la versión de la base de datos:

> db.version()
1.4.0

Para obtener la información del servidor MongoDB al que estamos conectados:

> db.getMongo()
{
"host" : "127.0.0.1",
"setSlaveOk" : function () {
this.slaveOk = true;
},
"getDB" : function (name) {
return new DB(this, name);
},
"getDBs" : function () {
var res = this.getDB("admin").runCommand({listDatabases:1});
assert(res.ok == 1, "listDatabases failed:" + tojson(res));
return res;
}
...


Esta información está en formato JSON (al igual que toda la información que se trata y utiliza en MongoDB), e incluye código JavaScript. Al principio obtenemos que estamos conectados a un servidor en la dirección 127.0.0.1 (localhost o máquina local). El resto son funciones disponibles para utilizar en el mismo comando. Por ejemplo, para obtener la lista de bases de datos (y su detalle) que gestiona el servidor Mongo al que estamos conectados:

> db.getMongo().getDBs()
{
"databases" : [
{
"name" : "admin",
"sizeOnDisk" : 1,
"empty" : true
},
{
"name" : "local",
"sizeOnDisk" : 1,
"empty" : true
},
{
"name" : "test",
"sizeOnDisk" : 1,
"empty" : true
}
],
"totalSize" : 0,
"ok" : 1
}


Comparativa  entre modelo relacional y modelo documental

Para que nuestra base de datos “pruebas” pueda crearse, ésta debe alojar algún dato, el cual se ubica en una colección. Podemos concebir una colección como un almacén de datos relacionados sobre una temática (agenda, noticia, pedidos, etc.). Puede tener un símil con las tablas de las bases de datos relacionales en cuanto a su concepto, pero no en cuanto a su forma, ya que las tablas tradicionales organizan la información de una manera estructura y rígida. Podemos imaginar una hoja de cálculo con x columnas (campos) y n filas (registros o tuplas). La información se almacena aquí con unas reglas estrictas. Las columnas son siempre las mismas y el tipo de datos es el mismo. Estas reglas aseguran la consistencia de la información, pero la gestión de esos datos resulta limitada a esas mismas reglas.

MongoDB es una base de datos orientada a documentos (u a objetos), y no está sometida a las reglas de las bases de datos relacionales. Por de pronto, nos olvidamos de las limitaciones de la hoja de cálculo, pues cada fila es un documento (u objeto), el cual puede ser igual, similar o distinto a los documentos precedentes o posteriores de la misma colección.

Un documento, en sí mismo, una colección de valores clave/valor, con un formato libre. De esta manera, el dato de una clave en un documento puede ser de un tipo, y en otro documento puede ser de otro tipo. Asimismo, una clave puede no estar limitada a un único valor, si no contener un array (o lista) de valores, o incluso un documento o un array de documentos (como si fuera otra colección interna (“inner”)).
Para visualizar gráficamente ésto, imaginemos una base de datos para almacenar noticias. Para no extendernos mucho, almacenaremos la noticia junto con las etiquetas de categoría y los comentarios de los usuarios.

En una base de datos relacional, necesitaríamos las siguientes tablas:

Tabla noticia
Campo id_noticia (entero, no nulo, único, clave primaria)
Campo titulo (texto(50), no nulo)
Campo fecha (fecha, no nulo)
Campo autor (texto(20), no nulo)
Campo noticia (texto grande, no nulo)

Tabla comentario
Campo id_comentario (entero, no nulo, único, clave primaria)
Campo id_noticia (entero, no nulo, clave foránea)
Campo fecha (fecha, no nulo)
Campo autor (texto(20), no nulo)
Campo comentario (texto grande, no nulo)

Tabla etiqueta
Campo id_etiqueta (entero, no nulo, único, clave primaria)
Campo etiqueta (texto(20), no nulo)

Tabla relacion_etiqueta_noticia
Campo id_noticia (entero, no nulo, clave foránea)
Campo id_etiqueta (entero, no nulo, clave foránea)

El modelo entidad relación sería el siguiente:

La normalización de los datos permite evitar la redundancia (repetición) de los mismos, y para ello se divide y se clasifica la información en diferentes tablas. Se crea un campo clave (normalmente con nombre id) que representa ese dato de forma única. En un modelo relacional, los datos están atomizados.

Este modelo ha funcionado muy bien hasta nuestros días, pero implica una complejidad asociada. Por un lado, hemos de conocer el modelo de los datos para tracear y poder reconstruir y unir de nuevo la información. A veces, con una join es suficiente, pero muchas veces hemos de realizar varios procesos dependientes unos de otros, lo que complica la programación.

En el modelo documental esto es mucho más sencillo, pues la entidad de documento es en sí un objeto, lo que podemos utilizar clases que directamente carguen los datos sin operaciones de consulta complejas ni intermedias.

Con el ejemplo propuesto, un documento en MongoDB podría ser el siguiente:

{ autor: ‘Rafael Hernamperez’,
titulo: ‘Primeros pasos en MongoDB Linux’,
fecha: Date(’03-27-2010’),
noticia: 'bla bla bla',
etiqueta: [‘opensource’,’base de datos’,’MongoDB’],
comentarios: [{autor: ‘adan3000’, fecha: Date('03/27/2010'), comentario: ‘Muy sencillo, gracias’},
{autor: ‘majopero’, fecha: Date('03/27/2010'), comentario: 'Me parece muy interesante'}
]
}

Como se puede apreciar, todo está ahí, de manera directa. No es necesario reconstruir el documento consultando diferentes fuentes, como en el modelo relacional. Si en otro documento no quiero etiquetas o comentarios, simplemente, no los pongo. Todo ésto, además de versátil y sencillo, es óptimo y legible. El modelo relacional nos obliga a estar ligando los datos a través de códigos id que para nosotros no tienen significado..

Las ventajas o inconvenientes entre estos dos modelos de datos no acaba ahí. Por ejemplo, si el día de mañana deseamos agregar galerías de imágenes o de vídeos a la noticia (o cualquier otro tipo de adición que pueda acontecer y que no tenemos previsto), se complica en el modelo relacional, pues hay que añadir nuevas tablas, nuevas claves, nuevas relaciones y nuevas reglas. El desarrollo debe añadir un extra para ligar los nuevos datos, reconstruirlos y representarlos.

Espero que en un artículo futuro pueda recopilar todas las diferencias y analizar los pros y los contras de ambos modelos.


Andando, que es gerundio

Tras la teoría del capítulo anterior, vamos a crear definitivamente la base de datos “pruebas”, creando un documento que se añadirá a una colección llamada “noticias”. Para ello, desde la consola mongo, se creará una variable que contenga el documento y, a continuación se guarda. Se puede realizar directamente, pero para dejarlo más claro, debido a lo extenso de los datos del documento, se ha preferido hacer en dos pasos:

> var noticia = {
... autor: 'Rafael Hernamperez',
... titulo: 'Primeros pasos en MongoDB Linux',
... fecha: Date('03/27/2010'),
... noticia: 'bla bla bla',
... etiqueta: ['opensource', 'base de datos', 'MongoDB'],
... comentarios: [
... {autor: 'adan3000', fecha: Date('03/27/2010'), comentario: 'Muy sencillo, gracias'},
... {autor: 'majopero', fecha: Date('03/27/2010'), comentario: 'Me parece muy interesante'}
... ]
... }
> db.noticias.save(noticia)
Sat Mar 27 10:32:53 allocating new datafile /data/db/pruebas.ns, filling with zeroes...
Sat Mar 27 10:32:53 done allocating datafile /data/db/pruebas.ns, size: 16MB, took 0.066 secs
Sat Mar 27 10:32:53 allocating new datafile /data/db/pruebas.0, filling with zeroes...
Sat Mar 27 10:32:54 done allocating datafile /data/db/pruebas.0, size: 64MB, took 0.185 secs
Sat Mar 27 10:32:54 building new index on { _id: 1 } for pruebas.noticias
Sat Mar 27 10:32:54 Buildindex pruebas.noticias idxNo:0 { name: "_id_", ns: "pruebas.noticias", key: { _id: 1 } }
Sat Mar 27 10:32:54 done for 0 records 0secs
Sat Mar 27 10:32:54 insert pruebas.noticias 261ms

De forma implícita, MongoDB ha creado físicamente la colección “noticias” dentro de la base de datos “pruebas” (en uso). Para verificarlo, listamos las bases de datos:

> show dbs
admin
local
pruebas
test

Ahora listamos las colecciones:

> show collections
noticias
system.indexes

Para listar todos los documentos de la colección:

> use pruebas
switched to db pruebas
> db.noticias.find()
{ "_id" : ObjectId("4badd0c542691c3d5d4ba694"), "autor" : "Rafael Hernamperez", "titulo" : "Primeros pasos en MongoDB Linux", "fecha" : "Sat Mar 27 2010 10:32:39 GMT+0100 (CET)", "noticia" : "bla bla bla", "etiqueta" : [ "opensource", "base de datos", "MongoDB" ], "comentarios" : [
{
"autor" : "adan3000",
"fecha" : "Sat Mar 27 2010 10:32:39 GMT+0100 (CET)",
"comentario" : "Muy sencillo, gracias"
},
{
"autor" : "majopero",
"fecha" : "Sat Mar 27 2010 10:32:39 GMT+0100 (CET)",
"comentario" : "Me parece muy interesante"
}
] }

Internamente, MondoDB crea claves con el prefijo “_”. La clave “_id” es gestionada de forma interna y exclusiva por MongoDB para evitar la redundancia de documentos.

Podemos añadir nuevos documentos con claves similares pero no iguales:

> db.noticias.save({autor:'Rafael Hernamperez', titulo:'Noticia2', fecha: Date('03/27/2010'), noticia: 'bla bla bla 2'})
> db.noticias.save({autor:'Claudio Mendetto', titulo:'Noticia3', fecha: Date('03/27/2010'), noticia: 'bla bla bla 3'})

Ahora tenemos tres documentos. Para hacer una búsqueda, por ejemplo, las noticias publicadas por Claudio:

> db.noticias.find({autor: 'Claudio Mendetto'})

O las noticias en las cuales 'adan3000' ha dejado comentario:

> db.noticias.find({'comentarios.autor' : 'adan3000'})

Technology IT News


Conceptos básicos de MongoDB
2010-11-29T08:02:00.003+01:00
Filosofía de almacenamiento en MongoDB

La filosofía de las bases de datos NOSQL suele ser chocante para todos los que llevan años trabajando en bases de datos relacionales. El no tener el concepto de una tabla, o de una integridad referencial con su relación de clave maestra a clave foránea, se hace difícil imaginar cómo puede funcionar y cómo pueden relacionarse y entenderse los datos.

MongoDB tiene el concepto de la información almacenada como clave/valor. Estos pares se almacenan en forma de documento u objeto dentro de una colección. Podemos imaginar un símil entre clave/valor como campo/valor, entre un objeto o documento y una fila, y entre colección y tabla. Este concepto puede ayudar a entender un poco mejor este sistema, pero no hay que olvidar que es un símil, no una equiparación.

Un documento u objeto (los dos términos se refieren a lo mismo), aunque se asemeje a una fila, en realidad no tiene nada que ver, pues en una base de datos relacional, cada fila tiene una organización estructurada común entre todas las filas. En MongoDB, cada fila puede tener su propia estructura, tener más o menos campos, e incluso tener campos que en sí mismos son arrays (contener varios valores) o incluso contener otro documento como valor, o incluso un array de documentos. Esto, entendido bien, nos puede dar una idea de la potencia que ello implica, pues es posible tener en un mismo objeto, de manera incrustada, otros objetos, sin necesidad de implicar a la base de datos en varias tablas, definir claves y relacionar dichas claves.  Por ejemplo, imaginemos la clásica relación “Categoría” y  “Producto”. En un sistema de base de datos tradicional, se definirían dos tablas:

Tabla categoría:
- idcategoria: integer: PRIMARY KEY
- nombrecategoria: char(30)

Tabla producto:
- idproducto: integer: PRIMARY KEY
- nombreproducto: char(30)
- idcategoria: integer

Internamente, el gestor de base de datos debe estar constantemente velando para que los datos clave sean únicos, no nulos y que no violan las reglas de integridad referencial, realizando complejas operaciones de índices y actualización de éstos. Estas operaciones son transparentes para los usuarios y desarrolladores. Es cómodo, pero sobrecargan los tiempos de CPU y penalizan otras operaciones que pueden ser más importantes.

En una base de datos MongoDB se requeriría únicamente una colección de objetos, cada uno de los cuales puede tener una estructura propia (no tiene por qué ser la misma).

{producto: “Perdiz escabechada”, categoria:[“carne”,”conserva”]}
{producto:”Naranja”, categoria:”fruta”]}
{producto:”Sal”}

De este simple ejemplo se pueden extraer algunas reflexiones:
- El almacenamiento físico gana mucho, al no estar supeditada a una estructura fija y definida. Se pueden omitir claves (campos) si se desea, y los campos de texto ocupan sólo el número de caracteres que contiene, no un tamaño fijo.
- Se prescinde de campos id, que dificultan el entendimiento de los datos.
- Se centraliza todo en una única colección, y no añade la dificultad de las relaciones.
- Un producto puede no estar asociado a una categoría, o bien estar asociado a varias categorías. En este último caso, en una base de datos relacional, requeriría de una tercera tabla intermedia con la colección de relaciones, y el trabajo extra en el código para reconstruir las mismas.
- Si bien el control de la redundancia en las categorías es un esfuerzo por parte del código, en el caso de una base de datos relacional, también habría que hacer un esfuerzo en código cuando se determina si hay redundancia por los errores que emite la base de datos (clave duplicada, infracción de integridad…).
- El modo de almacenamiento es más natural para la máquina y para el humano, pues toda la información está en el mismo documento, en lugar de repartido. Esto evita al código repartir la información (al guardar) y de reunirla (al acceder).
- En un modelo relacional, utilizar id’s reduce el espacio de almacenamiento en tablas extensas (ocupa mucho menos un número que un texto), pero complica el desarrollo y el acceso. MongoDB reduce y optimiza espacio de almacenamiento en los campos de texto, supliendo este espacio e incluso mejorándolo. Asimismo, el código para guardar o acceder a la información es mucho más simple (no hay que realizar relaciones (los típicos join o el uso de varias consultas a varias tablas) ni realizar varias actualizaciones por cada una de las tablas involucradas).

Otro ejemplo de almacenamiento en un documento u objeto sería el siguiente:
{ nombre: ‘Rafael’,
apellidos: ‘Hernamperez Martin’,
fechaingreso: Date(’03-22-2010’),
seleccion: [‘Aprenda MongoDB’,’Flex 4 en una semana’,’AJAX para Dummies’],
comentarios: [{autor: ‘adan3000’, comentario: ‘Buena eleccion’},
{autor: ‘majopero’, comentario: ‘Te has pasado’, puntuacion:5}
]
}

La clave “comentarios” es un array de documentos. Un documento puede contener, asimismo, documentos asociados a una clave. Es lógico suponer que el nivel de anidamiento puede ser tan profundo como uno desee.

El formato de datos utilizado por MongoDB es JSON, una especificación estándar para representar la información. Es similar a la de XML, pero reduce el contenido a expresar y haciendo más legible y natural la interpretación de la información. El último documento en formato XML sería el siguiente:
<documento>
  <nombre>Rafael</nombre>
  <apellidos>Hernamperez Martin</apellidos>
  <fechaingreso>03-22-2010</fechaingreso>
  <seleccion>
    <titulo>Aprenda MongoDB</titulo>
    <titulo>Flex 4 en una semana</titulo>
    <titulo>AJAX para Dummies</titulo>
  </seleccion>
  <comentarios>
    <comment autor=”adan3000” comentario=”Buena elección”/>
    <comment autor=”majopero” comentario=”Te has pasado” puntuación=”5”/>
  </comentarios>
</documento>


Alguno se estará preguntando cómo mantener la consistencia de los datos en las aplicaciones. Por ejemplo, en una aplicación es conveniente evitar al usuario teclear la categoría, pudiendo seleccionar una ya predeterminada en una lista para asegurar que sea unívoca y que no haya multitud de referencias a un mismo valor que esté redundante porque se diferencia en una letra o está mal escrito. Se puede crear una colección de categorías, en un formato muy similar al de una tabla (usando documentos con una única clave), y usar ésta como se haría normalmente, o incluso añadir un documento en nuestra colección cuya clave sea un array de valores posibles. Aunque su estructura no tenga nada que ver con el resto de documentos almacenados en la misma. Se accede a dicho documento dentro de la colección y se extraen los posibles valores. La primera opción es más sencilla y legible. La última es más óptima en cuanto almacenamiento y gestión por parte del motor de base de datos (trabaja en la misma colección y comparte los mismos ficheros). Otra solución intermedia, y a la vez elegante, sería definir una colección exclusiva para almacenar documentos que contengan series de datos maestros (categorías, tipos, etc.)

Otra de las ventajas de utilizar este sistema de información, es que no tienes tantas limitaciones a la hora de escalar la información si los requisitos cambian (cosa que ocurre, pues nadie conoce el futuro). En bases de datos relacionales, añadir nuevos campos a una tabla, o una nueva tabla relacionada o maestra y normalizar una base de datos que lleva ya tiempo en producción, es cuanto menos un engorro y un agujero de problemas. 

Una vez se entienden estos sencillos conceptos, el adaptar nuestros desarrollos a este tipo de bases de datos es sencillo, e incluso nos beneficiaremos de una mayor legilibilidad y rapidez.


Paso a paso
El movimiento se demuestra andando, y para aprender a caminar en MongoDB procederemos a realizar, paso a paso, un ejemplo práctico. El propósito del mismo es tener una colección de datos personales llamada “agenda”, dentro de una base de datos llamada “ejemplo”. En el ejemplo se verá cómo crear la base de datos, la colección y los datos, y a continuación se verá como realizar consultas a dichos datos.

Arranque del servidor y de la consola MongoDB

Primeramente, arrancar el servidor de MongoDB desde una consola DOS (para Linux, los pasos son muy similares):

cd c:\mongodb-win32-i386-1.2.4\bin
mongod

A continuación, arrancar la consola de MongoDB (dbShell) en otra consola DOS:

cd c:\mongodb-win32-i386-1.2.4\bin
mongo


Creación de la base de datos y de la colección

Aunque no se haya creado aún la base de datos, utilizar ésta (asumirá que se va a utilizar para ser creada):

> use ejemplo
switched to db ejemplo

A continuación crear un objeto que contendrá un documento, el cual se insertará en la colección “agenda” (aún no creada):

> doc = {nombre: "Rafael", apellido1: "Gonzalez",  apellido2: "Martin", telefono: "912406790"}

{
"nombre" : "Rafael",
"apellido1" : "Gonzalez",
"apellido2" : "Martin",
"telefono" : "912406790"
}

El siguiente paso es añadir este objeto (documento) a la colección “agenda”:

> db.agenda.save(doc)

Se puede abreviar el proceso en un solo paso, creando directamente el objeto:

> db.agenda.save({nombre: "Rafael", apellido1: "Gonzalez",  apellido2: "Martin", telefono: "912406790"})

Esto equivaldría a la sentencia SQL:

INSERT INTO agenda (nombre, apellido1, apellido2, telefono) VALUES (‘Rafael’, ‘Gonzalez’, ‘Martin’, ‘912406790’)

Automáticamente, MongoDB crea los objetos por asunción. De esta manera, crea la base de datos “ejemplo”, y dentro de ésta crea la colección “agenda”, y dentro de ésta crea y agrega el documento “doc”.


Verificaciones

Para verificar todo lo anterior primero comprobaremos qué base de datos está en uso:

> db
ejemplo

A continuación, listaremos las bases de datos creadas con MongoDB:

> show dbs

admin
ejemplo
local
test

Las bases de datos “admin”, “local” y “test” son las bases de datos que por defecto tiene MongoDB.

La siguiente verificación será comprobar qué colecciones disponemos en la base de datos en uso (“ejemplo”):

> show collections
agenda
system.indexes

La colección “system.indexes” es creada y mantenida de forma automática por MongoDB para el control y gestión de los índices de las colecciones.

Para visualizar solamente las colecciones no internas de MongoDB, se puede usar el siguiente comando:

> db.getCollectionNames()
[ "agenda", "system.indexes" ]

Para conocer a qué base de datos pertenece una determinada colección:

> db.agenda.getDB()
ejemplo

Para conocer qué comandos se puede usar para tratar la colección:

> db.agenda.help()


Consultas a los datos

Para visualizar todos los objetos (documentos) de la colección:

> db.agenda.find()
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }

Automáticamente, MongoDB asigna un ID único a cada objeto de la colección (clave “_id”).

Vamos a añadir más documentos a la colección:

db.agenda.save({nombre:"Carlos",apellido1:"Sanchez",apellido2:"Sanchez",telefono:"91240890012",email:"carlosss@hotmail.com"}) db.agenda.save({nombre:"Javier",apellido1:"Cristobal",apellido2:"Nombela",telefono:"925407561",email:"javichuc@yahoo.es"})
db.agenda.save({nombre:"Yolanda",apellido1:"Ballesteros",apellido2:"Lopez",telefono:"925406902"})
db.agenda.save({nombre:"Antonio",apellido1:"Blazquez",apellido2:"Fernandez",telefono:"937607812"})
db.agenda.save({nombre:"Jose Miguel", apellido1:"Carvajal", apellido2:"Gomez", telefono:"983679103", email:"picachu234@gmx.com"})
db.agenda.save({nombre:"Juan Carlos", apellido1:"Blazquez", apellido2:"Gil", telefono:"925403789"})

Lista de todos los objetos de la colección:

> db.agenda.find()
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }
{ "_id" : ObjectId("4ba8aac55b3d000000007110"), "nombre" : "Carlos", "apellido1" : "Sanchez", "apellido2" : "Sanchez", "telefono" : "91240890012", "email" : "carlosss@hotmail.com" }
{ "_id" : ObjectId("4ba8ab435b3d000000007111"), "nombre" : "Javier", "apellido1" : "Cristobal", "apellido2" : "Nombela", "telefono" : "925407561", "email" : "javichuc@yahoo.es" }
{ "_id" : ObjectId("4ba8ac3f5b3d000000007112"), "nombre" : "Yolanda", "apellido1" : "Ballesteros", "apellido2" : "Lopez", "telefono" : "925406902" }
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }
{ "_id" : ObjectId("4ba8acde5b3d000000007114"), "nombre" : "Jose Miguel", "apellido1" : "Carvajal", "apellido2" : "Gomez", "telefono" : "983679103", "email" : "picachu234@gmx.com" }
{ "_id" : ObjectId("4ba8af123433000000003118"), "nombre" : "Juan Carlos", "apellido1" : "Blazquez", "apellido2" : "Gil", "telefono" : "925403789" }

Esto equivaldría a la sentencia SQL:

SELECT * FROM agenda

Cuando la colección contiene múltiples objetos será necesario introducir criterios en la búsqueda. El comando “find” permite pasar como parámetros dichos criterios (en formato JSON), los cuales recogen el par (clave/valor) a encontrar. El siguiente comando localiza todos los objetos en cuyo primer apellido sea “Blazquez”:

> db.agenda.find({"apellido1":"Blazquez"})
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }
{ "_id" : ObjectId("4ba8af123433000000003118"), "nombre" : "Juan Carlos", "apellido1" : "Blazquez", "apellido2" : "Gil", "telefono" : "925403789" }

Lo anterior equivaldría a la sentencia SQL:

SELECT * FROM agenda WHERE apellido1=”Blazquez”

Mediante el siguiente comando sabremos cuántos objetos tiene la colección:

> db.agenda.count()

En un conjunto de datos, para limitar el número de objetos retornados, se especificaría añadiendo el comando limit():

> db.agenda.find().limit(3)
{ "_id" : ObjectId("4ba8a3be5b3d00000000710f"), "nombre" : "Rafael", "apellido1" : "Gonzalez", "apellido2" : "Martin", "telefono" : "912406790" }
{ "_id" : ObjectId("4ba8aac55b3d000000007110"), "nombre" : "Carlos", "apellido1" : "Sanchez", "apellido2" : "Sanchez", "telefono" : "91240890012", "email" : "carlosss@hotmail.com" }
{ "_id" : ObjectId("4ba8ab435b3d000000007111"), "nombre" : "Javier", "apellido1" : "Cristobal", "apellido2" : "Nombela", "telefono" : "925407561", "email" : "javichuc@yahoo.es" }

El comando count() también se puede añadir a find() para saber cuántos objetos ha retornado:

> db.agenda.find({apellido1:"Blazquez"}).count()
2

En el caso de querer visualizar solamente el primero de un conjunto de datos retornados, se usaría el comando findOne():

> db.agenda.findOne({apellido1:"Blazquez"})
{
"_id" : ObjectId("4ba8ac865b3d000000007113"),
"nombre" : "Antonio",
"apellido1" : "Blazquez",
"apellido2" : "Fernandez",
"telefono" : "937607812"
}

Para especificar más criterios, éstos se separan por comas:

> db.agenda.find({"apellido1":"Blazquez","nombre":"Antonio"})
{ "_id" : ObjectId("4ba8ac865b3d000000007113"), "nombre" : "Antonio", "apellido1" : "Blazquez", "apellido2" : "Fernandez", "telefono" : "937607812" }

Su equivalente en SQL sería el siguiente:

SELECT * FROM agenda WHERE apellido1=”Blazquez” AND nombre=”Antonio”

El comando find() retorna realmente un cursor, el cual puede ser utilizado para un acceso más controlado. El siguiente ejemplo se declara una variable que recoge el cursor del comando find(), situándose antes del primer registro. A continuación se declara un bucle while que se repetirá mientras el cursor tenga elementos o no alcance el final (hasNext()). En este bucle se imprimirá, en formato JSON, el objeto actual sobre el cual está situado el cursor. Mediante el comando next(), el cursor avanzará al siguiente objeto.

> var cursor = db.agenda.find()
> while (cursor.hasNext()) { print(tojson(cursor.next())); }
{
"_id" : ObjectId("4ba8a3be5b3d00000000710f"),
"nombre" : "Rafael",
"apellido1" : "Gonzalez",
"apellido2" : "Martin",
"telefono" : "912406790"
}
…

El siguiente ejemplo, recoge el cursor y accede directamente al tercer objeto del mismo:

> var cursor=db.agenda.find()
> print(tojson(cursor[3]))
{
"_id" : ObjectId("4ba8ac3f5b3d000000007112"),
"nombre" : "Yolanda",
"apellido1" : "Ballesteros",
"apellido2" : "Lopez",
"telefono" : "925406902"
}

La variable “cursor” se podría ver como un array de objetos, por lo que si se quiere acceder a cualquier clave del mismo, se especifica mediante un punto, como si fuera una propiedad:

> print(cursor[3].nombre, cursor[3].apellido1, cursor[3].telefono)
Yolanda Ballesteros 925406902

Technology IT News


Primeros pasos en MongoDB
2010-11-29T08:01:00.003+01:00
Introducción
MongoDB es una base de datos opensource que está teniendo mucha aceptación por las prestaciones que ofrece en entorno Web 2.0, aunque puede ser utilizada en cualquier tipo de situaciones. MongoDB acerca el sistema de almacenamiento y gestión de datos tipo clave/valor, puliendo la diferencia con respecto a los sistemas de bases de datos relacionales. Este sistema permite una tremenda rapidez y escalabilidad, frente a la funcionalidad de los sistemas de bases de datos tradicionales.

Las principales características de MongoDB son las siguientes:
- Software abierto
- Escalable
- Alto rendimiento
- Alta disponibilidad (puede trabajar en modo maestro-esclavo)
- Orientado a documentos (no es relacional)
- Simplicidad basada en esquemas de tipo JSON
- Consultas dinámicas
- Completo soporte de índices, incluyendo índices secundarios, objetos internos, arrays (cadenas) embebidos, geospacial
- Rápido, actualizaciones in situ.
- Perfilado de consultas
- Almacenamiento eficiente de datos binarios en objetos largos, tales como vídeos o fotografías
- Replicación y soporte a prueba de fallos
- Auto fragmentación para escalabilidad a nivel de nube.
- Agregación compleja mediante MapReduce
- Acceso y gestión mediante drivers en multitud de lenguajes de programación: C, C++, C#, .NET, Java, JavaScript, PHP, Phyton, Ruby, Perl, etc.
- Soporte, formación y consultoría.

En este artículo (que espero sea el primero de muchos), se realiza una pequeña introducción a MongoDB.

Orientación a documentos
La información en MongoDB no se almacena en tablas (con sus correspondiente filas y columnas), si no en colecciones (estructuradas o no) cuyos datos forman parejas de clave y valor. Estos datos se almacenan con un estilo JSON, en formato binario llamado BSON. Un ejemplo de este estilo se puede apreciar en el siguiente documento:

{ nombre: ‘Rafael’,
apellidos: ‘Hernamperez Martin’,
fechaingreso: Date(’03-22-2010’),
seleccion: [‘Aprenda MongoDB’,’Flex 4 en una semana’,’AJAX para Dummies’],
comentarios: [{autor: ‘adan3000’, comentario: ‘Buena eleccion’},
{autor: ‘majopero’, comentario: ‘Te has pasado’, puntuacion:5}
]
}

Una colección sería similar a una tabla, y un documento sería similar a una fila. Habría que distinguir claramente, pues la colección puede tener documentos con estructura similar pero no igual (algunos documentos podrían tener más o menos claves). Asimismo, una única clave podría tener una colección de valores (array o cadena, como en el caso de la clave “seleccion"), o bien podría ser también una sub-colección con sus respectivos documentos (como en el caso de la clave “comentarios”).

La sintaxis en formato JSON es muy fácil de entender, eliminando los problemas de errores que pueden ocurrir en el formato XML (ambos son muy sinérgicos), además de reducir el tamaño de la información a transportar.

Este formato es utilizado no sólo para entenderlos, sino también para gestionarlos y realizar consultas en sus campos internos. Por ejemplo:

db.compras.find({'nombre':'Rafael'})

Nota: si falla, probar con comillas dobles

Esta consulta localizaría todos los documentos dentro de la colección “compras” cuya clave “nombre” tenga el valor “Rafael”.

Otro ejemplo:

db.compras.find({'comentarios.autor':'adan3000'})

Esta consulta localizaría todos los documentos dentro de la colección “compras” cuyo comentario haya sido realizado por el “autor” llamado “adan3000”.


Instalación
Para nuestros propósitos utilizaremos Windows como plataforma de operaciones. También puede instalarse en sistemas operativos OS X, Linux y Solaris (ver instrucciones en http://www.mongodb.org/display/DOCS/Quickstart)

En primer lugar hay que crear la siguiente ruta de directorio: “c:\data\db”. Esta ruta es la ruta por defecto para los archivos de bases de datos.

A continuación descargar el archivo zip (ocupa apenas 13MB) de la siguiente URL:
http://www.mongodb.org/display/DOCS/Downloads
y descomprimirlo en la ruta que deseemos (por ejemplo en C:\ donde creará un subdirectorio llamado “mongodb-winxx-xxxx”). 


Arrancar un servidor MongoDB
MongoDB se ejecuta principalmente en su consola. Para ello se accede al modo consola DOS de Windows (pulsar AltGr+R, escribir “cmd” (sin las comillas) y Aceptar).

Acceder al directorio “bin” de donde se descomprimió el fichero zip (ejemplo):

cd c:\mongodb-win32-i386-1.2.4\bin

Ahora, para lanza MongoDB por defecto, ejecutar el ejecutable:

mongod

Con esto, MongoDB accederá a las bases de datos almacenadas en el directorio 
c:\data\db y usando el puerto 27017. Si se desea cambiar el directorio de ficheros de bases de datos o el puerto, usar los siguientes parámetros:

mongod --dbpath [rutadirectorio] --port [puerto]

Si acaso saltase el cortafuegos, desbloquear el acceso para poder usarlo.

Para parar la base de datos, pulsar Ctrl+C. Con ello, MongoDB esperará hasta que todas las operaciones se hayan completado, guardando las últimas transacciones y cerrando los ficheros.

Existen otros parámetros que pueden ser usados por el motor de MongoDB:
-h (--help): Muestra información sobre los parámetros permitidos
--logpath rutafichero: Especifica fichero de log
--logappend: añade al log, en lugar de sobreescribirlo
--cpu: log periódico de la CPU y de los tiempos de entrada/salida
--fork: ejecución como demonio
--auth: Activa la seguridad
--noauth: Desactiva la seguridad (por defecto)
--nohttpinterface: Desactiva la interfaz http (localhost:27018)
--master: Designa este servidor como maestro (entorno de alta disponibilidad)
--slave: Designa este servidor como esclavo (entorno de alta disponibilidad)
--autoresync: Resincronización automática del servidor esclavo.
--source servidor:puerto: Para un servidor esclavo especifica dónde está el servidor maestro para la replicación

Una forma sencilla de arrancar el servidor MongoDB sin repetir los parámetros, es añadiendo éstos a un fichero de configuración. El formato del fichero sería el siguiente:

#comentario
parametro1 = valor1
parametro2 = valor 2
…

Para lanzar el servidor usando este fichero, ejecutar:

mongod –config ficheroconfiguración
mongod –f ficheroconfiguración

Consola de MongoDB
Una vez arrancado el servidor, podemos utilizar la consola de MongoDB para interactuar con las bases de datos. Para ello, acceder al modo consola DOS de Windows (pulsar AltGr+R, escribir “cmd” (sin las comillas) y Aceptar).

Acceder al directorio “bin” de donde se descomprimió el fichero zip (ejemplo):

cd c:\mongodb-win32-i386-1.2.4\bin

Ahora, lanzar la consola de MongoDB:

mongo

(nótese que no tiene la "d" final).

En esta nueva consola, nos permitirá escribir los comandos necesarios para interactuar con el servidor (mongod), de tal forma que podamos gestionar documentos y estructuras o acceder a la información (entre muchas acciones). Cada comando ha de estar acompañado por un “Enter” para su ejecución.

Por defecto se conecta a una base de datos llamada “test” (por defecto).

Para mostrar la base de datos en uso:
db

Para autentificar un usuario (sólo cuando se ejecuta el servidor en modo seguridad):
db.auth(usuario,contraseña)

Para salir de la consola MongoDB, escribir el comando 
exit

Para conseguir ayuda sobre los comandos disponibles, escribir el comando
help

Para mostrar las bases de datos disponibles:
show dbs

Para mostrar las colecciones de la base de datos actual:
show collections

Para mostrar los usuarios de la base de datos actual:
show users

Para utilizar una base de datos:
use nombrebasedatos

Para mostrar ayuda sobre los métodos de base de datos:
db.help()

Para mostrar ayuda sobre los métodos para la colección foo:
db.foo.help()

Para mostrar los objetos en una colección foo:
db.foo.find()

Referencias
Sitio oficial de MongoDB: http://www.mongodb.org


Technology IT News


Los picapedreros
2010-11-26T08:02:00.000+01:00
Cierta vez, el jefe de una cantera visitó a sus picapedreros, preguntándoles qué hacían y cómo les iba:
- Estoy ganándome la vida - dijo indiferente el primero.
- Estoy realizando el mejor y más eficiente trabajo de picar piedras del mundo - dijo con orgullo el segundo.
- Estoy construyendo la mejor de las catedrales - respondió con devoción el tercero.Technology IT News


¿Sueñan los bits con redes neutrales?
2010-11-23T21:27:00.002+01:00
Technology IT News


No me digan que no pueden
2010-11-22T19:35:00.002+01:00
Technology IT News

	MongoDB	CouchDB	RavenDB
Documentos
Formato	BSON	JSON	JSON
Metadata	No	Sistema	Sistema + personalizado
Versionado	No	Sí	Plugin incluído
Adjuntos	GridFS	Sí	Sí
Map/Reduce	JavaScript + otros	JavaScript	LINQ
Carga masiva	mongoimport	Sí	Sí
Consulta Adhoc	Sí	No	No
Almacenamiento
Fragmentación	Sí	Sí	Sí
Durabilidad	Servidor simple v1.8	Diseño "crash-only"	Escritura previa trazabilidad y aislamiento de instantáneas para garantizar recuperación vía ESE
Transacciones	No	No	Sí
Concurrencia	Actualización in-place	MVCC (Multi-Version Concurrency Control)	Concurrencia optimista
Consistencia	Maestro fuerte / Esclavo eventual	Nodo fuerte / Cluster eventual	Eventual
Replicación	Maestro-Maestro con funciones de resolución personalizadas	Maestro-Esclavo	Plugin incluído
Interfaz
Protocolo	Personalizado sobre TCP/IP	HTTP/REST	HTTP/REST
.NET API	Proyectos de terceros	Proyectos de terceros	Incluído
Otros
Triggers	No	Validación de actualización, Seguridad	Sí
Seguridad	Básica	Básica	Ninguna
Escrito en	C++	Erlang	C#

	BBDD	Modo durabilidad	java	ruby	python	php	.net	http
documento	mongodb	basado en réplica	x	x	x	x	x	x
	couchdb	nodo simple	x	x	x	x	x	x
	ravendb	nodo simple	-	-	-	-	x	x
clave-valor	redis	en memoria, serializado en disco	x	x	x	x	x	-
	riak	basado en réplica	x	x	x	x	x	x
tabular	cassandra	basado en réplica	x	x	x	x	x	-
grafo	neo4j	nodo simple	x	x	x	x	-	x
	sones	nodo simple	-	-	-	-	x	x