El rendimiento de la base de datos es un negocio serio, pero ¿por qué no tener un poco de diversión explorando sus desafíos y complejidades? 😉 Aquí está una historia bastante fantástica que presentamos en el capítulo 1 de . Performance at Scale, un libro de acceso abierto gratuito Desempeño de la base de datos a escala Desempeño de la base de datos a escala Los temas técnicos cubiertos aquí se extienden a lo largo del libro. Pero esta es la única vez que hablamos de pobre Patrick. Deje que sus luchas le traigan algunas lecciones valiosas, consuelo en sus propios predicamentos de rendimiento de la base de datos... y quizás también algunos chistes. * El Después de perder su empleo en una empresa FAANG MAANG (MANGA?) , Patrick decidió salir de su cuenta y fundó una tienda en línea de nicho dedicada a la negociación de su favorito absoluto entre los cabellos, los fedoras verdes. Después de experimentar con el nivel gratuito de la oferta, Patrick decidió firmar un contrato de un año con un proveedor de nube importante para obtener un descuento significativo en su oferta de base de datos NoSQL como servicio. Con un rendimiento previsto capaz de servir a hasta 1.000 clientes cada segundo, la pila de tecnología estaba lista y la tienda abrió sus puertas virtuales a los clientes. A la decepción de Patrick, menos de diez clientes visitaron el sitio diariamente. Al mismo tiempo, el brillante nuevo clúster de bases de datos continuó funcionando, alimentado por un flujo constante de dinero de su tarjeta de crédito y esperando que su potencial fuera aprovechado. Patrick’s Diary of Lessons Learned, Part I Diario de las lecciones aprendidas de Patrick, parte I Las clases comenzaron de inmediato: Aunque algunas bases de datos se anuncian como universales, la mayoría de ellas 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 la estimación de las características de su propia carga de trabajo: ¿Es probable que haya un flujo previsible y constante de solicitudes (por ejemplo, actualizaciones que se recogen de otros sistemas periódicamente)? ¿Es la variación alta y difícil de predecir, con el sistema estando vacío durante períodos potencialmente largos de tiempo, con ocasionales golpes de actividad? Las ofertas de base de datos como servicio a menudo te permiten elegir entre el rendimiento previsto y la compra a demanda. Aunque el primero es más rentable, incurre en un cierto coste independientemente de cuán ocupado sea la base de datos en realidad. Dale tiempo para evaluar su elección y evitar comprometerse a contratos a largo plazo (incluso si se atrae por un descuento) antes de ver que la configuración funciona para usted de una manera sostenible. El primer spike El 17 de marzo parecía un día extremadamente afortunado.Patrick estaba contento de notar un montón de nuevos pedidos a partir de la mañana temprana.Pero a medida que el número de clientes activos crecía 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 informando de su incapacidad para continuar con sus pedidos. Después de una breve sesión de brainstorming con él mismo y un motor de búsqueda web, Patrick se dio cuenta, a su desgracia, de que le faltaban herramientas de observación en su precioso (y bastante caro) clúster de bases de datos. Poco después de configurar frenéticamente Grafana y navegar por las métricas, Patrick vio que aunque el número de solicitudes entrantes siguió creciendo, su tasa de éxito se limitó a un cierto nivel, mucho por debajo del tráfico esperado de hoy. "El flujo provisto vuelve a golpear", gritó Patrick a sí mismo, mientras pasaba por miles de mensajes de error "excedido de flujo" que comenzaron a aparecer alrededor de las 11 de la mañana. Patrick’s Diary of Lessons Learned, Part II Diario de las lecciones aprendidas de Patrick, parte II Esto es lo que aprendió Patrick: Si su carga de trabajo es susceptible a picos, prepárate para ello y intenta arquitectar tu clúster para poder sobrevivir a una carga temporalmente elevada.Las soluciones de base de datos como servicio tienden a permitir configurar el rendimiento provisionado de manera dinámica, lo que significa que el umbral de solicitudes aceptadas puede ocasionalmente ser elevado temporalmente a un nivel previamente configurado.O, respectivamente, permiten disminuirlo temporalmente para hacer la solución un poco más rentable. Incluso si su carga de trabajo es absolutamente constante, un fallo temporal de hardware o un ataque DDoS sorpresa puede causar un aumento brusco en las solicitudes entrantes. La observabilidad es clave en los sistemas distribuidos. Permite a los desarrolladores investigar retrospectivamente un fallo. También proporciona alertas en tiempo real cuando se detecta un probable escenario de fallo, lo que permite a las personas reaccionar rápidamente y prevenir un fallo 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 el único día durante el año durante el cual los fedoras verdes experimentaron cualquier tipo de demanda, cuando llegó la carta. Incluía una indignación de un cliente potencial, que prosiguió 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 el envío! Sin más molestias, Patrick navegó por la base de datos. A su asombro, no encontró ningún rastro del pedido tampoco. Para ser completos, Patrick también puso en práctica su pensamiento deseoso navegando por el directorio de instantáneas de copia de seguridad. Permaneció vacío, ya que una de las decisiones ejecutivas iniciales de Patrick era ahorrar tiempo y dinero al no programar procedimientos de copia de seguridad periódicos. Después de estudiar el modelo de coherencia de su base de datos de elección, Patrick se dio cuenta de que hay un consenso entre las garantías de coherencia, el rendimiento y la disponibilidad. Al configurar las consultas, uno puede exigir linearizabilityFootnote7 al coste de la disminución del rendimiento, o reducir las garantías de coherencia y aumentar el rendimiento en consecuencia. Capacidades de rendimiento más altas fueron un no-brainer para Patrick hace unos días, pero finalmente los datos de los clientes aterrizaron en un solo servidor sin ninguna replicación distribuida en el sistema. Una vez que este servidor falló – lo que sucede a hardware sorprendentemente a menudo, especialmente a gran escala – los datos se habían ido. Patrick’s Diary of Lessons Learned, Part III Diario de las lecciones aprendidas de Patrick, parte III Otras lecciones incluyen: Las copias de seguridad son vitales en un entorno distribuido, y no hay tal cosa como establecer rutinas de copia de seguridad “demasiado pronto”. Cada sistema de bases de datos tiene un cierto modelo de coherencia, y es crucial tenerlo en cuenta al diseñar su proyecto.Puede haber compromisos a hacer.En algunos casos de uso (pensemos en sistemas financieros), la coherencia es la clave.En otros, la coherencia eventual es aceptable, siempre que mantenga el sistema altamente disponible y receptivo. Los Spike vuelven a atacar Con copias de seguridad regulares, un modelo de consistencia rediseñado y un recordatorio establecido en su calendario para el 16 de marzo para escalar el clúster para gestionar el tráfico elevado, se sintió moderadamente seguro. Si solo supiera que un vídeo de diez segundos de un gato vestido de leproso había acabado de hacerse viral en Malasia... lo que, teniendo en cuenta el fuso horario, ocurrió alrededor de las 2 de la mañana de Patrick, arruinando los mencionados esfuerzos de estabilización del sueño. Por un lado, la suite de observación hizo su trabajo y lanzó un aviso temprano, permitiendo una respuesta rápida. Por otro lado, aunque Patrick reaccionó a tiempo, las bases de datos rara vez son capaces de escalar instantáneamente, y su sistema de elección no fue una excepción en este sentido. El pico en concurrencia fue muy alto y concentrado, ya que miles de adolescentes malayos se apresuraron a comprar sombreros verdes a granel en busca de tendencias de Internet en constante cambio. Con una fórmula hermosamente concisa, L = λW, la ley se puede simplificar al hecho de que la concurrencia equivale a la latencia de los tiempos de rendimiento. La ley de Little Para aquellos que tienen dificultades para recordar la fórmula, piensen en unidades.La concurrencia es sólo un número, la latencia se puede medir en segundos, mientras que el rendimiento se expresa generalmente en 1/s. Entonces, es razonable que para que las unidades coincidan, la concurrencia debe obtenerse multiplicando la latencia (segundos) por el rendimiento (1/s). Tipo de: Tipo de: La transmisión depende del hardware y, por supuesto, tiene sus límites (por ejemplo, no se puede esperar que una unidad NVMe comprada en 2023 sirva los datos para usted en terabytes por segundo, aunque estamos cruzando nuestros dedos para que esta suposición sea invalidada en un futuro cercano!) Una vez que el límite sea alcanzado, se puede tratar como constante en la fórmula. Es entonces claro que a medida que la concurrencia aumenta, también lo es la latencia. Para los usuarios finales – adolescentes malayos en este escenario – significa que la latencia finalmente va a cruzar la barrera mágica para la percepción humana promedio de unos segundos. Una vez que esto suceda, los usuarios se sienten demasiado frustrados y simplemente renuncian a intentar todo, asumiendo que el sistema está roto más allá de la reparación. Es fácil encontrar artículos en línea Patrick’s Diary of Lessons Learned, Part IV Diario de las lecciones aprendidas de Patrick, parte IV Las lecciones continúan: Los picos inesperados son inevitables, y la ampliación del clúster puede no ser lo suficientemente rápida como para mitigar los efectos negativos de la concurrencia excesiva. Esperar que la base de datos la maneje correctamente no es sin mérito, pero no todas las bases de datos son capaces de ello. Si es posible, limite la concurrencia en su sistema lo antes posible. Por ejemplo, si la base de datos nunca es tocada directamente por los clientes (que es una buena idea por múltiples razones) pero se accede a ella a través de un conjunto de microservicios bajo su control, 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 fundamental para cualquier persona interesada en los sistemas distribuidos.Citarlo a menudo también te hace parecer excepcionalmente inteligente entre los pares. El backup vuelve a golpear Después de rediseñar su proyecto una vez más para tener en cuenta las fluctuaciones de la concurrencia esperadas e inesperadas, Patrick esperó felizmente que su negocio de fedora finalmente se convirtiera en rentable. Desafortunadamente, el próximo 17 de marzo tampoco fue tan suave como se esperaba. Patrick pasó la mayor parte del día disfrutando de los dashboards de Grafana, lo que continuó asegurándole que el tráfico estaba bajo control y capaz de manejar la carga de los clientes, con un margen de seguridad saludable. Pero luego los dashboards se detuvieron, mencionando amablemente que los discos se volvieron severamente sobreutilizados. Esto parecía completamente fuera de lugar dada la concurrencia observada. Mientras buscaba la posible fuente de esta anomalía, Patrick notó, a su horror, que el procedimiento de copia de seguridad programado coincidía con la carga de pico anual... Patrick’s Diary of Lessons Learned, Part V Diario de las lecciones aprendidas de Patrick, parte V Reflexiones concluyentes: Las operaciones de mantenimiento a menudo ocurren y debes tenerlas en cuenta porque son una fuente interna de concurrencia y consumo de recursos. Siempre que sea posible, planifique las opciones de mantenimiento para los momentos de baja presión esperada en el sistema. Si su sistema de gestión de bases de datos admite cualquier tipo de configuración de calidad de servicio, es una buena idea investigar tales capacidades. Por ejemplo, podría ser posible establecer una fuerte prioridad para las solicitudes de usuario sobre las operaciones de mantenimiento regulares, especialmente durante las horas de pico. Respectivamente, los períodos de baja actividad inducida por el usuario se pueden utilizar para acelerar las actividades de fondo. En el mundo de las bases de datos, los sistemas que utilizan una variante de árboles LSM para el almacenamiento subyacente necesitan realizar bastante compacciones (una especie de operación de mantenimiento en los datos) para mantener el rendimiento de lectura/escritura previsible y estable. el final. Más sobre Piotr Sarna es un ingeniero de software que está interesado en proyectos de código abierto y los idiomas Rust y C++. Anteriormente desarrolló un sistema de archivos distribuidos de código abierto y tuvo una breve aventura con el núcleo de Linux durante un aprendizaje en Samsung Electronics. También es un colaborador de larga data y mantenedor de ScyllaDB, así como libSQL. Piotr se graduó de la Universidad de Varsovia con un máster en Ciencias de la Computación. Es coautor de los libros "Database Performance at Scale" y "Writing for Developers: Blogs that Get Read". Piotr
