Bigtable para usuarios de Cassandra

Este documento está dirigido a desarrolladores de software y administradores de bases de datos que quieran migrar aplicaciones o diseñar nuevas aplicaciones para usarlas con Bigtable como almacén de datos. En este documento se aplican tus conocimientos sobre Apache Cassandra al uso de Bigtable para describir los conceptos que debes conocer antes de realizar la migración. Para obtener información sobre las herramientas de código abierto que puedes usar para completar la migración, consulta el artículo Migrar de Cassandra a Bigtable.

Bigtable y Cassandra son bases de datos distribuidas. Implementan almacenes de clave-valor multidimensionales que pueden admitir decenas de miles de consultas por segundo (CPS), almacenamiento que se escala hasta petabytes de datos y tolerancia a fallos de nodos.

Cuándo es Bigtable un buen destino para las cargas de trabajo de Cassandra

El mejor servicio de Google Cloud para tu carga de trabajo de Cassandra depende de tus objetivos de migración y de las funciones de Cassandra que necesites después de la migración.

Bigtable es la opción óptima si se cumplen una o varias de las siguientes condiciones:

• Quieres un servicio totalmente gestionado con alta disponibilidad y sin ventanas de mantenimiento.
• Necesitas un escalado elástico que responda automáticamente a los cambios en el tráfico del servidor.
• Utilizas tipos de colección, contadores o vistas materializadas de Cassandra además de tipos escalares.
• Tienes una aplicación que usa el parámetro USING TIMESTAMP.
• El rendimiento de escritura y la latencia son tan importantes como las lecturas.
• Utilizas uno de los modelos de replicación de Cassandra que acaban siendo coherentes.
• Tu caso práctico requiere un almacenamiento rentable.

Para migrar aplicaciones sin hacer cambios en el código, puedes autogestionar Cassandra en GKE o usar un partner, como DataStax o ScyllaDB. Google CloudSi tu aplicación tiene muchas lecturas y quieres refactorizar el código para obtener las funciones de una base de datos relacional y una coherencia sólida, puedes plantearte usar Spanner.

En este documento se ofrecen consejos sobre qué tener en cuenta al refactorizar tu aplicación si eliges Bigtable como destino de migración para tus cargas de trabajo de Cassandra.

Cómo usar este documento

No es necesario que leas este documento de principio a fin. Aunque en este documento se comparan las dos bases de datos, también puede centrarse en los temas que se apliquen a su caso práctico o a sus intereses.

Para ayudarte a comparar Bigtable y Cassandra, este documento hace lo siguiente:

• Compara la terminología, que puede variar entre las dos bases de datos.
• Ofrece una descripción general de los dos sistemas de bases de datos.
• Analiza cómo gestiona cada base de datos el modelado de datos para comprender las diferentes consideraciones de diseño.
• Compara la ruta que siguen los datos durante las escrituras y las lecturas.
• Examina el diseño de los datos físicos para comprender aspectos de la arquitectura de la base de datos.
• Describe cómo configurar la replicación geográfica para cumplir tus requisitos y cómo abordar el dimensionamiento de los clústeres.
• Revisa los detalles sobre la gestión, la monitorización y la seguridad de los clústeres.

Comparación de terminología

Aunque muchos de los conceptos que se usan en Bigtable y Cassandra son similares, cada base de datos tiene convenciones de nomenclatura ligeramente diferentes y diferencias sutiles.

Uno de los componentes básicos de ambas bases de datos es la tabla de cadenas ordenadas (SSTable). En ambas arquitecturas, se crean SSTables para conservar los datos que se usan para responder a las consultas de lectura.

En una entrada de blog del 2012, Ilya Grigorik escribe lo siguiente: "Una SSTable es una abstracción sencilla para almacenar de forma eficiente un gran número de pares clave-valor y, al mismo tiempo, optimizar el rendimiento alto y las cargas de trabajo de lectura o escritura secuenciales".

En la siguiente tabla se describen los conceptos compartidos y la terminología correspondiente que usa cada producto:

Cassandra	Bigtable
Clave principal: valor único de uno o varios campos que determina la colocación y el orden de los datos. partition key: valor de uno o varios campos que determina la colocación de los datos mediante un hash coherente. Columna de clustering: valor de uno o varios campos que determina la ordenación lexicográfica de los datos en una partición.	Clave de fila: una cadena de bytes única que determina la colocación de los datos mediante una ordenación lexicográfica. Las claves compuestas se imitan uniendo los datos de varias columnas mediante un delimitador común, como los símbolos de almohadilla (#) o porcentaje (%).
Nodo: máquina responsable de leer y escribir datos asociados a una serie de intervalos de hash de partición de clave principal. En Cassandra, los datos se almacenan en un almacenamiento a nivel de bloque que está conectado al servidor de nodos.	Nodo: recurso de computación virtual responsable de leer y escribir datos asociados a una serie de intervalos de claves de fila. En Bigtable, los datos no se colocan junto a los nodos de cálculo. En su lugar, se almacena en Colossus, el sistema de archivos distribuidos de Google. Los nodos tienen la responsabilidad temporal de servir varios intervalos de datos en función de la carga de las operaciones y del estado de otros nodos del clúster.
Centro de datos: es similar a un clúster de Bigtable, pero algunos aspectos de la topología y la estrategia de replicación se pueden configurar en Cassandra. Rack: agrupación de nodos de un centro de datos que influye en la colocación de réplicas.	Clúster: grupo de nodos de la misma zona geográfica, colocados en el mismo lugar por motivos de latencia y replicación.Google Cloud
Clúster: implementación de Cassandra que consta de una colección de centros de datos.	Instancia: un grupo de clústeres de Bigtable en Google Cloud zonas o regiones Google Cloud diferentes entre los que se produce la replicación y el enrutamiento de conexiones.
vnode: un intervalo fijo de valores de hash asignado a un nodo físico específico. Los datos de un vnode se almacenan físicamente en el nodo de Cassandra en una serie de SSTables.	Tablet: una SSTable que contiene todos los datos de un intervalo contiguo de claves de fila ordenadas lexicográficamente. Las tablets no se almacenan en nodos de Bigtable, sino en una serie de SSTables en Colossus.
Factor de replicación: el número de réplicas de un vnode que se mantiene en todos los nodos del centro de datos. El factor de replicación se configura de forma independiente para cada centro de datos.	Replicación: proceso de replicación de los datos almacenados en Bigtable en todos los clústeres de la instancia. La replicación en un clúster zonal se gestiona mediante la capa de almacenamiento de Colossus.
Tabla (antes familia de columnas): organización lógica de valores indexada por la clave principal única.	Tabla: organización lógica de valores indexada por la clave de fila única.
keyspace: espacio de nombres de tabla lógico que define el factor de replicación de las tablas que contiene.	No aplicable Bigtable gestiona los problemas del espacio de claves de forma transparente.
map: un tipo de colección de Cassandra que contiene pares clave-valor.	Familia de columnas: espacio de nombres especificado por el usuario que agrupa los calificadores de columnas para que las lecturas y las escrituras sean más eficientes. Cuando se consulta Bigtable mediante SQL, las familias de columnas se tratan como los mapas de Cassandra.
Clave de mapa: clave que identifica de forma única una entrada de clave-valor en un mapa de Cassandra.	Calificador de columna: etiqueta de un valor almacenado en una tabla que se indexa mediante la clave de fila única. Cuando se consulta Bigtable con SQL, las columnas se tratan como claves de un mapa.
Columna: etiqueta de un valor almacenado en una tabla que está indexada por la clave principal única.	columna: la etiqueta de un valor almacenado en una tabla que está indexada por la clave de fila única. El nombre de la columna se crea combinando la familia de columnas con el calificador de columna.
Celda: valor de marca de tiempo de una tabla asociado a la intersección de una clave principal con la columna.	Celda: valor de marca de tiempo de una tabla asociado a la intersección de una clave de fila con el nombre de la columna. Se pueden almacenar y recuperar varias versiones con marca de tiempo de cada celda.
contador: un tipo de campo incrementable optimizado para operaciones de suma de números enteros.	Contadores: celdas que usan tipos de datos especializados para operaciones de suma de números enteros. Para obtener más información, consulta el artículo Crear y actualizar contadores.
Política de balanceo de carga: política que se configura en la lógica de la aplicación para enrutar las operaciones a un nodo adecuado del clúster. La política tiene en cuenta la topología del centro de datos y los intervalos de tokens de los vnodes.	Perfil de aplicación: ajustes que indican a Bigtable cómo enrutar una llamada a la API de cliente al clúster adecuado de la instancia. También puede usar el perfil de aplicación como etiqueta para segmentar métricas. El perfil de la aplicación se configura en el servicio.
CQL el lenguaje de consulta de Cassandra, un lenguaje similar a SQL que se usa para crear tablas, cambiar esquemas, mutar filas y hacer consultas.	El cliente de Cassandra a Bigtable para Java es un sustituto perfecto para tus controladores de Cassandra. El cliente de Java interpreta tus consultas de CQL y te permite usar Bigtable de forma transparente con tu aplicación basada en Cassandra sin tener que reescribir el código. El adaptador de proxy de Cassandra a Bigtable es una capa independiente que puedes ejecutar en paralelo a tu aplicación y conectarte a Bigtable como otro nodo de Cassandra. El adaptador de proxy ofrece compatibilidad con CQL y admite la escritura dual y las migraciones masivas. Esta función es similar a la que ofrece el cliente de Cassandra a Bigtable para Java. Las APIs de Bigtable son las bibliotecas de cliente y las APIs de gRPC que se usan para crear instancias y clústeres, tablas y familias de columnas, mutaciones de filas y ejecuciones de consultas. La API SQL de Bigtable es familiar para los usuarios de CQL.
Vista materializada: una instrucción SELECT que define un conjunto de filas que se corresponde con las filas de una tabla de origen subyacente. Cuando cambia la tabla de origen, Cassandra actualiza la vista materializada automáticamente.	Vista materializada continua: resultado precalculado y totalmente gestionado de una consulta de SQL que se actualiza de forma incremental y automática a partir de una tabla de origen. Para obtener más información, consulta Vistas materializadas continuas.

Resumen de los productos

En las siguientes secciones se ofrece una descripción general de la filosofía de diseño y los atributos clave de Bigtable y Cassandra.

Bigtable

Bigtable ofrece muchas de las funciones principales que se describen en el artículo Bigtable: A Distributed Storage System for Structured Data. Bigtable separa los nodos de computación, que atienden las solicitudes de los clientes, de la gestión del almacenamiento subyacente. Los datos se almacenan en Colossus. La capa de almacenamiento replica automáticamente los datos para ofrecer una durabilidad que supera los niveles que proporciona la replicación de tres vías estándar del sistema de archivos distribuidos de Hadoop (HDFS).

Esta arquitectura proporciona lecturas y escrituras coherentes en un clúster, escala vertical y horizontalmente sin ningún coste de redistribución del almacenamiento y puede reequilibrar las cargas de trabajo sin modificar el clúster ni el esquema. Si algún nodo de procesamiento de datos se deteriora, el servicio Bigtable lo sustituye de forma transparente. Bigtable también admite la replicación asíncrona.

Además de gRPC y las bibliotecas de cliente para varios lenguajes de programación, Bigtable mantiene la compatibilidad con la HBase, una implementación alternativa de código abierto del motor de base de datos del documento de Bigtable.

En el siguiente diagrama se muestra cómo separa físicamente Bigtable los nodos de procesamiento de la capa de almacenamiento:

En el diagrama anterior, el nodo de procesamiento central solo se encarga de servir solicitudes de datos del conjunto de datos C en la capa de almacenamiento. Si Bigtable identifica que es necesario reequilibrar la asignación de intervalos de un conjunto de datos, los intervalos de datos de un nodo de procesamiento se pueden cambiar fácilmente porque la capa de almacenamiento está separada de la capa de procesamiento.

En el siguiente diagrama se muestra, de forma simplificada, un reequilibrio del intervalo de claves y un cambio de tamaño del clúster:

La imagen Reequilibrado muestra el estado del clúster de Bigtable después de que el nodo de procesamiento situado más a la izquierda reciba un mayor número de solicitudes del conjunto de datos A. Una vez que se ha completado el reequilibrado, el nodo central, en lugar del nodo situado más a la izquierda, es el responsable de atender las solicitudes de datos del conjunto de datos B. El nodo situado más a la izquierda sigue atendiendo las solicitudes del conjunto de datos A.

Bigtable puede reorganizar los intervalos de claves de fila para equilibrar los intervalos de conjuntos de datos en un número mayor de nodos de procesamiento disponibles. La imagen Cambio de tamaño muestra el estado del clúster de Bigtable después de añadir un nodo.

Cassandra

Apache Cassandra es una base de datos de código abierto que se ha visto influenciada en parte por los conceptos del documento de Bigtable. Utiliza una arquitectura de nodos distribuidos, donde el almacenamiento se coloca junto con los servidores que responden a las operaciones de datos. Se asigna aleatoriamente una serie de nodos virtuales (vnodes) a cada servidor para que sirva una parte del espacio de claves del clúster.

Los datos se almacenan en los vnodes en función de la clave de partición. Normalmente, se usa una función hash coherente para generar un token que determine la ubicación de los datos. Al igual que con Bigtable, puedes usar un particionador que conserve el orden para generar tokens y, por lo tanto, también para colocar datos. Sin embargo, la documentación de Cassandra desaconseja este enfoque porque es probable que el clúster se desequilibre, una situación difícil de solucionar. Por este motivo, en este documento se da por hecho que usas una estrategia de hashing coherente para generar tokens que distribuyan los datos entre los nodos.

Cassandra ofrece tolerancia a fallos a través de niveles de disponibilidad que se correlacionan con el nivel de coherencia ajustable, lo que permite que un clúster sirva a los clientes mientras uno o varios nodos están dañados. La replicación geográfica se define mediante una estrategia de topología de replicación de datos configurable.

Especifica un nivel de coherencia para cada operación. La configuración habitual es QUORUM (o LOCAL_QUORUM en determinadas topologías de varios centros de datos). Este ajuste del nivel de coherencia requiere que la mayoría de los nodos de réplica respondan al nodo coordinador para que la operación se considere correcta. El factor de replicación, que se configura para cada espacio de claves, determina el número de réplicas de datos que se almacenan en cada centro de datos del clúster. Por ejemplo, es habitual usar un valor de factor de replicación de 3 para ofrecer un equilibrio práctico entre la durabilidad y el volumen de almacenamiento.

En el siguiente diagrama se muestra, de forma simplificada, un clúster de seis nodos en el que el intervalo de claves de cada nodo se divide en cinco vnodes. En la práctica, puedes tener más nodos y, probablemente, más vnodes.

En el diagrama anterior, se puede ver la ruta de una operación de escritura, con un nivel de coherencia de QUORUM, que se origina en una aplicación o un servicio cliente (Cliente). En este diagrama, los intervalos de claves se muestran como intervalos alfabéticos. En realidad, los tokens generados por un hash de la clave principal son números enteros firmados muy grandes.

En este ejemplo, el hash de la clave es M y los vnodes de M están en los nodos 2, 4 y 6. El coordinador debe ponerse en contacto con cada nodo en el que se almacenan localmente los intervalos de hash de la clave para que se pueda procesar la escritura. Como el nivel de coherencia es QUORUM, dos réplicas (la mayoría) deben responder al nodo coordinador antes de que se notifique al cliente que la escritura se ha completado.

A diferencia de Bigtable, para mover o cambiar intervalos de claves en Cassandra, debes copiar físicamente los datos de un nodo a otro. Si un nodo está sobrecargado con solicitudes de un intervalo de hash de token determinado, añadir el procesamiento de ese intervalo de tokens es más complejo en Cassandra que en Bigtable.

Replicación y coherencia geográficas

Bigtable y Cassandra gestionan la replicación y la coherencia geográficas (también conocidas como multirregión) de forma diferente. Un clúster de Cassandra consta de nodos de procesamiento agrupados en racks, y los racks se agrupan en centros de datos. Cassandra usa una estrategia de topología de red que se configura para determinar cómo se distribuyen las réplicas de nodos virtuales entre los hosts de un centro de datos. Esta estrategia revela los orígenes de Cassandra como una base de datos que se implementó originalmente en centros de datos físicos locales. Esta configuración también especifica el factor de replicación de cada centro de datos del clúster.

Cassandra usa configuraciones de centros de datos y racks para mejorar la tolerancia a fallos de las réplicas de datos. Durante las operaciones de lectura y escritura, la topología determina los nodos participantes necesarios para ofrecer garantías de coherencia. Debe configurar manualmente los nodos, los racks y los centros de datos cuando cree o amplíe un clúster. En un entorno de nube, una implementación típica de Cassandra trata una zona de nube como un rack y una región de nube como un centro de datos.

Puedes usar los controles de quórum de Cassandra para ajustar las garantías de coherencia de cada operación de lectura o escritura. Los niveles de solidez de la coherencia final pueden variar. Por ejemplo, hay opciones que requieren un solo nodo de réplica (ONE), una mayoría de nodos de réplica de un solo centro de datos (LOCAL_QUORUM) o una mayoría de todos los nodos de réplica de todos los centros de datos (QUORUM).

En Bigtable, los clústeres son recursos zonales. Una instancia de Bigtable puede contener un solo clúster o un grupo de clústeres replicados. Puedes colocar clústeres de instancias en cualquier combinación de zonas de las regiones que ofrece Google Cloud . Puedes añadir y eliminar clústeres de una instancia con un impacto mínimo en otros clústeres de la instancia.

En Bigtable, las escrituras se realizan (con coherencia inmediata [read-your-writes]) en un solo clúster y, con el tiempo, serán coherentes en los demás clústeres de la instancia. Como las celdas individuales se versionan por marca de tiempo, no se pierde ninguna escritura y cada clúster sirve las celdas que tienen las marcas de tiempo más actuales disponibles.

El servicio expone el estado de coherencia del clúster. La API Cloud Bigtable proporciona un mecanismo para obtener un token de coherencia a nivel de tabla. Puedes usar este token para determinar si se han replicado por completo todos los cambios que se hicieron en esa tabla antes de que se creara el token.

Asistencia para transacciones

Aunque ninguna de las bases de datos admite transacciones complejas de varias filas, ambas admiten algunas transacciones.

Cassandra tiene un método de transacción ligera (LWT) que proporciona atomicidad para las actualizaciones de los valores de las columnas de una sola partición. Cassandra también tiene semánticas de comparación y definición que completan la operación de lectura de filas y la comparación de valores antes de que se inicie una escritura.

Bigtable admite escrituras de una sola fila totalmente coherentes en un clúster. Las transacciones de una sola fila se habilitan mediante las operaciones de lectura-modificación-escritura y comprobación-mutación. Los perfiles de aplicación de enrutamiento de varios clústeres no admiten transacciones de una sola fila.

Modelo de datos

Tanto Bigtable como Cassandra organizan los datos en tablas que admiten búsquedas y análisis de intervalos mediante el identificador único de la fila. Ambos sistemas se clasifican como almacenes de columnas anchas NoSQL.

En Cassandra, debes usar CQL para crear el esquema de tabla completo con antelación, incluida la definición de la clave principal junto con los nombres de las columnas y sus tipos. Las claves principales de Cassandra son valores compuestos únicos que constan de una clave de partición obligatoria y una clave de clúster opcional. La clave de partición determina la colocación de los nodos de una fila, mientras que la clave de clúster determina el orden de clasificación dentro de una partición. Cuando crees esquemas, debes tener en cuenta las posibles ventajas y desventajas de ejecutar análisis eficientes en una única partición y los costes del sistema asociados al mantenimiento de particiones grandes.

En Bigtable, solo tienes que crear la tabla y definir sus familias de columnas con antelación. Las columnas no se declaran cuando se crean las tablas, sino que se crean cuando las llamadas a la API de la aplicación añaden celdas a las filas de la tabla.

Las claves de las filas se ordenan lexicográficamente en todo el clúster de Bigtable. Los nodos de Bigtable equilibran automáticamente la responsabilidad nodal de los intervalos de claves, que a menudo se denominan "tabletas" y, en ocasiones, "divisiones". Las claves de fila de Bigtable suelen constar de varios valores de campo que se unen mediante un carácter separador de uso común que elijas (por ejemplo, el signo de porcentaje). Cuando se separan, los componentes de la cadena individual son análogos a los campos de una clave principal de Cassandra.

Diseño de claves de fila

En Bigtable, el identificador único de una fila de una tabla es la clave de fila. La clave de fila debe ser un valor único en toda la tabla. Puedes crear claves de varias partes concatenando elementos dispares separados por un delimitador común. La clave de fila determina el orden de clasificación global de los datos de una tabla. El servicio de Bigtable determina de forma dinámica los intervalos de claves que se asignan a cada nodo.

A diferencia de Cassandra, donde el hash de la clave de partición determina la colocación de las filas y las columnas de agrupamiento determinan el orden, la clave de fila de Bigtable proporciona tanto la asignación nodal como el orden. Al igual que en Cassandra, debes diseñar una clave de fila en Bigtable de forma que las filas que quieras recuperar juntas se almacenen juntas. Sin embargo, en Bigtable no es necesario diseñar la clave de fila para la colocación y la ordenación antes de usar una tabla.

Tipos de datos

El servicio Bigtable no aplica los tipos de datos de las columnas que envía el cliente. Las bibliotecas de cliente proporcionan métodos auxiliares para escribir valores de celdas como bytes, cadenas codificadas en UTF-8 y enteros de 64 bits codificados en big-endian (los enteros codificados en big-endian son necesarios para las operaciones de incremento atómico).

Familia de columnas

En Bigtable, una familia de columnas determina qué columnas de una tabla se almacenan y se recuperan juntas. Cada tabla necesita al menos una familia de columnas, aunque las tablas suelen tener más (el límite es de 100 familias de columnas por tabla). Debes crear familias de columnas explícitamente para que una aplicación pueda usarlas en una operación.

Calificadores de columna

Cada valor almacenado en una tabla en una clave de fila se asocia a una etiqueta llamada calificador de columna. Como los calificadores de columna son solo etiquetas, no hay un límite práctico en el número de columnas que puede tener en una familia de columnas. Los calificadores de columna se suelen usar en Bigtable para representar datos de aplicaciones.

Celdas

En Bigtable, una celda es la intersección de la clave de fila y el nombre de columna (una familia de columnas combinada con un calificador de columna). Cada celda contiene uno o varios valores con marca de tiempo que puede proporcionar el cliente o que el servicio puede aplicar automáticamente. Los valores de las celdas antiguas se recuperan en función de una política de recogida de elementos no utilizados configurada a nivel de familia de columnas.

Índices secundarios

Puedes usar vistas materializadas continuas como índices secundarios asíncronos de tablas para consultar los mismos datos con diferentes patrones o atributos de búsqueda. Para obtener más información, consulta Crear un índice secundario asíncrono.

Balanceo de carga y conmutación por error del cliente

En Cassandra, el cliente controla el balanceo de carga de las solicitudes. El controlador del cliente define una política que se especifica como parte de la configuración o mediante programación durante la creación de la sesión. El clúster informa a la política sobre los centros de datos más cercanos a la aplicación y el cliente identifica los nodos de esos centros de datos para dar servicio a una operación.

El servicio Bigtable dirige las llamadas a la API a un clúster de destino en función de un parámetro (un identificador de perfil de aplicación) que se proporciona con cada operación. Los perfiles de aplicación se mantienen en el servicio Bigtable. Las operaciones de cliente que no seleccionan un perfil usan un perfil predeterminado.

Bigtable tiene dos tipos de políticas de enrutamiento de perfiles de aplicación: de un solo clúster y de varios clústeres. Un perfil multiclúster dirige las operaciones al clúster disponible más cercano. Se considera que los clústeres de la misma región están a la misma distancia desde el punto de vista del router de operaciones. Si el nodo responsable del intervalo de claves solicitado está sobrecargado o no está disponible temporalmente en un clúster, este tipo de perfil proporciona una conmutación por error automática.

En cuanto a Cassandra, una política de varios clústeres ofrece las ventajas de conmutación por error de una política de equilibrio de carga que tiene en cuenta los centros de datos.

Un perfil de aplicación que tiene un enrutamiento de un solo clúster dirige todo el tráfico a un único clúster. La coherencia sólida de las filas y las transacciones de una sola fila solo están disponibles en los perfiles que tienen un enrutamiento de un solo clúster.

El inconveniente de usar un solo clúster es que, en caso de conmutación por error, la aplicación debe poder reintentar la operación usando un identificador de perfil de aplicación alternativo o debes realizar la conmutación por error manualmente de los perfiles de enrutamiento a un solo clúster afectados.

Enrutamiento de operaciones

Cassandra y Bigtable usan métodos diferentes para seleccionar el nodo de procesamiento de las operaciones de lectura y escritura. En Cassandra, se identifica la clave de partición, mientras que en Bigtable se usa la clave de fila.

En Cassandra, el cliente inspecciona primero la política de equilibrio de carga. Este objeto del lado del cliente determina el centro de datos al que se dirige la operación.

Una vez identificado el centro de datos, Cassandra se pone en contacto con un nodo coordinador para gestionar la operación. Si la política reconoce tokens, el coordinador es un nodo que sirve datos de la partición de vnode de destino. De lo contrario, el coordinador es un nodo aleatorio. El nodo coordinador identifica los nodos en los que se encuentran las réplicas de datos de la clave de partición de la operación y, a continuación, indica a esos nodos que realicen la operación.

En Bigtable, como hemos comentado anteriormente, cada operación incluye un identificador de perfil de aplicación. El perfil de aplicación se define a nivel de servicio. La capa de enrutamiento de Bigtable inspecciona el perfil para elegir el clúster de destino adecuado para la operación. La capa de enrutamiento proporciona una ruta para que la operación llegue a los nodos de procesamiento correctos mediante la clave de fila de la operación.

Proceso de escritura de datos

Ambas bases de datos están optimizadas para realizar escrituras rápidas y usan un proceso similar para completar una escritura. Sin embargo, los pasos que siguen las bases de datos varían ligeramente, sobre todo en el caso de Cassandra, donde, en función del nivel de coherencia de la operación, puede que sea necesario comunicarse con nodos participantes adicionales.

Una vez que la solicitud de escritura se ha dirigido a los nodos correspondientes (Cassandra) o al nodo (Bigtable), las escrituras se conservan primero en el disco de forma secuencial en un registro de confirmación (Cassandra) o en un registro compartido (Bigtable). A continuación, las escrituras se insertan en una tabla en memoria (también conocida como memtable) que se ordena como las SSTables.

Después de estos dos pasos, el nodo responde para indicar que la escritura se ha completado. En Cassandra, deben responder varias réplicas (en función del nivel de coherencia especificado para cada operación) antes de que el coordinador informe al cliente de que la escritura se ha completado. En Bigtable, como cada clave de fila solo se asigna a un nodo en un momento dado, solo se necesita una respuesta del nodo para confirmar que la escritura se ha realizado correctamente.

Más adelante, si es necesario, puedes vaciar la memtable en el disco en forma de una nueva SSTable. En Cassandra, el vaciado se produce cuando el registro de confirmación alcanza un tamaño máximo o cuando la tabla en memoria supera un umbral que hayas configurado. En Bigtable, se inicia un vaciado para crear nuevas SSTables inmutables cuando la memtable alcanza un tamaño máximo especificado por el servicio. Periódicamente, un proceso de compactación combina las SSTables de un intervalo de claves determinado en una sola SSTable.

Actualizaciones de datos

Ambas bases de datos gestionan las actualizaciones de datos de forma similar. Sin embargo, Cassandra solo permite un valor por celda, mientras que Bigtable puede conservar un gran número de valores versionados por celda.

Cuando se modifica el valor de la intersección de un identificador de fila único y una columna, la actualización se conserva tal como se ha descrito anteriormente en la sección proceso de escritura de datos. La marca de tiempo de escritura se almacena junto con el valor en la estructura SSTable.

Si no has vaciado una celda actualizada en una SSTable, solo puedes almacenar el valor de la celda en la memtable, pero las bases de datos difieren en lo que se almacena. Cassandra solo guarda el valor más reciente en la memtable, mientras que Bigtable guarda todas las versiones en la memtable.

Por otro lado, si has vaciado al menos una versión de un valor de celda en el disco en SSTables independientes, las bases de datos gestionan las solicitudes de esos datos de forma diferente. Cuando se solicita la celda a Cassandra, solo se devuelve el valor más reciente según la marca de tiempo. En otras palabras, se tiene en cuenta la última escritura. En Bigtable, se usan filtros para controlar qué versiones de las celdas devuelve una solicitud de lectura.

Eliminaciones de filas

Como ambas bases de datos usan archivos SSTable inmutables para conservar los datos en el disco, no es posible eliminar una fila inmediatamente. Para asegurarse de que las consultas devuelvan los resultados correctos después de eliminar una fila, ambas bases de datos gestionan las eliminaciones con el mismo mecanismo. Primero se añade un marcador (llamado lápida en Cassandra) a la memtable. Finalmente, una SSTable recién escrita contiene un marcador con marca de tiempo que indica que el identificador de fila único se ha eliminado y no se debe devolver en los resultados de las consultas.

Tiempo de vida

Las funciones de tiempo de vida (TTL) de las dos bases de datos son similares, excepto por una diferencia. En Cassandra, puedes definir el TTL de una columna o una tabla, mientras que en Bigtable solo puedes definir TTLs para la familia de columnas. Bigtable tiene un método que puede simular el TTL a nivel de celda.

Recolección de memoria residual

Como no es posible actualizar ni eliminar datos de forma inmediata con las SSTables inmutables, tal como hemos comentado antes, la recogida de elementos no utilizados se produce durante un proceso llamado compresión. El proceso elimina las celdas o las filas que no deberían aparecer en los resultados de las consultas.

El proceso de recogida de elementos no utilizados excluye una fila o una celda cuando se produce una combinación de SSTables. Si hay un marcador o una lápida en una fila, esa fila no se incluye en la SSTable resultante. Ambas bases de datos pueden excluir una celda de la SSTable combinada. Si la marca de tiempo de la celda supera el tiempo de vida, las bases de datos excluyen la celda. Si hay dos versiones con marca de tiempo de una celda determinada, Cassandra solo incluye el valor más reciente en la SSTable combinada.

Ruta de lectura de datos

Cuando una operación de lectura llega al nodo de procesamiento adecuado, el proceso de lectura para obtener datos que satisfagan el resultado de una consulta es el mismo en ambas bases de datos.

Por cada SSTable del disco que pueda contener resultados de la consulta, se comprueba un filtro de Bloom para determinar si cada archivo contiene filas que se deben devolver. Como los filtros Bloom nunca proporcionan falsos negativos, todas las SSTables aptas se añaden a una lista de candidatas para incluirlas en el procesamiento de los resultados de lectura.

La operación de lectura se realiza mediante una vista combinada creada a partir de la tabla en memoria y las SSTables candidatas del disco. Como todas las claves están ordenadas lexicográficamente, es eficiente obtener una vista combinada que se analice para obtener los resultados de la consulta.

En Cassandra, un conjunto de nodos de procesamiento determinados por el nivel de coherencia de la operación deben participar en la operación. En Bigtable, solo se debe consultar el nodo responsable del intervalo de claves. En el caso de Cassandra, debes tener en cuenta las implicaciones del tamaño de los recursos de computación, ya que es probable que varios nodos procesen cada lectura.

Los resultados de lectura se pueden limitar en el nodo de procesamiento de formas ligeramente diferentes. En Cassandra, la cláusula WHERE de una consulta CQL restringe las filas devueltas. La restricción es que las columnas de la clave principal o las columnas incluidas en un índice secundario se pueden usar para limitar los resultados.

Bigtable ofrece una gran variedad de filtros que afectan a las filas o celdas que recupera una consulta de lectura.

Hay tres categorías de filtros:

• Filtros de limitación, que controlan las filas o celdas que incluye la respuesta.
• Modificar filtros, que afectan a los datos o metadatos de celdas concretas.
• Crear filtros, que te permite combinar varios filtros en uno.

Los filtros de limitación son los más habituales. Por ejemplo, la expresión regular de la familia de columnas y la expresión regular del calificador de columna.

Almacenamiento de datos físico

Tanto Bigtable como Cassandra almacenan datos en SSTables, que se combinan periódicamente durante una fase de compactación. La compresión de datos de SSTable ofrece ventajas similares para reducir el tamaño del almacenamiento. Sin embargo, la compresión se aplica automáticamente en Bigtable y es una opción de configuración en Cassandra.

Al comparar las dos bases de datos, debe saber cómo almacena físicamente los datos cada una de ellas en los siguientes aspectos:

• La estrategia de distribución de datos
• Número de versiones de la celda disponibles
• Tipo de disco de almacenamiento
• El mecanismo de durabilidad y replicación de datos

Distribución de datos

En Cassandra, el método recomendado para determinar la distribución de datos en las distintas SSTables que sirven los nodos del clúster es un hash coherente de las columnas de partición de la clave principal.

Bigtable usa un prefijo variable para la clave de fila completa con el fin de colocar los datos en SSTables por orden lexicográfico.

Versiones de celdas

Cassandra solo conserva una versión activa del valor de la celda. Si se realizan dos escrituras en una celda, una política de "última escritura gana" asegura que solo se devuelva un valor.

Bigtable no limita el número de versiones con marca de tiempo de cada celda. Pueden aplicarse otros límites de tamaño de las filas. Si no se define en la solicitud del cliente, el servicio de Bigtable determina la marca de tiempo en el momento en que el nodo de procesamiento recibe la mutación. Las versiones de las celdas se pueden eliminar mediante una política de recogida de elementos no utilizados que puede ser diferente para cada familia de columnas de la tabla, o bien se pueden filtrar de un conjunto de resultados de una consulta a través de la API.

Almacenamiento en disco

Cassandra almacena SSTables en discos conectados a cada nodo del clúster. Para reequilibrar los datos en Cassandra, los archivos deben copiarse físicamente entre servidores.

Bigtable usa Colossus para almacenar SSTables. Como Bigtable usa este sistema de archivos distribuido, el servicio de Bigtable puede reasignar casi al instante SSTables a diferentes nodos.

Durabilidad y replicación de los datos

Cassandra ofrece durabilidad de los datos mediante el ajuste del factor de replicación. El factor de replicación determina el número de copias de SSTable que se almacenan en diferentes nodos del clúster. Un valor típico del factor de réplica es 3, que sigue permitiendo garantías de coherencia más sólidas con QUORUM o LOCAL_QUORUM, incluso si se produce un fallo en un nodo.

Con Bigtable, se ofrecen garantías de alta durabilidad de los datos a través de la replicación que proporciona Colossus.

En el siguiente diagrama se muestra el diseño de los datos físicos, los nodos de procesamiento de computación y la capa de enrutamiento de Bigtable:

En la capa de almacenamiento de Colossus, cada nodo se asigna para servir los datos que se almacenan en una serie de SSTables. Esas SSTables contienen los datos de los intervalos de claves de fila que se asignan dinámicamente a cada nodo. Aunque el diagrama muestra tres SSTables por cada nodo, es probable que haya más, ya que las SSTables se crean continuamente a medida que los nodos reciben nuevos cambios en los datos.

Cada nodo tiene un registro compartido. Las escrituras procesadas por cada nodo se conservan inmediatamente en el registro compartido antes de que el cliente reciba una confirmación de escritura. Como una escritura en Colossus se replica varias veces, la durabilidad se asegura incluso si se produce un fallo en el hardware de los nodos antes de que los datos se conserven en una SSTable para el intervalo de filas.

Interfaces de aplicaciones

Originalmente, el acceso a la base de datos de Cassandra se exponía a través de una API de Thrift, pero este método de acceso está obsoleto. La interacción recomendada con el cliente es a través de CQL.

Al igual que la API Thrift original de Cassandra, el acceso a la base de datos de Bigtable se proporciona a través de una API que lee y escribe datos en función de las claves de fila proporcionadas.

Al igual que Cassandra, Bigtable tiene una interfaz de línea de comandos, llamada cbtCLI , y bibliotecas de cliente que admiten muchos lenguajes de programación comunes. Estas bibliotecas se basan en las APIs gRPC y REST. Las aplicaciones escritas para Hadoop que dependen de la biblioteca de código abierto Apache HBase para Java pueden conectarse a Bigtable sin apenas cambios. En el caso de las aplicaciones que no requieren compatibilidad con HBase, te recomendamos que uses el cliente Java de Bigtable integrado.

Los controles de gestión de identidades y accesos (IAM) de Bigtable están totalmente integrados con Google Cloud, y las tablas también se pueden usar como fuente de datos externa de BigQuery.

Configuración de la base de datos

Cuando configuras un clúster de Cassandra, tienes que tomar varias decisiones de configuración y completar varios pasos. Primero, debes configurar los nodos de tu servidor para que proporcionen capacidad de computación y aprovisionen almacenamiento local. Si usas un factor de réplica de tres, que es el ajuste recomendado y más habitual, debes aprovisionar almacenamiento para almacenar el triple de la cantidad de datos que esperas que contenga tu clúster. También debe determinar y definir las configuraciones de los vnodes, los racks y la replicación.

La separación del proceso del almacenamiento en Bigtable simplifica el escalado vertical de los clústeres en comparación con Cassandra. En un clúster que funciona con normalidad, solo te suele preocupar el almacenamiento total que usan las tablas gestionadas, que determina el número mínimo de nodos, y tener suficientes nodos para mantener el QPS actual.

Puedes ajustar rápidamente el tamaño del clúster de Bigtable si el clúster está aprovisionado en exceso o en defecto en función de la carga de producción.

Almacenamiento de Bigtable

Aparte de la ubicación geográfica del clúster inicial, lo único que tienes que elegir al crear tu instancia de Bigtable es el tipo de almacenamiento. Bigtable ofrece dos opciones de almacenamiento: unidades de estado sólido (SSD) o unidades de disco duro (HDD). Todos los clústeres de una instancia deben compartir el mismo tipo de almacenamiento.

Cuando tienes en cuenta las necesidades de almacenamiento con Bigtable, no tienes que tener en cuenta las réplicas de almacenamiento, como sí harías al dimensionar un clúster de Cassandra. No se pierde densidad de almacenamiento para conseguir tolerancia a fallos, como ocurre en Cassandra. Además, como no es necesario aprovisionar el almacenamiento de forma explícita, solo se te cobra por el almacenamiento en uso.

SSD

La capacidad de 5 TB del nodo SSD, que es la opción preferida para la mayoría de las cargas de trabajo, ofrece una mayor densidad de almacenamiento en comparación con la configuración recomendada para las máquinas de Cassandra, que tienen una densidad de almacenamiento máxima práctica de menos de 2 TB por nodo. Cuando evalúes las necesidades de capacidad de almacenamiento, recuerda que Bigtable solo cuenta una copia de los datos. En comparación, Cassandra necesita tener en cuenta tres copias de los datos en la mayoría de las configuraciones.

Aunque el QPS de escritura de SSD es aproximadamente el mismo que el de HDD, SSD ofrece un QPS de lectura significativamente mayor que HDD. El almacenamiento SSD tiene un precio igual o similar al de los discos persistentes SSD aprovisionados y varía según la región.

HDD

El tipo de almacenamiento HDD permite una densidad de almacenamiento considerable: 16 TB por nodo. La contrapartida es que las lecturas aleatorias son significativamente más lentas, ya que solo se admiten 500 filas leídas por segundo en cada nodo. Se prefiere el HDD para cargas de trabajo con un uso intensivo de escritura en las que se espera que las lecturas sean análisis de intervalos asociados al procesamiento por lotes. El almacenamiento en HDD tiene un precio igual o similar al de Cloud Storage y varía según la región.

Consideraciones sobre el tamaño del clúster

Cuando dimensionas una instancia de Bigtable para preparar la migración de una carga de trabajo de Cassandra, debes tener en cuenta algunos aspectos al comparar clústeres de Cassandra de un solo centro de datos con instancias de Bigtable de un solo clúster, y clústeres de Cassandra de varios centros de datos con instancias de Bigtable de varios clústeres. En las directrices de las siguientes secciones se da por hecho que no es necesario hacer cambios significativos en el modelo de datos para migrar y que la compresión del almacenamiento es equivalente entre Cassandra y Bigtable.

Un clúster de un solo centro de datos

Cuando compare un clúster de un solo centro de datos con una instancia de Bigtable de un solo clúster, primero debe tener en cuenta los requisitos de almacenamiento. Para estimar el tamaño sin replicar de cada espacio de claves, puedes usar el comando nodetool tablestats y dividir el tamaño total de almacenamiento vaciado entre el factor de replicación del espacio de claves. A continuación, divide la cantidad de almacenamiento sin replicar de todos los espacios de claves entre 3,5 TB (5 TB * 0,70) para determinar el número sugerido de nodos SSD que se necesitan solo para gestionar el almacenamiento. Como se ha explicado, Bigtable gestiona la replicación y la durabilidad del almacenamiento en un nivel independiente que es transparente para el usuario.

A continuación, debes tener en cuenta los requisitos de computación del número de nodos. Puedes consultar las métricas del servidor y de la aplicación cliente de Cassandra para obtener un número aproximado de lecturas y escrituras sostenidas que se han ejecutado. Para estimar el número mínimo de nodos SSD que necesitas para llevar a cabo tu carga de trabajo, divide esa métrica entre 10.000. Probablemente necesites más nodos para las aplicaciones que requieran resultados de consulta con baja latencia. Google recomienda que pruebe el rendimiento de Bigtable con datos y consultas representativos para establecer una métrica de QPS por nodo que se pueda alcanzar con su carga de trabajo.

El número de nodos que necesita el clúster debe ser igual al mayor de los requisitos de almacenamiento y computación. Si no sabes con certeza qué almacenamiento o rendimiento necesitas, puedes comparar el número de nodos de Bigtable con el número de máquinas típicas de Cassandra. Puedes escalar un clúster de Bigtable verticalmente para adaptarlo a las necesidades de la carga de trabajo con un esfuerzo mínimo y sin tiempo de inactividad.

Un clúster de varios centros de datos

Con los clústeres de varios centros de datos, es más difícil determinar la configuración de una instancia de Bigtable. Lo ideal es que tengas un clúster en la instancia por cada centro de datos de la topología de Cassandra. Cada clúster de Bigtable de la instancia debe almacenar todos los datos de la instancia y debe poder gestionar la tasa de inserción total de todo el clúster. Los clústeres de una instancia se pueden crear en cualquier región de nube admitida del mundo.

La técnica para estimar las necesidades de almacenamiento es similar a la que se usa en los clústeres de un solo centro de datos. Utiliza nodetool para obtener el tamaño de almacenamiento de cada espacio de claves del clúster de Cassandra y, a continuación, divide ese tamaño entre el número de réplicas. Debes tener en cuenta que el espacio de claves de una tabla puede tener diferentes factores de replicación para cada centro de datos.

El número de nodos de cada clúster de una instancia debe ser suficiente para gestionar todas las escrituras del clúster y todas las lecturas de al menos dos centros de datos para mantener los objetivos de nivel de servicio (SLOs) durante una interrupción del clúster. Un enfoque habitual es empezar con todos los clústeres con la capacidad de nodos equivalente al centro de datos más activo del clúster de Cassandra. Los clústeres de Bigtable de una instancia se pueden escalar verticalmente de forma individual para adaptarse a las necesidades de la carga de trabajo sin que se produzcan periodos de inactividad.

Administración

Bigtable proporciona componentes totalmente gestionados para las funciones de administración habituales que se realizan en Cassandra.

Copia de seguridad y restauración

Bigtable ofrece dos métodos para cubrir las necesidades habituales de copias de seguridad: copias de seguridad de Bigtable y exportaciones de datos gestionadas.

Puedes considerar las copias de seguridad de Bigtable como una versión gestionada de la función de nodetoolcaptura de Cassandra. Las copias de seguridad de Bigtable crean copias restaurables de una tabla, que se almacenan como objetos miembros de un clúster. Puedes restaurar copias de seguridad como tablas nuevas en el clúster que inició la copia de seguridad. Las copias de seguridad están diseñadas para crear puntos de restauración si se produce un error a nivel de aplicación. Las copias de seguridad que crees con esta utilidad no consumen recursos de nodos y tienen precios iguales o similares a los de Cloud Storage. Puedes invocar copias de seguridad de Bigtable mediante programación o a través de la Google Cloud consola de Bigtable.

Otra forma de crear copias de seguridad de Bigtable es usar una exportación de datos gestionada a Cloud Storage. Puedes exportar los datos a los formatos de archivo Avro, Parquet o Hadoop Sequence. En comparación con las copias de seguridad de Bigtable, las exportaciones tardan más en ejecutarse y generan costes de computación adicionales porque usan Dataflow. Sin embargo, estas exportaciones crean archivos de datos portátiles que puedes consultar sin conexión o importar a otro sistema.

Modificando tamaño

Como Bigtable separa el almacenamiento y la computación, puedes añadir o quitar nodos de Bigtable en respuesta a la demanda de consultas de forma más fluida que en Cassandra. La arquitectura homogénea de Cassandra requiere que reequilibre los nodos (o vnodes) entre las máquinas del clúster.

Puedes cambiar el tamaño del clúster manualmente en la Google Cloud consola o de forma programática mediante la API Cloud Bigtable. Añadir nodos a un clúster puede proporcionar mejoras de rendimiento notables en cuestión de minutos. Algunos clientes han usado correctamente un escalador automático de código abierto desarrollado por Spotify.

Mantenimiento interno

El servicio Bigtable gestiona sin problemas las tareas de mantenimiento internas habituales de Cassandra, como la aplicación de parches del SO, la recuperación de nodos, la reparación de nodos, la monitorización de la compactación del almacenamiento y la rotación de certificados SSL.

Supervisión

Conectar Bigtable a la visualización de métricas o a las alertas no requiere ningún esfuerzo de administración ni de desarrollo. La página de la consola de BigtableGoogle Cloud incluye paneles de control prediseñados para monitorizar las métricas de rendimiento y utilización a nivel de instancia, clúster y tabla. Puedes crear vistas y alertas personalizadas en los paneles de control de Cloud Monitoring, donde las métricas están disponibles automáticamente.

Key Visualizer de Bigtable, una función de monitorización de la Google Cloud consola, te permite realizar ajustes de rendimiento avanzados.

IAM y seguridad

En Bigtable, la autorización está totalmente integrada en el framework de gestión de identidades y accesos deGoogle Cloudy requiere una configuración y un mantenimiento mínimos. Las cuentas y contraseñas de usuario locales no se comparten con las aplicaciones cliente. En su lugar, se conceden permisos y roles granulares a los usuarios a nivel de organización y a las cuentas de servicio.

Bigtable cifra automáticamente todos los datos en reposo y en tránsito. No hay ninguna opción para inhabilitar estas funciones. Todos los accesos administrativos se registran por completo. Puedes usar Controles de Servicio de VPC para controlar el acceso a las instancias de Bigtable desde fuera de las redes aprobadas.

Siguientes pasos

• Consulta información sobre el diseño de esquemas de Bigtable.
• Prueba el codelab sobre Bigtable para usuarios de Cassandra.
• Consulta información sobre el emulador de Bigtable.
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.