No hace mucho tiempo, la industria de las bases de datos consistía en un puñado de proveedores. Las bases de datos eran principalmente relacionales y se ejecutaban en máquinas individuales. La alta disponibilidad se implementó a través de "clústeres" activos-en espera. Con un modelo de "ampliación vertical", se trataba principalmente de almacenamiento compartido (SAN o DRBD) o replicación asincrónica de registros para sincronizar el estado con un nodo en espera. En 2001, cuando comencé a trabajar con NDB Cluster (lo que más tarde se convertiría en MySQL Cluster), el concepto de mantener una base de datos completa en la memoria principal era extraño:"¿Qué sucede si apaga el servidor?". Distribuir una base de datos en varios servidores era preocupante:"tienes datos aquí y allá". Y la idea de una base de datos de código abierto para cargas de trabajo de misión crítica era ridícula.
Avance rápido 15 años y ahora tenemos docenas de proveedores de bases de datos en el mercado, en su mayoría de código abierto, diferentes modelos (valor clave, documento, gráfico, …) y distribuidos de forma predeterminada. Los datos residentes en la memoria son prácticamente la norma para lograr un alto rendimiento y una baja latencia. Tres de las 5 bases de datos más populares (según la clasificación de db-engines) son de código abierto (MySQL, PostgreSQL y MongoDB). Hoy en día, es más probable que administre una flota de servidores de bases de datos distribuidos en diferentes centros de datos. Es posible que incluso tenga algunas de sus bases de datos administradas por un proveedor de nube externo.
Entonces, ¿cómo es administrar bases de datos en 2018?
AUTOMATIZACIÓN
Con tantas tareas que administrar y solo un número limitado de horas en un día, uno estaría loco si hiciera las cosas manualmente.
La automatización es una gran manera de hacer las cosas. Cuando teníamos pocas bases de datos para administrar, operar la base de datos sería muy práctico, con algunas tareas programadas en algo como bash o perl, por ejemplo, una secuencia de comandos para hacer una copia de seguridad de la base de datos, otra para mover los archivos de copia de seguridad a alguna ubicación. La conmutación por error sería manual e incluso estaríamos debatiendo si debería automatizarse o no.
Hoy en día, la automatización es una obviedad. Hay una serie de sistemas de administración de configuración o automatización de TI que se pueden aprovechar:Puppet, Chef, Ansible y Salt ofrecen marcos de trabajo de propósito general que se pueden usar para crear automatización para diferentes topologías de bases de datos. El software de administración de clústeres escrito específicamente para administrar configuraciones de bases de datos incluye MongoDB Ops Manager y ClusterControl. Permiten que los equipos de operaciones administren sus clústeres con algo que está disponible en el mercado. Crear un sistema de gestión de clústeres desde cero utilizando un sistema de gestión de configuración no es poca cosa. Requiere una experiencia significativa en la herramienta de automatización, así como la comprensión de las operaciones de administración, como la programación y verificación de copias de seguridad, la conmutación por error automática con la reconfiguración posterior de los sistemas, la implementación de cambios de configuración, la aplicación de parches, la actualización o degradación de la versión, etc.
Y, por supuesto, está el auge de las plataformas de servicio DBaaS, donde la implementación, el estado, la conmutación por error, las copias de seguridad, etc., están controlados por software. Los proveedores de la nube son realmente muy buenos en la automatización. Amazon RDS es un excelente ejemplo de automatización de bases de datos a escala:automatiza la implementación, las actualizaciones de parches, las copias de seguridad, la restauración en un momento dado, el escalado de réplicas y la alta disponibilidad/conmutación por error.
MASCOTAS vs GANADO
En la década de los 90 y hasta el auge y la caída de las puntocom, Sun Microsystems y Oracle hicieron una fortuna vendiendo bases de datos escalables en grandes hardware SMTP. Agregue algo de almacenamiento SAN y software de conmutación por error de Veritas y obtendrá un clúster de conmutación por error activo-en espera de última generación para alta disponibilidad. Los servidores de bases de datos eran relativamente pocos en número, pero poderosos, ya que crecerían verticalmente. Se les dieron nombres (¡igual que usted nombra a sus mascotas!) y fueron atendidos por administradores de bases de datos.
Hoy en día, las bases de datos son baratas y funcionan bien en hardware básico. Hay muchos de ellos, y les damos números, como si fueran ganado. Si uno se rompe, podemos conseguir uno nuevo.
También es una nueva raza de ganado:¡ganado de código abierto! Tres de las cinco principales bases de datos, según db-engines, son todas de código abierto:poco a poco se están comiendo la cuota de mercado de los dos proveedores propietarios. El código abierto es el nuevo estándar del centro de datos, no solo para el sistema operativo sino también para las bases de datos.
https://db-engines.com/en/ranking ¿Entonces que significa esto para usted? Bueno, en el futuro, es más probable que administre una base de datos de código abierto, o incluso varias para aplicaciones que utilizan recopilaciones de datos heterogéneas. En un mundo de persistencia políglota y microservicios, el almacén de datos subyacente ahora está dictado por la naturaleza de los datos. Desde el punto de vista de la arquitectura, las bases de datos de instancia única con alta disponibilidad basada en disco están dando paso a clústeres que potencialmente se distribuyen en varios centros de datos.
¿Necesitamos un DBA?
El rol de DBA es especializado:se necesitan años de experiencia para convertirse en uno. En el pasado, cuando solo había un par de proveedores de bases de datos propietarios para elegir, tenía DBA especializados con un conjunto específico de habilidades y experiencia. También era necesario:las bases de datos como Oracle o SQL Server tienen conjuntos de funciones enormes, creados durante décadas. No son fáciles de manejar. Por lo general, se implementaban como la única base de datos para una aplicación y era necesario monitorearlos, hacer una copia de seguridad de los datos y resolver cualquier problema que se presentara. Estas tareas eran exactamente en lo que los DBA estaban aquí para enfocarse.
Sin embargo, en la última década, ha surgido una industria de bases de datos completamente nueva, con docenas y docenas de bases de datos de código abierto, así como servicios de bases de datos en la nube. Como vimos anteriormente, no es raro que una aplicación utilice un par de almacenes de datos diferentes. Pero las empresas rara vez tienen un DBA para estos almacenes de datos que utilizan. ¿Dónde encuentra un DBA de MongoDB o Cassandra o
Administrarlos sería solo otra tarea agregada a la lista de tareas pendientes del equipo SysAdmin o DevOps o Site Reliability Engineering (SRE). Y vemos hoy que muchas empresas no tienen DBA a tiempo completo. En cambio, la responsabilidad se distribuye entre los equipos, y las herramientas de automatización se utilizan cada vez más para encargarse de las tareas rutinarias del día a día. Para las bases de datos que se han trasladado a la nube, los aspectos operativos de cómo se almacenan los datos se subcontratan por completo al proveedor de la nube. Entonces, en lugar de trabajar en cómo almacenar datos, el equipo de operaciones ahora puede concentrarse en el uso de los datos.
Ciclo de vida de la base de datos
El ciclo de vida promedio de una base de datos solía ser mucho más largo de lo que es hoy. Una vez que eligió una plataforma de base de datos, eso fue todo. La decisión se tomaría entre dos o tres bases de datos relacionales, generalmente por el DBA o alguien más alto en la organización. La empresa encontraría el dinero para comprar licencias perpetuas. Una vez que se tomó la decisión, ahora tenía que vivir con ella durante los próximos 10 años o más. Las bases de datos eran monolíticas y las aplicaciones solían utilizar una sola base de datos compartida.
Hoy en día, en un mundo de contenedores, nube, microservicios y canalizaciones de CI/CD, no es raro que los desarrolladores tomen las decisiones tecnológicas, especialmente si se trata de una base de datos de código abierto que se puede descargar fácilmente u ofrecer como un servicio. sin tener que hablar con un representante de ventas o buscar presupuesto de la gerencia. Las organizaciones enfrentan el desafío de crear valor más rápido, por lo que la tasa de cambio en la infraestructura/aplicaciones ha aumentado drásticamente. Las bases de datos monolíticas ahora se dividen en múltiples bases de datos pequeñas, y cada base de datos administra datos de dominio para un microservicio individual. Con la variedad de productos de bases de datos disponibles hoy en día en el ecosistema de código abierto, los equipos tienen la opción y la libertad de moverse a un mejor almacén de datos. A medida que los servicios se ponen en marcha y se dan de baja, también siguen las bases de datos, aunque los datos en sí pueden archivarse o trasladarse a un lago de datos. En un panorama de infraestructura que es mucho más dinámico hoy en día, encontramos que nuestras bases de datos tienen vidas más cortas.
FUNCIÓN DE DBA
El DBA, tradicionalmente tanto el guardián como el guardián de la base de datos, atendería las necesidades de la base de datos de los diferentes equipos de aplicación/infraestructura de la organización. Cualquier cambio que requiera acceso o cambios a la base de datos requerirá los servicios del DBA. Sin embargo, las prioridades en conflicto y la falta de disponibilidad de DBA podrían significar que el proyecto se bloquearía/retrasaría y se produciría una fricción inevitable.
El alto costo de la colaboración y la rápida innovación/corto tiempo de comercialización no van bien juntos. Como vimos anteriormente, los microservicios son un ejemplo de cómo la infraestructura y los servicios de aplicaciones ahora están diseñados para desacoplarse tanto como sea posible. Las bases de datos se están automatizando cada vez más y el control de la base de datos está pasando a los desarrolladores o equipos de proyecto. Incluso cosas como los cambios de esquema no son tan pesados como solían ser. Eran mucho más difíciles en el contexto de una base de datos central para una aplicación monolítica. Dado que los datos se comparten entre diferentes componentes, los cambios de esquema deberían coordinarse y planificarse cuidadosamente, generalmente con meses de anticipación. Los DBA tuvieron un papel clave en la comprensión y realización de cambios. La dinámica es diferente hoy en día, donde la tasa de cambio es mucho más rápida. No es raro que los equipos de desarrollo impulsen cambios de código en producción semanal o diariamente, ¡o incluso varias veces al día! Las bases de datos necesitan actualizaciones constantes para mantenerse al día con los cambios de la aplicación, y estos son realizados por los desarrolladores. Algunas de las bases de datos más nuevas como MongoDB incluso lo hacen muy simple al tener un modelo sin esquema. Lo que significa efectivamente es que el esquema de la base de datos se está moviendo hacia el código de la aplicación.
Entonces, si todas las tareas básicas comunes se están automatizando, ¿qué pasará con el rol de DBA en el futuro? En lugar de centrarse en las tareas administrativas, el DBA funcionará más como un mentor para otros equipos de la organización. Las organizaciones necesitan comprender qué datos tienen y cómo se pueden utilizar esos datos. Después de todo, los datos son más valiosos cuando se comparten y se combinan con otros recursos, no solo cuando se almacenan. Schemaless suena genial, pero aún necesitamos realizar un seguimiento de nuestros datos, ya sea en la base de datos o en el código. La seguridad es un desafío, y las filtraciones de datos siguen empeorando. Entonces, si queremos que los datos vuelvan a ser excelentes, el DBA debe cambiar a un rol de asesor/habilitador horizontal que abarque a todos los equipos. Desde una perspectiva de competencia, el DBA moderno necesita comprender cómo diseñar sistemas distribuidos de alta disponibilidad e implementar sistemas de automatización eficientes para encargarse de las tareas mundanas. A medida que las empresas implementan infraestructura en la nube o incluso en entornos de contenedores, comprender cómo crear bases de datos escalables y de alta disponibilidad en estas plataformas garantizará la supervivencia del DBA.
Resumen
Estamos sentados en un cruce fascinante en la historia de la industria de las bases de datos, que ha pasado por una transformación masiva en las últimas 2 décadas. La siguiente tabla intenta resumirlo.
| A la antigua | Nueva forma | |
|---|---|---|
| ¿Cómo? | Manual con ayuda de scripts y herramientas/utilidades | Automatización vía software (puppet, chef, ClusterControl) o plataformas DBaaS. |
| ¿Qué? | Pocas instancias de base de datos importantes, mascotas en lugar de ganado | Flota de instancias virtualizadas, entorno de persistencia políglota |
| Quién | DBA especializados | “Todo el mundo”:DBA, SysAdmins, DevOps, Dev. |
| Rol de DBA | Rol vertical:DBA como guardián/guardián, céntrese en tareas administrativas tradicionales relacionadas con la logística de datos. | Rol horizontal:DBA como mentor con enfoque en los datos. Cambio hacia tareas no operativas como arquitectura, seguridad y estrategia de análisis/consumo/ajuste de datos. |
| Ciclo de vida | Vida útil a largo plazo, con cambios planificados de antemano | Vida útil de corto a mediano plazo, con una tasa de cambio mucho más rápida |
| Competencia | Base de datos, SO, almacenamiento | Base de datos, SO, almacenamiento, sistemas distribuidos, redes y seguridad, secuencias de comandos de automatización |
Me interesaría conocer su opinión sobre la gestión de bases de datos de código abierto y si ha visto las mismas tendencias. ¿Cómo han sido sus luchas o éxitos con OSDB en los últimos años? ¿Y qué prevé que suceda el próximo año?
Por supuesto, en Variousnines continuaremos trabajando para ayudar a facilitar la gestión y automatización de sus bases de datos de código abierto en el próximo año y más allá. Así que manténgase atento a las actualizaciones sobre eso a partir del próximo enero.
Pero mientras tanto, déjame saber tu opinión y ¡nos vemos en 2019!
Fotos de SoRad (Shutterstock) y Los Simpson; otras fotos son de sus respectivos dueños.
