En este artículo, discutiremos las diferentes opciones de clase de estrategia admitidas por Cassandra , de modo que SimpleStrategy, LocalStrategy, NetworkTopologyStrategy son tres estrategias de replicación en las que generalmente usamos Simple y NetworkTopology Strategy en las que LocalStrategy se usa solo para el sistema. vamos a discutir uno por uno.
Los diferentes tipos de opciones de clase de estrategia de replicación compatibles con Cassandra son los siguientes:
1. SimpleStrategy 2. LocalStrategy 3. NetworkTopologyStrategy
Estos se explican a continuación a continuación.
1. SimpleStrategy:
es una estrategia simple que se recomienda para múltiples Nodes en múltiples bastidores en un solo centro de datos.
Consideremos tomar un ejemplo,strategy_demo es un nombre de espacio de claves en el que la clase es SimpleStrategy y replication_factor es 2, lo que simplemente significa que hay dos copias redundantes de cada fila en un solo centro de datos. echemos un vistazo.
Creando un espacio de claves:
CREATE KEYSPACE cluster1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 2};
Verifiquemos el espacio de claves cluster1.
describe keyspace cluster1;
Producción:
2. LocalStrategy:
es la estrategia en la que usaremos una estrategia de replicación para fines internos, de modo que se usa para el sistema y los espacios de claves sys_auth son espacios de claves internos. En Cassandra, los espacios de claves internos manejados implícitamente por la arquitectura de almacenamiento de Cassandra para administrar la autorización y la autenticación.
No está permitido crear un espacio de claves con la clase LocalStrategy si intentamos crear dicho espacio de claves, daría un error como «LocalStrategy es solo para el propósito interno de Cassandra».
3. NetworkTopologyStrategy:
es la estrategia en la que podemos almacenar múltiples copias de datos en diferentes centros de datos según la necesidad. Esta es una razón importante para usar NetworkTopologyStrategy cuando es necesario colocar varios Nodes de réplica en diferentes centros de datos.
Consideremos un ejemplo, cluster1 es un nombre de espacio de claves en el que NetworkTopologyStrategy es una estrategia de replicación y hay dos centros de datos, uno está al este con RF (Factor de replicación) = 2 y el segundo está al oeste con RF (Factor de replicación) = 3.
Echemos un vistazo.
CREATE KEYSPACE cluster1 WITH replication = {'class': 'NetworkTopologyStrategy', 'east' : 2, 'west' : 3};
Para verificar todos los espacios de claves internos existentes, utilice la siguiente consulta de CQL que se proporciona a continuación.
select * from system_schema.keyspaces;
Producción:
select * from system_schema.keyspaces where keyspace_name = 'cluster1';
Producción:
Para verificar todas las tablas para un espacio de claves existente específico, utilice la siguiente consulta CQL que se proporciona a continuación.
Primero, vamos a crear algunas tablas en el espacio de claves cluster1. echemos un vistazo.
create table tb1 ( Id int primary key, name text, city text );
Tabla 2:
create table tb2 ( Id int primary key, event text, team_name text );
Verifiquemos el esquema de espacio de claves de cluster1 usando la siguiente consulta CQL.
SELECT * FROM system_schema.tables WHERE keyspace_name = 'cluster1';
Producción:
Para averiguar todas las columnas de una tabla específica con un espacio de claves específico, utilice la siguiente consulta CQL que se proporciona a continuación.
SELECT * FROM system_schema.columns WHERE keyspace_name = 'cluster1' AND table_name = 'tb2';
Producción:
Espacios de claves system y system_auth:
el espacio de claves del sistema contiene información sobre familias de columnas, columnas y clústeres disponibles. El espacio de claves system_auth contiene principalmente información de autenticación, credenciales de usuario y permisos.
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