Temporizadores recursivos para agregar documentos y reducir el coste total de propiedad con Couchbase Server 6.6

Por dónde empieza...

La IoT, los dispositivos Edge y NoSQL son tecnologías que han ganado popularidad en los últimos años. Permitiendo a la gente crear cómodamente aplicaciones pesadas de interacción, sin la preocupación de la estabilidad y la disponibilidad. Un problema con la libertad y flexibilidad de estas nuevas tecnologías es mantener el coste. Agregar documentos y reducir la huella de datos es un caso de uso común para aplicaciones analíticas y de escritura pesada. Couchbase 6.6 nos proporciona aún más herramientas para ayudarte a reducir tu TCO. Veamos dónde empezó el problema y cómo podemos usar el conjunto de herramientas de Couchbase para resolverlo.

Aplicaciones e interacciones

Recuerdo la época en que las aplicaciones solían ser sencillas, cuando se proponían alcanzar un objetivo simple. Por ejemplo, una aplicación para el comercio minorista que permitiera digitalizar el proceso de compra, evitando que la gente tuviera que desplazarse a su tienda local para realizar la misma tarea. Películas y música disponibles con sólo pulsar un botón, en lugar de tener que comprar CD o DVD en una tienda. La transformación digital inicial de casi todo supuso un enorme salto en la comodidad del consumidor y devolvió más tiempo a todo el mundo, y durante un tiempo este cambio bastó para mantenernos contentos. Cualquier problema técnico parecía menor porque quedaba eclipsado por la cantidad de comodidad que proporcionaba.

Sin embargo, hoy en día, el hecho de que un nuevo minorista "se digitalice" no es nada del otro mundo, ya que las expectativas ya están ahí, y lo que ahora preocupa a los consumidores son los pequeños detalles que antes se pasaban por alto. Esas cuestiones técnicas, antes menores, serán ahora la clave del éxito de cualquier aplicación. A medida que la transformación digital se integra en las actividades cotidianas de las empresas, las expectativas de estas aplicaciones y sistemas han aumentado, y seguirán haciéndolo.

Bases de datos

A medida que desarrollamos software para satisfacer estas altas expectativas de experiencia de usuario, proporcionamos más interacción entre el usuario final y la aplicación. Las aplicaciones más complejas van de la mano de un mayor número de interacciones. Este número cada vez mayor de interacciones necesitará una cantidad cada vez mayor de almacenamiento para registrarlas, y aquí es donde encajan nuestras bases de datos.

Al igual que las propias aplicaciones, hubo un tiempo en el que las bases de datos relacionales eran perfectas para almacenar la información de casi todos los sistemas, y eso nos satisfacía. Sin embargo, al igual que las expectativas de la experiencia del usuario habían empezado a aumentar, también lo hicieron las expectativas de la base de datos subyacente. Ahora almacenamos una cantidad exponencial de datos a medida que pasa el tiempo y empezamos a ver dónde la base de datos relacional tenía sus defectos. Más datos significa más almacenamiento y, esencialmente, "más base de datos". Los que estén familiarizados con las bases de datos relacionales sabrán que esto no es tan sencillo como teclear ++. Para empezar, hacer cualquier ajuste a una base de datos relacional a menudo conlleva tiempo de inactividad, el tiempo de inactividad en el mundo de hoy ya no es aceptable. No es fácil ampliar los nodos relacionales, por lo que nos limitamos a ampliarlos. El problema es que ampliarlos resulta costoso y tiene sus propias limitaciones. También cabría esperar un aumento lineal del rendimiento cuanta más potencia de cálculo y almacenamiento se escalara; sin embargo, no es así. Por si fuera poco, el enfoque de esquema forzado hacía que la arquitectura general fuera rígida, lo que dificultaba cualquier cambio en el conjunto de datos subyacente. En general, el coste total de propiedad de los sistemas relacionales era imposible de mantener, y en un mundo en el que la tecnología cambia a un ritmo cada vez más rápido, se puede entender por qué la base de datos relacional necesitaba su sustitución para estas aplicaciones altamente interactivas.

La idea de las tecnologías NoSQL empezó a aparecer. NoSQL incorporaba un enfoque distribuido, escalable y sin esquemas para almacenar la información. Ofrecía la posibilidad de ampliar y reducir la base de datos sin necesidad de tiempos de inactividad. No había restricciones en torno al conjunto de datos, lo que permitía un desarrollo rápido y flexible. El coste total de propiedad de estas bases de datos es mucho menor y más fácil de mantener, por lo que se adaptan mejor a las aplicaciones que requieren un alto nivel de interacción.

IoT y dispositivos periféricos

Una de las principales introducciones en el mundo del software fue el repentino auge de los dispositivos IOT y Edge. Estos dispositivos suelen consistir en una combinación de hardware y software de menor tamaño y pueden actuar como puntos de entrada a la pila tecnológica subyacente. Un ejemplo importante de estos dispositivos es el uso de sensores y la capacidad de registrar continuamente datos que pueden volver a introducirse en la base de datos. Las bases de datos NoSQL permiten que estos dispositivos se multipliquen y crezcan sin preocuparse por el escalado, la rigidez y la alta disponibilidad, que un modelo relacional tendría dificultades para proporcionar. En muchos de estos casos, la aplicación abarcaría un alto nivel de operaciones de escritura y la información se analizaría en una fase posterior.

Caso práctico

Ahora bien, aunque la capacidad de escalar cómodamente es un suspiro de alivio para la mayoría de los DBA, rápidamente nos encontramos con un problema común que todo el mundo intenta resolver, el aumento de los costes. La flexibilidad y la libertad de almacenar tantos datos como sea posible también tiene sus inconvenientes, por lo que el tamaño de estos clústeres puede descontrolarse rápidamente.

Si tomamos como ejemplo un equipo de Fórmula 1 durante una carrera, podrían tener sensores integrados en el coche registrando estadísticas al milisegundo, podrían tener cientos o incluso miles de estos sensores alrededor del coche a lo largo de cada carrera. Aunque las lecturas individuales serían pequeñas, el número total de documentos almacenados ascendería a millones, ¡y estoy siendo conservador! Una vez que tienen todos estos datos, necesitan realizar análisis casi en tiempo real, el resultado de estos análisis permitirá al equipo hacer ajustes a lo largo de la carrera y mejorar a medida que avanzan. El problema no surge en ninguno de los escenarios anteriores, pero cuando se observa el clúster que lo soporta, se puede ver cómo la cantidad de datos y el coste total de propiedad de esta base de datos se pueden ir rápidamente de las manos. Para este equipo de Fórmula 1, sin embargo, resulta que después de 15 minutos, la granularidad de las lecturas de los sensores en milisegundos ya no es tan necesaria y en su lugar están contentos de almacenar los promedios por segundo, después de una hora, están contentos de almacenar los promedios por minuto, este proceso se puede repetir tanto como sea necesario.

Por ejemplo, si observamos un conjunto de documentos que contienen múltiples lecturas de temperatura y presión, podríamos obtener un conjunto de documentos con el siguiente aspecto

Para reducir el conjunto de datos y comprimir la información que tenemos, podríamos agregar los resultados en matrices de documentos mucho más pequeños

Couchbase introdujo el servicio de eventos en la versión 5.5 que permite a las aplicaciones actuar sobre los datos subyacentes en el sistema, con lógica de programación JavaScript. Hay una herramienta útil en eventing llamada temporizadores que pueden retrasar la ejecución de la lógica. En el caso del equipo de Fórmula 1, podían utilizar estos temporizadores y llamar repetidamente a las funciones de eventing para agregar los documentos en un tiempo determinado, pero antes de la versión 6.6 esto resultaba difícil de repetir. Muchos de mis clientes han utilizado las tareas cron de Linux para programar dichas tareas y permitir que las funciones de eventos se ejecuten a intervalos regulares activándolas mediante llamadas externas a la API REST.

La versión 6.6 de Couchbase introdujo el temporizador recursivo. Permitiendo a los usuarios crear temporizadores dentro de la llamada de otro temporizador. En el punto de ejecución, la lógica agregaría los documentos dentro de un marco de tiempo dado y luego antes de salir, haría girar otro temporizador para repetir el proceso después de un período de tiempo.

Aunque parezca trivial, simplifica enormemente el proceso de recursividad y elimina la necesidad de utilizar tecnologías externas para conseguir algo que podría hacerse internamente.

Por lo tanto, puede que no sientas la necesidad de la agregación de documentos cuando empieces a utilizar una base de datos NoSQL. Para casos de uso intensivo de escritura o incluso cuando el coste total de propiedad empiece a aumentar, buscarás cualquier idea y respuesta que puedas encontrar para ayudar a reducir la cantidad de datos que estás almacenando, esperemos que esta entrada del blog y el nuevo temporizador recursivo puedan ser parte de tu solución.