Configuring Apache Cassandra Data Consistency

Configuring Apache Cassandra Data Consistency

  • Orquestación
6 min de lectura Actualizado Jan 7, 2019

Puntos clave: Configuración de Apache Cassandra se centra en gestionar la consistencia de los datos mediante la configuración de replicación, equilibrando el tiempo de respuesta con la precisión, algo crucial para aplicaciones de alta integridad.

  • Las configuraciones de consistencia eventuales mejoran las operaciones de escritura y lectura.
  • Las estrategias de replicación incluyen SimpleStrategy y NetworkTopologyStrategy para una gestión eficaz de datos.

Veamos cómo Apache Cassandra gestiona la consistencia de datos.

Si te escribe datos en n - 1 nodos de un clúster y luego una aplicación los lee desde el nodo n, Cassandra podría informar que los datos no están como replicación están no instantáneo. Eso podría ser un gran problema o no ser un problema en absoluto. Depende de la aplicación. Si es una aplicación que genera ingresos, entonces es un problema.

Así, Cassandra permite a los administradores configurar la replicación y consistencia de los datos a nivel de aplicación. El compromiso están el tiempo de respuesta frente a la precisión de los datos.

Esta capacidad de configura esto a nivel de aplicación están llama consistencia eventual. Como su nombre indica, te puede decirle a Cassandra que espere después de una operación para escribir todos los datos en todos los centros de datos y racks o que pase a la siguiente operación después de que se están hecho la primera escritura con el entendimiento de que Cassandra acabará alcanzándose.

Esta idea es la misma que determinar qué tipo de almacenamiento alquilar o comprar al diseñar una aplicación. Las aplicaciones consideradas menos críticas son pueden utilizar almacenamiento de menor coste y aún menos discos, y Haz menos réplicas o ninguna réplica que las críticas.

La consistencia puede establecerse en estos niveles:

  • Centro de datos
  • Clúster
  • Tipo de operación de E/S (es decir, lectura o escritura)

Consistencia de escritura y lectura

La coherencia de escritura tiene muchas opciones diferentes. Aquí son un par.

TODOS

Los datos deben escribirse en el memtable y el log de commit en cada nodo. Los pasos que sigue Cassandra al escribir datos están:

  • escribe datos en el memtable (memoria)
  • Escribe en el registro de commitos
  • Escritura en disco
  • compactar los datos
QUÓRUM Un quórum a nivel de centro de datos. Un quórum está ((número de réplicas)) / 2 + 1 redondeado hacia arriba. Sumar 1 convierte este número en el siguiente entero cuando esa división da lugar a una fracción. Y no te puedes escribir en una fracción de un centro de datos, así que añade una más
UNO, DOS, TRES 1, 2 o 3 se replican, es decir, a nivel de nodo.

Consistencia de lectura

Dependiendo del conjunto de consistencia de escritura, algunos nodos tendrán copias de datos más antiguas que otros. Así que tiene sentido que te pueda configura la consistencia de lectura también.

TODOS Espera hasta que todas las réplicas respondan.
... etcétera.

Estrategia de replicación

La replicación está un factor en la consistencia de los datos. Una réplica significa una copia de los datos.

para determinar si una escritura ha sido exitosa y si la replicación está funcionando, Cassandra tiene un objeto llamado snitch, que determina a qué nodos de centro de datos y rack pertenecen y la topología de la red.

Son dos estaciones de replicación:

  1. SimpleStrategy: un centro de datos y un rack.
  2. NetworkTopologyStrategy—múltiples racks y múltiples centros de datos. Esto están preferido incluso cuando solo están un centro de datos.

Aquí lo ilustramos con un ejemplo.

Primero sigue estas instrucciones para montar un clúster.

Utiliza nodetool para determinar el nombre del centro de datos tal y como lo reporta el chivato. Aquí el nombre es datacenter1. Esto muestra que son dos nodos en este clúster. Por supuesto, te ejecutarías esto en cada nodo para Ve a qué centro de datos pertenece cada uno.

    nodetool status

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns    Host ID                               Rack
UN  172.31.46.15  532.22 MiB  256          ?       58999e76-cf3e-4791-8072-9257d334d945  rack1
UN  172.31.47.43  532.59 MiB  256          ?       472fd4f0-9bb3-48a3-a933-9c9b07f7a9f6  rack1

Crea un espacio de claves con NetworkTopologyStrategy con 1 réplica para el centro de datos1. Eso significa escribir los datos en dos racks, ya que solo está un centro de datos.

    CREATE KEYSPACE Customers
       WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 1};

Ahora Crea una tabla:

    CREATE TABLE  Customers.Customers (      
Name text PRIMARY KEY,  
credit int 
);

Pon algunos datos:

    insert into Customers.Customers (name, credit) values ('Hardware Store', 1000);

Activa el trazado.

    cqlsh> TRACING on;
Now Tracing is enabled

Y escribe otro disco:

    insert into Customers.Customers (name, credit) values ('Book Store', 1000);

Cassandra responde con información sobre la latencia. No muestra operaciones a nivel de rack.

    Tracing session: bf8e0a90-0c43-11e9-9628-9d6a90b241c5

Parsing insert into Customers.Customers (name, credit) values ('Book Store', 1000); 

activity| timestamp | source | source_elapsed | client

[Native-Transport-Requests-1] | 2018-12-30 15:01:12.761000 | 172.31.46.15 |  203 | 127.0.0.1

Preparing statement [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 359 | 127.0.0.1

Determining replicas for mutation [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 |            662 | 127.0.0.1

Appending to commitlog [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 | 753 | 127.0.0.1

Adding to customers memtable [Native-Transport-Requests-1] | 2018-12-30 15:01:12.762000 | 172.31.46.15 |            827 | 127.0.0.1

Request complete | 2018-12-30 15:01:12.762121 | 172.31.46.15 | 1121 | 127.0.0.1

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.

Más de Orquestación

¿Te interesa saber más de BMC?

El Brief están nuestro correo mensual sobre el mainframe y la orquestación empresarial: investigación, historias de clientes, noticias de productos, eventos.

Al registrarse para esta oferta te son confirmar que te leído y aceptado la Política de Privacidad de BMC.

Tú te has suscrito a The Brief

El Brief abarca la orquestación de mainframe y empresa—BMC AMI y Control-M—y la investigación de analistas, despliegues de clientes y eventos en ambas áreas.