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íží...
dnes 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 2
dnes 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 2
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 8
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 22
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 4
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

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

Dotaz: Správné ukládání velkého množství dat

22.3.2011 15:41 Michal
Správné ukládání velkého množství dat
Přečteno: 1041×
Zdravím,

chtěl bych se zeptat jestli je lepší ukládat data (*.txt a *.jpg) normálně do jednoho adresáře na webu, např. /data/123456.jpg nebo jestli je lepší to rozložit do podadresářů dle posledních čísel, např. /data/6/5/123456.jpg? Případně jestli stačí ext3.

Má to nějaký vliv na zátěž webu/serveru nebo je to prakticky jedno?

Díky za odpovědi.

Michal

Odpovědi

22.3.2011 15:51 Sten
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Pro ext3 nebo pokud umožňujete vypisovat obsah adresáře bych to doporučoval rozdělovat (řádově tisíce souborů do jednoho adresáře), pro jiné systémy a pouze přímý přístup to rozdělovat nemusí být potřeba (třeba Reiser4 ani btrfs nemají problémy s miliony souborů v jednom adresáři). Pokud to však máte jenom pro čtení, pak je to jedno.
22.3.2011 16:41 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat

S ext3 (a už dlouho ani ext2) není problém, pokud si výslovně nezakážete indexování adresářů. Naopak, když jsem to zkoušel měřit, vycházela práce s velkými adresáři na ext3 rychleji než třeba na XFS.

Na druhou stranu, při určitých operacích je stejně potřeba prohledat adresář celý a to je pomalé i s indexováním - takže ani tam nehraje volba filesystému roli.

22.3.2011 16:47 Sten
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Indexování pomocí b-stromů, které je v ext*, je při zápisu docela pomalé.
22.3.2011 18:55 pozortucnak | skóre: 21 | blog: vecny_windowsar
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Jde o to, jak k těm souborům hodláte přistupovat...

Při několika stovek tisíců souborů v adresáři vám systém spolehlivě vytuhne na takových banalitách jako jsou příkazy ls a obecně používání například žolíkových znaků v bash nebo výpis adresáře v php...

také můžou být problémy s ram - kešování názvů souborů v adresáři...
Jsem mimořádně obtížný případ
22.3.2011 19:34 kvas
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
toto potvrdzujem. na NFS mam v jednom adresari cca 1 500 000 ks suborov a "ls -l | wc -l" tak trva neuveritelnych 7 hodin:)
22.3.2011 20:10 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
To už by se docela vyplatilo napsat o znak víc a místo toho použít 'ls -1U' (což by navíc na rozdíl od 'ls -l' vedlo ke správnému výsledku).
David Watzke avatar 24.3.2011 00:40 David Watzke | skóre: 74 | blog: Blog... | Praha
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Mimochodem, -1 není třeba.
“Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
24.3.2011 00:53 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
No, není. To je spíš taková pojistka, aby výstup vypadal stejně, i kdybych ho poslal na terminál.
24.3.2011 09:13 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
což by navíc na rozdíl od 'ls -l' vedlo ke správnému výsledku
bash$ touch "a" "b
> c"
bash$ ls -1U
a
b?c
bash$ ls -1U | wc -l
3

vs

bash$ find . -type f -ls | wc -l
2
pokud počítáme soubory tak spíš o jedna blíže ke správnému výsledku, který je zde 2.
23.3.2011 09:34 Michal
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Díky moc za info. Nechám to tedy v jednom adresáři. Přístup je tam přímý, není třeba indexace. Vždy podle id v db sáhne přímo na určité soubory, tedy jako ten příklad /data/123456.jpg. Pokud to webu nevadí, tak to nechám takto.

Akorát mě teď napadá zálohování, to asi bude procházet komplet :-(.

Michal
23.3.2011 10:50 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Přístup je tam přímý, není třeba indexace. Vždy podle id v db sáhne přímo na určité soubory, tedy jako ten příklad /data/123456.jpg

A právě na to je ta indexace adresářů potřeba. Bez ní by byla časová náročnost vyhledání položky podle jména úměrná počtu položek v adresáři - a to je při velkém počtu položek (typicky od 10000 výše) docela velký problém.

23.3.2011 22:24 Michal
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Aha, takže změna ;-). Nicméně, když to udělám tedy stylem /data/5/6/123456.jpg, tak tím asi nic nezkazím, že?

Ale teď jsem zkoušel dát ls -1 data/123456.jpg a zobrazilo se to okamžitě, tak nevím.

Když však zkusím ls -1 data | wc -l, tak zobrazí výsledek 125985 až během 63 sekund.

Michal
23.3.2011 22:49 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
A zkusil jste výše zmíněné ls -1U data | wc -l ?
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
24.3.2011 00:31 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Ale teď jsem zkoušel dát ls -1 data/123456.jpg a zobrazilo se to okamžitě, tak nevím.

Ve všech dnes běžně používaných filesystémech adresáře indexované jsou, takže vyhledání položky podle jména je velmi rychlá operace.

Když však zkusím ls -1 data | wc -l, tak zobrazí výsledek 125985 až během 63 sekund.

To je úplně jiná situace. V tomto případě je potřeba projít všechny položky (v tom vám indexace stromem nepomůže, spíš naopak), seřadit je a seřazený seznam poslat na výstup. A při troše smůly se jako bonus na každou položku zavolá stat(). Příkaz ls totiž neví - a ani nemůže vědět - že výstup posílá "wc -l", takže by stačilo položky spočítat, ale musí vygenerovat stejný výstup, jako kdyby ho vypisoval na terminál (až na obarvovací sekvence, pokud používáte --color=tty).

Časová náročnost může být dána jednak pomalostí čtení z disku, jednak řazením:

...# time ls -1U >/dev/null ; time ls -1U >/dev/null ; time ls -1 >/dev/null

real    0m28.198s
user    0m0.184s
sys     0m0.462s

real    0m0.484s
user    0m0.182s
sys     0m0.302s

real    0m2.929s
user    0m2.576s
sys     0m0.330s
24.3.2011 08:37 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Když už to chcete takhle rozdělit, dělal bych to spíš podle začátku jména souboru – ty znaky získáte snáz a jednoznačně i při podivných názvech souborů.
24.3.2011 09:20 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Pokud všechny soubory nezačínají
img000...
tak je to určité zjednodušení, ale spíš bych čekal lepší rozložení na konci.
24.3.2011 10:31 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Pokud se shodneme na tom že je to třeba rozdělovat, což by jsme se na základě rad s této diskuze mohli, tak nabízím možnosti ke zvážení:
  • Pokud se jedná o běžný web případně s větší penetrací obrazového materiálu, ale stále jen web, není nezajímavé použít lehce použitelnou strukturu ROK/MESIC/Soubor nebo lépe ROK/TYDEN/Soubor - pokud si to spočítáte tak zjistíte co je pro Vás vhodnější. Samozřejmě toto jednoduché řešení má nevýhody v nerovnoměrnosti obsahu souborů v adresářích a nutnost v DB uchovávat cestu k souboru (což při běžném webu nevadí, protože nejsou těch souborů miliony).
  • Pokud se jedná o web s velkým množstvím obrázků (či jiných souborů), tak je vhodnější si stanovit limity například 1000 souborů na adresář a z ID v databázi, nebo jiného unikátního sloupce (předpokládám, že tam v pozadí je) generovat cestu a to může být různě. Můžete použít rozdělení desítkovou/hexadeciámlní reprezentaci id po třech znacích a hiearchii 3 adresářů apod.
    Takováto cesta nemusí být uložena v DB, protože ji lze kdykoliv sestavit
Pokud se chcete ochránit proti „vykradení“ obrázků a zachování přímé přístupnosti, můžete adresáře a názvy souborů překódovat /nebo jen názvy/ (třeba jen Crc32 s nějakým textem přidaným k názvu - po jeho provalení už je to ale v hájí), nebo pokud je cesta uložena v DB generovat názvy adresářů a souborů náhodně.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Heron avatar 24.3.2011 14:51 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Což takhle ty soubory vložit přímo do DB jako datový typ BYTEA nebo BLOB?

Vyřeší se tím hned několik věcí.

Jednak to zde diskutované uložení do nějaké adresářové struktury. V DB to fakt řešit nemusíte (pokud velikost a počet záznamů nepřesáhně nějakou hranici, ta je ale zcela jinde než u FS), ta si s tím poradí sama (všechna data obrázků mohou být v jedné tabulce dle schématu, netřeba explicitně řešit jejich umělé rozdělování, tak jak to řešíte teď). ID obrázku bude indexované a ke konkrétnímu obrázku se dostanete velmi rychle.

Dále (pro mě podstatná) konzistence operací. Nevím jak komu, ale mě nepřijde úplně "košér" si něco řešit odděleně v DB (id obrázku, uložená nějaká cesta + další metadata a vazby na ostatní tabulky dle schématu) a odděleně potom na fs (samotná data, nějaká cesta). Vazba data na fs a metadata v db je velmi slabá (není tam referenční vazba, resp je ale nic ji explicitně nevynucuje, tudíž se to velmi snadno rozpadne). Jakákoliv změna na FS se musí "nějak" odrazit ve DB a naopak, není to zabezpečené v transakci.

Dále při uložení do DB stačí zálohovat jen jedno místo (všechna data máte v DB). Záloha bude konzistentní.

Zvažte to. Má to samozřejmě i nevýhody, k obrázkům se nedostanete přímo, ale jen pomocí SQL, asi to nebude tak výkonné jako na FS apod. Pro mě ale výhody převažují (referenční integrita, transakční přístup, jedno datové úložiště, nemusím řešit ruční rozdělení dat).
24.3.2011 15:48 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Výhody jste naspal napíšu něco o nevýhodách tohoto modelu :).
Pokud se jedná o web aplikaci na běžných serverech a velkém počtu obrázků a samozřejmě i s více než 10 přístupy za hodinu :), tak Velmi nepříjemně tímto zvedáte požadavky na prostředky:
  • Ve stránce můžete mít i velký roj obrázků a to znamená velký roj samostatných dotazů do DB. Způsobené problémy s výkonem nebudou v jednotkách procent ale minimálně v desítkách a klidně několika stovkách procent.
  • Všechny obrázky (jejich obsah čili data) je třeba přenést přes všechny vrstvy od DB až po výstup.
  • Musíte řešit getImage stránku, kde si musíte udělat vlastní reportování chyb.
  • Nemusí být možné (dle db, providera a jejich velikosti) přečíst všechna data obrázku najednou, ale třeba postupným vytahováním z db (nebo je třeba alespoň tuto možnost zvažovat).
  • Zálohování je daleko náročnější protože pokud se jedná o mnoho data bez dalších řešení nelze zálohovat přírustkově, což v tomto případě na filesystému se přímo vybízí
  • Je to opak cache-ování dotazů a před-připravení DB dat - prostě problémy s výkonem, které jsem už napsal a jen jsem to znovu zdůraznil.
    Např. vygenerujete html stránku aby se všechno neustále stránka dynamicky nevytvářela z db, ale při tom všechny obrázku jdou stejně z db.
  • Neprovedete diskové operace na soubory-obrázky (jako hromadné přidání vodoznaku, změna třeba komprese/formátu, resample, hledání v obsahu, prohlížení pomocí nějakého „náhledovače“ a pod.).
Zjednodušeně je to konzistence versus výkon a nároky na prostor(včetně záloh) - práce s obsahem mimo aplikaci, je jak co.
Konzistence lze řešit pře aplikační transakci, a když se to udělá správně (případně je-li to nutné, uloží se i třeba CRC32 obrázku do db) není problém, protože sice se vám ve velmi specifických případech(<joke>1× za 100let</joke>) může stát, že Vám tam nějaký soubor přebývá - no a co, lze jej dohledat a situaci napravit.

DB řešení nenapadám ani nezatracuji, je to předmětem častých debat. Ale přes to: osobně pro velké množství obrázků s častými přístupy (webové fotogalerie / frekventované weby) se mi jeví jako (velmi) nevhodné.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Heron avatar 24.3.2011 20:06 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat

Předně děkuji za doplnění. Obecně máte (nebo máš, jestli si můžeme tykat) pravdu.

Ve stránce můžete mít i velký roj obrázků a to znamená velký roj samostatných dotazů do DB. Způsobené problémy s výkonem nebudou v jednotkách procent ale minimálně v desítkách a klidně několika stovkách procent.

Všechny obrázky (jejich obsah čili data) je třeba přenést přes všechny vrstvy od DB až po výstup.

Obé lze řešit cachováním. Požadavky na obrázky mohou jít buď skrz memcached, případně to může cachovat samotný DB stroj. Jistě namítnete, že totéž si může cachovat samotný FS. Ano může, ale to by znamenalo řešení se všemi nevýhodami, které jsem popsal.

Musíte řešit getImage stránku, kde si musíte udělat vlastní reportování chyb.

Nemusí být možné (dle db, providera a jejich velikosti) přečíst všechna data obrázku najednou, ale třeba postupným vytahováním z db (nebo je třeba alespoň tuto možnost zvažovat).

Souhlas a tohle považuji za největší nevýhodu mého řešení (což jsem i napsal).

Zálohování je daleko náročnější protože pokud se jedná o mnoho data bez dalších řešení nelze zálohovat přírustkově, což v tomto případě na filesystému se přímo vybízí

I DB lze zálohovat inkrementálně.

Např. vygenerujete html stránku aby se všechno neustále stránka dynamicky nevytvářela z db, ale při tom všechny obrázku jdou stejně z db.

Vracím se k bodu jedna, každý jednotlivý obrázek se nemusí brát vždy z DB (disku), mohou být cachovány a pokud se to udělá inteligentně, tak mohou být připraveny stejně jako ta html stránka.

Neprovedete diskové operace na soubory-obrázky (jako hromadné přidání vodoznaku, změna třeba komprese/formátu, resample, hledání v obsahu, prohlížení pomocí nějakého „náhledovače“ a pod.).

To záleží, jakým způsobem jsou tyto operace prováděny. Samozřejmě nelze na to přímo pustit program, který umí pracovat pouze ze souborem (dejme tomu ImageMagick convert). Pokud se to ale zpracovává nějakou knihovnou přímo v programu, tak se ta obrázková data většinou stejně předávají přes nějaké pole bajtů nebo stream a zdroj dat může být kdekoliv (už na něm nezáleží). Případně se ta data dají tomu externímu programu ládovat přes jeho standardní vstup (pokud to umožňuje).

Off topic:

Konzistence lze řešit pře aplikační transakci, když se to udělá správně

Já jsem v tomto spíše pesimista. Málokdy se to udělá správně, (komerčního) vývojáře tlačí rozpočet, termíny, séf apod. Rozhodně bych si nevsadil na vývojáře webové aplikace, že je schopen zvládnout transakční zpracování dat lépe, než vyspělá DB. Nic proti tomu webistovi, ale to už je zcela jiná liga.

že Vám tam nějaký soubor přebývá - no a co, lze jej dohledat a situaci napravit

Tak jednak by mě zajímalo jak se zjistí, že nějaký soubor přebývá. Ještě jsem neviděl webovou aplikaci (tohoto typu), která by měla něco jako "fsdbck". To se prostě nijak nezjisti. Ale ono nejde ani tak o to, že by nějaký soubor přebýval. To je ještě ok. Co ale například uděláte, když vám ten soubor na FS přejmenuji za jiný (prostě přehodím)? Aplikace si toho vůbec nevšimne, a bude nabízet jiný soubor. Ok tohle chcete řešit přes CRC32 (mno, lépe než kontrolní součet by bylo lepší použít hashovací funkce, ale rozumíme si). Tak jinak, ten soubor vám pojmenuji zcela jinak? Aplikace si toho možná všimne, možná ne (spíše ne, prostě v servírovaném html dokumentu bude stále odkaz na neexistující soubor). Tohle se prostě v DB nestane (pokud se nebudeme bavit o přímé editaci databázových datových souborů), tam to všechno ohlídá integrita, na "přejmenování" mohou být trigery, které upraví vazby na další tabulky apod.

24.3.2011 21:18 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Můžem, po staromoravsku to píšu i v patičce :)
Popravdě, čekal jsem v případné odpovědi slůvko memcached, ale pokud si představím „foto“ web, tak nemusí být technicky možné vše cache-ovat a pak dojde k tomu, že se to bere z DB a nebo z FS a výkon půjde rapidně dolů.

Přírustková záloha např. MySQL - bez toho anž bych tuto zálohu připravil (přes sql), jak? (nevím, a asi bych chtěl)

Ad. Konzistence, obecně je to tak, ale tady většinou stačí jen zvolit pořadí, uložit (úspěšně move-nout)obrázek, v případě úspěchu založit záznam do db a pak reportovat výsledek akce.

na FS přejmenuji za jiný (prostě přehodím)
Položme se na otázku: „A co když to udělám v DB?“ položme se na odpovědní otázku: „Mám DB integritu, ale je to ta integrita, která byla/je žádána?“ - no není obojí je prostě externí zásah a obojí je špatně a projeví se to stejným způsobem −> zobrazí se špatný obrázek.
Druhá situace je, když jej smáznete (asi zas externím zásahem), pokud je DB dobře udělaná »což na webu je často jen MyISAM úložiště (nezaručující referenční integritu) málokdy InnoDB či dokonce PostgreSQL«, tak je to OK, pokud je to na filesystému, tak ano, soubor chybí a je to reportováno do logu (doufejme :)).

hashovací funkce
Jo MD5 (či SHA1/SHA256) je super, ale žere 32Bytes (40/64) CRC32 jen 4Bytes a je rychlé.

Tady se trochu rozcházíme, jakýkoliv zásah do úložiště považuji za externí zásah. CRC32 (případně + filesize, na MySQL další 3Bytes), beru jako kontrolní mechanismus, při nějakém obnovení se záloh, či pro „check“ script (který není nic jiného než procházka po DB a pro každý soubor kontrola existence a kontrola CRC32 - řekněme, že je to „fsdbck“.).

Nadneseně:
Ta integrita je krásná věc, ale co to je?, to, že systém se při jakémkoliv zásahu chová stejně a správně?, no ale vrací stejně špatný obrázek, nebo ho nenajde.
Z vnějšího pohledu se to může jevit obojí naprosto stejně a někde je prostě hranice kde už to je rozjeté (v tomto případě, máme jistě HTML texty, které odkazují na obrázky a ty nám DB už nepokryje). Ano záloha není provedena v jednom kroku, takže existuje možnost, že záloha FS nekoresponduje s DB ale znovu, vadí to, že je tam něco navíc, co lze nalézt?

Praktická zkušenost: dva systémy odvozeného ze stejného základu (MySQL s InnoDB, PHP) nabízející ukládání obecných dokumentů (obrázků, externích odkazů, dokumentů - obecně), jejich základní verzování včetně „obálky“ (dokument != soubor, jeden dokument může být více souborů, např scanované stránky po jednom tvoří dokument).
Úložiště datově spravovaných dokumentů na výběr DB, Filesystém. Nastaveno na využívání DB. A cca. po roku provozu u obou žádost na přestavení na FS a převedení všeho na z DB na FS. Důvody: zásadní dvojí a stejné - 1. pro IT neprůhledné zálohování spousty GiB dat, 2. právě možnost diskového přístupu (readonly odkazování odkukoliv) /a to i přes to, že soubory nemají srozumitelný název a taky, jak jsem psal, soubor nemusí znamenat dokument/. A po té příjemné zjištění „není třeba nový server, nyní je zatížený výrazně méně“.
PS: zde jsou uchovávány jak některé meta informace, tak i CRC32 i MD5 (obojí jen proto, že MD5 zajišťuje plnohodnotnou kontrolu, ale CRC32 je velmi rychlé a v DB nezabírá moc místa), takže externí aplikace mohou využít co zrovna potřebují/preferují.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Bilbo avatar 24.3.2011 21:37 Bilbo | skóre: 29
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Big brother is not watching you anymore. Big Brother is telling you how to live...
24.3.2011 22:27 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Dejte mi dva rozdílné soubory ze stejnou MD5-kou a stejnou velikostí nebo mi dejte mi najděte dva rozdílné soubory se stejnou MD5-kou neuměle vytvořené.
Děkuji :)
To, že to není bezpečné v oblasti šifrování, ale z určitých důvodu, ještě neznamená, že to není vhodné na něco jiné.

Uvědomte si že MD5 - SHAkdovíco, má nějakou množinu kombinací, takže to není teoretická jistota, tou je porovnání skutečného obsahu, ale jedná se o praktickou jistotu.
Jen pro zajímavost na celkem 5 strojích (z různými verzemi Win a uživ. daty) při celkem 2.1 milionech souborech (a 121 tisicích adresářích) i u crc32 jsme jen 1× nalezli kolizi u názvu adresářů a jen cca. 10× kolizi obsahu souborů a to Vám klidně budu generovat různé soubory ze stejnou crc32 a rozdílným obsahem.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
25.3.2011 00:33 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Přílohy:
Dejte mi dva rozdílné soubory ze stejnou MD5-kou a stejnou velikostí

Máte je v příloze. Nebo tady jich najdete hned osm.

25.3.2011 08:52 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Takže díky, a doběhla mě má neznalost (jako vždy).
A lze splnit (je Vám známo) i druhé zadání, tj. je známá shoda dvou souborů neúčelově vytvořených? Předpokládám, že tyto soubory jsou účelově vytvořené.

PS: právě něco řeším a zvažuji - je třeba minimalizovat data v DB, protože jich bude opravdu hodně a neustále lavíruji mezi MD5 a SHA1, a teď je to další argument pro SHA1 a velikost řešit, binárním uložení hash-e.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
25.3.2011 09:55 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Záleží na tom, co přesně myslíte tím, že nejsou účelově vytvořené. Pokud jde o to, že máte konkrétní soubor "ze života" a chcete k němu najít kolizi, tak to zatím nikdo neumí (nebo přesněji: nikdo se zatím nepřiznal, že by to uměl :-) ). Ale IIRC jsem někde zahlédl zmínku, že už je znám postup, jak vyrobit kolizi s předepsaným začátkem, tj. že pro libovolný soubor se umí doplnit ho dvěma různými způsoby tak, aby vyšel stejný MD5 digest.
25.3.2011 21:20 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
V zásadě jsem myslel jestli je známa kolize MD5 nad soubory jak píšete „ze života“ ze stejnou velikostí.
Jen jsem zkusil, CRC32 k tomu nesedí - né, že by to něco znamenalo, ale kdoví co by to znamenalo splnit i tuto podmínku :)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
26.3.2011 01:18 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Dalo by to víc práce, ale ne nějak nepředstavitelně (je ale potřeba mít na paměti, že techniky generování kolizí MD5 se od té doby ještě zlepšily).
26.3.2011 14:28 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Jasně :)
Jen mě napadlo u:
nie je znama ziadna pouzitelna analyticka suvislost medzi tymi hashovacimi funkciami, je to předpoklad, ale vzhledem k tomu, že pro návrh SHA1 byly použity principy z MD5 a SHA2(224,256,384,512) jsou ze stejné rodiny, je otázkou jak to je/bude…
Což vlastně v odkazovaném textu je na konci napsáno.
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
Heron avatar 25.3.2011 07:26 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Přírustková záloha např. MySQL - bez toho anž bych tuto zálohu připravil (přes sql), jak? (nevím, a asi bych chtěl)

V PostgreSQL se to umí přes WAL log (Continuous Archiving and Point-In-Time Recovery), v MySQL to lze dělat také pomocí binárních logů (Point-in-Time (Incremental) Recovery Using the Binary Log).

no není obojí je prostě externí zásah a obojí je špatně a projeví se to stejným způsobem −> zobrazí se špatný obrázek.

Nevím, zda jsme se přesně pochopili. Já jsem směřoval k tomu, že pokud to mám v DB ošetřené pomocí referenční integrity, triggerů a všeho co jde (Ok, jako pokud se budeme bavit o MYISAM, tak tu diskusi asi můžeme uzavřít, já mám stále na mysli plnou DB), tak mi databáze samotná nedovolí tam udělat nežádoucí změnu, případně se ta změna projeví všude a výsledek bude opět konzistentní stav. Ten software tu integritu přímo vynucuje. Zatímco na disku ten obrázkový soubor mám přímo přístupný a nic mě nezastaví. Ano, je to externí zásah, ano nikdo nepovolaný by se neměl dostat ani na DB, ani na FS. Ovšem ona ta DB integrita dost často ochrání data i před chybou v aplikaci. Je to prostě vrstva navíc.

Praktická zkušenost: Atestovaný elektronický nástroj pro správu veřejných zakázek (EZAK). PHP(bohužel) + PostgreSQL (bohudík :-D). Veškeré dokumenty v DB, verzované, některé i šifrované (dle zákona). Každá změna DB je zaznamenávána pro audit. Pro mě, jako pro technika (nejsem programátor, vše co tu píšu je z pohledu technika a admina DB), je to super stav, kdy vím, že mi stačí zálohovat pouze DB a aplikace se případně (při obnově) nainstaluje nová. Nemusím řešit zálohu ještě něčeho jiného (což mě skutečně štve na všech redakčních systémech -- záloha dvou různých míst, kterou lze jen těžko udělat ve stejný čas), záloha (také několik GB) je konzistentní (udělá se v jedné transakci -- WAL backup zatím nepoužívám).

25.3.2011 09:55 dustin | skóre: 60 | blog: dustin
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
To je dobrý příklad, na druhou stranu kolik tam může být přiložených souborů, narozdíl od "velkého množství dat". A celý dump v řádu GB ten předpoklad potvrzuje. To nejsou žádné velké objemy. Ale třeba desítky/stovky tisíc blobů v objemu stovek GB do postgresu nebo mysql - to bych hodně váhal.
25.3.2011 18:39 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
… a pokud stroj má jedno jádro, 2GiB RAM a obsluhuje „všechno“ nejen DB, tak je já váhám podstatně dříve :) - přibližně někde u „To nejsou žádné velké objemy“ :)
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
25.3.2011 10:33 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Chtěl jsem napsat „bez použití binárních logů“ :).

Pochopil jsem to, ale nahodil jsem jen jiný pohled na to co je „konzistentní stav“.
Pohybuji se zjednodušeně ve třech rovinách správce(vedlejší až sociálně prospěšná činnost)/programátor(někdy i placená zábava)/manager(asi hlavní zaměstnání), a z každé roviny mám jiné úhly pohledu a ve výsledku nemám vyhraněný pohled na věc.
Pokud mám něco navrhnout, tak samozřejmě technicky databázová integrita je super.
Pokud mám něco zálohovat a mám dostatek prostředků tak udělat dump DB je to nejednodušší a obvykle i nejbezpečnější (v záloze je opravdu to co chceme a lze to zaručeně obnovit a vše v definovaného stavu)
Ale jakmile nemám dostatek prostředků je třeba volit kompromisy. A onen „konzistentní stav“ ve výsledném použití nemusí být to nejdůležitější, protože řeší úzkostlivě konzistenci něčeho co nemusí zaručovat správný/konzistentní výsledek.

PHP(bohužel) + PostgreSQL (bohudík).

PHP není špatné, jsou špatné a dobré aplikace, oproti například Java-ě je to opravdu volný jazyk, ale zas (nebijte mě) je výkonnější s potřebou výrazně menších prostředků. A malé firmy a soukromnící nemají (nebo nemají vůli) investovat do super řešení, protože všichni(většina) pracují za účelem generovat peníze, ne používat čisté/nové technologie :).
PostgreSQL je jednoznačně plnohodnotná asi jedna z nejlepších DB, ale opět MySQL není špatné, a to že MyISAM neumí referenční integritu je neustále bráno jako nějaký průšvih, ale proč, je to prostě úložiště dat, vždyť i některé super systémy používající Oracle jej ± používají stejně. MyISAM je jako jedna z možností a pro webové aplikace typu málo zápisu s spousta čtení je to výkoné jednoduché řešení.

což mě skutečně štve na všech redakčních systémech -- záloha dvou různých míst

Mě taky, povinností :) tvůrce je nabídnout script/postup na zálohu, tak aby záloha obsahovala vše co má (s případným pozastavením zápisů, či záloha obsahuje vše a možná něco navíc).
PS: Pokud to lze není až tak těžké, využít i LVM snapshot (zastavit aplikace na 1 min v noci není pro většinu systémů problém) pro konzistenci všeho (myšleno všech systémů běžící a spolupracujících na stroji).
To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
AraxoN avatar 24.3.2011 15:12 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Mal som milión súborov v jednom adresári na ext3 a vrelo to neodporúčam. Teraz to zvyknem deliť tak, že číselný identifikátor prepíšem do hexa a vložím do adresárov podľa jednotlivých bajtov. Pre /data/123456.jpg by to bolo /data/00/01/E2/40.jpg.
A fine is a tax for doing wrong. A tax is a fine for doing well.
24.3.2011 16:36 Michal
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Díky moc všem za nápady a připomínky.

Rozhodli jsme se tedy pro systém tří podadresářů, vzhledem k tomu, že se databáze stále rozrůstá. Výsledkem tedy z /data/123456.jpg bude /data/1/2/3/123456.jpg. Systém souborů zůstane ext3. Myslím, že to bude dostačující a snad nám to dlouho vydrží ;-).

Michal
24.3.2011 22:15 Sandokan
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
Dá se na to použít třeba takový skript :
#!/bin/bash

if [ $# -eq 1 ] ; then
    CUT="NO";
else
    if [ $# -eq 2 -a "$2" == "-extcut" ] ; then
        CUT="YES";
    else
        echo " ";
        echo "usage: $0 directory_name [-extcut]";
        echo " ";
        echo "where:  directory_name is directory with pictures";
        echo "        -extcut option will cut files extension (if exists)";
        exit 1;    
    fi
fi

DIR=$1;
if [ ! -d $DIR ] ; then
    echo " ";
    echo "'$DIR' is not a directory!";
    exit 1;
fi

cd $DIR
for FILE in `ls $DIR`
do
    if [ -f $DIR/$FILE ] ; then

        NEWNAME=$FILE;
        if [ "$CUT" == "YES" ] ; then
            NEWNAME=`echo $FILE | sed 's/^\(.*\)\..*/\1/g'`;            
        fi

        NEWPATH=./`echo $NEWNAME | sed 's/^\(.*\)\..*/\1/g' | sed 's/\(...\)/\1\//g' | sed 's/^\(.*\/\)[^\/]*$/\1/g'`;

        echo "copy: '$DIR/$FILE' to '$NEWPATH$NEWNAME'"
        mkdir -p "$NEWPATH"
        cp -f "$DIR/$FILE" "$NEWPATH$NEWNAME"
        rm "$DIR/$FILE"
    fi
done

echo "Successfully imported."
exit 0;
25.3.2011 06:11 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
U většího (teda já i u jednoho) množství souborů bych si asi rozmyslel dělat cp; rm místo mv. Šetřme životní prostředí, a navíc, co když se kopírování nepovede? To klidně smažete originál?
25.3.2011 06:23 Ash | skóre: 53
Rozbalit Rozbalit vše Re: Správné ukládání velkého množství dat
To for file in `ls $DIR` taky - máte dost dlouhou příkazovou řádku? Měřil jste ji? Raději for file in $DIR/*, spolupracujte s shellem, ne proti němu.

Hláška "Successfully imported" a exit 0 na konci by měla reflektovat činnost skriptu, ne se vysmát do očí uživateli s nepřipojeným cílovým diskem a smazanými fotkami :)

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.