Hlavní navigace

Vlákno názorů k článku Jak na účetnictví na Linuxu (2) od Koli - Chcem sa trosku pridat do diskusie. Mnoho ludi...

  • Článek je starý, nové názory již nelze přidávat.
  • 22. 10. 2002 14:41

    Koli (neregistrovaný)

    Chcem sa trosku pridat do diskusie. Mnoho ludi zavrhuje MySQL kvoli tomu ze nema transakcie. Lenze tie nedokazu riesit vsetko.

    V nasom projekte TUCNIAK sa chystame implementovat nieco, co by dokazalo zamykat jednotlive riadky tabuliek. Zatial neviem o ziadnom DB serveri ktory by to mal v sebe implementovane a tak ci tak by bolo potom potrebne previest tuto operaciu na stranu aplikacie. Ak to vyriesime, tak nam transakcie nebudu potrebne a kludne mozeme behat "kompaktne" aj nad MySQL.

    Teraz naco je to dobre. Predstavte si priklad kedy mam obchodnu firmu a 5 obchodnikov, ktori aktivne pracuju so skladom firmy. Povedzme ze kazdy z nich obsluhuje v realnom case nejakeho zakaznika co znamena ze asi pol hodinu s nim diskutuje co chce nakupit a co nie a postupne tieto polozky pridava na vydajku resp. fakturu. Ak by som JEDNOU transakciou "zamkol" tabulku skladu, z ktorej zaroven vyskladnuju ostatni 4 obchodnici, mohlo by sa stat ze po pol hodine roboty, by mi aplikacia vratila hlasku ze transakcia vyskladnenia neprebehla uspesne pretoze jednoducho na sklade uz dane polozky nie su. Obchodnika by asi trafil slak, ak by ho medzi casom nezaskrtil zakaznik. Zaroven keby obchodnik nemohol pracovat so skladom len kvoli tomu ze v tom case s nim pracuje niekto iny tak by tych obchodnikov nemuselo byt 5 ale stacil by jeden.

    Co sme navrhli my, je ze existuje nejaka tabulka, ktora si pamata nazov tabulky, ID riadku a usera ktory riadok zamkol. Takto dosiahneme to ze tabulka skladu bude pristupna cela a zamknuta bude vzdy len nejaka polozka s ktorou prave nejaky obchodnik pracuje. Samozrejme ostatni obchodnici tu polozku tiez vidia, ale keby s nou chceli pracovat tak sa im ukaze hlaska typu "momentalne s polozkou XY pracuje USER_YX, jej posledny aktualnuy stav bol Z-kusov". Takze uzivatel bude aspon tusit kolko toho je na sklade a ci je realne ze to USER_YX vsetko vyskladni. Povedzme pocka 3 min alebo posle USER_YX spravu "kedy uz skoncis zadavanie polozky XY:-)"
    Atd.

    Ak by niekto vedel nieco taketo urobit na strane servera tak uznam ze db-servery a jazyk SQL s transakciami su dobra vec. Ale zatial si take nieco fakt neviem predstavit na strane db-servera. Uznavam ze niekto by sa kludne mohol napojit na db aj inym klientom a robit sarapatu. Ale to by mohol aj tam kde su transakcie, takze kompaktnost db je podla mna vzdy tak trochu zavisla aj na samotnej Api

    A este maly odkaz pre tych, ktorym sa nepaci management projektu TUCNIAK. Projekt som prezentoval prvy krat zaciatkom roka ako sucast mojej diplomovky a cely som ho postavil na GPL. Je lahke viest projekt ked ma na to clovek financie a cas. Omnoho tazsie je zhanat ludi ktori nieco vyvijaju na zaciatku zadarmo pod GPL. Takze uznavam ze preluskat sa jeho kodom a zacat implementovat vlastne moduly je momentalne fakt fuska. Ale na druhu stranu sa mozeme pochvalit resp. mozem pochvalit momentalne nasho hlavneho programatora
    http://yenar.host.sk
    za vytvorenie kniznic libco a libcwe, na ktorych je momentalne tucniak postaveny a ktore mozno v buducnosti najdu vyuzitie aj v inych GPL projektoch. A celkovo je navrh robeny tak ze az vyjde prvy funkcny release a dokumentacia ku kodu zakladnych modulov tak sa to cele rozbehne trosku rychlejsie.

  • 22. 10. 2002 14:54

    tap (neregistrovaný)

    http://www.postgresql.org/idocs/index.php?mvcc.html

    http://www.google.com/search?q=row+level+locking

    Prosim neobjavuj koleso.

  • 22. 10. 2002 15:03

    Koli (neregistrovaný)

    Neobjavujem koleso. A citujem z:
    http://www.postgresql.org/idocs/index.php?locking-indexes.html

    Though PostgreSQL provides nonblocking read/write access to table data, nonblocking read/write access is not currently offered for every index access method implemented in PostgreSQL.

    Co jasne hovori o tom ze zamykanie riadkov nie je implementovane.

  • 23. 10. 2002 8:44

    Karel Zak (neregistrovaný)

    Nejen, ze PG ma row level lock, ale ma i multi-version system pro data v radcich coz je hodne advance :-) Pokud chcete neco o transakcich podivejte se na www.dbsvet.cz je tam informativni a prehledny serial prave na toto tema.

    IMHO row level lock by mala mit i nejnovejsi MySQL v tabulkach InnoDB. Nezkousel jsem...

  • 23. 10. 2002 13:39

    Koli (neregistrovaný)

    Je ale treba rozlisit lockovanie riadkov a lockovanie riadkov. Ano MySQL obsahuje InnoDB ktore ma lockovanie riadkov a to je to co ma aj Postgres. Ale ide skor o to ze to zrychluje cinnost db, tym ze to nezamkne celu tabulky a tyka sa to hlavne prikazov SELECT.

    Vtip je v tom ze ak chceme uvazovat o multiuser interface potrebujeme niekde drzat informaciu o tom ze nejaky uzivatel pracuje s jednym udajom aj povedzme hodinu a ma k nemu vyhradny pristup ktorym neobmedzuje nijako ostatne udaje a ich integritu.

    Vsetko lockovanie riadkov co existuje sa tyka casovych rozsahov radovo v milisekundach alebo sekundach a nie drzania zamknuteho riadku na hodinu.

  • 23. 10. 2002 0:13

    mexiko (neregistrovaný)

    Pohybuju se v oblasti ucetnictvi pomerne dost dlouho a jiz znam nekolik systemu (teda mysleno programu). Tyto problemy se vsak nechaji pomerne jednoduse obejit pouze kratkodobym uzavrenim databaze - treba jen onoho skladu - kdy je do patricne radky skladove karty do kolonky nazvane treba "rezervace" zapsane odpovidajici mnozstvi objednanych jednotek. K jejich odpisu dojde az v okamziku vystaveni vydejky/prodejky/dodaciho listu. A pokud nekdo (jiny obchodnik) vstoupi do databaze, tak je mozne softwarove!!!! osetrit, ze sice vidi, ze je na sklade tolik atolik mnozstevnich jednotek, ale jsou rezervovane a muze kontaktovat druheho obchodnika pro blizsi informace.
    A jeste jedna poznamka - vetsina ucetnich se zuby nehty drzi DOS-verzi ucetnictvi. Dost dlouho jsem se tomu divil, ale po zkusenost s verzemi pro WIN uz ne - mnoho policek neprehledne na pomerne velke plose, vetsinou barevne preplacane, odlisne ovladani od DOS-verzi a predevsim jista svazanost a omezeni moznych oprav.

  • 22. 10. 2002 15:35

    Marek Slapak (neregistrovaný)

    Je pravda, že transakce nevyřeší všechno, ale tenhle problém si myslím dá vhodným datovým návrhem řešit.

    Navíc jak je níže psáno, existuje row level locking

    Co se mi ale na článku ze všeho nejvíce líbí je, že působí jako lehce pochopitelný tutoriál o tom, jak neuvěřitelně elegantně a jednoduše se dá zajistit integrita dat v případě, že DBMS k tomu dává k dispozici nástroje.

    Tak jak byl tenhle díl pojat a s jak jednoduchým návrhem báze dat pracuje je taky krásně vidět, že i při řešení relativně jednoduché datové úlohy lze využít nástrojů pro zajištění datové integrity.

    Já osobně tvrdím a stojím si zatím, že psát něco rozumnýho na DBMS bez těchto nástrojů je silně kontraproduktivní a neelegantní.

    To, že PostgreSQL tyto nástroje má a zároveň je free bylo důvodem, že sem ABSOLUTNĚ vyloučil používání MySQL ... proč se ochuzovat o tyhle features, když se skoro u čehokoli, co časem roste může stát, že i když tenhle aparát z počátku nepotřebuji, tak při update funkcionality se najednou může stát, že referenční integritu potřebovat budu .. Oprogramovávat to všelijakejma brigulema a psaním tuny kódu? to mi připadne trochu divný...

    Ale je to jen můj skromnej názor, nic víc - nic míň

  • 22. 10. 2002 15:44

    Petr Bravenec (neregistrovaný)

    >> Co se mi ale na článku ze všeho nejvíce líbí je, že působí jako lehce pochopitelný tutoriál o tom, jak neuvěřitelně elegantně a jednoduše se dá zajistit integrita dat v případě, že DBMS k tomu dává k dispozici nástroje.

    Marku, myslím, že jsi první, kdo skutečně kápnul na to, proč jsem se do psaní tohoto seriálu pustil.

  • 22. 10. 2002 16:00

    Marek Slapak (neregistrovaný)

    >Marku, myslím, že jsi první, kdo skutečně kápnul na >to, proč jsem se do psaní tohoto seriálu pustil.

    Fakt ? :-) No sdělil jsem jen to, jak na mě ten seriál působí ...

    ... jde o to, že ale bohužel hodně lidí co pracuje v IT se na problematiku nedovedou podívat z abstraktního úhlu pohledu, což je myslím zásadní chyba...
    Ale faktem je, že moje zkušenost je ta, že zpočátku na to čovek MUSÍ neustále upozorňovat, protože jinak se stává, že dojde k nedorozumění a začnou se jako "pointa" řešit detaily typu jestli má něco bejt ve dvou polích, nebo jednom :)

    Já v rámci své profese na to narážím velmi často. Do mojeho jobu spadá mj. koncepce vývoje v našem podniku.

  • 22. 10. 2002 16:11

    Adam (neregistrovaný)

    Zdravim, taky pridam par slov do diskuse:

    myslim, ze Vas clanek mluvi o uplne jinem problemu nez o trasnakcich a integritnich omezenich.
    Pokud jsem to dobre pochopil (a chapu to jako zpet na stromy se zamykanim radku v souborovych tabulkach), je cele reseni zalozene na "atomicke" operaci "vlozeni zaznamu do tabulky zamku", ze?
    Slouzi ale pouze jako informativni charakter pro vasi aplikacni logiku. co se stane, kdyz jiny klient tyto pravidla dodrzovat nebude (jako ze v olbasit open-source software se to muze velmi jednoduse stat) ??? A k tomu prave slouzi ony transkace a integritni omezeni, ktere jsou tu od toho aby zajistily ze nemuze existovat hlavicka dokladu bez polozek nebo polozky bez hlavicky, ze nedojde k pripadu, ze uzivatel XXX cte data zrovna ve chvili, kdy uzivatel YYY uz zapsat hlavicku dokladu, ale jeste nezapsal jeho polozky, atd...

    A muzu mit jeden dotaz: ja vyresite, ze se "z jakehokoliv duvodu" neco nepovede pri insert/update editovanych zaznamu tabulky polozek, tabulky hlavicky, a odstraneni zamku? To jsou minimalne 3 operace, ktere se musi chovat "jako jedna" a hlavne, pokud se neco nepovede, stale musi by data v konzistentnim stavu?... pro tento pripad reseni bez transakci neexistuje... prominte, existuje, mozna pro 5-ti uzivatelsky system, kdy kazdy uzivatel pracuje na jine casti systemu(datech) :-(

    Adam.

  • 23. 10. 2002 9:36

    yenar (neregistrovaný)

    K tomu dotazu:
    1) vycerpani pameti, nejaka vyjimka, atd. pocas transakce: Tucniak obsahuje implementaci CSEH (cleanup stack structured exception handling), takze kdyz mam otevrenou transakci a neco se stane, mam handler, ktery ji uzavre (teda zatim ne, ale budu, kdyz bude hotov aspon zakladni libtucniak a budu mit trochu casu se na to podivat).

    2) segfault uprostred transakce
    No, tohle nevim. V prvni rade by se nic takoveho stat nemelo. Kdyz se stane, mame nasledujici stav: Zamknuty radek, mozna neuplna data. Ten zamknuty radek je problem, ale tucniak by mel bez vetsich problemu akceptovat mirne rozsypanou db (myslim neexistujici reference a podobne, a nic horsiho by se nejspis pri padu stat nemelo). Krom toho ten sigsegv muze dostat i db server, a to je ponekud horsi situace :).
    Mozne reseni by bylo pouzit transakci (MySQL-max, PostgreSQL, ...) nebo timestamp a expiraci zamku.

    Minimalne ja chci, aby tucniak umoznoval beh i s netransakcni databazi, pripadna podpora transakci by mela byt v databazove zavislem modulu. Neco jako M (cnt, lock, ...) by zamklo radek a otevrelo transakci, M (cnt, unlock, ...) by radek odemklo a zavrelo transakci. Jenze to znamena i nekolik hodin otevrenou transakci, co nepovazuji za prave dobry napad. Jine navrhy? Rad se necham poucit...

  • 23. 10. 2002 15:37

    Marek Slapak (neregistrovaný)

    >>> Jine navrhy? Rad se necham poucit...

    Ahoj,
    asi už mě někdo brzo napadne, že sem nějakej PR agent fy. SUN :)))) ale:

    nějak mi připadne, že se trápíte low-level řešením věcí, které se dají elegantně a průhledně řešit. A to řešit tak, že využijete J2EE.

    J2EE = Java 2 Enterprise Edition, EJB = Enterprise Java Beans

    Doporučuji se mrknout lehce na nějakej tutoriál kolem tohoto fenoménu a myslím, že budete docela v šoku, jak je tahle technologie mocná a zároveň průhledná a kolik věcí je pro podporu psaní rozumných aplikací k dispozici a to zcela FREE a OpenSource ...

    A co se týká rychlosti, na Linuxu doporučuju prubnout JSDK 1.4.1 od SUNu, nebo JSDK od blackdown.org .. nedá se říct, že by procesní rychlost byla zrovna malá ...

    Co se týče IDE doporučuju se mrknout na www.netbeans.org ... žravé co do prostředků, ale geniální ...

    Co se týče aplikačního SW, doporučuji se mrknout třeba na www.jboss.org .. tahle potvora toho umí proklatě moc a nároky na HW nejsou nijak kritické

    ... možná to beru trochu oklikou, ale dávám to jako tip.

    HLAVNĚ co se mi hrozně líbí je filozofie J2EE. Tohle když někdo vymejšlel, tak při tom přemejšlel .. v kostce: do rukou vám tahle technologie dává nástroj, ve kterém v podstatě designujete řešení blíže k lidskému stylu myšlení oproti klasickému stylu programování. Komunikaci mezi komponentami vám řeší aplikační server a to jak se k komponentám přistupuje je vám putna - to řeší též aplikační server ...

  • 22. 10. 2002 18:37

    karel (neregistrovaný)

    1.
    problem, o ktery se zde jedny se jmenuje rezervovani zdroju a timestamping. Je to reseno v kazdem software. S transakcemi to nema nic spolecneho.

    2.
    Transakce tady nejsou kvuli tomu aby liny programator s mizernym designem mohl pri nesplneni logickych podminek provest cancel - nybrz proto, kdyz se program odporouci s memory fault. Bez transakce by doslo k nekonsistenci i na 1-user systemu.

    3.
    doporucuji vratit diplom

  • 22. 10. 2002 19:03

    kuba (neregistrovaný)

    obavam se, ze na tohle transakce opravdu urceny nejsou. tim nerikam, ze se nedaji pouzit. problem vidim v tom, ze tahle transakce by trvala az pul hodiny, coz vidim jako naprosto zasadni problem - takhle ten system rozumne konkurentne fungovat nemuze (i kdyby se pouzival row-level locking, pripadne mvcc - "better than row-level locking..." pouzivat takhle dlouhe transakce (v tomto pripade), povazuju za spatny db design.