viernes, 24 de abril de 2009

Escalabilidad en cuanto a capacidad de poner en producción nuevas funcionalidades

Me ha resultado muy interesante este artículo del blog de uno de los fundadores de FriendFeed (y que anteriormente fue un mando intermedio en Google): http://bret.appspot.com/entry/how-friendfeed-uses-mysql

Con una base de datos con decenas o cientos de millones de entradas, se encontraron un problema de escalabilidad entre otras cosas en la adición de nuevas funcionalidades, en concreto en el tiempo que cuesta añadir o quitar columnas a tablas, o añadir índices o eliminarlos. Estamos hablando de una o varias horas de "no disponibilidad de la BD" en un sistema supuestamente 24x7 :-)

Así que la solución (no sólo para ese problema, sino también por estabilidad en los tiempos de respuesta, cosa que no termino de enteder por cierto) fue la que se describe en la mencionada entrada. Resumidamente, usar MySQL como motor de almacenamiento pero pasar como de la mierda de un modelo relacional...

Enriquecedora lectura, aunque no me aplique... (que yo sepa ;-)

miércoles, 15 de abril de 2009

Java 6u13

Desde hace 3 semanas, está disponible el update 13 de Java 6. Descargas aquí: http://java.sun.com/javase/6/

Recordemos que a partir del update 10, la política de versiones de Java SE es:
  • Las versiones pares incluyen mejoras y/o nuevas funcionalidades (además de parches de seguridad si aplican).
  • Mientras que las versiones impares están reservadas para contener exclusivamente (salvo excepciones).

En este caso, como puede verse en http://java.sun.com/javase/6/webnotes/6u13.html, se han corregido 7 vulnerabilidades y se ha aprovechado para corregir otros 7 bugs no relacionados directamente con la seguridad pero que se han considerado prioritarios.

Seguimos esperando ansiosos la inminente liberación del update 14 (Java 6u16), que supondrá un hito importante en cuanto a rendimiento (es decir incluirá todo lo experimentado en las performance releases del año pasado y más cosas :-)

Y... La 6u14 ya va por la build b04, lo que significa que estamos muy cerquita aunque este update yo creo que necesitará algunos más de lo habitual, seguramente será a mediados o finales en mayo cuando se libere, como llevamos tiempo precidiendo desde este blog. Más información y descargas de los snapshots: http://download.java.net/jdk6/6u14/

miércoles, 8 de abril de 2009

Incremento de un 100% de rendimiento de java.util.Logger (o los detalles sí importan)

Delicioso post de Jeremy Manson, que lleva tiempo teniéndnos "abandonaditos"...:

http://jeremymanson.blogspot.com/2009/04/faster-logging-with-faster-logger.html

A raíz de la necesidad de un cliente, que quería nada menos que un throughput de 2 MB por segundo en la escritura de logs (!), se han hemos una serie de optimizaciones en Logger.log para alcanzarlo, y se ha alcanzado...

Los cambios ya están disponibles en el último build de OpenJDK, y más detalles en http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6797480.

El código de Jeremy es precioso en si mismo (lo siento, seguramente un no-programador no puede entender el adjetivo precioso aplicado a esto). Toda una clase de sincronización y volatilidad. Y es el mejor ejemplo de que el mejor "Escape analysis" sigue haciéndolo el ingeniero...

Pero, y por mucho que él le quite culpas al desarrollador original de esa clase (incorporada en JDK 1.4)... joder ¿eso siempre ha estado ahí? ¿los procesos de entrega de Sun Microsystems no incluyen búsqueda de puntos calientes o locks adquiridos en cada thread?

Lo cierto es que me ha dejado un sabor de boca muy muy agridulce...

jueves, 2 de abril de 2009

Deja de hibernar y despierta de una vez!

Me hago eco de este artículo: "Good Advice on Keeping Your Database Simple and Fast".

Independientemente de si nos parece bien, mal o regular todo lo demás, de si creemos en SimpleDB y S3 o no... e independientemente de si todo este rollo del Cloud mola pero no te aplica porque tus problemas son otros, tú trabajas en un sistema de información interno...

...El primer párrafo del artículo es para enmarcarlo, y traduzco literalmente:
Mantener una base de datos simple y rápida es muchas veces complicado si se usan frameworks de alto nivel como (...) o tecnologías de persistencia de objetos en Java como HIBERNATE. Hay una gran cantidad de "magia" que ocurre fuera de tu vista sobre la que no tienes ningún control. Si tienes que escalar tu aplicación, generalmente son estas tecnologías para acceder a bases de datos relacionales las que se convierten en el cuello de botella tanto de rendimiento como de escalabilidad. (...)

¡Algo sensato! ¡Por fin! Por favor que vuelvan los tiempos del JDBC crudo (dentro o fuera de un EJB). Y no necesariamente implica perder el tiempo en codificar como un mulo.

Ya en el año 2001 en mi anterior empresa ideé y lideré un sistema que llamamos "BeanBuilder" para generar todo tipo de código a partir del esquema de base de datos. Y no sólo me refiero a los EJB con altas/bajas/modificaciones/consultas/filtros/paginación, sino incluso llegamos a generar operativas completas con sus JSP de listado y de formularios de alta en base a plantillas. Para que sirvan como base para modificarlos, ampliarlos, etc. Pero siempre con control sobre el código generado porque generábamos código Java.

Y allá por 2004 el sistema era realmente complejo, admitíamos tomar como punto de partida joins entre varias tablas y generar lo apropiado... Teníamos un formulario en el que elegías el tipo de framework que debía utilizar el código generado (¿EJB o framework propio con POJO? ¿JSP o XSLT? ¿Struts o nuestro framework propio?). Vamos, una herramienta para cualquier proyecto que abordáramos...

Es decir si el objetivo es ahorrar esas horas de desarrollo "que no aportan valor" pero mantener el control sobre lo que potencialmente te va a dar problemas.

No preguntéis el motivo, pero quedó en vía muerta. Si volviera a quella época hubiera lanzado un proyecto Open Source en toda regla...

¡Es hora de despertar de la "hibernación" en que estos arquitectos de salón nos han metido!