Piszę aplikację, która musi przechowywać i analizować duże ilości danych elektrycznych i temperaturowych.
Zasadniczo muszę przechowywać duże ilości godzinowych pomiarów zużycia energii elektrycznej przez ostatnie kilka lat i przez wiele lat, aby dotrzeć do dziesiątek tysięcy lokalizacji, a następnie przeanalizować dane w niezbyt skomplikowany sposób.
Informacje, które muszę przechowywać (na razie) to identyfikator lokalizacji, znacznik czasu (data i godzina), temperatura i zużycie energii elektrycznej.
Jeśli chodzi o ilość danych, które należy przechowywać, jest to przybliżone, ale coś w tym stylu: ponad
20 000 lokalizacji, 720 rekordów miesięcznie (pomiary godzinowe, około 720 godzin miesięcznie), 120 miesięcy (10 lat wstecz ) i wiele lat w przyszłość. Proste obliczenia dają następujące wyniki:
20 000 lokalizacji x 720 zapisów x 120 miesięcy (10 lat wstecz) = 1 728 000 000 zapisów .
Są to przeszłe rekordy, nowe rekordy będą importowane co miesiąc, więc jest to około 20 000 x 720 = 14 400 000 nowych rekordów miesięcznie .
Łączna liczba lokalizacji będzie również stale rosła.
Na wszystkich tych danych należy wykonać następujące operacje:
- Pobierz dane dla określonej daty ORAZ okresu: wszystkie rekordy dla określonego identyfikatora lokalizacji między datami 01.01.2013 a 01.01.2017 oraz między 07:00 a 13:00.
- Proste operacje matematyczne dla określonego zakresu ORAZ czasu, np. Temperatura MIN, MAX i AVG oraz zużycie energii elektrycznej dla określonego identyfikatora lokalizacji przez 5 lat od 07:00 do 13:00.
Dane będą zapisywane co miesiąc, ale będą odczytywane przez setki użytkowników (przynajmniej) stale, więc szybkość odczytu ma znacznie większe znaczenie.
Nie mam doświadczenia z bazami danych NoSQL, ale z tego, co zebrałem, są one najlepszym rozwiązaniem do zastosowania tutaj. Czytałem o najpopularniejszych bazach danych NoSQL, ale ponieważ są one całkiem różne i pozwalają na bardzo różną architekturę tabel, nie byłem w stanie zdecydować, która baza danych jest najlepsza do użycia.
Moimi głównymi wyborami były Cassandra i MongoDB, ale ponieważ mam bardzo ograniczoną wiedzę i nie mam prawdziwego doświadczenia, jeśli chodzi o duże dane i NoSQL, nie jestem bardzo pewien. Przeczytałem również, że PostreSQL dobrze radzi sobie z takimi ilościami danych.
Moje pytania są następujące:
- Czy powinienem używać bazy danych NoSQL dla tak dużych ilości danych. Jeśli nie, mogę trzymać się MySQL?
- Jakiej bazy danych powinienem użyć?
- Czy powinienem przechowywać datę i godzinę w osobnych, indeksowanych (jeśli to możliwe) kolumnach, aby szybko pobierać i przetwarzać dane dla określonych okresów czasu i dat, czy też można to zrobić, przechowując znacznik czasu w jednej kolumnie?
- Czy właściwe jest tutaj modelowanie danych szeregów czasowych, a jeśli nie, możesz podać mi wskazówki dotyczące dobrego projektu tabeli?
Dziękuję Ci.
Odpowiedzi:
Dokładnie to robię na co dzień, ale zamiast danych godzinowych korzystam z danych 5-minutowych. Codziennie pobieram około 200 milionów płyt, więc kwota, o której tu mówisz, nie stanowi problemu. Dane 5-minutowe mają rozmiar około 2 TB, a dane pogodowe sięgają 50 lat wstecz co godzinę według lokalizacji. Pozwól, że odpowiem na pytania na podstawie mojego doświadczenia:
Porada ogólna: przechowuję większość danych między dwiema bazami danych, pierwsza to dane z szeregów czasowych i jest znormalizowana. Moja druga baza danych jest bardzo zdenormalizowana i zawiera wstępnie zagregowane dane. Tak szybki jak mój system, nie jestem ślepy na fakt, że użytkownicy nawet nie chcą czekać 30 sekund na załadowanie raportu - nawet jeśli osobiście uważam, że 30 sekund na złamanie 2 TB danych jest wyjątkowo szybkie.
Aby wyjaśnić, dlaczego zalecam przechowywanie godziny oddzielnie od daty, oto kilka powodów, dla których robię to w ten sposób:
DATETIME
kolumna.Jak powiedziałem powyżej, wszystko opiera się na moim osobistym doświadczeniu i powiem wam, że ciężko było kilka lat i wiele przeprojektowań, aby dotrzeć do tego, gdzie jestem teraz. Nie rób tego, co zrobiłem, ucz się na własnych błędach i upewnij się, że angażujesz użytkowników końcowych twojego systemu (lub programistów, autorów raportów itp.) W podejmowanie decyzji dotyczących bazy danych.
źródło
Indeksy PostgreSQL i BRIN
Sprawdź to sam. To nie jest problem na 5-letnim laptopie z dyskiem SSD.
Utworzenie tabeli zajęło więc 22 minuty. W dużej mierze, ponieważ stół jest skromny 97 GB. Następnie tworzymy indeksy,
Tworzenie indeksów zajęło też sporo czasu. Chociaż są BRIN, mają tylko 2-3 MB i łatwo przechowują w pamięci RAM. Czytanie 96 GB nie jest natychmiastowe, ale nie jest to prawdziwy problem dla mojego laptopa przy twoim obciążeniu.
Teraz pytamy o to.
Zaktualizuj za pomocą znaczników czasu
Tutaj generujemy tabelę z różnymi znacznikami czasu w celu zaspokojenia żądania indeksowania i wyszukiwania w kolumnie znacznika czasu, tworzenie zajmuje trochę dłużej, ponieważ
to_timestamp(int)
jest znacznie wolniejsze niżnow()
(które jest buforowane dla transakcji)Teraz możemy zamiast tego uruchomić zapytanie dotyczące wartości znacznika czasu,
Wynik:
Tak więc w 83,321 ms możemy agregować 86 401 rekordów w tabeli zawierającej 1,7 miliarda wierszy. To powinno być rozsądne.
Godzina zakończenia
Obliczanie zakończenia godziny jest również dość łatwe, skróć znaczniki czasu, a następnie po prostu dodaj godzinę.
Ważne jest, aby pamiętać, że nie używa indeksu w agregacji, choć może. Jeśli to jest twoje typowe zapytanie, prawdopodobnie potrzebujesz BRIN na
date_trunc('hour', tsin)
tym polega niewielki problem, którydate_trunc
nie jest niezmienny, więc musisz najpierw go owinąć, aby tak było.Partycjonowanie
Innym ważnym punktem informacji na temat PostgreSQL jest to, że PG 10 przynosi partycjonowanie DDL . Możesz na przykład łatwo tworzyć partycje na każdy rok. Podział skromnej bazy danych na mniejsze, małe. Robiąc to, powinieneś być w stanie używać i utrzymywać indeksy btree zamiast BRIN, co byłoby jeszcze szybsze.
Lub cokolwiek.
źródło
Dziwi mnie, że nikt tutaj nie wspominał o testach porównawczych - to znaczy, dopóki @EvanCarroll nie przyszedł ze swoim doskonałym wkładem!
Gdybym był tobą, poświęciłbym trochę czasu (i tak, wiem, że jest to cenny towar!) Konfigurując systemy, uruchamiając to, co według ciebie będzie (uzyskaj informacje od użytkowników końcowych tutaj!), Powiedzmy, twoje 10 najczęstszych zapytań.
Moje własne myśli:
Rozwiązania NoSQL mogą działać bardzo dobrze w określonych przypadkach użycia, ale często są mało elastyczne w przypadku zapytań ad-hoc. Zabawne spojrzenie na NoSQL autorstwa Briana Akera - byłego głównego architekta MySQL - patrz tutaj !
Zgadzam się z @ Mr.Brownstone, że twoje dane doskonale pasują do rozwiązania relacyjnego (i ta opinia została potwierdzona przez Evana Carrolla )!
Gdybym zobowiązał się do jakichkolwiek wydatków, byłoby to związane z moją technologią dyskową! Wydawałbym wszelkie pieniądze, które miałem do dyspozycji, na NAS lub SAN, a może niektóre dyski SSD, aby przechowywać moje rzadko zapisywane dane zbiorcze!
Najpierw przyjrzę się temu, co mam teraz dostępne . Przeprowadź kilka testów i pokaż wyniki decydentom. Masz już pełnomocnika w formie pracy EC ! Ale szybki test lub dwa połączone na twoim sprzęcie byłyby bardziej przekonujące!
Następnie pomyśl o wydawanie pieniędzy! Jeśli zamierzasz wydawać pieniądze, najpierw spójrz na sprzęt, a nie na oprogramowanie. AFAIK, możesz wynająć technologię dyskową na okres próbny, lub jeszcze lepiej, wypróbować kilka dowodów koncepcji w chmurze.
Moim osobistym pierwszym portem do takiego projektu byłby PostgreSQL. Nie oznacza to, że wykluczyłbym zastrzeżone rozwiązanie, ale prawa fizyki i dysków są takie same dla wszystkich! „Yae cannae burta prawa fizyki Jim” :-)
źródło
Jeśli jeszcze tego nie zrobiłeś, spójrz na DBMS z szeregów czasowych, ponieważ jest on zoptymalizowany do przechowywania i wysyłania zapytań do danych, gdzie głównym celem jest typ daty / godziny. Zazwyczaj bazy danych szeregów czasowych są używane do rejestrowania danych w zakresach minut / sekunda / sub-sekund, więc nie jestem pewien, czy nadal jest odpowiedni dla przyrostów godzinowych. To powiedziawszy, wydaje się, że warto przyjrzeć się tego rodzaju DBMS. Obecnie InfluxDB wydaje się być najbardziej popularną i powszechnie stosowaną bazą danych szeregów czasowych.
źródło
Oczywiście nie jest to problem NoSQL, ale sugerowałbym, że chociaż rozwiązanie RDBMS mogłoby działać, myślę, że podejście OLAP będzie pasować znacznie lepiej, a biorąc pod uwagę bardzo ograniczone zakresy danych, zdecydowanie sugeruję zbadanie zastosowania bazy danych opartej na kolumnie zamiast jednego opartego na wierszach. Pomyśl o tym w ten sposób, możesz mieć 1,7 miliarda danych, ale nadal potrzebujesz tylko 5 bitów, aby zindeksować każdą możliwą wartość godziny lub dnia miesiąca.
Mam doświadczenie z podobną problematyczną domeną, w której Sybase IQ (obecnie SAP IQ) służy do przechowywania do 300 milionów liczników na godzinę danych zarządzania wydajnością sprzętu telekomunikacyjnego, ale wątpię, czy masz budżet na tego rodzaju rozwiązanie. Na arenie open source MariaDB ColumnStore jest bardzo obiecującym kandydatem, ale poleciłbym również zbadanie MonetDB.
Ponieważ wydajność zapytań jest dla Ciebie głównym czynnikiem, rozważ, w jaki sposób zapytania będą sformułowane. Tutaj OLAP i RDBMS pokazują swoje największe różnice: - dzięki OLAP normalizujesz wydajność zapytań, nie zmniejszając liczby powtórzeń, zmniejszając ilość pamięci, a nawet wymuszając spójność. Oprócz oryginalnego znacznika czasu (mam nadzieję, że pamiętasz uchwycenie jego strefy czasowej?) Masz osobne pole dla znacznika czasu UTC, inne dla daty i godziny, a jeszcze więcej dla roku, miesiąca, dnia, godziny, minuty i przesunięcie UTC. Jeśli masz dodatkowe informacje o lokalizacjach, możesz zachować je w osobnej tabeli lokalizacji, którą można sprawdzić na żądanie, i zachowaj klucz do tej tabeli w głównym rekordzie, ale zachowaj pełną nazwę lokalizacji w głównej tabeli jako w końcu
Ostateczna sugestia: użyj osobnych tabel dla popularnych danych zagregowanych i użyj zadań wsadowych do ich zapełnienia, dzięki czemu nie musisz powtarzać ćwiczenia dla każdego raportu, który używa zagregowanej wartości i sprawia, że zapytania porównują bieżące z historycznymi lub od historycznego do historycznego o wiele łatwiej i znacznie, znacznie szybciej.
źródło