Figura 2 de IDC #US52554824e, septiembre de 2024, página 4 https://techcontentwave.com/files/1763389937_64b594fd4f7f5607256a.pdf Extracción del gráfico original, sin modificar sus valores ni su leyenda: pdftoppm -f 4 -l 4 -r 300 -x 225 -y 1810 -W 1530 -H 780 -singlefile -png informe.pdf teoria/img/data-growth-idc-2024 IDC agrupa los datos semiestructurados con los no estructurados Las empresas generan ambos tipos; "de empresa" no equivale a "estructurado"
--- <!-- _class: compact -- > # El mismo problema, cinco modelos Ana (usuario 1) publica la pregunta 10; Luis (usuario 2) la responde con la respuesta 21; la pregunta recibe dos comentarios, el 101 y el 102 **Problema**: mostrar la pregunta con sus respuestas y comentarios Lo recorremos en cuatro pasos, con los cinco modelos delante: 1. **Qué guarda** cada uno del hilo 2. **Cómo se lee** el hilo completo 3. **Qué ocurre con una consulta nueva**: las respuestas de Luis 4. **Qué cuesta modificarlo**: Ana cambia su nombre y Luis añade otra respuesta Son diseños ilustrativos para comparar decisiones, no el esquema de los boletines --- <!-- _class: figure-only -- > # El mismo hilo en cinco representaciones  --- <!-- _class: compact small-table -- > # Leer el hilo: una operación por modelo | Modelo | Operación | Trabajo | |---|---|---| | SQL | `SELECT * FROM Posts WHERE Id = 10 OR ParentId = 10`<br>`SELECT * FROM Comments WHERE PostId = 10` | Dos consultas, o una unión, apoyadas en índices por `ParentId` y `PostId` | | Clave-valor | `GET pregunta:10` | Un acceso: el cliente decodifica el valor | | Documentos | `db.preguntas.findOne({ _id: 10 })` | Un acceso: un documento con todo el hilo | | Columnas | `SELECT * FROM hilo WHERE pregunta_id = 10` | Una partición, leída en orden | | Grafo | `MATCH (x)-[:RESPONDE_A\|COMENTA_A]->(:Pregunta {id: 10}) RETURN x` | Un recorrido desde el nodo de la pregunta | > Todos leen el hilo; cambia cuántos accesos hacen y qué unidad devuelven --- <!-- _class: compact small-table -- > # Una consulta nueva: las respuestas de Luis | Modelo | Cómo se resuelve | Qué cuesta | |---|---|---| | SQL | `SELECT * FROM Posts WHERE OwnerUserId = 2 AND PostTypeId = 2` | Un índice por autor (sesión 2) | | Clave-valor | No hay acceso por contenido: recorrer todos los valores o mantener otra clave, `respuestas:2` | Una segunda estructura que mantiene la aplicación | | Documentos | `db.preguntas.find({ "respuestas.autor": 2 })` | Un índice sobre el *array* (sesión 4); devuelve preguntas completas | | Columnas | Otra tabla con otra clave de partición: `respuestas_por_autor` | Duplicar los datos y escribir en las dos tablas | | Grafo | `MATCH (:Usuario {nombre: 'Luis'})-[:AUTOR_DE]->(r:Respuesta) RETURN r` | Localizar el nodo de Luis; desde él se recorre | > Cada modelo deja **optimizado** un acceso; los demás se pagan con índices, copias o recorridos --- <!-- _class: compact -- > # Para discutir: modificar el mismo hilo Con las representaciones a la vista: 1. **Ana cambia su nombre.** El hilo sólo guarda `autor: 1`: ¿dónde vive el nombre en cada modelo? ¿Qué cambia si cada copia llevase el nombre? 2. **Luis añade una respuesta.** ¿Qué se escribe, y en cuántos sitios, en cada modelo? 3. **¿Qué parte de cada cambio es una sola operación atómica?** La contestaremos en la sesión 4 Razonamos sobre las consecuencias de unas representaciones ya dadas, sin inventar antes un esquema --- <!-- _class: compact small-table -- > # Qué cuesta modificar el hilo | Modelo | Ana cambia su nombre | Luis añade una respuesta | |---|---|---| | SQL | Una fila de `Users`; el hilo sólo guarda `OwnerUserId` | Un `INSERT` en `Posts` | | Clave-valor | Si el nombre está dentro del valor, la aplicación reescribe cada valor que lo contiene | La aplicación lee y reescribe el valor completo; con una lista de Redis, añade un elemento | | Documentos | Un documento si se referencia; tantos como copias si se incrusta | Un `$push` en `respuestas`: una sola operación atómica | | Columnas | Cada fila donde se copió; si no, una fila de la tabla de usuarios | Un `INSERT` en la partición 10, y otro en `respuestas_por_autor` si existe | | Grafo | Una propiedad del nodo de Ana | Un nodo y dos aristas, autoría y respuesta, en una transacción | > El coste de un cambio lo deciden las copias que hay y la unidad que es atómica; la sesión 4 lo concreta en MongoDB