Hacker News 의견

• 다른 pg 기반의 Python 작업 실행기인 Procrastinate나 Chancy와 비교했을 때 어떤 점이 다른지 궁금함

• 매우 흥미로운 내용임

  • FOR UPDATE SKIP LOCKED가 25k 쿼리/초로 확장되지 않는다고 했을 때, 어느 시점에서 한계에 도달했는지 궁금함
  • 버퍼링된 읽기와 쓰기, 모든 대량 테이블을 ID 열로 전환하는 것에 대해 궁금함
  • 이러한 점들이 FOR UPDATE SKIP LOCKED를 필요에 맞게 확장하는 해결책의 일부였는지 궁금함

• 큐 작업(작업을 큐에 넣고 완료로 표시하는 것)이 내 비즈니스 로직과 동일한 트랜잭션에서 발생하는지 궁금함

  • 데이터베이스 기반 큐의 핵심 기능이라고 생각함
  • 재시도에 대한 논리를 단순화함
  • 작업 수행 시에도 동일한 문제가 발생할 수 있음
  • 이 시점에서는 SQS를 사용하는 것이 나을 수도 있음

• 이벤트/워크플로우 기반 애플리케이션을 설계 중인데, 이 솔루션이 매우 유망해 보임

  • Temporal도 고려했지만 완벽한 적합성은 느끼지 못했음
  • 오픈 소스 라이선스가 애플리케이션 설계에 대한 자신감을 줌
  • CEL과 같은 조건문을 찾고 있었음

• Hatchet 아키텍처의 여섯 가지 개선 사항 덕분에 모든 차원에서 성능이 향상됨

  • 시간 시리즈 테이블의 범위 기반 파티셔닝
  • 작업 이벤트의 해시 기반 파티셔닝
  • 모니터링 테이블과 큐의 분리
  • 버퍼링된 읽기와 쓰기
  • 모든 대량 테이블을 ID 열로 전환
  • Postgres 트리거의 적극적인 사용
  • 매뉴얼을 읽으면 놀라운 일을 할 수 있음

• README는 다크 모드를 사용하는 사용자가 더 많다고 가정함

  • 로고가 흰색이라 다크 모드가 없으면 보이지 않음
  • GitHub의 통계를 보면 흥미로울 것임

• Postgres를 메시지 큐로 사용할 때 큰 페이로드(50MB 이상)를 처리하는 문제에 직면함

  • 해결책은 비로그 테이블과 정기적인 전체 진공 사용이었음
  • Postgres 전문가가 아니지만, 이 문제를 해결했는지 궁금함

• 문서를 15분 동안 검토한 후 피드백을 제공함

  • 라이트 모드, 오픈 소스, 로깅, DX 인터페이스가 좋음
  • Hello World 예제를 실제 시나리오로 대체하는 것이 좋을 것임
  • 다단계 작업을 포함하는 워크플로우의 코드가 직관적이지 않음
  • Hatchet의 사고방식, 패턴, 용어에 익숙해져야 함
  • 고객에게 쉽게 만들기 위한 노력이 부족해 보임
  • 엔지니어링 게시물은 의미가 있지만, 고객은 클라우드 인프라에 관심이 없음
  • 워크플로우 시장에서 많은 옵션이 있기 때문에 마지막으로 재작성하거나 피벗할 가능성이 높음
  • 자동화 여정을 집중하고, 사람들이 쉽게 가져와서 구성할 수 있도록 해야 함
  • 워크플로우를 JSON으로 직렬화하기 어려움
  • Hatchet 워크플로우를 다른 회사로 쉽게 이동할 수 있도록 해야 함

• v1 출시를 축하함

  • Hatchet을 거의 1년 동안 사용해 왔고, 6개월 전에 프로덕션에 배포함
  • 오픈 소스 지원과 빠른 시작이 훌륭함
  • 시스템에 투입된 엔지니어링 작업이 눈에 띔

• 첫인상은 좋음, 출시를 축하함

  • 몇 가지 질문이 있음
  • 영구적인 작업을 지원하는지 궁금함
  • 작업 입력과 출력이 어디에 저장되는지 궁금함
  • PostgreSQL 인스턴스의 크기와 I/O 메트릭을 기반으로 시스템이 초당 처리할 수 있는 작업 수를 추정할 수 있는지 궁금함
  • 다양한 도구를 평가 중이며, Hatchet이 어떤 느낌인지 알고 싶음
  • 최소한의 보일러플레이트로 작업할 수 있는 도구를 찾고 있음