셀러리 대 RQ 사용에 대한 장단점
현재 저는 몇 가지 백그라운드 작업을 구현해야 하는 파이썬 프로젝트를 진행하고 있습니다(주로 이메일 전송 및 데이터베이스 업데이트).작업 브로커로 Redis를 사용합니다.그래서 이 점에서 저는 두 명의 후보자가 있습니다.셀러리와 RQ.저는 이러한 작업 대기열에 대해 약간의 경험이 있지만, 여러분께 이 도구를 사용한 경험을 공유해 주시기를 부탁드립니다.그렇게.
- 셀러리를 사용하는 것에 대한 장점과 단점RQ.
- 셀러리를 사용하는 데 적합한 프로젝트/작업의 예와RQ.
셀러리는 꽤 복잡해 보이지만 모든 기능을 갖춘 솔루션입니다.사실 저는 이 모든 기능이 필요하다고 생각하지 않습니다.다른 쪽에서 보면 RQ는 매우 간단하지만(예: 구성, 통합) 몇 가지 유용한 기능(예: 작업 취소, 코드 자동 재로드)이 부족한 것 같습니다.
정확히 같은 질문에 답하려고 노력하는 동안 발견한 것은 다음이 있습니다.그것은 아마도 포괄적이지 않을 것이고, 어떤 점에서는 부정확할 수도 있습니다.
간단히 말해서, RQ는 모든 면에서 더 단순하도록 설계되었습니다.셀러리는 더 튼튼하도록 설계되었습니다.그들은 둘 다 훌륭합니다.
- 설명서.RQ의 문서는 복잡하지 않고 포괄적이며 프로젝트의 전체적인 단순성을 반영합니다. 이는 길을 잃거나 혼란스러워하는 일이 전혀 없습니다.셀러리의 설명서도 포괄적이지만 내부화할 수 있는 옵션이 너무 많기 때문에 처음 설정할 때는 상당히 많이 다시 방문할 것으로 예상됩니다.
모니터링.셀러리의 꽃과 RQ 대시보드는 모두 설정이 매우 간단하며 원하는 모든 정보의 최소 90%를 제공합니다.
브로커 지원.셀러리는 확실한 승자이고, RQ는 레디스만 지원합니다.이는 "브로커란 무엇인가"에 대한 문서가 적어진다는 것을 의미하지만, Redis가 더 이상 당신을 위해 일하지 않는다면 앞으로 브로커를 바꿀 수 없다는 것을 의미합니다.예를 들어, 인스타그램은 레디스와 토끼를 모두 고려했습니다.셀러리와의 MQ.이는 중개인마다 보증이 다르기 때문에 중요합니다.Redis(문서 작성 시점)는 메시지가 배달되는 것을 100% 보장할 수 없습니다.
우선 순위 대기열.RQs 우선 순위 대기열 모델은 간단하고 효과적이며 작업자가 대기열에서 순서대로 읽습니다.셀러리는 서로 다른 대기열에서 소비하기 위해 여러 작업자의 회전 속도를 높여야 합니다.두 가지 접근 방식 모두 효과가 있습니다.
지원. 를 지원하는 셀러리가 는 셀러리입니다.
forkUnix ": Unix 시스템언어 지원.RQ는 Python만 지원하지만 Celery는 한 언어에서 다른 언어로 작업을 전송할 수 있습니다.
API. 셀러리는 매우 유연하지만(여러 결과 백엔드, 멋진 구성 형식, 워크플로우 캔버스 지원) 자연스럽게 이 기능은 혼란스러울 수 있습니다.이와 대조적으로, RQ api는 간단합니다.
하위 작업 지원.셀러리는 하위 작업(예: 기존 작업 내에서 새 작업 만들기)을 지원합니다.RQ가 그러는지 모르겠습니다.
공동체와 안정성.셀러리는 아마도 더 설립되었을 것이지만 둘 다 활동적인 프로젝트입니다.글을 쓰는 기준으로, 셀러리는 Github에 약 3500개의 별을 가지고 있는 반면, RQ는 약 2000개의 별을 가지고 있으며 두 프로젝트 모두 활발한 발전을 보여줍니다.
제 생각에, 셀러리는 평판이 당신이 믿게 만드는 것만큼 복잡하지는 않지만, 당신은 RTFM을 해야 할 것입니다.
그렇다면, 왜 사람들이 (아마도 더 완전한 기능을 갖춘) 셀러리를 RQ와 바꾸려고 합니까?제 생각에는, 모든 것이 단순함으로 귀결됩니다.RQ는 Redis+Unix로 제한함으로써 더 간단한 문서, 더 간단한 코드베이스, 더 간단한 API를 제공합니다.즉, 작업 대기열 시스템에 대한 세부 정보를 작업 메모리에 저장하는 대신 사용자(및 프로젝트의 잠재적인 기여자)가 중요한 코드에 집중할 수 있습니다.우리 모두는 한 번에 얼마나 많은 세부 정보를 머릿속에 담을 수 있는지에 대한 제한을 가지고 있습니다. RQ에 작업 대기열 세부 정보를 보관할 필요를 제거함으로써 관심 있는 코드로 돌아갑니다.이러한 단순성으로 인해 언어 간 작업 대기열, 광범위한 OS 지원, 100% 신뢰할 수 있는 메시지 보장 및 메시지 브로커를 쉽게 전환할 수 있는 기능과 같은 기능이 희생됩니다.
셀러리는 그렇게 복잡하지 않습니다.핵심에서 에서 단계별 구성을 수행한 다음celery를 들어,을 예를들어다, 를음장식다니합로으함수로 .@celery.task그런 다음 을 사용하여 태스크 실행my_task.delay(*args, **kwargs).
당신 자신의 평가에 따르면, 당신은 (주요한) 특징이 없는 것과 지나친 것 중 하나를 선택해야 할 것 같습니다.그것은 내가 보기에 그리 어려운 선택은 아닙니다.
언급URL : https://stackoverflow.com/questions/13440875/pros-and-cons-to-use-celery-vs-rq
'it-source' 카테고리의 다른 글
| C: printf에서 ptrdiff_t에 어떤 문자를 사용해야 합니까? (0) | 2023.07.25 |
|---|---|
| REST api를 사용하여 MariaDB에서 데이터를 가져오는 방법은 무엇입니까? (0) | 2023.07.25 |
| Spring REST 컨트롤러가 빈 데이터와 함께 JSON을 반환합니다. (0) | 2023.07.25 |
| 파일 및 폴더에 대한 Node.js 프로젝트 명명 규칙 (0) | 2023.07.25 |
| 부동 소수점 번호의 정확한 값은 어떻게 인쇄합니까? (0) | 2023.07.25 |