La ventaja de Cassandra es su capacidad de escalar a través de una configuración de anillo en un cluster. La información de la base de datos se distribuye entre todos los nodos configurados y puede ser accedida desde cualquiera de ellos. En este caso, la distribución es muy parecida a Riak, incluso emplean el mismo protocolo para intercomunicación entre nodos: Gossip; además, se requiere de generar un token especial balanceado para la configuración de cada nodo de Cassandra. En esta página hay un código escrito en Python para poder hacer esta tarea.

El acceso a la base de datos se realiza mediante RPC y usando Thrift, que representa otra de las 7 tecnologías clave de Facebook, y también liberada como software libre. Como Thrift es multi-lenguaje, está implementado en muchos de los lenguajes existentes, no hay problemas de implementación, ya sea en Python, Perl, PHP, Java, Erlang, etc.

¿Es NoSQL?

En un principio, usando la base de Thirft y las funciones estándar que podemos ver en cualquier documentación, podríamos decir que sí es NoSQL. Nos proveen de funciones para realizar un CRUD básico a través de la inserción, actualización, eliminación y obtención de datos desde la base de datos. No obstante, la búsqueda queda un poco en el aire, ya que para poder buscar por cualquiera de las columnas creadas, hay que prefijar un índice.

Vamos al principio para entenderlo mejor. Haciendo una similitud con el modelo relacional, podemos ver que Cassandra dispone de los siguientes elementos:

• Keyspace: debe de crearse un keyspace para almacenar la información y, a la hora de conectar, hay que indicar que keyspace se quiere utilizar. Esto es similar a lo que en las bases de datos tradicionales es la base de datos en sí.
• Column Family: la información se guarda en columnas dentro de la keyspace, pero se agrupan en familias para identificar la separación entre un conjunto de datos y otro. Por lo tanto, dentro de las keyspace debemos de crear column families, lo que en las bases de datos tradicionales serían las tablas.
• Columnas: son cada una de las columnas que se agrupan bajo una familia, que se declaran con un tipo (para validación del dato) y con un nombre. Si se establece un índice sobre la misma, entonces se da la posibilidad de poder buscar utilizándola.

Llegados a este punto, vemos diferencias con otras NoSQL, como por ejemplo Riak. Riak tiene buckets donde Cassandra tiene keyspaces. En Riak cada bucket almacena claves a las que se les asigna un valor… en Cassandra esto no existe, ya que la clave de Cassandra está un nivel más abajo, cuando ya se han definido las familias de columnas. Esto deja a Cassandra entre dos mundos.

Entre SQL y NoSQL… CQL

Para confirmarlo, Cassandra dispone de un lenguaje de consulta que hace posible el empleo del mismo para realizar búsquedas entre sus familias de columnas, sobre las columnas que se hayan definido (con índice, claro). Este lenguaje provee de las órdenes básicas para realizar inserciones, actualizaciones, eliminaciones y obtención de datos.

Es más, el lenguaje en sí es llamado CQL y, viendo su sintaxis se sabe el porqué de la similitud con SQL. Por ejemplo, si tenemos creada la familia de columnas contactos, con una columna llamada nombre, y otra telefono, podemos realizar la siguiente consulta:

SELECT nombre, telefono FROM contactos

En las nuevas versiones de Cassandra, además, se puede emplear, en lugar de cassandra-cli el nuevo cqlsh, que permite emplear los comandos en formato CQL para manejar el cluster y hacer consultas al mismo. Esto hace pensar que Cassandra se comienza a desplazar cada vez más hacia el modelo relacional, dejando el paradigma de clave-valor muy atrás.

No obstante, facilita el acceso a este tipo de base de datos, a sistemas tan potentes, como para mantener un conjunto de máquinas en activo, en un anillo balanceando peticiones y en modo maestro-maestro con cada nodo.

Conclusiones

Después de darle bastantes vueltas y emplearlo para un par de desarrollos, he encontrado Cassandra bastante potente para el desarrollo de aplicaciones en las que la información se mantiene estática y se puede capturar de forma fácil a través de sus claves. Es muy rápido dando la información y él mismo balancea entre los nodos que tenga configurado.

Una nota negativa puede ser el hecho de que la búsqueda de información se hace bastante dificultosa debido a que, los datos de las columnas tienen que estar prefijados y muchos datos, en el enlace con Thrift, no funcionan bien. Así mismo, el filtrado por cualquier campo obliga a crear un índice sobre ese campo, lo que conlleva más ocupación de espacio y ralentizar un poco las inserciones, modificaciones y eliminaciones.

En definitiva, es una base de datos con capacidad fácil para montarse en forma de cluster, que permite una rápida ingesta de datos (siempre que tengan un formato prefijado), y una consulta también rápida de los mismos. No es indicado para sistemas en los que las consultas se puedan complicar, ya que requiere en ese caso de la creación de muchos índices e incluso muchas tablas intermedias para no perder la pista de la información. Al final, la mayoría de código hay que ejecutarlo del lado del cliente, por lo que cuanto más difícil sea el esquema de datos, más lento se volverá.

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador… pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

La solución que se puede emplear: rewrite. En Apache, a través del módulo mod_rewrite, se pueden crear reglas de redireccionado de modo que una URL que es:

http://midominio.com/?p=129&a=crea-usuario

Se puede convertir en:

http://midominio.com/crea-usuario/129

En el caso concreto, tan solo bastaría con agregar un bloque de configuración como el siguiente:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.+)/([0-9]+)$    /index.php?p=$2&a=$1

Para más información vea la documentación oficial de Apache.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.