Administrace komentářů

Ahoj, U nas se to dela trosku jinak nez to co navrhujete. Strasne zalezi na tom co mate za data a hlavne kolik toho je

Nas system uklada za nejakych 16 hodin neco kolem 250mil. radek do database a to je docela dost takze jsem museli hodne optimilizovat

1) myslim ze index na datetime and symbol je nanic, pokud pouzivate insert vzdy se vam po transakci bude prepocitavat index to bude asi duvod proc rikate ze to mate pomale, zkuste copy from stdin 2) pouzivejte partitions my mame partitions per day. takze pokud potrebuju pracovat s jednim dnem pracuju s mene daty. udelejte si views abyste pracoval s co nejmene daty 3) mysql, oracle, sybase, db2 ani informix nam nedali dost rychlosi ulozit co potrebujem v realnem case, Je mi trapne priznat ale MSSQL to zvladlo - kdyz jsme to ukazali Microsoftu neverili nam . Ted pouzivame vertica, KDB a zkousime pgsql - zatim dobry ale nemame tam 100% nasich data takze jeste nevime presne 4) napiste is jiny load a zapoment na index pres dva sloupce, ano na DB urovni je to jak to ma byt ale budete tim trpet, loader tohler vyresi, size za cenu toho ze bude muset vedet o vsech symbolech na den co loadujete ale to se da chytre vyrseit. 5) data co popisujete nevypadaji tak strasne, mate tam vlastne jen symbol,den,open and close price a par dalsich blbosti to by se melo veji do nejakych 2 milionu radek za den 6) 100% musite rozumet vasim datum jinak oprimalizaci neudelate

Pokud mate tick data - coz je mozne jen nam to nerikate, zalezi na tom kolik toho je, je trba prizpusobit strukturu database . A asi nejlepe nepouzivat SQL ale neco jako vertica nebo KDB, my do toho cpemene zatim neco kolem 0.7TB/den a ani o tom nevime.

je potreba zkouset