[loginek0]

Mam prostą bazę w #mysql, gdzie zbieram sobie dane z czujnika. Są to:
idurządzenia, temp, wilgotność, coś tam jeszcze.
Wpisów mam już dość dużo (około 100mln - nie pytać czemu, tak ma być :) ). Zastanawiam się nad zmianą silnika bazodanowego, aby w przyszłości to działało szybko. Aktualnie gdy pobieram dane do wykresów czy jakiś obliczeń to trwa to już coraz dłużej. Co byście polecili? Myślałem o NoSQL lub #elasticsearch , ale czy faktycznie będzie taki przeskok wydajności?
Główne zapytania jakie chce to np. pobierz temp z okresu X-Y dla idurzadzenia = Z. Wynik zwraca nawet i kilkanaście tysięcy (a w przyszłości milionów) rekordów. Oczywiście może dość grupowanie gdy np. będę chciał aby pobrało 1 rekord na tydzień ale z przedziału 5 lat.

#programowanie #bazydanych #php (bo dane te będę obrabiał w php - ewentualnie dorobię jakieś api, ale końcówka zawsze będzie php)

[janek_]

A na tym mysqlu w miarę sensownie wykorzystujesz np. indeksy albo partycjonowanie?

[Supaplex]

@loginek0: Jak jak kolega @janek_: napisał, trzeba wziąć zapytanie, które zwraca wynik zbyt długo i przejrzeć jego testplan. Jak wynik jest słaby to zwiększanie IO czy silnika bazy danych nic nie zmieni, jeśli nie poprawisz struktury danych

[filip_k]

@loginek0: Przecież tutaj nie potrzebujesz bazy danych jako takiej, tylko takiej, co Ci przechowuje time-series.
Na przykład: https://prometheus.io/docs/introduction/overview/

[Narrorek]

@loginek0: Timeseries database

[loginek0]

@janek_: Tak tak, tutaj mam zoptymalizowane tak jak ma być. Nie słyszałem o partycjonowaniu - dzięki, poczytam jeszcze.

[b0rn2frag]

@loginek0: PostgreSQL+TimescaleDB

[janek_]

@loginek0: na Stacku znalazłem post na temat pokrewny Twojemu problemowi. https://dba.stackexchange.com/questions/190756/what-is-the-optimal-solution-for-storing-real-time-time-series-in-mariadb-mysq