Twitter ha lanzado hoy su base de datos de grafos (graph database) basada en MySQL, pensada para usarse en aplicaciones ajenas a Twitter, pero logicamente para almacenar las relaciones entre usuarios (following, followers).
Por ahora parece que es una versión básica, pero cuando esté correctamente me gustaría ver la relación con OQGraph
La normalización es el proceso por el cual se optimizan las tablas de una base de datos para que no haya datos redundantes, se optimice el espacio en disco y se evite errores en la actualización de datos. Ahora bien, aunque la normalización es el estado idóneo para la base de datos, eso no quiere decir que sea el más idóneo para nuestra aplicación.
Existen un caso perfecto cuando la normalización no es adecuada y es cuando la obtención de datos es lenta. Si normalizamos y eso implica que para obtener los datos tengamos que realizar varios joins, al haber muchos datos puede darse la situación de que las consultas sean lentas.
Algo parecido nos ha pasado en Bitacoras.com, ha sido necesario desnormalizar para mejorar la velocidad de respuesta. Imaginaros, teníamos que mostrar dentro de la Comunidad de los usuarios los posts de los usuarios a los que sigues y su actividad (tal sigue a cual).
Como se puede apreciar son datos totalmente distintos y lógicamente van en tablas diferentes, y a parte hay que obtener los datos de los usuarios a los que se sigue y usarlos para obtener sus posts (de todas sus bitácoras) y sus actividades y ordenarlos por fecha descendiente. Solo de leerlo ya me aparecen unos cuantos joins por la mente.
La solución ha sido crear una tabla de enlaces a ids de otras tablas. En la misma tabla tengo enlaces a los posts y a las actividades y a los ids de los usuarios. Es más rápido (unas 300 veces) debido a que existe paginación y es preferible obtener ids de dos tablas en una consulta sencilla y luego obtener n registros sencillos, que obtenerlo en una única consulta.
Otra cosa que he observado es que puede ser más rápido obtener una lista de IDs (sacadas de una consulta) y luego comparar haciendo un IN que hacer un join de dos tablas, cuando una de estas tablas se obtiene mediante una consulta.
Al final lo que nos queda es que la teoría no es siempre válida y que las situaciones en las que nos podemos encontrar hacen que la solución menos elegante sea la más efectiva
Thudb es un conjunto de servicios construidos sobre el framework Thrift de Facebook que provee servicios de indexación y almacenamiento de documentos para realizar y escalar sitios web. El propósito es ofrecer a los desarrolladores web servicios flexibles, rápidos y fáciles de usar que pueden mejorar y reemplazar los sistemas tradicionales de almacenamiento y las capas de acceso.
Entre sus caracterÃsticas nos encontramos con la disponibilidad de clientes para la mayorÃa de los lenguajes, replicación de múltiples master, backups incrementales, multiples backends de almacenamiento (S3 incluido), escalabilidad y API de búsqueda (Lucene).
Los servicios disponibles incluye el almacenamiento de documentos, indexación y búsqueda, cola de mensajes, particionamiento y balanceo de carga.
Thrudb
La verdad es que se trata de algo poco usado, son dos opciones a tener en cuenta en el futuro: Sphinx y Drizzle, aunque Sphinx cada vez se usa más en proyectos con gran volumen de datos, y Drizzle también es algo que debemos tener en mente con todo lo que pueda pasar con MySQL y Oracle o simplemente porque está enfocado a web.
Pues para quien trate con ambas tecnologías le puede venir muy bien este parche para poder usar ambas a la vez.
Drizzle patch for Sphinx 0.9.9-rc2
Para aquellos que necesiten Cassandra en sus proyectos o quieran trastear con él, les vendrá muy bien esta librería basada en CRUD. Soporta las estructuras de datos ofrecida por Cassandra y sus tipos de datos:
Un ejemplo de código sería el siguiente:
class Address extends PandraSuperColumn {
public function init() {
$this->addColumn('city', 'string');
$this->addColumn('street', 'string');
$this->addColumn('zip', 'int');
}
}
class Addresses extends PandraSuperColumnFamily {
public function init() {
$this->setKeySpace('Keyspace1');
$this->setName('Super1');
$this->addSuper(new Address('homeAddress'));
$this->addSuper(new Address('workAddress'));
}
}
$keyID = 'kenlogin';
$addrs = new Addresses();
$addrs->setKeyID($keyID);
// home address
$homeAddr = $addrs->getColumn('homeAddress');
$homeAddr->setColumn('city', 'san francisco');
$homeAddr->setColumn('street', '1234 x street');
$homeAddr->setColumn('zip', '94107');
// work address
$workAddr = $addrs->getColumn('workAddress');
$workAddr->setColumn('city', 'san jose');
$workAddr->setColumn('street', '9876 y drive');
// custom labelled supercolumn
$customAddr = new Address(''customAddress');
$customAddr->setColumn('city', 'another city');
$addrs->addSuper($customAddr);
// Saving via Column Family
$addrs->save();
// Saving via Super Column,
$customAddr->setColumn('city', 'another city');
$customAddr->save();Unos cuantos enlaces rápidos, con temática centrada en NoSQL
MemcacheQ es una interesante implementación de Memcache que permite realizar una cola de mensajes que luego podremos utilizar en nuestras aplicaciones de formas variadas, por ejemplo, si tenemos un proceso largo que queremos dividir y realizar partes en background, podemos crear una cola de mensajes e ir añadiendo distintas tareas para luego ir recuperándolas una a una.
MemcacheQ permite crear distintas colas y cuando se recupera un valor de la cola se borrará de esta. Imaginemos que tenemos un blog en el que cuando se publica un post se deben realizar una serie de tareas complejas, y no queremos tener a WordPress o Drupal o lo que usemos esperando para dar el OK de post publicado, lo que haríamos sería añadir un mensaje en la cola y luego con una tarea usando el cron, ir ejecutándolas una a una:
/* Método de publicación */
// Conectamos al servidor
$memcache_obj = memcache_connect('memcacheq_host', 21201);
// Añadimos el mensaje a la cola
memcache_set($memcache_obj, /* id_cola */ 'tareas_del_blog', /* mensaje */ $id_post, 0, 0);
memcache_close($memcache_obj);
/* Método del cron */
// Conectamos al servidor
$memcache_obj = memcache_connect('memcacheq_host', 21201);
$id_post = memcache_get($memcache_obj, 'tareas_del_blog');
tarea_enorme($id_post);
memcache_close($memcache_obj);Vía / PDPDeveloper.org