Odpowiedzi:
Być może dobrym sposobem na sparafrazowanie pytania jest, jakie są zalety w porównaniu do alternatywnych formatów?
Myślę, że głównymi alternatywami są baza danych, pliki tekstowe lub inny format spakowany / binarny.
Opcje bazy danych do rozważenia to prawdopodobnie magazyn kolumnowy lub NoSQL, lub małe samodzielne zestawy danych SQLite. Główną zaletą bazy danych jest możliwość pracy z danymi znacznie większymi niż pamięć, dostęp losowy lub indeksowany oraz szybkie dodawanie / dołączanie / modyfikowanie danych. Główną zaletą * dis * jest to, że jest on znacznie wolniejszy niż HDF, w przypadku problemów, w których cały zestaw danych musi zostać wczytany i przetworzony. Kolejną wadą jest to, że z wyjątkiem baz danych w stylu osadzonym, takich jak SQLite, baza danych jest systemem (wymagającym podziwu, konfiguracji, konserwacji itp.), A nie prostym, niezależnym magazynem danych.
Opcje formatu pliku tekstowego to XML / JSON / CSV. Są one wieloplatformowe / język / zestaw narzędzi i są dobrym formatem archiwalnym ze względu na możliwość opisywania się (lub oczywiste :). Jeśli nieskompresowane, są ogromne (10x-100x HDF), ale jeśli są skompresowane, mogą być dość wydajne pod względem przestrzeni (skompresowany XML jest mniej więcej taki sam jak HDF). Główną wadą jest tutaj szybkość: parsowanie tekstu jest znacznie, dużo wolniejsze niż HDF.
Inne formaty binarne (pliki numy npy / npz, pliki blz blaze, bufory protokołów, Avro, ...) mają bardzo podobne właściwości do HDF, z tym że są mniej obsługiwane (mogą być ograniczone tylko do jednej platformy: numpy) i mogą mają określone inne ograniczenia. Zazwyczaj nie oferują one istotnych korzyści.
HDF stanowi dobre uzupełnienie baz danych, może być sensowne uruchomienie zapytania w celu utworzenia zbioru danych o wielkości mniej więcej pamięci, a następnie buforowanie go w HDF, jeśli te same dane zostaną użyte więcej niż jeden raz. Jeśli masz zestaw danych, który jest stały i zwykle przetwarzany jako całość, przechowywanie go jako zbioru plików HDF o odpowiednim rozmiarze nie jest złą opcją. Jeśli masz często aktualizowany zestaw danych, okresowe umieszczanie niektórych z nich jako plików HDF może być nadal pomocne.
Podsumowując, HDF jest dobrym formatem dla danych, które są odczytywane (lub zapisywane) zazwyczaj jako całość; jest to lingua franca lub wspólny / preferowany format wymiany dla wielu aplikacji ze względu na szerokie wsparcie i kompatybilność, przyzwoity jako format archiwalny i bardzo szybki.
PS Aby nadać temu praktyczny kontekst, moje ostatnie doświadczenie w porównywaniu HDF z alternatywami, pewien mały (znacznie mniejszy niż pamięć) zestaw danych potrzebował 2 sekund na odczytanie jako HDF (a większość z nich to prawdopodobnie narzut z Pandas); ~ 1 minuta do odczytania z JSON; i 1 godzina na zapis do bazy danych. Na pewno można przyspieszyć zapis w bazie danych, ale lepiej mieć dobry DBA! Tak to działa po wyjęciu z pudełka.
Jedną z korzyści jest szerokie wsparcie - C, Java, Perl, Python i R mają wszystkie powiązania HDF5.
Kolejną zaletą jest szybkość. Nigdy nie widziałem go w testach porównawczych, ale HDF ma być szybszy niż bazy danych SQL.
Rozumiem, że jest bardzo dobry, gdy jest używany zarówno z dużymi zestawami danych naukowych, jak i szeregami czasowymi - monitorowanie sieci, śledzenie użycia itp.
Nie wierzę, że istnieje ograniczenie rozmiaru plików HDF (chociaż nadal obowiązywałyby ograniczenia systemu operacyjnego).
Aby dodać, sprawdź ASDF, w szczególności ich artykuł ASDF: nowy format danych dla astronomii ; ASDF próbuje ulepszyć HDF5, a artykuł opisuje niektóre wady formatu HDF5.