Si hubiese que hacer apuestas sobre el futuro de MariaDB y MySQL yo apostaría por MariaDB sin dudarlo (e incluso muchos de vosotros pensáis igual), pero cada día que pasa el fork libre, pero libre de verdad, de MySQL recibe muchos más apoyos y ahora ha saltado la noticia de que SkySQL va a colaborar con la Fundación MariaDB (y por lo menos es una empresa que se dedica a proveer bases de datos de software libre y no al negocio de las bases de datos de pago, que es algo que da más confianza).

El principal objetivo de esta unión es, como ellos dicen, conseguir un NewSQL (como concepto), que pretende llevar a MariaDB a un nivel de rendimiento superior que el de algunos de los mejores gestores de bases de datos NoSQL y mejorar totalmente la interacción con otras bases de datos NoSQL (como Cassandra o LevelDB), accediendo a otras bases de datos con nuevos motores instalables.

Lo positivo de la unión con SkySQL y no con otra compañía es que ésta basa su negocio en proveer bases de datos open source de calidad y que ofrezcan el mejor resultados para su clientes, lo que indica que va a hacer todo lo posible para mejorar este proyecto, pero sin influir en sus principios, siendo independiente el proyecto de MariaDB y SkySQL y garantizando que será libre siempre.

SkySQL colaborará con MariaDB proveyendo de fondos, ayudando con el desarrollo del proyecto e impulsando su uso entre su gama de servicios, siendo sin duda uno de los mejores apoyos que ha recibido MariaDB. Lo siguiente es que las distribuciones de Linux que no se han pasado a MariaDB den el paso, los hosting tomen también esta opción y las empresas a la hora de realizar cambios en su sistema de gestión o lo implementen de nuevo opten por MariaDB y ya sabemos lo que pasará con MySQL.

Más información | SkySQL

Tras la decadencia que está sufriendo MySQL desde que está en las manos de Oracle se están poniendo de moda distintos nuevos gestores de bases de datos, ya sean NoSQL (como MongoDB o SimpleDB) o sea un fork de MySQL y esté triunfando, como es el caso de MariaDB, que por su comunidad, facilidad de migración y sus mejoras respecto a MySQL está cada vez más presentes en el mundo del desarrollo y en el del hosting.

Con esta pregunta de la semana queremos saber si creéis que acabará desapareciendo MySQL o MariaDB o por el contrario se dejará de lado los gestores de bases de datos que hacen uso del lenguaje SQL.

¿MariaDB acabará definitivamente con MySQL?

Recuerda que para responder, debéis hacerlo desde nuestra sección de Genbeta Dev Respuestas y en este artículo los comentarios están cerrados. Gracias.

En la pregunta de la semana pasada queríamos saber: ¿Cuánta diferencia hay entre lo que cobras y tus expectativas salariales?. Y las respuestas son un poco pesimistas (algo abundante en estos días), pero la respuesta mejor valorada es la de Vcspider con la siguiente respuesta:

La verdad es que tengo un sueldo medianamente decente, no puedo comprarme una casa de 200m2 en el centro ni conducir un Ferrari pero tengo dinero para pagar mis gastos imprescindibles y los de mi familia (hipoteca, agua, luz, comida, ropa, ADSL, teléfono) y aun me da para algún capricho y para ahorrar un poquito así que me considero bien pagado.

Mi problema no es con lo que yo gano sino con lo que ganan otros con trabajos sin responsabilidad, riesgo o dificultad, normalmente resultado de enchufismo o peloterismo, con una productividad nula y demasiado remunerados. También creo que algunos trabajos físicos deberían de pagarse mejor, y lo pagaría con lo que le quitamos a los apoltronados.

Muchas gracias a todos por participar. Nos vemos la semana que viene con las mejores respuestas a la pregunta que os hemos propuesto. Y recordad que la sección de Genbeta Dev Respuestas está a vuestra disposición para resolver todas las dudas que tengáis.

En Genbeta Dev Respuestas | ¿MariaDB acabará definitivamente con MySQL?

Hoy en día MySQL suele ser la primera opción a la hora de usar bases de datos (por lo menos en el ámbito del software libre o del low cost), MySQL ha sufrido algunos cambios estos últimos años, en la que podemos destacar el cambio de propietario (de Sun a Oracle) y poco más, ya que en las manos de Oracle no está evolucionando como se podría esperar.

Pero por suerte MariaDB, el proyecto open source derivado de MySQL que más está dando que hablar últimamente gracias a la adopción como gestor de base de datos por defecto de varios sistemas operativos GNU/Linux de gran relevancia (como Fedora y OpenSUSE entre otros) y por el paso de Wikipedia a este gestor de bases de datos.

¿Qué es MariaDB?

Como muchos sabréis MariaDB es un derivado de MySQL que va al compás de MySQL, aunque MariaDB suele tener un retraso al liberar la versión estable, equivalente en nomenclatura a la de MySQL, para poder implementar sus mejoras y realizar las pruebas pertinentes.

Pero el gestor de bases de datos MariaDB gana a MySQL por varios motivos, el primero y más claro es que funciona igual que MySQL y por ello no hace falta realizar ningún cambio para usar este gestor, actúa igual y usa los mismos conectores con las distintas plataformas y lenguajes a las que se puede conectar (como PHP o Perl entre otros), hasta usa el mismo archivo de configuración, el my.ini.

Otras mejoras son la implementación de nuevos motores de almacenamiento y añadir versiones mejoradas de algunos (sin descuidar los que hay en MySQL, como InnoDB o MyISAM), se ha mejorado también INFORMATION_SCHEMA añadiendo información extra que no encontramos en MySQL y otro cambio que me ha llamado también la atención es que en MySQL las “vistas“ o consultas almacenadas que podemos usar rápidamente leían todas las tablas que estaban implicadas en la propia consulta, independientemente de si se captasen datos de la misma y por eso en MariaDB se ha añadido la funcionalidad de no leer esas tablas para ahorrar esfuerzos y mejorar el rendimiento.

¿Por qué puede ser el futuro de MySQL?

Desde mi punto de vista personal la pregunta que me hago es: ¿por qué no?, realmente MySQL lo gestiona Oracle y obviamente no podemos esperar de una empresa que vende un producto que es una base de datos, además gestione un proyecto de software libre para que se beneficie todo el mundo y sin pagar por ello.

La razón anterior simplemente sirve para hacernos una idea del avance que probablemente tendrá MySQL, pero MariaDB en cambio está cada vez teniendo un mayor respaldo de la comunidad, además de estar avalada por desarrolladores que participaron en el proyecto original de MySQL y otros tantos más de prestigio.

¿Sería dura una transición a MariaDB?

En el caso de que se abandonara el proyecto original muchas empresas serían las que optarían por dar el cambio y es que realmente no hay que emplear grandes esfuerzos, tiene una total compatibilidad con los archivos de MySQL, la ventaja es que está vitaminado y más optimizado, por lo que un copia pega podría solucionar toda la transición a MariaDB y no deberíamos de tocar ni un carácter el código que usemos.

Más información | MariaDB

El término Big Data hace referencia a los sistemas que capturan, analizan, buscan y visualizan grandes conjuntos de de datos, que últimamente están dando mucho que hablar en sectores como la meteorología, la genómica, la biología y ahora cada vez más en el sector de las finanzas o en el de los buscadores de Internet y empresas que estudian a la sociedad.

¿Y que tiene que ver esto con el desarrollo y que tiene que ver Obama?, como es de esperar estos análisis los tienen que hacer supercomputadoras con softwares muy complejos, como el que creó un grupo de “cerebritos“ durante dos años para que Barack Obama ganara estas elecciones.

Este grupo formado por programadores, ingenieros, sociólogos y matemáticos estuvieron confinados en “La Cueva” (el nombre es en honor a las ventanas que no tuvieron la oportunidad de tener, estando totalmente aislados) desarrollaron una base de datos con todos los datos electorales, sondeos, listas de donantes, datos recogidos por encuestadores… todo esto fue dividido por franjas de edad, sexo, raza, y por el lugar donde viven.

Todo lo anterior entra dentro de lo normal, y no haría falta un supercomputador durante dos años para analizar estos datos, pero entra en juego otro factor: Facebook y las redes sociales, que fueron rastreadas letra por letra analizando a cada potencial votante en búsqueda de esas personas que estaban dudosas, recogiendo sus aficiones, perfiles de consumo, preferencias, círculos de amigos… y esto fue la clave (aunque no parezca mucho), pero con solo estos datos y el gran computador trabajando hicieron las primeras pruebas, intentado que las personas hicieran microdonaciones (y si, funcionó, recaudaron mil millones de dólares), gracias a ese software de estadística y previsión hecho por ese conjunto de genios.

El software que usaron en los últimos meses de campaña iba más lejos que analizar parámetros básicos de la población, sino que era capaz de saber con precisión que personas eran las que estaban dudosas y crearon una APP que transmitía automáticamente (cosa normal cuando no se mira los permisos que se otorgan en Facebook) mensajes elaborados por sociólogos que mandaban mensajes por Facebook animando a acudir a las urnas, a bajarse la APP y sobre todo a votar a Obama (y el 20% picó y se la bajó). Es más, por poner un ejemplo este software identificó como grupo de población dudosa a las mujeres menores de 35 años del condado de Dade, que casualmente la gran mayoría seguían la serie Sons of Anarchy, donde casualmente se llenó de publicidad diseñada para convencer a las personas que cumplían este perfil.

Resumen

Lo importante del artículo no es la creación de la mayor máquina política creada jamás, sino la importancia que tendrá el Big Data para las empresas, que serán capaces de encontrar las necesidades de la población incluso antes de que haya la necesidad, todo gracias a el software creado para este análisis y las impresionantes máquinas necesarias para procesar esta cantidad ingente de datos.

En este terreno cada vez se está avanzando muchísimo más (que está más ligado a la potencia de procesamiento casi que al software), ya que dentro de poco se almacenarán y analizarán miles de petabytes, formado por todo tipo de información. En estos momentos IBM se podría decir que encabeza el sector con soluciones de una envergadura enorme, acabando de presentar hace poco lo que denomina la nueva generación de “Smarter Computing, que al igual que otras tecnologías similares están pensadas para analizar grandes cantidades de datos en tiempo real y también están hechas para autoprotegerse de amenazas que pueden afectar a la seguridad de sus sistemas y a la de su valiosa información.

Aunque el artículo no estaría completo si nombramos solo a IBM y no nombramos a la mayor empresa de recolección, guardado, análisis y venta de datos: Google, que analiza en tiempo real datos de millones de páginas web, arrastrando su información de un lado a otro de sus resultados de búsqueda, sin contar las datos personales de los hábitos en la web de cada individuo, con su popular herramienta de análisis web (Google Analytics), su plataforma de publicidad (Google Adsense) y todo su ecosistema, que al fin y al cabo nos da de forma gratuita… y a cambio reciben “Big Data“, de una envergadura enorme, tan grande que la información que recibió Obama para ganar las elecciones sería irrelevante.

Más información | Wikipedia – Big Data y Publico (como ganó las elecciones Obama)

Imperva ha realizado un estudio llamado “Monitorizando los Foros de los Hackers“ (y casualmente se encarga de monitorizar los foros frecuentados por hackers en búsqueda de patrones que señalen que intereses están más extendidos) y los resultados apuntan directamente a que los ataques DDoS y los SQL injection están presentes en el 19% de las conversaciones.

Muchos de los que hayáis programado con PHP y MySQL (siguiendo el caso del ejemplo que os expongo abajo) os habréis puesto a implementar medidas de seguridad contra este tipo de ataques, pero muchos otros puede que no hayan parado a pensar en esto, y no solo ahora, sino hace años, cuando se crearon muchos de los actuales sistemas de algunas empresas donde puede que no se implementaran las medidas necesarias para evitar estos ataques y aún no se hayan solventado, ya que este mismo estudio revela que menos del 5% del presupuesto de TI va destinado a mejorar la seguridad de estos sistemas que pueden contener datos importantes (y expuestos a ataques).

Un repaso rápido a SQL injection

En resumen este tipo de ataques aprovechan las consultas que se han realizado en una página para introducir un código añadido que actúa como queramos.

Por ejemplo, si tenemos una consulta en la que le pedimos que nos muestre un dato determinado que está asociado a una ID numérica (como: `id` = '1') y alguien puede jugar con las comillas y añadir algún código indeseado (como sería borrar una tabla: `id` = '1'; DROP TABLE `Usuarios`;'').

Os voy a poner un ejemplo funcional muy básico (como el del otro día con el super ataque por fuerza bruta), en este lo único que hay es un archivo PHP que accede a una base de datos y busca en los registros una entrada donde coincida el usuario y la contraseña con la que le hemos mandado por un formulario.

Para realizar el ejemplo necesitas lo siguiente:

• 5 minutos.


• Un servidor PHP y MySQL (debería de dar igual local o en la nube).


• Tener desactivadas las magic_quotes (que evitan este tipo de ataques, y me ha tocado desactivar mediante una apaño que hay en php.net), tenerlo en cuenta por si misteriosamente no va la inyección.

La base de datos

Lo primero es crear la base de datos donde estarán los usuarios, que se llamará PruebaSQL, que contendrá la tabla Usuarios donde tenemos a tres usuarios con los siguientes datos (por cada usuario):

• ID: identificación numérica única (que se autoincrementa).


• User: nombre del usuario.


• Pass: contraseña del usuario (sin ningún tipo de encriptación ni hash, más que nada para que fuese más visual, ya que con este ejemplo funcionaría igual).

id	name		pass
+-------+---------------+-------
1	Pedro		qwerty
2	Carlos		12345
3	Manuel		password

El PHP

Este código es muy simple, tanto como una consulta que comprueba si existe algún registro que coincida el usuario y la contraseña con el que le hemos mandado por el formulario y si coincide (o hacemos coincidir por otros medios) nos avisa devolviéndonos el usuario y la id del usuario.

if(isset($_GET['login'])){	//Si la URL tiene la variable "login" establecida se ejecuta
	$mysql=mysql_connect('localhost','Usuario_DB','Contraseña_DB');	//Nos conectamos al servidor MySQL
	mysql_select_db('PruebaSQL',$mysql);	//Seleccionamos la DB sobre la que trabajaremos
	//Pasamos las variables conseguidas por el formulario mediante POST
	$user=$_POST['user'];
	$password=$_POST['password'];
	//Creamos la consulta con los datos del formulario
	$query=mysql_query("SELECT * FROM `Usuarios` WHERE `user`='".$user."' AND `pass`='".$password."'");
	$resp=mysql_fetch_array($query, MYSQL_ASSOC);	//Leemos la respuesta
	//Si hay una 'id' establecido en la respuesta se ejecuta (si los datos son incorrectos no se ejecuta)
	if(isset($resp['id'])){
		echo "Sesión iniciada con ID: ".$resp['id']." (".$resp['user'].")";	//Nos indica que hemos acertado
	}else{
		echo "Fallo en la autentificación";	//Hemos fallado en la autentificación
	}
	mysql_close($mysql);	//Cerramos la conexión con la base de datos
}

El HTML

Al igual que el PHP este formulario es muy simple, manda el usuario y la contraseña por POST a la misma página a la que esta pero pasándole la variable “login” (el equivalente a index.php?login=si).

<;form action="?login=si" method="post">
	User		<;input name="user"><;br>
	Password	<;input name="password"><;br>
	<;input type="submit">
<;/form>

Realizar el ataque

Voy a dar por hecho que todos sabemos lo que es una base de datos.
Para realizar el ataque lo que realmente haremos es mandarle unos datos erróneos al servidor y en la contraseña añadiremos la inyección de SQL, que consiste en añadir a esta misma consulta otra que nos devolverá los mismos datos, pero solo le necesitamos establecer la id (y como hay dos consultas y la primera no devuelve nada cogerá la segunda, inyectada).

#El usuario y la contraseña que mandamos son "Error", y se haría esta consulta:
SELECT * FROM `Usuarios` WHERE `user`='Error' AND `pass`='Error'
#Y en este ejemplo veremos el resultado de la inyección del SQL
SELECT * FROM `Usuarios` WHERE `user`='Error' AND `pass`='' UNION SELECT * FROM `Usuarios` WHERE `id` = '1'

Para conseguir el resultado de la inyección SQL tenemos que inyectar el propio código que modificará la consulta (en el campo de la contraseña del formulario):

' UNION SELECT * FROM `Usuarios` WHERE `id` = '1

Probarlo nosotros mismos

Este ejemplo se puede probar sin muchas complicaciones, creamos la base de datos, añadimos la misma tabla y añadimos el archivo PHP con el HTML incluido y tirando.

Pero como se que a muchos os dará pereza pasar toda esta odisea he subido el ejemplo, podéis probar a identificaros con el usuario y la contraseña que ya sabéis (las mismas que la de la tabla de Usuarios), y posteriormente probar metiendo el código inyectado, y podéis probar con distintas ID.

Vía | CSO España

Domingo. Y los domingos en Genbeta Dev son para las curiosidades, para echarnos unas risas y seguir desconectados, que el fatídico lunes está a la vuelta de la esquina. Hoy os presentamos Howfuckedismydatabase.com, una hilarante web donde, proporcionando cual es tu base de datos te ofrecen un diagnóstico muy profesional de como de jodida está… pero profesional en plan Pazos en ‘Airbag’, ya tu sabeh…

Ahora mismo está disponible el diagnóstico para Postgre, MySQL, MSSQL, Oracle, SQL Lite, MS Access y bases de datos NoSQL. Ve pinchando en todos los enlaces y pártete el pecho de la risa. Y ojo, será una parida de web pero hay consultoras carísimas que no te dan mucha más información de tus bases de datos. Además, para que no todo sea risa y diversión, te recomiendan libros y guías para desjoder tu base de datos. Todo un detalle.

Pd1: lo mismo esta web es más antigua que el Fortran y todos la conocéis pero yo no la había visto en mi vida hasta esta semana y lo cierto es que me ha hecho llorar de la risa.

Pd2: la gente detrás de esta genial web tienen otra de mucha utilidad para linuxeros de pro: Howfuckedismydistro.com. No apta para talibanes del software libre y/o gente sin sentido del humor.

Vía | Howfuckedismydatabase.com (a través de un tuit de @asiermarques)

Es muy frecuente al desarrollar aplicaciones que los requisitos no estén completamente definidos desde el principio y/o que éstos sufran cambios a corto y medio plazo, bien porque son descartados, modificados o porque aparecen otros nuevos. Es por ésto que las metodologías ágiles establecen estrategias que se adaptan a dichos precarios escenarios.

Carlos Ble en su post Diseño emergente, también para la base de datos describe una forma de trabajar a nivel de base de datos mediante un enfoque emergente. Si bien muchos programadores llevan utilizando estrategias ágiles (o emergentes) desde hace mucho tiempo, y que lo que Carlos describe también se realiza desde hace mucho tiempo; la clarividencia con la que técnicas concretas (Scrum, Kanban, …) y Carlos en su artículo ponen de manifiesto un determinado aspecto es, a mi juicio, muy interesante y revelador, porque te hace pensar de forma consciente sobre problemas que llevas resolviendo, “inconscientemente”, desde hace mucho tiempo.

Así, con independencia de lo correcto o no de cada solución, del tipo de contexto que cada uno tengamos que resolver (y que serán diferentes), el compartir nuestras estrategias hace que cada cual piense en sus propios problemas y tome de cada uno aquello que le resulta útil.

Por tanto, te propongo un ejemplo práctico de cómo normalmente yo aplico el enfoque de Diseño emergente en la base de datos.

Breve reseña al diseño emergente

Cuando alguien diseña algo (un avión, una casa, un coche, …) es habitual planificar todos y cada uno de los aspectos que finalmente formarán parte del producto. Así, todo es diseñado y planificado de antemano. A modo de ejemplo llevado al extremo, podemos imaginar un sencillo y humilde tornillo ubicado en la parte interna de uno de los motores de los ya obsoletos transbordadores espaciales de la NASA. Es muy probable que dicho tornillo esté presente explícitamente en multitud de planos (no en todos, claro, en algunos estará presente de forma implícita) y que su tamaño, dimensiones y composición química fueran diseñados o elegidos realizando un cálculo concreto. Quien montara el motor, puso ese tornillo y no otro, porque así estaba decidido de antemano.

Un carpintero, puede construir una silla a partir de planos similares a los usados en la NASA, pero será probable que no se le indique el tipo concreto de tachuela que debe usar ni cuantas debe poner. Así, cuando el carpintero tenga que poner las tachuelas a la silla, decidirá en ese mismo momento que tipo de tachuela pondrá y con que separación. Es decir, el diseño final de la silla ha emergido del propio proceso de construcción, en oposición a una cuidadosa planificación previa.

Llevado al extremo, podríamos imaginar a un artista frente a un tronco de madera; el artista no sabe (no ha decidido aún) que figura va a esculpir, empieza observando el material, va esquilmando los trozos de madera agrietados o dañados, golpeando aquí y allá. Al poco vislumbra la imagen de un caballo rampante y comienza a dar grosera forma al material, pero aún no sabe cual será la posición de las patas, la cola, la crin, … todos y cada uno de los golpes del artista son espontáneos no hay absolutamente ningún tipo de diseño previo, cuando termina su obra, podemos decir que el caballo rampante ha emergido del proceso realizado por el artista.

En el diseño de software y concretamente en el agilismo, el diseño emergente se produce al aplazar decisiones, análisis, trabajos y/o requisitos sin que ello impida comenzar a desarrollar y utilizar las aplicaciones y sistemas involucrados. En cierto momento, surge la necesidad de implementar un requisito que ni siquiera se había comentados con anterioridad, este nuevo requisito a emergido del uso y/o desarrollo de la aplicación.

¿Es necesario el diseño emergente en la base de datos?

El artículo de Carlos me gustó porque puso de manifiesto un aspecto que ha estado presente desde siempre, pero que él ha sabido exponer de forma explícita y no como “un problema menor” con el que nos encontramos a diario. En los siguientes párrafos, intentaré transmitir el tipo de problema que se trata.

Como en cualquier elemento de software, un cambio en una parte afecta a otras y las bases de datos (concretamente relacionales) no son una excepción. Por ejemplo el añadir, quitar o cambiar las propiedades de un campo de una tabla, requiere normalmente ajustar otras partes del sistema. En casos concretos se dispone de herramientas que automatizan ciertos procesos (eg. CRUD), pero en general, cualquier cambio aparentemente nimio, exige un esfuerzo apreciable en otras partes del sistema.

El uso de ORM (Object relational mapping) es hoy muy común y permite automatizar buena parte del trabajo que hace un DBA (DataBase Administrator) tiene bastantes (y ágiles) ventajas. Algunos de los problemas que voy a describir se mitigan o eliminan completamente usando un ORM pero otros se mantienen igualmente. A mi en particular sólo me gusta usar ORM en aplicaciones compactas que hacen uso intensivo de un framework (eg. un portal web), en general, yo me siento muy cómodo teniendo en todo momento control sobre la base de datos, por lo que asumiré en lo siguiente que no se usa un ORM.

Respecto de las bases de datos, algunos ejemplos habituales que me vienen a la cabeza son los “campos zombies”, que serían aquellos que se introducen en el diseño pero que luego nunca se usan o se usan realmente poco, están en la base de datos, pero como si no estuvieran, de forma similar tendríamos las “tablas zombies”; otro ejemplo podrían ser las “tablas tocapelotas” que en diseño se han definido como relaciones “uno a cero o uno” pero cuya partición termina siendo un infierno porque realmente debería ser una única tabla y en todas las consultas se arrastra un horripilante “LEFT OUTER JOIN” que nunca o casi nunca actúa (siempre se hace el JOIN); otros muchos ejemplos provienen de un exceso o falta de normalización, a veces el diseño está muy normalizado penalizando en demasía el rendimiento obligando o bien a desnormalizar el diseño o a crear estructuras adicionales de cacheado; el caso contrario es una falta de normalización (cuando en diseño se piensa que el producto cartesiano en la práctica será pequeño, pero no es así) que produce tablas con ingentes cantidades de registros (innecesarios).

En definitiva, existen muchas situaciones en las que el mejor diseño no está claro (los motivos de que no estén claros son muy variados y pocas veces debidas a cuestiones técnicas) y es sólo cuando la aplicación se pone en marcha que emergen esos fallos dejando patente un mal diseño.

Diseño emergente en la base de datos

Como solución a los problemas mencionados, Carlos propone incluir en las tablas que lo requieran un campo en el que serializar todos aquellos datos cuyo diseño no esté claro aún. Por ejemplo, podemos llamar al campo xdata y serializar a json, xml, … después utiliza esa información en la capa de aplicación.

Yo utilizo ese esquema cuando los datos dentro de xdata no tengo que procesarlos internamente en la base de datos, habitualmente porque hay aplicaciones externas y personalizables que hacen uso de ella. Aun así, rara vez directamente en un campo xdata como tal, yo prefiero normalizar ese campo, veamos como.

La tabla de registro

Muchos conoceréis el “Windows Registry”, realmente no es mas que una gran tabla que asigna un valor a una clave. La estructura arbórea que surge, proviene únicamente de fijar delimitadores en las claves (como una ruta de archivo en /home/josejuan/datos/listado.txt).

Un resumen muy general de mi estrategia preferida sería precisamente esa, tener una tabla que almacena pares de “clave + valor”.

Por poner un ejemplo, los diferentes estados en los que puede estar un semáforo, se podrían codificar como:

De esta forma, no es preciso crear una tabla semáforo para almacenar los posibles estados en que puede estar. Si por ejemplo cuestionamos la necesidad de tener un campo “telephone 3” en la tabla “USER” se podría codificar en la misma tabla anterior como:

Por claridad y rendimiento, suelo tener tablas de registro especiales para conjuntos de datos especiales. Por ejemplo, si nuestro sistema cuenta con entidades “EMPRESA” será habitual tener una tabla de registro especial para esta entidad.

Me consta que este tipo de estrategias de una u otra forma es usada por muchos programadores.

Ejemplo práctico

Por escribir algo de código y clarificar la estrategia anterior, supongamos que estamos creando una aplicación (usando Extreme programming) y que por el momento únicamente necesitamos registrar cuentas de acceso para los usuarios, en tal caso, con la siguiente tabla sería suficiente:

El Product Owner rápidamente empieza a pedir requisitos que si bien están claros, son coherentes y son validables, tenemos serias dudas de su utilidad práctica final (algo subjetivo mientras no se demuestre lo contrario) ¿serán necesarios los cuatro campos de teléfono, dos de fax, el correo principal, el secundario y otros tantos campos “de imperiosa necesidad”?. Tras ver las orejas al lobo, decidimos cumplir con los requisitos usando una tabla de registro, que podría ser ésta:

Por tema de eficiencia, hemos dejado dos campos valor: uno pequeño y con datos en la página de registro y otro blob de acceso lento. Como verás, el campo pequeño es de tipo varbinary porque será capaz de almacenar cualquier tipo de dato que sea necesario (nosotros almacenamos un número como un número, no como una cadena, una fecha como una fecha, etc…).

Para probar el rendimiento de las consultas, vamos a generar 10.000 registros de usuario con aproximadamente unos 100.000 registros de valores en la tabla de registro. Esto se puede hacer con el siguiente script:

Los datos han generado para cada usuario la siguiente información:

• last_access, un campo fecha con la fecha de último acceso del usuario.
• error_count, un campo numérico con el número de errores asociados al usuario.
• message_status, un campo de texto con un mensaje de estado asociado al usuario.
• message list, que es una tabla asociada al usuario con un histórico de mensajes (mensaje 1, mensaje 2, …).

Para acceder a los datos, se puede utilizar una vista que simule una tabla, de forma que se minimizan los cambios a realizar en las consultas (básicamente añadir o quitar campos) en caso de cambios en la estructura. Por ejemplo la siguiente vista permite acceder (indizada adecuadamente, es decir, es eficiente) a los campos de registro de cada usuario:

(Esta consulta es estándar pero puede implementarse mediante PIVOT TABLE que en ciertos escenarios puede tener un mejor rendimiento).

Para acceder al histórico de mensajes, también podemos simular una tabla a partir de la de registro, por ejemplo:

En ambos casos, a partir de una tabla de registro a la que pueden añadirse estructuras adicionales, hemos creado dos “tablas virtuales” sin tener que modificar la estructura de la base de datos.

Por ejemplo, para listar los usuarios con más de 9 errores en los últimos 3 días bastaría escribir:

O bien para saber cual es el número medio de mensajes y longitud media por mensaje de todos los usuarios bastaría con hacer:

Como vemos, podríamos incluso realizar vistas y consultas sobre datos (claves) que ni siquiera existen.

Utilidad de la tabla de registro

La utilidad de la tabla de registro es bastante limitada como medio de evolucionar “emergentemente” una aplicación. En mi opinión, otras técnicas ágiles, usar ORM o refactorizar serán probablemente mejores alternativas que trabajar en el diseño y estructura de la aplicación apoyándose en la tabla de registro.

Además, aunque depende del tipo de aplicación, cambios en la lógica de negocio e interface de usuario son mucho más costosos que en la base de datos, un DBA experimentado no tiene problemas en añadir, eliminar o modificar objetos de la base de datos, quizás son algo molestos, sobre todo si lo usas en combinación con una herramienta CASE y datos en vivo, pero nada que no se pueda hacer en unos minutos.

Sin embargo, la tabla de registro es insustituible como medio para añadir de forma rápida y versátil estructuras que no suponen un coste añadido o a posteriori. Para almacenar valores de informe, de histórico, datos constantes, de configuración, … y en general, datos que no tendrán un coste o cobertura muy alta en la aplicación (si un dato es altamente actualizado, accedido, mapeado, … desde muchos puntos, será preferible que tenga “entidad propia”).

Así, yo la uso indiscriminadamente como forma de disponer de un gestor No-SQL dentro de mi gestor Sí-SQL.

Vía | Diseño emergente, también para la base de datos.
Más información | Emergent Design.
Más información | Windows Registry.
Más información | Extreme programming.
Más información | Object relational mapping. Database Administrator.

Twitter, el gigante del microblogging, usa MySQL como base de datos para la gran mayoría de su sistema (tweets, timelines, datos del usuario…). Como es lógico en una web que tiene que soportar un tráfico tan brutal, han tenido que, aprovechando el carácter open source (de momento) del SGBD de Oracle, tunear MySQL al máximo para que ofrezca un rendimiento óptimo (aquellos pioneros que estábamos en Twitter en 2007 podemos dar fe de que la web estaba más tiempo caída que de pie). La novedad está en que la semana pasada Twitter decidió compartir con el resto de la humanidad este fork propio de MySQL.

Este Twitter MySQL está basado en MySQL 5.5, está disponible en Github, se comparte con una licencia BSD y Twitter hace hincapié en que lo comparte con fines ilustrativos y que no se va a encargar en ningún caso de bugs, compatibilidades o mantenimiento. Las características más novedosas de Twitter MySQL se pueden agrupar en cinco campos:

• Nuevas variables de estatus.
• Optimización del acceso a memoria no uniforme (NUMA).
• Timeout de las querys del lado del servidor.
• Exportación y restauración del pool de conexiones de manera más liviana.
• Optimización para dispositivos SSD.

Pues ya sabes, forkea, cacharrea y luego nos cuentas porque buena pinta desde luego tiene, visto desde fuera.

Vía | Twitter Engineering
Descarga | Github
En Genbeta Dev | MySQL deja de ser libre (nuestra inocentada del día)
En Genbeta Dev | Twitter libera Bootstrap, su framework CSS para aplicaciones

Oracle ha anunciado una nueva release de MySQL Cluster. En esta nueva release, se soporta el uso de NoSQL a través de una API C++ un protocolo memcached y una interfaz REST.

Por otro lado, el acceso a la interfaz SQL de toda la vida se realiza de la forma habitual (JDBC, etc). Oracle asegura que en esta nueva release se ha mejorado la velocidad al ejecutar consultas complejas por setenta, una información algo exagerada quizás.

Como siempre, Oracle lanza una release de su software propietario MySQL Cluster Manager que acompaña a MySQL Cluster (libre) y que tiene como fin ayudarnos a realizar despliegues de clusters MySQL.

Mejoras

También se ha trabajado para solucionar los problemas con los privilegios de usuario en la replicación y en la sucesión de un entorno más sencillo de administración de permisos y usuarios.

Como no, también se han hecho importantes avances en la tarea de certificar e integrar los nodos del cluster dentro de la infraestrutura Oracle VM para tomar ventaja de la escalabilidad elástica de los despliegues en la nube. MySQL Cluster 7.2 está certificado en Oracle Linux y Oracle Solaris.

NoSQL

En cuanto a como mapear una base de datos SQL relacional para que sea accesible via Memcached que puede llegar a ser un dolor, Oracle facilita el siguiente tutorial donde explican como conseguirlo, con un poco de trabajo eso si.

Futuro GPL

Lejos de lo que se vaticinaba en un primer momento, Oracle ha seguido desarrollando MySQL así como todo el stack de aplicativos y servicios que lo rodean mejorando su integración con el ecosistema de bases de datos de la compañía.

No sabemos hasta cuando seguirá siendo así pero mientras siga el buen trabajo por parte de la compañía, bienvenido sea, aunque supongo que para esto como para casi todo, habrá opiniones de diverso indole.

Via | InfoQ
En Genbetadev | MySQL en Genbetadev

Amazon Web Services ha anunciado el lanzamiento de DynamoDB, una base de datos NoSQL que ha desarrollado y probado internamente Amazon durante estos últimos años. La demanda de bases de datos NoSQL está en claro auge debido al crecimiento de los volúmenes de datos y aplicaciones web actuales. Por eso Amazon sabiendo esta necesidad ha añadido un nuevo miembro a su oferta de bases de datos en la nube compuesta hasta ahora por RDS (base de datos relacional) y SimpleDB (NoSQL).

Al igual que la mayoría de los servicios ofrecidos por Amazon Web Services, DynamoDB puede ser gestionada en unos pocos clics desde la consola de administración de AWS. Así si lo requerimos podemos iniciar una nueva tabla de DynamoDB, aumentar o disminuir los recursos, según las necesidades consultando las estadísticas de rendimiento.

Todos los datos se almacenan discos de estado sólido (SSD) para asegurar que el acceso de datos sea más rápido. Además de cuenta con una amplia infraestructura que replica los datos entre los distintos servidores repartidos por el mundo con la intención de ampliar las zonas de disponibilidad.

DynamoDB no tiene un esquema fijo. En su lugar, cada elemento de datos puede tener un número diferente de atributos. Se pueden usar varios tipos de datos como strings, números o conjuntos. Integra Amazon Elastic MapReduce lo que permite realizar análisis complejos de grandes cantidades de información usando Hadoop sobre AWS.

Es interesante saber que DynamoDB ha sido creado íntegramente por el equipo de Amazon, los cuales siguen siendo reacios a integrar alguna de las bases de datos NoSQL en el mercado. Ya en 2007 publicaron un paper con detalles sobre los que sería la tecnología que implementaría DynamoDB y que la compañía ha ido probando en sus propios productos. El uso más reciente del que se enorgullecen es haber trasladando los metadatos de su Amazon Cloud Drive de una base de datos relacional a DynamoDB en previsión del pico de tráfico que provocaría la salida al mercado del Kindle Fire.

Más información | Amazon DynamoDB
Vía | All Things Distributed