FlockDB: base de datos de grafos basada en MySQL de Twitter

ByLuis

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

FlockDB

Similar Posts

|

Oracle creará un driver open source para PHP

ByLuis

OracleA parte de la casi compra de Bea por parte de Oracle (sería una buena noticia para los que desarrollen con Weblogic), nos enteramos de una gran noticia para los desarrolladores de PHP, y es que Oracle contribuye con un driver PHP open source para su OCI8. Este driver nos permite acceder a las características que nos ofrece la base de datos de Oracle, pudiendo así disponer del pool de conexiones, entre otras cosas.
Uno de las prioridades de Oracle es hacerse un hueco en la web2.0, para lo cual en colaboración de Zend pretende sacar este driver para así poder realizar aplicaciones que necesiten la robustez de la base de datos Oracle.
Oracle Contributes Open Source Driver for PHP

|

Neo4j Gets Geo Support

ByLuis

I guess that’s what kept the Neo Technology — the guys behind Neo4j — busy lately: The Neo4j Spatial project supports the use of geographic data by providing utilities that simplify and support advanced capabilities like: Storage of geographic features like points, lines and polygons as graphs Indexing and querying based on location with R-trees, Q …

Post original

Enlaces rápidos (04-06-2010)

ByLuis

Más enlaces rápidos sobre NOSQL, para variar:

Consejos para diseñar una base de datos

ByLuis

Diseñar una base de datos no es algo sencillo y sí muy importante, ya que un mal diseño conlleva dificultades para desarrollar la aplicación o una aplicación compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo.

  • Mal diseño: el diseño es lo fundamental, primero hay que saber qué es lo que se necesita mostrar para luego diseñar correctamente la base de datos. Yo personalmente me he encontrado con diseños iniciales muy básicos que luego han ido parcheando y haciendo modificaciones drásticas para ajustarlas a un modelo que era el mismo desde el inicio de la aplicación.
  • Ignorar la normalización: la normalización es fundamental para un buen rendimiento y una sencilla programación.
  • Nomenclatura no estándar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseño.
  • Falta de documentación: esto es una constante en todo el mundo de la programación, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que tú.
  • Una tabla que agrupa a muchas: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor meterlo todo en una única tabla.
  • Usar un identificador como única clave primaria: no siempre es correcto usar únicamente un identificador numérico secuencial como clave primaria única.
  • No usar las características de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaños de los campos y claves secundarias en el diseño para obtener una mejor integridad de datos.
  • No usar procedimientos almacenados para obtener los datos: es una forma de separar la capa de la base de datos de la capa del usuario. Aportan seguridad, encapsulamiento, mantenibilidad y rapidez. Yo también añadiría el uso de vistas.
  • Falta de pruebas: algo para mí muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitará la aplicación. Comprobar el tiempo de ejecución de las sentencias para añadir índices, etc…

Podéis ver todos estos puntos muy bien explicados y de forma extensa en el artículo original.

Ten Common Database Design Mistakes

HyperGraphDB: otra base de datos de grafos

ByLuis

Si hace tiempo hablé de OQGraph, un plugin para MySQL para almacenar grafos, en este caso se trata de una BD diseñada específicamente para ello. HyperGraphDB es una base de datos orientada a inteligencia artificial y redes sociales que mediante el almacenamiento de grafos facilita aplicaciones de este estilo.

Se trata de una BDopen source realizada en Java que es extensible, portable, distribuida y incrustable. Y cuyas características principales son:

  • Un segmento puede apuntar a más de un nodo.
  • La unidad básica de almacenamiento se llama átomo y cada átomo tiene su tipo y puede apuntar a ninguno o más átomos.
  • Los tipos de datos se manejan mediante un sistema almacenado en una estructura hipergrafo. Los tipos son en sí átomos pero con un rol particular.
  • Es accesible por cualquier lenguaje de programación y el sistema de almacenamiento usado a bajo nivel se basa en BerkeleyDB.
  • Procesos distribuidos basados en P2P para replicación y particionamiento de datos.

Vamos, una joyita para implementar una red social, aunque estaría bien conocer pruebas de rendimiento.

HyperGraphDB

Vía / High Scalability