Vlákno názorů k článku PostgreSQL 10: drsně rozběhnutý slon od BrainLess - Dobrý den, existuje v pgsql použitelný ekvivalent Oracle...
-
Ivan (neregistrovaný)
Messaging, ktery podporuje (distribuovane) transakce neni az takova hloupost. Oracle AQ je opravdu dost pomaly. Na intertetovych forech je spousta lidi kdyz jsou nestastni z toho, ze to nasadili a zjistili, ze nedokaze rozumne skalovat. Na druhou stranu ale, uroven ochrany dat, kterou to poskytuje je ale zase nekde jinde.
PS: porad je to ale lepsi nez to co predvadi zoufalci s Java JMS, kteri si implementuji messaging pomoci tabulek v db "rucne".
-
Palo (neregistrovaný)
- Messagingov ktore podporuju distribuovane transakcie a nie su postavene na DB je dostatok
- Pre spracovanie vstupnych sprav je ale ovela efektivnejsie pouzit napriklad Kafku a 'At least one delivery' a znacit si v DB iba cislo spravy. Duplicitne potom zahodite. Bude to o niekolko radov rychlejsie a pri tom stale bezpecne. Popripade mozte aj exactly one delivery ak viete co robite.
- Pri posielani sa da tiez nieco vymysliet aby to fungovalo bezpecne zalezi od podmienok, v kazdom pripade distribuovane transakcie su zlo ktoremu sa treba vyhybat ako sa len da. Riesit transakcny monitor, jeho stavy, pady pripadne ho nasledne rucne opravovat, ... brrrr najhorsie nocne mory sa mi vracaju. -
BrainLess (neregistrovaný)
Takova ta klasika, mate tabulku do ktere vam na jedne strane ( producer ) cpe zaznamy ke zpracovani a na druhe strane ( consumer ) je chce zpracovat. Pokud nemate neco jako Oracle AQ pristupujete na hloupost typu (select * from trabulka where status = "Nezpracovano") a dostavate se do problemu, bud to delate rychle a ubijite DB timto dotazem a nebo mate delay ale tim "omezujete" rychlost reakce na zpracovani pozadavku.
Jinak AQ provozuji od doby co to Oracle zavedl ( miliardy procpanych pozadavku, nikdy problem, nikdy zadna ztrata dat apod. ) a naprosta spokojenost, kdyz to clovek pouziva s rozumem. Samozrejme kdyz se nadje troll co do te queue jako payload cpe 2MB xml message a divi se ze je to pomaly ;-) neni to problem technologie.
-
Viděl jsem několik extenzí - díky SKIP LOCKED lze i relativně efektivně řešit zamykání - ale stejně pro větší zátěž - tisíce zápisů/výběrů z fronty bych se snažil takové řešení rozmluvit. V těchto systémech mají data relativně krátkou životnost - a to není case pro Postgres. Postgres je fajn databáze, ale mizerná cache - není praktické (při větší zátěži - několik tisíc write transakcí za sec) používat Postgres pro data, která mají krátkou životnost. Jakýkoliv sw, který bude optimalizovaný pro frontu (v Pg tabulky jsou haldy) bude při větší zátěži výrazně stabilnější. To řešení od Skype by mělo být funkční - Skype to používal pro svou potřebu, ale je fakt, že je hodně specifické co se týče designu a sám jsem věcem ze Skype toolu na chuť nepřišel (ale neměl jsem ani moc velkou motivaci).
https://pgxn.org/dist/qgres/ -
www (neregistrovaný)
advisory locks: https://github.com/chanks/que/blob/master/lib/que/sql.rb#L5
ČLÁNKY DO MAILU