https://www.siliconrepublic.com/people/women-in-technology-the-computer-girls-cosmopolitan

Let’s summarize the article👇:

Let’s go, Computer Girls! 🚀 Let’s go!

Características:

• ES usa documentos JSON y es ideal para trabajar con datos basados en JSON. La interacción con ES se realiza a través de una API RESTful, que permite realizar consultas a través de URL REST.

Comparación con bases de datos relacionales:

• A diferencia de las bases de datos relacionales, en las que los datos se organizan en bases de datos y tablas, ES utiliza índices para almacenar los datos.
• En lugar de filas y columnas, los datos se representan como documentos y campos, respectivamente.
• Comprender estos paralelismos ayuda en la transición de sistemas de bases de datos relacionales tradicionales como MySQL o PostgreSQL a ES.

Dado este resumen comparativo, pasemos a un ejemplo más visual que nos ayude a cementar los conceptos.

La unidad de información más simple en ES es el documento, representado como un archivo JSON. Los documentos forman índices, que son colecciones de documentos relacionados, como un «índice de aves» que contiene diferentes razas de aves.

¿Qué son los cluster y los nodos en ES?

ES funciona con clústeres y nodos, donde los clústeres son grupos de nodos (máquinas) que facilitan la comunicación y el almacenamiento de datos entre varios nodos para gestionar mayores volúmenes de documentos mediante el escalado horizontal.

Un cluster consta de varios nodos, cada uno con fragmentos primarios (P) y réplicas (R).

¿Qué son los shards en ES?

Un shard en Elasticsearch es una subdivisión de un índice. Cada índice se divide en múltiples shards para distribuir los datos y las solicitudes de búsqueda a través de varios nodos en un cluster.

Existen dos tipos de shards: primarios (En la imagen tenemos P0,P1 y P2), que almacenan los datos originales, y réplicas(En la imagen tenemos R2,R0 Y R1), que son copias de los shards primarios y proporcionan redundancia en caso de fallos de nodos.

¿A qué fallos de nodos te refieres?

Si un nodo falla debido a diversas razones (por ejemplo, desastres naturales, brechas de seguridad), las réplicas (copias de fragmentos) en diferentes nodos proporcionan una copia de seguridad, lo que permite la recuperación de la información.

¡Nunca se sabe cuándo vendrá el apocalipsis zombie en TEC! 🧟‍♂️ Así que, como buenos nerd scouts, estamos siempre listos 🤓🕶️.

¿Cómo el sharding mejora el performance de las búsquedas en ES?

Al permitir que ocurra simultáneamente en varios nodos.

ok 😵‍💫, en cristiano, ¿A qué me refiero?

El sharding, como se muestra en la imagen, distribuye los datos de un índice entre varios nodos (Node-1, Node-2, Node-3).

1. Paralelización de Consultas: Al distribuir los datos, las búsquedas se ejecutan en paralelo en cada shard, reduciendo el tiempo total de respuesta.
2. Balanceo de Carga: Cada nodo maneja solo una parte de la búsqueda, evitando que un solo nodo se sature con todas las consultas.

En este ejemplo, recordemos que nuestros shards primarios serían P0, P1 y P2.

Entonces, imaginemos que tenemos 1,000,000 de documentos (a.k.a Rows) y que al inicio sólo contábamos con 1 para procesar todo. 😱

Con sharding, en este ejemplo: dividimos un índice de un millón de documentos en tres nodos, cada uno almacenando un tercio. Antes, una búsqueda tomaba 10 segundos; con sharding, el tiempo se reduce a un tercio, ya que los tres nodos buscan en paralelo.

Pero ¡quejesto! ¿Es magia? 🔮

No… ¡es sharding!

Mic drop 🎤💥

Nota: Como no vivimos en el mundo de la pantera rosa, la elección del número de shards por índice requiere un análisis cuidadoso, ya que afecta por ejemplo a los costos (memoria, CPU, almacenamiento), etc.

En este ejercicio, nos enfocaremos en activar un Widget de encuesta cuando un usuario haya leído al menos tres reportes que contienen palabras clave específicas. Aunque ya hemos trabajado previamente con este Widget, esta será la primera vez que modifiquemos su comportamiento. Este desafío nos invita a reflexionar y considerar cuidadosamente cómo abordar el desarrollo, manteniendo un enfoque innovador y adaptativo.

Desarrollo:

¿Qué debemos considerar ?

Paso 1: Revisión y Persistencia de Datos

Para registrar la cantidad de reportes leídos por un usuario, hemos decidido añadir un atributo metadata de tipo JSON al modelo User. El key userReportsViewed se incorporará dentro de este atributo, permitiendo una gestión de datos flexible y estructurada. Esta elección nos evita tener que modificar la estructura de la base de datos con nuevas migraciones para cada tipo de dato que deseamos incorporar, facilitando así la adaptación a nuevas características y la recolección de feedback de los usuarios mediante encuestas. De esta manera, cada par key/value nuevo podría ser útil para cada encuesta de las funcionalidades futuras.

Paso 2: Actualización de Datos en GraphQL

Para la actualización de los datos, empleamos GraphQL, específicamente un archivo de mutaciones para las operaciones de creación, actualización y eliminación. Dentro del contexto de nuestro modelo User, utilizaremos user_mutation.rb.

a) Declaración de Datos: Primero, definimos el tipo de datos con los que trabajaremos, optando por no exponer los IDs por razones de seguridad y eligiendo, en su lugar, trabajar con las keys de los usuarios.

b) Implementación del Método Resolve: A continuación, implementamos el método resolve, la estructura/estrategia facilita la adición de nuevos operadores o la modificación de la lógica existente sin cambios significativos en el diseño general del método.

c) Declaración de la Nueva Mutación: Introducimos una nueva mutación denominada UpdateUserMetadataMutation y la declaramos en MutationType.

d) Integración en Queries de JS: Agregamos el metadata dentro de nuestras queries de JavaScript, anidadas dentro de otro modelo (Por privacidad no daremos detalles específicos de esto)

e) Exportación de la Mutación: Finalmente, exportamos nuestra mutación especificando el tipo de dato deseado y el resultado esperado del response de la petición en el frontend, como el status y el value.

3) Ahora sí, antes de implementar la petición en la vista de react, debemos importar la mutación de nuestra ruta.

Paso 3: Implementación en la Vista de React

Creamos un método llamado updateViewedReports, empleando todo lo desarrollado en los pasos anteriores. Este proceso se resume en una imagen adjunta para proporcionar una visión clara del flujo.

Cabe recalcar, que hay otros “detalles” que intervienen en el proceso, sin embargo el objetivo principal de este artículo es detallar el paso a paso de como seguir un flujo de una aplicación que se comunica con Ruby on Rails, GraphQL y React.

Nota: Para los diagramas, utilicé una herramienta denominada Excalidraw. En mi caso, necesito dibujar para poder retener la información y comprender cómo se interconecta todo dentro del flujo.