Çok sayıda sütunu depolamanın iyi bir yolu nedir?

Bu verileri veritabanımda nasıl saklayacağınıza karar vermede bir sorunum var. Bunu yapmanın en iyi yolu hakkında herhangi bir öneriniz var mı? Veritabanları hakkında çok fazla şey bilmiyorum, ekleyebilirim.

Ben böyle biçimlendirilmiş olarak gelen veri var, ama 4 yerine, sütun sayısı yaklaşık 240, her tarih onunla ilişkili 240 benzersiz değerleri vardır:

Date/Time 200,00 202,50 205,00  
2010.11.12  13:34:00  45,8214 43,8512  41,5369   
2010.11.12  13:35:00  461,9364  454,2612  435,5222 

Ayrıca, satırlar DataSites ile ilişkilendirilir.

İlk düşüncem şöyle bir tabloya sahip olmaktı: DataID (pk), DataSiteID, ParameterID, Date, Value, DataSite, Parameter ve Date diziniyle. ParameterID, giriş sütunu başlıklarını (200,00 202,50 205,00 ...) depolayan başka bir tabloya karşılık gelir.

İkinci düşüncem sadece 240 tek sütun içeren bir tabloya sahip olmaktı. Birkaç yol daha buldum, ama onlar da oldukça tatmin edici değiller.

İlk çözümümle ilgili sorunum (çok büyük bir sorun değil, ama hoşuma gitmiyor), Date ve DataSiteID'nin bu giriş satırındaki 240 değer için tekrarlanacağı, bu yüzden biraz kullanması ekstra alan.

Yılda yaklaşık 40 gb veri gelecek (yukarıdaki metin biçiminde) ve veriler DataSite, Parameter ve Date tarafından aranacak. Gelen veri miktarı bir yıl içinde dört kat artacaktır.

İyi fikirleriniz var mı? Teşekkürler, James

edit: Bu sütunlar farklı dalga boylarında ölçümleri olan zaman serisi verileridir. Veriler nispeten dar dalga boyları aralığında analiz edilmek isteyecektir. Gelecekte bir noktada ekstra dalga boyları da eklenebilir.

edit: cevaplar çocuklar için teşekkürler, gerçekten takdir :) Ben muhtemelen 500gb ya da öylesine test verileri ile bazı deneyler çalıştırmak için zaman bulabiliriz düşünüyorum. Herhangi bir sonuç ile geri göndereceğim;)

Her iki durumda da bir durum oluşturabilirsiniz, ancak veriler analiz için kullanılacaksa ve genellikle aynı anda bu verilerden birden fazla sütun görmek istiyorsanız geniş tablo ile devam edin. Veritabanları sütun miktarınızı ve satır boyutu sınırlarınızı bildiğinizden emin olun. Veri türlerini doğru yaptığınızdan emin olun. Sütunların çoğu boşsa, SQL Server tabloyu bunun için optimize etmenize izin verir. Bu tür verilerin analizi için bir NOSQL (Sadece SQL değil) çözümü de kullanabilirsiniz.

Bu veriler analiz için daha az olacaksa, sorunuzda belirtildiği gibi normalleştirmek isteyebilirsiniz.

Sizinkine çok benzer bir durumum vardı, yılda 30-50 gb ile 257 alan geliyor. Sadece basit, SQL Server'da büyük bir çocuk masası tutmaya son verdim. Verilerim adil bir şekilde sorgulandı, ancak esas olarak tarihte ve iyi çalıştı.

Verileri mantıksal küçük aynalara (50 veya daha fazla grup) ayırabilirdim, ancak bu durumda gerçekten çok fazla bir avantaj yoktu, bu yüzden kendimi rahatsız ettim.

Eğer şimdi fantezi hissediyorsam, teoriye daha uygun bir NoSQL seçeneğini düşünebilirim, ancak görev kritik verileriyle yeni şeyler denemek her zaman sinirler için harika değildir.

Bu yüzden, gecikmeli olarak kendi sorumu cevaplamak için (proje sonunda hiç ilerlemedi), boş bir zaman elde etmeyi başardığımda, 500 gb veri içeren bir test tablosunu şu şekilde düzenlenmiş olarak doldurdum:

İlk düşüncem şöyle bir tabloya sahip olmaktı: DataID (pk), DataSiteID, ParameterID, Date, Value, DataSite, Parameter ve Date diziniyle. ParameterID, giriş sütunu başlıklarını (200,00 202,50 205,00 ...) depolayan başka bir tabloya karşılık gelir.

Veritabanı kurulumu 3GB RAM ile eski bir çift çekirdekli makineye standart PostgreSQL kurulumu oldu. DataSite Date ve ParameterID ile verileri seçerek, 1 saatlik bir süre, 1 günlük zaman dilimi boyunca verileri ortalaması alarak ve yeni veri parçaları ekleyerek yaklaşık bir düzine farklı sorgu çalıştırdım. Bellekten, tüm sorguların yürütülmesi bir saniyeden az sürdü. Kesinlikle beklediğimden çok daha hızlı ve oldukça kullanışlı. Düşündüğüm bir şey, bu şekilde indekslenmiş tablo ile dizin dosyasının da neredeyse 500gb olmasıydı, bu yüzden 240 sütun genişliğinde bir tabloya sahip olmak kesinlikle çok fazla disk alanı kazandıracaktı.

Postgres'de bunu zarif bir dizi türü veya Oracle'daki bir varray ile çözerdim .

Sorununuz için yararlı olup olmadığını bilmiyorum, ancak sütunlar için doğrudan isteklerde bulunmam gerekmiyor (WHERE durumuma asla koymadım cols) ve sadece bazı bilgiler hakkında bilgi istediğimde bilgilendirici belirli satırları, JSON biçimlendirilmiş bir blog alanında onları birleştirmek.

Muhtemelen tasarımın nihai kararını sorgulanan parametre_kitelerinin dağıtımına bağlı yapardım. Yani, neredeyse sadece sorgulanan birkaç parametre_id varsa, değerlerini sıcak bir tabloya ve kalan değerleri başka bir soğuk tabloya koyardım .

Otoh, sorgu dağıtımı aşağı yukarı eşitse, birkaç gün değerinde bir örnek kümesini, kayıtların / db blokları arasındaki oranın ne olduğunu görmek için bir kaydın tüm değerleri tuttuğu bir tabloya yüklerdim (veya hatta bir satır zincirleme sorunu bile var , bu muhtemelen). Buna bağlı olarak başka bir tasarım kararı vereceğim.

Okuduktan sonra, muhtemelen bir karar için her iki yaklaşımı da paralel olarak yapardım.

Soruyu yeniden okuyordum - eğer bu doğru varsa, her kayıtta girdi olarak alırsınız, (ParameterID'ye göre) izlenen farklı değerler vardır:

ParameterID, giriş sütunu başlıklarını (200,00 202,50 205,00 ...) depolayan başka bir tabloya karşılık gelir.

... verilerle nasıl etkileşim kurduğunuzu bilmiyorum, ama başka bir seçeneğe gitmeye meyilli olurum - her parametre kimliği için ayrı bir tabloya sahip olurum ve gerekirse tarihe ve konuma göre çeşitli farklı parametreleri daha geniş (240 sütun) tabloya birleştirin; DataID'yi görünümde erişilebilir tutmak önemliyse, a UNIONyerine bir kullanabilirsiniz JOIN, ancak sütunlar seyrek olarak doldurulur.