Archivo de la etiqueta: MongoDB

Nuevo libro Keystone.js Succinctly

keystonejs_succinctly

Los amigos de Syncfusion han lanzado un nuevo libro sobre Keystone.js, un framework web libre y abierto para Node.js, con él se puede desarrollar sitios web con acceso a base de datos, aplicaciones y API RESTful. El framework fue construído sobre Express.js y MongoDB, utiliza el patrón de diseño Model-View-Template. En Keystone.js Succinctly junto con Manikanta Panati descubre como utilizar este framework para administrar plantillas de aplicaciones, vistas y rutas, utilizando JavaScript. Aprende como configurar un ambiente de desarrollo y un proyecto vacío, trabajar con modelos para leer, consultar y manipular datos, integra formularios complejos, autentica usuarios, puedes exponer extremos REST en una aplicación Keystone.js y más.

El libro está escrito en inglés y lo puedes descargar aquí. Si no estás registrado lo puedes hacer ahí.

Anuncios

¿Habrá una continuación para NoSQL?

El título es un juego de palabras en inglés SQL se pronuncia “sequel” que significa secuela más información aquí.

La reciente noticia que MongoDB Inc. aseguró un inversión de capital de $150 millones, subraya el hecho de que las bases de datos “open source” o de código libre ya no están en su infancia.

De hecho juzgando por los nombres de los inversionistas es justo decir que estas fuentes de datos de código libre han pasado a la fase final de la adolescencia. No están completamente maduras pero muy pronto lo estarán. Y Wall Street está apostando que algún día lanzará piedras lo suficientemente grandes como para dañar a los gigantes como IBM y Oracle.

El camino a la adultez de NoSQL no sido del todo suave.

En el año 2010 hubo un serio problema cuando “Foursquare” dejó de funcionar por 11 horas seguidas. Esto se debió a un problema con el balance de carga y escalamiento de MongoDB.

El entonces Director de Operaciones de Foursquare  publicó un artículo y explicación técnica con el título “So, that was a bummer.” “Eso fue decepcionante”. El CTO de 10gen (la compañía cambió de nombre a MongoDB, Inc este año), condujo un riguroso análisis de qué salió mal con el código y una discusión sobre las correcciones necesarias como consecuencia para los desarrolladores de MongoDB en todo el mundo.

Las razones exactas son complicadas pero simplificándolo Foursquare no pudo mantener el crecimiento de los datos de sus clientes. El equipo falló en planear adecuadamente ese crecimiento y la implementación de MongoDB tenía fallas profundas.

Para agosto del 2010, Foursquare tenía más de 3 millones de usuarios pero solo 32 empleados. La compañía tenía cerca de un año de edad. Bienvenidos al extraño y sorprendente mundo de la codificación de los datos del siglo 21.

En la era de las aplicaciones distribuidas y datos en tiempo real, el camino hacia un millón de clientes puede suceder en un latido del corazón. A eBay y a AOL le tomó años llegar a su primer millón de clientes; Instagram alcanzó el mismo logro en unos cuantos meses. Escalar aplicaciones y datos no es un problema nuevo. Lo que es nuevo es el corto intervalo de tiempo para hacerlo bien.

Tres años después del problema de Foursquare, MongoDB ha emergido como el claro líder del movimiento NoSQL. Cisco y Craiglist lo están usando y también Shutterfly y McAfee. Hoy, la compañía MongoDB, Inc. está valorada en más de un billón de dólares – nada mal para una empresa “startup” que se alimenta de la innovación del código libre.

A la fecha tiene más de 5 millones de descargas y ese número crece en 150,000 al mes. Alrededor de MongoDB hay muchos otros jugadores no-relacionales, incluyendo Cassandra, HBase, CouchDB y Riak. En términos de tecnología, estos sistemas NoSQL comparten características comunes.

Generalmente, todas son no-relacionales, código libre, amistosos con los “clusters”, no tienen esquemas y son construidos para el siglo 21 de la computación web. Todos tratan de tener un pedazo de una industria de $30 billones. Sólo porque el código es generalmente gratuito no significa que el espacio de NoSQL es una caridad. El valor real no está en el código pero en el conocimiento requerido para ejecutarlo a una escala masiva.

Lo que las compañías y desarrolladores se están dando cuenta es que cuando se trata de ejecutar aplicaciones con datos intensivos todo lo que importa es el rendimiento. No sólo del código pero también de la arquitectura y hardware.

Conforme estos ecosistemas de NoSQL evolucionen una clase de selección natural se producirá. Algunos sabores de NoSQL saldrán del mapa y otros se acelerarán. Las empresas demandarán más de sus socios NoSQL, incluyendo herramientas para que el escalamiento sea más fácil y eficiente.

Una plataforma como MongoDB tiene una gran demanda porque permite a los desarrolladores usar estructuras de datos nativas en muchos populares lenguajes de codificación. Los desarrolladores prefieren codificar que ponerse el sombrero del DBA (Administrador de Base de Datos) y preocuparse de cosas como escalamiento. Con MongoDB, el escalamiento automático y balance de carga de los datos está esencialmente cableado en la plataforma. Es fácil ver porqué los desarrolladores lo aman.

Pero hay una sutil distinción entre escalamiento automático (parte del diseño) y escalamiento automatizado (sucede sin intervención del usuario). Y esto es donde la siguiente gran fase de innovación de NoSQL está sucediendo, muy debajo de la aplicación.

MongoDB automáticamente soporta escalamiento horizontal o “sharding”. Por defecto el balanceador de carga moverá trozos de datos para balancear la carga de trabajo entre el “cluster” de “shards”. A MongoDB no le preocupa si estos “shards” residen en servidores “físicos”, “virtuales” o en la “nube” pero a tus clientes le importará.

Resulta que los servidores virtualizados de la nube pública o “barata” no equiparan el rendimiento que la expansión de datos de NoSQL requieren. Sin un método para automatizar el escalamiento horizontal  de los dato conforme van creciendo en una infraestructura de nube, te encontrarás persiguiendo infinitamente los datos.

Entonces, ¿cómo una aplicación obtiene la escalabilidad de la nube pero el rendimiento de servidores físicos? Este es el Santo Grial (Holy Grail) de los datos en el mundo de la computación. Las buenas noticias es que algunos proveedores están haciendo serios esfuerzos por encontrarlo.

De seguro es posible construir una nube privada y mantener todos los datos detrás de tu propio firewall pero a menos que te guste construir centros de datos masivos, es probable que no encuentres un inversionista o aprobación del CFO (Jefe de Finanzas). Aquí es donde una nueva generación de proveedores de “datos-como-servicio” aparecen. Están haciendo la ingeniería de cada capa de la pila – desde el núcleo (kernel) hasta las unidades de disco pasando por el sistema de archivos – todo para optimizar el rendimiento de los datos.

MongoDB por ejemplo, están desarrollando herramientas para automatizar la selección de la clave correcta de “shard” (el separador de las cargas de trabajo de datos) y están automáticamente añadiendo “shards” pre-aprovisionados para el “cluster” conforme los datos crecen. Piensa de este nuevo modelo como usar una clase de “unidad de capacidad contenida”.

Donde difiere de la nube tradicional es que no utiliza la forma de “un-tamaño-para-todos”. En vez de eso toma un manera super-personalizada para desplegar una unidad de escalabilidad que tiene las características de rendimiento de los más poderosos servidores físicos. Estos nuevos proveedores también entienden que muchas aplicaciones se basan igualmente en el lado relacional y NoSQL del mundo de los datos, ellos están construyendo formas para unir los 2 reinos y que permanezcan sincronizados. Finalmente entenderán el hecho que NoSQL y MySQL han sido siempre aliados y no enemigos jurados.

Si hay una secuela para NoSQL, es tener la promesa de escalamiento integrado y recuperación de masivas cantidades de datos inmediatamente, cumplida. La línea entre la infraestructura y la tecnología de base de datos en sí misma continua siendo borrosa. El contenedor de capacidad de datos se volverá la unidad de ingeniería, no el servidor.

En mi libro, esa es una secuela que vale la pena mirar.

Extraído de The Next Web por Kenny Gorman