MySQL:Dzielenie dużej tabeli na partycje czy osobne tabele?

Cóż, jeśli liczysz na nową odpowiedź, oznacza to, że prawdopodobnie przeczytałeś moje odpowiedzi, a ja brzmię jak zdarta płyta. Zobacz Blog o partycjonowaniu dla nielicznych przypadków użycia, w których partycjonowanie może poprawić wydajność. Twój nie brzmi jak którykolwiek z 4 przypadków.

Zmniejsz device_id . INT ma 4 bajty; czy naprawdę masz miliony urządzeń? TINYINT UNSIGNED to 1 bajt i zakres od 0..255. SMALLINT UNSIGNED to 2 bajty i zakres 0..64K. To trochę zmniejszy stół.

Jeśli Twój prawdziwy Pytanie dotyczy tego, jak zarządzać tak dużą ilością danych, więc „pomyślmy nieszablonowo”. Czytaj dalej.

Wykresy... Jakie zakresy dat wykreślasz?

• „Ostatnia” godzina/dzień/tydzień/miesiąc/rok?
• Dowolna godzina/dzień/tydzień/miesiąc/rok?
• Dowolny zakres, niezwiązany z granicami dnia/tygodnia/miesiąca/roku?

Co rysujesz?

• Średnia wartość w ciągu dnia?
• Maks./min. w ciągu dnia?
• Świeczniki (itp.) na dzień, tydzień czy cokolwiek?

Niezależnie od przypadku należy zbudować (i stopniowo utrzymywać) tabelę podsumowującą z danymi. Wiersz zawierałby informacje podsumowujące z jednej godziny. Proponuję

CREATE TABLE Summary (
    device_id SMALLINT UNSIGNED NOT NULL,
    sensor_id TINYINT UNSIGNED NOT NULL,
    hr TIMESTAMP NOT NULL,
    avg_val FLOAT NOT NULL,
    min_val FLOAT NOT NULL,
    max_val FLOAT NOT NULL
    PRIMARY KEY (device_id, sensor_id, hr)
) ENGINE=InnoDB;

Jedna tabela podsumowująca może mieć 9 GB (dla aktualnej ilości danych).

SELECT hr,
       avg_val,
       min_val,
       max_val
    FROM Summary
    WHERE device_id = ?
      AND sensor_id = ?
      AND hr >= ?
      AND hr  < ? + INTERVAL 20 DAY;

Daje ci wartości hi/lo/avg na 480 godzin; wystarczy do wykresu? Pobranie 480 wierszy z tabeli podsumowań jest znacznie szybsze niż pobranie 60*480 wierszy z tabeli surowych danych.

Uzyskanie podobnych danych przez rok prawdopodobnie zablokowałoby pakiet graficzny, więc może warto zbudować podsumowanie podsumowania - z rozdzielczością dnia. Byłoby to około 0,4 GB.

Istnieje kilka różnych sposobów budowania tabeli(ów) podsumowania; możemy o tym porozmawiać po zastanowieniu się nad jego pięknem i przeczytaniu Blog z tabelami podsumowania . Być może najlepszym sposobem jest zebranie danych z godziny, a następnie powiększenie tabeli podsumowania. To byłoby trochę jak omawiany flip-flop mój blog dotyczący tabeli Stagingu .

A jeśli masz podsumowania godzinowe, czy naprawdę potrzebujesz danych minuta po minucie? Rozważ wyrzucenie go. A może dane po, powiedzmy, miesiącu. Prowadzi to do korzystania z partycjonowania, ale tylko dla jego korzyści w usuwaniu starych danych jak omówiono w „Przypadku 1” Blog o partycjonowaniu . Oznacza to, że miałbyś codzienne partycje, używając DROP i REORGANIZE co noc przesuwać czas w tabeli „Fakt”. Doprowadziłoby to do zmniejszenia rozmiaru 145 GB, ale bez utraty dużej ilości danych. Nowy ślad:około 12 GB (podsumowanie godzinowe + szczegóły minuta po minucie z ostatnich 30 dni)

PS:Blog z podsumowaniem pokazuje, jak uzyskać odchylenie standardowe.