Arquitectura de Apache Cassandra

Avinash Lakshman y Prashant Malik inicialmente desarrollaron Cassandra en Facebook para potenciar la función de búsqueda en la bandeja de entrada de Facebook. Facebook lanzó Cassandra como un proyecto de código abierto en el código de Google en julio de 2008. Se convirtió en un proyecto de incubadora de Apache en marzo de 2009. Se convirtió en uno de los proyectos de nivel superior el 17 de febrero de 2010. Impulsado por la revolución de Internet, los dispositivos móviles y el correo electrónico. comercio, las aplicaciones modernas han superado las bases de datos relacionales. Por necesidad, ha surgido una nueva generación de bases de datos para abordar los desafíos de gestión de datos distribuidos globalmente a gran escala. 

Cassandra impulsa los servicios en línea y el backend móvil para algunas de las marcas más reconocidas del mundo, incluidas Apple, Netflix y Facebook. 

Arquitectura de Apache Cassandra : 
En esta sección describiremos el siguiente componente de Apache Cassandra. 

Terminología básica: 

Node
Data center
Cluster

Operaciones: 

Read Operation
Write Operation

Motor de almacenamiento: 

CommitLog
Memtables
SSTables
Data Replication Strategies

vamos a discutir uno por uno. 

Terminología básica: 

1. Node: 
El Node es el componente básico de Apache Cassandra. Es el lugar donde realmente se almacenan los datos. Por ejemplo: como se muestra en el diagrama, el Node que tiene la dirección IP 10.0.0.7 contiene datos (espacio de claves que contiene una o más tablas). 

Figura – Node 

2. Centro de 
datos: el centro de datos es una colección de Nodes. 
Por ejemplo: 

DC – N1 + N2 + N3 …. 
DC: Data Center
N1: Node 1
N2: Node 2
N3: Node 3 

3. Cluster: 
Es la colección de muchos centros de datos. 
Por ejemplo: 

C = DC1 + DC2 + DC3….
C: Cluster
DC1: Data Center 1
DC2: Data Center 2
DC3: Data Center 3 

Figura: Node, centro de datos, clúster 

Operaciones:  

1. Operación de lectura: 
en la operación de lectura hay tres tipos de requests de lectura que un coordinador puede enviar a una réplica. El Node que acepta las requests de escritura se llama coordinador para esa operación en particular. 

  • Paso 1: Solicitud directa: 
    en esta operación, el Node coordinador envía la solicitud de lectura a una de las réplicas. 
  • Paso 2: Solicitud de resumen: 
    en esta operación, el coordinador contactará con las réplicas especificadas por el nivel de consistencia. Por ejemplo: CONSISTENCIA DOS; Simplemente significa que cualquier dos Nodes en el centro de datos reconocerán. 
  • Paso 3: Solicitud de reparación de lectura: 
    si hay algún caso en el que los datos no son coherentes en todo el Node, se inicia una solicitud de reparación de lectura en segundo plano que garantiza que los datos más recientes estén disponibles en todos los Nodes. 

2. Operación de escritura: 

  • Paso 1: 
    en la operación de escritura, tan pronto como recibimos la solicitud, primero se descarga en el registro de confirmación para asegurarse de que los datos se guarden. 
  • Paso 2: 
    Inserción de datos en la tabla que también está escrita en MemTable que contiene los datos hasta que se llena. 
  • Paso 3: 
    si MemTable alcanza su umbral, los datos se descargan en la tabla SS. 

Figura: operación de escritura en Cassandra 

Motor de almacenamiento: 

  1. Registro de confirmación: 
    el registro de confirmación es el primer punto de entrada al escribir en el disco o en la tabla de memoria. El propósito del registro de confirmación en Apache Cassandra es solucionar los problemas de sincronización del servidor si un Node de datos está inactivo. 
  2. Mem-table: 
    después de que los datos se escriban en el registro de confirmación, después de que esos datos se escriban en Mem-table. Los datos se escriben en la tabla Mem temporalmente. 
  3. SSTable: 
    una vez que Mem-table alcance un cierto umbral, los datos se descargarán en el archivo de disco SSTable. 

Estrategia de replicación de datos: 
básicamente se utiliza para la copia de seguridad para garantizar que no haya un punto único de falla. En esta estrategia, Cassandra utiliza la replicación para lograr una alta disponibilidad y durabilidad. Cada elemento de datos se replica en N hosts, donde N es el factor de replicación configurado por instancia”. 

Hay dos tipos de estrategia de replicación: estrategia simple y estrategia de topología de red. Estos se explican a continuación a continuación. 

1. Estrategia Simple: 
En esta Estrategia permite definir un RF (factor_replicación) entero único. Determina el número de Nodes que deben contener una copia de cada fila. Por ejemplo, si replication_factor es 2, entonces dos Nodes diferentes deberían almacenar una copia de cada fila. Trata a todos los Nodes de manera idéntica, ignorando cualquier centro de datos o rack configurado. 

Consulta CQL (lenguaje de consulta de Cassandra) para estrategia simple. Un espacio de claves se crea utilizando una instrucción CREATE KEYSPACE: 

create_keyspace_statement ::=  
      CREATE KEYSPACE [ IF NOT EXISTS ] keyspace_name 
       WITH options 

Por ejemplo: 

CREATE KEYSPACE User_data
    WITH replication = {'class': 'SimpleStrategy', 
                        'replication_factor' : 2}; 

Para verificar el esquema de espacio de claves, se utilizó la siguiente consulta CQl. 

DESCRIBE KEYSPACE User_data

Representación pictórica de estrategia simple. 

Figura – Estrategia simple 

2. Estrategia de topología de red: 
en esta estrategia permite especificar un factor de replicación para cada centro de datos del clúster. Incluso si su clúster solo usa un único centro de datos. Se debe preferir esta estrategia a SimpleStrategy para que sea más fácil agregar nuevos centros de datos físicos o virtuales al clúster más adelante. 

Consulta CQL (lenguaje de consulta de Cassandra) para la estrategia de topología de red. 

CREATE KEYSPACE User_data
    WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : 2, 'DC2' : 3}
    AND durable_writes = false; 

Para verificar el esquema de espacio de claves, se utilizó la siguiente consulta CQl. 

DESCRIBE KEYSPACE User_data

Representación pictórica de la estrategia de topología de red. 

Figura: estrategia de topología de red 

Estructura de la tabla en Cassandra: 

USE User_data;

CREATE TABLE User_table (
     User_id int,
     User_name text,
     User_add text,
     User_phone text,
     PRIMARY KEY (User_id)
);

Insert into User_data (User_id, User_name, User_add, User_phone ) 
                    VALUES(1000, ‘Ashish’, ‘Noida’, ‘8077178539’);
Insert into User_data (User_id, User_name, User_add, User_phone ) 
                        VALUES(1001, ‘Ashish Gupta’, ‘Bangalore’);
Insert into User_data (User_id, User_name, User_add, User_phone ) 
                                              VALUES(1002, ‘Abi’); 

Producción: 

Figura – Estructura de la tabla 

Aplicación de Apache Cassandra: 
algunos de los casos de uso de aplicaciones en los que Cassandra sobresale incluyen: 

  • Cargas de trabajo de big data en tiempo real 
  • Gestión de datos de series temporales 
  • Análisis y consumo de datos de dispositivos de alta velocidad 
  • Gestión de transmisión de medios (p. ej., música, películas) 
  • Entrada y análisis de redes sociales (es decir, datos no estructurados) 
  • Venta minorista web en línea (por ejemplo, carritos de compras, transacciones de usuario) 
  • Análisis de datos en tiempo real 
  • Juegos en línea (p. ej., mensajería en tiempo real) 
  • Aplicaciones de software como servicio (SaaS) que utilizan servicios web 
  • Portales en línea (p. ej., interacciones entre el proveedor de atención médica y el paciente) 
  • La mayoría de los sistemas de escritura intensiva 
     

Publicación traducida automáticamente

Artículo escrito por Ashish_rana y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *