Hacker News 의견

• 이 코드에는 많은 버그가 있음

  • 예를 들어, ExpandID 함수는 cycleMap에서 읽을 때 패키지 전역 뮤텍스를 잠그지 않음
  • NextID 함수는 cycleMap에 쓸 때 패키지 전역 뮤텍스를 잠금
  • 쓰기는 서로 동기화되지만 읽기와는 동기화되지 않아 ExpandID와 NextID의 동시 호출 시 경쟁 상태 발생 가능성 있음
  • 취미 프로젝트로는 괜찮지만, 생산 가능한 시스템과는 거리가 멀음

• DiceDB 코드베이스를 보며 디자인에 대한 몇 가지 질문이 있음

  • 이 프로젝트의 목표와 디자인 논리를 이해하고자 함
  • 주 메모리 저장소가 잠금이 있는 표준 Go 맵으로 보임
  • 이는 반복적 개발을 위한 임시 선택인지, 더 최적화된 데이터 구조로의 장기 계획이 있는지 궁금함
  • DiceDB의 반응 메커니즘, 특히 전체 감시 명령의 재실행이 흥미로움
  • Eval 함수가 클라이언트 측 명령을 실행하는 것으로 보이며, 이는 더 복잡한 감시 명령을 위한 기초를 다지는 것으로 보임
  • 전체 명령을 재실행하는 주된 동기가 무엇인지 궁금함
  • 재실행이 계산적으로 비싼 작업일 수 있는데, 성능 병목 현상은 어떻게 해결되는지 궁금함
  • 이 "재실행" 접근 방식이 확장성과 일관성 면에서 다른 방법들과 어떻게 비교되는지 궁금함
  • GET.WATCH 외에 더 복잡한 감시 명령을 지원할 계획이 있는지 궁금함
  • 이 디자인 선택의 트레이드오프와 프로젝트의 목표와의 정렬 여부에 대해 궁금함

• 이 기술이 실제로 무엇인지 설명하는 문장이 있는지 궁금함

• 우연의 도구를 데이터 저장 기술의 이름으로 사용하는 것이 재미있음

• DiceDB는 무작위 결과를 반환하는 농담 같은 데이터베이스 이름처럼 들림

• 4vCPU와 num_clients=4에서의 벤치마크 결과가 크게 다르지 않음

  • 반응형이 유망해 보이지만, 캐시로서의 실용성은 낮아 보임
  • 예를 들어, 클라이언트가 구독 중인 상태에서 기계가 다운되면 반응성은 어떻게 되는지 궁금함

• DiceDB와 Redis의 성능 비교

  • DiceDB의 처리량은 초당 15655 ops, Redis는 12267 ops
  • GET p50과 p90, SET p50과 p90의 응답 시간 비교

• GET 요청에 20ms를 소비하는 것이 이해되지 않음

  • 기존 오픈소스 구현에 대한 경험은 많지 않지만, 이전 직장에서의 인메모리 응답 시간은 수십~수백 마이크로초였음
  • io_uring을 사용하면 더 나은 타이밍이 나올 것으로 예상됨
  • NVMe에서 읽고 6개의 노드에서 복구를 수행하면 수십 밀리초가 걸릴 수 있음
  • 단일 노드 RAM DB에서 이러한 숫자가 나오는 것이 이해되지 않음

• 저지연 고처리량 오픈소스 키-값 저장소에 대한 경험이 있는지 궁금함

  • 특정 구현을 추천할 수 있는지 궁금함

• PubSub의 전달 의미론에 대해 알고 싶음

  • 최선의 노력/최대 한 번 전달인지, 재시도가 있는지 궁금함
  • 메시지가 전달되거나 실패할 수 있는 시나리오가 무엇인지 궁금함

• Hetzner CCX23 기계에서 초당 15655 ops는 인메모리 데이터베이스로서는 느림

  • 네트워크 지연을 탓할 수 없음
  • supermassivedb.com은 Go로 작성되었고 훨씬 더 많은 성능을 발휘함
  • Dice의 병목 현상을 조사해야 함

• Nubmq보다 훨씬 느림