Interfaz de Cassandra

Vista previa — Cassandra interface

Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles “tal cual” y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se comparan las arquitecturas de Apache Cassandra y Spanner, y se te ayuda a comprender las capacidades y limitaciones de la interfaz de Cassandra de Spanner. Se supone que conoces Cassandra y deseas migrar aplicaciones existentes o diseñar aplicaciones nuevas mientras usas Spanner como tu base de datos.

Cassandra y Spanner son bases de datos distribuidas a gran escala creadas para aplicaciones que requieren alta escalabilidad y baja latencia. Si bien ambas bases de datos pueden admitir cargas de trabajo NoSQL exigentes, Spanner proporciona funciones avanzadas para el modelado de datos, las consultas y las operaciones transaccionales. Para obtener más información sobre cómo Spanner cumple con los criterios de las bases de datos NoSQL, consulta Spanner para cargas de trabajo no relacionales.

Conceptos básicos

En esta sección, se comparan los conceptos clave de Cassandra y Spanner.

Terminología

Cassandra	Spanner
Clúster	Instancia Un clúster de Cassandra equivale a una instancia de Spanner, es decir, una colección de servidores y recursos de almacenamiento. Dado que Spanner es un servicio administrado, no tienes que configurar el hardware ni el software subyacentes. Solo necesitas especificar la cantidad de nodos que deseas reservar para tu instancia o usar el ajuste de escala automático para escalar la instancia automáticamente. Una instancia actúa como un contenedor para tus bases de datos. También puedes elegir la topología de replicación de datos (regional, birregional o multirregional) a nivel de la instancia.
Keyspace	Base de datos Un espacio de claves de Cassandra equivale a una base de datos de Spanner, que es una colección de tablas y otros elementos del esquema (por ejemplo, índices y roles). A diferencia de un keyspace, no necesitas configurar la ubicación de la replicación. Spanner replica automáticamente tus datos en la región designada en tu instancia.
Tabla	Tabla Tanto en Cassandra como en Spanner, las tablas son una colección de filas identificadas por una clave primaria especificada en el esquema de la tabla.
Partición	División Tanto Cassandra como Spanner se escalan mediante la fragmentación de datos. En Cassandra, cada fragmento se denomina partición, mientras que en Spanner, cada fragmento se denomina división. Cassandra usa el particionado por hash, lo que significa que cada fila se asigna de forma independiente a un nodo de almacenamiento según un hash de la clave primaria. Spanner se fragmenta por rangos, lo que significa que las filas que son contiguas en el espacio de claves de la clave primaria también son contiguas en el almacenamiento (excepto en los límites de división). Spanner se encarga de dividir y combinar los datos según la carga y el almacenamiento, y esto es transparente para la aplicación. La implicación clave es que, a diferencia de Cassandra, los análisis de rangos sobre un prefijo de la clave primaria son una operación eficiente en Spanner.
Fila	Fila Tanto en Cassandra como en Spanner, una fila es una colección de columnas identificadas de forma única por una clave primaria. Al igual que Cassandra, Spanner admite claves primarias compuestas. A diferencia de Cassandra, Spanner no distingue entre la clave de partición y las columnas de agrupamiento en clústeres, ya que los datos se fragmentan por rango. Puedes pensar que Spanner solo tiene columnas de agrupamiento en clústeres, con la partición administrada en segundo plano.
Columna	Columna Tanto en Cassandra como en Spanner, una columna es un conjunto de valores de datos que tienen el mismo tipo. Hay un valor para cada fila de una tabla. Para obtener más información sobre la comparación de los tipos de columnas de Cassandra con Spanner, consulta Tipos de datos.

Arquitectura

Un clúster de Cassandra consta de un conjunto de servidores y almacenamiento ubicados junto con esos servidores. Una función de hash asigna filas de un espacio de claves de partición a un nodo virtual (vnode). Luego, se asigna un conjunto de vnodes de forma aleatoria a cada servidor para que entregue una parte del espacio de claves del clúster. El almacenamiento para los vnodes se conecta de forma local al nodo de entrega. Los controladores de cliente se conectan directamente a los nodos de procesamiento y controlan el balanceo de cargas y el enrutamiento de consultas.

Una instancia de Spanner consta de un conjunto de servidores en una topología de replicación. Spanner fragmenta dinámicamente cada tabla en rangos de filas según el uso de CPU y disco. Los fragmentos se asignan a los nodos de procesamiento para la publicación. Los datos se almacenan físicamente en Colossus, el sistema de archivos distribuidos de Google, por separado de los nodos de procesamiento. Los controladores de cliente se conectan a los servidores de frontend de Spanner, que realizan el enrutamiento de solicitudes y el balanceo de cargas. Para obtener más información, consulta el informe técnico Ciclo de vida de las operaciones de lectura y escritura de Spanner.

A un nivel general, ambas arquitecturas se ajustan a medida que se agregan recursos al clúster subyacente. La separación del procesamiento y el almacenamiento de Spanner permite que la carga entre los nodos de procesamiento se reequilibre más rápido en respuesta a los cambios en la carga de trabajo. A diferencia de Cassandra, los movimientos de fragmentos no implican movimientos de datos, ya que los datos permanecen en Colossus. Además, la partición basada en rangos de Spanner podría ser más natural para las aplicaciones que esperan que los datos se ordenen por clave de partición. La desventaja de la partición basada en rangos es que las cargas de trabajo que escriben en un extremo del espacio de claves (por ejemplo, las tablas con claves según la marca de tiempo actual) pueden tener puntos calientes si no se consideran diseños de esquemas adicionales. Para obtener más información sobre las técnicas para superar los hotspots, consulta Recomendaciones sobre el diseño del esquema.

Coherencia

Con Cassandra, debes especificar un nivel de coherencia para cada operación. Si usas el nivel de coherencia de quórum, la mayoría de los nodos de réplica deben responder al nodo coordinador para que la operación se considere correcta. Si usas un nivel de coherencia de uno, Cassandra necesita que un solo nodo de réplica responda para que la operación se considere correcta.

Spanner proporciona coherencia sólida. La API de Spanner no expone réplicas al cliente. Los clientes de Spanner interactúan con Spanner como si fuera una base de datos de una sola máquina. Una escritura siempre se realiza en la mayoría de las réplicas antes de que Spanner informe al usuario que se realizó correctamente. Cualquier lectura posterior reflejará los datos recién escritos. Las aplicaciones pueden optar por leer una instantánea de la base de datos en un momento anterior, lo que podría tener beneficios de rendimiento en comparación con las lecturas sólidas. Para obtener más información sobre las propiedades de coherencia de Spanner, consulta la Descripción general de las transacciones.

Spanner se creó para admitir la coherencia y la disponibilidad necesarias en las aplicaciones a gran escala. Spanner proporciona coherencia sólida a gran escala y con alto rendimiento. Para los casos de uso que lo requieren, Spanner admite lecturas de instantáneas (inactivas) que relajan los requisitos de actualización.

Interfaz de Cassandra

La interfaz de Cassandra te permite aprovechar la infraestructura de Spanner, que es administrada por completo, escalable y de alta disponibilidad, con herramientas y sintaxis conocidas de Cassandra. En esta página, se explican las capacidades y limitaciones de la interfaz de Cassandra.

Beneficios de la interfaz de Cassandra

• Portabilidad: La interfaz de Cassandra proporciona acceso a la amplitud de las funciones de Spanner, con esquemas, consultas y clientes que son compatibles con Cassandra. Esto simplifica la migración de una aplicación compilada en Spanner a otro entorno de Cassandra o viceversa. Esta portabilidad proporciona flexibilidad en la implementación y admite situaciones de recuperación ante desastres, como una salida forzada.
• Familiaridad: Si ya usas Cassandra, puedes comenzar a usar Spanner rápidamente con muchas de las mismas instrucciones y tipos de CQL.
• Spanner sin concesiones: Debido a que se basa en la infraestructura existente de Spanner, la interfaz de Cassandra proporciona todos los beneficios existentes de disponibilidad, coherencia y relación precio-rendimiento de Spanner sin tener que comprometer ninguna de las capacidades disponibles en el ecosistema complementario de GoogleSQL.

Compatibilidad con CQL

• Compatibilidad con el dialecto de CQL: Spanner proporciona un subconjunto del dialecto de CQL, que incluye el lenguaje de consulta de datos (DQL), el lenguaje de manipulación de datos (DML), las transacciones ligeras (LWT) y las funciones de agregación y de fecha y hora.

• Funcionalidad de Cassandra compatible: La interfaz de Cassandra admite muchas de las funciones más usadas de Cassandra. Esto incluye partes centrales del esquema y el sistema de tipos, muchas formas de consultas comunes, una variedad de funciones y operadores, y los aspectos clave del catálogo del sistema de Cassandra. Las aplicaciones pueden usar muchos clientes o controladores de Cassandra conectándose a través de la implementación de Spanner del protocolo de cable de Cassandra.

• Compatibilidad con el cliente y el protocolo de transferencia: Spanner admite las capacidades de consulta principales del protocolo de transferencia v4 de Cassandra con el adaptador de Cassandra, un cliente ligero que se ejecuta junto con tu aplicación. Esto permite que muchos clientes de Cassandra funcionen tal como están con una base de datos de interfaz de Spanner Cassandra, a la vez que aprovechan la administración de conexiones y el extremo global de Spanner, y la autenticación de IAM.

Tipos de datos de Cassandra admitidos

En la siguiente tabla, se muestran los tipos de datos de Cassandra admitidos y se asigna cada tipo de datos al tipo de datos equivalente de GoogleSQL de Spanner.

	Tipos de datos de Cassandra admitidos	Tipo de datos de GoogleSQL de Spanner
Tipos numéricos	tinyint (número entero de 8 bits con signo)	INT64 (número entero de 64 bits con firma) Spanner admite un solo tipo de datos de 64 bits de ancho para números enteros con signo.
	smallint (número entero de 16 bits con signo)
	int (número entero de 32 bits con signo)
	bigint (número entero de 64 bits con firma)
	float (punto flotante IEEE-754 de 32 bits)	FLOAT32 (punto flotante IEEE-754 de 32 bits)
	double (punto flotante IEEE-754 de 64 bits)	FLOAT64 (punto flotante IEEE-754 de 64 bits)
	decimal	Para los números decimales de precisión fija, usa el tipo de datos NUMERIC (precisión 38, escala 9).
	varint (entero de precisión variable)
Tipos de cadenas	text	STRING(MAX) Tanto text como varchar almacenan y validan cadenas UTF-8. En Spanner, las columnas STRING deben especificar su longitud máxima. No hay impacto en el almacenamiento; esto es para fines de validación.
	varchar
	ascii	STRING(MAX)
	uuid	STRING(MAX)
	timeuuid	STRING(MAX)
	inet	STRING(MAX)
blob	BYTES(MAX) Para almacenar datos binarios, usa el tipo de datos BYTES.
Tipos de fecha y hora	date	DATE
	time	INT64 Spanner no admite un tipo de datos de tiempo dedicado. Usa INT64 para almacenar la duración en nanosegundos.
	timestamp	TIMESTAMP
	duration	STRING(MAX) Spanner no admite un tipo de duración almacenada. Usa STRING para almacenar la duración.
Tipos de contenedores	set	ARRAY Spanner no admite un tipo de datos set dedicado. Usa columnas ARRAY para representar un set.
	list	ARRAY Usa ARRAY para almacenar una lista de objetos escritos.
	map	JSON Spanner no admite un tipo de mapa dedicado. Usa columnas JSON para representar mapas.
Otros tipos	boolean	BOOL
	counter	INT64

Anotaciones de tipo de datos

La opción de columna cassandra_type te permite definir asignaciones entre los tipos de datos de Cassandra y Spanner. Cuando creas una tabla en Spanner con la que planeas interactuar usando consultas compatibles con Cassandra, puedes usar la opción cassandra_type para especificar el tipo de datos de Cassandra correspondiente para cada columna. Spanner usa esta asignación para interpretar y convertir los datos correctamente cuando los transfiere entre los dos sistemas de bases de datos.

Por ejemplo, si hay una tabla en Cassandra con el siguiente esquema:

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

En Spanner, usas anotaciones de tipo para asignar los tipos de datos de Cassandra, como se muestra a continuación:

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

En el ejemplo anterior, la cláusula OPTIONS asigna el tipo de datos de Spanner de la columna a su tipo de datos de Cassandra correspondiente.

• albumId (Spanner STRING(MAX)) se asigna a uuid en Cassandra.
• title (Spanner STRING(MAX)) se asigna a varchar en Cassandra.
• artists (ARRAY<STRING(MAX)> de Spanner) se asigna a set<varchar> en Cassandra.
• tags (JSON de Spanner) se asigna a map<varchar,varchar> en Cassandra.
• numberOfSongs (Spanner INT64) se asigna a tinyint en Cassandra.
• releaseDate (Spanner DATE) se asigna a date en Cassandra.
• copiesSold (Spanner INT64) se asigna a bigint en Cassandra.
• score (ARRAY<INT64> de Spanner) se asigna a frozen<set<int>> en Cassandra.

Modifica la opción cassandra_type

Puedes usar la instrucción ALTER TABLE para agregar o modificar la opción cassandra_type en las columnas existentes.

Para agregar una opción cassandra_type a una columna que aún no la tiene, usa la siguiente instrucción:

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

En este ejemplo, la columna uuid de la tabla Albums se actualiza con la opción cassandra_type establecida en uuid.

Para modificar una opción cassandra_type existente, usa la instrucción ALTER TABLE con el nuevo valor de cassandra_type. Por ejemplo, para cambiar el cassandra_type de la columna numberOfSongs en la tabla Albums de tinyint a bigint, usa la siguiente instrucción:

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

Solo se te permite modificar los siguientes tipos:

De	A
tinyint	smallint, int, bigint
smallint	int, bigint
int	bigint
float	double
texto	varchar
ascii	varchar, text

Asignaciones directas y detalladas

En muchos casos, la asignación entre los tipos de datos de Spanner y Cassandra es sencilla. Por ejemplo, un STRING(MAX) de Spanner se asigna a un varchar de Cassandra, y un INT64 de Spanner se asigna a un bigint de Cassandra.

Sin embargo, hay situaciones en las que la asignación requiere más consideración y ajustes. Por ejemplo, es posible que debas asignar un smallint de Cassandra a un INT64 de Spanner.

Funciones compatibles de Cassandra

En esta sección, se enumeran las funciones de Cassandra que se admiten en Spanner.

En la siguiente lista, se muestra la compatibilidad de Spanner con las funciones de Cassandra.

• Todas las funciones de agregación
• Todas las funciones de fecha y hora, excepto currentTimeUUID
• Todas las funciones de conversión, excepto las funciones de conversión de BLOB
• Todas las funciones de transacción ligeras, excepto las condiciones de BATCH
• Ninguna de las siguientes funciones de consulta:
  • WRITETIME
  • TTL
  • TOKEN

Tiempo de actividad (TTL)

Cuando migres desde Cassandra, agrega una política de eliminación de filas a tu tabla de Spanner para usar la opción USING TTL en las declaraciones INSERT o UPDATE, o bien el TTL de Spanner.

La lógica del TTL de Spanner opera a nivel de la fila, a diferencia de Cassandra, donde la lógica del TTL se puede aplicar a nivel de la celda. Para usar el TTL de Spanner, debes incluir una columna de marca de tiempo y un intervalo de tiempo en la política de eliminación de filas. Spanner borra la fila después de que esta supera la duración especificada en relación con la marca de tiempo.

La eliminación del TTL de Spanner no es instantánea. Un proceso asíncrono en segundo plano borra las filas vencidas, y las eliminaciones pueden tardar hasta 72 horas.

Para obtener más información, consulta Habilita el TTL en los datos de Cassandra.

Funciones de Cassandra no compatibles en Spanner

Es importante comprender que la interfaz de Cassandra proporciona las capacidades de Spanner a través de esquemas, tipos, consultas y clientes que son compatibles con Cassandra. No admite todas las funciones de Cassandra. Migrar una aplicación de Cassandra existente a Spanner, incluso con la interfaz de Cassandra, probablemente requiera algo de trabajo para adaptarse a las capacidades de Cassandra no admitidas o a las diferencias en el comportamiento, como la optimización de consultas o el diseño de clave primaria. Sin embargo, una vez que se migran, tus cargas de trabajo pueden aprovechar la confiabilidad y las capacidades multimodelo únicas de Spanner.

En la siguiente lista, se proporciona más información sobre las funciones de Cassandra no admitidas:

• Algunas funciones del lenguaje de CQL no son compatibles: tipos y funciones definidos por el usuario, marca de tiempo de escritura.
• Spanner y plano de control de Google Cloud : Las bases de datos con interfaces de Cassandra usan Spanner y herramientas de Google Cloudpara aprovisionar, proteger, supervisar y optimizar instancias. Spanner no admite herramientas, como nodetool, para actividades administrativas.

Compatibilidad con DDL

Las sentencias DDL de CQL no se admiten directamente con la interfaz de Cassandra. Para los cambios en el DDL, debes usar la consola de Spanner Google Cloud , el comando de gcloud o las bibliotecas cliente.

Conectividad

• Compatibilidad con clientes de Cassandra

  Spanner te permite conectarte a bases de datos desde una variedad de clientes:

  • El adaptador de Cassandra se puede usar como un asistente en el proceso o como un proxy de sidecar para conectar tus aplicaciones de Cassandra a la interfaz de Cassandra. Para obtener más información, consulta Conéctate a Spanner con el adaptador de Cassandra.
  • El adaptador de Cassandra se puede iniciar como un proceso independiente de forma local y conectarse con CQLSH. Para obtener más información, consulta Conecta la interfaz de Cassandra a tu aplicación.

Control de acceso con Identity and Access Management

Debes tener los permisos spanner.databases.adapt, spanner.databases.select y spanner.databases.write para realizar operaciones de lectura y escritura en el extremo de Cassandra. Para obtener más información, consulta la descripción general de IAM.

Para obtener más información sobre cómo otorgar permisos de IAM de Spanner, consulta Cómo aplicar roles de IAM.

Supervisión

Spanner proporciona las siguientes métricas para ayudarte a supervisar el adaptador de Cassandra:

• spanner.googleapis.com/api/adapter_request_count: Captura y expone la cantidad de solicitudes del adaptador que Spanner realiza por segundo o la cantidad de errores que se producen en el servidor de Spanner por segundo.
• spanner.googleapis.com/api/adapter_request_latencies: Captura y expone la cantidad de tiempo que Spanner tarda en controlar las solicitudes del adaptador.

Puedes crear un panel personalizado de Cloud Monitoring para mostrar y supervisar las métricas del adaptador de Cassandra. El panel personalizado contiene los siguientes gráficos:

• Latencias de solicitudes de P99: Es la distribución del percentil 99 de las latencias de solicitudes del servidor por message_type para tu base de datos.

• Latencias de solicitudes P50: Es la distribución del percentil 50 de las latencias de solicitudes del servidor por message_type para tu base de datos.

• Recuento de solicitudes a la API por tipo de mensaje: Es el recuento de solicitudes a la API por message_type para tu base de datos.

• Recuento de solicitudes a la API por tipo de operación: Es el recuento de solicitudes a la API por op_type para tu base de datos.

• Tasas de errores: Son las tasas de errores de la API para tu base de datos.

Consola de Google Cloud

1. Descarga el archivo cassandra-adapter-dashboard.json. Este archivo contiene la información necesaria para completar un panel personalizado en Monitoring.

2. En la consola de Google Cloud , accede a la página Paneles :

   Acceder a Paneles

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.

3. En la página Descripción general de los paneles, haz clic en Crear panel personalizado.
4. En la barra de herramientas del panel, haz clic en el ícono de Configuración del panel. Luego, selecciona JSON y, después, Editor de JSON.
5. En el panel Editor de JSON, copia el contenido del archivo cassandra-adapter-dashboard.json que descargaste y pégalo en el editor.
6. Para aplicar los cambios al panel, haz clic en Aplicar cambios. Si no quieres usar este panel, vuelve a la página Resumen de los paneles.
7. Después de crear el panel, haz clic en Agregar filtro. Luego, selecciona project_id o instance_id para supervisar el adaptador de Cassandra.

gcloud CLI

1. Descarga el archivo cassandra-adapter-dashboard.json. Este archivo contiene la información necesaria para completar un panel personalizado en Monitoring.

2. Para crear un panel en un proyecto, usa el comando gcloud monitoring dashboards create:

   gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json
   

   Para obtener más información, consulta la referencia de gcloud monitoring dashboards create.

Además, las siguientes métricas de Spanner son útiles para supervisar el adaptador de Cassandra:

• Las métricas de uso de CPU proporcionan información sobre el uso de CPU para las tareas del usuario y del sistema, con desgloses por prioridad y tipo de operación.
• Las métricas de uso del almacenamiento proporcionan información sobre el almacenamiento de bases de datos y copias de seguridad.
• Las tablas de estadísticas integradas de Spanner proporcionan estadísticas sobre las consultas, las transacciones y las lecturas para ayudarte a descubrir problemas en tus bases de datos.

Para obtener una lista completa de las estadísticas del sistema, consulta Supervisa instancias con estadísticas del sistema. Para obtener más información sobre cómo supervisar tus recursos de Spanner, consulta Supervisa instancias con Cloud Monitoring.

Precios

No se aplican cargos adicionales por usar el endpoint de Cassandra. Se te cobra el precio estándar de Spanner por la cantidad de capacidad de procesamiento que usa tu instancia y la cantidad de almacenamiento que usa tu base de datos.

Para obtener más información, consulta Precios de Spanner.

¿Qué sigue?

• Aprende a migrar de Cassandra a Spanner.
• Aprende a conectarte a Spanner con el adaptador de Cassandra.
• Prueba el codelab de Spanner para usuarios de Cassandra.