저자는 캐싱, 세션, 큐와 같은 다양한 백엔드 작업에 Redis를 광범위하게 사용해 왔습니다. 최근에는 호환되지만 아키텍처가 다른 대안인 Dragonfly를 탐색했습니다. Dragonfly는 Redis API를 기반으로 하지만 최신 멀티코어 프로세서를 활용하기 위해 멀티스레드, 공유되지 않는 아키텍처를 사용합니다. 이는 단순성과 예측 가능성을 위해 설계된 Redis의 주로 단일 스레드 실행과 대조됩니다.Dragonfly는 프로토콜 호환성 덕분에 통합이 쉬웠습니다. 아키텍처가 성능 향상을 제공하는 CPU 또는 메모리 바운드 워크로드가 되면 잠재적인 이점이 나타납니다. 그러나 Dragonfly는 더 젊은 프로젝트이며 일부 거친 부분이 있습니다. 지속성은 스냅샷 전용이며 세분화된 내구성을 위한 Redis의 AOF 옵션이 부족합니다. Lua 스크립팅 동작은 동적으로 생성된 키의 경우 특히 다를 수 있으며, 여러 키 작업은 조정 비용을 발생시킵니다. 클러스터링은 다르게 관리되며 일부 고급 Redis 모듈과의 호환성은 아직 보장되지 않습니다.저자는 Dragonfly의 버그 목록이 늘어나고 있지만 Redis의 성숙도에 비해 초기 단계라고 언급합니다. Redis는 오랜 안정성, 강력한 내구성 옵션, 방대한 생태계 지원 및 모든 기능에 걸친 예측 가능한 동작에서 여전히 이점을 가지고 있습니다. 둘 사이의 선택은 특정 워크로드 특성과 운영 요구 사항에 따라 달라집니다. Redis는 워크로드를 편안하게 처리하거나 성숙도와 생태계가 가장 중요하다면 여전히 적합합니다. Dragonfly는 스냅샷 지속성이 허용되는 경우 대규모 기계에서 CPU 집약적인 작업, 메모리 효율성이 중요한 경우 또는 클러스터 관리를 단순화하려는 경우 평가할 가치가 있습니다. 궁극적으로 둘 다 타당한 아키텍처 결정을 내렸으며 최상의 선택은 개별 프로젝트 요구 사항에 따라 달라집니다.