domingo, marzo 31, 2013

Lo que viene con Java 7

Tomado de: Java 7

Y yo que me pensaba un gran técnico... en fin. Después de leer este artículo vuelvo al planeta tierra...


Aquí tenéis un verdadero campeón de la innovación, liderando el desarrollo de Java EE 7 (vamos que de estrés tiene que tener un poco).
Os comento brevemente las novedades que se esperan para primavera del año 2013 (es decir, muy pronto, si el artículo es correcto).
  • Java API for RESTful Web Services 2.0: amplias mejoras en la implementación de Jax rs de Java (comentadas en artículos anteriores).
  • Java Message Service 2.0: JMS 1 fue desarrollada con la versión JDK 1.4... la nueva versión evoluciona a la par que lo ha hecho el lenguaje Java, y permite realizar funcionalidad que, antes, se realizaba en 20 líneas, en 6. Por poner un simple ejemplo.
  • Java API for JSON Processing 1.0: Api de streaming (a bajo nivel, para poder leer JSON, aparte de ser un buen plugin para parsers y generators), modelo de objeto (implementado sobre el Api de streaming, que permite ser una API de alto nivel, con facilidad de uso). Pendiente para el futuro dejan la posibilidad de que, mediante una anotación, se pueda parsear el objeto con un una entrada JSON (creo haber entendido). Es decir, inyección directa (vaya tela).
  • Java API for WebSocket 1.0: Java EE7 permitirá dar soporte a WebSocket.
  • Bean Validation 1.1: validaciones, ya introducidas en Java EE 6 (nº de caracteres, formato numérico, campos de email, objetos no nulos, etc). En Java EE 6 básicamente se utilizaban en JPA y JSF, ahora en Java EE 7 se puede utilizar en EJBs y POJOs. El resumen es que, mediante una anotación, puedes validar un campo.
  • Batch Applications for the Java Platform 1.0: mediante la definición de ficheros XML (que harán el papel de configuración), se podrá definir tareas planificadas, que podrán ser ejecutadas en paralelo o de manera secuencial. En este caso, se han dejado influenciar por Spring. Incluso hay posibilidad de definir un flujo completo de trabajo (similar, por ejemplo, desde mi punto de vista, a las tareas de Ant).
  • Concurrency Utilities for Java EE 1.0: anteriormente, parece que el contenedor de Java EE tenía problemas a la hora de conocer qué hilo se estaba ejecutando. Por este motivo, quieren mejorar este punto, definiendo Api's que permitan gestionar hilos, haciendo consciente al contenedor, que tiene posibilidad de manejarlos. Me he encontrado más de un problema ejecutando hilos en una aplicación web en Tomcat....
  • JavaServer Faces 2.2: parece que viene bastante evolucionado e influenciado por otros frameworks: integra bien HTML5, permite reutilizar flujos, y una librería de recursos. Aparece el concetpo Faces Flow, que reúne los conceptos de Oracle ADF Task Flow, Spring Web Flow, and Apache MyFaces CODI. Además, se introduce la anotación CDI @FlowScoped (que permitirá el almacenamiento del flujo a nivel local), y @FlowDefinition (que permitirá definir el flujo con métodos de producción de CDI).

5 Pros y 5 contras de cinco bases de datos NoSQL

Tomado de: Noticias de Linux y tecnología 5 Pros y 5 contras de cinco bases de datos NoSQL

Durante casi dos décadas, el modelo de las bases de datos relacionales (RDBMS) fue el único "juego" en la ciudad de la gestión de base de datos. En los últimos años, ha surgido otro juego: NoSQL, un modelo no-relacional de base de datos distribuida. Siga leyendo para conocer los 5 primeros beneficios y las desventajas de los 5 mejores.

Aunque dista mucho de nuevo -el concepto NoSQL ha existido durante 10 años más o menos- NoSQL ha atraído mucha atención en los últimos años, debido principalmente a la producción de las implementaciones de gran renombre. Ejemplos como Dynamo de Amazon y BigTable de Google son algunas de las mejores implementaciones conocidas.

Mientras NoSQL ofrece una serie de beneficios, no sin inconvenientes inevitables. Aquí están cinco Beneficios de NoSQL



1.- Es de código abierto - Sobre todas las cosas buenas

Los productos de código abierto proporcionan a los desarrolladores grandes beneficios, sobre todo por su estado sin costo alguno. Otros beneficios: el software de código abierto tiende a ser más confiable, seguro y rápido de implementar que las alternativas propietarias.

Gestores NoSQL populares son Cassandra, CouchDB, Hbase, MongoDB y Redis.

2.- Escalamiento sencillo.

NoSQL sustituye a la antiguo "escalar" el mantra de los gestores de las bases de datos con una nueva: "manera" en lugar de añadir más servidores para manejar más carga de datos, una base de datos NoSQL permite a una empresa distribuir la carga entre varios hosts a medida que aumenta la carga.

3.- Diferentes DBs NoSQL para diferentes proyectos

MongoDB y Redis son buenas opciones para el almacenamiento de escritura con alta frecuencia, rara vez leen los datos estadísticos, tales como web, contador de visitas.

Hadoop, una libre, DB distribuida que hace un buen trabajo almacenando grandes de datos tales como estadísticas del tiempo o el trabajo de análisis de negocio.

Memcache, una db transeúnte, destaca en la web, el almacenamiento de sesiones, y las estadísticas a corto plazo.

Cassandra y Riak (clusters automáticos, tiendas redundantes) un buen rendimiento en entornos con aplicaciones de alta disponibilidad, donde el tiempo de funcionamiento máximo es de vital importancia.

Impresionante implementaciones NoSQL de

Empresas como Amazon, Facebook, la BBC, y Google se basan en DB NoSQL. NoSQL vuela alto en la Nube

4.- NoSQL y la nube es un ajuste natural. Los servidores de hoy en día son de bajo costo y fácilmente pueden ser ampliados a petición mediante un servicio como Amazon EC2. Al igual que toda la tecnología de la nube, EC2 se basa en la virtualización. El eslabón débil de la virtualización es la E/S, la memoria y CPU que deben ser ágiles

5.- Las bases de datos NoSQL utilizan sobre todo el uso de memoria en vez del disco como la principal ubicación de escritura - lo que impide inconsistente rendimiento I/O. Y como los almacenes de datos NoSQL aprovechan típicamente particiones horizontales, son capaces de tomar ventaja en la nube de la elástica del aprovisionamiento.


Aquí están cinco Desventajas de NoSQL


1.- El código abierto puede significar una "mancha" en el soporte para las empresas

Mientras que los principales proveedores de RMBMS tales como Oracle, IBM y Sybase ofrecen buenos soportes a pequeñas, medianas y grandes empresas y típicamente start-ups, los vendedores de código abierto esperan ofrecer un soporte comparable -con excepción de un puñado de clientes blue-chip.

Generalmente un vendedor de código abierto no tiene el alcance global, servicios de soporte, y la credibilidad de Oracle o IBM.

2.- No están lo suficientemente maduros para algunas empresas

A pesar de sus puestas en práctica en algunas grandes empresas, las bases de datos NoSQL aún se enfrentan a un problema de credibilidad importante con muchas empresas. Los críticos señalan la falta de madurez de NoSQL y los posibles problemas de inestabilidad, mientras que citan la madurez, y una gran funcionalidad y estabilidad de los RDBMSes.

3.- Limitaciones de Inteligencia de Negocios

Hay una o dos cuestiones acerca de las capacidades de BI de las bases de datos NoSQL. ¿Pueden estas bases de datos proporcionar la clase de minería de datos rigurosos que las empresas se utilizan con las RDBMSes? ¿Cuántos conocimientos de programación se necesitan para hacer la consulta ad hoc y análisis?

Las respuestas no son precisamente positivas. Las bases de datos NoSQL no tienen muchos ganchos para el uso general de herramientas de BI, mientras que la más simple consulta ad-hoc y análisis implica conocimientos de programación bastante buenos. Sin embargo, las soluciones están disponibles. Quest Software, por ejemplo, ha creado Toad para bases de datos en la nube, que proporciona capacidades de consulta ad-hoc para algunas bases de datos NoSQL.

4.- La falta de experiencia

La novedad de NoSQL significa que no hay una gran cantidad de desarrolladores y administradores que conocen la tecnología -lo que hace difícil a las empresas encontrar personas con los conocimientos técnicos apropiados. Por el contrario, el mundo RDBMS tiene miles de personas muy cualificadas.

5.- Problemas de compatibilidad

A diferencia de las bases de datos relacionales, que comparten ciertos estándares, las bases de datos NoSQL tienen pocas normas en común. Cada base de datos NoSQL tiene su propia API, las interfaces de consultas son únicas y tienen peculiaridades. Esta falta de normas significa que es imposible cambiar simplemente de un proveedor a otro, por si no quedara satisfecho con el servicio.

NoSQL (I): Introducción


Tomado de: NoSQL (I): Introducción

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

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

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

Base de datos Cassandra, diseñada para escalar naturalmente a millones de usuarios

Tomado de: Base de datos Cassandra, diseñada para escalar naturalmente a millones de usuarios


Una de las tendencias actuales en bases de datos son las llamadas "bases de datos del tipo BigTable", un modelo de base de datos nada nuevo, pero sí hecho práctico y popularizado por Google, quien creó su propio sistema de almacenamiento y gestión de datos ya que de otra manera no hubiera podido escalar de manera práctica su masiva infraestructura para servir a los cientos de millones de personas que utilizan sus servicios a diario. Sin embargo, aunque Google ha hecho público muchos de los detalles de su implementación, lo cierto es que por motivos de competitividad la empresa mantiene celosamente guardada su implementación actual optimizada. Pero, como siempre ocurre, un grupo de talentosos programadores se han unido junto con otras grandes empresas para crear algo sino similar, incluso quizás hasta mejor. Uno de los primeros frutos de estos esfuerzos fue la base de datos Hadoop HBase de la cual les hablé el año pasado, pero ahora verán la próxima generación... Hablamos de un proyectos bajo el nombre "Cassandra", mantenido por la Fundación Apache, y que quizás sea el sistema de bases datos diseñada para escalar "naturalmente" mas sofisticado del momento, y un tremendo punto a su favor es que gran parte de su fuente fue generado por los ingenieros del portal social Facebook, quienes han estado pasando toda su !@#$%^&*ánica infraestructura a este modelo, y como si fuera poco, la empresa Twitter recién hizo público que también planea migrar toda su infraestructura a esta nueva plataforma de datos. Además, empresas como CISCO y Rackspace también están entre las empresas que están apoyando el proyecto. Según los que mantienen a Cassandra, ya existen instalaciones con hasta 150 máquinas en paralelo y 100TB de datos en producción, por lo que aun en estado "beta", no hay duda de que este motor ha cobrado mucha tracción en el mercado, y es ahora mismo la alternativa primaria para toda empresa que necesite una base de datos que escale a millones de usuarios y en donde algo como Oracle, MySQL, Postgress o MS SQL Server no es suficiente (tanto desde el punto de vista de poder, como de costo y complejidad). Pero, ¿qué hace a Cassandra algo tan atractivo? Pues para empezar, fue pensada para que escale "naturalmente" casi por sí sola con uno simplemente agregar mas máquinas a un cluster, prometiendo ser uno de los primeros sistemas de esta magnitud que escala "linealmente" acorde se le agreguen mas máquinas, y todo de una manera sencilla. Noten que existen soluciones que pueden escalar bastante bien en varios escenarios, como es utilizar MemCache con MySQL, pero el problema de esas soluciones es que requiere de mucha configuración manual para agregar nuevos nodos al cluster, y aparte de eso no garantiza una escalabilidad lineal como lo ofrece Cassandra. Otro punto a favor de Cassandra es que no es un sistema centralizado, ni gestionado de manera centralizada, sino que toda la inteligencia de gestionar los datos es manejada de manera distribuída entre todos los nodos, lo que en la práctica en realidad significa que no existe un solo punto de fallas en el sistema, ya que aun si se caen varios de los servidores, los otros continuarán operando ininterrumpidamente, lo que es esencial para muchos tipos de sistemas estilo web hoy día. Incluso, Cassandra soporta replicación no solo local en una red, sino que entre varios centros de datos remotos, todo de manera natural. Ahora, uno se preguntará, con estos datos tan distribuído entre centenares (o potencialmente centenares de miles) de máquinas, ¿como puede el sistema escalar en tiempo real sin generar un flujo masivo de tráfico en el proceso? Y la respuesta es que esa escalabilidad la puedes manejar tu a tu antojo, pudiendo especificar que todo el cluster implemente un modelo que va desde simples lecturas sin bloqueo, hasta bloquear hasta que todos los nodos hayan sido escritos. Sin embargo, para tomar ventaja de este tipo de arquitectura también es necesario tener una aplicación que se beneficie de ella, ya que lo ideal para escalar a cientos de millones de personas es crear un balance entre disponibilidad de datos (es decir, que los datos estén siempre disponibles en todo momento y en tiempo real), y consistencia (es decir, que todos los datos estén propiamente sincronizados entre todos los nodos). A tal fin, el modelo recomendado (y por defecto) de Cassandra (así como de casi todas las bases de datos de este tipo) es el de un modelo "eventualmente consistente", lo que significa que los cambios se van propagando poco a poco entre todos los nodos del cluster, pero mientras tanto lo que sea que esté disponible para lectura se le ofrece al usuario mientras tanto lleguen las últimas actualizaciones. Es por eso que este tipo de bases de datos es ideal para portales sociales como Facebook y Twitter, en donde no importa si algunos usuarios reciben una actualización poco después que otros, ya que lo importante es que todos "eventualmente" tengan todas las actualizaciones. En otras palabras, hablamos de que para sacar ventaja de este tipo de sistemas se necesita modificar la mentalidad ACID que por décadas ha gobernado las bases de datos relacionales, y pensar mas en un esquema mas práctico y flexible, si bien no 100% consistente. Obviamente este tipo de modelos no aplica a todo tipo de aplicaciones, pues por ejemplo, aplicaciones financieras son el ejemplo clásico de transacciones que deben confirmarse y estar 100% consistentes en todo momento, para cuyo caso algo como un cluster de MySQL sería quizás mejor (o dependiendo de la aplicación, una mezcla entre ambos mundos). O en otras palabras, este tipo de bases de datos no tiene como objetivo reemplazar las tradicionales del tipo relacional, sino que complementar a estas en aplicaciones distintas para las cuales el modelo clásico simplemente no es óptimo. Noten además que debido a la naturaleza a estas bases de datos, que estas no utilizan el mismo concepto de tablas relacionadas a las que hemos estado acostumbrado por años, sino que mas bien de conjuntos de datos basados en modelos de "variable + valor", similar a las hashtables en los lenguajes clásicos de programación. Sin embargo, si hay algo que deben sacar de este artículo, es que si eres un desarrollador de software, y quieres mojarte las manos con el futuro de las bases de datos altamente escalables, o si tienes una aplicación que necesita escalar a millones de usuarios, que este es quizás el mejor punto de partida que podrás encontrar por el momento. 

Página oficial de Apache Cassandra (recuerden que es software Beta)

Introducción al modelo de datos de Cassandra

Una introducción a Cassandra para programadores de Rails Previamente en eliax:
Hadoop HBase, ¿el futuro de bases de datos escalables? (may 21, 2009)
Fusion Tables, Google trae la Base de Datos a la Nube del Internet (jun 12, 2009)
Predicciones de eliax y tendencias para el año 2010 (dic 28, 2009)

Posteriormente en eliax:
Google BigQuery y Prediction APIs, apuntan a inicios de Inteligencia Artificial masiva (sep 1, 2010)
Pregunta de lector: ¿Recursos para aprender a programar? (ene 13, 2011)
Sobre el nuevo Google Dart, un reinicio en lenguajes para la Era Web (oct 12, 2011)
MemSQL, motor de base de datos compatible con MySQL, 30x más rápido (jun 26, 2012)

Breve Introducción a Cassandra DB.

Tomado de: Articulo Original
Cassandra es un motor de bases de datos de las llamadas “No-SQL”, o no relacionales.
En un principio, Cassandra, fue diseñada por Facebook para gestionar de forma eficiente su ingente cantidad de datos, posteriormente, en 2008, se liberó su código pasando a manos de Apache Software Foundation, quien lo ha convertido en un proyecto estable y está contribuyendo en su desarrollo y gestión.
Unos ejemplos de entidades que usan esta base de datos son Digg, Cisco, Rackspace o IBM, y últimamente, se está hablando mucho de la migración de Twitter desde su sistema MySQL, a Cassandra, debido a la gran cantidad y gran incremento de información a la que se está viendo sometida esta red social.
Su modelo de datos está basado en el sistema BigTable de Google, y en Dynamo, este modelo se asienta sobre un par Key/Value siendo su
principal característica la posibilidad de almacenar registros de una forma contínua y ordenada y la definición de Columnas y Supercolumnas (columnas de columnas).
Observando la arquitectura del motor de base de datos de “Cassie”, nos encontramos con un gran interrogante, ¿Qué preferimos en nuestra base de datos?, consistencia de datos, o latencia, bien, pues esto no va a ser problema con Cassandra, ya que nos permite ajustar el tiempo de respuesta (latencia), y la consistencia de los datos a nuestro antojo y según nuestras necesidades.
La característica más importante de Cassandra es su alta ESCALABILIDAD y la gestión de los datos entre una serie de servidores o nodos de un clúster. Estos nodos se añaden al clúster de forma horizontal de modo que nuestra información es procesada  automáticamente por el sistema, quien se encarga de hacer el balanceado y mantener la consistencia en los nodos ya existentes y en el nodo recién añadido. Esta característica es la que hace especial a Cassandra, ya que al igual que el balanceado de datos y el manejo de la consistencia se hace de forma automática al añadir un nodo, también se encarga de realizar la misma operación si algún nodo se pierde, y con esto aunque el servidor esté caído, no veremos afectados nuestros datos por esta eventualidad.


Video donde se explica la utilizacion de Base de datos NOSQL


Instalación de Cassandra DB en Windows.
Para instalar Cassandra en Windows, procedemos de la siguiente forma:
Lo primero que debemos hacer es descargarnos el archivo de la base de datos desde la siguiente dirección:

http://www.cassandra.apache.org
Actualmente se encuentra en la versión 0.7.0.
Una vez obtenemos el fichero, lo descomprimimos en C:
Para que funcione nuestra base de datos, debemos crear dos variables de entorno, para lo que haremos lo siguiente:
En equipo, pongo el ratón sobre el icono y pulso el botón derecho, y en la pestaña que aparece me voy a propiedades, dentro de propiedades, pulso en configuración avanzada del sistema y en las pestañas superiores que nos aparecen, me muevo a la que tiene el título de “Variables de Entorno”.
En las variables de entorno, puedo observar tres opciones, “Nueva”, “Editar”, “Eliminar”, pinchamos en el botón “Nueva”, y aparece un cuadro de diálogo con dos opciones para rellenar:

“Nombre de la Variable”, y “Valor de la variable”.
En el primer campo pongo lo siguiente: JAVA_HOME
En el segundo campo, escribo la dirección donde se encuentra nuestro jdk, que en mi caso sería en el siguiente directorio:
C: \Program Files\Java\jdk1.6.0_17
Hecho esto, le doy a aceptar, y ya tenemos la primera de las dos variables de entorno creadas.
La segunda variable, se crea de la misma forma, y en el campo del nombre debemos poner lo siguiente CASSANDRA HOME y en la dirección, el directorio donde se encuentra la carpeta cassandra que descomprimimos anteriormente.
Después de establecer las variables de entorno, se inicia el servidor Cassandra abriendo la línea de comandos y escribiendo lo siguiente:
cd..
cd..
cd apache-cassandra-0.7.0
cd bin
cassandra -start

El resultado es el inicio del motor de la base de datos, que debe quedar en espera a la escucha de los clientes de Thrift.



lunes, marzo 18, 2013