Python, databáze a správa dat

20.9.2014 08:55 | Přečteno: 3622× | pripravto | | poslední úprava: 21.9.2014 11:48

Na Připravto používáme mnoho různých formátů dat. Jako hlavní pracovní formát používáme pickle modul (ukládání dat) + shelve (slovník pro ukládání), který je dobře použitelný právě pro Python. Vzhledem k tomu, že aplikace vytváří množství rozdílných dat, tak je potřeba mít dostatečně pružnou databázi. Data se váží pro jednotlivé produkty - nábytek, kde jsou informace o rozměrech, materiálech, kování, dílcích a apod po zakázky, zpracované kalkulace a podobně.

Jako vedlejší formát máme YAML, který se hodí pro více standardizovanou formu zpracování a exportu. V současné chvíli je právě spíše záložním formátem a pro materiály, kde je dobrá rychlá možnost úpravy. Již před nějakou dobou, jsme přešli pro z pickle/YAML exportu do Blenderu na JSON, který se pro toto použití docela dobře hodí, jelikož formát je docela již běžný, takže se dobře zpracovává na obou stranách. Podobný formát v JSON máme i pro ThreeJS. No a pak máme sérii JSON/XML/CSV/DXF/OBJ/SVG/BLEND exportů, které jsou určené hlavně pro předávání dat dále.

Dříve jsme plánovali používat nějakou SQL databázi jako je sqlite (zdá se jednoduše použitelná). Po čase se ukázalo, že z důvodu potřeby různých datových struktur, je SQL obtížné a hlavně do budoucna (formát se může změnit) těžce udržovatelné. Proto jsme nakonec pro zpracování zakázek vybrali formát shelve (máme i upravenou verzi, která umí použít sqlitedict jako backend - ale o tom někdy příště). Čímž je možné sdílet data mezi jednotlivými instancemi a tak podobně.

Jak už to ale bývá, upravený shelve v kombinaci s dubmbdbm a pickle protokolem 0, sice funguje již několik měsíců docela dobře pro databáze na zakázky, ale není to úplně použitelné. První věc je, jak upozorňují na stránkách, že časem může narůstat. A to je docela pravda ze souboru, který má na začátku 2-5KB, se za nějakou dobu stane např. 40MB soubor (těchto souborů pak máte i více). Toto lze řešit např. přes update a vytvořením nového souboru (bude mít třeba 3MB). Ukázkový kód pro aktualizaci databáze. Je to možné upravit tak, aby se nejdříve vytvořila a zapsala kopie a pak se nahradila původní verzí. Případně přidat try/except blok pro mazání/zápis. Je nutné to provádět při vypnuté aplikaci.

 
    def update_db(filename="/tmp/database"):
        """cleaning up  python -c  'import utils; utils.update_db()'"""
        database = shelve_database(filename)
        data = {}
        data.update(dict(database))
        database.close()
        os.remove("{}.dat".format(filename))
        os.remove("{}.bak".format(filename))
        os.remove("{}.dir".format(filename))
        new_database = shelve_database(filename)
        new_database.update(data)
        new_database.sync()
        new_database.close()

Situace

Bohužel, větší problém přichází při automatickém verzování této databáze. Pokud používáme v Pythonu pickle modul s protokolem 0 (pozor ještě na kódování), tak se dá dobře verzovat. My na to používáme bzr - je dobře propojitelné na Python. Stejně tak se dá použít git/hg. V případě shelve, ale už to není tak jednoduché, jelikož je částečně binární (začne být více, při bobtnání) a to už se pak hůře verzuje. Proto jsme chtěli vyměnit shelve s dumbdbm vyměnit za něco užitečnějšího, např. shelve+sqlitedict. Tato kombinace vcelku funguje, ale není přímočará.

Zkoušeli jsme několik jiných objektových databází, ale použitelnost byla pro naše účely obtížná. Obvykle to vyžadovalo sérii specifických úprav a hlavně se to hůře používalo. Pak jsme objevili Dobbin a ZODB. ZODB je pěkná věc, avšak těžce instalovatelná. Bohužel sama o sobě neumí řešit např. přidání nového klíče do slovníku - shelve ano (je potřeba zvláštní slovník). A také sestavení ZODB je úplně někde mimo. Dobbin je naopak vcelku jednoduchý a dobře použitelný, bohužel také se mu již nevěnuje pozornost. Nakonec jsme však našli to, co bylo potřeba.

Řešení

Pickleshare většinu těchto problémů řeší. Jedná se o databázi pracující se složkou a soubory.  Ve složce jsou uložené jednotlivé pickle soubory (dobrá verzovatelnost, jednoduchá údržba a úpravy). V případě nastavení protokolu 0, je možné načítat v Pythonu 3 i 2 a hlavně i samostatně. Tzn jednotlivé soubory jsou načítatelné přímo Pythonem jako části slovníku a jsou tedy dobře opravitelné v případě potřeby. Instalace pickleshare je jednoduchá. Dokonce není ani potřeba instalovat - je možné kopírovat.

    pip install path pickleshare

Pokud máte problém s instalací modulu Path a máte IPython, tak stačí upravit import na řádce 41 v souboru pickleshare, tak aby použil Path z IPython a následně zakomentovat původní. Mimo to některé instalace IPython mají v sobě i pickleshare. Více o Pickleshare na stránkách.

    #radek 41 v souboru pickleshare
    #from path import path as Path
    from IPython.external.path import path as Path
    import os,stat,time

Ukázka na zakázce pro Elišku s kalkulací a optimalizací.

    import initialization as oc
    from inout.optimio import PickleShareDB
    db = PickleShareDB("/tmp/orders_new") #nová db
    orders = oc.shelve_database("/tmp/orders") #původní db
    db.update(dict(orders))
    db['eliska_edit'].calc
out:
    [Calculation(name='eliska_edit',cost=32078.9680716),
    Calculation(name='eliska_edit',cost=32078.9680716)]

    db['eliska_edit'].calc[0].cost
out: 
    [{'name': 'mat_GLASS',
      'price': 200,
      'quantity': 0.57,
      'total': 114.6068,
      'unit': 'm2/m3'},
     {'name': 'mat_U625',
      'price': 251.76,
      'quantity': 5.34,
      'total': 1344.2827666320004,
      'unit': 'm2/m3'}]

A nyní adresářová struktura a jednotlivé klíče.

    fractal@fractal-laptop:/tmp/orders_new$ ls -l
    celkem 4680
    celkem 4680
         645 2014-09-19 19:27 ales
       62523 2014-09-19 19:27 blansko_skrin
      191117 2014-09-19 19:27 cestina
      133875 2014-09-19 19:27 dilny
      117995 2014-09-19 19:27 eliska
      110196 2014-09-19 19:27 eliska_edit
      307597 2014-09-19 19:27 hoode
      358076 2014-09-19 19:27 jara_skrine
      128095 2014-09-19 19:27 jirka

Závěr

V následujícím měsíci plánujeme vyměnit hlavní shelve se seznamem zakázek za upravený PickleShareDB. To by mohlo zjednodušit údržbu, přenést větší zodpovědnost na souborový systém, umožnit přístup více instancím najednou a zanechat stejné výhody. Pickleshare má i jednu pěknou vlastnost a to je možnost používání cest, tedy klíče, které obsahují lomítko vytváří další složky a další třídění.

Pro ukládání jednotlivých zakázek - tedy nábytkových dílců, produktů a specifikací nábytkových položek zatím zanecháme samotný pickle, jelikož ten je pro každou zakázku již nyní jedinečný a dobře se předává jako uložený soubor na jiné místo, do jiné instance.

Na závěr bych se rád zeptal co používáte na ukládání dat? Běžné databáze i pro hodně rozdílná data? Jak se stavíte k SQL co se týče možností? Myslíte, že by třeba CAD aplikace mohla fungovat nad SQL a těžila by z toho?

       

Obrázky

Komentáře

[odin]

Na závěr bych se rád zeptal co používáte na ukládání dat? Běžné databáze i pro hodně rozdílná data?

Postgresql a pripadne jeho hstore.

[backinabag]

Jako hlavni duvody pro pouziti SQL databaze misto souboru vidim:

- rychle hledani, rychly pristup ke konkretnimu zaznamu (do tohohle bodu radim i JOINy, to je v podstate taky hledani)

- rychla editace, u souboru musim nacist cely soubor, zmenit jednu hodnotu a pak vsechno zase ulozit

- podpora transakci

Mene dulezite pak jsou integritni omezeni, podpora paralelniho pristupu, atd.

Cena za vsechno tohle je, ze to neni tak primocare a jednoduche na pouziti a udrzbu jako soubory.

[Normotron]

Muset načíst soubor celý nevadí, jelikož by to aplikace stejně za chvilku udělala. Jde o to, že aplikace např. spravovanou zakázku má načtenou celou, pro tvorbu výkresové dokumentace, pro zpracování kalkulace a další výpočty je to potřeba.

Naopak SQL v základní variantě nepodporuje seznamy a slovníky v Python, nebo např. pokud někdo chce array/numpy v Pythonu. Ano mohu vše skládat znovu, případně používat modul ast pro rozpoznávání. Když však použiji pickle/ZODB/Dobbin/Shelve tak tyto možnosti mám.

Jak jste říkal ohledně JSON, ano přes ten je možné to dělat. Pokud se však půjde dále tak tam např. neuložím instanci nějakého složitějšího objektu např. optimalizace/kalkulace > což je velké množství dat + numpy pole. Tušíte jak toto řešit? Případně je u SQL běžné mít hodně úrovňová data? např.

db['zakazka'].optim[0].summary['all']['material']

Kdy ze zadané zakázky > optimalizace 0, celého souhrnu vyberu materiál a informace o optimalizaci. Jak bych podobnou konstrukci napsal v SQL?

[vlastikroot]

SQL standardne slouzi k ukladani hodne urovnovych dat, jen ta struktura musi byt dopredu dana. Obcas se na to pouzivaji ORM, kde se struktura nadefinuje v nejakem treba XML a vygeneruje se z toho struktura databaze i objektu. Nektere umi pokrocilejsi veci jako migrace dat z jednoho schematu do jineho.

[Normotron]

Ano o ORM vím, ale stále to není ideální, viz potřeba pro běžné třídy definovat pro každý parametr novou definici, používat typy z SQL a následně těžké použití bez databáze. Často je totiž potřeba mít odlišnou definici třídy a pak problémový __init__.

Naopak možnost přístupu z jiných aplikací je dobrá, ale za cenu ztráty rychlého a efektivního přístupu to asi nestojí, zvláště když se data často mění a generují znovu si právě nejsem jistý jestli SQL nepřináší více překážek. Máte zkušenosti s použitím SQL u často se měnících dat? Aplikace je nyní parametrická a při změně jednoho parametru dochází často k velkým změnám, které ovlivní značné množství výstupů a ty se v současné době udržují v paměti a při nové regeneraci se všechny zapisují.

[Heron]

Máte zkušenosti s použitím SQL u často se měnících dat?

Ano, je to bez problémů. DB pro uložení transakce potřebuje jeden fsync, běžný desktopový disk zvládá cca 100 commitů za 1s. Předpokládám, že tak často uživatel ta data stejně měnit nebude.

[Asaf]

Kolko commitu zvlada moderne SSD ?

[backinabag]

Nevim, ale moje SSD mi porad zasekava system, kdyz builduju projekt nebo rozbaluju nejaky zip, tak klidne minutu skoro nemuzu hybat s mysi.

[Heron]

Nevím co chcete slyšet. Od 5 000 do 5 000 000. Podle toho, jaký model si koupíte a kolik peněz do toho dáte.

[backinabag]

To mi prijde dost malo... zajimalo by me, jak to je s paralelnimi commity, jestli to nektere databaze umi batchovat, takze v jednom fsyncu provede nekolik commitu.

[Heron]

7200rpm / 60 = 120rps. Obyčejný HDD umí tedy na jedno místo zapsat maximálně 120x za sekundu.

PostgreSQL umí počkat s commity, dá se to nastavit. Ovšem potom se (logicky) zvyšuje latence.

commit_delay
commit_siblings

Viz dokumentace.

[backinabag]

Dik za info, neznal jsem.

[xkucf03]

potřeba pro běžné třídy definovat pro každý parametr novou definici,

Ale zase když ty třídy a atributy máš, tak se s tím v programu lépe pracuje – nemusíš střílet od boku a hádat, jak se ten který parametr jmenuje nebo to hledat v dokumentaci, IDE ti může říct, jaké parametry ten objekt může mít.

používat typy z SQL

ORM běžně mapuje SQL typy na typy daného objektového jazyka. A pokud ti nestačí automatické mapování, dopíšeš si vlastní konverze. Obecně to mapování nemusí být 1:1 ani co se týče struktury (tabulka=třída).

a následně těžké použití bez databáze.

ORM (např. JPA) definuje rozhraní – za ním můžou být různé implementace a klidně můžeš mít implementaci, která data ukládá do CSV nebo YAML souborů na disk a s žádnou databází nepracuje.

[vlastikroot]

Struktura dat by mela byt nejak pevna. I hodne vnorena a nestejna data jdou casto po promysleni dat do par pevnych tabulek. Ja na hodne se menici veci pouzivam memory nebo temporary tabulky (podle potreby). Nactu si data z pevne struktury, prepocitam jak potrebuju (kombinace SQL a C++ kodu) v docasne tabulce a zas zpatky ulozim do pevne struktury.

SQL ma tu vyhodu, ze mam hromady ruznych zpusobu, jak poskladat porad ty stejny data. Obcas je proste potreba koukat na data z druhy strany, roztridit to podle jinych kriterii. A vykon i slozitych JOINu je vysoky, i pri velkem mnozstvi dat.

Nevim jak v te vasi aplikaci, ale casto se da vetsina vypoctetni logiky prevest do SQL. Treba groupovani a s tim spojene agregacni funkce jsou schopne neskutecne ulehcit praci. Da se treba vymyslet system, kdy parametricka data jsou opravdu parametricka - tzn. nikde nejsou predpocitana, pocitaji se opravdu az pri selectovani - napr. skladove hospodarstvi nebo ucetnictvi. Bezne se pouzivaji SQL selecty co takhle zpracovavaji miliony zaznamu a pritom trvaji par ms.

Takze si dokazu predstavit i treba CAD napsany nad SQL. Pokud by ten navrh byl inteligentni a nebylo to pouhe zneuziti databaze jako ulozny dat (jako to casto byva ve vetsine komercniho softu), tak by to mohlo prinest znacne vyhody.

[Normotron]

Tak my nyní už máme většinu struktury pevnou, avšak jak jsou zanořovaná do sebe, ne že by to nemohlo být bez toho, ale často k sobě patří nebo je to několik různých tříd v sobě, které pracují navzájem s vlastními daty.

Bohužel převody výpočtů do sql by asi nebyly moc možné, aplikace je náročná na výpočty, část jich je v numpy a jedná se obvykle o výpočty souřadnic, rozměrů a následně z těchto aktuálních hodnot např. otočení v prostoru, kalkulace, spotřeba materiálu a tak podobně.

Naopak uložení nějakých stejných dat do databáze by se mohlo projevit jako výhodné, takže proto by mě to zajímalo. Bohužel většina z nich jsou instance tříd, které by se vždy musely znovu inicializovat / nebo nějak uložit jako binární data do db..

[vlastikroot]

Ja taky vsechny narocnejsi vypocty delam v C++. Ukladam treba vykresy desek s plosnym spojem, vsechno pomoci zakladnich SQL typu. Takovy vykres obsahuje ruzna data, od vektoroveho obrysu desky az po soucastky s ruznyma parametrama. Pomoci SQL to probiram a generuju z toho ruzne rozpisky, postup vyroby rozdeleny pro ruzne lidi - atd. Samozrejme je i vizualizace dat (2D obrazek desky, ruzne obarveny), ta se ale nikde neuklada, vykresluje se pri behu aplikace. Kazda deska ma tisice ruznych objektu, kazdy s desitkami atributu.

Nejsem moc pro ukladani serializovanych instanci trid. Kazdy ma na to asi jiny nazor, ale interni struktura aplikace by nemela souviset s datovym schematem.

[Heron]

Naopak SQL v základní variantě

V základní variantě sice ne, ale když už používáš Python tak PostgreSQL má (dle mého názoru) skvělý konektor Psycopg2, který umí pracovat s Postgres poli. Takže to by bylo bez další konverze.

Dále, PostgreSQL má i JSON včetně fcí, takže i složitější objekty tam uložíš.

Jinak, uložit data do relační SQL nikdy nepůjde "jen tak", vždy je třeba se zamyslet nad strukturou. Osobně si ale už nedovedu představit ukládat data někam jinam než do psql. V produkci máme 2TB dat (bohužel jako BLOB, ale kluci už začínají makat na převodu do JSONb a doufám, že je i překecám o konverzi z BLOBů na BYTEA - BLOBY jsou dané historicky a je to koule na noze).

Teď na domácím pokusném serveru budu konvertovat nějakou starou strukturu na novou, s trochou snahy se snad podaří rozsekat binární data na jednotlivé skupiny a očekávám díky normalizaci snížení velikosti ze 120GB pod 30GB a s tím i značné zvýšení rychlosti (když už se to skoro vejde do RAM).

[xkucf03]

že je i překecám o konverzi z BLOBů na BYTEA - BLOBY jsou dané historicky a je to koule na noze).

Jakou má PostgreSQL režii při posílání proudu bajtů ke klientovi? Když to srovnáš třeba s Nginxem (nebo nějakým jednoduchým serverem pro jiný protokol), který by servíroval ta data ze souborů?

Osobně jsem to řešil tak, že jsem binární data nechal v souborech a aplikační server pak jen Nginxu řekne, který soubor má poslat – takže ten tok dat je:

disk → Nginx → klient

místo:

disk → PostgreSQL → aplikační server → Nginx → klient

Pokud by těch dat bylo málo nebo se málo používala (třeba intranet), tak bych to asi nechal v DB. Přeci jen člověk tu nemá transakce mezi DB a soubory nebo SQL přístupová práva a musí si tyhle věci řešit v aplikaci.

[Heron]

Osobně jsem to řešil tak, že jsem binární data nechal v souborech a aplikační server pak jen Nginxu řekne

To je úplně na nic, protože nic nevynucuje referenční integritu a dle Murphyho zákonů se to rozejde v nejhorší možnou chvíli způsobem, který napáchá nejvíce škod. Mimochodem právě pro lepší vynucení referenční integrity chci z blobů udělat bytea -- blob je v pg identifikován pouze svým oid (takže odkazem), zatímco bytea je přímo hodnota.

Nehledě na to, že pokud jsou veškerá data v DB, tak záloha je vždy konzistentní, zatímco pokud jsou data v souborech na disku a cesty (metadata) k nim jsou v DB, tak bez odstávky appky (nebo alespoň přepnutí do ro) není ani možné udělat zálohu (obsah disku konsistentní s db).

Takže se sice ztrácí nějaký výkon (nikdy jsem to neměřil, nikdy to nebyl problém), ale to je zase vráceno v referenční integritě a transakčním zpracování.

Více jsem se o tom rozepsal zde a zde.

[xkucf03]

Ty moje soubory jen přibývají, nemění se – takže dost problémů odpadá – navíc je to typ dat, kde by se ta nekonzistence ještě dala přežít: chybějící soubor se dá snadno najít a přebývající by ani moc nevadil (akorát zabírá místo na disku, ale nevadí tam) a najít by šel taky (třeba po nějaké havárii a obnově ze zálohy).

Souhlasím, že to není dokonalé a nekonzistence může nastat, ale pro tuhle úlohu mi přišla rizika a nevýhody přijatelné – lepší než tahat data delší cestou při opakovaném čtení.

Ideální by asi bylo, kdyby PostgreSQL uměla zpřístupnit ty bloby i v podobě souborů – tzn. vkládání by probíhalo přes DB, ale číst by je šlo i přímo z disku – databáze by se postarala o konzistenci a nastavení ACL nějakému uživateli (třeba tomu webovému serveru), který by pak mohl číst rovnou soubory. V SQL bys pak měl funkci, kterou by sis zjistil název toho souboru a mohl ho předat Nginxu.

[Heron]

navíc je to typ dat, kde by se ta nekonzistence ještě dala přežít

Pro mě je konzistence základ. V praxi jsem narazil na:

• Soubor na disku je, v db není. Nejmenší problém. Jen zabírá místo, netřeba moc řešit.
• Chybějící soubory na disku, přičemž v db záznamy jsou. Aplikace "sletí" na neexistujícím souboru. Navíc uživatel je přesvědčen, že data v aplikaci jsou a může je smazat u sebe. Potom už nejsou nikde. Když se napíše fsck, tak tohle lze detekovat. Ale která aplikace to skutečně řeší?
• V DB byla tabulka ID (autoincrement) a soubory na disku pojmenovány dle ID. Jenže appka asi nebyla "thread safe", takže při současném uploadu dvou souborů od dvou uživatelů byl soubor od jednoho uživatele pojmenován ID patřící k druhému uživateli. (Špatné ošetření sekvenčních čísel.)
• Soubory na disku byly posunuty proti db, tedy souboru id+-1 odpovídalo záznamu id v DB. Jak tohle vzniká netuším. Tohle už je prakticky nedetekovatelné (kdo si do db ukládá hash obsahu souboru a kontroluje ho?).

Ve spojení se zálohováním a obnovou potom už může nastat cokoliv. Pokud není DB a soubory na jednom FS nebo se nedělá snapshot, není to nikdy konzistentní. Málokterá webová aplikace řeší sync souborů na disk (hodně bych se divil, kdyby to řešila alespoň jedna jediná PHP aplikace), zatímco commit se volá přece jen častěji.

Ideální by asi bylo, kdyby PostgreSQL uměla zpřístupnit ty bloby i v podobě souborů – tzn. vkládání by probíhalo přes DB, ale číst by je šlo i přímo z disku – databáze by se postarala o konzistenci a nastavení ACL nějakému uživateli (třeba tomu webovému serveru), který by pak mohl číst rovnou soubory.

Při současné implementaci pomocí TOASTů si tohle nedovedu představit. Určitě bylo napsat FUSE FS, který by běžel nad danou DB a zpřístupňoval by ona data. (FUSE nad SQL)

[Alhambra]

myslim, ze v Anglii nebo ve Francii navrhuji, ze povinnost pouzit pri zpracovani dat relacni databazi, transakce a referencni integritu, bude predepsana ustavou.

[deda.jabko]

Ideální by asi bylo, kdyby PostgreSQL uměla zpřístupnit ty bloby i v podobě souborů – tzn. vkládání by probíhalo přes DB, ale číst by je šlo i přímo z disku – databáze by se postarala o konzistenci a nastavení ACL nějakému uživateli (třeba tomu webovému serveru), který by pak mohl číst rovnou soubory.

Při současné implementaci pomocí TOASTů si tohle nedovedu představit. Určitě bylo napsat FUSE FS, který by běžel nad danou DB a zpřístupňoval by ona data. (FUSE nad SQL)

Ten napad celkove nedava smysl. Aby to mohlo poradne fungovat, musi byt pristup k DB i FS ve stejne transakci, jinak se tam budou porad zjevovat nekonzistence a jsme porad tam, kde jsme byli.

[Heron]

Tak mohlo by to fungovat podobně jako materializované pohledy. Ty také nejsou vždy aktuální, aktualizují se na vyžádání či při určité události.

[xkucf03]

Smysl to dává ve chvíli, kdy jsi ochotný slevit z konzistence v určitém dílčím¹ ohledu ve prospěch výkonu².

Může se stát, že přístup přes FS by měl malé zpoždění oproti přístupu přes DB, že by tam chvilku ta data chyběla. U veřejných dat na webu to často nemusí vadit³. Ale i to by šlo řešit – za cenu pomalejšího potvrzení transakce v DB – ta se potvrdí, až když je soubor celý přístupný pod správným názvem a má správně nastavené ACL.

A samozřejmě se to hodí jen pro data, která se přes ten FS budou pouze číst a taky se nebudou (příliš) měnit.

Příklad: Dejme tomu, že máš aplikaci na správu ISO obrazů nebo nějakých větších příloh. Chceš je zpřístupnit po HTTP, FTP, CIFSu, NFS, SFTP atd. A chceš k nim evidovat metadata v databázi, mít nějaký pěkný katalog. PostgreSQL bys pak mohl použít k zajištění konzistence⁴ a obecně většího pořádku v datech.

_{[1] tzn. nechceš se vzdát vymožeností relační databáze jako takových
[2] snížit počet procesů a bufferů přes které se ta data předávají
[3] ale má to svoje meze – u různých facebooků, twitterů a podobných se často dělají taková zvěrstva, že ta nekonzistence fakt škodí a uživatel na ni naráží – to už se mi nelíbí
[4] vyšší než by ti poskytl samotný FS nebo třeba rozšířené atributy souborů – ty jsou sice fajn, ale zase nejsou indexované a nedá se v nich dobře hledat}

[deda.jabko]

Smysl to dává ve chvíli

• kdy jsi ochotný slevit z konzistence
• přístup přes FS by měl malé zpoždění oproti přístupu přes DB
• se to hodí jen pro data, která se přes ten FS budou pouze číst a taky se nebudou (příliš) měnit.

Ty podminky jsou tak specificke, ze oproti kombinaci oddelene DB+FS neprinasi prilis uzitku, ale jen nove problemy, at uz jsou to nekonzistence z toho, ze pristup k FS budu muset bezet vzdy ve vlastni transakci nebo mapovani opravneni DB na opravneni FS.

[xkucf03]

Takže ty ISO obrazy bys dal na FS a konzistenci by ti DBMS nezajistil vůbec žádnou? Nebo bys je nacpal do databáze?

[deda.jabko]

Takze ty bys radsi do databaze nacpal API, ktery nikdy nemuze fungovat spravne, jenom abys ulehcil jednomu specifickemu pripadu uziti?

Takže ty ISO obrazy bys dal na FS a konzistenci by ti DBMS nezajistil vůbec žádnou? Nebo bys je nacpal do databáze?

Absolutne nema smysl diskutovat o fiktivni sluzbe provozovane s fiktivnim softwarem.

[xkucf03]

A co třeba web, kde máš u každého článku několik obrázků nebo příloh? Opravdu je potřeba a) vzdát se konzistence zajištěné RDBMS a řešit si ji v aplikaci nebo b) vložit mezi disk a HTTP server další dva procesy/buffery?

Další možností je reverzní proxy s mezipamětí – ovšem tím neodstraníš ty nadbytečné procesy/buffery – naopak přidáš další a pokusíš se problém obejít. Kdyby to byly soubory na disku, tak je můžeš nasdílet po síti a ty reverzní proxy tam přidat taky. Navíc mezipaměť vyžaduje další místo na disku.

[deda.jabko]

Budiz, upravim svou otazku:

Takze ty bys radsi do databaze nacpal API, ktere nikdy nemuze fungovat spravne?

Další možností je reverzní proxy s mezipamětí

Priznam se, ze v tento moment prestavam chapat tve myslenkove pochody.

Kdyby to byly soubory na disku, tak je můžeš nasdílet po síti

Kdyby to byly soubory na disku, tak jsi opet tam, kde jsi byl, protoze ti tam prozmenu budou prebyvat buffery pro sdileni souboru + rezie, kterou ma databaze a jeji export pro FS. Apropos, tve reseni bude blbe skalovat, protoze aplikacni server, ktery se bude starat o distribuci dat z FS musi byt na stejnem stroji jako databaze.

[xkucf03]

Takze ty bys radsi do databaze nacpal API, ktere nikdy nemuze fungovat spravne?

Co znamená správně? Bude fungovat předvídatelně, podle dokumentace – což je u softwaru definice správně a kvalitně. V té dokumentaci bude popsané, jak se to chová a za jakých okolností to může být nekonzistentní.

BTW: hodně věcí je nekonzistentních – např. na webu nebo i u jiných aplikací používá málokdo transakce napříč všemi vrstvami – jakmile data putují mezi aplikačním serverem a HTTP serverem ke klientovi, už jsou obvykle mimo transakci – můžeš třeba začít psát komentář pod článek, který mezitím někdo smazal, a máš prostě smůlu. Transakce se používají většinou jen mezi DB a aplikací. Ne na dalších vrstvách – tam se v lepším případě použije optimistické zamykání, v horším ani to ne. Dvoufázový commit je celkem výjimka. Nicméně obvykle argumentuji ve prospěch transakcí – tahle diskuse je spíš výjimka

Priznam se, ze v tento moment prestavam chapat tve myslenkove pochody.

Někdo může namítnout, že když data tečou přes DB a aplikaci pomalu, vrazíme tam reverzní proxy a tím to zrychlíme. Ke zrychlení resp. zvýšení kapacity dojde, ale za cenu vyšší složitosti, vyšších nároků na disk (data jsou uložena vícekrát), vyšší latence (oproti variantě FS → HTTP) a dokonce větší nekonzistence (data v mezipaměti můžou být zastaralá).

Neříkám, že proxy a mezipaměť jsou špatné, ale můžu je postavit i za za ten server, kde je přímo FS → HTTP nebo FS → NFS (nebo jiný protokol) a kde nemusí data proudit navíc přes DBMS a aplikaci.

Kdyby to byly soubory na disku, tak jsi opet tam, kde jsi byl, protoze ti tam prozmenu budou prebyvat buffery pro sdileni souboru

Ne, rozdíl je v tomhle:

FS → DB → aplikace → X

vs.

FS → X

Za X si dosaď cokoli – HTTP server, SFTP, NFS, CIFS, FTP… – co je schopné servírovat soubory z disku.

Odpadnou ti dvě vrstvy (DB + aplikace), přes které by data nemusí projít. Navíc tohle sdílení může mít podporu v jádře nebo být implementované nějak jednodušeji a efektivněji.

+ rezie, kterou ma databaze a jeji export pro FS.

DB s tím žádnou režii nemá, uloží data do souborů na disk (což by dělala tak jako tak) a nechá je tam ležet. Jen bude někde popsané/nastavené, v jakém adresáři se tyto soubory ukládají, jak se jmenují a jaká mají práva (pro čtení). V DB budeš mít funkci, která ti řekne, kde se tenhle blob nachází na FS.

Soubory nebudou moci být komprimované nebo deduplikované pomocí DB, ale tohle je stejně spíš úloha pro souborový systém.

Nicméně pro čtení režie odpadá (a celou dobu tu mluvím o případu, kdy optimalizujeme pro více čtení a méně zápisů).

Apropos, tve reseni bude blbe skalovat, protoze aplikacni server, ktery se bude starat o distribuci dat z FS musi byt na stejnem stroji jako databaze.

Nemůže škálovat hůř, protože možnost tahat data přes DB (místo přímo z FS) by byla zachovaná – kdo si bude chtít SELECTovat blob, ten samozřejmě může.

Aplikační server distribuci dat pouze řídí – ale samotná data přes něj nemusí téct. AS se DB pouze zeptá, jak se soubor jmenuje, ověří práva případně další věci a pak pošle HTTP hlavičku Nginxu/Apachovi, který na základě ní odbaví data přímo z disku (což může trvat dlouho, ale aplikace a databáze v tu chvíli už můžou zavřít spojení, uvolnit si paměť, přestat se tímhle požadavkem zabývat a řešit jiné). Ten HTTP server může běžet i na jiném serveru (na který ta data nasdílíš po síti třeba přes NFS).

Tvůj návrh:

FS → DB → AS → HTTP

Moje návrhy:

FS → HTTP

FS → NFS (SFTP, FTP, CIFS atd.)

FS → HTTP → reverzní proxy

FS → NFS → HTTP

FS → NFS → HTTP → reverzní proxy

Reverzní proxy může být na jiném stroji, stejně tak ten HTTP (nebo jiný) server, když to proložíš NFS nebo jiným sdílením souborů. Ve všech případech ušetříš jednu až dvě vrstvy.

Je mi prostě proti srsti tlačit gigabajty dat přes databázi/aplikaci, když to nemá opodstatnění. A připadá mi to jako chtít mít jeden nástroj jak pro spravování hodinek, tak pro přehazování hromady koksu. Databázi a aplikaci beru jako místo pro precizní práci, je lepší, když budou co nejlehčí, nebudou v paměti držet zbytečně moc dat, budou řešit pokud možno požadavky, které lze rychle odbavit. A tam, kde je potřeba hrubá síla – třeba odeslat někomu na Internetu gigabajty dat – se použije jiný nástroj, pořádná lopata místo pinzety.

[deda.jabko]

Co znamená správně? Bude fungovat předvídatelně, podle dokumentace – což je u softwaru definice správně a kvalitně.

WAT? Dobre, jinymi slovy, ten obskurni programavaci jazyk z prikladu je kvalitni, protoze ty uchylnosti jsou zdokumentovane...

Odpadnou ti dvě vrstvy (DB + aplikace), přes které by data nemusí projít. Navíc tohle sdílení může mít podporu v jádře nebo být implementované nějak jednodušeji a efektivněji.

Ty vrstvy ti tam nemuzou odpadnout...

Musis tam mit FS -> DB -> (export jako FS) -> X.

Nemuzes nechat nekoho jen tak hrabat do dat databaze, byt by to bylo jen pro cteni! S takovou nebudes mit zarucene zhola nic, ani atomicke operace nad objekty!

DB s tím žádnou režii nemá, uloží data do souborů na disk (což by dělala tak jako tak) a nechá je tam ležet. Jen bude někde popsané/nastavené, v jakém adresáři se tyto soubory ukládají, jak se jmenují a jaká mají práva (pro čtení). V DB budeš mít funkci, která ti řekne, kde se tenhle blob nachází na FS.

Viz vyse, musis tam mit vrstvu, ktera data exportuje jako FS a odstinuje te od implementacnich detailu, jako je zamykani, atp.

Ten HTTP server může běžet i na jiném serveru (na který ta data nasdílíš po síti třeba přes NFS).

Tim tam dostanes dalsi vrstvu, ktere ses vlastne chtel zbavit. Rozdil je jenom v tom, ze misto aplikace ty data ven bude tlacit NFS, nebo kdo vi co.

A připadá mi to jako chtít mít jeden nástroj jak pro spravování hodinek, tak pro přehazování hromady koksu.

V tom pripade te nechapu. Jsi to prave ty, kdo tu chce mit databazi, ktera je schopna prehazovat gigabyty dat. Bud budes mit precizni praci se vsemi daty vsech velikosti, i za cenu, ze ti bude proti srsti ty data pres neco prohanat, nebo si das data bokem a budes tezet z primeho pristup k FS. Ten hybrid, ktery tu prosazujes, vlastne prilis nic neresi.

[xkucf03]

S takovou nebudes mit zarucene zhola nic, ani atomicke operace nad objekty!

Ty se pořád držíš představy, že všechno musí být dokonale ACID. Ano, transakce jsou super, ale jsou i případy, kdy se bez nich obejdeš a kdy můžeš být k nějaké nekonzistenci tolerantní.

Např. web je toho plný – lidi si stáhnou tvoji stránku, mají ji otevřenou v prohlížeči a za chvíli kliknou na nějaký odkaz – ale ty jsi mezi tím tu odkazovanou stránku přesunul nebo smazal – odkaz nefunguje, je to nekonzistentní! Stejně tak, když si někdo rozepíše komentář a ty mu smažeš ten článek, nebo třeba jiný komentář, na který on reaguje – rovněž je ten systém nekonzistentní.

Aby konzistentní byl, tak bys musel dotáhnout ty transakce až k poslednímu klientovi – když si někdo otevře tvůj web, tak by začala transakce, všechno by se zamklo a pokud bys chtěl něco měnit, tak bys musel počkat, až všichni uživatelé zase všechno zavřou.

Ale raději už dost, jak jsem psal, obvykle transakce hájím a hádám se s lidmi, kteří je považují za zbytečné a místo relačních databází chtějí používat nějaké bastly.

Musis tam mit FS -> DB -> (export jako FS) -> X.

Nemusíš – pro čtení tam ty soubory můžou být. DB by se postarala o správné přejmenování souboru tak, aby se na svém místě objevil, až když je nahraný celý. Aktualizace by buď nebyly, nebo by se soubor opět přejmenoval a chvíli chyběl, případně by se mohl zduplikovat (COW) a pak by po dobu nahrávání byla dostupná stará verze a pak by se prohodily. Pokud by nějaký proces měl ten soubor otevřený, tak by dokončil operaci se starým obsahem – např. by se dokončilo stahování původního ISO obrazu, což je v zásadě žádoucí chování.

Jak jsem psal, nekonzistence tu můžou být, ale můžou být v mezích, které jsi ochotný tolerovat.

Rozdil je jenom v tom, ze misto aplikace ty data ven bude tlacit NFS, nebo kdo vi co.

Jednak to NFS je přímo v jádře operačního systému a jednak to není místo aplikace, ale místo aplikace a databáze, viz výše.

si to prave ty, kdo tu chce mit databazi, ktera je schopna prehazovat gigabyty dat. Bud budes mit precizni praci se vsemi daty vsech velikosti, i za cenu, ze ti bude proti srsti ty data pres neco prohanat, nebo si das data bokem a budes tezet z primeho pristup k FS. Ten hybrid, ktery tu prosazujes, vlastne prilis nic neresi.

Je otázka, jestli tohle má řešit nějaký framework nebo DBMS. Řešit to v aplikaci je nedokonalé řešení, protože to není znovupoužitelné a můžeš tam snadno při implementaci udělat chyby. Je to úloha, kterou by bylo dobré vyřešit jednou na jednom místě, znovupoužitelně. Požadavky jsou jednoduché:

• chci vyšší¹ konzistentnost, než když budu mít část dat v databázi a část v souborech a budu si to hlídat ručně v aplikaci
• chci mít možnost servírovat data přímo z FS, aniž by musely procházet přes DBMS a aplikaci

Dovedu si představit, že by tenhle framework šel implementovat formou databázových procedur + případně nějakého malého démona, který by nastavoval přístupová práva k souborům nebo dělal asynchronní kontroly.

_{[1] vyšší, ne absolutní a dokonalou}

[Heron]

Je mi prostě proti srsti tlačit gigabajty dat přes databázi/aplikaci, když to nemá opodstatnění. A připadá mi to jako chtít mít jeden nástroj jak pro spravování hodinek, tak pro přehazování hromady koksu. Databázi a aplikaci beru jako místo pro precizní práci, je lepší, když budou co nejlehčí, nebudou v paměti držet zbytečně moc dat, budou řešit pokud možno požadavky, které lze rychle odbavit. A tam, kde je potřeba hrubá síla – třeba odeslat někomu na Internetu gigabajty dat – se použije jiný nástroj, pořádná lopata místo pinzety.

Aha, já jsem si říkal proč to všechno. Tohle mi to vysvětlilo.

Pro mě DB funguje lépe než FS.

Díky tomu, že lze efektivně ukládat a pracovat s metadaty, tak požadavky na přenos (velkých binárních) dat jsou mnohem menší než na fs.

Když jsou (ty požadavky) mnohem menší, mnohem lépe fungují cache.

Teď tu mám jednu tabulku o velikosti 107GB. Ve skutečnosti má ta tabulka 12MB, ten zbytek je transparentně v toastu. 12MB se vejde do paměti a ve skutečnosti se tam naleje hned po startu appky (protože tam mám omylem schválně jeden full table scan dotaz - 40ms -- srovnej s údajem za chvíli). Těch 12MB metadat slouží k tomu, aby se k těm 107GB přistupovalo efektivně. Když jsem to odlil na FS (přes 130tis záznamů), nedalo se s tím adresářem vůbec rozumně pracovat. Příkaz ls je lineární a pokud se chce víc než jen jméno souboru, tak pro každý záznam se musí udělat výlet do inode, tedy 130tis seeků, což je skoro 20minut - jen na jeden příkaz ls -la! Pokud už ta adresářová struktura není v paměti, což ale fs zdá se nijak dlouho nedrží. Srovnej 18 minut a 40ms. Na de facto totéž (z pohledu uživatele na zcela totéž.)

Dále netřeba nijak řešit počet záznamů. Zatímco FS se zakucká při stovkách tisíc souborů, s db lze nerušeně pracovat při stovkách miliónů na stejném HW. Zatímco u FS se vymýšlí všechno možné (rozdělení většího počtu souborů do adresářového stromu apod.), což jen zatěžuje prog. od vlastní logiky appky, tak při práci s DB jsem to nikdy nemusel řešit. Prostě se to všechno nahází do jedné tabulky a poraď si. 500M záznamů žádný stres. (No, ve skutečnosti moje nejpočetnější db měla 300mil záznamů, ale věřím, že ta půlmiliarda by nebyla problém.) Pochopitelně, pokud by na té jedné tabulce mělo být 30 indexů a měnila by se 20x za minutu, tak by s tím byl problém. Při návrhu je třeba přemýšlet.

Jo, takže z mé zkušenosti se není třeba vůbec bát nasazení SQL DB i jako skladiště pro velká binární data. Samozřejmě, pokud bych měl dělat sklad ISO souborů nějaké distribuce, nebo něco takového, asi bych to do DB nedal. Ale pokud je s těmi daty i hromada metadat a je třeba to držet konzistentně při sobě, tak není žádný důvod, proč to nemít v jedné DB. Když se to udělá chytře, tak lze spoustu věcí ušetřit. Navíc tím, jak se do Postgresu dostávají další datové typy (nehovořím o tom, že si je člověk může implementovat sám, ale ne každý se do toho chce pustit), tak lze ta binární data "odbinarizovat" a uložit je normalizovaně a mnohem efektivněji (co do místa na disku a tím i zvýšit efektivitu cache).

Pokud by jeden server nestačil, můžu dělat ro repliky. Opět, data a metadata jsou spolu, nikde se nic nerozklíží (což se u replikací metadat a nezávislé synchronizace dat mezi servery říci nedá).

[xkucf03]

Předně musím říct, že mě těší tvoje důvěra v PostgreSQL a tvoje dobré zkušenosti s ní. Je to moje oblíbená databáze

Nicméně stále tam vidím ty dva procesy (v operačním systému) navíc, které musí v nějakém cyklu číst vstupní proud a předávat to na výstupní proud tomu druhému procesu.

Když jsem to odlil na FS (přes 130tis záznamů), nedalo se s tím adresářem vůbec rozumně pracovat. Příkaz ls je lineární a pokud se chce víc než jen jméno souboru, tak pro každý záznam se musí udělat výlet do inode, tedy 130tis seeků, což je skoro 20minut - jen na jeden příkaz ls -la!

To je otázka implementace konkrétního FS a konkrétního SŘBD – oboje má svoje indexy a FS je v zásadě taky databáze – navíc je realizovaná jako modul do jádra a může pracovat se surovým blokovým zařízením.

Malý test na zhruba třetinovém počtu souborů:

$ time find | wc -l
44078

real    0m2.558s
user    0m0.096s
sys     0m0.548s

$ time find | wc -l
44078

real    0m0.081s
user    0m0.027s
sys     0m0.061s

$ time ls -ltR | wc -l
52042

real    0m0.344s
user    0m0.116s
sys     0m0.251s

Je to XFS na běžném HDD. Čerstvě po připojení ten ls -ltR trval tři vteřiny. Případně, když těch souborů bude víc:

$ time ls -ltR | wc -l
156114

real    0m1.014s
user    0m0.423s
sys     0m0.659s

Kdyby to trvalo 20 minut, tak tam musí být něco špatně, případně to muselo být už hodně dávno.

A teď ještě koukám, že jsem tam při připojování zapomněl dát noatime, takže se dokonce u všech těch souborů i zapisovalo do metadat.

Zatímco u FS se vymýšlí všechno možné (rozdělení většího počtu souborů do adresářového stromu apod.), což jen zatěžuje prog. od vlastní logiky appky, tak při práci s DB jsem to nikdy nemusel řešit.

U databází se tohle taky dělá – říká se tomu partitioning – v PostgreSQL se k tomu používá dědičnost. Nicméně souhlas v tom, že u DB bude ten limit, kdy je to potřeba, asi vyšší, databáze bude obvykle stavěná na větší počty záznamů v tabulce než FS na počty souborů ve složce.

Jo, takže z mé zkušenosti se není třeba vůbec bát nasazení SQL DB i jako skladiště pro velká binární data.

Já nerozporuji, že se ta data do DB vejdou, ani že je DB dokáže efektivně spravovat – jde mi o to, kudy ta data tečou během provozu, při čtení.

[Heron]

Předně musím říct, že mě těší tvoje důvěra v PostgreSQL a tvoje dobré zkušenosti s ní. Je to moje oblíbená databáze

Postgresem na serveru se zabývám už dlouho, je fakt, že tady na ABC vyšel pouze jeden článek (o zálohování), takže to asi nemusí být známo. Jo, Postgres mám rád a ještě mě nezklamal.

Kdyby to trvalo 20 minut, tak tam musí být něco špatně, případně to muselo být už hodně dávno.

Tak neexistuje pouze XFS. (Teď jsem na XFS zkoušel a je to 11s pro 32tis souborů v různých adresářích - běžný 7200rpm 3TB disk.)

U databází se tohle taky dělá – říká se tomu partitioning – v PostgreSQL se k tomu používá dědičnost.

Jo jo. Proto jsem také psal, že kdyby tam mělo být 30 indexů apod, tak by to tak svižné nebylo (pro zápis).

jde mi o to, kudy ta data tečou během provozu, při čtení.

Chápu. Mě se ten nápad s tím, že by DB zpřístupňovala bloby na disku, líbí, akorát si (při současném stavu věcí) nedovedu představit jeho realizaci.

[backinabag]

Jak jsem pochopil ten vas problem, taky moc nevidim duvod pro SQL, serializace do souboru mi prijde na prvni pohled ok.

U viceurovnovych dat je potraba vic tabulek, takze u toho prikladu by asi byly potreba tabulky: zakazky, optimalizace, souhrny, materialy. A v SQL pak pouzit nekolik dotazu (nebo mozna by sel jeden slozitejsi dotaz s JOINy).

Jak jste říkal ohledně JSON, ano přes ten je možné to dělat. Pokud se však půjde dále tak tam např. neuložím instanci nějakého složitějšího objektu např. optimalizace/kalkulace > což je velké množství dat + numpy pole. Tušíte jak toto řešit? Případně je u SQL běžné mít hodně úrovňová data? např.

Pokud je to tolik dat, ze se to nevejde do BLOBu (ted nevim jake jsou typicke limity), tak by slo v tom sloupci mit odkaz na soubor na disku a v databazi by byly jenom data, podle kterych je potreba hledat.

[backinabag]

Pak je jeste jedno reseni, ktery se mi dost libi. Kombinuje to vyhody relacni i "hloupe" databaze.

Mit normalne napr. SQLite db, ale mit defaultne jenom jeden sloupec a v nem JSON, napr. nejaky 3D model. A podle potreby si tam pridat dalsi (indexovane) sloupce na hledani / JOINy. A nad tim nejakou vrstvu, ktera pri vlozi JSONu automaticky vyextrahuje a ulozi i do tech indexovanych sloupcu.

Dela to myslim Foursquare, psali o tom do jejich blogu.

[backinabag]

Dela to myslim Foursquare, psali o tom do jejich blogu.

Teda FriendFeed, link.

[Bystroushaak]

Ne že by to bylo úplně k věci, ale na něco podobného bych použil asi http://ponyorm.com/

[Radek Miček]

Umí to modelovat podtypy/kategorie – nic o tom nevidím v dokumentaci? Např., jak tam vymodeluji entitu domácí mazlíček a její dvě kategorie pes, kočka?

[Bystroushaak]

Dědictvím?

[backinabag]

Ano, správně.

[Radek Miček]

Díky, našel jsem to.

Nepříjemný je ovšem způsob, jak je dědičnost (lépe řečeno podtypy nebo kategorie) realizována v databázi. Kvůli němu nebudou tabulky ani v 1. NF. Kromě toho bude problematické přidávání dalších kategorií (bude třeba měnit existující tabulku) a při vyšším počtu kategorií vznikne tabulka o velkém počtu sloupců, což může mít negativní dopad na výkon.

[Bystroushaak]

No, výkonnost imho není není úplně priorita toho ORM, to je fakt.

[Normotron]

To asi nebude problém, předpokládám, že když se udělá nová třída z původní, tak půjde přidat nové atributy.

[Normotron]

To jsem neznal, zkoušel jsem SQLAlchemy a Storm. Zdá se že to umí používat generátory, což je dobře. Stále to však potřebuje odvozovat jednoduché třídy od nějaké jiné třídy a hlavně tam opět asi bude problém s použitím __init__ a introspection. Naše běžné třídy mají samotný init a vytvoření dost obsáhlé + se používá dost seznamů/slovníků pro jednotlivé parametry, takže si nedovedu moc dobře představit. Zvláště když jedna základní instance produktu sám má zhruba 50-200 volitelných parametrů a k tomu několik zásobníků informací, které se dále větví. Proto právě nevím, jak takovéto informace uložit > jedná se o jeden produkt - např. jedna jednoduchá skříňka. Jakmile jde o složitější objekt a hlavně již třídu, která je postavená na tomto základu, množství informací začíná narůstat a je potřeba s nimi pracovat jako s celkem. No a když se to přežene tak pak jedno přegenerování, díky změně rozměru změní celý strom a vznikne odlišná třída a odlišné parametry.

Většina použití ORM co jsem našel pouze a hlavně přepisovala zadané údaje, ale často nešlo o generování nových ze zadaných.

[Dalibor Smolík]

Mám firemní data uložená v MySQL od roku 1997. Při vhodné archivaci mohou vydržet

[Tonda]

pro Vašich 15 zákazníků by snad stačil excel, ne?

[Dalibor Smolík]

Nestačil, v systému se eviduje spousta věcí, spotřeba materiálu, vystavují se dodací listy a faktury, jsou třeba sestavení expedic v určitém období pro konkrétní zákazníky apod. Potřebná sestava to vyjede za pár vteřin

[kotyz]

Příloha:

• pripravto.png (67968 bytů)

Přišel mi od nich email kterej nechápu. Prej sem jim něco někde psal, ale jednak vůbec nevim že něký priprav.to vůbec existuje a taky sem nikde nic nepsal. Tak nevim kdo si ze mě dělá prdel a proč...

[Normotron]

Za toto se omlouváme, přišla nám zpětná vazba s odkazem na vás. Bohužel na Google Forms, nelze zjistit IP/podrobnější informace odesilateli, takže asi již nezjistíme co se stalo. Pokusíme se na podobné situace lépe připravit.