Databáze podobná RRD – MySQL – Fórum – Programujte.com

Zdravím, do db ukládám kažkou minutu svá data z meteostanice.Poté následně kreslím grafy (denní, týdenní, měsíční, roční,...) A potřebuji mít možnost koukat podrobně na libovolný den zpětně. Takže v jedné tabulce budou všechny data. Pak ale při vykreslování grafu za dlouhé období načítám značné množství dat. Napadlo mi udělat více tabulek, kde by byli třeba hodnoty po hodině, 12h,.... Šli by ty tabulky vytvářet přes trigery? Je zapotřebí duplikovat celý obsah řádku? Záznamy v původní tabulce nejsou vždy po minutě(výpadky elektřiny, údržba,...). Jaké zvolit efektivní řešení?

http://dev.mysql.com/doc/refman/5.6/en/features.html

Support for large databases. We use MySQL Server with databases that contain 50 million records. We also know of users who use MySQL Server with 200,000 tables and about 5,000,000,000 rows.

pokud se bojis o kapacitu tabulky tak bych se asi nebal. a proc ze to neresis pres where klauzuli?

#2 p3can
Myslíš jednu tabulku se vším a přes WHERE dostat dostat hodinové průměry? To nevím jak. Nicméně i tak se budu přehrabovat v db a vybírat jen pár dat.

#3 Pavelv 

SELECT date(ts) AS dd, hour(ts) AS hh, avg(teplota) AS prumer
    FROM meteo GROUP BY dd, hh;

Pokud chceš pracovat jen s částí velkého objemu dat, vytvoříš si dočasnou tabulku a nebo pohled, naplníš ji nebo ho podmnožinou dat se kterou chceš pracovat. Dočasná tabulka je pomalejší při vytváření, ale každý klient má svou. Ve složitějších selectech s dočasnou tabulkou může být problém - Can´t reopen table. Pohled je rychlejší, ale je pro celou db jako běžná tabulka. Pohledy lze vytvářet s unikátními názvy a tím klienty od sebe "izolovat", řešilo se to tu nedávno.

hu

#4 Kit
No ale tim nezískám pole hodnot např. za celý měsíc, kde každá hodnota průměrována cca 60 vzorky(hodinou)

#6 Pavelv
Jak to že ne? Mně to krásně funguje. V čem vidíš problém? 

CREATE TABLE `meteo` (
  `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
       ON UPDATE CURRENT_TIMESTAMP,
  `teplota` float(6,2) DEFAULT NULL
) ENGINE=InnoDB;

INSERT INTO `meteo` VALUES
('2014-06-10 00:14:55',23.50),
('2014-07-10 00:01:38',23.40),
('2014-07-10 00:01:45',23.20),
('2014-07-10 00:01:54',23.10),
('2014-07-10 00:02:00',23.00),
('2014-07-10 00:02:10',22.90),
('2014-07-10 00:02:14',22.80),
('2014-07-10 00:02:18',22.70),
('2014-07-10 00:04:25',22.60),
('2014-07-10 08:55:06',22.60);

SELECT date(ts) AS d, hour(ts) AS h, avg(teplota) AS hodinovka
    FROM meteo GROUP by d, h;

Objem dat lze redukovat "vzorkováním" - vybereš např každou pátou hodnotu. Rozestup mezi hodnotami je dobré odvodit od rozlišení grafu - kolik bodů může fakticky vykreslit (v závislosti na rozlišení monitoru je to několik set bodů). 

Chceš vykreslovat graf "hodinové průměry teplot"? Tzn zprůměrovat každou hodinu jako samostatný průměr a pak vykreslit graf průměrů za např. 28 hodin?

hu

#7 Kit
Jojo už to běhá, jen šlo by udělat i jiný průměr? Třeba dvouhodinový, půldenní,..

#9 Pavelv
Šlo, jen to chce zapojit trochu fantazie. Například šestihodinový 

SELECT date(ts) AS d,
    hour(ts) - hour(ts)mod 6 AS h6,
    avg(teplota) AS hodinovka
    FROM meteo GROUP by d, h6;

Tomuto sa podla mna hovori ist s kanonom na vrabce. Za 10 rokov budes mat asi oklo 5.3e6 zaznamov. Na tvojom mieste by som to s kludnym svedomim ukladal ako plain text. Ale zalezi o co ti ide. Ak ti ide o to naucit sa nieco s mysql tak potom v poriadku. A tam tiez nemusis nic velmi riesit. Skus floor (dolna cela cast) SELECT avg(teplota), day(ts) as dd, hour(ts) AS hh FROM meteo GROUP BY dd, FLOOR(hh/2);  Aj ked nebude to uplne ono na to aby ti to pocitalo kazde 2 hod od zaciatku by si potreboval vediet kolko bolo hod. na zaciatky a to odratat od sucasneho casu.

#11 sleepy
Jakou výhodu bude mít 5.3e6 záznamů v plain textu? Aspoň CSV.

Vyhody: uspora casu. Zariadenie na ktorom to bezi nevyzaduje mysql. Nemusi sa ucit SQL (ale to patri do uspory casu). Moze si ulozit {1,2,3,...,n} hodinove priemery a uz ich nemusi nikdy pocitat, aj ked toto sa da aj v mysql. Dokonca ak by chcel nejaky dlhodoby priemer k-hodin kde k == 0 (mod n1) tak mu staci orobit priemer s n1 zaznamov. Tieto zaznami su prirodzene dobre usporiadane a navyse sa uz nebudu menit. Ci uz pouzije csv, xmolocha alebo nieco ine je len na nom. Ale ak mu ide o to naucit sa sql, tak len smelo do toho.

#13 sleepy
Jestli tím xmolochem myslíš XML, tak ten se na logování vůbec nehodí.

Jen je trochu problém u těch textových souborů udržet konzistenci.

Co se týká předpočítaných hodinových průměrů, tak to MySQL zvládne hravě. Umí to i SQLite, pokud bys nechtěl jít s kanónem na vrabce. Je to takový rozumný kompromis mezi MySQL a textem.

Jen tak na závěr: MySQL pracuje i s engine=CSV. Takže primární data se logují do CSV a trigger updatuje hodinové a denní průměry, které mohou být v MyISAM nebo InnoDB.