El rendimiento de la base de datos es un negocio serio, pero ¿por qué no divertirse un poco explorando sus desafíos y complejidades? 😉 Aquí hay una historia bastante fantasiosa que presentamos en el Capítulo 1 de Rendimiento de la base de datos a escalaun libro de acceso abierto gratuito.
Los temas técnicos cubiertos aquí se amplían en todo el libro. Pero esta es la única vez que hablamos del pobre Patrick. Deje que sus luchas te traigan algunas lecciones valiosas, consuelo en tus propios predicamentos de rendimiento de la base de datos … y tal vez algunas risas también.
***
Después de perder su trabajo en una compañía Faang Maang (Manga?), Patrick decidió atacar por su cuenta y fundó una tienda en línea de nicho dedicada a comerciar su favorito absoluto entre los sombreros, Inexperienced Fedoras. Al darse cuenta de que una cierta base de datos NoSQL estaba recientemente en la primera página de Hacker Information, Patrick lo eligió para su pila de backend.
Después de una experimentación con el nivel gratuito de la oferta, Patrick decidió firmar un contrato de un año con un importante proveedor de la nube para obtener un descuento significativo en su oferta de base de datos NoSQL como servicio. Con un rendimiento aprovisionado capaz de servir hasta 1,000 clientes cada segundo, la pila de tecnología estaba lista y la tienda abrió sus puertas virtuales a los clientes. Para la decepción de Patrick, menos de diez clientes visitaron el sitio todos los días. Al mismo tiempo, el nuevo clúster de base de datos brillante seguía funcionando, alimentado por una afluencia constante de dinero de su tarjeta de crédito y esperando que su potencial se aproveche.
El diario de lecciones de Patrick aprendió, Parte I
Las lecciones comenzaron de inmediato:
- Aunque algunas bases de datos se anuncian a sí mismas como universales, la mayoría de ellos funcionan mejor para ciertos tipos de cargas de trabajo. El análisis antes de seleccionar una base de datos para sus propias necesidades debe incluir estimar las características de su propia carga de trabajo:
- ¿Es possible que sea un flujo de solicitudes predecible y constante (por ejemplo, actualizaciones de otros sistemas periódicamente)?
- ¿La varianza es alta y difícil de predecir, con el sistema inactivo durante períodos de tiempo potencialmente largos, con baches ocasionales de actividad? Las ofertas de base de datos como servicio a menudo le permiten elegir entre el rendimiento aprovisionado y la compra a pedido. Aunque el primero es más rentable, incurre en un cierto costo independientemente de cuán ocupada esté realmente la base de datos. Este último cuesta más por solicitud, pero solo paga por lo que usa.
- Tómese el tiempo para evaluar su elección y evitar comprometerse con contratos a largo plazo (incluso si es atraído por un descuento) antes de ver que la configuración funciona para usted de manera sostenible.
El primer pico
El 17 de marzo parecía un día extremadamente afortunado. Patrick se complació en notar muchos pedidos nuevos a partir de la madrugada. Pero a medida que el número de clientes activos se disparó alrededor del mediodía, el estado de ánimo de Patrick comenzó a deteriorarse. Esto se correlacionó estrictamente con la tasa de llamadas que recibió de clientes enojados que informaron su incapacidad para proceder con sus pedidos.
Después de una breve sesión de lluvia de concepts con él y un motor de búsqueda net, Patrick se dio cuenta, para su consternación, que carecía de herramientas de observabilidad en su precioso (y bastante caro) clúster de base de datos. Poco después de configurar frenéticamente a Grafana y navegar por las métricas, Patrick vio que aunque el número de solicitudes entrantes mantenía creciendo, su tasa de éxito se limitó a un cierto nivel, muy por debajo del tráfico esperado de hoy.
“El rendimiento aprovisionado ataca nuevamente”, Patrick gimió para sí mismo, mientras se desplazó a través de miles de mensajes de error de “rendimiento excedido” que comenzaron a aparecer alrededor de las 11 a.m.
El diario de lecciones de Patrick aprendió, Parte II
Esto es lo que Patrick aprendió:
- Si su carga de trabajo es prone a los picos, prepárese para ello e intente arquitectar su clúster para poder sobrevivir una carga temporalmente elevada. Las soluciones de base de datos como servicio tienden a permitir la configuración del rendimiento aprovisionado de manera dinámica, lo que significa que el umbral de las solicitudes aceptadas ocasionalmente se puede elevar temporalmente a un nivel previamente configurado. O, respectivamente, permiten que disminuya temporalmente para que la solución sea un poco más rentable.
- Siempre espere picos. Incluso si su carga de trabajo es absolutamente estable, una falla temporal de {hardware} o un ataque de DDoS sorpresa pueden causar un fuerte aumento en las solicitudes entrantes.
- La observabilidad es clave en los sistemas distribuidos. Permite a los desarrolladores investigar retrospectivamente una falla. También proporciona alertas en tiempo actual cuando se detecta un escenario de falla possible, lo que permite a las personas reaccionar rápidamente y evitar que ocurran una falla mayor, o al menos minimizar el impacto negativo en el clúster.
La primera pérdida
Patrick ni siquiera logró recuperarse del trauma de perder la mayor parte de sus ingresos potenciales en el único día durante todo el año durante el cual Inexperienced Fedoras experimentó cualquier tipo de demanda, cuando llegó la carta. Incluyó una diatriba enojada de un posible cliente, que continuó con éxito con su pedido y lo pagó (con un recibo del operador de procesamiento de pagos como prueba), pero ahora no puede ver ningún detalle de su pedido, ¡y todavía está esperando la entrega!
Sin más preámbulos, Patrick navegó por la base de datos. Para su asombro, tampoco encontró ningún rastro de la orden. Para completar, Patrick también puso en práctica su ilusión al navegar por el directorio de instantáneas de respaldo. Permaneció vacío, ya que una de las decisiones ejecutivas iniciales de Patrick period ahorrar tiempo y dinero al no programar ningún procedimiento de respaldo periódico.
¿Cómo le sucedió la pérdida de datos, de todas las personas? Después de estudiar el modelo de consistencia de su base de datos de elección, Patrick se dio cuenta de que hay un consenso que hacer entre garantías de consistencia, rendimiento y disponibilidad. Al configurar las consultas, uno puede exigir LinealizabilityFootnote7 a costa del rendimiento disminuido, o reducir las garantías de consistencia y aumentar el rendimiento en consecuencia. Las capacidades de rendimiento más altas fueron obvias para Patrick hace unos días, pero en última instancia, los datos de los clientes aterrizaron en un solo servidor sin ninguna réplica distribuida en el sistema. Una vez que este servidor falló, lo que sucede al {hardware} sorprendentemente a menudo, especialmente a gran escala, los datos habían desaparecido.
El diario de lecciones de Patrick aprendió, Parte III
Otras lecciones incluyen:
- Las copias de seguridad son vitales en un entorno distribuido, y no existe la configuración de rutinas de copia de seguridad “demasiado pronto”. Los sistemas fallan, y las copias de seguridad están allí para restaurar la mayor cantidad de datos importantes posible.
- Cada sistema de bases de datos tiene un cierto modelo de consistencia, y es essential tenerlo en cuenta al diseñar su proyecto. Puede haber compromisos que hacer. En algunos casos de uso (piense en sistemas financieros), la consistencia es la clave. En otros, la consistencia eventual es aceptable, siempre que mantenga el sistema altamente disponible y receptivo.
El Spike ataca de nuevo
Pasaron los meses y el horario de sueño de Patrick incluso comenzaba a mostrar signos de estabilización. Con copias de seguridad regulares, un modelo de consistencia rediseñado y un recordatorio establecido en su calendario para el 16 de marzo para ampliar el clúster para gestionar el tráfico elevado, se sintió moderadamente seguro.
Si tan solo supiera que un video de diez segundos de un gato vestido como un duende se había vuelto viral en Malasia … que, teniendo en cuenta la zona horaria, ocurrió alrededor de las 2 de la mañana del tiempo, arruinando los esfuerzos de estabilización del sueño antes mencionados.
Por un lado, la suite de observabilidad hizo su trabajo y desencadenó una advertencia temprano, permitiendo una respuesta rápida. Por otro lado, a pesar de que Patrick reaccionó a tiempo, las bases de datos rara vez pueden escalar instantáneamente, y su sistema de elección no fue una excepción en ese sentido. El aumento en concurrencia fue muy alto y concentrado, ya que miles de adolescentes de Malasia se apresuraron a los sombreros verdes de compra a granel en busca de tendencias de Web en constante cambio. Patrick pudo observar una instanciación de la vida actual de la ley de Little, que recordaba vagamente de sus días en la universidad. Con una fórmula bellamente concisa, L = λw, la ley se puede simplificar al hecho de que la concurrencia es igual a la latencia de los tiempos de rendimiento.
CONSEJO: Para aquellos que tienen problemas para recordar la fórmula, piense en unidades. La concurrencia es solo un número, la latencia se puede medir en segundos, mientras que el rendimiento generalmente se expresa en 1/s. Luego, es lógico razonar que para que las unidades coincidan, la concurrencia debe obtenerse multiplicando la latencia (segundos) por rendimiento (1/s). ¡De nada!
El rendimiento depende del {hardware} y naturalmente tiene sus límites (por ejemplo, no puede esperar que una unidad NVME comprada en 2023 le sirva los datos en terabytes por segundo, aunque estamos cruzando los dedos para que esta suposición se invalida en el futuro cercano. Entonces está claro que a medida que aumenta la concurrencia, también lo hace la latencia. Para los usuarios finales, los adolescentes de Malasia en este escenario, significa que la latencia finalmente cruzará la barrera mágica para la percepción humana promedio de unos pocos segundos. Una vez que eso sucede, los usuarios se sienten demasiado frustrados y simplemente se dan cuenta de intentarlo por completo, suponiendo que el sistema se rompa fuera de la reparación. Es fácil encontrar artículos en línea citando que “Amazon descubrió que 100 ms de latencia les cuestan un 1 por ciento en ventas”; Aunque suena demasiado simplificado, también es bastante cierto.
El diario de lecciones de Patrick aprendió, Parte IV
Las lecciones continúan:
- Los picos inesperados son inevitables, y escalar el grupo podría no ser lo suficientemente rápido como para mitigar los efectos negativos de la concurrencia excesiva. Esperar que la base de datos la maneje correctamente no está exento de mérito, pero no todas las bases de datos son capaces de eso. Si es posible, limite la concurrencia en su sistema lo antes posible. Por ejemplo, si los clientes nunca tocan directamente la base de datos (lo cual es una muy buena thought por múltiples razones), sino que se accede a través de un conjunto de microservicios bajo su management, asegúrese de que los microservicios también sean conscientes de los límites de concurrencia y se adhieran a ellos.
- Tenga en cuenta que la ley de Little existe: es un conocimiento basic para cualquier persona interesada en sistemas distribuidos. Citar a menudo también te hace parecer excepcionalmente inteligente entre los compañeros.
Strikes de respaldo
Después de rediseñar su proyecto una vez más para tener en cuenta las fluctuaciones de concurrencia esperadas e inesperadas, Patrick esperó felizmente a que su negocio de Fedora finalmente se volviera ramen rentable.
Desafortunadamente, el próximo 17 de marzo tampoco fue tan bien como se esperaba. Patrick pasó la mayor parte del día disfrutando de los paneles de Grafana constantes, lo que le aseguró que el tráfico estaba bajo management y capaz de manejar la carga de clientes, con un margen seguro saludable. Pero luego los paneles se detuvieron, mencionando amablemente que los discos se superaron severamente. Esto parecía completamente fuera de lugar dada la concurrencia observada. Mientras buscaba la posible fuente de esta anomalía, Patrick notó, para su horror, que el procedimiento de respaldo programado coincidió con la carga máxima anual …
El diario de lecciones de Patrick aprendió, Parte V
Pensamientos finales:
- Los sistemas de bases de datos casi nunca están inactivos, incluso sin solicitudes de usuarios entrantes. Las operaciones de mantenimiento a menudo ocurren y debe tenerlas en consideración porque son una fuente interna de concurrencia y consumo de recursos.
- Siempre que sea posible, programen opciones de mantenimiento para los tiempos con baja presión esperada sobre el sistema.
- Si su sistema de gestión de bases de datos admite cualquier tipo de calidad de configuración de servicio, es una buena thought investigar tales capacidades. Por ejemplo, podría ser posible establecer una fuerte prioridad para las solicitudes de los usuarios sobre las operaciones de mantenimiento common, especialmente durante las horas pico. Respectivamente, se pueden utilizar períodos con baja actividad inducida por el usuario para acelerar las actividades de fondo. En el mundo de las bases de datos, los sistemas que utilizan una variante de los árboles LSM para el almacenamiento subyacente deben realizar un poco de compacciones (un tipo de operación de mantenimiento en los datos) para mantener el rendimiento de lectura/escritura predecible y estable.
El fin.
Sobre Piotr Sarna
Piotr es un ingeniero de software program interesado en los proyectos de código abierto y los idiomas de Rust y C ++. Anteriormente desarrolló un sistema de archivos distribuido de código abierto y tuvo una breve aventura con el núcleo de Linux durante un aprendizaje en Samsung Electronics. También es colaborador y mantenedor de Scylladb, así como LibsQL. Piotr se graduó de la Universidad de Varsovia con una maestría en informática. Es coautor del “rendimiento de la base de datos a escala” y “Escribir para desarrolladores: blogs que se leen”.
