Zdravím, boli tu diskusie na bigdata a sú tu ľudia, čo do toho vidia, tak teda vyskúšam.

Mám veľa veľa dát zo staníc, ktoré merajú niekoľko vecí (teplotu apod.) Každý záznam zo stanice má teda cca 10 stĺpcov (čas a desatinné čísla).
Takáto stanica vyprodukuje za deň cca 5000 záznamov. Staníc je aktívnych 10 (takže dáta z nich stále pribúdajú), v budúcnosti ich ešte asi pribudne a ďalších cca 20 je neaktívnych (už dáta nepribúdajú)
Spolu mám z takýchto staníc dáta za posledných asi 8 rokov. Je to teda nejakých 100 miliónov záznamov, pričom každý deň (raz denne) pribudne cca 50 000 záznamov (5000 záznamov krát 10 staníc)

Moja otázka teda znie, akým spôsobom by som mohol uchovávať takéto data tak, aby sa s nimi pohodlne pracovalo?
Dnes sa ukladajú ako binárne súbory a keď sa k nim pristupuje, tak sa jednoducho čítajú a prevádzajú do textu. Tento prístup sa mi nepáči, tak hľadám nejakú krajšiu alternatívu, ktorá by dovoľovala rýchlo uložiť nové dáta a rýchlo ich aj čítať. Hlavne by som chcel selekciu podľa stĺpcov (to sa s bin. súbormi robí ťažko), preto chcem databázu. A tiež by som chcel mať možnosť zálohovania (kľudne aj manuálne, že zbaliť nejaké súbory a preniesť inam)

V databázach sa veľmi nevyznám a príliš sa mi nechce testovať každú, o ktorej prečítam, že to dokáže. Vraj aj MySQL by mala toľko dát zvládnuť, myslíte, že bude stačiť, alebo skôr doporučíte niečo iné?
Tiež si veľmi neviem predstaviť, ako by som (nie len mysql) databázu naplnil a jednorázovo tam napchal 50mil záznamov.

Budem rád za odpovede a nejakú diskusiu o možnostiach

Načítať toľko záznamov z MySQL bude vcelku stresujúce na server. Viem keď som mal na mojom webe pár tisíc príspevkov a chcem som ich cez PHP MyAdmin vymazať, tak kým to načítalo, tak aleluja.
Na webe sa ti to bude zobrazovať v pohode ak budeš vypisovať po cca 100 záznamoch na stránku.

Ps.: Upload toľkých záznamov do DB ti potrvá pomerne dlho.

Hold ale s DB nie som nejako veľmi pokročilý, takže toto ber len ako IRL skúsenosť s veľa riadkami v MySQL.

tak to si mal slabý server alebo iba zle nakofigurovaný. Prípadne zlý návrh databázy. Naša db tu na fore má cez 2,7GB a všetko v pohode svižne funguje.

skôr by som sa zamyslel na čo ti tie dáta treba a ako ich spracovávať. Treba vôbec evidovať všetky? Nestačí posledný rok? MySQL by to zvládnuť malo. Žiaden limit pre maximálny počet záznamov neexistuje. A jednotlivé záznamy nebudú zas tak náročné (žiaden text, blob...) takže tá db bude mať cca 3,7GB v hrubom odhade

mysql to v pohode zvladne, mam db cez 60gb s vyse miliardou zaznamov a nikdy nebol problem. Treba len rozmyslat pri skladani dotazov

Dobre, takže nejaké tipy, ako MySQL čo najlepšie nakonfigurovať, alebo čoho sa vyvarovať? Čoho sa napr vyvarovať pri skladaní dotazov? A tiež ako by som mal reprezentovať čas? (určite je rozdiel v rýchlosti medzi datetime a timestamp, či?)
A ďalej, ako tam tie existujúce dáta nasypať? Čo skúšam v php na localhoste, neviem pridať v jednom inserte viac ako 15 000 záznamov a ohlási mi to "MySQL server has gone away". A to je len 15 tisíc, ako tam nejak efektívnejšie pridať 50mil?

eeeh, v php nie
syp to tam cez konzolu

jjj, už som našiel ako vyriešiť tú chybu a usúdil som z toho, že cez php je to blud. Ďalšie otázky stále platia

datetime je vraj rýchlejšie ako timestamp. Tu sa o tom niečo píše: http://dbscience.blogspot.sk/2008/08/ca ... etime.html ale osobne som to nikdy netestoval a neviem o koľko je to rýchlejšie/pomalšie. Nemám teraz čas to googliť

vyvaruj sa trivialnym dotazom, radšej jeden zložitý. Takže čo najviac insertov do jedného query. Nakonfigurovať neviem, treba prekutať dokumentáciu. Zatiaľ som sa so žiadnymi extra konfiguráciami nehral. Sypať cez konzolu, to som ti napísal a ako to efektívne pridať na to musíš prísť sám Neviem v akej forme to máš, a ako tie binárne súbory dokážeš spracovať. Či máš k tomu nejaký soft alebo čo

Mozes urobit napriklad nejaky jednorazovy programovy parser ktory bude tie subory citat hoc aj po riadkoch a zapisovat do db... ale to nie je asi velmi efektivne riesenie ked si to nevies sam napisat.

MySQL server has gone away je timeout error, takze obist sa da napr. jednorazovym nastavenim brutalne velkeho timeoutu, ale ajtak by som radsej urobil to, aby sa to nasypavalo po castiach.

Rozdiel v rychlosti ti velmi povedat neviem, lebo s DB mam skusenosti minimalne, to poradi niekto iny.

Co sa tyka zalohovania, zalezi ake jadro bude mat databaza, najviac sa pouziva MyISAM alebo InnoDB, obe maju svoje vyhody a nevyhody, o.i v zalohovani, MyISAM ti staci riesit konkretne subory, ale InnoDB to nefunguje, tam musis ist cez tooly. MySQL ma zabudovany tool na sqldump a restore z neho, v zavislosti na serveri a velkosti a strukture db to nemusi fungovat (riesili sme nedavno v praci zhodou okolnosti). Existuje ale hromada toolov ktore ti s tym pomozu.

audiotrack napísal:tak to si mal slabý server alebo iba zle nakofigurovaný. Prípadne zlý návrh databázy. Naša db tu na fore má cez 2,7GB a všetko v pohode svižne funguje.

Hosting u websupportu a spominal som ze na webe samotnom to pojde fajn ak obmedzi vypis na niekolko riadkov, no ked som ich chcel mazat viacero v PHP MyAdmine, tak som ich dal ukazat naraz 1.000 a to uz zacalo vsetko mrznut

Michaelo, dáta nemám prečo vypisovať. Keď vypisuješ, tak je jasné, źe ti to zožerie veľa času, ale to nie je kvôli databáze

Poznám formát tých súborov, takže čítať ich viem, to nie je problém. Tie triviálne dotazy by ma asi nenapadli Skôr som si myslel, že jednoduchší bude rýchlejší, ale áno, dáva to zmysel, urobiť veľa práce naraz a potom s ztoho profitovať.

No dobre, tak sa teda vrhnem do MySQL. Vďaka za rady
Možno ma ešte niečo napadne, tak napíšem.

//autoeditácia príspevku (14 Máj 2014, 14:44)
Jo, ešte nadhodím takúto otázku: Bolo by lepšie urobiť pre každú stanicu vlastnú tabulku? Alebo je to jedno a môže byť všetko v jednej (a pri každom zázname id stanice)? Mohlo by to mať nejaký výrazný vplyv na rýchlosť? (predsa len prehľadávať 50mil riadkov vs. 5mil/5mil/5mil...) Alebo je to skôr úplne jedno a mám sa rozhodnúť sám?

Michaelo napísal:Na webe sa ti to bude zobrazovať v pohode ak budeš vypisovať po cca 100 záznamoch na stránku.

Ani to nemusí byť celkom pravdou pokiaľ vyberáš 100 riadkov z miliónov špeciálne nie v prípade ,že dáta sa vyberajú za pomoci LIMIT X, X.

Michaelo napísal:Načítať toľko záznamov z MySQL bude vcelku stresujúce na server..

Pokiaľ sa bavíme o výbere miliónov riadkov naraz tak jedine za pomoci streamu inač ti nevystačí pamäť (Samozrejme záleži od dát & tvojho PC).

audiotrack napísal:Žiaden limit pre maximálny počet záznamov neexistuje.

Pre počet záznamov možno nie no pre veľkosť tabuľky áno http://dev.mysql.com/doc/refman/5.0/en/ ... limit.html

audiotrack napísal:eeeh, v php nie
syp to tam cez konzolu

Do toho veľmi silno nevidím avšak nemyslím si ,žeby si tým malo mať php až taký problém hlavne nevytváraj pri každom dotaze nové spojenie a neposielaj do databázy naraz niekoľko dotazov (Pr. 10 tis.) Ak napríklad vkladáš nové dáta nerob to v takom štýle ,že do cyklu nahodíš INSERT INTO a vložíš len jeden záznam tz. desať záznamov = desať dotazov. Používaj radšej toto (Ak vkladáš milióny budeš to musieť ,ale aj tak rozdeliť inač ti asi nebude stačiť ram).

S-player napísal: Do toho veľmi silno nevidím avšak nemyslím si ,žeby si tým malo mať php až taký problém hlavne nevytváraj pri každom dotaze nové spojenie a neposielaj do databázy naraz niekoľko dotazov (Pr. 10 tis.) Ak napríklad vkladáš nové dáta nerob to v takom štýle ,že do cyklu nahodíš INSERT INTO a vložíš len jeden záznam tz. desať záznamov = desať dotazov. Používaj radšej toto (Ak vkladáš milióny budeš to musieť ,ale aj tak rozdeliť inač ti asi nebude stačiť ram).

Kód: Vybrať všetko

INSERT INTO table (field, field, field) VALUES ("1", "2", "3"), ("a", "b", "c"), ("x", "y", "z");

Takto to samozrejme robím a píše to tú chybu. Ako píše Fabo, treba zasiahnuť v my.ini (resp. my.cnf) a prestaviť max veľkosť dotazu (max_allowed_packet), prípadne veľkosť timeoutu (innodb_lock_wait_timeout).
Po častiach to síce musím, ale zase robiť to po 10tis by som sa zbláznil

Áno... musíš si to správne nakonfigurovať. Nepočitaj s tým ,že do databázy nahodíš naraz len tak desať miliónov záznamov. Pokiaľ by si dal ,ale takých 5, 10 tisíc za sekundu tak to by bolo v pohode. (A to sa ešte nevie na akej mašine to robíš )

Možno ti to pomôže http://www.mysqlperformanceblog.com/200 ... on-basics/

Dík, nastavenie k MySQL už si nájdem a daako to porobím. Hlavne mi išlo o to, či je MySQL dobrý nápad, alebo nie

možno nie Ale je najrozšírenejšie, takže k tomu nájdeš najviac info a do budúcna aj najviac ľudí čo ti budú schopní poradiť

do viac tabuliek - to záleží ako tie dáta spolu súvisia. Ak súvisia, a treba robiť nejaké štatistické operácie zo všetkých stanic súčasne, tak to daj do jednej. Ak je každá stanica samostatná a nezaujímajú ju iné stanice, tak to spolu nemusí byť. Potom by som ale asi spravil radšej samostatnú db pre každú stanicu, nie samostatnú tabuľku v rámci jednej db

Rád by som tu spomenul ,že máš na výber ešte MariaDB čo je vlastne "lepšie MySQL" ,ak sa to tak dá nazvať.

U nas vo firme na big data pouzivame windows azure table storage. Dokaze uchovat az 100 TB dat a je pekelne rychly. Je to vsak NoSQL ulozisko, preto ma obmedzenia na strukturu dat a dotazy, ktore sa nad nimi daju robit. Nedaju sa pouzit indexy, jedine indexovanie je podla vopred definovanych klucov, takze treba pri navrhu struktury tabulky dobre zvazit, ake dotazy sa budu vykonavat. Porovnanie so SQL najdes tu.

Reagujem uz sice neskoro ale skus pouzit MongoDB.
Co sa tyka MySQL tak to tam lej v tranzakcii a skus si precitat toto, http://kvz.io/blog/2009/03/31/improve-m ... rformance/ ja som podobny problem riesil asi pred dvoma rokmi, no potom som presiel na MS SQL (ale nie Express, ta ma obmedzenie na velkost databazy, vdaka skolskej licencii som mal Enterprise ediciu).

//autoeditácia príspevku (15 Máj 2014, 10:51)
Este jedna vec, vyber uloziska by mal zavisiet najme od toho co s tymi datami planujes v buducnosti robit.

Tie dáta sa budú ďalej spracovávať a skúmať. Typicky tak, že sa nejaká ich podmnožina vizualizuje a bude sa skúmať, čo to znamená. Nad touto db bude postavená webová aplikácia, ktorá toto poskytne. Čiže selekciu hlavne podľa času a ďalej podľa ostatných atribútov a nejakých zložitejších podmienok. Na to bude SQL vhodné.

A vzhľadom na to, že ja to síce urobím, ale v budúcnosti to po mne niekto preberie a bude spravovať, chcem nejaké jednoduchšie, alebo často použivané riešenie. NoSQL databáze mi prišli ako overkill, MySQL vítam a som rád, že som si potvrdil, že na to bude stačiť. MariaDB vyzerá tiež dobre, ale asi nejdem experimentovať, na MySQL som už zvyknutý.