Yanıtlar:
Belki de soruyu parola ifade etmenin iyi bir yolu, alternatif biçimlere kıyasla avantajları nelerdir?
Ana alternatifler bence: bir veritabanı, metin dosyaları veya başka bir paketlenmiş / ikili format.
Dikkate alınacak veritabanı seçenekleri muhtemelen sütunlu bir mağaza veya NoSQL veya küçük bağımsız veri kümeleri SQLite içindir. Veritabanının en büyük avantajı, bellekten çok daha büyük verilerle çalışma, rastgele veya indekslenmiş erişime sahip olma ve verileri hızlıca ekleme / ekleme / değiştirme yeteneğidir. Başlıca * dis * avantajı, tüm veri kümesinin okunması ve işlenmesi gereken sorunlar için HDF'den çok daha yavaş olmasıdır. Diğer bir dezavantaj, SQLite gibi gömülü stil veritabanlarının haricinde, bir veritabanının basit bir kendi kendine yeten veri deposundan ziyade bir sistem (yönetim, kurulum, bakım, vb. Gerektiren) olmasıdır.
Metin dosyası formatı seçenekleri XML / JSON / CSV'dir. Bunlar platformlar arası / dil / araç takımıdır ve kendi kendini tanımlayabilmesi (ya da açık :) olması nedeniyle iyi bir arşiv formatıdır. Sıkıştırılmamışlarsa, büyüklerdir (10x-100x HDF), ancak eğer sıkıştırılırlarsa, oldukça alan verimli olabilirler (sıkıştırılmış XML, yaklaşık olarak HDF ile aynıdır). Buradaki ana dezavantaj yine hızdır: metni ayrıştırma, HDF'den çok daha yavaştır.
Diğer ikili biçimler (npy / npz numpy dosyaları, blz blaze dosyaları, protokol arabellekleri, Avro, ...) HDF'ye çok benzer özelliklere sahiptir, ancak daha az yaygın olarak desteklenirler (yalnızca bir platformla sınırlı olabilir: numpy) ve kendine özgü sınırlamaları var. Genelde zorlayıcı bir avantaj sunmazlar.
HDF, veritabanları için iyi bir tamamlayıcıdır, kabaca bellek boyutunda bir veri kümesi üretmek için bir sorgu yürütmek ve aynı verilerin birden fazla kullanılması durumunda HDF'de önbelleğe alınması mantıklı olabilir. Sabit ve genellikle bir bütün olarak işlenen bir veri kümeniz varsa, uygun boyutlu HDF dosyaları koleksiyonu olarak saklamak kötü bir seçenek değildir. Sık sık güncellenen bir veri kümeniz varsa, bir kısmını periyodik olarak HDF dosyaları olarak hazırlamak hala yardımcı olabilir.
Özetlemek gerekirse, HDF tipik olarak bir bütün olarak okunan (veya yazılan) veriler için iyi bir formattır; geniş destek ve uyumluluk nedeniyle, bir arşivleme formatı olarak iyi ve çok hızlı olması nedeniyle birçok uygulama için lingua franca veya ortak / tercih edilen değişim formatıdır.
PS Bu pratik pratik bağlamda, HDF'yi alternatiflerle karşılaştıran en son deneyimim, belirli bir küçük (bellek boyutundan çok daha az) bir veri setinin HDF olarak okunması 2 saniye sürdü (ve bunun çoğu muhtemelen Panda'ların yüküdür); JSON'dan okumak için ~ 1 dakika; ve veritabanına yazmak için 1 saat . Tabii ki veritabanı yazma hızlandırabilir, ancak iyi bir DBA'nız olsa iyi olur! Kutudan çıktığı gibi.
Bir fayda geniş destek - C, Java, Perl, Python ve R hepsinin HDF5 bağları var.
Diğer bir fayda ise hızdır. Ben kıyaslama görmemiştim, ancak HDF'nin SQL veritabanlarından daha hızlı olması gerekiyordu.
Hem büyük veri hem de zaman serileri verileriyle kullanıldığında çok iyi olduğunu biliyorum - ağ izleme, kullanım izleme vb.
HDF dosyaları için bir boyut sınırlaması olduğuna inanmıyorum (işletim sistemi sınırları hala geçerli olsa da).
Eklemek için ASDF'ye , özellikle de yazılarına göz atın ASDF: Astronomi için yeni bir veri formatı ; ASDF, HDF5'i iyileştirmeye çalışır ve kağıda HDF5 formatının bazı dezavantajları açıklanmaktadır.