Instalar Cassandra en Ubuntu

ByLuis

Con tanta noticia de Cassandra y Twitter, me ha dado por instalar Cassandra en local. No soy un experto en Ubuntu, más bien soy un poco torpe en algunas cosas de administración, pero bueno, si yo lo he conseguido ¿por qué no ayudar a aquellos que pueden ser tan torpes como yo?

Lo primero que hay que hacer es bajarse la última versión: http://cassandra.apache.org/#download

Una vez descomprimido y renombrada la carpeta a cassandra, lo muevo al directorio /opt:

sudo mv cassandra /opt/

Luego creamos unos cuantos directorios necesarios para la aplicación:

sudo mkdir -p /var/lib/cassandra/{commitlog,data,callouts,staging}
sudo mkdir /var/log/cassandra
sudo chmod -R 777 /var/lib/cassandra/

Creamos el fichero /var/log/cassandra/system.log y le damos permisos de escritura:

sudo chmod 777 /var/log/cassandra/system.log

Bueno, pues esto ya está instalado, ahora solo falta ejecutar Cassandra y luego probarlo con la aplicación CLI:

/opt/cassandra/bin/cassandra -f &
/opt/cassandra/bin/cassandra-cli -host localhost -port 9160

Podéis hacer pruebas con los ejemplos que salen aquí.

Actualizado: Armonth me indica un truco que simplifica la creación de los directorios, muchas gracias.

|

PHPillow: librería PHP para CouchDB

ByLuis

PHPillow es una librería PHP que nos permite interactuar con CouchDB (base de datos documental de Apache basada en JSON).

Ahora que el NoSQL es una alternativa a las bases de datos relacionales, esta librería nos ayudará bastante a la hora de realizar nuestra aplicación, ya que el código es bastante sencillo.

class myBlogDocument extends phpillowDocument { 
  protected static $type = 'blog_entry'; 
  protected $requiredProperties = array( 'title', 'text', ); 
  public function __construct() { 
    $this->properties = array( 
      'title' => new phpillowStringValidator(), 
      'text' => new phpillowTextValidator(), 
      'comments' => new phpillowDocumentArrayValidator( 'myBlogComments' )
    ); 
    parent::__construct(); 
  } 
  protected function generateId() { 
    return $this->stringToId( $this->storage->title ); 
  } 
  protected function getType() { 
    return self::$type; 
  } 
}

PHPillow

Comparativa de Data Stores

ByLuis

Entendiendo por Data Stores los sistemas de almacenamiento tanto RDBMS o NoSQL, el PDF que referencio compara los distintos tipos de data stores que hay:

  • Almacenamientos clave-valor
  • Almacenamiento de documentos
  • Similares al BigTable de Google
  • BD relacionales escalables

De cada tipo de data store explica cuales son y que características tiene, y por último hace comparativa entre ellos. También nos dice posibles ejemplos de uso:

  • Sistemas clave-valor: útil cuando los datos almacenados se basan en el acceso de información mediante un ID (sin joins) y que se actualiza pocas veces o se actualiza siempre de la misma manera.
  • Almacenamiento de documentos: cuando la información almacenada depende de varios campos (por ejemplo un stock de vehículos).
  • Sistemas basados en BigTable: se puede tratar de aplicaciones similares a los almacenamientos documentales, pero con la diferencia de que es necesario un elevado número de registros.
  • RDBMS escalables: cuando nuestra aplicación necesita de relaciones entre distintos datos y nuestro servidor se queda corto para aguantar el volumen de datos o de transacciones.

Me gustaría destacar que entre estos data store, se encuentra Cassandra, proyecto open source de Facebook, que ahora es un proyecto de Apache y que Twitter va a usar para sustituir MySQL.

High Performance Scalable Data Stores

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

Terrastore: base de datos documental

ByLuis

Terrastore es una BD documental distribuida que ofrece escalabilidad sin quitarle consistencia. Entre sus características encontramos:

  • Accesible mediante HTTP
  • Distribuida: permite distribuir los nodos por cualquier servidor de nuestra red
  • Elasticidad: permite quitar y poner nodos sin necesidad de parar el servicio o cambiar la configuración
  • Escalabilidad en la capa de datos: los documentos se dividen y reparten por los nodos con balanceo automático y unión de las partes
  • Escalabilidad computacional: las queries y updates se distribuyen por los nodos reduciendo el tráfico
  • Consistencia: ofreciendo consistencia para los documentos, garantizando que siempre obtendrás el último valor de un documento, con aislamiento de la lectura de posibles commits de modificación

Terrastore

Vía / High Scalability

Parche para indexar Drizzle con Sphinx

ByLuis

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

Meter trazas en tus consultas SQL

ByLuis

En muchas ocasiones nos encontramos con que alguna query va lenta y tenemos que mirar el SHOW PROCESS LIST para localizar la query lenta, y luego buscarla en el código, algo que suele ser bastante pesado y a veces complicado.

Mi compañero David ha tenido hoy una brillante idea que nos va a facilitar a los dos la tarea de encontrar queries lentas en el código, para ello se trata de añadir un comentario en la query indicando la clase, el método y la línea:

select /* clase, metodo, linea */ campo from tabla

Sencillo pero muy efectivo

Cómo “tracear” consultas SQL

Bases de datos para tener en cuenta

ByLuis

No solo de MySQL vive el desarrollador web, por lo que está bien conocer estas otras bases de datos:

Alternativas opensource de BigTable de Google:

Alternativas opensource de Amazon Dynamo, almacenamiento distribuido:

Otros proyectos interesantes:

QCon London 2009: Database projects to watch closely

Vía / High Scalability

Artículos sobre BD

ByLuis

Buena recopilación de artículos sobre bases de datos, en inglés, pero interesantes:

10 Useful articles about Database design

Cuando no hay que normalizar la base de datos

ByLuis

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