Evaluación de HDF5: ¿Qué limitaciones/características proporciona HDF5 para los datos de modelado?

Question

Evaluación de HDF5: ¿Qué limitaciones/características proporciona HDF5 para los datos de modelado?

Estamos evaluando tecnologías que usaremos para almacenar 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 lo siguiente SO answer me hizo considerar que HDF5 podría ser una tecnología adecuada para que la usemos. Me preguntaba si la gente aquí podría ayudarme a responder algunas preguntas iniciales que tengo:

Rendimiento. El uso general para el los datos se escribirán una vez y se leerán "varias" veces, similar a la vida útil de un '.o' archivo generado por un compilador. ¿Cómo se compara HDF5 con el uso de algo como una base de datos SQLite? ¿Es una comparación razonable?
Con el tiempo agregaremos a la información que estamos almacenando, pero no necesariamente desearemos 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 BD, en esa información está asociada con una etiqueta/columna y, por lo tanto, una herramienta construida para leer una estructura anterior simplemente ignorará los campos que no le conciernen. ¿Tengo entendido esto correctamente?
Una parte significativa de la información que deseamos escribir será un tipo de estructura de árbol: jerarquía de alcance, jerarquía de tipos, etc. Idealmente podríamos modelar los alcances como tener padres, hijos, etc. ¿Es posible que un objeto HDF5 "apunte" a otro? Si no, hay un 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!

39

database binaryfiles hdf5 datamodel

Author: Community, 2009-02-13

Source

2 answers

Producimos datos HDF5 en mi proyecto, pero normalmente no los trato directamente. Puedo tomar una puñalada en las dos primeras preguntas:

Usamos un modelo write once, read many times 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 ya que el rendimiento sufría y nadie la estaba usando. Obviamente, SQLite no es Oracle, pero el formato HDF5 era más adecuado para el tarea. Basado en ese punto de datos, un RDBMS puede ajustarse mejor para múltiples inserciones y actualizaciones.
Los lectores que utilizan nuestros clientes son robustos cuando agregamos nuevos tipos de datos. Algunos de los cambios se anticipan, pero no tenemos que preocuparnos por romper cosas al agregar más campos de datos. Nuestro DBA recientemente escribió un programa Python para leer datos HDF5 y rellenar archivos KMZ para su visualización en Google Earth. Ya que era un proyecto que solía aprender Python, yo diría que no es difícil construye 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.

9

Author: Jon Ericson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:00:16

score 22 · Accepted Answer

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

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

Ambos están destinados a ser de alto rendimiento.

Con el tiempo vamos a añadir a la información que estamos almacenando, pero no necesariamente queremos redistribuir un conjunto completamente nuevo de" lectores " para soportar 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 hacia atrás), pero sé que si diseña su "lector" correctamente debería ser capaz de manejar tipos que se cambian en el futuro.

¿Es posible que un objeto HDF5 "apunte" a otro?

Absolutamente! Usted querrá usar atributos. Cada objeto tiene una o más cadenas que describen la ruta para llegar a ese objeto. HDF5 los grupos son análogos a las carpetas/directorios, excepto que las carpetas/directorios son jerárquicas = 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 lo desea.)