sql >> Database teknologi >  >> NoSQL >> Redis

Fordele og ulemper ved at bruge Selleri vs. RQ

Her er, hvad jeg har fundet, mens jeg forsøgte at besvare præcis det samme spørgsmål. Det er sandsynligvis ikke udtømmende, og kan endda være unøjagtigt på nogle punkter.

Kort sagt, RQ er designet til at være enklere overalt. Selleri er designet til at være mere robust. De er begge fremragende.

  • Dokumentation. RQs dokumentation er omfattende uden at være kompleks, og afspejler projektets overordnede enkelhed – du føler dig aldrig tabt eller forvirret. Selleris dokumentation er også omfattende, men forvent at besøge den ret meget, når du først sætter tingene op, da der er for mange muligheder at internalisere
  • Overvågning. Selleri's Flower og RQ-dashboardet er begge meget enkle at konfigurere og giver dig mindst 90 % af al information, du nogensinde vil have

  • Mægler support. Selleri er den klare vinder, RQ understøtter kun Redis. Det betyder mindre dokumentation om "hvad er en mægler", men betyder også, at du ikke kan skifte mægler i fremtiden, hvis Redis ikke længere fungerer for dig. For eksempel overvejede Instagram både Redis og RabbitMQ med selleri. Dette er vigtigt, fordi forskellige mæglere har forskellige garantier f.eks. Redis kan ikke (i skrivende stund) garanterer 100% at dine beskeder bliver leveret.

  • Prioriterede køer. RQs prioritetskømodel er enkel og effektiv - arbejdere læser fra køer i rækkefølge. Selleri kræver, at flere arbejdere spindes op for at forbruge fra forskellige køer. Begge tilgange virker

  • OS Support. Selleri er den klare vinder her, da RQ kun kører på systemer, der understøtter fork for eksempel. Unix-systemer

  • Sprogstøtte. RQ understøtter kun Python, hvorimod Celery lader dig sende opgaver fra et sprog til et andet sprog

  • API. Selleri er ekstremt fleksibel (multiple resultat backends, nice config format, workflow canvas support), men naturligvis kan denne magt være forvirrende. Derimod er RQ api'et simpelt.

  • Underopgavesupport. Selleri understøtter underopgaver (f.eks. oprettelse af nye opgaver fra eksisterende opgaver). Jeg ved ikke, om RQ gør

  • Fællesskab og stabilitet. Selleri er nok mere etableret, men de er begge aktive projekter. I skrivende stund har Selleri ~3500 stjerner på Github, mens RQ har ~2000, og begge projekter viser aktiv udvikling

Efter min mening er Selleri ikke så kompleks, som dens omdømme kan få dig til at tro, men du bliver nødt til at RTFM.

Så hvorfor skulle nogen være villig til at bytte (velsagt mere fuldt udstyret) Selleri for RQ? I mit sind handler det hele om enkelheden. Ved at begrænse sig til Redis+Unix giver RQ enklere dokumentation, enklere kodebase og en enklere API. Det betyder, at du (og potentielle bidragydere til dit projekt) kan fokusere på den kode, du holder af, i stedet for at skulle opbevare detaljer om opgavekøsystemet i din arbejdshukommelse. Vi har alle en grænse for, hvor mange detaljer der kan være i vores hoved på én gang, og ved at fjerne behovet for at opbevare opgavekødetaljer derinde lader RQ vende tilbage til den kode, du holder af. Denne enkelhed kommer på bekostning af funktioner som inter-sprog opgavekøer, bred OS-understøttelse, 100 % pålidelige meddelelsesgarantier og muligheden for nemt at skifte meddelelsesmægler.



  1. Cassandra vs. MongoDB:hvilken skal du vælge

  2. En oversigt over databaseindeksering for MongoDB

  3. Den hurtigere metode til at flytte redis-data til MySQL

  4. Samtidighed i gopkg.in/mgo.v2 (Mongo, Go)