Curso Datastax: Cassandra - Practica 6

En esta última practica se añaden vistas estadísticas y se utilizan características avanzadas de Cassandra para optimizar algunas partes de la aplicación.

Ejercicio 1 - Usando contadores para recolectar estadísticas

 
Añadimos la tabla de estadísticas:

CREATE TABLE statistics (counter_name text PRIMARY KEY, counter_value counter);

Implementamos el método StatisticsDAO.increment_counter y SatisticsDAO.decrement_counter. Para incrementar o decrementar un contador debe utilizarse una instrucción update:

 
Comprobamos que la pagina de estadísticas de la aplicación web funciona correctamente; nos dice que tenemos 2 usuarios y 5 playlist, lo comprobamos en el shell:
 

SELECT * FROM users;
username | password | playlist_names
----------+----------+-------------------------------
  astwin1 |     test |            {'test1', 'test2'}
  astwin2 |     test | {'test''3', 'test1', 'test2'}

Ejercicio 2 - Verificando logins leyendo con un mayor nivel de consistencia (quorum)

 

Una de las características de las que dispone Cassandra es que permite escoger el nivel de consistencia que se desee. Por defecto, sólo requiere que una de las replicas de los datos entre los nodos sea leída en una consulta. Se puede escoger un valor más elevado de consistencia, requiriendo que más de una de las replicas de los datos sea leída, comprobada (comprobar que todos los nodos contienen la misma información actualizada) y poder obtener el valor más reciente de un valor.

Debemos modificar el método UserDAO.getUserWithQuorum para añadir un nivel de consistencia de quorum en la consulta:

Ejercicio 3 - Usando paginación

 

Automatic paging introduced in Cassandra 2.0, allows the developer to iterate on an entire ResultSet without having to care about its size: some extra rows are fetched as the client code iterate over the results while the old ones are dropped. The amount of rows that must be retrieved can be parameterized at query time. In the Java Driver this will looks like:

Statement stmt = new SimpleStatement("SELECT * FROM images");
stmt.setFetchSize(100);
ResultSet rs = session.execute(stmt);

Modificar el método  TracksDAO.listSongsByGenre para obtener 200 entradas cada vez (paginación):

Ejercicio 4 - Mejorando el rendimiento de las consultas con una cache de registros

 
En las tablas que más se lean se puede activar una caché para almacenar la últimas consultas. Si las consultas se realizan muy a menudo a esa tabla se puede obtener ventaja, leyendo de la caché en vez tener que traer los datos otra vez del cluster.

Utilizar la herramienta nodetool y el comando info para ver que el tamaño de caché de registros es 0 (también aparecen las estadísticas de la caché):
 

Aumentamos a 50 MB la caché de registros modificando el archivo cassandra.yaml:

astwin@astwin-H87-HD3:~$ sudo gedit /etc/cassandra/cassandra.yaml

# Default value is 0, to disable row caching.
row_cache_size_in_mb: 50

Activamos la caché en alguna de las tablas. Lo hacemos en la de tracks_by_genre por ejemplo:

cqlsh> ALTER TABLE playlist.track_by_genre WITH caching='rows_only';
cqlsh> use playlist ;
cqlsh:playlist> describe KEYSPACE;

 
Reiniciamos Cassandra:

astwin@astwin-H87-HD3:~$ sudo service cassandra restart

Miramos unas cuantas veces la misma consulta en la web de canciones por género y comprobamos las estadísticas de la caché de registros (rows) para ver que sí se ha utilizado la caché (y se habrá obtenido un beneficio en rendimiento en las consultas):

Row Cache        : size 12964446 (bytes), capacity 52428800 (bytes), 27 hits, 32 requests, 0,844 recent hit rate, 0 save period in seconds 

Ejercicio 5 - Variable estática para 'PreparedStatement'

 
Uno de los beneficios de utilizar un PreparedStatement en la API de Java para realizar consultas, es que se puede instanciar el objeto una única vez y reutilizarlo en las posteriores consultas. Se nos pide crear una variable estática de este tipo para que sólamente se tenga que instanciar una única vez: