DiceDB 출시
(dicedb.io)- DiceDB는 오픈소스, 고성능, 반응형 인메모리(in-memory) 데이터베이스임
- 주로 캐시로 사용되며, 쿼리 구독(query subscription)을 통해 실시간 데이터 업데이트 제공
- 최신 하드웨어에 최적화되어 높은 처리량과 낮은 지연 시간을 제공
- 사용하기 쉽고 친숙한 인터페이스를 제공하며 오픈 소스
-
성능 벤치마크
- Hetzner CCX23 머신(4 vCPU, 16GB RAM)에서 다른 인메모리 데이터베이스와 비교한 처리량 및 GET/SET 지연 시간
- 처리량(ops/sec): DiceDB 15655, Redis 12267
- GET p50(ms): DiceDB 0.227327, Redis 0.270335
- GET p90(ms): DiceDB 0.337919, Redis 0.329727
- SET p50(ms): DiceDB 0.230399, Redis 0.272383
- SET p90(ms): DiceDB 0.339967, Redis 0.331775
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보다 훨씬 느림