Dotaz: Postgresql - snapshot tabulek???

[tino]

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]

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.

[OldFrog {Ondra Nemecek}]

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.

[okbob]

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.

[OldFrog {Ondra Nemecek}]

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í.

[okbob]

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.

[OldFrog {Ondra Nemecek}]

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!