abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 13:00 | IT novinky

    Jednodeskový počítač Raspberry Pi slaví 12 let. Prodej byl spuštěn 29. února 2012 (Wikipedie, 𝕏).

    Ladislav Hagara | Komentářů: 5
    včera 12:00 | Nová verze

    Byla vydána verze 3.2 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ářů: 0
    včera 11:44 | Nová verze

    Byla vydána nová verze 1.6.0 grafického správce diskových oddílů GParted (GNOME Partition Editor) a také verze 1.6.0 živé distribuce GParted Live, která obsahuje tohoto správce a další nástroje pro zálohování či obnovu dat. Linux byl povýšen na verzi 6.6.15-2.

    Ladislav Hagara | Komentářů: 1
    včera 06:00 | Nová verze Ladislav Hagara | Komentářů: 0
    28.2. 22:44 | Nová verze

    Byla vydána (𝕏) únorová aktualizace aneb nová verze 1.87 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.87 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

    Ladislav Hagara | Komentářů: 10
    28.2. 22:11 | Nová verze

    Byla vydána (Mastodon, 𝕏) nová verze 2024.1 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.

    Ladislav Hagara | Komentářů: 0
    28.2. 18:44 | Zajímavý software

    Společnost Cloudflare pod licencí Apache 2.0 uvolnila zdrojové kódy svého frameworku Pingora napsaného v Rustu pro vytváření rychlých, spolehlivých a programovatelných síťových systémů.

    Ladislav Hagara | Komentářů: 0
    28.2. 16:55 | IT novinky

    Účet za cloudové služby může nepříjemně překvapit. Například místo obvyklých 0 dolarů se ve vyúčtování může objevit 104 500 dolarů. Uživatel si u Netlify hostoval jednoduchý web a 4 roky nemusel nic platit. Měsíčně se nikdy nepřeneslo více než 10 GB dat. V únoru se to ale změnilo. Během několika dnů to jenom na jedné písničce v mp3 udělalo 164 TB a za každých 100 GB navíc by měl uživatel platit 55 dolarů. V rámci reklamace byla cena snížena na 5 225

    … více »
    Ladislav Hagara | Komentářů: 4
    28.2. 12:44 | Nová verze

    Komunita KDE s hrdostí uvádí Plasma 6, Frameworks 6 a Gear 24.02 postavené na Qt 6. Předchozí velké vydání 5 bylo vydáno téměř před 10 lety (červenec 2014).

    Ladislav Hagara | Komentářů: 13
    27.2. 21:11 | Nová verze

    Byla vydána nová major verze 6.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Založena je na Debianu 12 Bookworm a GNOME 43. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.10.

    Ladislav Hagara | Komentářů: 0
    Kolik máte nálepek na víku notebooku?
     (18%)
     (60%)
     (5%)
     (3%)
     (5%)
     (9%)
    Celkem 428 hlasů
     Komentářů: 18, poslední 27.2. 20:10
    Rozcestník

    Dotaz: Postgresql - snapshot tabulek???

    24.9.2015 20:28 tino
    Postgresql - snapshot tabulek???
    Přečteno: 1164×
    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.