Przechowywanie ogromnych ilości danych z matrycy czujników

Zadanie polegało na wdrożeniu rozwiązania (aplikacji i bazy danych) do przechowywania próbek danych z ogromnej matrycy czujników. Tablica składa się obecnie z około 20 000 czujników, ale wkrótce będzie rosnąć, do 100 000 czujników. Każdy czujnik wysyła próbkę danych co 10 sekund, a każda próbka ma rozmiar 28 bajtów.

Wykonywanie sum prowadzi zatem do:

• 8640 próbek na czujnik dziennie
• 242kB danych na czujnik dziennie
• 864 miliony próbek dziennie

Teraz zastanawiam się, jaki byłby najlepszy sposób przechowywania / odzyskiwania danych? „Przyłączyłem się” do tego projektu po tym, jak oprogramowanie zostało już określone, dlatego należy je zaimplementować na platformie Windows za pomocą programu SQL Server.

Obecne rozwiązanie w mojej głowie polega na utworzeniu bazy danych z dwiema tabelami do przechowywania próbek danych. Pierwszy służy jako swego rodzaju indeks do drugiego, który przechowuje zebrane próbki w polu binarnym na dzień na podstawie czujnika:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

Zasadniczo napiszę próbki ze wszystkich czujników do plików tymczasowych (1 na czujnik). Na koniec każdego dnia utworzę wpis w tabeli 1, użyj wygenerowanego identyfikatora RecordID i zrzuć plik do pola danych w tabeli 2.

W ten sposób otrzymuję tylko 100 000 wpisów dziennie, zamiast 864 milionów wpisów. Dane powinny być dostępne w sieci LAN lub High Speed ​​WAN, więc pobieranie danych z czujników przez cały dzień byłoby dopuszczalne.

Chociaż wszystkie dane muszą być przechowywane, większość z nich prawdopodobnie nigdy nie zostanie odczytana. Tak więc ilość odczytów na stole (stołach) nie będzie znacznie większa niż liczba zapisów.

Wiem, że mogłem zaimplementować coś przy użyciu systemu plików, po prostu przechowując ścieżkę do plików danych, ale przeczytałem, że SQL Server przewyższa NTFS, podczas gdy twoje pola binarne są mniejsze dzięki 256kB. (Szary obszar istnieje od 256 kB do 1 MB, podczas gdy NTFS znacznie przewyższa SQL Servera dla rozmiarów binarnych> 1 MB).

Nieufnie też przechowuję dane ze 100 000 czujników we własnych plikach bez powodowania problemów w systemie plików, ponieważ albo mają ogromne ilości plików w folderze, albo mają złożoną strukturę drzewa z kilkoma plikami w każdym folderze, chociaż nie nawet biorąc pod uwagę fragmentację plików.

1. Czy ktoś może zaoferować mi praktyczne porady / komentarze na powyższe tematy?

2. Czy są oczywiste pułapki, w które wpadnę?

3. Przykładowe dane dość dobrze się kompresują. Plik 242 kB kompresuje się do około 85 kB. Czy mogę jednak wdrożyć pewien rodzaj kompresji na poziomie bazy danych, aby przykładowe dane (kolumna) były kompresowane automatycznie?

4. Czy SQL Server jest oczywiście złym wyborem dla tego projektu?

5. Czy mój projekt dwóch stołów jest mądry, czy równie dobrze mogę połączyć go w jeden stół, który nadal będzie tak „wydajny” jak dwa stoły?

Tak, istnieje dość duży pułapek, na który wpadniesz dość szybko, a to z powodu wielkości i utrzymania stołów. Jesteś trochę na dobrej drodze, mówiąc, że chcesz codziennie umieszczać swoje dane w tymczasowej tabeli, a następnie przenieść je do stałej tabeli, ale wkrótce będziesz miał kłopoty z tym schematem.

Załóżmy na przykład, że chcesz „wycofać” dane z najstarszego miesiąca po dwóch latach. W swoim projekcie musiałbyś wydać instrukcję DELETE na swoim dużym, dużym stole. Będzie to prawdopodobnie nieco powolne, w zależności od liczby posiadanych indeksów. Spowoduje to również fragmentację indeksów, a jedynym sposobem na naprawę byłoby przebudowanie lub reorganizację indeksów w tej bardzo dużej tabeli, co również spowodowałoby problemy z wydajnością. Istnieje również wiele innych problemów z dużym projektem pojedynczego stołu. Na przykład przy dużym pojedynczym stole nie można wykonywać kopii zapasowych opartych na FILEGROUP , co oznacza, że ​​jeśli chcesz mieć pełną kopię zapasową bazy danych, będzie WIELKA i jej wykonanie zajmie DŁUGO czasu.

Jakie jest rozwiązanie Partycjonowanie tabeli. Przeczytaj o tym dogłębnie, w jak największej liczbie miejsc. Zasadniczo partycjonowanie pozwala podzielić dane na „tabele w tabelach” - każda partycja ma ten sam schemat i jest dostępna przez obiekt tabeli, ale może być indeksowana i utrzymywana w inny sposób. Partycje to w zasadzie tabele podzielone na użyteczny klucz. W twoim przypadku prawdopodobnie będzie to data. Można je usuwać tak jak (i ​​tak szybko jak) tabele, co oznacza, że ​​jeśli podzielisz tabele dużych zbiorów danych według daty, możesz po prostu natychmiast usunąć stare partycje, bez negatywnego wpływu na indeksy na żadnej innej partycji. Możesz umieścić partycje na różnych aplikacjach, co oznacza, że ​​starsze partycje można wycofać lub przenieść na tańsze przechowywanie towarów, jeśli nie jest to powszechnie używane. Wreszcie, w SQL 2012: „na starszych partycjach tylko do odczytu , mając jednocześnie inny, bardziej zorientowany na wstawianie schemat indeksowania na aktywnej partycji, na której wstawiasz wszystkie dane z czujnika.

Mam nadzieję że to pomoże. Masz dużo badań do zrobienia na temat partycjonowania i schematów partycjonowania, ale mam nadzieję, że teraz znasz kierunek, w którym musisz patrzeć.

PS: Och, i zapomniałem wypunktowaną listę pytań ... Odpowiedz 1, 2 i 5. Patrz wyżej. Odpowiedź 3: W SQL Server możesz kompresować partycję według partycji, więc agresywnie kompresuj starsze partycje za pomocą kompresji PAGE. Uważam jednak, że jeśli tego nie zrobisz, duże typy danych poza wierszem nie będą kompresowane - ponownie możesz rozwiązać ten problem poprzez normalizację wartości czujników. Odpowiedź 4: Absolutnie nie, ale jeśli wszystko, co chcesz zrobić, to przechowywać dane statyczne w ciągu dnia i nigdy ich nie wyszukiwać w inny sposób, skompresowane pliki płaskie mogą być znacznie łatwiejszą drogą.

PPS: Aha i jeszcze jedno. Nie potrzebujesz rozwiązania z dwoma stołami, aby wszystko działało. Duże dane czujnika binarnego powinny być typu VARBINARY (MAX), ponieważ ich wartości mogą być przechowywane „ poza wierszem ”, ale nadal mogą być kolumną w pojedynczej tabeli (patrz dokumentacja sp_tableoption ). Możesz jednak rozważyć normalizację niektórych danych z czujników z danych binarnych, które masz w tabeli, ponieważ baza danych nie będzie przydatna, jeśli nie zrobisz tego z czasem.

Zastanów się nad rozwiązaniem Hadoop. 2 Tb / dzień sumuje się szybko. Rozważ także rejestrowanie tylko rekordów delta, tj. Wartości początkowej, i tylko wtedy, gdy nastąpi zmiana.