¡Participa de la Maratón Behind the Code, la competencia de programación más desafiante! Inscríbete aqui

Configuración de la arquitectura base de Apache Cassandra

Aunque es posible que usted ya lleve algún tiempo escuchando acerca de big data y de las bases de datos NoSQL, quizá todavía no haya tenido la oportunidad de trabajar con ellos. Aunque es posible que usted ya sepa que una base de datos NoSQL podría ayudarle en alguno de sus proyectos, quizá no tenga confianza para empezar con la tarea. Si es así, este tutorial está aquí para ayudarle.

Le guiará a través de la configuración de uno de los mejores y más resilientes almacenes de big data disponibles: Apache Cassandra. Este es un tutorial práctico para desarrolladores y administradores de bases de datos que tengan conocimientos básicos sobre bases de datos relacionales. Cubrirá a detalle los principales aspectos de Cassandra y lo remitirá a otras fuentes para obtener información adicional.

Para probar la configuración del entorno utilizo las utilidades de Cassandra, y utilizo un script de Python para consumir los datos que están almacenados en Cassandra. No se preocupe si no está familiarizado con estas herramientas, ya que no son necesarias para la configuración y solo se utilizan para validar la configuración y para servir como recursos adicionales.

Conceptos básicos

En esta sección, explico algunos de los detalles heredados por Cassandra como base de datos distribuida. Si ya tiene algún conocimiento sobre esos conceptos o si ahora mismo no está interesado en la teoría, puede pasar a Construir el plan.

Teorema CAP

CAP significa «consistencia, disponibilidad y tolerancia a la partición». El teorema CAP, que fue formulado por primera vez por Eric Brewer en 2000, establece que como mucho, solo se pueden obtener dos de esas propiedades en cualquier sistema de datos compartidos. Así que debe elegir dos; no puede tenerlas todas. Para saber más acerca del teorema, vea a continuación «Temas relacionados», aunque le voy a dar una visión general.

Es importante que entienda el teorema CAP ya que está relacionado con Cassandra, porque es posible que le haga llegar a la conclusión de que Cassandra no es la mejor opción para su solución de bases de datos NoSQL. En cualquier caso, le ayudará a empezar a pensar en las restricciones de su solución en términos de consistencia y disponibilidad.

Según el teorema, para cualquier sistema distribuido se debería elegir las dos garantías más importantes para el sistema (vea la Imagen 1). En Cassandra es posible tener las tres garantías, pero no al mismo tiempo. Por lo tanto, cuando se quiere una base de datos altamente disponible y sin tiempo de inactividad, y no se quiere ser sorprendido por fallas ocasionales del hardware, Cassandra es la mejor opción para las soluciones que se enfocan en la disponibilidad y en la tolerancia a particiones.

Esto contrasta con las propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad) de un sistema de gestión de bases de datos relacionales (RDBMS) tradicional, como MySQL, DB2®, Oracle y Sybase. No quiero sugerir que en Cassandra no se tengan las operaciones atómicas ni que los datos en Cassandra no estén aislados ni sean duraderos. Simplemente quiero decir que esas no son las principales preocupaciones de Cassandra. La base de datos nació para ser distribuida de forma nativa y para escalar fácilmente a medida que crecen los datos y las transacciones de las aplicaciones.

Imagen 1. Garantías del teorema CAP y Cassandra

Gráfico con tres círculos: El Círculo P cubre parcialmente los círculos C y A, el círculo A cubre una parte del círculo C.

Base de datos distribuida

Por naturaleza, Cassandra es una base de datos distribuida. Eso significa que fue diseñada para ejecutarse en una red de nodos de computadoras, funcionando como un servidor que tiene diferentes partes que se ejecutan en diferentes máquinas sin ningún hardware o software específico para gestionar o coordinar. Toda la coordinación de los nodos y la distribución de los datos están dentro de su propia arquitectura.Esta es una de las razones por las que una red de Cassandra es más barata y más fácil de escalar de forma horizontal que otros sistemas de bases de datos relacionales comunes.

La topología típica de la red de Cassandra está compuesta por un clúster de nodos, también llamado anillo de Cassandra, que se ejecuta en diferentes direcciones de red que están ubicadas en servidores físicos diferentes.

Imagen 2. Clúster de nodos de Cassandra en diferentes hosts de la red

Un círculo conectando tres círculos menores numerados de uno a tres.

Esta función incrementa la disponibilidad de la red en caso de falla de un nodo. Cada nodo puede coordinar la solicitud de un cliente sin un nodo maestro, para que no haya un punto único de falla. También le permite establecer diferentes estrategias de configuración para que los datos sean conscientes de las diferentes ubicaciones de los nodos, lo que, por lo tanto, incrementa aún más la disponibilidad del sistema.

Imagen 3. Clúster de ocho nodos de Cassandra que recibe datos de escritura de la conexión del cliente en un espacio de claves configurado con un factor de replicación 3

Un círculo llamado coordinador que emite información del cliente a otros círculos conectados entre sí.

Todos los datos se distribuyen uniformemente a través del anillo de Cassandra (nodos) según un algoritmo hash, para crear el número de copias necesarias, también llamadas réplicas. El factor de replicación es un aspecto importante de la configuración del clúster. Se define por un espacio de claves o por la configuración del esquema.

Toda la información acerca de los datos del clúster, de la topología, de la disponibilidad de nodos, y del rendimiento es intercambiada entre los nodos a través del gossip protocol, un tipo de protocolo peer-to-peer. Esta información es importante para avisar a las condiciones del cliente acerca de qué nodo es el mejor para leer o escribir datos en un momento dado.

Los clientes de Cassandra se pueden comunicar con el servidor a través de dos protocolos: el protocolo binario CQL o a través de un protocolo RPC llamado thrift. El protocolo binario CQL es un protocolo más reciente y preferible a thrift. Cassandra Query Language (CQL) es un lenguaje similar al SQL, que utiliza Cassandra para crear comandos para manipular los datos y la estructura de su esquema (DDL y DML).

Estructura y modelado básico de datos

Un aspecto importante y a veces complicado de Cassandra es su enfoque para el modelado de datos. Primero, es necesario entender cómo se organizan los datos dentro de su arquitectura y, después, cómo modelar la estructura de datos de su aplicación para sacar el máximo provecho de su rendimiento.

En Cassandra, todos los datos están organizados en particiones con una clave primaria (clave de fila), que le proporciona acceso a todas las columnas o cómo establecer pares de clave/valor como se muestra a continuación.

Imagen 4. Partición de la estructura de datos de Cassandra

Partición de la estructura de datos representa en tres columnas subdivididas Cada columna contiene su llave y su valor.

La clave primaria de Cassandra puede estar formada por dos claves especiales: la clave de la partición y (opcionalmente) la clave de la agrupación. El propósito de la clave de la partición es repartir los datos de forma uniforme alrededor del clúster. El trabajo de la clave de agrupación (también llamada «columnas de agrupación») es agrupar y organizar datos de una partición para permitir la realización de consultas eficientes. Considere el siguiente ejemplo.

Cuando cree una tabla en Cassandra, utilice un comando CQL similar al siguiente:

CREATE TABLE movie_catalog (categoría text, año int, título text,
PRIMARY KEY (categoría));

La primera columna se considera implícita para la clave de la partición de la tabla movie_catalog. No hay clave de agrupación. Sin embargo, suponga que añade la columna año dentro de la clave primaria de esta manera:

CREATE TABLE movie_catalog (categoría text, año int, título text,
PRIMARY KEY (categoría,año))

Ahora categoría sigue siendo la clave de la partición, mientras que la columna año es la clave de la agrupación. Ambas columnas forman parte de la clave primaria.

Si piensa que esto es confuso, ¡no piense demasiado en ello! Lo importante que tiene que saber es que todas las tablas de Cassandra deben tener una clave primaria para ubicar el nodo del clúster en el que están los datos. Esa clave está compuesta por al menos la clave de la partición. Como se ha indicado antes, la clave de la agrupación, que se utiliza para ubicar los datos dentro del nodo (partición), también puede formar parte de la clave primaria.

Para modelar las tablas, es necesario elegir cuidadosamente la clave de la partición para permitir que Cassandra realice una buena distribución de los datos a través de los nodos. No es una buena idea tener todos los datos de la aplicación (filas) en solo una partición. De igual manera, es posible tener demasiadas particiones. Por lo tanto, es necesario que encuentre un buen equilibrio en el agrupamiento de sus datos para satisfacer los requisitos de su aplicación.

La técnica que se utiliza más a menudo para modelar en Cassandra se llama Query Based Modeling. Este enfoque requiere que usted piense en qué consultas enviará primero la interfaz de usuario de su aplicación. Después, usted modela sus tablas basándose en esas consultas. Este tema es un posible asunto para otro tutorial.

Construir el plan

Imagine que se le pide diseñar un nivel de una base de datos para una arquitectura de una aplicación crítica, que almacenará información de exámenes de pacientes para un hospital más grande. Este sistema requerirá de un tiempo de actividad 24×7 y servirá a muchos usuarios. Su primera preocupación es que la base de datos debe tener alta disponibilidad y ser tolerante a fallas, para que no afecte de forma negativa a sus usuarios ni a las operaciones del hospital. En la siguiente sección describiré una solución posible.

Visión general de la solución

Para el entorno de pruebas (UAT) usted decide configurar inicialmente un clúster de pruebas básico formado por tres nodos. Después, en producción, este se implementará en tres máquinas de servidores diferentes en el centro de datos de producción del hospital.

Imagen 5. Aplicación del hospital accediendo a la capa de servidores de la base de datos que ejecuta un clúster de tres nodos de Cassandra

Un círculo conectando tres nodos. La aplicación Hospital conecta a uno de esos tres nodos del cluster.

La idea de tener un clúster de tres nodos en vez de solo un nodo incrementa la disponibilidad de su sistema de bases de datos. En el caso de falla en un nodo, todavía tendrá funcionando dos nodos para responder a todas las solicitudes de la aplicación. También, es posible balancear la carga de las solicitudes en caso de mucha carga, lo que proporciona a la aplicación una baja latencia durante las lecturas y escrituras de datos.

Los controladores del cliente de Cassandra pueden descubrir automáticamente todos los nodos disponibles y pueden elegir el mejor nodo coordinador que será responsable de escribir todas las copias o réplicas de sus datos. Todo esto es posible gracias a la implementación del «gossip protocol» de Cassandra, que intercambia información de la salud del nodo entre los otros nodos.

Factor de replicación

El siguiente paso consiste en decir qué factor de replicación y nivel de consistencia usted utilizará para la aplicación. Después de eso, usted puede empezar a instalar y a configurar el entorno del tiempo de ejecución de la base de datos y a crear esquemas y tablas para su aplicación.

En la definición del esquema, usted establece un factor de replicación 3. Esto significa que usted configura el esquema de la base de datos (espacio de claves) para crear tres copias de los datos en sus tres nodos. Cada vez que la aplicación se conecta con un nodo e introduce datos en una tabla, éstos se replican automáticamente en los otros dos nodos. Esto le proporcionará más fiabilidad para almacenar sus datos de forma segura.

CREATE KEYSPACE patient WITH replication = {'class': 'SimpleStrategy',
    'replication_factor' : 3};

Nivel de consistencia

También tiene que definir el nivel de consistencia que utilizará la aplicación cuando un cliente se conecta durante la sesión de lecturas y escrituras. Esto le ayudará a determinar cuál es la fuerza que tiene que tener para que las consultas sean consistentes con el estado de los datos.Por ejemplo, usted podría decidir tener un nivel de consistencia QUORUM para escribir y leer datos, lo que significa que usted forzará a que Cassandra lea y escriba los datos para la mayoría de los nodos (dos nodos) antes de devolver una solicitud.

El nivel de consistencia se define para cada sesión del cliente y se puede cambiar en cualquier momento. Como ejemplo, en la consola del cliente cqlsh que se muestra a continuación, en cualquier momento puede probar el nivel de consistencia para las consultas de la misma forma que le permiten hacerlo la mayoría de los controladores de Cassandra.

cqlsh:patient> consistency QUORUM ;
Nivel de consistencia establecido a QUORUM.
cqlsh:patient>

Aquí hay una contrapartida entre la consistencia y el rendimiento de la latencia. Cuanto mayor sea la consistencia, mayor será el tiempo que tarden las operaciones de lectura/escritura. En nuestra configuración básica del clúster, esto no impone ninguna diferencia de tiempo significativa, pero es un concepto importante para aplicar en clústeres grandes de Cassandra. Ahí, es posible que se esté tratando con grandes cantidades de datos y que siga necesitando un tiempo de respuesta rápido.

Qué necesitará

Las bases de datos Cassandra están basadas en las plataformas Java™, para que se puedan ejecutar en cualquiera de los muchos sistemas operativos que soportan la tecnología Java y que tengan poco espacio en el disco y poca memoria para empezar a trabajar. Para la aplicación que se describe en este tutorial, recomiendo lo siguiente:

  • mínimo de 2 GB de RAM disponibles — Para instalar y ejecutar una instancia de la base de datos de Cassandra, recomiendo que tenga una máquina con al menos 4 GB de RAM, y al menos 2 GB disponibles. Una máquina de 8 GB de RAM sería incluso mejor. Si decide ejecutar las instancias de Cassandra en Docker, cada contenedor debe tener disponible al menos 1 GB of RAM para ejecutar cada nodo de Cassandra.
  • Java 8 — Desde el lanzamiento de Apache Cassandra V3, es necesario tener instalado Java Standard Edition 8 en la máquina porque Cassandra se ejecuta en la Máquina Virtual de Java (JVM). Las versiones más antiguas de Cassandra (como la V2.2) se pueden ejecutar con Java 7. Es posible verificar la versión de Java escribiendo

    java -version

    en la línea de comandos de su SO.

  • Python 2.7 — La instalación de Python es necesaria si se quiere utilizar la herramienta de gestión de nodos de Cassandra nodetool y la utilidad de la consola cqlsh._ Esas herramientas son útiles para obtener la información acerca de Cassandra, de su gestión y de sus bases de datos. Es posible verificar la versión de Python que está instalada escribiendo

    python --version.

  • Docker CE — Esto es algo opcional si usted quiere configurar todos los nodos de Cassandra en contenedores que se ejecuten en la misma máquina. Recomiendo su uso para crear un entorno de clústeres de pruebas. No se preocupe si no conoce nada sobre los contenedores Docker. Abajo, lo guio a través de los comandos necesarios para configurar su clúster de Cassandra. Descargue la versión más reciente de Docker CE para su plataforma desde el sitio web de Docker.

Instalación

Es posible instalar manualmente Cassandra desde el sitio web de Cassandra o automáticamente a través de contenedores de Docker. Si elige el uso de contenedores de Docker para crear su clúster Cassandra, se puede saltar la sección «Descargar el paquete».

Descargar el paquete

Si está utilizando Linux, es posible que encuentre un paquete específico para su instalación, pero la mayoría de las veces usted descargará un archivo tar.gz comprimido que contiene la última versión disponible (V3.11 en el momento en el que se escribe esto).

  1. Después de la descarga, descomprima el paquete con la utilidad TAR (o con una herramienta similar):

    $ tar -xvf apache-cassandra-3.11.0-bin.tar.gz
    
  2. Extraiga el contenido del archivo a cualquier ubicación deseada. Después de la extracción, cree un directorio apache-cassandra-3.11.0 que contenga todos los binarios, archivos de configuración, bibliotecas y herramientas de utilidades de Casandra, de la siguiente manera:

    $ ls
    CHANGES.txt  LICENSE.txt  NEWS.txt  NOTICE.txt  bin  conf  doc  interface  javadoc  lib  pylib  tools
    

Configuración

Esta sección cubre la configuración manual del primer nodo de Cassandra. Si usted está utilizando Docker, es posible que todavía quiera leer esta sección para entender los principales parámetros de la configuración de Cassandra. En caso contrario, pase a «Establezca un clúster de pruebas con Docker

Toda la configuración principal de Cassandra se coloca en el archivo cassandra.yaml que está ubicado en el directorio «conf».

Parámetros de la configuración

Edite el archivo cassandra.yaml para cambiar los siguientes parámetros básicos:

  • cluster_name — Esto identifica el nombre de su clúster de tres nodos de Cassandra. Es importante que todos los nodos de configuración tengan el mismo nombre.

    cluster_name: 'Clúster de Pruebas del Hospital'

  • semillas — La dirección de IP de la red o la lista del nombre del host de los principales nodos del clúster. Para probar su clúster, usted tendrá que establecer la dirección IP del primer nodo.

    semillas: "127.0.0.1"

  • listen_address — El nombre del host del nodo que utilizarán los clientes y los otros nodos para conectarse a este nodo. En vez de utilizar el localhost (como se muestra aquí), establezca el nombre real del host que utiliza la máquina en esta red.

    listen_address: localhost

  • native_transport_port — El número del puerto TCP del nodo que utilizarán los clientes para conectarse a este nodo. Asegúrese de que utiliza un puerto que no esté bloqueado por los firewalls. El puerto predeterminado es 9042.

    native_transport_port: 9042

Para establecer una configuración básica de la autenticación y de la autorización de esta instancia, es necesario cambiar estos parámetros adicionales y opcionales:

  • authenticator — Permite la autenticación del usuario. Es necesario cambiar este parámetro para obligar a que los usuarios informen del nombre de usuario y de la contraseña cuando se conecten al clúster.

    authenticator: PasswordAuthenticator

  • authorizer — Permite la autorización del usuario y limita sus permisos. Si usted cambia este parámetro, tendrá que incrementar el factor de replicación del espacio de claves system_auth para crear otras copias de los datos de la autorización en otros nodos cuando un nodo no esté disponible.

    authorizer: CassandraRoleManager

Inicie manualmente el primer nodo

Ahora que está realizada toda la configuración, es posible ejecutar el script de Cassandra que está ubicado dentro del directorio bin de la siguiente manera. La opción -f dará como resultado en el primer plano todos los registros de arranque. Por primera vez, esto es útil para verificar los errores que ocurren durante el inicio de Cassandra.

$ bin/cassandra -f

Si se ve la siguiente información del registro después de que pasen algunos segundos desde la inicialización, significa que el nodo de Cassandra está activo, funcionando y listo para recibir las conexiones del cliente.

INFO  [main] 2017-08-20 18:04:58,329 Server.java:156 - Starting listening for CQL
    clients on localhost/127.0.0.1:9042 (unencrypted)...

Para volver a verificar el estado del nodo, es posible utilizar la utilidad nodetool que está ubicada en el directorio «bin». Esto puede proporcionar la información acerca del clúster y de los nodos de Cassandra. Para verificar el estado del clúster solo tiene que emitir el siguiente comando:

$ nodetool status

El siguiente comando imprime información acerca del clúster, lo que incluye el nombre del centro de datos en el que se está ejecutando (en este caso, la configuración predeterminada) y el estado de cada nodo que pertenece al clúster:

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  127.0.0.1  103.67 KiB  256          100.0%            6aae6c1f-cf06-4874-9507-a43025c312d1  rack1

Las letras UN que están antes de la dirección IP significan que el nodo está Activo (U) y Normal (N). Después del primer inicio se crearán los directorios de datos y del registro para almacenar respectivamente todos los datos y registros de los espacios de claves/tablas.

Si no se quieren utilizar contenedores de Docker, se pueden repetir los pasos anteriores para crear otros nuevos. Acuérdese de utilizar la dirección IP del primer nodo como la configuración de las semillas para los otros nodos. Si no quiere utilizar los contenedores de Docker, siga los siguientes pasos.

Establezca un clúster de pruebas con Docker

En vez de instalar y configurar Cassandra en las diferentes máquinas físicas del servidor, se pueden utilizar los contenedores de Docker para crear un clúster de tres nodos que se ejecutan en la misma máquina del servidor de pruebas. Asegúrese de que tiene suficiente RAM para ejecutar tres instancias de Cassandra. En caso contrario, podría intentar reducir el número de nodos a dos.

Si tiene instalado Docker en su máquina de pruebas, puede utilizar las imágenes oficiales que están disponibles en la plataforma de Docker. Para descargar, instalar y ejecutar Cassandra 3.11, ingrese el siguiente comando de Docker:

docker run --name node1 -d cassandra:3.11

Este comando busca en Internet una imagen que se llama cassandra que tenga la etiqueta de versión 3.11 en el registro de la plataforma de Docker. Después descarga la imagen y crea e inicia un contenedor llamado node1. Este contenedor ya ha sido configurado en la configuración predeterminada de Cassandra, de forma similar a lo descrito anteriormente.

Es posible verificar si el contenedor está activo y funcionando utilizando el comando docker ps:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                                         NAMES
803135731d1a        cassandra:3.11      "/docker-entrypoint.s"   About a minute ago   Up About a minute   7000-7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp   node1

Ahora, se pueden iniciar otras instancias, informando a cada nodo nuevo de la ubicación del primer nodo. Hágalo cambiando la dirección IP del nodo semilla del nodo nuevo utilizando CASSANDRA_SEEDS. Esto cambia automáticamente la configuración de las semillas que están dentro del archivo cassandra.yaml del nodo nuevo que se ha creado dentro del contenedor. Para crear e iniciar el segundo contenedor de nodos (node2), introduzca lo siguiente:

$ docker run --name node2 -d -e CASSANDRA_SEEDS="$(docker inspect --format='{{
    .NetworkSettings.IPAddress }}' node1)" cassandra:3.11

Para determinar cuántos nodos están dentro de su clúster, ejecute la utilidad nodetool dentro del contenedor node1:

$ docker exec -it node1 nodetool status

Este comando muestra el estado de cada nodo del clúster que se ha configurado hasta ahora, así que el resultado esperado será similar al siguiente:

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  172.17.0.3  103.25 KiB  256          100.0%            f1bbd4d1-8930-45a3-ba43-4a2416617c7f  rack1
UN  172.17.0.2  108.64 KiB  256          100.0%            bec1b022-a397-4401-bd42-676c60397fe1  rack

Si node2 sea iniciado correctamente, se podrá crear un tercer nodo (node3) de la misma forma. Cuando los tres nodos se estén ejecutando, vaya a «Pruebas«, que está a continuación. Si por alguna razón node2 no se ha iniciado, continúe con el siguiente procedimiento de resolución de problemas.

Resolución de problemas del clúster en Docker

Si uno de sus nodos no se inicia correctamente, verifique en los registros de Cassandra:

$ docker logs node2

Si ve un error similar a «Unable to gossip with any seeds,» tendrá que añadir un parámetro siguiendo las instrucciones siguientes. En caso contrario, vaya a «Pruebas

  1. Para añadir el parámetro necesario, primero capture en la dirección IP de node1 utilizando el comando inspect de Docker:

    $ docker inspect --format='{{ .NetworkSettings.IPAddress }}' node1
    
  2. Vamos a asumir que la dirección IP devuelta es 172.17.0.2. Ejecute los siguientes comandos para parar y eliminar el contenedor node1, y después recréelo con la dirección de trasmisión de «gossip» y con los parámetros del puerto:

    $ docker stop node1
    $ docker rm node1
    $ docker run --name node1 -d -e CASSANDRA_BROADCAST_ADDRESS=172.17.0.2 -p 7000:7000 cassandra:3.11
    
  3. Después, cree node2 con la dirección IP de transmisión 172.17.0.3, reutilizando la dirección de node1 como el nodo semilla:

    $ docker run --name node2 -d -e CASSANDRA_BROADCAST_ADDRESS=172.17.0.3 -p 7001:7000 -e CASSANDRA_SEEDS=172.17.0.2 cassandra:3.11Esta configuración permitirá que los dos nodos trasmitan entre ellos la información del «gossip protocol» que está configurado en el puerto 7000 a través de los puertos 7000 y 7001 del contenedor.

  4. Después, utilice docker ps para verificar si los dos procesos de Docker se están ejecutando. Después, vuelva a utilizar la utilidad nodetool para confirmar el estado del clúster:

    $ docker exec -it node1 nodetool status
    Datacenter: datacenter1
    =======================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
    UN  172.17.0.3  108.29 KiB  256          100.0%            fd135375-711a-471a-b4e5-409199bbaaa5  rack1
    UN  172.17.0.2  108.66 KiB  256          100.0%
        5db97fc3-70e9-48e5-b63b-0be67e35daea  rack1
    

Variables de entorno del contenedor

Para cambiar la configuración del nombre del clúster de Cassandra dentro del contenedor de Docker se pueden utilizar las variables de entornos del contenedor.

Cuando ejecute una imagen Cassandra de Docker, podrá establecer las configuraciones específicas de Cassandra pasando una o más variables de entorno en la línea de comandos ejecutar Docker con -e. La imagen utilizará esto para cambiar los parámetros de Cassandra que están dentro del contenedor. Para obtener más información, vea la documentación de la imagen de Cassandra en la plataforma de Docker.

Pruebas

El primer paso para probar la configuración de su clúster es conectarlo con la utilidad de la consola de CQL (cqlsh). Este es un script de la línea de comandos de Python, que crea un cliente que se puede conectar con cualquier host del clúster. Todo lo que tiene que hacer es emitir el comando cqlsh. De forma predeterminada, el script intentará conectarse a una instancia que se ejecute en localhost. Es posible cambiar el host pasando el parámetro host. Vea la ayuda de cqlsh para obtener más detalles (cqlsh --help).

herramienta de la consola de CQL

Si está utilizando Docker, puede ejecutar cqlsh desde dentro del contenedor:

$ docker exec -it node1 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh>

Esta consola le permite enviar comandos CQL similares a los SQL para crear y definir su espacio de claves (schema), sus tablas y sus datos manipulados. Es posible encontrar más información en la Documentación de Cassandra.

Cree el espacio de claves para las pruebas

Vamos a crear su primer espacio de claves para almacenar toda la información de los exámenes de los pacientes:

  1. Envíe el comando CQL CREATE KEYSPACE para crear el esquema de los pacientes.

    cqlsh> CREATE KEYSPACE patient WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
    
  2. Ahora puede acceder al espacio de claves creado y puede crear la primera tabla para almacenar los datos de los exámenes. El comando CQL que se utiliza para crear una tabla es similar al comando SQL DDL:

    CREATE TABLE patient.exam (
    patient_id int,
    id int,
    date timeuuid,
    details text,
    PRIMARY KEY (patient_id, id));
    

    Los comandos anteriores crean una tabla que tiene una clave primaria que está formada por el ID del paciente y por el propio ID del examen.

Insertar los datos

  1. Ahora que ya tiene creada la estructura de su espacio de claves, inserte algunos datos de muestra para tres pacientes:

    INSERT INTO exam (patient_id,id,date,details) values (1,1,now(),'primer examen del paciente 1');
    INSERT INTO exam (patient_id,id,date,details) values (1,2,now(),'segundo examen del paciente 1');
    INSERT INTO exam (patient_id,id,date,details) values (2,1,now(),'primer examen del paciente 2');
    INSERT INTO exam (patient_id,id,date,details) values (3,1,now(),'primer examen del paciente
        3');
    
  2. Después, ejecute una consulta de pruebas para capturar todos los exámenes del paciente 1:

    cqlsh:patient> select * from exam where patient_id=1;
    
Imagen 6. Ejecutar una consulta para el paciente 1

Resultado de consulta con id del paciente y detalles de exámenes

Probar el clúster

Ahora es el momento de probar la disponibilidad, la consistencia y la tolerancia a particiones del clúster. Si su configuración del factor de replicación es tres para el espacio de claves del paciente, en cada uno de los tres nodos usted tendrá una copia de los datos que se hayan escrito en la tabla del examen.

Prueba de replicación de nodos

Es posible introducir los datos en node1 y consultarlos en node3, porque los datos que están escritos en node1 se replicarán automáticamente en node2 y node3, lo que confirma las tres réplicas de los datos. Para probar la inserción de un paciente en node1 para determinar si su información está disponible en node3, ingrese lo siguiente:

$ docker exec -it node1 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> INSERT INTO patient.exam (patient_id,id,date,details) values (9,1,now(),'first exam patient 9');
cqlsh> quit;
$ docker exec -it node3 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> select * from patient.exam where patient_id=9;
 patient_id | id | date                                 | details
------------+----+--------------------------------------+----------------------
          9 |  1 | 9cf570b0-8e9d-11e7-a592-6d2c86545d91 | first exam patient 9
(1 rows)

Prueba de falla de nodos

Ahora pare node2 y node3, después introduzca los datos del paciente en node1. Vuelva a iniciar node2 y node3 para ver que los datos que se han introducido en node1 se hayan replicado en node2 y node3, que no están disponibles.

$ docker stop node2
$ docker stop node3
$ docker exec -it node1 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> INSERT INTO patient.exam (patient_id,id,date,details) values (10,1,now(),'first exam patient 10');
cqlsh> quit;
$ docker start node2
$ docker start node3
$ docker exec -it node3 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> select * from patient.exam where patient_id=10;
 patient_id | id | date                                 | details
------------+----+--------------------------------------+-----------------------
         10 |  1 | 76439070-8f04-11e7-a592-6d2c86545d91 | first exam patient 10
(1 rows)

Prueba de consistencia de nodos

Si quiere una consistencia robusta en la lectura, debe establecer el nivel de consistencia a QUORUM, para que cualquier consulta verifique los datos, al menos, en dos nodos que estén disponibles.

$ docker stop node1
node1
$ docker stop node2
node2
$ docker exec -it node3 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> select * from patient.exam where patient_id=10;
 patient_id | id | date                                 | details
------------+----+--------------------------------------+-----------------------
         10 |  1 | 76439070-8f04-11e7-a592-6d2c86545d91 | first exam patient 10
(1 rows)
cqlsh> consistency quorum
Consistency level set to QUORUM.
cqlsh> select * from patient.exam where patient_id=10;
NoHostAvailable:

En este caso, la mayoría de sus nodos (dos) deberán estar activos y funcionando o la consulta dará error. Esto es una compensación. Si quiere más disponibilidad y mayor consistencia, en su clúster debe tener más nodos para que continúe funcionando en caso de que algunos fallen. Si establece el nivel de consistencia a UNO, su consulta tendrá éxito ya que hay una copia local disponible en node3, donde usted está conectado.

cqlsh> consistency one
Consistency level set to ONE.
cqlsh> select * from patient.exam where patient_id=10;
 patient_id | id | date                                 | details
------------+----+--------------------------------------+-----------------------
         10 |  1 | 76439070-8f04-11e7-a592-6d2c86545d91 | first exam patient 10
(1 rows)
cqlsh> quit;

Si vuelve a iniciar node1, usted tendrá la mayoría de los nodos, por lo que se pueden satisfacer la consistencia de QUORUM, y la consulta ya no dará error.

$ docker start node1
node1
$ docker exec -it node3 cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.0 | CQL spec 3.4.4 | Native protocol v4]
Utilice HELP para obtener la ayuda.
cqlsh> consistency quorum
Consistency level set to QUORUM.
cqlsh> select * from patient.exam where patient_id=10;
 patient_id | id | date                                 | details
------------+----+--------------------------------------+-----------------------
         10 |  1 | 76439070-8f04-11e7-a592-6d2c86545d91 | first exam patient 10
(1 rows)

Si verifica el estado de sus nudos, podrá ver que hay dos nodos activos (UN) y uno inactivo (DN).

$ docker exec -it node3 nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
DN  172.17.0.3  306.19 KiB  256          100.0%            fd135375-711a-471a-b4e5-409199bbaaa5  rack1
UN  172.17.0.2  365.72 KiB  256          100.0%            5db97fc3-70e9-48e5-b63b-0be67e35daea  rack1
UN  172.17.0.4  285.42 KiB  256          100.0%            4deb44f8-9253-4bff-b74b-239085e3a912  rack1

Se pueden explorar otros escenarios de pruebas, como las pruebas de latencia o la prueba del balanceado de carga, con más nodos, y confirmar las características del clúster distribuido de Cassandra que se han descrito anteriormente.

Conclusión

En este tutorial, mi objetivo ha sido guiarle a través de la instalación y la configuración básica de un clúster de Cassandra y explicar sus características más importantes. También, he pretendido brindarle algunos ejercicios prácticos para ayudarle a familiarizarse con este tipo de bases de datos NoSQL. Es posible que usted ahora esté listo para comenzar su proyecto y para utilizar Cassandra si sus requisitos coinciden por las características de Cassandra.

Hay otros detalles que todavía no he cubierto acerca de las técnicas de modelación para los diferentes conjuntos de datos y tareas de administracióny sobre los ajustes finos para mejorar el rendimiento. También se han quedado fuera del ámbito de este tutorial muchos otros aspectos del manejo de los controladores del cliente relacionados con el desarrollo. Es posible que esto se cubra en próximos tutoriales. Mientras tanto, para saber más acerca de Cassandra, hay dos fuentes de información que recomiendo: el sitio web oficial de Apache Cassandra y el sitio web de la documentación de DataStax. Vea a continuación los «Temas relacionados».

Aviso

El contenido aquí presentado fue traducido de la página IBM Developer US. Puede revisar el contenido original en este link