Base de datos nativa de Kubernetes: TiDB vs. Base de datos DataStax Astra

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB.

La revolución de la computación en la nube ha inspirado y se ha beneficiado de múltiples tendencias interrelacionadas. La disponibilidad de infraestructura de nube pública de autoservicio ha ayudado a impulsar la adopción de arquitecturas de microservicios y prácticas de DevOps, incluida la automatización y la observabilidad.

El impulso hacia la creación de contenedores y la orquestación de contenedores ha llevado a la adopción generalizada de Kubernetes como entorno para administrar aplicaciones nativas de la nube.

Pero una de las áreas rezagadas en esta revolución han sido los datos y la infraestructura de datos. Durante demasiado tiempo, los datos han sido algo que ha vivido fuera de Kubernetes, lo que ha generado mucho esfuerzo y complejidad adicionales para los desarrolladores a la hora de implementar aplicaciones nativas de la nube.

Un axioma muy repetido en los primeros años de Kubernetes era que aún no estaba listo para cargas de trabajo con estado. Afortunadamente, se ha producido un cambio importante que ha alcanzado un punto de madurez.

Inicialmente, la transformación ocurrió lentamente, comenzando con esfuerzos para contener las bases de datos existentes. Esto funcionó relativamente bien en bases de datos pequeñas que se ejecutaban en un solo nodo de cómputo, o bases de datos que habían sido diseñadas en un mundo nativo de la nube, como Apache Cassandra y DynamoDB, pero los desafíos persistieron.

En los últimos dos o tres años, ha surgido una nueva generación de bases de datos. Estas bases de datos "nativas de Kubernetes" se han diseñado desde cero para ejecutarse en este sistema de orquestación de código abierto.

Aquí, definiremos las cualidades que hacen que una base de datos sea nativa de Kubernetes y los beneficios de adoptar una base de datos nativa de Kubernetes. Para hacerlo, veremos dos bases de datos que reclaman la etiqueta nativa de Kubernetes: TiDB y DataStax Astra DB.

MySQL nativo de Kubernetes con TiDB

Primero, examinemos una base de datos con un énfasis relacional: TiDB (abreviatura de Titanium Database). TiDB es un sistema de código abierto creado por PingCAP que proporciona una base de datos compatible con MySQL y una base de datos en columnas para admitir el procesamiento transaccional y analítico híbrido (conocido como HTAP, para abreviar).

Como se muestra en la Figura 1 a continuación, TiDB tiene un diseño de microservicio. La capa de consulta TiDB, las bases de datos TiKV MySQL, las bases de datos en columnas TiFlash, los nodos Spark y la administración de metadatos se implementan como microservicios escalables en sus clústeres. Este diseño separa el trabajo intensivo en computación del trabajo intensivo en almacenamiento, ya que las capas de consulta y base de datos son escalables de forma independiente.

Un compromiso crítico que hicieron los creadores de TiDB fue que la base de datos solo se ejecuta en Kubernetes.

¿Es eso suficiente para que sea nativo de Kubernetes?

Profundicemos un poco más.

En primer lugar, un operador de Kubernetes implementa y administra TiDB mediante recursos personalizados (CRD). Los CRD de TiDB incluyen TiDBCluster, que le permite especificar el escalado y la configuración de cada microservicio y cómo los componentes de la capa de la base de datos utilizan el almacenamiento a través de los volúmenes persistentes de Kubernetes. Se utilizan CRD adicionales para implementar herramientas de monitoreo y administrar tareas operativas como respaldo y restauración.

TiDB también tiene una extensión de programador opcional que interactúa con el programador K8s predeterminado para tomar decisiones de programación más conscientes de la aplicación. Este énfasis en el uso de las capacidades existentes de Kubernetes donde estén disponibles es la marca de una base de datos nativa de Kubernetes.

Cassandra nativo de Kubernetes con DataStax Astra DB

Ahora, mire otra base de datos nativa de Kubernetes y observe algunas similitudes y diferencias.

Cassandra es una base de datos NoSQL altamente escalable que fue una de las primeras en afirmar ser nativa de la nube, pero ¿cómo se ve implementar Cassandra en Kubernetes?

DataStax Astra DB es una versión de Cassandra que se ha incluido en los microservicios, como se muestra en la Figura 2.

Al igual que TiDB, la base de datos incluye microservicios relacionados con el procesamiento de consultas y el almacenamiento de datos, así como servicios de control de acceso e identidad, reparación de datos y copia de seguridad/restauración.

Los servicios de datos son particularmente interesantes en su uso del almacenamiento , con volúmenes persistentes de Kubernetes que se usan solo para el almacenamiento en caché y el almacenamiento de objetos se usa para la persistencia a más largo plazo. La separación de la compactación en su servicio permite que este procesamiento de cómputo intensivo se realice en segundo plano sin afectar el rendimiento de los servicios de datos que atienden el tráfico de lectura y escritura.

Astra DB se ofrece como un servicio administrado disponible en varias regiones de la nube. Cada región contiene un plano de datos que consta de los servicios mencionados anteriormente, administrados por un operador de Kubernetes, así como servicios de infraestructura, incluida la pila Kube-Promethus para la observabilidad y etcd para la gestión de metadatos.

Los planos de datos son administrados por un plano de control que puede ejecutarse en una o más nubes para administrar cuentas y bases de datos de clientes y aprovisionar clústeres de Kubernetes en nuevas regiones.

Un aspecto novedoso de Astra DB es su arquitectura multiinquilino en la que múltiples bases de datos de usuarios pueden compartir los mismos microservicios e infraestructura de soporte, lo que reduce la economía de la unidad para usuarios de menor escala.

A medida que los usuarios hacen crecer sus aplicaciones, pueden pasar a recursos dedicados para lograr un rendimiento óptimo a escala, todo sobre una base de " pago por uso ".

Principios de la base de datos nativa de Kubernetes

Basándonos en nuestras observaciones de TiDB y Astra DB, podemos derivar algunas ideas de lo que hace que una base de datos sea nativa de Kubernetes. Muchos de estos corresponden a una lista de principios para datos nativos de la nube, que describí en un artículo anterior :

• Arquitectura de microservicio componible: en primer lugar, una base de datos dividida en microservicios constituyentes permite escalar cada servicio de forma independiente. Algunos tipos de procesamiento intensivo de cómputo pueden incluso escalarse a cero para una verdadera solución sin servidor, especialmente cuando se combinan con un diseño multiinquilino.
• Trate la computación, la red y el almacenamiento como productos básicos: los microservicios compuestos por una base de datos nativa de Kubernetes deben aprovechar al máximo las API de Kubernetes para administrar los recursos fundamentales de las aplicaciones nativas de la nube: recursos de computación como StatefulSets e implementaciones para administrar cargas de trabajo, el subsistema de volumen persistente para almacenamiento , ingreso de Kubernetes y servicios para exponer el acceso a la red a datos y más. Esto incluye aprovechar las capacidades que ya están presentes en Kubernetes, como etcd para la gestión de metadatos, en lugar de incorporar componentes con funciones duplicadas.
• Aproveche las mejores prácticas de Kubernetes: seguir patrones comunes para las aplicaciones de Kubernetes generará múltiples beneficios operativos, por ejemplo, exponiendo controles de actividad y preparación en cada microservicio para ayudar a la disponibilidad y exponiendo métricas a través de la API Prometheus PromQL para la observabilidad . De forma predeterminada, Kubernetes en sí mismo establece un gran ejemplo que las bases de datos deben seguir para estar seguras: usar Kubernetes Secrets para distribuir credenciales de seguridad, exponer solo los puertos según sea necesario, etc.
• Gestión declarativa a través de operadores: una base de datos nativa de Kubernetes debe incorporar los principios de Kubernetes de gestión declarativa a través de operadores y recursos personalizados, en lugar de depender de interfaces de usuario y CLI de gestión de bases de datos heredadas. Cuando sea necesario, los puntos de extensión de Kubernetes, como las extensiones del programador, se pueden usar para agregar un comportamiento específico de la aplicación . El objetivo es una clara separación de la funcionalidad del plano de datos (administración de datos) de la funcionalidad del plano de control (administración de la base de datos).

Las bases de datos y otras infraestructuras de datos que adopten fielmente estos principios generarán beneficios, incluido un alto rendimiento para un costo óptimo en todas las escalas , una menor complejidad operativa que resulta en un tiempo de comercialización más rápido y soluciones que cumplen con los estándares que cumplen con las demandas actuales de alta disponibilidad y seguridad.

El futuro de la infraestructura de datos nativos de Kubernetes

Todavía queda mucho por hacer, y no se limita solo a las bases de datos. Los principios nativos de Kubernetes se pueden aplicar a otros tipos de infraestructura de datos, incluida la transmisión, el análisis y el aprendizaje automático.

Las soluciones nativas de Kubernetes continuarán avanzando en las implementaciones de múltiples clústeres y múltiples nubes para escalar globalmente y adoptarán principios de tenencia múltiple y sin servidor para una mejor optimización de costos.

Kubernetes en sí tiene margen de mejora al agregar más flexibilidad a StatefulSets y soporte para la federación de múltiples clústeres.

La clave para el progreso continuo es la colaboración abierta. La comunidad de datos en Kubernetes es un grupo muy activo de fanáticos de los datos que reúne a los desarrolladores de aplicaciones de uso intensivo de datos y la infraestructura que las respalda.

Únase a nosotros para hablar sobre ideas como desarrollar operadores reutilizables que puedan administrar múltiples bases de datos o definir un conjunto común de CRD para conceptos como copia de seguridad/restauración y carga de datos. Juntos continuaremos ampliando el horizonte de la computación en la nube para el beneficio de todos.

Obtenga más información sobre las bases de datos nativas de Kassandra y más en la cumbre digital Cassandra Forward el 14 de marzo de 2023.

Este artículo se basa en el Capítulo 7, "La base de datos nativa de Kubernetes", del libro de O'Reilly " Gestión de datos nativos de la nube en Kubernetes " de Jeff Carpenter y Patrick McFadin.

[

Por Jeff Carpenter, DataStax

Jeff Carpenter ha trabajado como ingeniero y arquitecto de software en múltiples industrias y como defensor de los desarrolladores en DataStax, ayudando a los ingenieros a tener éxito con Apache Cassandra. Está involucrado en múltiples proyectos de código abierto en los ecosistemas de Cassandra y Kubernetes, incluidos Stargate y K8ssandra. Es coautor de los libros de O'Reilly "Cassandra: The Definitive Guide" y "Managing Cloud Native Data on Kubernetes".