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í
×
včera 11:55 | Komunita

Vývojový tým OpenSSL ve spolupráci s iniciativou Core Infrastructure konsorcia Linux Foundation spustil proces přelicencování této kryptografické knihovny ze současné licence na licenci Apache Licence v 2.0 (ASLv2). Nová licence usnadní začleňování OpenSSL do dalších svobodných a open source projektů. Všichni dosavadní vývojáři OpenSSL (Authors) obdrží v následujících dnech email s prosbou o souhlas se změnou licence.

Ladislav Hagara | Komentářů: 6
včera 01:11 | Komunita

Před třemi týdny Mozilla.cz představila projekt Photon, jehož cílem je návrh a implementace nového vzhledu Firefoxu. Včera zveřejnila první náhled vzhledu Photon. Práce na projektu Photon jsou rozděleny do pěti týmů, které celkem čítají 19 lidí. Zaměřují se na zlepšení prvního spuštění Firefoxu a zaujetí nových uživatelů, celkovou úpravu vzhledu, zlepšení animací, zrychlení odezvy uživatelského rozhraní a také upravení nabídek. Vývoj lze sledovat v Bugzille.

Ladislav Hagara | Komentářů: 18
23.3. 20:00 | Komunita

OneDrive pro firmy je již ve webových prohlížečích na Linuxu stejně rychlý jako na Windows. Microsoft opravil chybu z listopadu loňského roku. OneDrive pro firmy běžel na Linuxu mnohem pomaleji než na Windows. V popisu chyby bylo uvedeno, že stačilo v prohlížeči na Linuxu nastavit v user-agentu Windows a vše se zrychlilo. Odpovědí Microsoftu bylo (Internet Archive: Wayback Machine), že Linux není podporován. Po bouřlivých diskusích na redditu i Hacker News byla chyba nalezena a opravena.

Ladislav Hagara | Komentářů: 4
23.3. 19:00 | Zajímavý projekt

Byla vyhlášena soutěž Hackaday Prize 2017. Soutěž je určena vývojářům open source hardwaru. Pro výherce je připraveno celkově 250 tisíc dolarů. Každý ze 120 finalistů získá tisíc dolarů. Nejlepší pak navíc 50, 30, 20, 15, 10 a 5 tisíc dolarů. Jedná se již o čtvrtý ročník soutěže. V roce 2014 zvítězil projekt globální sítě open source pozemních satelitních stanic SatNOGS. V roce 2015 zvítězil open source systém pro řízení elektrických invalidních vozíků pohybem očí Eyedriveomatic. V roce 2016 zvítězil modulární robot Dtto.

Ladislav Hagara | Komentářů: 0
23.3. 15:00 | Bezpečnostní upozornění

Byla vydána Samba ve verzích 4.6.1, 4.5.7 a 4.4.12. Řešen je bezpečnostní problém CVE-2017-2619. Pomocí symbolických odkazů a souběhu (symlink race) lze "teoreticky" získat přístup k souborům, které nejsou sdíleny. Linuxové distribuce jsou postupně aktualizovány (Debian).

Ladislav Hagara | Komentářů: 0
23.3. 07:43 | Nová verze

Na Steamu se objevil port hry Arma: Cold War Assault (Operation Flashpoint) pro Mac a Linux. … více »

creon | Komentářů: 29
23.3. 05:55 | Nová verze

Po 18 měsících od vydání verze 8.0 byla vydána verze 9.0 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 0
23.3. 03:33 | Komunita

Platnost posledního patentu souvisejícího s Dolby Digital (AC-3) vypršela. Po MP3 se tak do Fedory oficiálně dostane také kodek AC-3.

Ladislav Hagara | Komentářů: 5
23.3. 00:44 | Komunita

Feral Interactive, společnost zabývající se vydáváním počítačových her pro operační systémy macOS a Linux, nabízí své hry na Steamu vývojářům open source 3D grafické knihovny Mesa zdarma. Podmínkou je minimálně 25 commitů za posledních 5 let. Stejnou nabídku dostali vývojáři knihovny Mesa v roce 2015 od Valve. O rok dříve dostali od Valve tuto nabídku vývojáři Debianu a Ubuntu.

Ladislav Hagara | Komentářů: 0
22.3. 23:55 | Nová verze

Opera 44, verze 44.0.2510.857, byla prohlášena za stabilní. Nejnovější verze tohoto webového prohlížeče je postavena na Chromiu 57. Z novinek vývojáři Opery zdůrazňují podporou Touch Baru na nejnovějších MacBoocích Pro (gif). Přehled novinek pro vývojáře na blogu Dev.Opera.

Ladislav Hagara | Komentářů: 1
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (14%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 926 hlasů
 Komentářů: 72, poslední 1.3. 11:16
    Rozcestník

    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: 792×
    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.