OT:Fragmentace
Martin Záruba
swz na volny.cz
Pondělí Srpen 3 11:30:06 CEST 2020
Pro účely archivace to tak dělám, jenže pro normální režim to nejde
použít, protože uživatel může chtít data jak za posledních pár minut tak
třeba za poslední den, týden,měsíc, rok. Podívejte se na
http://www.ekovy.cz/servis/index.htm?firma=demo Server teď funguje tak,
že klient (webový prohlížeč) pošle kolik bodů potřebuje pro vykreslení
grafu v zadaném časovém intervalu a server vrací jen data, která se dají
zobrazit. Třeba při zvoleném časovém rozlišení každý stý vzorek. Server
ví, jak často za sebou (není to úplně přesně, ale to nevadí) jsou vzorky
a pokud je požadován každý desátý vzorek nebo méně, najde se půlením
intervalu první a pak se čte sekvenčně až se získá potřebný počet
vzorků. Pokud je interval větší, čtou se všechny vzorky půlením
intervalu. tento mechanismus se ukázal jako nejrychlejší.
Martin Záruba
Dne 3.8.2020 v 10:01 Stanislav Šmejkal napsal(a):
> Dělal jsem v minulosti něco podobného. Nahrávání všech televizních
> kanálů (3 multiplexy, tuším že asi 26 GB/hod). Tudíž cca 20 vláken
> současně, každou minutu zvláštní soubor. A disk byl stále na 90 %
> plný, nejstarší záznamy se odmazávaly. Znamenalo to hodně dat, která
> pak ještě další procesy četly. Fungovalo to bez problému několik let.
> Ale byl to Linux na xfs.
>
> Osobně bych šel jinou cestou. Nasaďte si tam skripty, které jednou za
> čas (třeba jednou za hodinu nebo jednou za den) soubory vezme a
> překopíruje na jiný disk - postupně jedním vláknem. Tam už data
> fragmentovaná nebudou. Prostě navrhuju obejít to klasickými prostředky
> operačního systému.
>
> Standa
>
> Dne 3.8.2020 v 9:45 Martin Záruba napsal(a):
>> Děkuji všem za nápady. Samozřejmě nechce se mi to příliš předělávat a
>> použití sql znamená to předělat hodně. To řešení, které požívám je
>> velmi svižné, některé soubory mají okolo 200 000 záznamů a nalezení
>> potřebných dat trvá do vteřiny, přičemž je třeba přečíst cca 1000
>> vzorků. Pokud to není zoufale fragmentované. Soubory jsou setříděny
>> podle klíče-datum+čas. Asi opravdu nejlepší bude ssd. Celá databáze
>> má nyní asi 50 GB.
>>
>> Martin Záruba
>>
>> Dne 3.8.2020 v 9:18 Jiří Nesvacil napsal(a):
>>> Pokud to jsou logové informace každých x sekund, tak bych je do db
>>> necpal. Za rok či dva budou 4/5 GB velikosti databáze jen logové
>>> informace. Dostat se k těmto datům pružně bude stejně problematické
>>> jako v souboru. Žádný SQL server nebude držet data v paměti, aby se
>>> nad tím dalo rozumně pracovat. SQL je relační db a ne archiv log
>>> informací. Dá se samozřejmě použít k čemukoliv, ale s limity. Nad
>>> tím velkým logem Vám při dání SQL dotazu s setříděním třeba vypadne
>>> spojení, protože to bude zpracovávat minuty či hodiny. Pokud to bude
>>> na webhostingu, tak s tím třeba ani nic neuděláte. Nejprve si
>>> spočítejte kolik toho zaplníte za jakou dobu a zda tomu SQL dáte
>>> pořádně RAM v nastavení, aby mohl pracovat... .
>>>
>>> Jirka
>>>
>>>
>>> Dne 03.08.2020 v 8:54 Ladislav Vaiz napsal(a):
>>>> Souhlasím, že je to práce pro databázi (jsou i malé typu sqlite),
>>>> ale k původnímu dotazu jsem našel:
>>>> https://stackoverflow.com/questions/53334343/windows-refs-ntfs-file-preallocation-hint
>>>>
>>>> L.
>>>>
>>>> Dne 03.08.2020 v 8:50 Jan Půhoný napsal(a):
>>>>> Podle me kdyz to budete ukladat do databaze tak nebudete muset
>>>>> resit takoveto obezlicky. Uz z povahy věci je to úloha pro nějaký
>>>>> hosting za pár korun a bude to řádově spolehlivější než PC s
>>>>> win2000 někde u Vás na firmě. MySQL umí kdejaký hosting za pár korun.
>>>>>
>>>>> HP
>>>>>
>>>>> Dne po 3. 8. 2020 7:55 dop. uživatel Róbert Šuška
>>>>> <suska.roobert na gmail.com <mailto:suska.roobert na gmail.com>> napsal:
>>>>>
>>>>> Alebo pouzit SSD disk pre servre ? Nebudes musiet riesit
>>>>> fragmentaciu a ani zivotnost...
>>>>> Robo
>>>>>
>>>>> -----Original Message-----
>>>>> From: Hw-list <hw-list-bounces na list.hw.cz
>>>>> <mailto:hw-list-bounces na list.hw.cz>> On Behalf Of Lubor Otta
>>>>> Sent: Monday, August 3, 2020 3:16 AM
>>>>> To: hw-list na list.hw.cz <mailto:hw-list na list.hw.cz>
>>>>> Subject: Re: OT:Fragmentace
>>>>>
>>>>> Jsem jenom laik, ale není systémové řešení tohoto problému v
>>>>> použití
>>>>> databázového serveru?
>>>>> Lubor
>>>>>
>>>>>
>>>>> Dne 2.8.2020 v 21:42 Martin Záruba napsal(a):
>>>>> > Jasně. To mě taky napadlo. Data přibývají spojitě, vždy cca
>>>>> po 10 s
>>>>> > asi 100 byte.
>>>>> >
>>>>> > Jenže jak se to zachová, když více vláken spustí zápis (je to 4
>>>>> jádro)
>>>>> > současně? Provede se to sekvenčně? Myslím to tak, že pokud
>>>>> vznikne
>>>>> > současně ze dvou vláken zápis, vytvoří jedno vlákno souvislý
>>>>> blok
>>>>> > (třeba nul) a pak druhé, nebo se prostřídají a stejně to bude
>>>>> > fragmentované?
>>>>>
>>>>> _______________________________________________
>>>>> HW-list mailing list - sponsored by www.HW.cz
>>>>> <http://www.HW.cz>
>>>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>>>
>>>>> _______________________________________________
>>>>> HW-list mailing list - sponsored by www.HW.cz
>>>>> <http://www.HW.cz>
>>>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> HW-list mailing list - sponsored by www.HW.cz
>>>>> Hw-list na list.hw.cz
>>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> HW-list mailing list - sponsored by www.HW.cz
>>>> Hw-list na list.hw.cz
>>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
Další informace o konferenci Hw-list