Bigtable para usuarios de Aerospike

Este documento ayuda a los desarrolladores de software y a los administradores de bases de datos a migrar aplicaciones de Aerospike con Bigtable como base de datos. Utiliza tus conocimientos sobre Aerospike para describir los conceptos que debes comprender antes de migrar a Bigtable.

Para ayudarte a empezar a trabajar con Bigtable y Aerospike, este documento hace lo siguiente:

  • Compara la terminología de Aerospike y Bigtable.
  • Ofrece una descripción general de las operaciones de Bigtable y describe el diseño de los datos en Bigtable.
  • Explica el modelado de datos y las consideraciones de diseño clave.
  • Aclara cómo se lleva a cabo la replicación y cuál es su impacto.

Para obtener información sobre el proceso de migración y las herramientas de código abierto que puedes usar para completar la migración, consulta Migrar de Aerospike a Bigtable.

Comparación de terminología

Aerospike y Bigtable son bases de datos NoSQL distribuidas, pero difieren significativamente en su diseño, funcionamiento y terminología.

En Aerospike, los datos se almacenan en registros. Cada registro contiene uno o varios contenedores con nombre, junto con metadatos como el tamaño del registro (en bytes), el tiempo de vida (TTL) y la hora de la última actualización (LUT).

Bigtable almacena los datos en tablas escalables, cada una de las cuales es un mapa de clave-valor ordenado. La tabla se compone de filas indexadas por claves de fila y columnas identificadas por un calificador de columna. Si están relacionadas entre sí, las columnas pueden formar una familia de columnas. Esta estructura te permite almacenar varias versiones de un valor con la misma clave. Cada versión se identifica con una marca de tiempo única. Las versiones anteriores se pueden filtrar durante las operaciones de lectura o se pueden eliminar mediante la recogida de elementos no utilizados en función de las políticas configuradas.

Para obtener más información, consulta el artículo Modelo de almacenamiento de Bigtable.

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

Aerospike Bigtable
No hay ningún elemento que corresponda directamente. Instancia: grupo gestionado de clústeres en diferentes Google Cloud zonas o regiones entre los que se produce la replicación y el enrutamiento de conexiones.
Clúster: una implementación de Aerospike que consta de una colección de nodos. Clúster: grupo de nodos de las mismas Google Cloud zonas geográficas.
Nodo: un servidor que proporciona computación y tiene su propio almacenamiento. Nodo: un servidor que solo proporciona computación. El almacenamiento se gestiona mediante Colossus, un sistema de archivos distribuido independiente.
namespace: almacena parámetros como el TTL o el tipo de almacenamiento. En un espacio de nombres, los datos se subdividen en conjuntos y registros. Tabla: el equivalente más cercano a un espacio de nombres de Aerospike. Algunos parámetros se definen para todas las tablas a nivel de clúster. Se puede ejercer un control más preciso a nivel de tabla o de familia de columnas.
set: se usa para la división lógica de registros y parámetros, como el TTL y el tamaño máximo. Las claves deben ser únicas en un conjunto. No hay ningún elemento que corresponda directamente.
No hay ningún elemento que corresponda directamente. Tabla: un recurso a nivel de instancia que se replica automáticamente en todos los clústeres. Una tabla contiene un conjunto de valores identificados por claves de fila únicas. Las tablas son dispersas, lo que significa que no usan espacio adicional para almacenar columnas que no contienen ningún valor.
No hay ningún elemento que corresponda directamente. Tablet: un intervalo continuo de filas almacenadas juntas. Bigtable usa tablets para el balanceo de carga asignándolas a nodos. Los límites de las tabletas son dinámicos, por lo que pueden dividirse o combinarse con el tiempo.
Registro: conjunto de contenedores con nombre que se usa para almacenar datos. Puede tener un tamaño máximo de 8 MB. Fila: conjunto de valores identificados por familia de columnas, calificador de columna y marca de tiempo. Todas las operaciones son atómicas a nivel de fila.
No hay ningún elemento que corresponda directamente. Familia de columnas: grupo de columnas ordenadas alfabéticamente. La recolección de elementos no utilizados se define en este nivel.
bin: un par clave-valor en el que el nombre del contenedor es el identificador de un valor de un registro. Calificador de columna: etiqueta de un valor almacenado en una tabla.
No hay ningún elemento que corresponda directamente. Celda: etiqueta de un valor con marca de tiempo almacenado en una tabla.
Resumen(registro): un hash de una tupla de tres elementos que identifica un registro: espacio de nombres, conjunto y clave. No hay ningún elemento que corresponda directamente.
Clave: identificador de registro único en un conjunto. Clave de fila: identificador de fila único en una tabla.
AQL una herramienta de línea de comandos para buscar datos y desarrollar funciones definidas por el usuario para la base de datos Aerospike. GoogleSQL lenguaje de consulta que usan varios Google Cloud servicios, como Spanner, BigQuery y Bigtable.

Límites de los tipos de datos

En la siguiente tabla se comparan los límites de los tipos de datos que usan Aerospike y Bigtable:

Aerospike Bigtable
namespace: el número máximo de espacios de nombres de Enterprise Edition es 32. Tabla: una instancia puede tener hasta 1000 tablas. El nombre de una tabla no puede tener más de 50 caracteres.
Conjuntos: un clúster puede tener hasta 4095 conjuntos. El nombre de un conjunto no puede superar los 63 bytes. No hay ningún elemento que corresponda directamente.
Registro: el tamaño máximo de un registro es de 8 MB. Fila: el tamaño máximo de una fila es de 256 MB.
No hay ningún elemento que corresponda directamente. Familia de columnas: el número de familias de columnas es ilimitado, pero si hay más de 100, el rendimiento puede verse afectado.
Contenedores: el número de contenedores es ilimitado, pero cada contenedor no puede contener más de 1 MB de datos. El nombre del contenedor no puede superar los 15 bytes. Calificador de columna: el límite es de 100 MB, pero se recomienda no superar los 10 MB. El número de columnas es ilimitado.
Clave: el tamaño máximo de la clave es de 8 KB. Clave de la fila: el tamaño máximo de la clave de la fila es de 4 KB.

Para obtener más información sobre los límites de Bigtable y Aerospike, consulta las páginas Cuotas y límites y Límites y umbrales del sistema Aerospike, respectivamente.

Arquitectura

En las siguientes secciones se ofrece una descripción general de la arquitectura de Bigtable y Aerospike.

Bigtable

Los nodos de Bigtable están separados de la capa de almacenamiento, lo que significa que los nodos no afectan a la durabilidad de los datos. Los clientes de las tablas de Bigtable no conocen la distribución de datos subyacente. Una capa de enrutamiento adicional distribuye las solicitudes al nodo correcto. Cada nodo gestiona un subconjunto de las solicitudes al clúster. Una tabla de Bigtable se fragmenta en bloques de filas contiguas, denominados tablets, que se almacenan en Colossus, un sistema de archivos distribuido que ofrece una alta durabilidad. Cada tablet se asocia a un nodo de Bigtable específico.

Los clientes del clúster de Bigtable se comunican con los nodos a través de la capa de enrutamiento, que distribuye los datos al nodo correcto.

La arquitectura de Bigtable ofrece las siguientes ventajas:

  • Los clientes de Bigtable no tienen que conocer la distribución de datos ni el balanceo de carga. La capa de enrutamiento se encarga de estas complejidades.
  • El reequilibrado se produce muy rápido y la recuperación tras un fallo es rápida porque los datos reales no se copian entre nodos.
  • Cuando falla un nodo de Bigtable, no se pierden datos.

Aerospike

A diferencia de Bigtable, el almacenamiento de Aerospike se encuentra en los nodos que lo sirven. Todos los nodos (servidores) del clúster de Aerospike son idénticos. Los datos de cada espacio de nombres se dividen en exactamente 4096 particiones mediante el cifrado hash de los nombres de los registros. Estas particiones se distribuyen de forma uniforme entre los nodos.

Los nodos se conocen entre sí y vuelven a equilibrar las particiones almacenadas cuando cambia el clúster. Cada vez que se produce un cambio en el clúster, las réplicas eligen una réplica principal que coordina el reequilibrio. Se espera que las bibliotecas de cliente hagan un seguimiento de la réplica que almacena la partición principal y envíen solicitudes de escritura a las réplicas correctas. Si un cliente envía una solicitud al nodo incorrecto (esto puede ocurrir durante el reequilibrado), los nodos redirigen la solicitud.

Los clientes del clúster de Aerospike se comunican con los nodos que gestionan el reequilibrio de la carga de trabajo

Replicación

En esta sección se compara el proceso de replicación de Aerospike y Bigtable.

Bigtable

Una instancia de Bigtable puede constar de un solo clúster o de varios clústeres replicados. Una tabla siempre se replica en todos los clústeres de una instancia. Los clústeres se pueden añadir o eliminar de una instancia con un impacto mínimo en otros clústeres.

Bigtable ofrece coherencia inmediata (read-your-writes) en un solo clúster. Las escrituras se realizan en un solo clúster y, con el tiempo, se vuelven coherentes en otros clústeres de la instancia. A diferencia de Aerospike, Bigtable no pierde las actualizaciones intermedias porque las celdas individuales tienen versiones internas, lo que garantiza que no se pierda ninguna escritura. Cada clúster sirve las celdas que tienen las marcas de tiempo más recientes disponibles.

La API Bigtable ofrece un token de coherencia a nivel de tabla que se puede usar para verificar si todos los cambios realizados antes de la creación del token se han replicado por completo.

Aerospike

Aerospike gestiona la replicación en un clúster a nivel de partición. Un espacio de nombres se divide en particiones que se distribuyen de forma uniforme entre los nodos. La coherencia inmediata se garantiza en un clúster. Una operación de escritura se confirma solo después de que todas las réplicas del clúster la hayan reconocido.

La replicación entre centros de datos (XDR) se puede configurar para sincronizar datos entre diferentes clústeres. La convergencia de contenedores de Aerospike asegura que los datos sean los mismos en todos los centros de datos al final de la replicación, pero se pueden perder actualizaciones intermedias.

Para garantizar la durabilidad, el algoritmo de coherencia basado en listas de Aerospike requiere N+1 copias para gestionar N fallos.

Modelo de datos

En esta sección se comparan los modelos de datos que usan Bigtable y Aerospike.

Esquema flexible

Aerospike no aplica restricciones de esquema, lo que permite que cada registro tenga diferentes contenedores con distintos tipos de valores. Del mismo modo, Bigtable admite columnas dispersas, por lo que no se consume almacenamiento en las columnas sin valores. Aunque no hay un límite estricto en el número de columnas o familias de columnas, es mejor que el número de familias de columnas no supere las 100 por motivos de rendimiento.

Diseño de claves de las filas

Bigtable identifica las filas mediante claves de fila, que deben ser únicas en una tabla. Se ordenan lexicográficamente y se mantienen juntas en las tablets. Esto difiere de Aerospike, donde los registros se distribuyen entre los nodos en función de su hash. Las claves de las filas deben diseñarse de forma que las filas a las que se acceda con frecuencia se almacenen juntas.

Tipos de datos

Aerospike admite tipos de datos avanzados, como escalares, GeoJSON, HyperLogLogs, listas y objetos anidados. Estos tipos se pueden indexar y consultar con la ayuda de índices secundarios. Además, Aerospike proporciona APIs del lado del servidor que permiten realizar operaciones complejas en estos tipos de datos, como filtrar por geolocalización o manipular el contenido de las listas.

La API Bigtable se centra principalmente en la gestión de bytes sin procesar, con algunas excepciones. También usa de forma nativa INT64 para las marcas de tiempo y los contadores, que se pueden incrementar como una operación atómica. El lenguaje de consulta también admite muchos tipos complejos, como escalares, objetos JSON y contenedores HLL. Es posible que los tipos avanzados se admitan cada vez más en el futuro, pero, en el momento de escribir este documento, no hay forma de introducir estos tipos en Bigtable. Todo se serializa en el lado del cliente. Puedes usar la biblioteca de adaptadores de aerospike-migration-tools para serializar tus tipos de datos.

Familia de columnas

En Bigtable, las familias de columnas definen qué columnas de una tabla se almacenan y se recuperan juntas, y cada tabla debe tener al menos una familia de columnas. Las columnas relacionadas deben agruparse en la misma familia. Los datos con diferentes requisitos de conservación deben separarse en familias de columnas distintas, ya que las políticas de recogida de elementos no utilizados se aplican a nivel de familia de columnas.

Calificadores de columna

En Bigtable, los calificadores de columna se usan en una familia de columnas para definir columnas concretas. Las tablas pueden admitir millones de columnas, pero es recomendable limitar el número de columnas de una sola fila. Opcionalmente, los calificadores de columna se pueden tratar como datos, lo que permite insertar valores directamente en el nombre de la columna para ahorrar espacio.

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.

Índices secundarios

Las vistas materializadas continuas pueden actuar como índices secundarios asíncronos, lo que permite consultar tablas mediante diferentes patrones de búsqueda o atributos. Para obtener más información, consulta Crear un índice secundario asíncrono.

Transacciones

Bigtable y Aerospike no admiten transacciones de varias filas, pero se diferencian en sus funciones de una sola fila. Bigtable ofrece escrituras de una sola fila totalmente coherentes en un clúster y admite transacciones de una sola fila mediante solicitudes de mutación de filas. Permiten realizar varias operaciones en una sola fila, que se ejecutan de forma atómica. Todas se completan correctamente o todas fallan. Además, hay operaciones de lectura-modificación-escritura y de comprobación y mutación, aunque no están disponibles con los perfiles de enrutamiento multiclúster. Por el contrario, Aerospike amplía las transacciones de una sola fila con la manipulación de datos del lado del servidor y la ejecución de funciones definidas por el cliente.

Balanceo de carga y conmutación por error

Aerospike usa Smart Client para gestionar el balanceo de carga del lado del cliente. Proceso que se ejecuta en el lado del cliente y que conoce el estado del clúster y la distribución de los datos. Este cliente es el responsable de enrutar la solicitud.

Si falla un nodo o se añade uno nuevo, el clúster debe volver a equilibrarse. Se elige un nodo principal temporal para coordinar el proceso de reequilibrar y redistribuir las particiones entre los nodos. Mientras tanto, el clúster sigue operativo, pero el cliente tiene que monitorizar los cambios para enrutar las solicitudes. Si una solicitud llega al nodo incorrecto, se redirige internamente al correcto.

El cliente de Bigtable es un cliente ligero que oculta al usuario todas las complejidades, como el estado del clúster y la distribución de datos. La siguiente capa, un cliente grueso dentro de la infraestructura de Google CloudBigtable, se encarga de enrutar la solicitud.

Otra diferencia es la política de enrutamiento, que no está disponible en Aerospike. Bigtable usa perfiles de aplicación para gestionar el enrutamiento de solicitudes, con prioridades configurables para controlar el orden en el que se atienden las solicitudes. Hay dos tipos de políticas de enrutamiento: de un solo clúster y de varios clústeres. Un perfil multiclúster dirige las operaciones al clúster disponible más cercano. Los clústeres de la misma región se consideran equidistantes desde la perspectiva 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 perfil proporciona una conmutación por error automática. Por el contrario, Aerospike no ofrece conmutación por error automática en caso de que falle todo el clúster.

Copia de seguridad y restauración

Aerospike proporciona herramientas externas de copia de seguridad y restauración llamadas asbackup y asrestore que crean copias de seguridad lógicas del lado del cliente y son análogas a la realización de un análisis. La gestión de copias de seguridad también se puede llevar a cabo a través de Aerospike Backup Service o Aerospike Kubernetes Operator, que usan asbackup y asrestore internamente, y proporcionan programación y coordinación multiproceso. Las copias de seguridad no son atómicas, lo que significa que es posible que no se registren las operaciones de escritura que se produzcan durante la copia de seguridad.

Bigtable ofrece dos métodos para cubrir las necesidades habituales de copias de seguridad: copias de seguridad de Bigtable y exportaciones de datos gestionadas. Las copias de seguridad 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 de Bigtable tampoco son atómicas. Es posible que se hagan cambios en una sección de la tabla que ya haya copiado la copia de seguridad.

Diferencias clave en la gestión de copias de seguridad

  • Las copias de seguridad de Aerospike se crean del lado del cliente. No requieren espacio adicional en el servidor, pero son más lentas. En Bigtable, una copia de seguridad comparte el almacenamiento físico con la tabla de origen y otras copias de seguridad de la tabla.
  • El usuario de Aerospike debe encargarse de exportar, almacenar y eliminar las copias de seguridad obsoletas. Como las copias de seguridad de Bigtable están totalmente integradas, el servicio Bigtable se encarga automáticamente de todas estas acciones.

Consideraciones sobre el rendimiento.

Como Aerospike y Bigtable tratan las operaciones de lectura y escritura de forma diferente, tienen diferencias de rendimiento que es importante tener en cuenta. En la siguiente tabla se incluyen varios ejemplos de diferencias de rendimiento entre las dos bases de datos. Para obtener más información, consulta las directrices de rendimiento de Bigtable.

Consideración Bigtable Aerospike
Filas activas Distribuye las tablets y las operaciones para igualar el uso de los recursos. Una fila a la que se accede con frecuencia se puede aislar en una tablet de una sola fila en un nodo, lo que limita el impacto en otras filas. Distribuye las filas en función de los hashes en todos los nodos, independientemente del tráfico. Una fila activa puede afectar al rendimiento de toda una partición.
Búsquedas en claves ordenadas Almacena los datos lexicográficamente, lo que lo hace muy eficaz para transmitir datos ordenados. Distribuye los registros en función de los hashes, por lo que, para analizar muchas claves consecutivas, es necesario consultar varios nodos y agregar los resultados, lo que puede ser más lento. Admite índices secundarios, incluidos los de tipo avanzado, lo que puede reducir la necesidad de realizar análisis.
Insertar muchas claves consecutivas Almacena datos lexicográficamente, lo que significa que un solo nodo gestiona muchas operaciones de escritura de claves consecutivas. Como resultado, un patrón de lectura o escritura puede acabar en el nodo que contiene la tablet responsable del final del espacio de claves de fila, lo que provoca una sobrecarga. Distribuye las claves en función del hash, lo que reparte la carga entre varios nodos al escribir claves consecutivas.
Filas con un número muy elevado de columnas Aunque Bigtable puede admitir filas de hasta 256 MB, el procesamiento de filas grandes puede afectar al rendimiento. Bigtable está optimizado para filas más pequeñas, por lo que se debe tener en cuenta la organización de las celdas y el acceso a los datos durante el diseño del esquema para evitar que los datos se distribuyan en muchas celdas si no es necesario. No funciona de forma óptima cuando se encuentra con una fila o un registro con un número muy elevado de columnas o contenedores.
Arranques en frío Funciona mejor con tablas grandes a las que se accede con frecuencia. Si empiezas a enviar solicitudes después de un periodo sin uso (un inicio en frío), es posible que observes una latencia alta. Esto ocurre porque la división en tablets y su distribución entre nodos puede que no sea óptima y porque las cachés están frías. La distribución entre nodos puede no ser totalmente óptima hasta que pasen unos minutos durante el arranque en frío y el reequilibrio. El rendimiento no cambia con el tiempo, ya que la distribución de datos no se basa en la carga. Aunque las cachés necesitan calentarse, los índices se mantienen en la memoria, lo que minimiza el tiempo de búsqueda en el disco y reduce la importancia del almacenamiento en caché.
Muchas tablas pequeñas Evita crear muchas tablas pequeñas. Se justifica el uso de tablas independientes para diferentes casos prácticos o esquemas, pero no para datos similares, ya que no mejora el equilibrio de carga y aumenta la sobrecarga de gestión. La mayoría de los registros se encuentran en un espacio de nombres, agrupados en conjuntos. Los conjuntos no tienen esquemas específicos, pero los índices secundarios o las operaciones de análisis se pueden definir por conjunto. Dividir los datos en conjuntos no afecta al rendimiento.
Conjunto de datos de gran tamaño Puede almacenar conjuntos de datos a escala de exabytes. El rendimiento no se ve afectado por el tamaño total del conjunto de datos debido a su arquitectura y a la división dinámica de tablets. Técnicamente, las bases de datos de Aerospike no tienen un límite de tamaño. Sin embargo, Aerospike almacena los índices y los registros por separado. Ambos tipos de datos se pueden almacenar en diferentes tipos de dispositivos de almacenamiento para aumentar el rendimiento. Almacenar índices en la RAM es fundamental para conseguir latencias bajas, pero puede que no sea viable en conjuntos de datos muy grandes. Por ejemplo, con 4000 millones de objetos y un factor de replicación de 2 (RF2), la memoria consumida en asociación con el índice principal en el clúster de All Flash es de 2,5 GiB. En el mismo ejemplo con una configuración de memoria híbrida, en la que el índice principal está en la memoria, se usarían 476,8 GiB de memoria.
Escalado El procesamiento y el almacenamiento están desacoplados y se pueden escalar de forma independiente. Un solo nodo puede gestionar fragmentos de datos de varios cientos de terabytes o incluso petabytes. Almacenar índices en la RAM es fundamental para reducir la latencia. En ese caso, las máquinas deben escalarse verticalmente junto con la capacidad de almacenamiento para tener en cuenta el índice principal.

Siguientes pasos