abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 17:02 | Pozvánky

Přijďte si popovídat o open source obecně a openSUSE konkrétně s dalšími uživateli a vývojáři. Oslava nového vydání openSUSE Leap se uskuteční 16. prosince od 17:00 v nových prostorách firmy SUSE v Praze. K dispozici bude nějaké občerstvení a DVD pro ty, kdo je sbírají nebo ještě mají mechaniku. Po párty v kanceláři se bude pokračovat v některé z hospod v okolí.

Miška | Komentářů: 7
včera 14:55 | Zajímavý software

Byla vydána verze Alpha 1.0 otevřeného operačního systému pro chytré hodinky AsteroidOS. Podporovány jsou hodinky LG G Watch, LG G Watch Urbane, Asus ZenWatch 2 a Sony Smartwatch 3. Ukázka ovládání hodinek na YouTube. Jaroslav Řezník přednášel o AsteroidOS na chytrých hodinkách (videozáznam) na letošní konferenci OpenAlt.

Ladislav Hagara | Komentářů: 0
včera 13:30 | Zajímavý software

Byly uvolněny zdrojové kódy známé rogue-like hry DoomRL. Počátky hry jsou v roce 2002. Je napsána ve FreePascalu a zdrojový kód je nyní k dispozici na GitHubu pod licencí GNU GPL 2.0. Autor pracuje na nové hře Jupiter Hell, která je moderním nástupcem DoomRL a na jejíž vývoj shání peníze prostřednictvím Kickstarteru.

Blaazen | Komentářů: 0
včera 13:15 | Pozvánky

Přijďte s námi oslavit vydání Fedory 25. Na programu budou přednášky o novinkách, diskuse, neřízený networking atd. Release Party se bude konat 16. prosince v prostorách společnosti Etnetera. Na party budou volně k dispozici také propagační materiály, nová DVD s Fedorou 25 a samozřejmě občerstvení. Přednášky budou probíhat v češtině. Pro více informací se můžete podívat na web MojeFedora.cz. Jen připomínám, že tentokrát jsme zavedli

… více »
frantisekz | Komentářů: 0
9.12. 16:38 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 5. a 6. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu. Celkově bylo zpracováno 65 hodin z 89 přednášek a workshopů.

Ladislav Hagara | Komentářů: 0
9.12. 11:30 | Komunita

Bylo oznámeno, že bude proveden bezpečnostní audit zdrojových kódů open source softwaru pro implementaci virtuálních privátních sítí OpenVPN. Audit provede Matthew D. Green (blog), uznávaný kryptolog a profesor na Univerzitě Johnse Hopkinse. Auditována bude verze 2.4 (aktuálně RC 1, stabilní verze je 2.3.14). Audit bude financován společností Private Internet Access [reddit].

Ladislav Hagara | Komentářů: 4
9.12. 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
9.12. 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 1
8.12. 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
8.12. 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 5
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (23%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 810 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu

LangPa avatar 15.3.2012 19:44 LangPa | skóre: 12 | blog: LangPavel | Hradec Králové
MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
Přečteno: 786×
Zdravím

Mám následující tabulku, principiáně:
CREATE TABLE `temperature` (
  `time`       BIGINT NOT NULL PRIMARY KEY,  /* UNIX timestamp * 1000 */
  `id_sensor`  TINYINT NOT NULL,             /* cizi klic na senzor */
  `t16`        SMALLINT NOT NULL,            /* teplota - 12bitu */
);

Stručně
  1. Jaká úložiště nejefektivněji ukládají řádek s pevnou velikostí
  2. Lze použít DATETIME nebo TIMESTAMP jako primární klíč když je možné naměřit 2 a více hodnot za vteřinu?
Detailně

Tabulka uchovává data ze senzorů teploty tak jak jsou čtena, cca 1 teplota z 1 senzoru za 1 sekundu.

Tabulka bude v čase konstantně růst. Potřebuji navrhnout tabulku tak abych měl co největší efektifitu ukládání, Jaký je v tomto rozdíl mezi jednotlivými úložišti (je li nějaký), dělá úložiště padding, ušetřím něco TINYINTem? (InnoDB, MyISAM)

Nechtěl jsem zavádět explicitní primární klíč, vzhledem k tomu že se zde jako naturální hodí čas měření. Protože se ale může stát, že dvě měření se uskuteční ve stejnou sekundu a nevím zda DATETIME či TIMESTAMP rozlišuje milisekundy, zvolil jsem UNIX timestamp * 1000 (po milisekundách, což je mimo jiné způsob interpretace javascriptu, který data zpracovává na webu)

Agregaci dat budu samozřejmě dělat, ale až po nějakém intervalu (cca 1 měsíc), ale nechtěl bych data zbytečně mazat, dokud si neověřím, že mě to občas nehodí nesmyslnou chybu měření/přenosu dat po sběrnici.

Díky za radu

Odpovědi

LangPa avatar 15.3.2012 19:50 LangPa | skóre: 12 | blog: LangPavel | Hradec Králové
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
jen ještě dodám aktuální situaci:

Nemodifikovaná struktura:

CREATE TABLE `temperature` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `id_sensor` int(11) NOT NULL COMMENT 'foreign to sensor',
  `time` datetime NOT NULL COMMENT 'date and time',
  `temperature` float NOT NULL COMMENT 'temperature',
  PRIMARY KEY (`id`),
  KEY `time` (`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;

CREATE TABLE `sensor` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `uid` varchar(20) COLLATE utf8_czech_ci NOT NULL COMMENT 'sensor ID',
  `location` varchar(50) COLLATE utf8_czech_ci NOT NULL COMMENT 'short location description',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;

Velikost dat 71 942 144

Velikost indexů 34 160 640

Řádků (auto increment): 1 559 770
15.3.2012 20:09 Kit
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
V daném případě bych asi použil CSV Storage Engine bez indexů. Indexy se hodí pro vyhledávání, ale pokud by to mělo být jen 1x za měsíc, tak nejsou potřebné.

Syntetický primární klíč by měl sémantiku "číslo měření", byl by tedy vhodný i tady. Jinak by asi musel být primární klíč složený (datetime,id_sensor).

Zkusil bych zvážit, zda se MySQL pro tento účel hodí. Je to obyčejné logování, které se dá velmi snadno realizovat běžnými systémovými prostředky přímo na filesystému.
LangPa avatar 15.3.2012 20:51 LangPa | skóre: 12 | blog: LangPavel | Hradec Králové
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
Tak CSV se mi nějak nezdá, chci data ukládat binárně možná i po bitech :-) nevěřím že by CSV byla menší než MyISAM nebo InnoDB

Protože nelze realizovat 2 měření zároveň tak syntetický klíč není potřeba i když logicky se nabízí.

MySQL používám protože se na úlohu hodí asi nejlépe, mám interaktivní graf na (zatím neveřejném) webu a tam se zobrazuje agregace po minutě a každou minutu se aktualizuje pomocí AJAXu.

Jediné co mi teď asi vadí je to, že nevím, kolik bitů sebere datetime nebo timestamp bez timezone oproti BIGINTu.

Aktuálně jsem si spočítal, že potřebuju:
  • čas od 1.1.1970 po 0,1s minimálně 34bitů do roku 2024, 35bitů do roku 2078
  • id senzoru 4bity pro 16 čidel
  • teplota z čidla je na 12bitů signed
celkem tedy 50 bitů, což je nejblíže 7 bajtům na záznam což by odpovídalo cca 604800 byte na den :-) (1 záznam na sekundu) a takto zůstane záznam se všemi hodnotami; integrálně do streamu bych si to mohl psát taky s ještě vyšší efektivitou, ale chci SQL...
15.3.2012 21:11 Kit
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
... mám interaktivní graf na (zatím neveřejném) webu a tam se zobrazuje agregace po minutě a každou minutu se aktualizuje pomocí AJAXu.
Tak tohle bych neoznačil jako agregace 1x za měsíc ani náhodou. Takže 1x za minutu. To úplně mění požadavek.

Pro úsporné uložení používám SQLite, ale na 7 bytů se nedá dostat ani náhodou. A ani v MySQL to nepůjde.
LangPa avatar 16.3.2012 01:08 LangPa | skóre: 12 | blog: LangPavel | Hradec Králové
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
Psal jsem že budu provádět agregaci, ale po nějaké době, tím jsem myslel něco ve smyslu CRONu, mělo by to vzít data načtená, zagregovat je (a to hruběji, tak po deseti minutách) a uložit do jiné tabulky, přiznávám, že jsem se asi špatně vyjádřil.

Je mi jasné že na 7 bytů se nedostanu jinak než vlastním kódem, ale co jsem chtěl je smrsknout rekord co možná nejvíce a proto jsem se ptal na úložiště. Asi zvolím MyISAM s jedním indexem a to bude UNIX timestamp * 10 (kvůli desetinám sekundy) a uložím to jako BIGINT, díky tomu můžu použít čas jako primární klíč, což odbourá potřebu indexu na čas, jak to mám teď po staru (viz první doplňující příspěvek pod dotazem)

Jde mi o to že teď mi jeden tento primitivní záznam zabírá efektivně (Podle statistiky) 46.3 bajtů včetně indexů, samotné indexy přitom mají 22.4 bajtů na záznam a to je hodně divné :-) (data tudíš zabírají 23.9 bajtů)

Podle výpočtu velikosti rekordu mi vychází původně: 8+4+4+8 = 24 bytů což odpovídá, podle nového návrhu v dotazu budu potřebovat na data 8+1+2 = 11 bytů (bez indexů (a tady jen PK)) a taky nevím, zda MySQL neudělá nějaký padding.
16.3.2012 13:05 blondak | skóre: 36 | blog: Blondak | Čáslav
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
Nebo nic neřešit a používat RRD, to mi na to přijde úplně nejlepší, dělá to agregaci samo a grafy také.
Každý problém ma své logické, snadno pochopitelné nesprávné řešení.
rADOn avatar 16.3.2012 16:39 rADOn | skóre: 44 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: MySQL nejlepší úložiště pro tabulku s pevnou velikostí záznamu
Jaká úložiště nejefektivněji ukládají řádek s pevnou velikostí
10.5. Data Type Storage Requirements
Lze použít DATETIME nebo TIMESTAMP jako primární klíč když je možné naměřit 2 a více hodnot za vteřinu?
10.3.5. Fractional Seconds in Time Values

IMO se sql na to co chceš moc nehodí, ale když na tom trváš, dobrou radu najdeš zde

"2^24 comments ought to be enough for anyone" -- CmdrTaco

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.