Asi jsem staromodní, ale pořád mi přijde lepší použít nástroj, který byl primárně vyvinutý na řešení dané úlohy. Takže na key-value Redis, na message broker RabbitMQ a na web v Pythonu uwsgi. Že ten nástroj umí něco dalšího může být fajn v jednoduchých případech, ale je tam riziko, že se daleko dřív narazí na kompromis.
Jj taky jsem staromódní, ale fakt porovnáváš porovnatelné? Storage: Redis, ano. Message broker - na to je RMQ skvělý (nebo 0MQ), ale tady se bavíme spíše o job queue nebo o task queue. Tu ve skutečnosti nedělá RQ sám, ale používá přímo prostředky OS, proto je tak extrémně snadný. uwsgi tam zapadá přesně jak? Pro ovládání?
Pokud tam není intenzivní zátěž, tak je to ok - tj pro déletrvající joby. Mám zákazníka, kterému fronty implementované v SQL fungovaly 5 let, ale s tím jak intenzivně zvyšoval zátěž musel přejít na nativní message queue sw. Jejich joby oscilují mezi stovkami milisec a několika sec, problémem jsou několika minutové peaky, kde se takových jobů může protočit desítek tisíc - navíc v systému citlivém na latence.
Jinak, pokud by se používalo SQL řešení pro zátěž do cca 500-1000 tps, tak dost možná bych si nekomplikoval život a použil SQL db, u větší zátěže spíš asi ne.
Jezdím po zákaznících a mám docela problém říct, co je typické použití - alespoň u mých zákazníků nic typického nevidím.
Jen bych doplnil, že z praxe znám případ, kdy to běželo i v zátěži přes 7000 q/s. Jednalo se ovšem o MySQL 3.23 (před 15 lety), která byla dostatečně primitivní, aby měla malou režii. Plnohodnotná databáze (s MVCC apod.) by pro tento účel opravdu nebyla nejvhodnější. A i samotná MySQL, jak získávala tyto vlastnosti, "ztratila" rychlost takovýchto operací několikanásobně.
Předpokládám, že to bylo nad MyISAM nebo in memory. Dost možná, že za pár let to bude jedno - jakmile budou k dispozici inmemory ACID SQL databáze - ale i tak - relační tabulka je halda, a nemůže se výkonnostně srovnávat s čímkoliv, co má frontu opravdu implementovanou interně jako frontu. U msg queue systémů dost často nemáte implementovaný UPDATE -- pouze něco jako INSERT, a SELECT + DELETE. Pokud vím, že nebude UPDATE, tak si mohu dovolit mnohem jednodušší formát - navíc fronty mají typicky relativně málo záznamů - což mohu zase využít pro výkonnostní optimalizace - např. mohu pracovat se záznamem jako s větou fixní velikosti, atd.
Ano, byl to MyISAM a během standardního provozu se požadavky vyřizovaly tak rychle, že bylo všechno malé a udrželo se v cache (takže de facto in-memory).
A jak sem uvedl, můj příspěvek byla exkurze do historie, kdy nebyly stabilní message brokery běžně k dispozici. Např. do premiéry i zde zmíněného RabbitMQ chyběly ještě minimálně 4 roky a v případě Redisu to bylo ještě víc :)