Jak agregować dane według daty i czasu?

Obecnie korzystamy z tabeli podsumowującej, która gromadzi informacje dla naszych użytkowników co godzinę w czasie UTC. Problem w tym, że ten stół staje się zbyt duży i ogromnie spowalnia nasz system. Zrobiliśmy wszystkie techniki strojenia zalecane dla PostgreSQL i wciąż doświadczamy powolności.Jak agregować dane według daty i czasu?

Naszym zamiarem było rozpoczęcie agregacji według dnia, a nie godziny, ale problem polega na tym, że pozwalamy naszym klientom zmienić strefę czasową, która przelicza dane na ten dzień.

Czy ktoś wie o sposobie przechowywania podsumowania dziennego, ale nadal przestrzega liczb i sum, kiedy przełącza strefy czasowe?

Źródło

2010-08-06 Russ Bradberry

Czy mówimy potencjalnie wszystkie strefy czasowe na Ziemi? – MPelletier

Ściśle mówiąc w przypadku modelowania danych, tracisz szczegółowość strefy czasowej, gdy idziesz do granularności dnia. Ale możesz zagregować według strefy czasowej, szczególnie jeśli odpowiedź na pytanie @ MPelletiera brzmi "Nie". – bobs

@ MPellier agregujemy teraz przez godzinę, więc obsługujemy tylko strefy czasowe, które są "na godzinę" –

Podsumuj dane w tabelach z kolumną przesunięcia czasowego i pole "dzień" (data), które jest dniem dla danej linii podsumowania. Indeksuj (przesunięcie czasowe, dzień, inne odpowiednie pola), jeśli to możliwe, w klastrze (przypuszczalnie PostgresSQL ma indeksy klastrowe?) I wszystko powinno być dobrze.

Źródło

2010-08-06 22:39:16

Tak więc, zamiast 24 linii dziennie, jeden dzień wytworzyłby jedną linię ... razy 24 strefy czasowe. Nie widzę tutaj znacznego zysku. – MPelletier

Myślałem o tym, ale potem muszę utrzymać 24 tabele podsumowujące, które również zwiększą możliwość różnicy w raportowaniu między strefami czasowymi. –

@ Melletier - różnica polega na tym, że nie musisz agregować 24 wierszy na jeden dzień, aby wytworzyć dzienną liczbę - wyciągasz jedną linię podsumowującą dla danego przedziału czasowego/dnia - więc robisz 1/24 praca - z odpowiednim indeksowaniem oczywiście. –

Zakładam, że przeszedłeś wszystkie kwestie dotyczące partycjonowania, na przykład partycjonowanie według użytkownika.

Widzę kilka rozwiązań twojego problemu, w zależności od wzoru użycia.

Dane zagregowane dziennie, według wyboru użytkownika. W przypadku zmiany strefy czasowej należy ponownie przeliczyć agregat dla tego partnera. Jest to prawdopodobne, jeśli zmiany strefy czasowej są rzadkie i jeśli pewne opóźnienie w danych może zostać wprowadzone, gdy użytkownik zmieni strefy czasowe.
Jeśli masz stosunkowo mało miar, możesz zachować 24 kolumny dla każdej miary - każda opisuje dzienny agregat dla miary w innej strefie czasowej.
Jeśli zmiany strefy czasowej są częste i istnieje wiele działań, wydaje się, że 24 różne tabele zbiorcze byłyby drogą do zrobienia.

Źródło

2010-08-07 22:58:21 shmichael

Zmiany stref czasowych są w rzeczywistości stosunkowo niewielkie. mogłem programowo przeliczać miary w oparciu o zmianę, ale pierwsza zmiana miałaby znaczące opóźnienie. Mamy około 8 miar, 24 kolumny na miarę nie byłoby dobrym pomysłem. im zacząć myśleć, że 24 stoły to droga. zajrzałem do rozwiązania @Will A's i może być opłacalne z kolumną db. ale nie w przypadku bazy danych, która pogarsza się z liczbą wierszy. –

192 kolumn całkowitych nie jest tak źle, faktycznie. A jeśli będziesz używać kolumnowego DB, nie sądzę, że będziesz potrzebował jakiejkolwiek zmiany schematu - przynajmniej nie z wyżej wymienionym problemem. – shmichael

Ten problem został rozwiązany. Przyjmuję to rozwiązanie: dane z typem daty używają lokalnej strefy czasowej, inne dane o typie datetime używają strefy czasowej UTC, ponieważ indeks statystyki jest lokalny. Innym powodem jest to, że mamy tylko dane lokalne.

Źródło

2016-04-26 07:53:47 tinyJason

Jak agregować dane według daty i czasu?

Odpowiedz

Powiązane problemy