Web pro horních 10 000 www.koncier.cz
Zobrazují se odpovědi 1 až 5 z 5

Vhodná struktura ukládání dat na serveru pro tisíce souborů

  1. Ahoj,

    jaká je vhodná struktura ukládání dat na serveru, pokud nahrávám opravdu velké množství menších dokumentů?

    Je dobré mít na serveru adresář upload/documents/ a zde ukládat už přímo cílové soubory a nebo adresáře ještě více větvit formou, např.:

    /2018/leden
    /2018/leden/01

    Jde mi o to, aby třeba neztroskotaly možnosti OS při čtení souborů z takového adresáře a nebo k tomuto vůbec nemůže dojít, pokud vždy přistupuju k souborům absolutní cestou a nedělám operace typu "vylistuj celý adresář".

    Pro informaci uvedu, že OS bude vždy Linux. Vím, že některé verze 32-bit OS WIN měly dříve problém přečíst soubor o větší velikosti než 4GB - tak nějak to bylo. Tak zjišťuji zda není ještě podobné omezení na Linuxu.

    Děkuji Vám za rady.

  2. Co se právě děje na Webtrhu?
  3. Na modernim unix OS nebude problem. Ale drive se bezne stavalo, ze mit vse v jednom adresari byl problem (vykon, inody...) a neni duvod se toho nedrzet.

  4. da se to delat jak uznas za vhodne (klidne jak jsi nastinil), obecne kazdej file system zvaldne do 10k souboru, moderni file system uz vicemene unlimited.

    Pokud to budes prochazet nekdy treba pres ftp, tak neodporucuju vic jak 1000 na adresar (pak uz je to fakt osina to prochazet)... Jine omezeni asi nejsou ani zavedene konvence jak to ukladat

  5. "opravdu velké množství menších dokumentů" - sqlite

  6. tohle je složité konkrétně odpovědět, když člověk neví jak k souborům budeš přistupovat, jestli je budeš skenovat a prohledávat, jak moc se budou číst, jaký chceš filesystém atd.

    Pokud vezmu ext2 (dost stará věc, ale ext4 se chová podobně), maximální velikost souboru 2TB (při 8kib block size), maximální počet souborů ve složce 4 mld, ale při jednom milionu rapidně padá výkonnost. Na linuxu poté musíš řádně nastavit limits.conf pro počet inodes a otevřených souborů, výchozí je kolikrát nízkých 64 tis.

    Drtivá většina posix nástrojů pro práci se soubory a adresáři je jednovláknových a mají tendenci si číst celý adresář najednou (pouze metadata), z toho vychází nutnost nedávat vše do jedné složky, ale udělat složky po třeba 10 000, jinak se může se stát, že každá operace bude mít zbytečnou režiji a udusíš s tím systém. Tady hodně záleží jak budeš na soubory přistupovat, jestli tam budeš lést běžnými linuxovými nástroji nebo tam bude chodit pouze aplikace na konkrétní soubor podle názvu (pokud jde o názvy, doporučuji nepoužívat ty původní jak ti soubor někdo nahraje, ale třeba md5 hashe, id z databáze, Linux neumí všechny znaky a může vzniknout špatným ošetřením security issue).

    Rozložení a pojmenování složek zvol tak, aby počty souborů v nich byly rovnoměrně rozložené, pokud se ti může stát, že v jeden den ti přibude milion souborů, tvůj navrhovaný layout bude nedostatečný. Některé systémy používají takový trik, udělají si hash md5(název souboru), který třeba je e841fa2979b20a1e9ac8188a77cd7eb4, vezmou první dva znaky e8 a vytovří složku e8, do ní uloží soubor e841fa2979b20a1e9ac8188a77cd7eb4 a původní název souboru mají v databázi, v případě většího počtu souborů se může přidat další znak, nebo naopak znak ubrat.

    Velké databáze používají často místo velkého množství malých souborů jeden velký datový a v něm ty soubory mají uložené. Linux má krásnou možnost vytvořit prázdný soubor a ten naformátovat jako filesystém a připojit ho jako disk, do něj se poté dají ukládat soubory a na disku to je jako jeden velký soubor. Má to výhodu pro administraci OS, zálohování, obnovování, pracuje se totiž pouze s jedním souborem, bezva pro takové jednoduché zálohávání.

    Dnes na linuxu je často jako výchozí filesystem ext4 se zapnutými journaly, nezapomeň pro větší počet souborů zvednout velikost indexu, jinak se ti tam nevlezou (tune2fs flashes -J size=xxx, viz google). Journaly jsou v tomhle případě vhodná věc, udržují index souborů v mimo a zvyšuje se tím čas vyhledávání.

    Osobně bych ale takové uložiště raději stavěl nad zfs/brtfs s možností dělat inkrementální snapshoty a lépe to celé zálohovat. Na linuxu obecně není snadné dělat zálohu filesystemu, který má miliony souborů, trvá to příliš dlouho a nedá se zajistit konzistence, u zfs si udělám vlastní datový zpool a mohu dělat zálohu klidně každou hodinu. Ext nepodporuje online defragmentaci a pokud bude potřeba, je možné zvolit xfs.

    Je také možné vzít nějakou databázi, technologii a udělat z ní storage pro soubory, kdysi jsem třeba uložiště pro obrovské množství malých souborů (miliony pár desítek kb velkých souborů) vytvořit nad sqllite databází (nemyslím tím sql daemona, ale použití přímo C knihovny).

Hostujeme u Server powered by TELE3