Jaki jest dobry sposób na przechowywanie dużej liczby kolumn?

Mam problem z decyzją, jak przechowywać te dane w mojej bazie danych. Wszelkie sugestie dotyczące najlepszego sposobu, aby to zrobić? Dodam, że nie znam się na bazach danych.

Mam dane tak sformatowane, ale zamiast 4 liczba kolumn wynosi około 240, więc z każdą datą związane są 240 unikalne wartości:

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 

Ponadto wiersze są powiązane z DataSites.

Moją pierwszą myślą było stworzenie takiej tabeli: DataID (pk), DataSiteID, ParameterID, Date, Value, z indeksem DataSite, Parameter and Date. Parametr ID odnosi się do innej tabeli, która przechowuje nagłówki kolumn wejściowych (200,00 202,50 205,00 ...).

Moją drugą myślą było po prostu mieć stół ze wszystkimi 240-osobowymi kolumnami. Wymyśliłem kilka innych sposobów, ale są one również niezadowalające.

Problem z moim pierwszym rozwiązaniem (nie jest to tak duży problem, ale mi się nie podoba) polega na tym, że Date i DataSiteID będą się powtarzać dla wszystkich 240 wartości w tym wierszu wejściowym, więc używa całkiem sporo dodatkowej przestrzeni.

Będzie około 40 GB danych rocznie (w powyższym formacie tekstowym), a dane będą wyszukiwane według DataSite, parametru i daty. Ilość napływających danych najprawdopodobniej zwiększy się czterokrotnie w ciągu około roku.

Jakieś dobre pomysły? Dzięki, James

edycja: Są to dane szeregów czasowych, przy czym kolumny są pomiarami przy różnych długościach fal. Dane będą musiały być analizowane w stosunkowo wąskim zakresie długości fal. W przyszłości mogą zostać dodane dodatkowe długości fal.

edytuj: Dzięki za odpowiedzi chłopaki, naprawdę to doceniam :) Myślę, że prawdopodobnie znajdę czas na przeprowadzenie eksperymentów z danymi testowymi o wielkości około 500 GB. Odpowiem z wszelkimi wnioskami;)

Możesz zrobić przypadek w obu przypadkach, ale jeśli dane będą wykorzystywane do analizy i często chcesz zobaczyć wiele kolumn z tych danych w tym samym czasie, przejdź do szerokiej tabeli. Upewnij się, że znasz limity ilości i wielkości wierszy w bazach danych. Upewnij się, że poprawnie otrzymałeś typy danych. Jeśli wiele kolumn jest pustych, SQL Server pozwala na optymalizację tabeli w tym celu. Możesz również rozważyć użycie rozwiązania NOSQL (nie tylko SQL) do analizy tego typu danych.

Jeśli tych danych będzie mniej do analizy, możesz chcieć je znormalizować, jak podano w pytaniu.

Miałem bardzo podobną sytuację do twojej, 257 pól z 30-50 GB rocznie. Skończyło się na prostym, długim stole dla dużych chłopców w SQL Server. Moje dane były nieco przeszukiwane, ale głównie na czas i działały dobrze.

Mógłbym podzielić dane na logiczne mniejsze uchwyty (grupy 50 lub więcej), ale w tym przypadku tak naprawdę nie było z tego żadnej przewagi, więc nie zawracałem sobie głowy.

Gdybym teraz miał ochotę, mógłbym rozważyć opcję NoSQL, która lepiej pasuje do teorii, ale w przypadku danych o znaczeniu krytycznym wypróbowywanie nowych rzeczy nie zawsze jest dobre dla nerwów.

Tak więc, aby z opóźnieniem odpowiedzieć na moje własne pytanie (projekt nigdy nie poszedł do przodu), kiedy udało mi się uzyskać trochę wolnego czasu, wypełniłem tabelę testową 500 GB danych z tabelą ułożoną w następujący sposób:

Moją pierwszą myślą było stworzenie takiej tabeli: DataID (pk), DataSiteID, ParameterID, Date, Value, z indeksem DataSite, Parameter and Date. Parametr ID odnosi się do innej tabeli, która przechowuje nagłówki kolumn wejściowych (200,00 202,50 205,00 ...).

Konfiguracja bazy danych była standardową instalacją PostgreSQL na starej maszynie dwurdzeniowej z 3 GB pamięci RAM. Uruchomiłem około tuzina różnych zapytań, po prostu wybierając dane według DataSite Data i ParameterID, uśredniając dane w ciągu 1 godziny, 1 dnia i wstawiając nowe porcje danych. Z pamięci wykonanie wszystkich zapytań zajęło mniej niż sekundę. Było to z pewnością znacznie szybsze niż się spodziewałem i całkiem użyteczne. Jedną z rzeczy, o których nie myślałem, było to, że przy indeksowaniu tabeli w ten sposób plik indeksu również miał prawie 500 GB, więc posiadanie tabeli o szerokości 240 kolumn z pewnością zaoszczędziłoby dużo miejsca na dysku.

W Postgres elegancko rozwiązałbym to za pomocą typu tablic lub varray w Oracle.

Nie wiem, czy jest to przydatne w przypadku twojego problemu, ale w przypadku kolumn nie muszę wysyłać bezpośrednich żądań (cols, których nigdy nie umieszczam w warunku WHERE) i które mają charakter informacyjny tylko wtedy, gdy chcę uzyskać wszystkie informacje o niektórych konkretne wiersze, łączę je w polu blogu sformatowanym JSON.

Prawdopodobnie ostateczna decyzja projektu zależałaby od rozkładu zapytanych parametrów_id. To znaczy, jeśli istnieje kilka pytań o parametr_id, które są prawie wyłącznie pytane, umieściłbym ich wartości w gorącej tabeli, a pozostałe wartości w innej zimnej tabeli .

Oto, jeśli ich rozkład zapytań jest mniej więcej równy, załadowałbym przykładowy zestaw warty kilka dni do tabeli, w której jeden rekord przechowuje wszystkie wartości, aby zobaczyć jaki jest stosunek między rekordami / blokami db (lub jeśli istnieje nawet problem łączenia łańcuchów w rzędy , co jest prawdopodobne). W zależności od tego podjąłbym następnie inną decyzję projektową.

Cóż, po przeczytaniu go prawdopodobnie wykonałbym oba podejścia równolegle w celu uzyskania odwagi.

Czytałem ponownie pytanie - jeśli mam to prawidłowe, to w każdym rekordzie, który otrzymujesz jako dane wejściowe, śledzone są różne wartości (w oparciu o ParameterID):

Parametr ID odnosi się do innej tabeli, która przechowuje nagłówki kolumn wejściowych (200,00 202,50 205,00 ...).

... Nie wiem wystarczająco dużo o tym, jak wchodzisz w interakcję z danymi, ale byłbym skłonny przejść do innej opcji - mieć osobną tabelę dla każdego identyfikatora parametru, a następnie, jeśli to konieczne, mieć widok, który połącz różne parametry według daty i lokalizacji w szerszą (240 kolumna) tabelę; jeśli ważne było, aby DataID był dostępny w widoku, można użyć UNIONraczej zamiast a JOIN, ale kolumny będą słabo wypełnione.