Bigtable para usuarios de Aerospike

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

Para ayudarte a comenzar a trabajar con Bigtable y Aerospike, en este documento se hace lo siguiente:

  • Compara la terminología entre Aerospike y Bigtable.
  • Proporciona una descripción general de las operaciones de Bigtable y describe el diseño de los datos dentro de Bigtable.
  • Explica el modelado de datos y las consideraciones clave de diseño.
  • Se aclara cómo se realiza 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 Migración 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, operación y terminología.

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

Bigtable almacena datos en tablas escalables, cada una de las cuales es un mapa clave-valor ordenado. La tabla se compone de filas indexadas por claves de fila y columnas identificadas por un calificador de columna. Si se relacionan 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 quitar a través de la recolección de elementos no utilizados según las políticas configuradas.

Para obtener más información, consulta Modelo de almacenamiento de Bigtable.

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

Aerospike Bigtable
No hay ningún elemento que corresponda directamente. Instancia: Es un grupo administrado de clústeres en diferentes zonas o regiones de Google Cloud entre los que se producen la replicación y el enrutamiento de la conexión.
clúster: Es una implementación de Aerospike que consta de una colección de nodos. clúster: Es un grupo de nodos en las mismas Google Cloud zonas geográficas.
Nodo: Es un servidor que proporciona procesamiento y posee su almacenamiento. node: Es un servidor que solo proporciona procesamiento. El almacenamiento se controla con Colossus, un sistema de archivos distribuido independiente.
namespace: Almacena parámetros como el TTL o el tipo de almacenamiento. Dentro de un espacio de nombres, los datos se subdividen en conjuntos y registros. table: Es el equivalente más cercano a un espacio de nombres de Aerospike. Algunos parámetros se configuran para todas las tablas a nivel del clúster. Es posible tener un control más preciso a nivel de la tabla o la familia de columnas.
set: Se usa para la división lógica de registros y parámetros, como el TTL y el tamaño de la limitación. Las claves deben ser únicas dentro de un conjunto. No hay ningún elemento que corresponda directamente.
No hay ningún elemento que corresponda directamente. table: Es un recurso a nivel de la instancia que se replica automáticamente en cada clúster. 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: Es un rango continuo de filas almacenadas juntas. Bigtable usa tablets para el balanceo de cargas asignándolos a nodos. Los límites de las tabletas son dinámicos, ya que pueden dividirse o combinarse con el tiempo.
Registro: Es un conjunto de discretizaciones con nombre que se usan para almacenar datos. Puede tener un tamaño máximo de 8 MB. fila: Es un conjunto de valores identificados por la familia de columnas, el calificador de columna y la marca de tiempo. Todas las operaciones son atómicas a nivel de fila.
No hay ningún elemento que corresponda directamente. familia de columnas: Es un grupo de columnas ordenadas en orden lexicográfico. La recolección de elementos no utilizados se establece en este nivel.
bin: Es un par clave-valor en el que el nombre del bin es el identificador de un valor dentro de un registro. calificador de columna: Es una etiqueta para un valor almacenado en una tabla.
No hay ningún elemento que corresponda directamente. celda: Es una etiqueta para un valor con marca de tiempo almacenado en una tabla.
Resumen(registro): Es 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.
key: Es un identificador de registro único dentro de un conjunto. clave de fila: Es un identificador de fila, único dentro de una tabla.
AQL:Es una herramienta de línea de comandos para explorar datos y desarrollar funciones definidas por el usuario para la base de datos de Aerospike. GoogleSQL: Es un lenguaje de consultas que usan varios servicios de Google Cloud , incluidos Spanner, BigQuery y Bigtable.

Límites de 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: La cantidad máxima de espacios de nombres para la edición Enterprise es de 32. table: Una instancia puede tener hasta 1,000 tablas. El nombre de una tabla no puede superar los 50 caracteres.
set: Un clúster puede tener hasta 4,095 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 del registro es de 8 MB. fila: El tamaño máximo de la fila es de 256 MB.
No hay ningún elemento que corresponda directamente. Familia de columnas: La cantidad de familias de columnas es ilimitada, pero más de 100 pueden degradar el rendimiento.
Bin: La cantidad de bins es ilimitada. Sin embargo, cada bin no puede contener más de 1 MB de datos. El nombre del bin no puede superar los 15 bytes. Calificador de columna: El límite es de 100 MB, pero se recomienda no superar los 10 MB. La cantidad de columnas es ilimitada.
clave: El tamaño máximo de la clave es de 8 KB. clave de fila: El tamaño máximo de la clave de fila es de 4 KB.

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

Arquitectura

En las siguientes secciones, se proporciona 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 la durabilidad de los datos. Los clientes de tablas de Bigtable no conocen la distribución de datos subyacente. Una capa de enrutamiento adicional distribuye las solicitudes al nodo correcto. Cada nodo controla un subconjunto de las solicitudes al clúster. Una tabla de Bigtable se fragmenta en bloques de filas contiguas, llamados tablets, que se almacenan en Colossus, un sistema de archivos distribuido que proporciona alta durabilidad. Cada tablet se asocia con un nodo específico de Bigtable.

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 proporciona los siguientes beneficios:

  • Los clientes de Bigtable no necesitan conocer la distribución de datos ni el balanceo de cargas. La capa de enrutamiento se encarga de estas complejidades.
  • El reequilibrio se produce muy rápido y la recuperación de la falla es rápida porque los datos reales no se copian entre los nodos.
  • No se pierden datos cuando falla un nodo de Bigtable.

Aerospike

A diferencia de Bigtable, el almacenamiento de Aerospike se encuentra en los nodos que lo proporcionan. Todos los nodos (servidores) del clúster de Aerospike son idénticos. Los datos de cada espacio de nombres se dividen en exactamente 4,096 particiones a través del hash de los nombres de los registros. Estas particiones se distribuyen de manera uniforme entre los nodos.

Los nodos se conocen entre sí y reequilibran 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 cliente hagan un seguimiento de qué réplica 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 reequilibrio), los nodos la redireccionan.

Los clientes del clúster de Aerospike se comunican con los nodos que controlan 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 varios clústeres replicados. Una tabla siempre se replica en todos los clústeres de una instancia. Los clústeres se pueden agregar o quitar de una instancia con un impacto mínimo en otros clústeres.

Bigtable proporciona coherencia en la lectura de tus escrituras dentro de un solo clúster. Las escrituras se realizan en un solo clúster y, con el tiempo, se vuelven coherentes en los demás clústeres de la instancia. A diferencia de Aerospike, Bigtable no pierde actualizaciones intermedias porque las celdas individuales tienen versiones internas, lo que garantiza que no se pierda ninguna escritura. Cada clúster entrega las celdas que tienen disponibles las marcas de tiempo más actuales.

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

Aerospike

Aerospike controla la replicación dentro de un clúster a nivel de la partición. Un espacio de nombres se divide en particiones que se distribuyen de manera uniforme entre los nodos. Se garantiza una coherencia sólida dentro de 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 la sincronización de datos entre diferentes clústeres. La convergencia de contenedores de Aerospike garantiza 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 el registro de Aerospike requiere N+1 copias para controlar N fallas.

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 discretizaciones con tipos de valores variables. Del mismo modo, Bigtable admite columnas dispersas, por lo que no se consume almacenamiento para las columnas sin valores. Si bien no hay un límite estricto en la cantidad de columnas o familias de columnas, es mejor mantener la cantidad de familias de columnas por debajo de 100 por motivos de rendimiento.

Diseño de la clave de fila

Bigtable identifica las filas por claves de fila, que deben ser únicas dentro de una tabla. Se ordenan de manera lexicográfica y se mantienen juntos en las tabletas. Esto difiere de Aerospike, donde los registros se distribuyen entre los nodos según su hash. Las claves de fila deben diseñarse de manera que las filas a las que se accede con frecuencia juntas también se almacenen juntas.

Tipos de datos

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

La API de Bigtable se enfoca principalmente en el manejo 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 búsqueda también admite muchos tipos complejos, como los escalares, los objetos JSON y los discretizaciones de 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 incluir esos tipos en Bigtable, ya que todo se serializa del 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 recuperan juntas, y debe existir al menos una familia de columnas para cada tabla. Las columnas relacionadas deben agruparse en la misma familia. Los datos con diferentes requisitos de retención deben separarse en familias de columnas distintas, ya que las políticas de recolección de elementos no utilizados se aplican a nivel de la familia de columnas.

Calificadores de columnas

En Bigtable, los calificadores de columna se usan dentro de una familia de columnas para definir columnas individuales. Las tablas pueden admitir millones de columnas. Sin embargo, la práctica recomendada es limitar la cantidad de columnas en una sola fila. De manera opcional, los calificadores de columna se pueden tratar como datos, lo que permite que los valores se incorporen 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 la columna (una familia de columnas combinada con un calificador de columna). Cada celda contiene uno o más valores con marcas de tiempo que el cliente puede proporcionar o que el servicio aplica de forma automática.

Índices secundarios

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

Transacciones

Tanto Bigtable como Aerospike carecen de compatibilidad con transacciones de varias filas, pero difieren en sus capacidades de una sola fila. Bigtable proporciona escrituras completamente coherentes de una sola fila dentro de un clúster y admite transacciones de una sola fila a través de solicitudes de mutate-row. Permiten realizar varias operaciones en una sola fila, todas ejecutadas de forma atómica y todas se realizan correctamente o todas fallan. Además, existen operaciones de lectura, modificación y escritura, y de verificación y mutación, aunque estas no están disponibles con los perfiles de enrutamiento de varios clústeres. Por el contrario, Aerospike extiende las transacciones de una sola fila con la manipulación de datos del servidor y la ejecución de funciones definidas por el cliente.

Balanceo de cargas y conmutación por error

Aerospike usa Smart Client para controlar el balanceo de cargas del cliente. Es un proceso que se ejecuta del lado del cliente y que conoce el estado del clúster y la distribución de datos. Este cliente es responsable de enrutar la solicitud.

Si falla un nodo o se agrega uno nuevo, se debe volver a equilibrar el clúster. Se elige un nodo principal temporal para coordinar el acto de reequilibrar y redistribuir las particiones entre los nodos. Mientras eso sucede, el clúster sigue operativo, pero el cliente debe hacer un seguimiento de los cambios para el enrutamiento de solicitudes. Si una solicitud llega al nodo incorrecto, se enruta internamente al nodo 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. El enrutamiento de la solicitud lo controla la siguiente capa, un cliente grueso dentro de la infraestructura de Google CloudBigtable.

Otra diferencia es la política de enrutamiento, que no está disponible en Aerospike. Bigtable usa perfiles de aplicación para administrar el enrutamiento de solicitudes, con prioridades configurables para controlar el orden en el que se atienden las solicitudes. Existen dos tipos de políticas de enrutamiento: de un solo clúster y de múltiples clústeres. Un perfil de múltiples clústeres enruta las operaciones al clúster disponible más cercano. Los clústeres en la misma región se consideran equidistantes desde la perspectiva del router de la operación. Si el nodo responsable del rango de claves solicitado está sobrecargado o no está disponible temporalmente en un clúster, este perfil proporciona conmutación por error automática. En cambio, Aerospike no proporciona conmutación por error automática en caso de una falla completa del clúster.

Copia de seguridad y restablecimiento

Aerospike proporciona herramientas externas de copia de seguridad y restablecimiento llamadas asbackup y asrestore que crean copias de seguridad lógicas del cliente y son análogas a la realización de un análisis. La administración de copias de seguridad también se puede controlar a través de Aerospike Backup Service o Aerospike Kubernetes Operator, los cuales usan asbackup y asrestore de forma interna, y proporcionan programación y coordinación de varios procesos. Las copias de seguridad no son atómicas, lo que significa que es posible que no se capturen las operaciones de escritura que se producen durante la copia de seguridad.

Bigtable proporciona dos métodos para cubrir las necesidades comunes de copias de seguridad: las copias de seguridad de Bigtable y las exportaciones de datos administrados. Las copias de seguridad crean copias de una tabla que se pueden restablecer y que se almacenan como objetos miembros de un clúster. Puedes restablecer copias de seguridad como una tabla nueva en el clúster que inició la copia de seguridad. Estas copias de seguridad se diseñaron para crear puntos de restablecimiento si se produce una corrupción a nivel de la aplicación. Las copias de seguridad de Bigtable tampoco son atómicas. Es posible que se realicen cambios en una sección de la tabla que la copia de seguridad ya copió.

Diferencias clave en el manejo 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 quitar las copias de seguridad obsoletas. Dado que las copias de seguridad en Bigtable están completamente integradas, el servicio de Bigtable se encarga automáticamente de todas estas acciones.

Consideraciones de rendimiento

Debido a que Aerospike y Bigtable tratan las operaciones de lectura y escritura de manera 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 los lineamientos de rendimiento de Bigtable.

Consideración Bigtable Aerospike
Filas destacadas Distribuye las tablets y las operaciones para igualar el uso de recursos. Una fila a la que se accede con frecuencia se puede aislar en un tablet de una sola fila en un nodo, lo que limita el impacto en otras filas. Distribuye las filas según los hashes en todos los nodos, independientemente del tráfico. Una fila activa puede afectar el rendimiento de toda una partición.
Analiza las claves ordenadas Almacena los datos de forma lexicográfica, lo que lo hace muy eficaz para transmitir datos ordenados. Distribuye los registros según los hashes, por lo que analizar muchas claves consecutivas requiere consultar varios nodos y agregar resultados, lo que puede ser más lento. Admite índices secundarios, incluidos los tipos avanzados, lo que podría reducir la necesidad de realizar análisis.
Cómo insertar muchas claves consecutivas Almacena los datos de forma lexicográfica, lo que significa que un solo nodo controla muchas operaciones de escritura de claves consecutivas. Como resultado, un patrón de lectura o escritura puede terminar en el nodo que contiene la tablet responsable del final del espacio de clave de fila, lo que lo sobrecarga de manera efectiva. Distribuye las claves según el hash y distribuye la carga entre varios nodos cuando se escriben claves consecutivas.
Filas con una gran cantidad de columnas Si bien Bigtable admite filas de hasta 256 MB, el procesamiento de filas grandes puede afectar el rendimiento. Bigtable está optimizado para filas más pequeñas, por lo que la organización de las celdas y el acceso a los datos se deben tener en cuenta durante el diseño del esquema para evitar la propagación de datos en muchas celdas si no es necesario. Tiene un rendimiento inferior al óptimo cuando se encuentra con una fila o un registro con una gran cantidad de columnas o discretizaciones.
Inicios en frío Tiene un mejor rendimiento con tablas grandes a las que se accede con frecuencia. Si comienzas a enviar solicitudes después de un período sin uso (un inicio en frío), es posible que observes una latencia alta. Esto sucede porque la división en tablas y su distribución entre los nodos podría no ser óptima, y porque las memorias caché están frías. La distribución entre los nodos podría no ser completamente óptima hasta que transcurran unos minutos durante el inicio en frío y el rebalanceo. El rendimiento no cambia con el tiempo, ya que la distribución de datos no se basa en la carga. Si bien las cachés necesitan calentamiento, 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. Las tablas separadas se justifican para diferentes casos de uso o esquemas, pero no para datos similares, ya que no mejoran el balanceo de cargas y aumentan la sobrecarga de administración. La mayoría de los registros residen en un espacio de nombres, agrupados en conjuntos. Los conjuntos no tienen esquemas específicos, pero se pueden establecer índices secundarios o operaciones de análisis por conjunto. Dividir los datos en conjuntos no afecta el rendimiento.
Conjunto de datos grande 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 la tabla. 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 lograr latencias bajas, pero podría no ser factible para conjuntos de datos muy grandes. Por ejemplo, con 4,000 millones de objetos y un factor de replicación de 2 (RF2), la memoria consumida en asociación con el índice principal en todo el clúster en All Flash es de 2.5 GiB. Con el mismo ejemplo en 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.
Escalamiento El procesamiento y el almacenamiento están desacoplados y se pueden escalar de forma independiente. Un solo nodo puede controlar fragmentos de datos de varios cientos de terabytes o incluso petabytes. Almacenar índices en la RAM es fundamental para lograr latencias bajas. En ese caso, las máquinas deben escalarse verticalmente junto con la capacidad de almacenamiento para tener en cuenta el índice principal.

¿Qué sigue?