Introducción a
CockroachDB
Jordi Conesa i Caralt
Así en groso modo...
- Es un sistema gestor de base de datos NewSQL,
- A nivel de usuario sigue un modelo relacional,
- Garantiza las propiedades ACID,
- Es distribuida
- Permite autosharding y fragmentación manual,
- Usa información geográfica para
- promocionar la localidad de datos, y
- Garantizar la disponilidad / consistencia por
área geográfica.
- Permite replicación, y
- Escala horizontalmente.
- Gestiona los fallos de red de forma automática
Índice
- Origen de CockroachDB
- Características de CockroachDB
- Geoparticionamiento en CockroachDB
- Aspectos de diseño
Los inicios de CockroachDB
- Nace el 2015,
- De 3 ex-empleados de Google
- Inspirada en Google Spanner,
- Y si está basada en Spanner, ¿Por qué crear una nueva
BD?
- Porque Spanner es un producto gestionado por
Google, alojado en su nube y, por lo tanto, no es de
código libre ni descargable ni instalable en entornos
cliente.
- CockroachDB se concibió como alternativa a Spanner
en un entorno más abierto y accesible.
01
Características de
CockroachDB
Características
- Modelo de datos
- Utiliza SQL estándar (estándares ANSI SQL),
- Utiliza el protocolo de conexión de PostgreSQL,
- Utiliza las estrategias de optimización clásicas de los
entornos relacionales.
- A nivel transaccional
- Prima la consistencia antes que la disponibilidad
(consistencia fuerte),
- Garantiza las propiedades ACID (serializable).
- A nivel distribuido
- Ofrece escalabilidad horizontal,
- Ofrece una fragmentación / replicación sensibles a la
ubicación (usando zonas y regiones),
- Ofrece alta disponibilidad,
- Ofrece opciones de optimización adicionales.
- Portabilidad: se puede instalar en cualquier entorno.
Opciones de alojamiento
- Serverless
- Gestionado por Cockroach Labs,
- Acceso como un servicio de la nube,
- Pago por peticiones y almacenamiento
- A día de hoy gratuito hasta 50 millones de
peticiones y 10 GiB de almacenaje.
- Self-hosted
- Desplegable en un entorno propio,
- Existen descargables y ejecutables para Windows, Mac
y Linux,
- Existe una imagen Docker en Docker Hub.
- Cluster dedicado
- Gestionado por Cockroach Labs.
- ¡No se puede utilizar si se ofrece como un servicio!
Estructura interna de los datos
- Los datos se almacenan internamente siguiendo un modelo
clave-valor.
Arquitectura de distribución y replicación
- Utiliza autosharding para distribuir la información de la
base de datos en diferentes nodos,
- Da cierto margen al administrador de la base de
datos para indicar:
- la ubicación de los fragmentos o
- la ubicación de las réplicas destacadas.
- Respecto a la gestión de las réplicas, utiliza un sistema
de quórum basado en el algoritmo Raft.
Arquitectura de distribución
- Por defecto el tamaño de los fragmentos es de
- Un máximo de 512 MB y
- Un mínimo de 128 MB
- Cada fragmento contiene un conjunto de registros ordenado
alfabéticamente por su clave (fragmentación horizontal)
- Cada fragmento puede estar replicado
- El conjunto de réplicas de un fragmento se denomina
grupo de réplicas
Arquitectura de distribución
- Facilita las búsquedas por valor y por rango de la clave
primaria
Gestión de réplicas
- Utiliza el protocolo Raft para consensuar las escrituras
- Utiliza una arquitectura P2P
- Utiliza quórums para garantizar consistencia fuerte
- Un mínimo de 3 réplicas por fragmento,
- El número máximo de caídas que el sistema puede
tolerar es (N-1)/2,
- Si un nodo cae, se escoge otro para gestionar sus
réplicas.
Gestión de réplicas: configuración
- Las réplicas pueden tener un rol
- Líder (leaseholder): recibe las operaciones de lectura y
escritura.
- Seguidor (follower): pueden contener datos obsoletos en
caso de caídas de red.
- La réplica líder y sus seguidores mantienen un contacto
directo de forma periódica (heartbeat)
- ¿Cómo se configura un clúster? Al inicio de la configuración
de un clúster:
1. Todas las réplicas tienen el rol de seguidor,
2. Algunas réplicas se pueden postular como candidatos,
3. Las réplicas votan quien será el líder,
4. Al llegar al consenso, se asigna el rol de líder a la réplica
líder y el resto vuelven a ser seguidores.
Gestión de réplicas: funcionamiento
- Ante una operación de lectura
- La réplica líder recibe y resuelve la operación
mediante la información local
- Ante una operación de escritura
1. La réplica líder recibe la petición,
2. Promueve su escritura síncrona al resto de
réplicas,
3. Cuando la mayoría escribe el valor se acepta la
operación.
- Ante una caída de red
○ Si los nodos seguidores no reciben su
correspondiente heartbeat, se inicia una votación
para escoger un nuevo líder.
02
Geoparticionamiento
Despliegue multiregión
- Permite distribuir los datos considerando la ubicación
geográfica de los nodos à geoparticionamineto
- Promueve la localidad de datos
- La localidad definida tendrá un gran impacto en:
- La disponibilidad, escalabilidad de la base de datos,
- La latencia de sus operaciones, y en general
- la optimización de la base de datos.
- Región y zona:
- Región: área geográfica amplia que distinguimos del
resto de regiones.
- Zonas de disponibilidad: constituidas por centros de
datos ubicados en una región.
- Toda base de datos tiene una región primaria.
Despliegue multiregión
Configuración de disponibilidad
- La disponibilidad en CockroachDB se denomina objetivo de
supervivencia.
- Debe configurarse a nivel de base de datos
- Básicamente hay dos opciones:
- Supervivencia a nivel de zona
- Los datos continúan siendo accesibles en la región
local aunque las otras regiones hayan caído
- Por defecto usan 3 réplicas.
- Supervivencia a nivel de región
- Los datos continúan siendo accesibles aunque
caigan uno o más nodos de cualquiera de las
regiones.
- Por defecto usan 5 réplicas.
Supervivencia a nivel de zona
Supervivencia a nivel de región
¿Cómo gestionar la localidad de datos?
- CockroachDB permite distintas optimizaciones para
promover la localidad de datos y minimizar la latencia de las
operaciones:
- Definir una región por tabla (regional table)
- Distribuir filas entre distintas regiones (regional rows)
- Definir tablas globales (global table)
- Realizar lecturas locales (follower read)
Definir una región por tabla
- Se asigna una región a cada tabla.
- Las réplicas líder de la tabla se ubican en la región de
interés.
- Impacto en las operaciones:
- Lecturas locales à Rápidas
- Escrituras locales à Medianas
- Lecturas no locales à Lentas
- Escrituras no locales à Lentas
Distribuir filas entre distintas regiones
- Distribuye las filas de una tabla en diferentes regiones,
simulando el proceso de fragmentación horizontal.
- La tabla tendrá un atributo que indicará la región a la que se
debe asignar cada fila.
- El rendimiento es parecido al de las tablas locales pero
permite una localidad de datos distinta para cada registro
(más flexibilidad):
- Lecturas locales à Rápidas
- Escrituras locales à Medianas
- Lecturas no locales à Lentas
- Escrituras no locales à Lentas
Realizar lecturas locales (Follower reads)
- El hecho de asignar regiones a las tablas (o filas) puede
penalizar las lecturas que se hagan en regiones distintas a la
de la réplica líder.
- Para realizar una lectura más rápida (o más disponible) se
puede realizar una lectura de una réplica de la región local,
aunque no sea una réplica líder.
- El valor obtenido puede ser inconsistente (obsoleto),
- Una lectura podría generar problemas en la gestión de
concurrencia (rechazar operaciones concurrentes)
- Para evitar interferencias se lee un valor antiguo de
base de datos (stale read)
Definir una tabla de tipo global
- Las follower read permiten lecturas locales a réplicas de tipo
seguidor pero penalizan la consistencia
- Para promover lecturas locales manteniendo la
consistencia se utilizan tablas de tipo global.
- Para ello, se define un marca de tiempo a futuro hasta la que
no se permitirán escrituras. Así, durante ese tiempo, se
pueden realizar lecturas de forma local y consistente en
todas las regiones.
- Mejoramos la velocidad de respuesta de las lecturas a costa
de la velocidad de lectura de las escrituras:
- Lecturas à Rápidas
- Escrituras à Lentas
02
Aspectos de diseño
Aspectos de diseño a considerar
- No utilizar claves primarias autogeneradas (ordenadas)
- Pueden generar hotspots (nodos muy sobrecargados)
- Utilizar UUID o claves compuestas cuando sea posible
- Utilizar índices cuando sea necesario
- En los casos clásicos,
- Para indexar arrays i documentos JSON
- ¡OJO! Sólo permite consultas por valor
- Utilizar columnas computadas
- Pueden ser materializadas
- Para crear valores derivados o acceder a datos de un
array / JSON de forma más eficiente
Referencias
- Cockroach Labs. (2024). CockroachDB Docs.
https://www.cockroachlabs.com/docs/stable
- Seldess, J., Darnell, B., & Harrison, G. (2022). CockroachDB: the Definitive
Guide: Distributed Data at Scale. O’Reilly Media.
- Reid, R. (2022). Practical CockroachDB: Building Fault-Tolerant Distributed
SQL Databases. Apress.
- Rajanna, K. D. K. (2022). Getting Started with CockroachDB: A Guide to
Using a Modern, Cloud-native, and Distributed SQL Database for Your
Data-intensive Apps. Packt Publishing.
Un ejemplo de cómo el modelo relacional
y la consisténcia puede hacerse
extensible en entornos altamente
distribuidos y replicados
[email protected]
jconesac.wordpress.com/
