27 de abril - 3 de mayo

Archivos Binarios, struct y Registros de Longitud Fija

• Módulo struct: empaquetado/desempaquetado, endianness, calcsize
• Registros de longitud fija: acceso directo con seek por offset
• Mantenimiento de archivos (ABM): free list encadenada y bitmap
• Holístico: bloques del SO, fragmentación, buffer cache, lseek

En la Semana 6 introdujimos los archivos de texto y un patrón básico de persistencia: abrir, leer línea por línea o escribir con write, y cerrar. Los archivos de texto son cómodos para datos destinados al ojo humano —listados, configuraciones, logs, CSV sencillos— pero resultan ineficientes y limitados cuando los datos son datos estructurados para el programa, no para el lector. Tres limitaciones importantes se hacen evidentes cuando un archivo de texto pasa de ser consultado a ser procesado intensivamente:

• Costo de conversión: cada número en un archivo de texto está representado como una secuencia de caracteres dígito. Para usarlo, hay que invocar int() o float() al leer, y str() al escribir. Sobre millones de registros, esas conversiones dominan el tiempo de ejecución.
• Ocupación variable: el número 42 ocupa 2 caracteres, pero 1234567890 ocupa 10. Esto hace imposible predecir dónde comienza el k-ésimo dato sin leer todo lo anterior. Los archivos de texto son, por naturaleza, de acceso secuencial.
• Ausencia de tipos: todo es cadena. La semántica —¿es un entero, un flotante, una fecha?— vive solo en la cabeza del programador y en los convertidores ad-hoc.

Los archivos binarios resuelven estas tres limitaciones a la vez: almacenan los bytes tal cual están en memoria, sin conversión a caracteres. Un entero de 4 bytes ocupa siempre 4 bytes, sea el valor 0, 42 o 2 147 483 647. Esa regularidad en el tamaño es la llave maestra que abre la puerta al acceso directo: si todos los registros miden lo mismo, el registro número k comienza exactamente en el byte k × tamaño_registro, y se llega a él con una sola llamada del sistema operativo. Lo que con archivos de texto costaba O(n) —porque había que leer desde el principio hasta encontrarlo— con archivos binarios cuesta O(1).

Los problemas de esta semana introducen el trabajo con archivos binarios como medio para la persistencia eficiente de grandes colecciones de datos homogéneos. El eje temático es la representación directa de datos en bytes mediante el módulo struct y el aprovechamiento del acceso directo por offset que permite una sola llamada al sistema operativo (seek) para llegar al k-ésimo registro sin recorrer los anteriores. Sobre esa base, se construye el patrón ABM (Alta, Baja lógica, Modificación) con gestión de espacio libre por free list encadenada, y se verifica empíricamente la diferencia de rendimiento entre acceso secuencial y acceso directo.

Los cinco problemas están organizados en tres bloques con conexiones deliberadas: el Bloque A construye los cimientos —empaquetado de datos elementales y diseño del registro—; el Bloque B ataca el patrón ABM completo con free list y verificación visual del archivo binario mediante volcado hexadecimal; y el Bloque C mide empíricamente la ganancia del acceso directo sobre el secuencial y verifica que la representación elegida en struct respeta lo aprendido en la Semana 2 sobre complemento a dos e IEEE 754. Se agrega una sección de Desafíos extracurriculares grupales con cuatro propuestas que profundizan los temas conceptualmente introducidos pero no implementados en la teoría (bitmap de espacio libre, slotted pages, log append-only y migración entre formatos de serialización).

Desde esta semana hasta el fin de la próxima tendrán tiempo para desarrollar uno de los desafíos extracurriculares grupales de  Problemas Semana 8 usando GitHub Classroom como plataforma de gestión y entrega. En esta guía se explica cómo.

Los grupos que se conformen podrán escoger un problema o desafío según la cantidad de integrantes:

• Los grupos de 2 integrantes pueden optar por el desafío 1 (ABM de registros de longitud fija con bitmap auxiliar de espacio libre), o el desafío 3 (Log append-only con índice y reconstrucción).
• Los grupos de 3 o 4 integrantes pueden optar por el desafío 2 (Catálogo en bloques de longitud fija con índice persistente), o el desafío 4 (Migración entre formatos — struct ↔ JSON Lines).

El plazo para terminar el trabajo es el sábado 9 de abril a las 23:59.

Los enlaces para desarrollar los desafíos como tareas en GitHub Classroom (ver condiciones de acceso y conformación de grupos en la guía antes de acceder) son:

1. https://classroom.github.com/a/i_JmIVTt
2. https://classroom.github.com/a/x4XJ0fih
3. https://classroom.github.com/a/Oozk6ebA
4. https://classroom.github.com/a/0bYhAta0

Corrección de trabajos