Dotaz: uchovavanie textovych suborov v databaze

[ondro]

Riesim problem ako uchovavat (zalohovavat) male textove subory aby s nimi bolo mozne nasledne relativne efektivne pracovat v pripade potreby. Jednalo by sa o stovky suborov denne o velkosti niekolko kilobajtov az desiatky kilobajtov , vynimocne vecsie do 1MB. Ta potreba s nimi pracovat by bola minimalna. Ide mi o to ak ta potreba nastane aby sa potrebny subor dal lahko vyhladat a nejakym sposobom spracovat pomocou programu. Stacilo by mi ukladal nazov suboru a jeho obsah. Ukladat ich na file system mi pripada trochu neprakticke. Aka databaza je nieco taketo vhodna?

Odpovědi

[mess]

Mají ty soubory nějakou společnou vnitřní strukturu? Co je jeich obsahem? Je důležité, aby bylo zachováno to, že to je soubor nebo stačí, že to bude záznam v databázi? Z jakého důvodu je pro tebe ukládání souborů do systému souborů nepraktické? Jaký typ operací s nimi bude ten program provádět?

Pokud ti jde jen o možnost snadného dohledání tak bych je nechal na tom filesystému a vyrobil si jen nějaký vyhledávací index (na to určitě bude už něco vymyšlené).

Jinak z hlediska zpracování programem je filesystém ideální - který programovací jazyk/jeho standardní knihovna neobsahuje metody pro práci se soubory?

Pokud chceš konkrétnější rady, tak, prosím, zodpověz otázky, na položené začátku tohoto mého příspěvku.

[Filip Jirsák]

K otázkám Messe ještě doplním něco k té praktičnosti. Podle mne je nepraktické spíš ukládání do databáze – ale zase to má tu výhodu, že máte vše na jednom místě a pokud se vám vážně nepoškodí databáze, máte data konzistentní. Na ukládání do souborového systému mi připadá praktické to, že souborové systémy přirozeně umí se soubory pracovat, máte k souborům snadný přístup, pokud je potřebujete někam poslat (třeba po síti), dá se to udělat bez kopírování v paměti přímo z keše. Ale hlavně, bude se to daleko lépe zálohovat. Stačí zálohovat jen nové a změněné soubory, na staré nemusíte sahat. Když budete zálohovat databázi, bude to pravděpodobně dump celé databáze, takže budete zbytečně třeba každý den někam kopírovat staré soubory, na kterých se nic nezměnilo. Z tohoto důvodu bych do databáze ukládal jenom ID souboru, a z něj pak vytvořil cestu k souboru. Databáze tak bude malá, a nebude se zbytečně pořád kopírovat obsah všech souborů. Zakódujte ID třeba pomocí upraveného Base64. Pokud pak budete mít na jednu úroveň 2 znaky, budete mít v adresáři nejvýš 4096 položek, což by měl zvládnout každý souborový systém. Když použijete 3 úrovně, uložíte takhle 16 milionů souborů (ve vašem případě tedy max 16 TB), pokud byste potřeboval víc, použijete 4 úrovně.

[Ivan]

Jen bych dodal, ze existuji i jine databaze nez MySQL, a ty podporuji konzistentni binarni zalohy, vcetne tech inkrementalnich. Dokonce podporuji i point-in-time recovery, pokud ale mate cast dat na FS tak se to dela blbe.

[Filip Jirsák]

Umí inkrementální zálohy (ne replikaci) nějaká opensource SQL databáze?

[Ivan]

Myslim, ze PostgreSQL to umi. Z komercnich DB to umi vsechny. A treba posledni free verze Informixu vypadave hodne zajimave.

[Filip Jirsák]

V PostgreSQL to ale podle mého názoru pořád ještě není pro běžné použití na produkci. Jsou tam nějaká omezení, nastavení zálohování i samotná obnova jsou docela pracné.

[dush]

U MySQL lze udělat plnou zálohu a pak už jen zálohovat binární logy, které obsahují změny (INSERT, UPDATE, DELETE,..).

[ondro]

Aby som to trochu upresnil. Hladam efektivne uchovavanie komunikacie medzi dvoma systemami, ktore si medzi sebou vymienaju informacie cez textove subory. Ide mi o to vybudovat historiu komunikacie pre potreby kontroly. Ta kontrola staci aby bola jednoducha. Ak nastane nejaka nezrovnalost, tak potrebujem vyhladat konkretny subor a nasledne jeho cely obsah alebo len jeho cast (toto je ta pravdepodobnejsia moznost). Tuto historiu by som uchovaval len urcity cas, odhadom niekolko mesiacov az rok(to v tejto chvili neviem presne povedat). k tej vnutornej strukture - tie subory by sa dali rozdelit do skupin a tie subory v skupine maju rovnaku vnutornu strukturu.

K tej neprakticnosti - rozmyslam nad uchovavanim tych suborov v databaze preto lebo si ti javi cistejsie a jednoduchsie z pohladu spravy a konzistencie. Bude sa o to starat databaza a tie data nebudu "len tak viditelne". Zda sa mi to cistejsie reisenie. Mat milion malych suborov v adresarovej strukture ma trochu desi a napadlo ma to riesit cez databazu. To si len myslim, vivedte ma z omylu.

[Filip Jirsák]

V tom případě bych vytvořil adresářovou strukturu podle dat (rok/měsíc nebo rok/měsíc/den) a do té bych dával soubory. Bez databáze. Můžete na to pak použít spoustu nástrojů schopných pracovat se soubory (grep atd.) a nemusíte řešit žádnou aplikaci pro přístup k těm datům. Implementace takového řešení bude nesrovnatelně jednodušší a bude to flexibilnější.

[ondro]

Praveze by som to chcel aplikacne riesit aby ludia, ktory to budu potrebovat vedeli tie udaje rychlo vyhladat a skontrolovat. Bud cez jednoucelovu aplikaciu, v ramci vecsej aplikacie alebo jednoduchym nastrojom. Potrebujem aby s obsahom tych suborov vedeli pracovat aj ludia bez ziadnych extra zrucnosti. Tiez aby pristup k tym datam bol, co najjednoduchsi (univerzalny), do urcitej miery komfortny a "odkialkolvek". V terajsom stave sa to odzalohovava v urcitej adresarovej strukture ale, ked je potrebne nieco vyhladat, tak su to schopny urobit len urcity ludia, s urcitymi znalostami a nieje to extra komfortne. Je to cista manualna robota a ja by som to chcel zjednodusit a zefektivnit.

Bola by tu moznost rozbit skoro vsetky tie textove subory(data v nich) a tie data naimportovat do tabuliek ale vyvstava otazka navrhu databazy aby bolo mozne vidiet hodnoty v danom casovom okamihu(hodnoty po importne konkretnehu suboru). Niektore subory sa aj takto importuju do databazy ale v databaze vidime len posledne hodnoty ale do tej databazy maju pristup rozny ludia a rozne aplikacie a ked nieco nesedi, tak vinny samozrejme sme my. Preto my potrebujeme v pripade nesuladu vediet hodnoty, ktore sme my zapisali alebo preniesli v textovych suboroch. Pri pocte typov tych suborov a mnozstve hodnot to nevyzera jednoducho. Nechel by som nic komplikovane, ked sa nad tym nebudu robit extra operacie a bude sa to vyuzivat nie prilis casto na overenie. Jednoducho mi si nejako potrebujeme osetrit nase data, ktore prenasame z jedneho system u do druheho cez textove subory. Mat moznost ich spetnej kontroly, ci sme ich preniesli spravne.

[Kit]

Stále píšeš příliš obecně. Co je to za soubory? Textové, grafické, dokumenty office, PDF. Požaduješ, aby s každým zápisem vznikla nová verze souboru tak, aby ta předchozí nezanikla, ale jen přestala být vidět? Kdysi to v některých filesystémech bylo, ale zaniklo to a dnes se po tom opět prahne. Nedávno jsem někde četl článek o souborovém systému postaveném na Gitu, který by to mohl splňovat.

Jen pro upřesnění: Wordovský soubor není textový.

[ondro]

Požaduješ, aby s každým zápisem vznikla nová verze souboru tak, aby ta předchozí nezanikla, ale jen přestala být vidět?

Nieco v tom style potrebujem. Aby ak pride novy subor aby stary nezanikol ale sa niekde odlozil. Aplikacie a ludia by stale spracovali najnovsi a cakali na dalsi. Ten novy by bol stale platny az do prichodu noveho suboru. Pod tym spracovali myslim cast z nich naimportovat do databazy a cast bud len zobrazit alebo dopisat do ineho suboru (to az tak nieje moja starost, co sa s nimi presne deje). Su to vecsinou strukturovane textove subory, kde su cisla a pismena oddelene oddelovacom (csv). Su v nich rozne sumy, cisla, popisy, informacie. Tie subory sa daju rozdeli to viacerych skupin, len cisla, zmiesany text a cisla alebo len text. Vecsina sa da a aj sa spracova tak, ze ich niekto importuje do databazy (my alebo niekto iny) ale ja by som ich radsej vsetky uchovaval ako celok. Pripadalo mi jednoduchsie nasekat ich do databazy v celku ako ich importovat po hodnotach do inej databazy (vzhladom na to, na co si ich chcem odkladat a ako casto s nimi chcem robit). Aj vzhladom na to, ze vsetky nemaju rovnaku strukturu a ta struktura databazy by bola dost zlozita.

A moja prefolmulovana otazka znie, ci to ma vyznam riesit cez databazu alebo sa zmierit a len si urobit nejaku adresarovu strukturu, tam ich odkladat a len najst nejaky sposob ako s nimi pracovat. Hlavne mi islo o to, ze napisat SQL select sa mi zda jednoduchsie ako praca s textovymi subormi a to ako z pohladu aplikacie, tak aj cloveka.

[ondro]

Jedno male upresnenie. Mne by asi stacila jednoducha struktura tabulky. Nazvod suboru, obsah samotneho suboru, cas importu(ak sa importuje a importuje ho nasa aplikacia). Preto ma laka ukladat ich do databazy. Este je tu jedna otazka, ci je na to vhodna relacna databaza (pouzivame PostgreSQL a IBM DB2) alebo radsej nejaka noSQL databaza. S noSQL nemam skusenosti.

[rADOn]

Adresar, v nem milion souboru, jmeno souboru je cislo ktere je unixovym casem importu. Veskera prace s takovym ulozistem je otazka par shellovych prikazu resp. standartnich libc funkci ktere umi kazdy programovaci jazyk. Napriklad pridani noveho souboru foo/bar :

cp foo/bar /var/storage/$(date +'%s')

Troufnul bych si celou vec timto stylem zbastlit za hodinku. Databaze pro tvoje zadani neprinese naprosto nic. Pokud neco neumis v shellu co umis v sql, radsi ze zeptej zde pritomnych znalcu. Bastlit neco v SQL na co ma unix uz hotove nastroje neni lenost ale blbost.

[Kit]

Raději bych místo časového razítka použil nějaký hash, třeba SHA1. Soubory se tím krásně deduplikují.

Kromě toho u časového razítka značně hrozí kolize. To bych fakt nedělal.

[l0gik]

U hashe hrozí taky kolize... Navíc uložit soubor do databáze je záležitost jednoho volání mysql... Aby to nakonec v tom filesystému nebylo složitější.

IMHO ať to udělá v čem chcem, pokud toho nebudou alespoň alespoň stovky gigabyte - což nebudou, řádově tak jednotky GB za rok, jestli počítám, tak je to úplně šumák, jestli to udělá shellem, db, nebo třeba gitem. V čem umí nejlíp, v tom to bude mít nejrychlejc. Všechno je velmi jednoduché a dostatečně výkonné (db. paradoxně možná nejvýkonější, neboť tam jde udělat naprosto jednoduše fulltext a index a jediné, kde bude trápit rychlost je vyhledávání)

PS: Inkrementální záloha bude také i v db jednoduchá, jelikož se data pouze vkládají a nemodifikují.

[ondro]

Dakujem za reakcie.

Z mojho pohladu sa mi zda pouzitie db jednoduche a univerzalne (pristup k databaze sa da nastavit komukolvek a odkialkolvek) a existuje kopa nastrojov na pristup k databaze v pripade nudze a zapisat jednoduchy select vie urobit viacero nasich uzivatelov ako hrabat sa v textakoch na file systeme.

Nemam skusenosti s ukladanim suborov do db a tak som sa chcel prv poradit.

to rADOn: Ja to nemam problem urobit na file systeme a v shellu ale nezda sa mi to dost univerzalne riesenie pre pristup roznych ludi z roznych miest. Viedla ma to k tomu aj existencia napr. datoveho typu clob (alebo jemu podobnych typov). Ak tie datove typy existuju a daju sa pouzit na ulozenie aj ovela vecsich suborov, tak preco ich nepouzit na male textove subory. Bohuzial nemam s tym skusenosti na co je ich dobre pouzit a ake su rizika.

Pouzit na to programy na spravu verzii ma nenapadlo.

[l0gik]

Pokud Ti nejde o rychlost získání jednoho souboru, když k němu víš cestu (na to je filesystém přecijen optimalizovanější), tak to neřeš, narvi to do db - datovej typ klidně TEXT, fungovat to bude bez problémů. Soubor jsou data jako každá jiná, když na idnesu (stejnějakokdekolijinde) mají všechny články uložené v db, tak to evidentně takto jde .

[rADOn]

Jen potvrzujes co jsem psal predtim – databaze ti neprinese nic. Neco jineho by bylo kdybys chtel vyuzivat _databazove_ vlastnosti – datove typy, indexy, cizi klice, integritni omezeni, transakcni zpracovani… Nic z toho, ani nic jineho v cem by byla databaze lepsi podle vlastniho popisu nepotrebujes.

Z mojho pohladu sa mi zda pouzitie db jednoduche a univerzalne…

Z meho pohledu jsi zivy doklad prislovi, ze "kdyz vsechno co mas je kladivo, kazdy problem vypada jako hrebik". Jednoduche? Pokud sql je vsechno co umis a tvoje jedine kriterium je lenost tak mozna. Univerzalni? Jestli ti propriterani protokol pristupny pres specialni knihovnu pripada univerzalnejsi nez neco co je uz desitky let soucasti operacnich systemu, tak ti realita chysta velke prekvapeni.

zapisat jednoduchy select vie urobit viacero nasich uzivatelov ako hrabat sa v textakoch na file systeme

Opravdu mate lidi kteri ovladaji sql lepe nez midnight/total commandera? Nejsou spis ty "jednoduche" selecty fantazie ktera nebude uskutecnitelna bez normalizace obsahu tech souboru do neceho nad cim selecty jdou provadet? Protoze z blobu toho moc nevyselectis, vime?

Ak tie datove typy existuju a daju sa pouzit na ulozenie aj ovela vecsich suborov, tak preco ich nepouzit na male textove subory.

Protoze bloby jsou urcene k tomu abys jejich obsah mohl spojit s relacnimi daty. Ve tvem pripade kdybys chtel drzet a prohledavat nejaka dalsi metadata. A i v takovych pripadech se casto drzi jen cesta a soubor je na filesystemu. Protoze filesystem, ac ti to asi bude pripadat neuveritelne, je na takovou praci urcen.

Nemam skusenosti s ukladanim suborov do db a tak som sa chcel prv poradit.

Oki, poradim ti. Neptej se kdyz nechces slyset odpoved

[ondro]

dik rADOn za trpezlivost pri reakciach.

Niektore databazove vlastnosti by som urcite chcel vyuzivat. V tejto chvili neviem povedat ake a v akej miere. Evidovat asi nazov suboru, samotny obsah suboru, stav, cas spracovania a mozno este jendu-dve informacie. Mozno by bolo zaujimave previazat ju s inou existujucou tabulkou ,ak to bude mozne. Neviem presne povedat, co vsetko sa bude vo finale s tymi datami robit. Viem, ze pristup k nim nebude prilis casty, len zapisy novych a pripade potreby vyhladanie samotneho suboru, jeho obsahu, casu spracovania a stavu. Neviem povedat presne.

Na uvod mi islo o to ci a ako uchovavat textove subory v databaze. Ci je to efektivne riesenie, nejake vseobecne informacie.

Ano niektorym ludom ide lepsie praca s databazou ako s file systemov a textovym editrom.

Nechcem silou-mocou pouzivat databazu ale teraz sa tieto subory uchovavaju na file systeme a nepaci sa mi to. Minimalne z toho dovodu, ze neuchovavame o nich ziadne informacie a tak som to chcel vsetko dat do databazy. Ako so uz pisal nema problem s file systemom, skor beriem ohlad na prostredie, ludi a buducnost.

Skusim si to trochu viacej premysliet a nieco aj vyskusat. Uvidim, co mi to prinesie.

[rADOn]

Jestli te to opravdu zajima a nechces se jen utvrdit v iluzi ze php a mysql jsou pupkem sveta tak to jeste trochu rozvedu…

Ja tady soubory v blobech mam a zadny problem s tim neni. Sahli jsme k tomu proto, ze jsou ty soubory navazane na tabulku uzivatelu v existujici aplikaci a admini mohou vyuzit hotove reseni replikace a zalohovani. OTOH jsem taky prepisoval jeden nastroj z milion radkove databaze na mmapovany barel, kteryzto byl o par radu rychlejsi.

1. Korektne a konzistentne odzalohovat DB neni uplne trivialni.
2. Uzly v hierarchii nemusi byt stejne. Muzu napriklad rozdelit data do adresaru podle casu a ty nejnovejsi namountit na treba na rychlejsi ssd disk. Nebo naopak stare odsouvat na komprimovany filesystem. Vynucena homogenita databaze je sice dobra pro integritu dat, ale straslive omezuje flexibilitu.
3. Cilovy fileystem muze byt sitovy, diskove pole nebo cokoliv jineho z desitek ruzne exotickych a uzitecnych veci ktere jsou v kernelu. A i obycejny fileystem jde ruzne ladit. SQL server muzes samozrejme taky ruzne nastavovat, ale behat vice instanci sql je celkem slozite samo o sobe. Naopak kombinovat filesystemy je bezne do te miry ze treba linux s jedinym fs ani poradne nenabootujes.
4. Ridke soubory, sym/hard linky, rozsirene atributy, casove znacky, zamky…
5. Vykon. Fakt. Ne ze by sql serverny byly nevykonne, ale jsou optimalizovane uplne jinym smerem – na prohledavani velkych dat, nikoliv na jejich ukladani. Napriklad ve tvem pripade sql server muze najit zadany blob podle indexu velice rychle, ale precteni jeho obsahu zahrnuje nekolikere kopirovani po pameti nebo dokonce prenos po socketu. To jsou operace ktere tvurcum filesystemu vhaneji slzy do oci Znovu zduraznuji ze to neni chyba - databaze jsou proste optimalizovane na hledani jehly v kupe sena, filesystemy na zonglovani s katedralami. Oboji dost dobre nelze, takze BLOB ti sice umozni schovat do kupy sena i tu katedralu, ale zpusob jakym s ni sql server zachazi moc nezmeni.
6. Filesystemy jsou obecne univerzalnejsi – spoustu veci je relativne slozitejsi nastavit ale vysledek je z pohledu aplikace transparentni. Naopak v sql je nemalo veci jednodussi rozbehnout (sharding, replikace…) ale vysledkem je tanec po rozbitem skle – musis davat pozor na kazdem kroku.
7. S tim je spojena robustnost obecne – databaze maji tendence rvat vsechno do jednoho obrovskeho barelu ktery se cely najednou posere. Nejde ani tak o to ze by nesel opravit, ale dokud neni vsechno koser databaze je v hajzlu i kdyby byl spatne jediny blok v jedinem indexu. Filesystem neni tak haklivy.
8. Vubec delat v databazi vetsi zmeny za behu je docela problem. Krajni pripady se daji resit postupnym prehazovanim mastera a updatem odpojenych replik ale to je strasliva drbarna. Pokud si umis pohlidat integritu, na filesystemu se da spachat prakticky cokoliv nejakym tim kopirovanim, symlinkovanim apod. primo pod rukama aplikaci aniz by neco poznaly. Zrovna nedavno jsem mel tu cest s alterem zive tabule o ctvrt miliarde radku a veru to neni nic co bych si chtel zopakovat
9. Jemnejsi rizeni pristupu nez je mozne v databazi.
10. A pro me nejdulezitejsi bod – nastroje pro praci s databazi jsou oproti nejhloupejsimu shellu a unixu na urovni doby kamenny. Leccos by mel napovedet samotny fakt ze preklopeni ze mnou popsaneho schematu do databaze podle tveho gusta by se dalo napsat na jeden radek v shellu…

Pro databaze by se dal najit stejne dlouhy seznam jinych vyhod ale to si necham na priste. Vim ze pro tvou vec to neni vsechno relevantni, ale rad bych rozbil mytus menecenosti filesystemu jako celek.

(samozrejme nepocitam primitivni systemy jako windows ktere maji pro pevne disky jediny filesystem

[l0gik]

Víš, on je trochu problém, že tady srovnáváš mysql a php s hiend fíčurama filesystému. To co píšeš jde velmi často samozřejmě dělat i v databázi (např. řídké soubory: v db zapíšu pouze nenulové úseky dat apod.: db jen vyžaduje trochu jinou filosofii náhledu na data)

V jednom máš pravdu. Pokud jde opravdu o každou kapku výkonu, tak opravdu filesystém jako o jednu úroveň nižší nástroj nabídne větší flexibilitu a zároveň větší výkon. Na druhou stranu už ale nebereš v úvahu, že za to člověk platí: absencí všech těch nástrojů a možností, které nabízí SŘBD a které ve filesystému nejsou. Jistě: ve FS můžu cokoli měnit pod rukama. V DB ne - protože DB např. hlídá konzistenci datových struktur. To je ovšem (pro vývoj a garantování fčnosti aplikace) plus, nikoli mínus. Jistě FS se Ti kvůli každé chybě nesesype... ale také v DB si chyby všimneš, dokud je malá, ve FS jich může být hromada a nikdo nic nevědět, atd...

Evidentně máš filesystém rád a umíš s ním. Ok. Ale to, co tady vyčítáš DB, tak se v tomto případě vůbec neprojeví (např. záloha insert only databáze je triviální - ona je teda záloha každé db triviální, tys asi myslel inkrementální, horizontální partitioning a tablespacy na různých filesystémech také databáze umí), nebo nejsou nevýhodou (ano, čtení z filesystému je o něco rychlejší... trápí to někoho v případě nástroje, kdy jednou za měsíc budu číst pár stokilových blobů z databáze?)

[l0gik]

Dobrá odpověď. IMHO jsi tu zcela odůvodnil, že DB význam má, a to jsi ještě nejmenoval např. fulltext, ochranu proti současnému zápisu atd...

U malých souborů je db efektivní a dokonce na místo efektivnější než ve FS, protože FS alokuje po sektorech, zatímco DB nikoli. A zcela máš pravdu v tom, že uložení v DB dává do budoucna daleko širší možnosti než uložení ve FS.

Větší nevýhodu má DB jen jednu: o něco pomalejší čtení (nikoli vyhledávání) dat (to se projeví u větších souborů), obzvlášť přes PHP - ale jak vidno, když todle neřeší ani na takovejch serverech jako idnes, imho to nemusíš řešit taky.

[Filip Jirsák]

IMHO jsi tu zcela odůvodnil, že DB význam má, a to jsi ještě nejmenoval např. fulltext, ochranu proti současnému zápisu atd...

Asi jsme každý četli jiný komentář.

U malých souborů je db efektivní a dokonce na místo efektivnější než ve FS, protože FS alokuje po sektorech, zatímco DB nikoli.

Neporovnávejte databáze s FAT. Existují i lepší souborové systémy. My jako etalon vlastností databází taky nebereme DBF.

A zcela máš pravdu v tom, že uložení v DB dává do budoucna daleko širší možnosti než uložení ve FS.

Když řeknete do budoucna a širší možnosti, představím si pro soubory Amazon S3, Hadoop a podobné. Jaká je k tomu alternativa v DB?

Větší nevýhodu má DB jen jednu: o něco pomalejší čtení dat

Přesněji řečeno minimálně o řád pomalejší čtení. Soubor můžete do sítě poslat tak, že se z disku jednou načte do paměti, jádro předá odkaz aplikaci, ta jej předá do jádra do síťování, a síťová karta data rovnou z paměti cpe do drátů. Když to budete dělat s databází, ta data se budou několikrát v paměti kopírovat a předávat mezi systémem a aplikací.

ale jak vidno, když todle neřeší ani na takovejch serverech jako idnes, imho to nemusíš řešit taky

V případě článků to neřeší proto, protože se data mezi čtením a odesláním ještě mnohokrát transformují. Když se budou 150× kopírovat kvůli nějakým šablonám, je nějakých 10 kopírování kvůli čtení z DB už jedno. Ale statické soubory (skripty, styly) posílají ze souborového systému, ne z databáze. YouTube, Picasa, GMail, fotky Facebook - ti bloby samozřejmě neukládají do SQL databáze...

[l0gik]

To je u Tebe vcelku obvyklé, že reaguješ na něco jiného. Ne, sory, ale pokud tazatel píše, že bude u každého souboru ukládat jedny a ty samé informace (teda bude ukládat data stejné struktury), že to asi bude i provazovat na nějakou další tabulku, že tam bude záznamy vyhledávat - tak to jsou přesně úkoly, na které je DB zařízena a dělají se tam rychle a snadno.

- Jistě, některé filesystémy ukládají např. data do inodů, pokud se vejdou. Ale i inody jsou nějak konstantně velké. A navíc, zde se bavíme o souborech, které jsou zpravidla velké jako několik bloků. Který konkrétně souborový systém máš na mysli? Nemohu tvrdit, že znám všechny, ale zatím jsem neslyšel o žádném, který by neztrácel volné místo díky granularitě.

- Jasně fotky (velké soubory, které se jednou nahrají a nic se s nima nedělá) popř. styly (tzn. soubory, ke kterým přistupují všichni a furt) se optimalizují na rychlost. Ostatní soubory radši dávají do databáze, protože se tam s nima lépe pracuje, lépe se zachycují jejich metadata atd. No a pak se stačí zamyslet: je zde prioritou vysoký výkon pro mnohouživatelský přístup, nebo spíš snadnost práce s daty?

PS: odstavec o Hadoop par beru jako tvoje typické stavění vzdušných zámků a ignorování zadání uživatele. Pro pár giga logů asi nikdo nebude dělat distribuovanou databázi a podobné s odpuštěním kraviny. Do budoucna znamená, že časem bude potřeba např. přidat pár dalších vlastností k souboru, že ukládaná data částečně rozparsuje a základní info uloží strutkurovaně, by se v tom dalo lépe hledat, že ze souborů bude generovat nějaké další statistiky apod. Ne, že z jednoduchého systému na správu logů udělá jadernou ponorku s automatickým řízením a umělou inteligencí rozpoznávající a eliminující totalitní státy.

[Filip Jirsák]

To je u Tebe vcelku obvyklé, že reaguješ na něco jiného.

To si nechte pro sebe.

Ne, sory, ale pokud tazatel píše, že bude u každého souboru ukládat jedny a ty samé informace (teda bude ukládat data stejné struktury)

Nic takového tazatel nepíše. Tazatel píše, že bude ukládat obsah souboru a jeho název. Existuje nástroj speciálně pro tohle určený -- souborový systém. Mimochodem, Microsoft chtěl mít ve Windows 7 místo souborového sytému databázi. Nakonec to po dlouhém vývoji a zpoždění celých Windows 7 museli odpískat, protože to nebylo použitelné.

e to asi bude i provazovat na nějakou další tabulku

To zmínil jednou jako možnost, naopak vícekrát výslovně uvedl, že nic jiného než název souboru, čas změny a obsah ukládat nechce.

Který konkrétně souborový systém máš na mysli?

Například RaiserFS, JFS nebo Btrfs.

Nemohu tvrdit, že znám všechny, ale zatím jsem neslyšel o žádném, který by neztrácel volné místo díky granularitě.

Tady si můžete rozšířit obzory: Comparison of file systems: Allocation and layout policies. Podívejte se na první sloupec, Block suballocation.

Ostatní soubory radši dávají do databáze

Do databáze nedávají soubory. Dávají tam články, komentáře atd.

odstavec o Hadoop par beru jako tvoje typické stavění vzdušných zámků a ignorování zadání uživatele.

Tak to berete špatně. Byla to reakce na vaše vzdušné zámky o tom, jak databáze dává při uložení BLOBů do budoucna daleko širší možnosti.

[l0gik]

Přímo v odpovědi, na kterou reagujeme, tazatel píše: Evidovat asi nazov suboru, samotny obsah suboru, stav, cas spracovania a mozno este jendu-dve informacie. Takže si prosím přestaň vymýšlet a začni číst, na co reaguješ.

Ano, MS chtěl mít místo FS databází, protože je pro ukládání dat v mnoha směrech výhodná: především na vyhledávání a další zpracovávání dat. Bohužel zjistil, že napsat to tak, aby to vyhovovalo všem možným užitím FS: tedy na uložení dat všech možných druhů, je příliš obtížné - a taky asi kvůli výkonu. Tady ale jsou data silně homogenní a výkon požadován není - pouze vyhledávací, který je v db skvělý - čili zde se největší nevýhody DB neprojeví a naopak plusy projeví.

Na tailpacking jsem trochu zapoměl, to máš pravdu, nicméně tailpacking Ti problém obecně nevyřeší, pouze v některém případě zoptimalizuje. Na tři soubory o velikosti 2/3 bloku furt budeš potřebovat bloky tři, nikoli optimální dva. Takže Tvůj argument to co jsem tvrdil nijak nevyvrátil.

Ad vzdušné zámky: nepochopil. Ano, distribuované filesystémy systémy dávají člověku netušené a skvělé možnosti jako ukládat data po celém světě a kdesicosi. Naopak databáze přidává taková chabá plus jako bezproblémová správa konkurenčního přístupu, konzistenci, snadné vyhledávání dat, snadná anotace, snadné rozšíření počtu ukládaných údajů, snadné provázání s dalšími informacemi, nástroje na analýzu dat atd... Kupodivu: všechny tyto nepodstatné možnosti budou při dalším rozvoji projektu skoro s jistotou potřeba, narozdíl od od těch superfuturistických vlastností cloudových FS, které jsou sice hypersupercool, ale v praxi se používají minimálně a pro zcela jiné spektrum úloh.

[Filip Jirsák]

Homogennost dat není pro DB žádnou výhodou, výkon samostatných fulltextových enginů je lepší, než výkon fulltextů integrovaných v databázích. Databáze řeší problém ukládání blobů do bloků nebo fragmentaci úložiště úplně stejně, jako souborové systémy -- není žádný kouzelný proutek, který by databázi toho problému zbavil. Bezproblémová správy konkurenčního přístupu nebo konzistence není nic, co by tazatel požadoval, navíc na úrovni dostatečné pro jeho potřeby to řeší i souborový systém. Snadné vyhledávání dat a nástroje pro analýzu jsou výhodou souborových systémů, pro databáze je těch nástrojů mnohem méně. Anotace a rozšíření počtu ukládaných údajů tazatel nechtěl, ale i to je v souborovém systému snadné. Provázání s dalšími informacemi tazatel možná chce, možná nechce. Úplně stejně můžu prohlásit, že potřeba bude možnost předat část dat někomu na zpracování, takže mu pošlu pár souborů e-mailem nebo si je na flashce odnese domů. Nebo že bude potřeba snadné inkrementální zálohování pomocí rsync nebo HTTP.

[l0gik]

- Homogennost, čili stejná struktura samozřejmě pro DB výhodou je, protože stejně strukturovaná data jdou dekomponovat a indexovat.

- To, že výkon samostatných fulltextů je řádově lepší než těch databázových není pravda, zrovna nedávno jsem viděl srovnání, kde lucene s tsearch2 prohrálo.

- Databáze má zpravidla více menších záznamů, takže se jí ten problém týká více a tedy má i sofistikovanější algoritmy, jak problém řeší. Např. postgresql (zjednodušeně řečeno) automaticky delší záznamy rozseká po 2kB, které sype do (defaultně) 8kiB stránek. Takže výše popsaný případ u ní nenastane.

- Vyhledávání dat a analýza se dělá hlavně ve filesystému? WTF? A proč jsou tedy data mining a veškeré podobné nástroje postavené nad databázemi? A proč chtěl microsoft udělat z FS databázi, když se ve FS tak dobře vyhledává. Blbina. (nemluvím teď o konkrétních nástrojích na zpracování konkrétních logů, které různé programy sypou do filesystému, tam je majorita nedb nástrojů daná čistě tím, že lidé už ta data ve FS mají: zde evidentně nejde o běžný formát logů ale o nějaká proprietální xmlka a nejsou primárně ukládaná ve FS)

- Anotace chtěl ("a možná další jeden až dva údaje") a navíc je to nejpravděpodobnější rozšíření systému. To, že se ve FS soubory snadno anotují je opět blbina, proč tedy se něco takového dávno nepoužívá a každý formát souboru má svůj proprietální způsob anotace (ID3 tagy, popisky exe souborů atd...) a o něčem jako vyhledávání dle anotací si FS může nechat zdát?

- Pokud je v požadavcích že uživatel něco možná chce a možná ne, tak si to normální člověk přeloží: pokud navrhnu řešení, ve kterém to nepůjde, tak si koleduju o průšvih.

- Bezproblémová správa konkurenčního přístupu je potřeba vždy. Např. ve filesystému triviální řešení název souboru = čas vytvoření je častým zdrojem problémů, když se sejdou dvě události. Ano, i ve FS je to řešitelné, ale v DB nad tím nemusím ani přemýšlet a mám jistotu, že neudělám chybu.

- Nějaké další věci si můžeš samozřejmě vymýšlet, ale spojování s dalšími tabulkami zmínil sám tazatel, takže je reálnější. Nicméně, z db ani nic na flashku dávat nemusím, pouze mu dám url adresu, kde se na ta data může podívat. A inkrementální zálohování db do které se pouze přidává je velmi triviální úloha.

[Filip Jirsák]

To, že něco neumíte, ještě neznamená, že to nejde. Rozšířené atributy linuxové souborové systémy podporují už nějaký ten pátek, nad atomickým vytvořením nového souboru v souborovém systému taky nemusím nijak přemýšlet a mám jistotu, že neudělám chybu.

[l0gik]

Rozšířené atributy filesystémy sice umí, ale to je tak všechno. Nějaká rozumná indexace, vyhledávání, nebo i jen rozumné zobrazení atd... moc k dispozici není. Např. MC rozšířené atributy rozumně nezobrazí. Find s nima neumí pracovat atd... Takže ta Tvoje univerzalita nástrojů rychle vezme za svý a skončíš u toho, že si stejně budeš psát svoje nástroje, akorát pod tim nebudeš mít databázi, která Tě odstíní od spousty problémů a polovinu věcí vyřeší za Tebe.

Nepochybuju, že to jde, ale zrovna cp: teda jedna z těch univerzálních utilitek, který tady prosazuješ, to neumí. Navíc i s tím, co to umí, se nevyhneš cyklu: vymyslím jméno, zkontroluju, jestli neexistuje a popř. zarezervuju atd, dokud nenajdu volný. Možná máš nějakej nacvičenej postup, kterej to řeší a nad kterym nemusíš přemejšlet (i když zrovna např. zamykání v shellu se často řeší dost trikově), nicméně pořád tu máš riziko, že Tě vůbec nemusí napadnout, že něco takovýho musíš řešit. V DB to máš prostě zaručený.

[Filip Jirsák]

Indexace rozšířených atributů je zase vámi přidaný požadavek. cp samozřejmě umí nepřepisovat cílový soubor. V DB nemám nic zaručený, ale musím znát postup, jak té jednoznačnosti dosáhnout, stejně jako u souborového systému.

[l0gik]

cp? Kterým přepínačem? (opět, možná, že to nějaká verze někde umí, zajímá mě rozumné řešení, čili řešení dle normy).

Není? V požadavcích je ukládání rozšířených atributů (jsem rád, žes aspoň to už uznal) a to, aby šel soubor dobře vyhledat. Nepíše se dle čeho se má soubor vyhledat, tzn. každá informace, která lze použít k jeho nalezení je vhodná. Nevím, z čeho si vymyslel, že se to netýká rozšířených atributů. Jeden z rozšířených atributů má být např. stav zpracování souboru. To chceš tvrdit, že nebude potřeba vyhledat např. všechny nezpracované soubory?

Navíc, i kdyby to tam nebylo, tak směšuješ dvě věci: vstupní podmínky - tam NESMÍŠ nic přidávat, to je dané, a požadavky na funkčnost - kde naopak je záhodno, aby aplikace uměla (nebo bylo snadno implementovatelné) i to, co sice zákazník nevyspecifikuje, ale pravděpodobně chce nebo může chtít.

V DB, pokud udělám insert, tak se mi prostě nikdy nestane, že ten insert přepíše jinej záznam. Takže defakto unikátní ID nepotřeboju. Hodí se na tahání dat - ale když to zjistím, není problém ho založit, narozdíl od toho, když zjistím chybu ve FS (pokud vůbec zjistím, že se mi něco přepisuje) o nic nepřijdu.

Založení umělého PK, by záznam byl i zaručeně jednoznačně identifikovatelný je sice pravda práce navíc: během zakládání tabulky napíšu id serial primary key,. Trvá mi to asi tak sekundu a můžu se přitom dloubat v nose a bavit se s kolegou (pravda spíš asi jedno nebo druhý ), protože je to naprosto standardní věc, která k DB řešení inherentně patří, nikoho by ani nenapdalo to udělat jinak nebo neudělat a především, jak se ukázalo narozdíl od FS řešení na tom naprosto není co zvorat.

[Kit]

PK je vyžadován až od 2NF. Na rozdíl od většiny souborových systémů není problém do DB uložit několik souborů s totožným názvem a rozdílným obsahem. Můžu tedy vesele do DB ukládat INSERTem a nemusím se obávat, že si něco přepíšu.

[l0gik]

Hele, tvoje odpověď je poměrně arogantní, a přitom IMHO špatná.

Databáze je opravdu univerzálnější v tom, že spoustu věcí řeší. Například konzistenci dat, konkurenční přístup, problémy s počtem záznamů v adresáři atd... To vše je potřeba řešit, i když se nevyužije vše, co db nabízí. Proč jsou asi všechny redakční systémy (včetně těch opravdu velkých, např. noviny) implementovány s uložením článků v databázi a ne ve filesystému? Tvůj argument, že textové bloby se ukládají zhusta jako odkaz do FS není pravdivý.

Pokud máš fulltextovej index, vyseletíš daleko více a hlavně rychlejc, než z filesystému. Samozřejmě, existuje i fulltext nad FS, ale jeho použití je řádově složitější než toho nad DB.

[Filip Jirsák]

Stejně tak se dá říct, že databáze spoustu problémů přináší, třeba zpomalení přístupu nebo nutnost používání speciálních nástrojů. Redakční systémy jsou tak řešené proto, protože ukládají spoustu metadat, a obsah článku je jen jeden z mnoha údajů, které v databázi jsou. Argument o fulltextovém indexu je už úplně mimo. Samostatný fulltextový engine (třeba Lucene) toho umí mnohem víc, než fulltext vestavěný v databázi (třeba MySQL nebo PostgreSQL) -- tedy pokud ta databáze nepoužívá právě např. Lucene. A použití takového fulltextu může být taky řádově jednodušší, než jeho použití nad DB. Taky se dá obrátit váš argument na ruby -- proč asi fulltextové enginy své bloby ukládají jako soubory na disk a ne do databáze?

[l0gik]

Zpomalení přístupu: jistě. Ovšem vzhledem k tomu, kolik se bude číst dat, tak to je zanedbatelné. Evidentně, když to nevadí idnesu, tak to nebude vadit ani tady.

Nutnost používání speciálních nástrojů? To je nevýhoda, nebo výhoda? Speciální nástroj zpravidla proto, že je speciální a přináší vyšší efektivitu. Pokud se tady ta data užívají (což evidentně ano, když přepisují aplikaci na jejich správu), tak se tvorbě spešl nástrojů stejně nevyhnou.

Implementovat fulltext nad filesystémem je jednodušší než nad DB? WTF? Implementoval jsi někdy v DB index? Srovnej např. s http://www.lucenetutorial.com/lucene-in-5-minutes.html. Oproti napsání speciální aplikace na vyhledávání, udržování indexů uptodate, řešení mergování indexů (přeci je nebudeš pokaždý přebudovávat) atd je těch pár SQL příkazů směšnejch.

Že out of box umí specialní fíčury? On je potřebuje? Vzhledem k parsování strojových dat nebude potřebovat žádné spešl věci jako skloňování apod.

Navíc DB fultext umí používat snad každej - a pokud ne, tak tutoriál visí na každém kroku, zatímco filesystémovej málokdo a jen nalézt jak na to chvíli potrvá.

Kam ukládají fultextové enginy svá data už je s prominutím úplně ulítlej argument. Kam asi ukládaj data databáze? Taky do filesystému. Podle Tvé logiky je tedy DB na nic, protože by jinak DB ukládala data do DB. DB ti poskytuje komfort a úložiště vhodné pro stejněstrukturovaná data. Pokud ti jde o každej kousek výkonu, je samozřejmě lepší se mezivrstvě vyhnout. Pokud ukládáš data vhodná pro DB a je pro Tebe více komfort než rychlost (což platí v 99%) použiješ DB.

[Filip Jirsák]

Váš způsob porovnávání s iDnes je opravdu zvláštní. Když se vám to hodí, berete iDnes jako vhodné srovnání, když se vám to hodí opak, prohlásíte, že přece nebudeme srovnávat uložení pár logů a velký portál iDnes.

Speciální nástroj psql, kterým musím nejprve blob vytáhnout z databáze a zapsat jako soubor na disk, abych s obsahem mohl dále pracovat, opravdu nepřináší žádnou výhodu proti tomu, když rovnou pracuju se souborem na disku.

Fulltextový index a databázový index jsou dvě odlišné věci. Když budete chtít nad databází implementovat pořádný fulltext, který má aspoň stopwords, lematizaci a proximitní hledání, budete tam stejně někde mít -- ať už viditelně nebo skrytě -- Lucene nebo něco podobného. Speciální aplikaci pro vyhledávání a udržování indexů není potřeba psát, stačí ji stáhnout a nasadit. Což se v případě databáze musí udělat také.

Navíc DB fultext umí používat snad každej - a pokud ne, tak tutoriál visí na každém kroku, zatímco filesystémovej málokdo a jen nalézt jak na to chvíli potrvá.

Nesmíte všechny soudit podle sebe.

Kam ukládají fultextové enginy svá data už je s prominutím úplně ulítlej argument.

To je jen reakce na vaši argumentaci, že libovolný blob je vždy vhodné uložit do databáze. Evidentně není. Takže byste se měl zaměřit na to, proč zrovna v případě tazatele je vhodné bloby ukládat do databáze.

Pokud ukládáš data vhodná pro DB

Soubory jsou data vhodná pro souborový systém. Pro DB jsou vhodná strukturovaná data.

je pro Tebe více komfort než rychlost

plsql nebo mysql nepovažuju zrovna za vrchol komfortu.

[l0gik]

Idnes je obrovský server. Pokud tedy nějaké řešení používá on, je z hlediska výkonu zcela jistě vhodné i pro toto řešení. To ale neznamená, že KAŽDÉ řešení, které idnes používá, je nutné a vhodné použít na takto malý projekt (např. load balancing je tady k ničemu). Co je na tom k nepochopení?

No pokud je pro Tebe cíl práce s logy vytvořit soubor na disku, pak ano, pak je lepší je uložit na disk. Já s logy pracuji jinak: prohledávám je, čtu je, vyhledávám ten, který mne zajímá, dále je zpracovávám atd... A k tomu nikterak nepotřeuji je nejprve vyplivnout na disk, naopak na spoustu činností (např. vyhledávání) se dělá lépe přímo v db.

To, že fulltext a db index jsou dvě věci nijak nepopírám. To, co tvrdím je, že implementace fulltextu v DB je jednodušší než ve filesystému. Ano, můžu si stáhnout spešl fulltext, stáhnout apikaci na správu indexů, napsat aplikaci která bude přidávat data a řešit vše potřebné okolo..... ale proč bych to dělal takto složitě, když v databázi mám ten samý výsledek na třech řádkách? Zdá se mi, že žiješ v 20 století, kdy opravdu stály FTS v DB za nic, dnes jsou bezproblémově použitelné (ano, stopwords i leximizaci postgresql má).

Já nesoudím podle sebe, já soudím podle toho, že implementace Fulltext search v databázi je na tři řádky, zatímco ve filesystému řádově přinejmenším na desítky, a podle toho, že fulltext v databázi se používá vkaždém druhém projektu, zatímco implementace spešl fulltextu se objevuje daleko řidčeji a spíše čím dál tím méně, protože db fulltext je natolik vyspělý, že dostačuje.

Jenže tady se neukládají jen soubory, ale informace o souboru. To, že jedna z položek (obsah souboru) je výrazně větší než zbytek může být teoreticky výkonnostní problém, ale (viz IDNES) pouze teoreticky. V principu tedy budeme ukládat velké množství záznamů s furt stejnou strukturou (název, čas, stav, obsah, ...,...), kdy navíc budeme potřebovat podle jednotlivých položek těch struktur vyhledávat. Tzn. práce pro db.

Pokud píšeš databázové aplikace tak, že se ovládají pouze pomocí psql (byť pro člověka, co s tím umí je i toto dosti komfortní přístup, ale to by byla jiná debata), pak Tvoje námitky chápu. Už ovšem přístup pomocí např. admineru se nijak neliší od filesystému (spíš je lepší, protože se v něm vyhledává snáž) a napsání jednoduché webové aplikace zpřístupňující data vhodnou formou je opět jednodušší, než totéž nad filesystémem.

[Filip Jirsák]

Já si log z 15.3.2012 přečtu tak, že napíšu view 2012-03-15.log a prohlížím si jej pohodlně ve vimu. Jak to děláte vy s databází, že je to ještě snazší a pohodlnější? Proč bych složitě instaloval databázi, psal aplikaci pro ukládání dat, aplikaci pro vyhledávání a pro čtení, když ve vyhledávači mám totéž na třech řádcích? Zdá se mi, že žijete ve 20 století, kdy existovaly jen samostatné vyhledávací enginy a aplikace kolem nich bylo nutné teprve vystavět. Dnes už jsou hotové vyhledávače bezproblémově použitelné. Fulltextový vyhledávač má každý s Windows Vista a vyšší nainstalován na počítači, dále se používají Google Desktop Search a další aplikace. Rozhodně má mnohem víc lidí na počítači nainstalován souborových fulltext než databázový server. V souborovém systému se samozřejmě neuchovává jen obsah souboru, ale také informace o souboru. iDnes pravděpodobně soubory neukládá do databáze, ale v souborovém systému.

[l0gik]

Ano, u logu z 15.3. to tak jde. Pokud je těch souborů stovky denně, nejvíce času strávím nalezením toho správného. Ve filesystému se v hromadě souborů hledá dosti špatně. Právě možnost co nejsnažšího vyhledávání byla v požadavcích.

Jinak aplikaci pro ukládání dat samozřejmě psát musím tak jako tak, protože to není tak, že ta xmlka někde jsou a extra bych je do databáze dával: mám někde xmlka a buď je někam přesouvám do FS, vymýšlím unikátní jména atd..., nebo jedním SQL příkazem je vložím do databáze. Obojí je cca stejně složité (obé na jeden delší řádek), akorát v DB mám ihned zadarmo ukládání i dalších metadat o souboru a jejich indexaci.

Pokud je pro Vás např. apt-get install postgresql složité, no tak potěš koště, navíc tu db již mám zpravidla na stroji stejně nainstalovanou. A příprava struktury DB se nijak neliší od přípravy FS struktury, kam budu ukládat soubory.

Nabízet na vyhledávání mezi stovkama logů denně Google desktop search, pak už beru jako fakt blbej vtip a nedostatek argumentů, to ani není třeba komentovat. To jako si ty logy vždycky přehraju ze serveru k sobě? Nebo na tom serveru kvůli tomu poběžím Xka? Tendle argument se Ti fakt nepoved: ten člověk nehledá blbou hračku, ale použitelné řešení, se kterým se bude co nejlépe a co nejrychleji (v případě průšvihu) pracovat.

[Filip Jirsák]

Ukládání jakých metadat máte v databázi zadarmo? V souborovém systému máte rovnou s obsahem souboru uložený také název a datum vytvoření. V databázi nemáte ani to. Pokud chcete získávat nějaká další data ze souborů, musíte ten soubor analyzovat a musíte také navrhnout příslušné databázové struktury, což bude rozhodně složitější, než návrh adresářové struktury. Výhodou pak samozřejmě bude, že v těch strukturovaných datech půjde lépe vyhledávat. Ale pokud vím, tazatel chtěl ukládat soubory, ne z nich extrahovat strukturovaná data a ta ukládat. apt-get install postgresql mi nepřipadá o nic jednodušší, než apt-get install solr.

[l0gik]

Všech: v rámci jednoho insertu tam vložím cokoli. Název souboru při ukládání musíš taky napsat, čas taky v databázi můžeš udělat s default value, takže to je naprosto srovnatelný. Jo, možná je FS o to jednoduší, protože je dělanej na ukládání trojic Název, čas, data, tak že tam nemusim napsat, že ukládám zrovna tudle trojici. Jenže jakmile ukládám něco trochu jinýho, má FS problém.

Ano: instalace je stejná (až na to, že na rozumnym serveru ta db už je, zatímco Solr nikoli, takže vlastně také ne). Ale tím to bohužel končí. Narozdíl od postgresu, kde budeš mít všechna data na jednom místě, tady musíš řešit zvlášť ukládání dat do fulltextu a zvlášť zbytek. Takže většina zbylých věcí bude náročnější. Např. máš díky tomu nedořešenou atomicitu (už zkopíruješ soubor, ještě ho nezaindexuješ Solru, a skript Ti spadne), případná obnova dat bude složitější atd. atd. A z pohledu zaměstnavatele bych člověka, kterej přijde s tím Solr, hnal, protože pokud mi podobnou službu udělá nástroj, s kterym umí pracovat 90% lidí, neni důvod nasazovat věc, se kterou se většina lidí, co s ní přijde do styku, bude muset učit.

Argument o jednoduchosti FS struktury je s prominutím blbina: do databáze mohu v jednom varcharu postihnout totéž, co cestou v adresářové struktuře. Pokud mi to stačí, nikdo mě nenutí dělat nějakej overengineering. Ale ono se bude vyhledávat podle více kritérií (např. podle času a zdroje dat, nebo podle stavu dané věci atd...) a tady už filesystému dojde dech, zatímco db se furt šťourá malíčkem v nose.

[Filip Jirsák]

Do Solru se dá uložit i celý obsah souboru. Firma, kde umí 90 % lidí pracovat s SQL ale neumí pracovat s webovým vyhledávačem možná existuje, ale rozhodně není běžná.

[l0gik]

Dá, pak je to ale úplně jiné řešení, než jsi na počátku prosazoval.

Nejde o práci s vyhledávačem (ono vzhledem k tomu, že zdaleka ne vždy je potřeba hledat dle fulltextu, tak stejně je třeba kolem toho něco postavit) ale o to, že o to řešení se někdo bude dále starat a rozvíjet ho, když náhodou z té firmy odejdeš. A tady řešení používající majoritní technologie velmi silně vede.

[rADOn]

Kdyby se obtezoval si moji odpoved precist celou tak bys zjistil ze zadnou ze zminenych vlastnosti SQL nepopiram. Naopak, sam je denne vyuzivam. Moje odpoved vychazi z toho ze tazatel podle sveho popisu zadnou z nich nepotrebuje. Redakcni system totiz nepise takze to co pises je sice pravda ale zcela irelevantni.

Az na ty fulltexty – to je strasliva blbost. Fulltext je soucasti unixu uz od usvitu veku a obesel se bez sql. Vsechny decentni fulltextove stroje pouzivaji binarni barely optimalizovane pro zpusob jakym se pri hledani ctou, ktery si obvykle mmapujou primo do pameti. Rychlosti s jakou tyhle strojecky makaj se fulltextovej index v databazi ani nepriblizuje

[l0gik]

Nepotřebuje? Copak nepotřebuje v případě chyby vyhledávat, který přenos chybu způsobil? Takže indexy potřebuje. Jak nefulltextové (omezení dle času vzniku souboru), tak i fulltextové. Jistě, existují i fulltexty mimo DB. Ale srovnej, kolik práce potřebuješ k jejich nasazení oproti pár SQL příkazům zprovozňujícím fulltext v DB.

Copak nepotřebuje ochránit, aby v případě dvou simultáních přenosů se tyto nezapsaly do jednoho souboru? Potřebuje. Takže potřebuje transakce. (jistě, jde to řešit, ale v db to vůbec řešit nemusím).

Inkrementální zálohy: opět

Copak ke každému souboru nebude ukládat ta samá metadata (čas uložení, zdroj, velikost, stav zpracování atd....). Bude. Takže využije i to, že DB je velmi vhodná pro uložení dat se shodnou strukturou.

Získaná data nějak popisují činnost služeb. Ta možná bude třeba nějak analyzovat. Takže se budou hodit i agregační funkce, řazení dle různých kritérií.

atd....

[Filip Jirsák]

Copak nepotřebuje ochránit, aby v případě dvou simultáních přenosů se tyto nezapsaly do jednoho souboru? Potřebuje. Takže potřebuje transakce.

Nezáleží na tom, jak tomu říkáte, ale operaci "vytvoř soubor, pokud ještě neexistuje", zvládá snad každý souborový systém.

Copak ke každému souboru nebude ukládat ta samá metadata (čas uložení, zdroj, velikost, stav zpracování atd....).

Tazatel psal o názvu souboru, čase změny a obsahu souboru. Tyto informace ukládá drtivá většina souborových systémů.

Získaná data nějak popisují činnost služeb. Ta možná bude třeba nějak analyzovat. Takže se budou hodit i agregační funkce, řazení dle různých kritérií.

Agregace a řazení nad blobem? Pravděpodobně jste volně přešel k tomu, že se do databáze nebudou ukládat soubory, ale místo toho se soubory rozparsují a do databáze se uloží strukturovaná data. Což je ale úplně jiné zadání. Nějakou posměšnou větičku o neschopnosti držet se zadání si doplňte sám.

[l0gik]

Umí. Ale klasické FS operace: např. v bashi (třeba cp) ani klasické fopen v C++ to neumí. Musí se to tedy řešit jinak, než se řeší věci "běžně". Tzn. i když člověk správné řešení vysype z rukávu, furt je to věc, na kterou je třeba myslet a také kde se dá udělat chyba.

Ne, tazatel psal o více údajích. Furt si vymýšlíš. Už jsem Ti i citoval, pokud je něco marný, je to marný.

Agregovat a řadit bude třeba právě ty další metadata, např. datum vytvoření souboru (řazení je jasné, argegace je např. odpověď na počet událostí během dní) atd.

[rADOn]

Atomické operace nad fs jsou součástí posixu už od dřevních dob. Jsi fakt odvážný vyjadřovat se tak autoritativně k něčemu o čem ani nevíš že to existuje, natož jak se to používá.

Co se údajů týče, možnosti DB tady všichni známe. Co jsem stále ještě neslyšel je v čem konkrétně filesystém nedostačuje tomuto zadání. Zatím jsme se jen dozvěděli že některé standartní vlastnosti unixu neumíš používat :-P

PS Sorry pokud to zní arogatně. Nevím co slušněji říci když mě někdo přesvědčuje že můj denní chleba neexistuje.

[l0gik]

Ne, v pohodě, to akorát neumíš číst (promiň, že to zní arogantně, ale oplácím stejnou mincí).

Já snad někde tvrdím, že v posixu nejsou atomické operace? Já jen tvrdím, že nemalá část běžně používaných nástrojů potřebné atomické operace neumí a tedy že když to bude člověk dělat "bez přemýšlení", tak to s velkou pravděpodobností napíše blbě. Tzn. že člověk musí extra přemýšlet nad tím, které nástroje může a nemůže použít a jak - a navíc na potvoru musí použít zrovna ty, které nebývají "first choice", takže je větší pravděpodobnost, že je ani nebude znát a bude muset do manuálu. Jako příklad jsem pak dal jak cp, které nemá přepínač způsobující selhání při existenci souboru nebo fopen kde taktéž schází v normě C++ i posixu mód pro exklusivní zápis. Chceš popřít, že to jsou běžně užívané funkce v bashi/C++, nebo chceš popřít to, že implementace těmito fcemi má za následek možnost chyby plynoucí z race condition?

Stejnětak jsem nikdy netvrdil, že filesystém zadání nedostačuje, pouze, že implementace ve filesystému bude (jakožto implementace v univerzálnějším a nízkoúrovnějším prostředí) pracnější, jelikož dost z potřebných věcí DB implicitně (jako např. transakce, řešení race conditions apod.) či sice explicitně, ale daleko jednodušeji (fulltext, vyhledávání, ukládání dalších metadat a jejich prohledávání) poskytuje a tedy je zbytečné vymýšlet kolo, protože implementace v filesystému bude mít jedinou podstatnou výhodu: rychlejší přístup k obsahům souborů, a to nikoho trápit nebude.

[rADOn]

Příkaz cp není ani "operace" natož atomická. Atomická kopie se dělá jinak. open() má O_EXCL flag, kromě toho jsou tu takové nedůležité maličkosti jako fcntl() a flock(). Nepočítaje v to ten drobný detail že zamykání je něco trochu jiného a k tebou uváděnému případu konkurenčního zápisu to může použít jen začátečník. To by ti přece neprošlo ani v databázi. Čili jsi jen dokázal že někdo kdo o tom ví kulový to dokáže napsat blbě. Zvláště když chce. Chceš popřít že běžně používané dotazy v sql nejde napsat tak aby obsahovaly stejnou race condition? Chceš popřít že člověk s pěti mozkovými buňkami se tomu dokáže bez námahy vyhnout? Chceš popřít že nemáš páru jak totéž udělat nad fs? Chceš popřít že tvůj názor je takto na hovno?

Konkrétně, pokud je vstup dejmetomu na stdin tak by se bezpečný (atomický na tohle není potřeba) zápis dal udělat zhruba takhle…

dest=$(date +"%y/%m/%d/neco-%s.$$")
mkdir -p $(dirname $dest) && cat - > $dest

Zadání splněno, méně než minuta práce… A teď mi zopakuj pohádku o tom jak je v databázi všechno jednodušší

[l0gik]

Filip tady hájil FS, že tam je spousta standardních nástrojů a že se o ně zbytečně připravuju. Tak ukazuju, že z té spousty nástrojů je většina, a to ještě těch standardně užívaných, použít nelze.

Ano, open má flag. Jenže běžně používané funkce na vstup/výstup není open, což je nízkoúrovňová operace, ale fopen. S open nemáš bufferování, parsování vstupu/výstupu atd. atd. Proto většina lidí používá fopen a open použije pouze když musí.
Právě to, že se atomické operace dělají ve FS jinak než standardní operace je ten problém, který na FS řešení kritizuju, neboť vede k riziku chyby.

Máš pravdu, že běžně používané dotazy v tomto případě: tzn. přidání nového záznamu tak, aby nekolidoval klíč záznamu, jde napsat i v db tak, aby nastala race condition. Narozdíl od FS ale:
1) standardní způsob jak se to dělá bezpečný je, tady člověk musí přemýšlet, aby udělat insert nebezpečný, standardně jsou operace atomické a vkládané záznamy unikátní. Ve FS je to naopak: tam člověk musí explicitně ošetřit atomicitu či unikátnost, aby to fungovalo správně
2) i když to člověk udělá nebezpečně, je zvykem klíč označit jako klíč, tzn. chyba neskončí tichým přepsáním dat, ale zařve. Ve FS, když to člověk zvoře, tak na chybu třeba nikdy nepřijde.

Navíc to Tvé řešení je špatně. Co když Ti ten skript v půlce spadne? Zůstane Ti tam soubor se špatnými daty, a ty ani nebudeš vědět, kterej to vlastně soubor je. Správně je to nejprve nasypat do tempsouboru a ten pak atomicky přesunout. To jsou přesně ty špeky, které ve FS jsou a na které nemusí člověk přijít.

Já furt nevím, proč mi vkládáš do úst, že tvrdím, že nemám páru, jak to udělat nad FS. Těch způsobů je spousta: ať jednodušších, kdy si data zaplevelíš pidem, po složitější, kdy se pokoušíš ve smyčce najít volné jméno souboru. Co tvrdím je, že first choice a zároveň nejjednodušší možnost (cp zdroj `$date`) je chybná a proto toto řešení je méně odolné proti chybě programátora.
A jak vidno, i second choice je chybná. Takže jsi jen potvrdil, že FS přístup je méně odolný proti chybám a vyžaduje víc než 5 buněk pro to, aby to programátor napsal dobře. A zapojení té 6 buňky stojí programátora i čas.

No a nakonec, já netvrdím, že vše ve FS je složitější - opět polemizuješ se svým fantómem. Ano, poté, co přijdeš na race condition a "zaplevelíš" jméno souboru pidem, a opravíš chybu s atomicitou, tak je furt složitost +- srovnatelná (ovšem nikoli mentální, vymyslet to správně je těžší). Jednodušší i na napsání je vše okolo, tzn. ukládání dalších metadat či práce s nimi, fulltext, indexace dle data (vyhledání událostí od ... do data atd...).

[Filip Jirsák]

Ty nástroje jsou grep, find, perl, head, tail atd. Myslel jsem samozřejmě nástroje použitelné pro tento konkrétní případ a zejména pro zpracování těch souborů. Vy neustále operujete nemožností s cp atomicky vytvořit soubor, přičemž ale žádný rozumný scénář týkající se diskutovaného problémů žádnou takovou operaci nezahrnuje.

Vámi popsaný standardní bezpečný způsob použití v databázi se týká případu bez provázaných tabulek. Sám ale pořád argumentujete tím, jak bude strašně výhodné mít uloženo spoustu dalších dat. Jakmile přidáte další závislé tabulky, běžně používaný způsob přestane být bezpečný. Najednou bude potřeba se starat o transakce, a to nepatří ke standardnímu způsobu práce s MySQL.

Co tvrdím je, že first choice a zároveň nejjednodušší možnost (cp zdroj `$date`) je chybná

Ano, je to chybné, ale hlavně proto, že to nedělá nic smysluplného v kontextu této diskuse. Nikde v zadání určitě nebylo, že chce mít tazatel nějaká data uložená dvakrát.

No a nakonec, já netvrdím, že vše ve FS je složitější - opět polemizuješ se svým fantómem. Ano, poté, co přijdeš na race condition a "zaplevelíš" jméno souboru pidem, a opravíš chybu s atomicitou, tak je furt složitost +- srovnatelná (ovšem nikoli mentální, vymyslet to správně je těžší). Jednodušší i na napsání je vše okolo, tzn. ukládání dalších metadat či práce s nimi, fulltext, indexace dle data (vyhledání událostí od ... do data atd...).

Zatím jste ale nevyřešil, odkud se ta data vůbec vezmou. Ono je totiž dost pravděpodobné, že příprava pro zápis do databáze by spočívala v tom zapsat soubor s unikátním názvem na disk…

[l0gik]

Žádný rozumný scénář neexistuje? V zadání je, že někde je xml soubor, který je třeba nějak persistentně uchovat. Nevím, jak Tebe, ale podle mě většinu rozumných programátorů první co napadne, tak ho zkopíruju nebo přesunu na nějaké trvalé umístění. Nicméně pokud Ti tak vadí, že jsem jako příklad vzal cp, tak si to cp nahraď mv. To to totiž neumí úplně stejně.

Nicméně, i cp samozřejmě smysl má, např. pokud chci s tím zdrojovým souborem ještě dále pracovat, pokud chci zkontrolovat, že při přesunu (který mohl být mezi filesystémy) nedošlo k chybě, pokud je ten soubor původně je někde na síťovém disku, kam nemám právo zápisu, ale pouze čtení, pokud ho budu zálohovat atd...

Příprava dat do databáze spočívá v zapsání unikátního souboru? Prosím proč? Buď tam někde ten soubor už je - ale s názvem a umístěním, které není vhodné pro trvalé zpracování (např. vzniklý voláním mktemp). Anebo přišel odněkud přes síť. V obou případech nijak nepotřebuju vytvářet nový soubor a ani pokud ten soubor na disku byl, tak se nemuselo při jeho vytváření řešit problém, jak udělat název zároveň smysluplný (nesoucí význam) a zároveň unikátní.

[Filip Jirsák]

Mezi cp a mv je dost podstatný rozdíl. Jak z hlediska výsledků, tak z hlediska předpokladů. Např. mv v rámci jednoho souborového systému je atomická operace, můžete takto bez problémů přesunout soubor, do kterého se stále zapisuje, a mv s parametrem -n selže, pokud soubor s cílovým názvem už existuje – navzdory tomu, že vy o tomto chování nevíte.

Je fajn, že jste si konečně všiml, že ten soubor s unikátním názvem už nejspíš někde uložený je. Takže stačí jej přesunout (nebo klidně i okopírovat) do správného adresáře, a je hotovo. O generování unikátního názvu se nemusím starat, protože to zajišťuje již zdrojový soubor.

[l0gik]

A ty víš, že je to na jednom filesystému? Ne? Takže irelevantní argument.

O tom, že na různých systémech jsou různé nestandardní přepíánače vím, ale pokud řeším problém a není specifikovaný systém, tak se držím POSIX normy: http://www.unix.com/man-page/POSIX/0/mv/ a v té tento přepínač není.

Takže ho stačí přesunout do správného adresáře? WTF? A kde máš zajištěno, že v tom adresáři už soubor se stejnym názvem neni? Kde máš řečeno, že ten soubor nevzniknul např. voláním mktemp, který samozřejmě může vytvořit soubor se stejným názvem dvakrát, pokud první mezi tím zmizí? Navíc si chtěl v názvu souboru uchovávat informace, jak víš, že v tom zdrojovym názvu jsou a ve formě jak je potřebuješ? A jak víš, že soubory nepocházejí z více zdrojů? Atd.... Jinými slovy: ano, pokud mu něco vytváří unikátní soubory, má problém s unikátností souborů vyřešen. Je to někde v zadání? Ne? Opět si tedy zadání ohýbáš, jak se Ti hodí. A i kdyby bylo, tak stejně je to věc, kterou ve FS musíš ověřovat, že tomu tak opravdu je, zatímco v DB to prostě nemusíš řešit.

Všiml sis, že tady už pěkně dlouho řešíme tu úplně nejtriviálnější věc: spolehlivé založení souboru. To, co se v DB udělá jedním insertem a není tam jediný problém? Zatímco tady furt řešíme jak co je a není atomické (a vidno úplně triviální to není), vede to k užití nepřenositelných přepínačů (navíc pak tam musíš mít test a další řešení co když se to nepovede, takže složitější kód), kolega navrhl zas řešení, které není odolné výpadku a má i další chyby... Proč bych se tím měl zatěžovat? Abych pak mohl použít standardní nástroje jako find a grep, když databáze mi nabízí na vyhledávání daleko efektivnější nástroje? Nebo perl, kterému je úplně šumák, odkud data dostane?

PS: ...chyby: např. když zároveň vedle poběží analyzátor, tak může spadnout na nekompletním XML, protože přečte soubor dřív než je dokopírován (i mv je atomické pouze na jednom FS a zaručeno není).

[Filip Jirsák]

Neřešíme, řešíte. My to řešit nepotřebujeme, protože to umíme. Taky bychom tu mohli podobně řešit váš jeden insert, že to vlastně vůbec není tak jednoduché, že se musí použít sekvence, když budu chtít použít ID v další tabulce, musím použít transakce a umět to ID zjistit… A navíc v SQL 92 žádné sekvence nejsou, a málokterá databáze plně podporuje něco novějšího, takže když se držím SQL normy, žádné jednoznačné identifikátory vygenerovat nemůžu. V zadání přece nic o možnosti použít SQL 2003 nebylo.

Když ten nekompletní XML soubor budete mít v databázi, myslíte, že na tom budete líp?

[Kit]

Nějak mi uniká, jak se může do databáze dostat nekompletní soubor. Buď tam není nic, je tam stará nebo nová verze. Nic mezi tím.

[l0gik]

- Sequence je standard SQL 2003 a podporují je většina databází (přinejmenším Postgresql, Oracle, MS SQL). Takže Tvoje argumentace normou je blbina. Mohu se držet normy a identifikátor v pohodě vygenerovat. A v DB, které normu nepodporují se sekvence vždy dají velmi snadno nahradit.

- V zadání samozřejmě nebylo nic o SQL 2003, protože v zadání nebyly předepsané prostředky, kterým se má řešení dosáhnout. V zadání nebylo ani použití cp a mv, dokonce ani POSIX filesystém, to znamená, že to při řešení nesmím použít??

- SQL normy se držet nemusím, protože konkrétní databáze je sama normou a je přitom snadno přenositelná. Narozdíl od FS utilit, které jsou systém od systému různé a přenositelné jsou těžko. Když vymyslíš řešení s netradičním cp, tak to budeš na jeho konkrétní systém implementovat dosti blbě. Když vymyslíš řešení se sekvencí, tak v libovolné databázi to řešení implementuješ snadno stejně jako snadno na daný systém přeneseš danou databázi (pokud to nebude MS SQL teda ).

- Když chci použít id v další tabulce, tak to už mám řešení, které svoji funkčnost dosti přesahuje jednoduché uložení souboru do FS - to odpovídá jedné "ploché" tabulce. Srovnávej srovnatelné.

- Na zjištění id vloženého záznamu rozhodně nepotřebuju transakce! To nevíš ani takovoudle základní věc?? (úplně pominu to, že opět použití transakce je naprosto standardní věc, nad kterou se nemyslí a automaticky dělá).

- Jak to "umíte" ukázal Tvůj kolega, který tady dal špatné řešení, i defakto ty, když jsi tvrdil, že cp umí nepřepisovat soubory (a pro jistotu řešení nedodal žádné).... No comment.

- Jestli nevíš, tak zápis do databáze je atomický, takže se tam žádný nekompletní XML soubor nedostane (respektive může se tam dostat, ale nebude ostatními přistupujícími klienty vidět a bude brzo přepsán, takže jako by nebyl). Opět neznalost úplně elementární věci a přitom mě tady poučuješ, jak "umíš".

[l0gik]

PS: abych doplnil, pravda postgresql se od normy trochu odlišuje (o pár znaků v zápise při volání next value for). Plně 2003 SQL compiant ohledně sequencí jsou zbylé dvě plus např. Firebird, Db2, podobně jako postgresql je na tom informix. Jedinej, kdo z běžně užívanejch db nemá sekvenci je mysql, kde ale autoincrement ji pro tento případ nahrazuje dostatečně.

[rADOn]

Jak to "umíte" ukázal Tvůj kolega, který tady dal špatné řešení,

Tak to bych si vyprosil. Moje "řešení" měl být příklad jak si to zorganizovat, ošetření závisí na tom jak ty soubory doopravdy vznikají pročež jsem je pominul. Ve skutečnosti se spíše budou přehazovat hotové soubory což je atomické samo o sobě, stdin jsem použil aby se to snadno vyzkoušet. I kdyby data opravdu padaly na stdin, řešení je jak jsi sám poznal, triviální – jeden rename. I kdyby to bylo třikrát tak dlouhé, stále jsi nějak nevysvětlil v čem bude databáze "jednodušší".

[l0gik]

Ukazoval jste, jak umístit soubor do konečného úložiště, pokud lezou korektně ze stdin. Pokud ale z nějakého důvodu (např. nedostatek místa na disku, chyba, nedostatek paměti na serveru, výpadek UPS, nevímco) by byl skript v průběhu příkazu přerušen, v úložišti by zůstal nekompletní soubor. To nijak nesouvisí s původem souboru, to je prostě špatně zvolená metoda k finálnímu umístění souboru. Je to přesně to, na co jsem narážel: že sice existuje hafo standardních příkazů k práci s FS, ve skutečnosti se ale zdaleka všechny nedají použít.

Jo, možná teď chcete tvrdit, že jste tam něco neošetřoval, protože.... ale zaprve si šáhněte do svědomí, zdali jste tuto možnost opravdu uvažoval, jednak i kdyby jo, tak zas jestli jsi úmyslně vynechal polovinu skriptu, abys mohl říct: "hele, jak je to jednoduchý," tak to je dosti nekorektní argumentace, ne?

V čem je db jednodušší jsem napsal desetkrát, napíšu to klidně po jedenácté. Jednoduchost řešení v databázi spočívá v tom, že tam člověk narozdíl od FS nemusí přemýšlet jak to udělat, aby vyloučil chyby plynoucí z race condition a atomicity, protože to za člověka řeší db. Bude se tam lépe a efektivněji implementovat jak vyhledávání, fulltext, tak i ukládání dalších atributů a bude to i řešení rozšiřitelnější (vzhledem k ukládání dalších návazných dat, provádění a ukládání výsledeků analýz, zodpovědnosti za řešení bugů atd...).

PS: data nemusí padat na stdin, mohou padat na nějaký socket, mohou být na jiném FS, na síti, mohou být pro daného uživatele read-only... Ve všech těch případech nemohu použít atomické mv a musím to udělat dvoufázově.

[l0gik]

PS: Ale to, že je to špatně neříkám proto, abych ukázal, "jak jsi blbej" , já bych takovou chybu možná udělal taky. Ukazuju na to proto, protože právě tydle operace nad FS jsou v tomdle prostě zákeřný. Když mi to DB v podstatě zadarmo a bez práce ošetří....

[Filip Jirsák]

Pokud ale z nějakého důvodu (např. nedostatek místa na disku, chyba, nedostatek paměti na serveru, výpadek UPS, nevímco) by byl skript v průběhu příkazu přerušen, v úložišti by zůstal nekompletní soubor.

Zatímco v případě databáze by taky mohla zůstat porušená celá databáze. To je opravdu výhra.

data nemusí padat na stdin, mohou padat na nějaký socket, mohou být na jiném FS, na síti, mohou být pro daného uživatele read-only... Ve všech těch případech nemohu použít atomické mv a musím to udělat dvoufázově.

Ve všech těchto případech je to problém načítání vstupu, a je potřeba ho ošetřit i při ukládání do databáze. Akorát když to bude dělat člověk, který souborovým systémům nebo síťové komunikaci rozumí, nejspíš na to nezapomene. Když to budete dělat vy, prohlásíte, že zápis do databáze je atomický a není potřeba to řešit, a budete to mít neošetřené.

[Kit]

Pokud ale z nějakého důvodu (...) by byl skript v průběhu příkazu přerušen, v úložišti by zůstal nekompletní soubor.

Zatímco v případě databáze by taky mohla zůstat porušená celá databáze. To je opravdu výhra.

To by byla docela hloupá databáze, kdyby takovou prkotinu neustála.

Ve všech těchto případech je to problém načítání vstupu, a je potřeba ho ošetřit i při ukládání do databáze. Akorát když to bude dělat člověk, který souborovým systémům nebo síťové komunikaci rozumí, nejspíš na to nezapomene. Když to budete dělat vy, prohlásíte, že zápis do databáze je atomický a není potřeba to řešit, a budete to mít neošetřené.

Do databáze? Jaké ošetření? Proč? Transakce se buď udělá, anebo ne. To si databáze ošetří sama.

[Filip Jirsák]

Do databáze? Jaké ošetření? Proč? Transakce se buď udělá, anebo ne. To si databáze ošetří sama.

Přesně jak jsem psal, když někdo slepě věří, že si databáze vše ošetří sama, bude mít program přesně s tou chybou, na kterou tady L0gik pořád vytýká souborům. Tak ještě jednou: když máte na vstupu nekompletní soubor, jak uváděl L0gik, souborový systém ani databáze nic sami neošetří a skončíte s nekompletním souborem v úložišti, ať jím bude souborový systém nebo databáze. Souborový systém v tom má jednu výhodu – pokud budete soubor přesouvat v rámci jednoho souborového systému (což je celkem logické, nedává moc smysl jej kopírovat z harddisku na harddisk), nemusíte se o to starat. Soubor prostě přesunete, a zápis bude plynule pokračovat do „nového“ souboru. V případě databáze tam samozřejmě vždy musíte naprogramovat nějakou logiku, která umí zjistit, že vstup už je celý a je možné zahájit kopírování do databáze.

[Kit]

Tak ještě jednou: když máte na vstupu nekompletní soubor, jak uváděl L0gik, souborový systém ani databáze nic sami neošetří a skončíte s nekompletním souborem v úložišti, ať jím bude souborový systém nebo databáze.

Tak ještě jednou: Než budeš příště něco takového tvrdit, ověř si to. Databáze si s tím poradí. Vkládaná data budou buď kompletní, anebo tam nebudou. Nic mezi tím. Totéž platí pro update. Buď původní, anebo nová. Opět kompletní.

[Filip Jirsák]

Příloha:

• input.xml (7 bytů)

Dobře. V příloze k tomuto komentáři máte nekompletní vstupní soubor. Načtěte ho do databáze. V databázi bude podle vašeho tvrzení kompletní, takže ho jistě můžete kompletní přečíst a přidat jej jako přílohu k dalšímu komentáři.

[Kit]

Příloha:

• input.xml (7 bytů)

Jistě. To není problém. Soubor z DB mám kompletní, obsahuje stejných 7 bytů, které jsem do něj vložil.

[Filip Jirsák]

Soubor z DB nemáte kompletní. Kompletní soubor má 16 bajtů. Takže ta vaše databáze zas takové zázraky, o jakých píšete, neumí.

[Kit]

Pokud jsou vstupní data považována za nekompletní, do databáze se neuloží vůbec. Jenže dodaný 7bytový soubor byl technicky vzato kompletní, i když nebyl validní XML.

Ke zkrácení 16bytového souboru došlo na úrovni souborového systému, nikoli databáze. Pokud by ten soubor pocházel z jiné tabulky a měl 16 bytů, nemůže se stát, že by se do jiné tabulky překopírovalo pouze 7 bytů.

[Filip Jirsák]

Nebo-li to, zda je vstupní soubor kompletní, je potřeba řešit v každém případě – ať se bude ukládat do databáze nebo do souborového systému.

[Kit]

Ne. Pouze při převodu FS-DB a při převodu FS-FS. Problém je stále na straně souborů, nikoli databází. Při přenosu dat mezi tabulkami či databázemi se to řešit nemusí, tam je integrita garantována.

[l0gik]

Je-li vstupní soubor kompletní především v daném zadání nelze řešit, protože není informace, jak to poznat, ani způsob, jak to řešit.

Mnou vytýkaná chyba se týkala úplně něčeho jiného a existuje i při zaručeně kompletním vstupu a DB řešení ji řeší. Bohužel jsi to asi doteď nepochopil a proto se nedokážeš s ostatními dohodnout, protože místo co bys řešil to, co ostatní: tu zmíněnou chybu, tak řešíš něco, co prostě z principu s daným zadáním řešit nelze (a tak nikdo nečeká, že by to někdo řešil).

[l0gik]

Ale kdo tady mluví o nekompletním vstupu? O vstupu nic nevíme, tak je blbina řešit nějaké hypotetické možnosti způsobené vstupem. Ty jsi podstatu té chyby opravdu nepochopil, ta na kompletnosti vstupu nezávisí, to fakt nemá cenu. (anebo pochopil a úmyslně se snažíš demagogicky odvést debatu jinam??).

O tom, že databáze se zmrší celá - to je opět argument jak noha. Úplně stejně se Vám může zrušit celý filesystém. Obojí se na dobře spravovaném stroji, pokud není chyba HW a člověk používá rozumné prostředky, nestává.

PS: Ano, při splnění X premis (jeden FS, právo zápisu, zdrojový soubor si do logu neotvírá postupně více handlů....) je přesun atomický. Vzhledem k tomu, že jde o dva systémy, které si vyměňují informace přes textťáky, tak ty soubory s největší pravděpodobností leží někde na síti a tedy přinejmenším premisa o stejném FS splněna není, pravděpodobně tam nebude ani právo zápisu (v dobře spravovaném prostředí má každej proces pouze nutná oprávnění).

[Filip Jirsák]

Ale kdo tady mluví o nekompletním vstupu?

Vy.

[l0gik]

Tím jen dokazuješ, že opravdu "neumíš". Protože já jsem nikdy nemluvil o nekompletním vstupu. Já jsem mluvil o případech, kdy přestože bude mít vámi popsané řešení k dispozici kompletní vstup, tak programy pracující s cílovým úložištěm uvidí soubor nekompletní. Právě proto, že navrhované řešení používá neatomické operace k přesunu souboru do cílového umístění (tzn. někdo jiný může vidět půl operace, popř. se dokonce může skript v půlce operace přerušit, pak je výsledkem trvalé porušení struktury).

Celou dobu tady přesvědčuješ, jak jsi dobrej a jak umíš řešit záludnosti FS, a doteď jsi nepochopil, že to prezentovaný řešení je v tomdle děravý?? No comment.

[Filip Jirsák]

V prezentovaném řešení by další operace se soubory následovaly po úspěšném dokončení přenosu do cílového umístění. Úplně stejně, jako v databázi. V obou příkladech na to programátor musí trochu myslet – v souborovém systému otestovat návratovou hodnotu příkazu, v databázi pokračovat v práci ve stejné session.

[Kit]

Opět problém v konverzi dat do FS. Ideální by bylo nepřevádět záznamy do FS a zpět, ale všechny operace provádět přímo na DB. Jenže bohužel většina aplikací pracuje pouze se soubory.

Pokud by například kompilátor cpp byl DB funkcí, vypadalo by to např. takto:

UPDATE tabulka obj=cpp(zdrojak);

Pokud by při kompilaci došlo k chybě, zůstaly by původní obj a vyvolala by se výjimka. Nemohlo by se stát, že by se část souborů zkompilovala a část ne.

Netvrdím, že je to žádoucí chování kompilátorů, ale pokud by zdrojáky byly v DB, neřešili bychom verzování. Verzování v souborovém systému kdysi sice bylo, ale kvůli vysoké ceně médií bylo vytlačeno souborovými systémy bez verzování.

[l0gik]

Nepochopil. To je fakt marný. Hele, fakt toho nech, protože jen ukazuješ, že opravdu o špecích ve FS nevíš. Všimni si, že i Tvůj kolega to uznal, že je tam potřeba o jedno mv navíc.

= Když ti to kopírování vprostřed spadne, tak tam máš prostě nedokončenej soubor. Nevíš ani kterej to přesně je, abys to opravil.

= Když poběží analyzátor v jinym procesu, což je standardní řešení: spousta analýz je třeba dělat až na vyžádání a dle požadavků uživatele, tak analyzátor uvidí i právě ukládané a tzn. nekompletní soubory.

PS: Je to poslední pokus Ti to vysvětlit. Mlátit hlavou do dubu nehodlám.

[Filip Jirsák]

O kterém řešení píšete? O tomhle? Můžete popsat konkrétní scénář, ve kterém nebude výstupní soubor kompletní a příkaz na třetím řádku vypíše nulu?

dest=$(date +"%y/%m/%d/neco-%s.$$")
mkdir -p $(dirname $dest) && cat - > $dest
echo $?

Když poběží analyzátor v jiném procesu, musím s tím počítat a soubory do cílového umístění atomicky přesouvat. Když poběží analyzátor v jiném procesu, musím s tím v drtivé většině případů počítat i v databázi. V některých hodně jednoduchých případech to bude fungovat správně i tehdy, když s tím počítat nebudu, ale vědět, které to jsou, to vyžaduje dost podrobné znalosti konkrétní databáze.

[l0gik]

Konkrétní scénář je ten, že příkaz cat spadne. To, co je na třetím řádku nikdo nezjistí, protože skript prostě spadnul.

V požadavcích bylo, aby šel soubor v případě potřeby vyhledat a zpracovat. V případě potřeby znamená, že to vyhledávání má být nezávislé na ukládání (běží tu a tam) a tedy pochopitelně v jiném procesu poběží. Takže tento požadavek v zadání byl a přesto navrhované řešení touto chybou trpí.

Naopak V KAŽDÉ (SQL) DATABÁZI, pokud jedním příkazem uložím obsah souboru, tak ho ostatní session buďto mají k dispozici celý, nebo vůbec. A pokud ukládám data dekomponovaně a používám (dle standardu a dle základních pouček o psaní db aplikací) transakce, opět je jejich viditelnost "atomická". Takže žádnou dosti podrobnou znalost konkrétní databáze nepotřebuji, stačí mi elementární znalost pravidel, jak se píšou DB aplikace. To Ti evidentně chybí, pokud jsi schopen napsat takovou blbinu.

[Filip Jirsák]

Když skript spadne, tak se příkazy na třetím a dalším řádku neprovedou. Takže těžko mohou pracovat s nekompletním souborem. Vyhledávání nad nekompletními soubory ničemu nevadí – přinejhorším najdu soubor, který se teprve kopíruje, takže pokud jej uživatel bude chtít vidět celý, bude si na něj muset počkat. V případě databáze se o něm vůbec nedozví, dokud nezkusí znova celé vyhledávání. Takže to není žádná chyba, nikde v zadání nebylo řečeno, že uživatel soubor buď nesmí vidět vůbec, nebo ho musí vidět celý.

Kdyby viditelnost celé transakce byla vždy atomická, není potřeba řešit různé úrovně izolace transakcí. Vaše poučka platí pouze o serializovatelné úrovni izolace, která ovšem má odpovídající výkonnostní dopady.

[l0gik]

Spadlý proces bude těžko pracovat, ale kterýkoli další proces, který bude nějak pracovat s daty bude muset tento chybný soubor řešit.

Přinejhorším najdu soubor, který se teprv kopíruje... Takže další složitost, kvůli tomu, že nemáš atomické přesuny, tak všichni, kdo pracují s daty musí řešit zdali čtený soubor je nebo kus. Fakt skvělý. Zatímco to, že DB aplikace tento soubor prostě ignoruje (což je chování identické tomu, kdyby byla spuštěna o půl ms dřív) je strašlivá chyba. Ano, v zadání to řečeno nebylo - ono se to jaksi předpokládá automaticky. To jako chceš popřít, že konzistence dat a možnost konkurenčního přístupu není žádáná vlastnost? Ufff...

Izolace transakcí je různá, ale atomicita zápisu (tzn. nedělitelnost zapsaných změn) platí nikoli od úrovně serializible, ale už od read commited. Rozdíl v dalších úrovních je akorát v opakovatelnosti čtení, transakce však vždy vidí pouze výsledek ostatních transakcí.

Standarní úroveň izolace transakcí je přinejmenším read commited (osobně za ní považuji repeatable reads) a stadardně je izolace na tyto úrovně nastavena. Read uncommited se používá ve velmi speciálních případech - defakto je to explicitní vyžádání, aby DB porušila atomicitu zápisu. Takže to není třeba řešit, je to vyřešeno, jen má člověk možnost to obejít, když se mu to hodí. Tvůj argument je tedy, jako bys říkal: když jedu autem, musím řešit startování klikou. No podívej: vyndám startér a ono to nestartuje a musím mít kliku.

Navíc to vše se týká zápisu více hodnot atomicky, což ve FS už nejde udělat vůbec, takže se zde pohybujem na úrovni, kteoru FS poskytnout nemůže vůbec. Ten horkotěžko zajistí atomicitu některých operací, což je věc, kterou DB zajistí vždy a za každé okolnosti.

[Filip Jirsák]

Neúplný soubor klidně můžu dostat už na vstupu. Takže s touto možností musím při práci s daty počítat stejně. Konzistence dat ve smyslu buď úplný log nebo nic je zrovna v případě logů vlastnost spíše nežádoucí, tam zpravidla platí opačný požadavek – klidně i jen částlogu, ale hlavně mít aspoň něco.

Ve FS atomický zápis více hodnot udělat lze – přejmenováním souboru s rozšířenými atributy, přejmenováním adresáře, vytvořením symbolického odkazu na soubor nebo adresář… Pro jemnější řízení přístupu je pak možné použít zamykání uvnitř souborů.

[l0gik]

Pokud něco je schopno produkovat neúplný soubor, je správná cesta ho při zpracování zkontrolovat a případně vyloučit a informovat admina, protože se něco stalo špatně. Ne chybu ignorovat a navíc ještě propagovat dál.

--

Anebo můžu rovnou napsat databázi.... To co jsi dal všechno řeší jen malý výsek z možných kombinací operací (zápis více hodnot nemusí jít do jednoho podstromu, či xattrs nemusí stačit na rozumnou strukturaci dat) a navíc to je dosti neefektivní (chci změnit xattrs u 1GB souboru - musím ho proto zkopírovat a pak atomicky přejmenovat zpátky atd... Čím obecnější transakce to bude řešit, tím to míň bude FS využívat a více to bude operace nad FS zneužívat (jako různé obskurní přejmenovávání adresářů), popř. to transakce bude řešit externími nástroji (zámky a strukturamy popisujícími, co je vlastně zamčeno).

Samozřejmě, že to nakonec vždycky nějak udělat půjde, v tom jsem samozřejmě své tvrzení hodně zjednodušil: spíše jsem měl říci, že FS neposkytuje efektivní nástroje pro transakce. Zbastlit se to tam samozřejmě dá, ale zpravidla to nebude ani hezké, ani efektivní, ani jednoduché řešení. Přičemž samozřejmě čím více se bude jednoduchost transakcí blížit atomickým transakcím, tím méně krkolomné to bude.

Když to srovnáš s přímočarým a jednoduchým konceptem transakcí v db...

[Filip Jirsák]

FS neposkytuje efektivní nástroje pro transakce

V tom se shodneme. Akorát že transakce jsou při zpracování logů málokdy potřeba.

[l0gik]

- Ano, dokud je třeba ukládat jednu vlastnost. Až bude třeba ukládat jejich analýzy, už to neplatí. Nebio pokud nějaká služba vyplivne dva soubory najednou. Ale v tom zadání, jak je teď ne, v tom máš pravdu.

- Do (víceoperačních) transakcí jsi mne ale nutil Ty, já zde naopak hájil, že my stačí atomicita, která je v DB transparentí. O transakcích jsem tady začal mluvit, abych ukázal, že DB je v jištění proti race conditions o řád dál: zatímco FS má probléímy už při atomicitě (musí se to spešl řešit a ne vše jde (jednoduše) atomicky), tak DB má atomicitu bez práce a dokonce i transakce.

[Filip Jirsák]

POSIX normy se držet musíte, protože jste si to vymyslel. SQL normy se držet nemusíte, protože jste si vymyslel, že se jí držet nemusíte. To je vskutku rovný přístup.

Když na zjištění ID vloženého záznamu nepotřebujete transakce, jistě sem dokážete dát posloupnost SQL příkazů, kterou použijete.

GNU cp má parametr -n, který zakáže přepis cílového souboru. Když vy si můžete stanovit, že použitá databáze umí sekvence, já si můžu stanovit, že použité cp umí nepřepisovat soubory.

Psal jste o případu, kdy se zdrojový soubor začne zpracovávat dříve, než je zapsán celý. Zpracování může být jak kopírování jinam, tak zápis do databáze. Opravdu ani databáze si neumí správný obsah souboru domyslet. Neznalost úplně elementární věci je to na vaší straně – vymyslíte si tvrzení, že zápis do databáze je atomický (které je nic neříkající, někdy to pravda být může, někdy nemusí), zapomenete, že vlastně píšete o čtení ze souboru, a nesmysl je na světě.

[l0gik]

Databáze jako taková je portovatelná snadno kamkoli a proto jako normu můžu vzít jako normu její konkrétní implementaci SQL. Nijak mi to implementovatelnost na libovolný stroj (pokud to nebude 8bit atari) neovlivní. Nicméně i tak jsou sequence části normy SQL, takže jejich užívání normu neporušuji, ač tvrdíte opak.

POSIX normy se držím, protože vůbec nevím, jakej má tazatel systém (a když budu chtít řešení přesunout, tak to s proprietálním přepínači půjde těžko). Pokud na jeho systému mv -n mít nebude, tak si tam těžko bude portovat jinou implementaci. Třeba solaris mv má v určitých drobnostech jiné chování než GNU, takže instalací GNU mv si člověk může zadělat na pěkné problémy. Samozřejmě: vše je řešitelné. Jen je otázka za jak dlouho a s jakým rizikem chyby.

---

Posloupnost příkazů? To se fakt chceš až tak ztrapnit až tak, že nevíš, že operace nad sekvencema je by definition nezávislá na transakcích? Takže třeba:

SELECT NEXT VALUE FOR moje_sequence ;
INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*)

anebo (tady pro postgresql)

INSERT INTO tabulka (...) VALUES ();
SELECT curval(moje_sequence);

a taky to nebude trpět chorobou z konkurečního přístupu, i když to neudělám v transakci. Překvápko, co? Vidím, že fakt "umíš". (sorry za sarkasmus, ale todle fakt nejde, normální člověk dřív, než něco takhle opakovaně tvrdí, tak si to aspoň zkontroluje, že to tak opravdu je, jinak je za blbce).

A navíc v každé db je funkce na zjištění ID vloženého záznamu (LAST_INSERT_ID v Mysql, RETURNING clause v Postgresql, Oracle, Firebird), takže těch cest je X a pokud neudělám select zpět na tabulku (což je ta úplně nejhloupější cesta a navíc nesmyslná, protože select má smysl pouze pokud umím záznam identifikovat a pak to ID vlastně ani nepotřebuju), tak transakci nepotřebuje snad žádná.

---

Vzhledem k tomu, že o vstupu nic konkrétního nevíme, tak je normální předpokládat, že je korektní (předpokládal to i Tvůj kolega).

A ano, analyzátor může začít zpracovávat soubor vzniklý z korektního vstupu dříve, než ho v příkladu prezentované řešení pomocí cat zapíše celý, zatímco v databázi se to opravdu stát nemůže.

Atomicita je přesně daný termín, pokud se bavíte o takovýchto věcech a nevíte co to znamená, tak no comment. Tak si to přečtěte na wiki. Operace nad databází (pokud nepoužívají externí funkce přistupující jinam, ale to už pak není čistě DB operace) jsou atomické vždy z definice, nikoli pouze někdy, jak tvrdíte. To Ti už dokládat nebudu, už mě to nebaví, nechám to Tvému samostudiu.

[Filip Jirsák]

Chcete tím říct, že databáze se portuje snadněji, než GNU cp nebo GNU mv?

To se fakt chceš až tak ztrapnit až tak, že nevíš, že operace nad sekvencema je by definition nezávislá na transakcích?

Myslel jsem si, že aspoň o těch databázích něco víte. Teď vidím, že jsem se mýlil.

SELECT NEXT VALUE FOR moje_sequence ;
INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*)

To je ten běžný postup, který se všude používá?

anebo

INSERT INTO tabulka (...) VALUES ();
SELECT curval(moje_sequence);

Výjimka asi nebude přesně to, co jsem chtěl získat. Zapomněl jste totiž na to, že curval() funguje jen v rámci jedné session.

A navíc v každé db je funkce na zjištění ID vloženého záznamu

A všechny logicky vyžadují buď stejnou transakci nebo stejnou session. Což se nezařídí samo od sebe, ale musí o tom programátor vědět a napsat to tak. Když to nevíte ani vy, jak na tom asi bude ten programátor?

A ano, analyzátor může začít zpracovávat soubor vzniklý z korektního vstupu dříve, než ho v příkladu prezentované řešení pomocí cat zapíše celý, zatímco v databázi se to opravdu stát nemůže.

V příkladu řešení pomocí cat by analyzátor logicky začal práci až po úspěšném dokončení catu. Pro databázi lze samozřejmě taky vymyslet nějaké hodně hloupé řešení, které se bude pokoušet číst data z databáze dřív, než tam budou zapsaná. Třeba ten váš slavný první kód rozšíří programátor takhle, a bude volat klasicky každý příkaz zvlášť, tedy v nové transakci a potenciálně v nové session:

SELECT NEXT VALUE FOR moje_sequence ;
INSERT INTO tabulka (id, ...) VALUES (*ziskane_id*);
CALL analyze(*ziskane_id*);

[l0gik]

Ano - databáze je totiž k portaci na všechny rozumné systémy připravená a navíc její instalace neinterferuje se systémem. GNU fileutils je sice na některé systémy taky k portaci, ale jejich instalace se systémem interferuje, tzn. mění jeho vlastnosti, a tak je daleko problémovější.

Zdali je to běžný postup, který se všude používá? Všude se nepoužívá nic, ale je, je to naprosto standardní a základní způsob jak se se sekvencemi pracuje (v podstatě dle SQL standardu moc jiných možností není). Ty fakt neznáš ani základní idiomy používané v SQL databázích? Nedivím se, že pak chceš řešit vše ve FS, když neumíš databáze používat...

Že vyžadují stejnou session je problém? A ty jako někdy píšeš tak, že pro každej SQL příkaz děláš nový připojení do databáze? Víš vůbec, co je to session?? Tendle příkaz samozřejmě každej kdo jen trochu umí s databází použije pouze jako přímou posloupnost příkazů v jednom spojení. Jinak použije první řešení (chce-li psát dle normy), nebo ještě spíš řešení s returning, které je jednopříkazové. Ono teda rozumný člověk ta druhá řešení použije tak jako tak: todle řešení je ze zmíněných X řešení nepotřebujících transakci nejhorší a nedoporučuje se z určitých důvodů užívat. Dal jsem ho sem ale právě proto: abych Ti ukázal, že ani to nejhorší řešení které jakoby na race condition trpí ve skutečnosti také transakci nepotřebuje a teda jaké s odpuštěním bláboly jsi tvrdil.

Analyzátor zpravidla spouští uživatel, když ji potřebuje a je naprosto nezávislý na zdroji analyzovaných dat. Analýza se také zpravidla netýká jednoho záznamu, ale X záznamů za nějaký čas, spouštět ji po každém insertu je tedy zbytečné.

[Filip Jirsák]

Cha cha, che che, chi chi.

Jsem rád, že jste konečně uznal, že to v té databázi také nefunguje samo od sebe a musí se to správně použít. Stejně jako ty souborové operace. Přičemž běžnému pojídači koláčů spíš dojde, že cp může nějakou dobu trvat, než že musí dávat pozor na to, odkud bere databázové spojení a zda má zaručeno, že se pro oba dva příkazy použije to samé. Ono úplně stačí, že si to pěkně rozdělí do dvou funkcí, v každé si řekne poolu uloženému v kontextu o databázové spojení, a problém je na světě.

[l0gik]

Rozumný člověk narozdíl od Tebe ví, že když chce pracovat nadále s nějakým objektem, tak si jeho identifikaci nejprve vygeneruje a pak v aplikaci používá. Pokud má jako Ty zlozvyky z MySQL, kde tento postup nejde použít (a proto Ti připadalo řešení s NEXT VALUE FOR divné) tak že se id čte okamžitě po založení záznamu. To patří k úplně základním programátorským návykům při práci s db.

Pokud existuje člověk, kterej si myslí, že na jednom místě založí objekt a někde na druhém místě pomocí jiné db konexe se zeptá na poslední vložené id a že to bude fungovat, tak ať dá ruce pryč od databáze a od programování vůbec. To, že Tě taková s odpuštěním prasárna vůbec napadla o něčem svědčí. (To je, jako by si pro uložení názvu vygenerovaného souboru použil místo proměnné nějaký soubor ve FS a divil se, že Ti ho může jiný proces přepsat a nadával bys, že ten FS je naprosto na nic).

Použití cp či cat > je naprosto standardní postup, který se často používá, jen někdy není vhodný. To, cos tady popsal je prasečina v každém případě, navíc Tebou zasazená do dosti nepravděpodobného scénáře, aby se vůbec projevila. To, že to seš schopný srovnávat svědčí buďto o Tvé totální neznalosti DB programování, nebo o úmyslné demagogii. Proto se předem omlouvám, pokud se další diskuse nebudu účastnit: opravovat furt Tvé omyly mě nebaví a diskuse s demagogem je zbytečná.

Takže ano, pokud považuješ za výhru to, že před s odpuštěním totálním prasetem neochrání ani databáze, tak ano. Vyhrál si (ať má Tvé ego klid - i když to, že i v databázi to jde zprasit jsem psal v jednom z prvních příspěvků). Před blbostí totiž opravdu spolehlivá obrana není.

[Filip Jirsák]

Přesně to samé se dá říci opačně – zlozvyky z MySQL jsou standardní postup, který jen někdy není vhodný. Kdo neví, že atomický vznik plného souboru získá jen pomocí mv na stejném souborovém systému, ať dá ruce pryč od programování.

K poslednímu odstavci bych jen dodal to, že při dodržení některých základních pravidel dostanu od databáze lepší podporu pro transakční zpracování. Což na druhou stranu vede na neopodstatněné spoléhání na to, že databáze správně zařídí transakčnost, i v případech, kdy tomu tak není.

[l0gik]

Standardní postup je takový, který odpovídá standardům a minimalizuje riziko chyby. Obojí postup z MySQL nesplňuje (byť ta chyba může vzniknout úplně jinak, než co jsi se snažil ukázat).

Dokud se při zakládání souboru nepoužívá VŽDY metoda vytvoř dočasný soubor a atomicky přesuň, je situace naprosto nesrovnatelná, protože výše zmíněné chyby se evidentně dopustí člověk snadno, zatímco tvojí prasečinu s ID rozumnej člověk neudělá. Rozdíl je vidět i v tom, že zatímco chybu s cat > nejde jednoduše objevit, člověk se nad tím musí zamyslet, tak Tvojí prasečinu s ID lze detekovat primitivní statickou analýzou zdrojového kódu.

K poslednímu odstavci se dá říci toto: směšuješ transakční zpracování a atomicitu, jde o dvě věcí: databáze má atomické operace i bez použití transakcí. Nikdo neříká, že databáze Ti zařídí transakce sama od sebe, pouze atomické čtení a zápis. O transakci musíš explicitně požádat a ta má své limity.

U FS je to ale daleko horší, ten nemá transakce vůbec a o atomicitu musíš explicitně požádat (vybrat správný způsob provedení dané operace). Navíc narozdíl od DB lze požádat pouze ve speciálních případech (zatímco v DB je každá jednotlivá operace atomická automaticky) a proto se narozdíl od DB, kde používání transakcí patří ke slušnému chování, atomicita často stojí výkon navíc a proto se standardně nevyžaduje.

Proto je FS v tomto ohledu daleko horší a méně user friendly: něco tam nejde (některé atomické operace, transakce) a vzhledem častému k používání neatomických operací člověk běžně atomicitu neřeší a proto ji pak neřeší ani tam, co má. V DB člověk bez ztráty výkonu má nejen atomicitu, ale i transakce a je standardem je používat. Pokud neřeším atomicitu ve FS, mám na 99% průšvih. Pokud v DB a nepíšu jako prase, málokdy to způsobí problém.

[lertimir]

Takto asi se přimo radit nedá. Podstatné jsou dvě otázky.

1. co jsou to za data? jsou RDF, SOAP, XML nebo jsou to logová data tvaru čas - událost? mají nějaké identifikátory transakce? Těch možností jsou mraky.
2. Podle čeho se bude vyhledávat? podle času? transakce? fulltextově podle obsahu? nebo podle nějakých charakteristik?

Obecně řečeno, je v podstatě jedno, jak to bude ukládáno. Podstatné je, aby to podle čeho se bude vyhledávat, bylo zaindexované a jestli v databázi nebo nějaký jiným indexerem je skoro jedno, při zátěži, kterou očekáváte. (jako příklady mě napadá, tracker, beagle, nepomuk, ale už vidím jak mne tu za ně zašlapávají) Index je potřeba vymyslet tak, aby když budete potřebovat něco najít, tak na rozumný dotaz vám index odpověděl vše co potřebujete.

[Kit]

Je možné, že potřebuješ něco jako systém pro správu verzí. SVN, Git, Mercurial nebo Bazaar. Dá se to velmi snadno automatizovat.

[kuka]

Kazda databaze to nejakym zpusobem umoznuje. Asi te neprekvapi, ze pro zadani "nasledne relativne efektivne pracovat" a "subor dal lahko vyhladat a nejakym sposobom spracovat" ti nikdo nic rozumneho neporadi.

[mess]

Jak se tak na tebe dívám, tak by se ti možná hodil nějaký systém správy verzí, třeba Git. Když po každém exportu/importu uděláš commit, tak se ti inkrementálně "zazálohujou" nejnovější změny. Dá se to různě prohledávat (git grep), je to inkrementální a jako bonus se z toho dá dostat informace, jaké změny kdy byly. A existujou pro to grafická klikátka (qgit, gitg, gitk, giggle ...).

A když po commitu uděláš i push někam na server, tak budeš mít i zálohy.