Instalación de Apache Cassandra

De ChuWiki
Saltar a: navegación, buscar

Apache Cassandra es una de las bases de datos pensadas para correr de forma distribuida en varios servidores y para distribuir sus datos en varios discos, replicados o no. Veamos aquí una instalación básica y unos primeros ejemplos.


Instalación y Descarga

Podemos bajarnos un instalable para nuestro sistema operativo o bien un zip para desempaquetar en cualquier directorio de nuestro gusto de la página http://cassandra.apache.org/download/

Nos bajamos el tar.gz y con algún programa para desempaquetar ficheros lo desempaquetamos en cualquier directorio de nuestra elección. Antes de arrancar, revisemos algunos parámetros de configuración que nos puede interesar tocar. Vamos al fichero conf/cassandra.yaml en el directorio donde hayamos desempaquetado Cassandra y lo editamos. Buscamos una línea

cluster_name: 'Test Cluster'

este es el nombre que deseamos para nuestro cluster de apache cassandra. Si varios servidores de apache cassandra van a correr juntos trabajando conjuntamente, todos deben tener el mismo nombre de cluster. Una vez arrancado apache Cassandra, este nombre se guardará en una base de datos propia de Apache Cassandra y no será tan fácil volver a cambiarlo, de hecho, si lo cambiamos en el fichero y rearrancamos Cassandra, dará un fallo y no arrancará, por no coincidir el nombre de cluster en el fichero con el que tiene almacenado internamente. Por ello, antes de arrancar Apache Cassandra, conviene pensar qué nombre queremos y ponerlo. Todos los servidores que vayan a trabajar en conjunto deben tener el mismo nombre.

La siguiente propiedad de interés es

data_file_directories:
 - /var/lib/cassandra/data

Aquí es donde Cassandra guardará los datos. Conviene poner un directorio que nos guste para nuestros datos. Cassandra lo creará si es necesario.

Otra propiedad relacionada con la anterior es

commitlog_directory: /var/lib/cassandra/commitlog

aquí es donde Cassandra dejará los ficheros de log. Puesto que una de las cosas que más limitan el número de transacciones por segundo que podemos hacer en una base de datos es la velocidad del disco duro y la cantidad de accesos que hacemos a él, Apache Cassandra aconseja que los ficheros de log y datos se configuren en discos separados.

Finalmente, la línea

listen_address: localhost

indica qué sólo se aceptarán conexiones de localhost. Si queremos poder conectarnos desde el exterior, debemos poner ahí en vez de localhost la IP de nuestro ordenador.

Arranque de Cassandra

Una vez configurado Cassandra (o directamente si la configuración por defecto nos vale), arrancar Cassandra en fácil. Basta situarse en el directorio bin de nuestra instalación de Cassandra y ejecutar el comando cassandra.bat (o cassandra para linux), bien desde línea de comandos, bien haciendo doble click sobre dicho fichero. Aparecé una ventana de ms-dos con todo el log de arranque y listo.


Hacer alguna prueba

Arrancamos un cliente de Apache Cassandra que viene en el directorio bin de Cassandra. En concreto, puede ser cassandra-cli.bat (casandra-cli para linux) o bien si tenemos python instalado, podemos arrancar el ciente cqlsh que viene en el mismo directorio

c:\Python27\python.exe cqlsh

o el comando equivalente de linux

Ambos clientes (cassandra-cli y cqlsh) son válidos. La diferencia es que cli es un cliente de más bajo nivel, posiblemente más adecuado para aprovechar al 100% las posibilidades de Apache Cassandra, mientras que cqlsh es de más alto nivel, usando un lenguaje similar a SQL llamado CQL y que pretende convertirse en el estándar para acceso a Apache Cassandra. Por ello, Cassandra recomiendo dentro de lo posible usar cqlsh.

Veamos algunos ejemplos con ambos clientes

Creación de un Keyspace

Un keyspace es el equivalente en una base de datos tradicional a una base de datos, es decir, el sitio en el que vamos a agrupar tablas. Al definir un keyspace en Cassandra es donde decidimos si queremos copias de los datos en varios de los servidores o sólo en uno. En función de esto, cassandra repartirá los datos entre los servidores disponibles.

Con cli, el keyspace se puede crear así

CREATE KEYSPACE demo
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = {replication_factor:1};

Con cql, sería

CREATE KEYSPACE demodb
WITH REPLICATION = {'class' : 'SimpleStrategy', 'replication_factor': 1};

El nombre del keyspace es demo o demodb, la estrategia para repartir los datos en los servidores es SimpleStrategy (la otra opción es NetworkTopologyStrategy). El replication_factor indica cuántas copias queremos del dato en los distintos servidores.

Creación de una familia de columnas

La familia de columnas es el equivalente a una tabla SQL, aunque mucho más versátil que una tabla. En una familia de columnas podemos guardar varios registros identificados por una clave (igual que en una tabla SQL), pero la diferencia es que cada registro puede tener sus propias columnas (nombre y valor), mientras que en una tabla SQL las columnas son iguales para todos los registros.

Al igual que en SQL, antes de crear la familia de columnas (tabla), debemos usar el key space (base de datos) que acabamos de crear.

Con cli sería

use demo;

CREATE COLUMN FAMILY users
WITH comparator = UTF8Type
AND key_validation_class=UTF8Type
AND column_metadata = [
   {column_name: full_name, validation_class: UTF8Type}
   {column_name: email, validation_class: UTF8Type}
   {column_name: state, validation_class: UTF8Type}
   {column_name: gender, validation_class: UTF8Type}
   {column_name: birth_year, validation_class: LongType}
];

Hemos creado la familia de columnas "users" con 5 columnas. UTF8Type es un campo de texto y LongType un entero de 8 bytes. http://www.datastax.com/docs/1.2/cql_cli/using_cli . La clave de la tabla es ese UTF8Type que sigue a users, es decir, un texto hace de clave.

Con clq sería

use demodb;
CREATE TABLE users (
  user_name varchar PRIMARY KEY,
  password varchar,
  gender varchar,
  session_token varchar,
  state varchar,
  birth_year bigint
);

Hemos creado nuevamente una tabla "users" con varios campos, en el que el user_name es la clave primaria.

Insertar datos

Con cli, los datos se insertan a base de hacer SET en las distintas "celdas" de la tabla, usando como fila la clave de users (su nombre por ejemplo) y de columna, el nombre de la columna cuyo valor queremos poner. Por ejemplo

SET users['bobbyjo']['full_name']='Robert Jones';
SET users['bobbyjo']['email']='bobjones@gmail.com';
SET users['bobbyjo']['state']='TX';
SET users['bobbyjo']['gender']='M';
SET users['bobbyjo']['birth_year']='1975';

Con CQL, tenemos el insert y update tradicional, aunque no hay mucha diferencia entre uno y otro en cassandra, ya que en un caso como este en el que la clave es el nombre de usuario, cassandra hará automáticamente insert o update según exista o no el usuario, independientemente de que escribamos insert o update.

insert into users
(user_name, password, gender) values
('pedro','una clave', 'tio');

Consultar datos

Con cli, podemos obtener todos los datos con list

list users;

o bien, con get para obtener datos concretos, toda la fila, o una celda concreta.

get users['bobbyjo'];
get users['bobbyjo']['full_name'];

con cql, es un select similar a los de SQL

select * from users where user_name='pedro';