Evaluación de HDF5: ¿Qué limitaciones/características proporciona HDF5 para modelar datos?
Estamos evaluando tecnologías que usaremos para almacenar los datos que recopilamos durante el análisis del código C/C++. En el caso de C++, la cantidad de datos puede ser relativamente grande, ~20 Mb por TU.
Después de leer la siguiente respuesta SO , me hizo considerar que HDF5 podría ser una tecnología adecuada para nuestro uso. Me preguntaba si la gente aquí podría ayudarme a responder algunas preguntas iniciales que tengo:
Actuación. El uso general de los datos será escribir una vez y leer "varias" veces, similar a la vida útil de un archivo '.o' generado por un compilador. ¿Cómo se compara HDF5 con el uso de algo como una base de datos SQLite? ¿Es esa siquiera una comparación razonable?
Con el tiempo agregaremos información a la que estamos almacenando, pero no necesariamente querremos redistribuir un conjunto completamente nuevo de "lectores" para admitir un nuevo formato. Después de leer la guía del usuario, entiendo que HDF5 es similar a XML o una base de datos, en el sentido de que la información está asociada con una etiqueta/columna y, por lo tanto, una herramienta creada para leer una estructura anterior simplemente ignorará los campos que no le interesan. ¿Es correcto mi entendimiento sobre esto?
Una parte importante de la información que deseamos escribir será una estructura de tipo árbol: jerarquía de alcance, jerarquía de tipos, etc. Lo ideal sería modelar los alcances como si tuvieran padres, hijos, etc. ¿Es posible tener un "punto" de objeto HDF5? ¿a otro? Si no es así, ¿existe una técnica estándar para resolver este problema utilizando HDF5? O, como se requiere en una base de datos, ¿necesitamos una clave única que "vincule" un objeto a otro con búsquedas apropiadas al buscar los datos?
¡Muchas gracias!
¿Cómo se compara HDF5 con el uso de algo como una base de datos SQLite? ¿Es esa siquiera una comparación razonable?
Algo parecido pero no tanto. Ambos son archivos estructurados. SQLite tiene funciones para admitir consultas de bases de datos utilizando SQL. HDF5 tiene funciones para admitir grandes conjuntos de datos científicos.
Ambos están destinados a ofrecer un alto rendimiento.
Con el tiempo agregaremos información a la que estamos almacenando, pero no necesariamente querremos redistribuir un conjunto completamente nuevo de "lectores" para admitir un nuevo formato.
Si almacena datos en forma estructurada, los tipos de datos de esas estructuras también se almacenan en el archivo HDF5. Estoy un poco oxidado en cuanto a cómo funciona esto (por ejemplo, si incluye compatibilidad innata con versiones anteriores), pero sí sé que si diseña su "lector" correctamente, debería poder manejar tipos que se cambien en el futuro.
¿Es posible hacer que un objeto HDF5 "apunte" a otro?
¡Absolutamente! Querrás usar atributos . Cada objeto tiene una o más cadenas que describen el camino para llegar a ese objeto. Los grupos HDF5 son análogos a las carpetas/directorios, excepto que las carpetas/directorios son jerárquicos = una ruta única describe la ubicación de cada uno (al menos en sistemas de archivos sin enlaces físicos), mientras que los grupos forman un gráfico dirigido que puede incluir ciclos. No estoy seguro de si puede almacenar un "puntero" a un objeto directamente como un atributo, pero siempre puede almacenar una ruta absoluta/relativa como un atributo de cadena. (o en cualquier otro lugar como una cadena; podría tener muchas tablas de búsqueda si lo desea).
Producimos datos HDF5 en mi proyecto, pero normalmente no me ocupo directamente de ellos. Puedo intentar responder las dos primeras preguntas:
Usamos un modelo de escritura una vez, lectura muchas veces y el formato parece manejar esto bien. Conozco un proyecto que solía escribir tanto en una base de datos Oracle como en HDF5. Finalmente, eliminaron la salida de Oracle porque el rendimiento se vio afectado y nadie la estaba usando. Obviamente, SQLite no es Oracle, pero el formato HDF5 era más adecuado para la tarea. Con base en ese único punto de datos, un RDBMS puede estar mejor ajustado para múltiples inserciones y actualizaciones.
Los lectores que utilizan nuestros clientes son sólidos cuando agregamos nuevos tipos de datos. Se anticipan algunos de los cambios, pero no tenemos que preocuparnos por romper algo al agregar más campos de datos. Nuestro DBA escribió recientemente un programa Python para leer datos HDF5 y completar archivos KMZ para visualizarlos en Google Earth. Dado que fue un proyecto que utilizó para aprender Python, diría que no es difícil crear lectores.
En la tercera pregunta, me inclinaré ante el conocimiento superior de Jason S.
Yo diría que HDF5 es una opción completamente razonable, especialmente si ya está interesado en él o planea producir algo para la comunidad científica.
