database - Evaluación de HDF5: ¿Qué limitaciones/características proporciona HDF5 para modelar datos?

binaryfiles datamodel

Question

Estamos evaluando las 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, ~ 20Mb por TU.

Después de leer la siguiente respuesta SO, me hizo considerar que HDF5 podría ser una tecnología adecuada para nosotros. Me preguntaba si la gente aquí podría ayudarme a responder unas pocas preguntas iniciales que tengo:

1. Actuación. El uso general de los datos se escribirá una vez y leerá "varias veces", similar a la duración de un archivo ''.o'' generado por un compilador. ¿Cómo se compara HDF5 con el uso de algo así como una base de datos SQLite? ¿Es incluso una comparación razonable para hacer?

2. Con el tiempo, agregaremos la información que estamos almacenando, pero no necesariamente querremos volver a distribuir 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 a DB, en que la información está asociada con una etiqueta / columna, por lo que una herramienta creada para leer una estructura anterior simplemente ignorará los campos que no le interesan. Es mi entendimiento sobre esto correcto?

3. Una parte significativa de la información que deseamos escribir será un tipo de estructura arborescente: jerarquía de alcance, jerarquía de tipos, etc. Lo ideal sería modelar ámbitos con padres, hijos, etc. ¿Es posible tener un objeto "objeto" HDF5? ¿a otro? Si no, ¿existe una técnica estándar para resolver este problema usando HDF5? O, como se requiere en un DB, ¿necesitamos una clave única que "enlace" un objeto a otro con búsquedas apropiadas cuando se buscan los datos?

¡Muchas gracias!

Answer 1

¿Cómo se compara HDF5 con el uso de algo así como una base de datos SQLite? ¿Es incluso una comparación razonable para hacer?

Algo similar pero no realmente. Ambos son archivos estructurados. SQLite tiene características para admitir consultas de bases de datos utilizando SQL. HDF5 tiene características para admitir grandes conjuntos de datos científicos.

Ambos están destinados a ser de alto rendimiento.

Con el tiempo, agregaremos la información que estamos almacenando, pero no necesariamente querremos volver a distribuir 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 sobre cómo funciona esto (por ejemplo, si incluye la compatibilidad hacia atrás innata), pero sé que si diseñas correctamente tu "lector", debería poder manejar los tipos que se cambian en el futuro.

¿Es posible tener un objeto "punto" HDF5 a otro?

¡Absolutamente! Querrá usar atributos . Cada objeto tiene una o más cadenas que describen la ruta para llegar a ese objeto. Los grupos HDF5 son análogos a carpetas / directorios, excepto que las carpetas / directorios son jerárquicos = una ruta única describe la ubicación de cada uno (en sistemas de archivos sin enlaces duros al menos), 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 tablas de búsqueda en abundancia si quisiera).

Answer 2

Producimos datos HDF5 en mi proyecto, pero normalmente no me ocupo de ellos directamente. Puedo tomar una puñalada en las primeras dos preguntas:

1. Utilizamos un modelo de escritura, lectura muchas veces y el formato parece manejarlo bien. Conozco un proyecto que solía escribir tanto en una base de datos Oracle como en HDF5. Eventualmente eliminaron la salida de Oracle ya que el rendimiento sufría y nadie lo estaba usando. Obviamente, SQLite no es Oracle, pero el formato HDF5 era más adecuado para la tarea. Basado en ese único punto de datos, un RDBMS puede ajustarse mejor para múltiples inserciones y actualizaciones.

2. Los lectores que usan nuestros clientes son robustos cuando agregamos nuevos tipos de datos. Algunos de los cambios son anticipados, 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 poblar archivos KMZ para su visualización en Google Earth. Como era un proyecto que usaba 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.

Diría que HDF5 es una elección completamente razonable, especialmente si ya está interesado en él o planea producir algo para la comunidad científica.