Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: astarus 29. 07. 2012, 23:05:09

Název: Ukladanie frame-like dát do DB
Přispěvatel: astarus 29. 07. 2012, 23:05:09
Pôjdem hneď k veci  :) - Potrebujem ukladať medicínske dáta, ktoré chodia vo frameoch. Viem framerate, číslo frameu a hodnotu (real, resp. DECIMAL). Pekný príklad je meranie EMG.

Problém je v tom, že v súčasnosti sa dáta ukladajú ako parametre (5 FK do číselníkov) a k nim sa priradí 100 hodnôt do sto stĺpcov tabuľky. Tu je ten problém, že ak je počet frameov iný ako 100, tak sa to musí dopočítať, poprípade zahodiť. Preto by som chcel spraviť presnejšie ukladanie - to jest uloži sa len to, čo sa nameralo.
Súčasná tabuľka:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|0|1|2|......|100|

Rozmýšľal som, že spravím nasledujúcu zmenu:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|Cislo frameu|Hodnota|

Tu je problém, že sa mi počet záznamov prakticky zostonásobí. Ešte dodám, že pôvodných záznamov je niečo cez jeden milión. To, že by som mal 100 mega riadkov asi prežijem, ale horšie vidím plytvanie priestorom, pretože 100-krát zopakujem všetky parametre a budem meniť iba číslo frameu a hodnotu. Súčet veľkosť parametrov nedám pod 14 bytov, čo dáva 1.4kB odpadu na jedno meranie (ak predpokladáme 100 frameov - obecne sa počet frameov pohybuje od 50 do pár stoviek). Aby ste nemuseli počítať, tak po zmene by DB narástla o cca 1.4GB  :o

Nejaké nápady, ako ukladať takýto typ dát?
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: Radim Kolář 29. 07. 2012, 23:23:17
SDI
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: Tomáš Vondra 30. 07. 2012, 00:16:33
SDI
Nějaká ještě kratší a odpověď by nebyla?
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: Tomáš Vondra 30. 07. 2012, 00:56:59
Pôjdem hneď k veci  :) - Potrebujem ukladať medicínske dáta, ktoré chodia vo frameoch. Viem framerate, číslo frameu a hodnotu (real, resp. DECIMAL). Pekný príklad je meranie EMG.

Takže vám postupně chodí nějaká časová řada, tj. jedna skalární hodnota (+ ty doplňující informace ukládané do sloupců Parameter1, ..., Parametr5)? Potřebujete s těmi daty pak provádět něco dalšího (např. nad nimi provádět dotazy - počítat průměr apod.) nebo je potřebujete jenom uložit?

Jakou DB vlastně používáte? MySQL, PostgreSQL, něco komerčního?

Problém je v tom, že v súčasnosti sa dáta ukladajú ako parametre (5 FK do číselníkov) a k nim sa priradí 100 hodnôt do sto stĺpcov tabuľky. Tu je ten problém, že ak je počet frameov iný ako 100, tak sa to musí dopočítať, poprípade zahodiť. Preto by som chcel spraviť presnejšie ukladanie - to jest uloži sa len to, čo sa nameralo.
Súčasná tabuľka:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|0|1|2|......|100|

Rozmýšľal som, že spravím nasledujúcu zmenu:
|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|Cislo frameu|Hodnota|

Tu je problém, že sa mi počet záznamov prakticky zostonásobí. Ešte dodám, že pôvodných záznamov je niečo cez jeden milión. To, že by som mal 100 mega riadkov asi prežijem, ale horšie vidím plytvanie priestorom, pretože 100-krát zopakujem všetky parametre a budem meniť iba číslo frameu a hodnotu. Súčet veľkosť parametrov nedám pod 14 bytov, čo dáva 1.4kB odpadu na jedno meranie (ak predpokladáme 100 frameov - obecne sa počet frameov pohybuje od 50 do pár stoviek). Aby ste nemuseli počítať, tak po zmene by DB narástla o cca 1.4GB  :o

Nejaké nápady, ako ukladať takýto typ dát?

Tak z pohledu teorie je ta první varianta dost neoptimální - konec konců problémy jste popsal sám. Ta druhá varianta je "správnější" a pokud chcete jít ještě o krok dál tak ji dekomponujte na dvě. V jedné bude entita "měření" s umělým PK a ve druhé (kardinalita 1:*) budou naměřené hodnoty a FK odkazující na ten umělý PK. Tj. něco jako

mereni:
Kód: [Vybrat]
|PK|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|
hodnoty:
Kód: [Vybrat]
|PK|Cislo frameu|Hodnota|
Výhoda je v tom že nebudete pořád opakovat ty parametry - budou jenom 1x v té první tabulce, v druhé tabulce je jenom ten umělý PK (typicky integer). Kolik ušetříte závisí na velikosti těch parametrů (tj. čím jsou delší tím víc ušetříte) apod.

Nevýhoda je že pro dotazování musíte ty tabulky joinovat (a nebo si vyhledat PK v první tabulce a pak se v druhém kroku dotazovat do té druhé). Jak moc to vadí závisí na tom jak to používáte.

Další možností je využít různých specifických vlastností jednotlivých databází - např. PostgreSQL umí pracovat s poli, takže si tu tabulku můžete definovat takhle:

Kód: [Vybrat]
CREATE TABLE mereni (
  PARAMETR1 INT,
  PARAMETR2 INT,
  PARAMETR3 INT,
  PARAMETR4 INT,
  PARAMETR5 INT,
  HODNOTY   DECIMAL[]
)

a pak do toho data vkládat jednoduše
Kód: [Vybrat]
INSERT INTO mereni
     VALUES (1, 2, 3, 4, 5, ARRAY[20000, 25000, 25000, 25000]);

případně s tím manipulovat pomocí 'array_append(pole, prvek)' apod.

U MySQL o ničem takovém nevím, komerční DB podobné věci mají (např. Oracle má varrays).
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: astarus 30. 07. 2012, 09:40:04
SDI
Nějaká ještě kratší a odpověď by nebyla?

Pisateľ pravdepodobne myslel http://en.wikipedia.org/wiki/Spatial_data_infrastructure (http://en.wikipedia.org/wiki/Spatial_data_infrastructure)

Pôjdem hneď k veci  :) - Potrebujem ukladať medicínske dáta, ktoré chodia vo frameoch. Viem framerate, číslo frameu a hodnotu (real, resp. DECIMAL). Pekný príklad je meranie EMG.

Takže vám postupně chodí nějaká časová řada, tj. jedna skalární hodnota (+ ty doplňující informace ukládané do sloupců Parameter1, ..., Parametr5)? Potřebujete s těmi daty pak provádět něco dalšího (např. nad nimi provádět dotazy - počítat průměr apod.) nebo je potřebujete jenom uložit?

Skoro presne - príde jednorázový záznam s pár sto hodnotami (+ informácie typu z ktorého merania to je, a parameter1..5). Priamo nad nimi sa nič nepočíta. Jedine nad priemerom z X meraní.

Jakou DB vlastně používáte? MySQL, PostgreSQL, něco komerčního?

Používame MySQL, InnoDB.

Tak z pohledu teorie je ta první varianta dost neoptimální - konec konců problémy jste popsal sám. Ta druhá varianta je "správnější" a pokud chcete jít ještě o krok dál tak ji dekomponujte na dvě. V jedné bude entita "měření" s umělým PK a ve druhé (kardinalita 1:*) budou naměřené hodnoty a FK odkazující na ten umělý PK. Tj. něco jako

mereni:
Kód: [Vybrat]

|PK|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|


hodnoty:
Kód: [Vybrat]

|PK|Cislo frameu|Hodnota|


Výhoda je v tom že nebudete pořád opakovat ty parametry - budou jenom 1x v té první tabulce, v druhé tabulce je jenom ten umělý PK (typicky integer). Kolik ušetříte závisí na velikosti těch parametrů (tj. čím jsou delší tím víc ušetříte) apod.

Nevýhoda je že pro dotazování musíte ty tabulky joinovat (a nebo si vyhledat PK v první tabulce a pak se v druhém kroku dotazovat do té druhé). Jak moc to vadí závisí na tom jak to používáte.

To ma tiež napadlo, ale má to svoje problémy. Tam sa nezmestím pod 8 bytov za FK a 2 byty za cislo frameu = 10 bytov namiesto 14. Čiže problém to úplne nerieši + pridáva to komplikovanosť dotazov.

Další možností je využít různých specifických vlastností jednotlivých databází - např. PostgreSQL umí pracovat s poli, takže si tu tabulku můžete definovat takhle:
....

Presne v niečo takéto som dúfal, možno SDI ako bolo vyššie spomenuté. Akurát problém s MySQL.
Nemáte ešte nejaký podobný nápad? Tie polia prakticky sú to, čo potrebujem - keď manipulujem s dátami, tak už so všetkými skalármi súčasne. Pridávať nepotrebujem, to sa spraví vždy dávkou a už sa to nezväčšuje.
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: Tomáš Vondra 30. 07. 2012, 11:16:43
SDI
Nějaká ještě kratší a odpověď by nebyla?

Pisateľ pravdepodobne myslel http://en.wikipedia.org/wiki/Spatial_data_infrastructure (http://en.wikipedia.org/wiki/Spatial_data_infrastructure)

Možné to je, ale jak to aplikovat na váš problém je mi záhadou ...

Tak z pohledu teorie je ta první varianta dost neoptimální - konec konců problémy jste popsal sám. Ta druhá varianta je "správnější" a pokud chcete jít ještě o krok dál tak ji dekomponujte na dvě. V jedné bude entita "měření" s umělým PK a ve druhé (kardinalita 1:*) budou naměřené hodnoty a FK odkazující na ten umělý PK. Tj. něco jako

mereni:
Kód: [Vybrat]

|PK|Parameter1|Parameter2|Parameter3|Parameter4|Parameter5|


hodnoty:
Kód: [Vybrat]

|PK|Cislo frameu|Hodnota|


Výhoda je v tom že nebudete pořád opakovat ty parametry - budou jenom 1x v té první tabulce, v druhé tabulce je jenom ten umělý PK (typicky integer). Kolik ušetříte závisí na velikosti těch parametrů (tj. čím jsou delší tím víc ušetříte) apod.

Nevýhoda je že pro dotazování musíte ty tabulky joinovat (a nebo si vyhledat PK v první tabulce a pak se v druhém kroku dotazovat do té druhé). Jak moc to vadí závisí na tom jak to používáte.

To ma tiež napadlo, ale má to svoje problémy. Tam sa nezmestím pod 8 bytov za FK a 2 byty za cislo frameu = 10 bytov namiesto 14. Čiže problém to úplne nerieši + pridáva to komplikovanosť dotazov.

To nedokážu posoudit - zatím jste nám neprozradil o jaké datové typy se jedná, takže netuším kolik co zabírá. Navíc ony ty počty nejsou takhle jednoduché, protože některé typy mohou mít overhead kvůli dodatečnému infu (délka, přesnost, ...).

O jakých datových objemech se vlastně bavíme? O megabajtech, gigabajtech?

Další možností je využít různých specifických vlastností jednotlivých databází - např. PostgreSQL umí pracovat s poli, takže si tu tabulku můžete definovat takhle:
....

Presne v niečo takéto som dúfal, možno SDI ako bolo vyššie spomenuté. Akurát problém s MySQL.
Nemáte ešte nejaký podobný nápad? Tie polia prakticky sú to, čo potrebujem - keď manipulujem s dátami, tak už so všetkými skalármi súčasne. Pridávať nepotrebujem, to sa spraví vždy dávkou a už sa to nezväčšuje.

MySQL pokud vím žádný nativní datový typ pro pole nemá, takže si to tam budete muset serializovat ručně. Např. do BINARY nebo spíš VARBINARY.
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: astarus 30. 07. 2012, 11:29:49
O jakých datových objemech se vlastně bavíme? O megabajtech, gigabajtech?

Bavíme sa o nízkych GB (celá DB je trochu komplikovanejšia ako táto jedna tabuľka).

MySQL pokud vím žádný nativní datový typ pro pole nemá, takže si to tam budete muset serializovat ručně. Např. do BINARY nebo spíš VARBINARY.

Toto je pravdepodobne víťaz. Akurát prevod budem musieť robiť na aplikačnej vrstve, ale inak to má samé klady.

Ďakujem za diskusiu, mne už chýbali nápady a potreboval som to s niekým prebrať.
Název: Re:Ukladanie frame-like dát do DB
Přispěvatel: Radim Kolář 30. 07. 2012, 16:18:57
Nějakou podporu pro SDI mysql má:
http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html

koukám do manuálu, mělo by to stačit.