Nutzt Ihr HDF5 bei der Entwicklung neuer binaerer Dateiformate?
-
Umfrage: Nutzt Ihr HDF5 bei der Entwicklung neuer binaerer Dateiformate?
Auswahl Stimmen Prozent Ja. 1 5.6% Nein. 5 27.8% Hä? 12 66.7% Hi.
Mich interessiert, wie verbreitet die Nutzung von HDF5 bei der Entwicklung neuer binaerer Dateiformate ist. Deswegen diese Umfrage hier. Wenn Ihr dazu etwas beitragen moechtet, was nicht in das Korsett der Fragestellung passt (vielleicht wird es z.B. nur in Eurem Umfeld stark genutzt), dann bin ich gespannt auf Euren Beitrag.
-
Bis gerade eben nie davon gehört.
-
Interessantes Thema. Die wikipedia-Einträge zu HDF und NetCDF sind noch recht überschaubar: https://de.wikipedia.org/wiki/Hierarchical_Data_Format https://de.wikipedia.org/wiki/NetCDF
-
Ich finde es interessant, dass HDF5 (und vielleicht auch NetCDF als Alternative) derart unbekannt zu sein scheint. Aus meiner Sicht wird durch dieses Format eine Abstraktionsschicht bei der Speicherung von Daten eingebaut, die sehr nuetzlich ist, wenn es um Portabilitaet und so weiter geht. Sie ermoeglicht auch die Entwicklung von allgemeinen Werkzeugen um entsprechende Dateien sinnvoll betrachten zu koennen. Insgesamt erscheint es mir als ob doch eine recht gute Infrastruktur im Zusammenhang mit HDF5 existiert. Entsprechende Bibliotheken existieren zum Beispiel fuer viele relevante Sprachen.
Warum wird es dann anscheinend nur in einer recht kleinen Community genutzt? Gibt es Alterantiven in anderen Bereichen? Oder werden durch diese Formate Probleme geloest, die nur sehr selten auftreten?
-
Hi Gregor,
welchen Grund sollte es für "Otto-Normalentwickler" geben, derartige Formate zu nutzen.
Mir ist schon klar, dass es für bestimmte Anwendungen wie Wetterberechnungen, 3D-Grafikanwendungen oder FEM-Berechnungen auch auf effiziente Speicherungen der benötigten Datenmengen ankommt. Aber für den "Normalo" ist eine Datenbank immer noch das gegebenste. Schließlich will ich nicht Milliarden von Datensätzen ablegen, die ich ständig nach beliebigen Algorithmen lesen oder schreiben will, sondern ich will einen überschaubaren Hamstervorrat an Daten, den ich befragen kann, und der mir dann die gewünschten Antworten gibt.Erinnert mich irgendwie an meine erste Ingenieurarbeit, als ich die ganze Datenhaltung noch zu Fuß selber gemacht habe, bzw. meine Diplomarbeit, wo ich den ersten Entwurf auch noch auf eigenen Datenbankstrukturen aufbauen wollte, bevormir gerade noch rechzeitig mit Delphi 1 eine Programmieroberfläche mit für die damalige Zeit vorbildlicher Datenbankeinbindung unter die Finger kam.
Heute würde ich so was kaum noch machen, auch wenn das selber realisieren von Datenhaltung eine geistig sehr anspruchsvolle und interessante Arbeit ist. Aber den Aufwand bezahlt einem einfach keiner. Bei mir muss ein Programm rauskommen, das mit minimalem Aufwand von irgendwelchen SQL-Tauglichen Typen an aktuelle Bedingungen angepasst werden kann. Außerdem solls ohne Installation gehen. Bleibt mir als vernünftiges System nur noch Access. Wenns eingermaßen ordentlich strukturiert ist, funktioniert das ausreichend gut und für Sonderwünsche sind blitzschnell die nötigen Abfragen geschrieben oder angepasst.
Gruß Mümmel
-
Hey muemmel,
Ich glaube, die Nutzung einer Datenbank ist noch deutlich schwergewichtiger als die Nutzung so eines Formats. Ich sehe das vielleicht etwas naiv eher aus einer Perspektive, in der man sich wirklich low-level mit dem Datenformat auseinandersetzt. Demgegenueber hat eine Abstraktionsschicht wie HDF natuerlich eine ganze Menge Vorteile. Portabilitaet hatte ich schon angemerkt. Das einfachste Beispiel hierfuer ist wohl die Abstraktion von der Endianness. Wartbarkeit und Rueckwaertskompatibilitaet ist sicherlich auch ein Punkt. Ich kann dem Format zum Beispiel problemlos Eintraege hinzufuegen und es trotzdem noch mit den alten Routinen lesen.
Mir ist natuerlich klar, dass Datenbanken diese Probleme auch loesen, dort hat man es aber, wie Du schon anmerkst, mit deutlich staerkeren Einschraenkungen bezueglich der Effizienz zu tun.
Letztendlich ist es eine Frage der Art der Daten, die man speichern muss. Ich glaube aber nicht, dass Daten, die auf das Konzept von HDF5 passen derart selten entstehen, wie Du es andeutest.
-
Hi Gregor,
sicher sind Deine Einwände berechtigt. Aber es gibt eben doch einen gewaltigen Unterschied: Die Datenbank ist für jeden, der das Passwort bekommt frei zugänglich und notfalls könnte auch Lieschen Schmidt aus der buchhaltung da mal schnell irgend eine Auswertung machen, oder Herr Müller von der DB-Administration ein paar Berechnungen ändern oder komplett neu gestalten.
Die von Dir beschriebenen Datenabstraktionen bedingen dagegen immer meinen Einsatz an der Quelltextfront.
Wobei ich natürlich auch zugeben muss, das die ganzen normalen Daten- und Verfahrensabstraktionen wie sie z.B. Design Patterns ... wenn man Delphi und die VCL nutzt mehr oder weniger außen vor sind. Die Architektur wird einfach durch die VCL vorgegeben, und man muss damit klar kommen. Irgendwo ist daher aus meiner Sicht die Grenze, obeherhalb derer man Delphi und die VCL nicht mehr sinnvoll nutzen kann/sollte. Aber für kleine Dinge ist es für mich das Mittel der Wahl. Und durch die sehr weitgehenden Möglichkeiten eigene Komponenten zu entwerfen kann man da vieles ausgleichen.
Die Nutzung solche von Dir genannter Datenformate würde da sicher wieder mehr Möglichkeiten bieten, gerade auch um mehr mit Design Pattern zu arbeiten. Aber Herr Müller und Lieschen Schmidt wären dann außen vor.
Effizienzmäßig bin ich noch lange nicht an der Grenze, wo es Probleme gibt, die größte Effizienzbremse sitzt immer 30-35 cm vor dem Bildschirm. Und durch die Verwendung von Access-MDBs brauch ich auf dem Rechner wo die Anwendung arbeiten soll nicht mehr als ein MS-Betriebssystem ab Windows-XP voraussetzen. Die Unterstützung von Jet-SQL ist da bereits als Betriebssystem-Dienstleistung vorhanden.Daten, die auf das Konzept von HDF5 passen entstehen vermutlich wesentlich öffter, als wir beide uns denken können, aber was entscheidender ist, wie oft entstehen Daten die das Konzept von HDF5 benötigen (was der Bauer nicht kennt frist er nicht). Ohne Leidensdruck nichts neues. Für das alte DB-System existiert eine rundum runde Infrastruktur (xls, ppt, mdb...) um zu erfassen, auszuwerten, zu visualisieren (und zu manipulieren bzw. bescheißen wenn nötig). Neue Formate sind immer am besten am Anfang einer Sache aufgehoben, oder bei einer grundsätzlichen Neuorientierung, im normalen Betrieb sind sie eher wie eine heiße Kartoffel.
Gruß Mümmel
-
Gregor schrieb:
Ich kann dem Format zum Beispiel problemlos Eintraege hinzufuegen und es trotzdem noch mit den alten Routinen lesen.
Das konntest du schon damit machen: https://de.wikipedia.org/wiki/Type-Length-Value
-
muemmel schrieb:
Daten, die auf das Konzept von HDF5 passen entstehen vermutlich wesentlich öffter, als wir beide uns denken können, aber was entscheidender ist, wie oft entstehen Daten die das Konzept von HDF5 benötigen (was der Bauer nicht kennt frist er nicht). Ohne Leidensdruck nichts neues. Für das alte DB-System existiert eine rundum runde Infrastruktur (xls, ppt, mdb...) um zu erfassen, auszuwerten, zu visualisieren (und zu manipulieren bzw. bescheißen wenn nötig). Neue Formate sind immer am besten am Anfang einer Sache aufgehoben, oder bei einer grundsätzlichen Neuorientierung, im normalen Betrieb sind sie eher wie eine heiße Kartoffel.
Du hast mich davon ueberzeugt, dass Du in Deinem speziellen Umfeld kein HDF5 brauchst. Ich wuerde aber davon ausgehen, dass weder Dein noch mein Arbeitsumfeld so einfach auf die Allgemeinheit extrapolierbar sind.
-
Naja, es kommt vielleicht auch auf die sonstige Umgebung drauf an. Wir haben auch mehrere Anwendungsfälle, wo wir sehr viele Daten in eigenen Formaten speichern. Einige sind so ähnlich aufgebaut wie Datenbanken, mit Paging, Caching usw. Andere verwenden QDataStream, weil wir viel mit Qt machen. Einiges ist historisch entstanden. Anderes hat sich aus irgendwas ergeben und wurde vielleicht immer weiter optimiert. Die Codebasis ist insgesamt schon sehr alt, d.h. vieles wurde irgendwann mal mit irgendwas geschrieben, dann aber optimiert und umgebaut. Wenn wir jetzt was komplett neues entwickeln würde, würde so ein Format wahrscheinlich auch in Frage kommen, wobei ich vermute, dass unsere exakt an die Anforderungen angepassten eigenen Formate besser sind, als ein allgemeines Framework. Da wir aber eh schon sehr viel Code haben, machts auch keinen Sinn, sich nach sowas umzuschauen.
