abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 19:44 | Nová verze

    Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.

    Ladislav Hagara | Komentářů: 0
    dnes 17:33 | Nová verze

    Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.

    Ladislav Hagara | Komentářů: 0
    dnes 05:33 | Komunita

    Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.

    Ladislav Hagara | Komentářů: 13
    dnes 03:55 | Komunita

    sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.

    Ladislav Hagara | Komentářů: 0
    včera 22:11 | Nasazení Linuxu

    Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).

    Ladislav Hagara | Komentářů: 2
    včera 13:22 | IT novinky

    Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.

    Ladislav Hagara | Komentářů: 1
    včera 04:55 | Nová verze

    Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.

    Ladislav Hagara | Komentářů: 1
    včera 00:33 | Komunita

    Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.

    Ladislav Hagara | Komentářů: 32
    5.5. 23:22 | Pozvánky

    Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou

    … více »
    bkralik | Komentářů: 0
    5.5. 22:33 | IT novinky

    Dle plánu dnes končí služba Skype. Uživatelé mohou pokračovat v Microsoft Teams.

    Ladislav Hagara | Komentářů: 1
    Jaký filesystém primárně používáte?
     (57%)
     (1%)
     (8%)
     (22%)
     (4%)
     (2%)
     (3%)
     (1%)
     (1%)
     (3%)
    Celkem 548 hlasů
     Komentářů: 25, poslední dnes 20:12
    Rozcestník

    Dotaz: Postgresql - snapshot tabulek???

    24.9.2015 20:28 tino
    Postgresql - snapshot tabulek???
    Přečteno: 1205×
    Ahoj, mám víceuživatelskou webovou aplikaci, která provádí následující:
    1. Uživatel vloží vstup
    2. Na základě vstupu aplikace načte data z db
    3. Na základě oněch načtených dat a obsahu nějakých souborů na disku načte další data z db a něco do db uloží

    Problém je ten, že všechny body musí vidět stejná data. Body 2 a 3 mohou trvat několik minut, takže nepřichází v úvahu běh v transakci. Ta by mi kvůli konkurenčnímu použití aplikace málokdy doběhla do konce. Nechci nijak zamykat řádky, chci jen po dobu sql spojení "snapshot" stavu několika tabulek. V transakci bych zpracovával jen něco v bodu 3.

    Původně jsem myslel, že bych "vnořoval" transakce (SAVEPOINT), nicméně pokud by ta podtransakce v bodu 3 něco zamykala, tak by mohla zhavarovat ta "rodičovská" transakce v jiném spojení. Jediné současné řešení, které mě napadá je manuálně si verzovat řádky vybraných tabulek. Je ještě jiná možnost? Ideálně něco jako "rodičovská" transakce, které by nikdy nedělala rollback "dceřiných".

    Odpovědi

    okbob avatar 25.9.2015 07:31 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    U databází, které jsou postavené nad MVCC- Multi Version Concurrency Control (a to Postgres je) transakce v řádech minut obvykle nebývají problém. Pracovat se snaphotem je ten nejmenší. Zde platí, že UPDATE neblokuje SELECT a SELECT neblokuje UPDATE.
    25.9.2015 09:19 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    Připojím se s dotazem: Mám eshop, který při objednání zapisuje do tabulky produktů (aktualizuje zde počet prodaných kusů) a mám dávku, která v eshopu aktualizuje údaje o produktech (data se berou ze skladového systému). Dávka běží v transakci několik minut. Problém je zřejmý: Pokud během této doby někdo objednává, zasekne se objednávka a čeká na dokončení transakce a jelikož to probíhá synchronně s odesíláním košíku, čeká i uživatel. A nakonec dojde buď trpělivost uživateli nebo dojde na timeout při čekání na konec transakce. Databáze je Mysql.

    Jak toto nejlépe řešit? Nejlépe při zachování atomicity té dávky (buď prijde celá nebo vůbec). Nad dávkou mám plnou kontrolu, nad eshopem taky ale nechci upravovat jádro.

    PS: Dávka byla navržená původně na běh 1x denně v noci, ale znáte to, přišlo se na to, že je občas potřeba aktualizovat i během dne.
    -- OldFrog
    okbob avatar 25.9.2015 09:31 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    Pokud se pracuje nad stejnými tabulkami, tak se s tím nedá nic dělat. Ověřit si, že běžíte nad InnoDB, které zamyká po řádcích, a snažit se co nejrychleji urychlit dávku - což znamená hlavně rychlé disky, dost paměti, indexy. Dalším řešením je rozdělit transakci po kategoriích atd. Dálším může separátní uložiště pro odeslání košíku - i při UPDATE se může z tabulky číst.

    V prvním kroku bych se zaměřil na rychlost té dávky - na dnešních počítačích bych během několika minut měl zaktualizovat několik miliónů produktů. To skutečně děláte? Pokud ne, tak je docela dost možné, že ta dávku bude možné napsat inteligentněji.
    25.9.2015 10:04 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    Ověřit si, že běžíte nad InnoDB, které zamyká po řádcích
    Ano, všude je InnoDB. Ale čeká to na dokončení celé transakce. Dávka jde sekvenčně produkt po produktu, u každého produktu udělá dotazy do několika tabulek a několik tabulek aktualizuje. Transakce tam je začatá úplně primitivně na začátku celé dávky, takže pokud dojde k chybě neaktualizuje se žádný produkt. Asi by stačilo transakci otevřít a pak komitnout pro každý produkt zvlášť, takže by byla zaručena alespoň konzistence jednotlivého produktu. Musel bych prostudovat, jaké tam jsou vedlejší efekty - kvůli něčemu jsme transakce po produktech zamítli.
    Dalším řešením může být separátní uložiště pro odeslání košíku - i při UPDATE se může z tabulky číst.
    Tomuhle nerozumím, můžete to prosím ještě rozvést?
    (...) během několika minut měl zaktualizovat několik miliónů produktů. To skutečně děláte? Pokud ne, tak je docela dost možné, že ta dávku bude možné napsat inteligentněji.
    Ta dávka není čisté sql, používá se orm a řeší se tam kde co, mimo jiné se rozhoduje podle existujících záznamů v databázi. Přepis do sql s případným použitím procedur by bylo ideální, nicméně nejdražšší řešení.
    -- OldFrog
    okbob avatar 25.9.2015 10:31 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    Při zpracování košíku bych nezapisoval do tabulky produktů, ale do nějaké pomocné tabulky. Tím by nemělo docházet k čekání na zámek.

    Přepis do SQL - vždy je to otázka ceny, ale spočítejte si, kolik zákazníků a prodeje ztratíte.
    25.9.2015 10:38 OldFrog {Ondra Nemecek} | skóre: 36 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Postgresql - snapshot tabulek???
    Ano, košík by neměl zapisovat do tabulky produktů, to je chyba návrhu (jde o OXID eshop). Pokud se zápis odstraní, vše funguje. Takže by bylo řešení si to ukládat bokem do jiné tabulky a pak třeba jednou denně přelít do tabulky produktů. To je asi nejschůdnější řešení, vyžadující bohužel zásah do eshopu.

    Děkuju za odpovědi a mějte se!
    -- OldFrog

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.