Interfaz de Cassandra

En esta página se compara la arquitectura de Apache Cassandra y Spanner, y se explican las funciones y las limitaciones de la interfaz de Spanner con Cassandra. Se presupone que conoces Cassandra y quieres migrar aplicaciones o diseñar otras nuevas usando Spanner como base de datos.

Cassandra y Spanner son bases de datos distribuidas a gran escala creadas para aplicaciones que requieren alta escalabilidad y baja latencia. Aunque ambas bases de datos pueden admitir cargas de trabajo NoSQL exigentes, Spanner ofrece funciones avanzadas para el modelado, las consultas y las operaciones transaccionales de datos. Para obtener más información sobre cómo cumple Spanner 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 es equivalente a una instancia de Spanner, que es un conjunto de servidores y recursos de almacenamiento. Como Spanner es un servicio gestionado, no tienes que configurar el hardware ni el software subyacentes. Solo tienes que especificar la cantidad de nodos que quieres reservar para tu instancia o usar el autoescalado para escalar la instancia automáticamente. Una instancia actúa como un contenedor de tus bases de datos. También puedes elegir la topología de replicación de datos (regional, birregional o multirregional) a nivel de instancia.
Espacio de claves 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 de esquema (por ejemplo, índices y roles). A diferencia de un espacio de claves, no es necesario configurar la ubicación de la réplica. 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 principal especificada en el esquema de la tabla.
Partición Dividir

Tanto Cassandra como Spanner escalan fragmentando los datos. En Cassandra, cada fragmento se denomina partición, mientras que en Spanner se denomina división. Cassandra usa la partición por hash, lo que significa que cada fila se asigna de forma independiente a un nodo de almacenamiento en función de un hash de la clave principal. Spanner se fragmenta por intervalos, lo que significa que las filas que son contiguas en el espacio de claves de la clave principal también lo son en el almacenamiento (excepto en los límites de las divisiones). Spanner se encarga de dividir y combinar en función de la carga y el almacenamiento, y esto es transparente para la aplicación. La principal implicación es que, a diferencia de Cassandra, las lecturas de intervalo en un prefijo de la clave principal 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 principal. 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 clustering, ya que los datos se fragmentan por intervalo. Puedes considerar que Spanner solo tiene columnas de clustering, con la partición gestionada 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 por 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 colocados junto a esos servidores. Una función hash asigna filas de un espacio de claves de partición a un nodo virtual (vnode). A continuación, se asigna aleatoriamente un conjunto de vnodos a cada servidor para que sirva una parte del espacio de claves del clúster. El almacenamiento de los vnodes está conectado localmente al nodo de servicio. Los controladores de cliente se conectan directamente a los nodos de servicio y gestionan el balanceo de carga 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 intervalos de filas en función del uso de CPU y disco. Los fragmentos se asignan a nodos de computación para que se publiquen. Los datos se almacenan físicamente en Colossus, el sistema de archivos distribuidos de Google, de forma independiente de los nodos de computación. Los controladores de cliente se conectan a los servidores frontend de Spanner, que se encargan del enrutamiento de solicitudes y del balanceo de carga. Para obtener más información, consulta el informe sobre el ciclo de vida de las lecturas y escrituras de Spanner.

A grandes rasgos, ambas arquitecturas se escalan a medida que se añaden recursos al clúster subyacente. La separación de la computación y el almacenamiento de Spanner permite que la carga entre los nodos de computación 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 intervalos de Spanner puede ser más natural para las aplicaciones que esperan que los datos se ordenen por clave de partición. La otra cara de la partición basada en intervalos es que las cargas de trabajo que escriben en un extremo del espacio de claves (por ejemplo, las tablas con claves basadas en la marca de tiempo actual) pueden tener puntos de acceso si no se tienen en cuenta diseños de esquemas adicionales. Para obtener más información sobre las técnicas para superar los hotspots, consulta Prácticas recomendadas para el diseño de esquemas.

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 un único nodo de réplica para responder y que la operación se considere correcta.

Spanner proporciona una coherencia inmediata. 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 escribe en la mayoría de las réplicas antes de que Spanner informe al usuario de que se ha realizado correctamente. Las lecturas posteriores reflejarán los datos recién escritos. Las aplicaciones pueden leer una instantánea de la base de datos en un momento anterior, lo que puede ofrecer ventajas de rendimiento con respecto a 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 diseñó para ofrecer la coherencia y la disponibilidad que necesitan las aplicaciones a gran escala. Spanner ofrece una coherencia inmediata a gran escala y con un alto rendimiento. En los casos prácticos que lo requieran, Spanner admite lecturas de instantáneas (obsoletas) que reducen los requisitos de actualización.

Interfaz de Cassandra

La interfaz de Cassandra te permite aprovechar la infraestructura totalmente gestionada, escalable y de alta disponibilidad de Spanner con herramientas y sintaxis de Cassandra que ya conoces. En esta página se describen las funciones y las limitaciones de la interfaz de Cassandra.

Ventajas de la interfaz de Cassandra

  • Portabilidad: la interfaz de Cassandra proporciona acceso a la amplia gama de funciones de Spanner mediante esquemas, consultas y clientes compatibles con Cassandra. De esta forma, se simplifica la migración de una aplicación creada en Spanner a otro entorno de Cassandra o viceversa. Esta portabilidad ofrece flexibilidad de implementación y admite situaciones de recuperación ante desastres, como una salida forzada.
  • Familiaridad: si ya usas Cassandra, puedes empezar a usar Spanner rápidamente con muchas de las mismas instrucciones y tipos de CQL.
  • Spanner sin concesiones: como se basa en la infraestructura de Spanner, la interfaz de Cassandra ofrece todas las ventajas de disponibilidad, coherencia y relación precio-rendimiento de Spanner sin tener que renunciar a ninguna de las funciones 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.

  • Funciones de Cassandra compatibles: la interfaz de Cassandra admite muchas de las funciones más habituales de Cassandra. Esto incluye partes principales del esquema y del sistema de tipos, muchas formas de consulta habituales, 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 conexión de Cassandra.

  • Compatibilidad con clientes y protocolos de conexión: Spanner admite las funciones de consulta principales del protocolo de conexión de Cassandra v4 mediante el adaptador de Cassandra, un cliente ligero que se ejecuta junto con tu aplicación. De esta forma, muchos clientes de Cassandra pueden trabajar tal cual con una base de datos de interfaz de Cassandra de Spanner, al tiempo que aprovechan la gestión de conexiones y endpoints globales y la autenticación de gestión de identidades y accesos de Spanner.

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 de GoogleSQL de Spanner equivalente.

Tipos de datos de Cassandra admitidos Tipo de datos de GoogleSQL de Spanner
Tipos numéricos tinyint (entero de 8 bits con signo) INT64 (entero de 64 bits con signo)

Spanner admite un único tipo de datos de 64 bits para números enteros con signo.

smallint (entero de 16 bits con signo)
int (entero de 32 bits con signo)
bigint (entero de 64 bits con signo)
float (coma flotante IEEE-754 de 32 bits) FLOAT32 (coma flotante IEEE-754 de 32 bits)
double (coma flotante IEEE-754 de 64 bits) FLOAT64 (coma 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 cadena 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 afecta al almacenamiento, sino que se usa con 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 específico. Usa INT64 para almacenar la duración en nanosegundos.

timestamp TIMESTAMP
duration STRING(MAX)

Spanner no admite un tipo de duración almacenado. Usa STRING para almacenar la duración.

Tipos de contenedores set ARRAY

Spanner no admite un tipo de datos set específico. Usa columnas ARRAY para representar un set.

list ARRAY

Usa ARRAY para almacenar una lista de objetos tipados.

map JSON

Spanner no admite un tipo de mapa específico. 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 quieres interactuar mediante consultas compatibles con Cassandra, puedes usar la opción cassandra_type para especificar el tipo de datos de Cassandra correspondiente a cada columna. Spanner usa esta asignación para interpretar y convertir correctamente los datos al transferirlos 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, se usan 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 al 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 (Spanner ARRAY<STRING(MAX)>) se asigna a set<varchar> en Cassandra.
  • tags (Spanner JSON) 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 (Spanner ARRAY<INT64>) se asigna a frozen<set<int>> en Cassandra.
Modificar la opción cassandra_type

Puede usar la instrucción ALTER TABLE para añadir o modificar la opción cassandra_type en las columnas.

Para añadir una opción cassandra_type a una columna que aún no la tenga, 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 definida como uuid.

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

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

Solo puedes modificar los siguientes tipos:

De Para
tinyint smallint, int, bigint
smallint int, bigint
int bigint
flotante doble
texto varchar
ascii varchar, text
Asignaciones directas y matizadas

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 atención y ajustes. Por ejemplo, puede que tengas que asignar un smallint de Cassandra a un INT64 de Spanner.

Funciones de Cassandra admitidas

En esta sección se enumeran las funciones de Cassandra compatibles con Spanner.

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

Tiempo de vida (TTL, time to live)

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

La lógica de TTL de Spanner funciona a nivel de fila, a diferencia de Cassandra, donde se puede aplicar a nivel de 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 elimina la fila cuando supera la duración especificada en relación con la marca de tiempo.

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

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

Funciones de Cassandra no compatibles en Spanner

Es importante tener en cuenta que la interfaz de Cassandra proporciona las funciones de Spanner a través de esquemas, tipos, consultas y clientes compatibles con Cassandra. No admite todas las funciones de Cassandra. Migrar una aplicación de Cassandra a Spanner, incluso usando la interfaz de Cassandra, probablemente requiera algunos cambios para adaptarse a las funciones de Cassandra no compatibles o a las diferencias de comportamiento, como la optimización de consultas o el diseño de claves principales. Sin embargo, una vez que se haya migrado, tus cargas de trabajo podrán aprovechar la fiabilidad y las funciones multimodelos únicas de Spanner.

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

  • Algunas funciones del lenguaje CQL no están disponibles: tipos y funciones definidos por el usuario, y marca de tiempo de escritura.
  • Spanner y el Google Cloud plano de control: las bases de datos con interfaces de Cassandra usan Spanner y las Google Cloudherramientas para aprovisionar, proteger, monitorizar y optimizar instancias. Spanner no admite herramientas como nodetool para actividades administrativas.

Compatibilidad con DDL

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

Conectividad

  • Compatibilidad con clientes de Cassandra

    Spanner te permite conectarte a bases de datos desde varios clientes:

Control de acceso con Gestión de Identidades y Accesos

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

Para obtener más información sobre cómo conceder permisos de gestión de identidades y accesos de Spanner, consulta Aplicar roles de gestión de identidades y accesos.

Supervisión

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

  • spanner.googleapis.com/api/adapter_request_count: captura y expone el número de solicitudes de adaptador que Spanner realiza por segundo o el número 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 tarda Spanner en gestionar las solicitudes del adaptador.

Puede crear un panel de control personalizado de Cloud Monitoring para mostrar y monitorizar las métricas de Cassandra Adapter. El panel de control personalizado contiene los siguientes gráficos:

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

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

  • Número de solicitudes a la API por tipo de mensaje: el número de solicitudes a la API por message_type de tu base de datos.

  • Número de solicitudes a la API por tipo de operación: el número de solicitudes a la API por op_type de tu base de datos.

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

Google Cloud consola

  1. Descarga el archivo cassandra-adapter-dashboard.json. Este archivo contiene la información necesaria para rellenar un panel de control personalizado en Monitorización.
  2. En la Google Cloud consola, ve a la página  Paneles de control:

    Ve a Paneles.

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

  3. En la página Resumen de los paneles de control, haga clic en Crear panel de control personalizado.
  4. En la barra de herramientas del panel de control, haga clic en el icono Configuración del panel de control. A continuación, 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 has descargado y pégalo en el editor.
  6. Para aplicar los cambios al panel de control, haz clic en Aplicar cambios. Si no quieres usar este panel de control, vuelve a la página de resumen de paneles de control.
  7. Una vez creado el panel de control, haz clic en Añadir filtro. A continuación, selecciona project_id o instance_id para monitorizar el adaptador de Cassandra.

CLI de gcloud

  1. Descarga el archivo cassandra-adapter-dashboard.json. Este archivo contiene la información necesaria para rellenar un panel de control personalizado en Monitorización.
  2. Para crear un panel de control 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 monitorizar el adaptador de Cassandra:

Para ver una lista completa de las estadísticas del sistema, consulta Monitorizar instancias con estadísticas del sistema. Para obtener más información sobre cómo monitorizar tus recursos de Spanner, consulta el artículo Monitorizar instancias con Cloud Monitoring.

Precios

No se aplica ningún cargo adicional por usar el endpoint de Cassandra. Se te cobrará el precio estándar de Spanner por la cantidad de capacidad de computación que use tu instancia y la cantidad de almacenamiento que use tu base de datos.

Para obtener más información, consulta la página de precios de Spanner.

Siguientes pasos