Hacker News 의견

• 2015년 Uber에서 근무할 때, 우편번호 기반의 지리적 분할을 육각형 기반의 방식으로 전환하려고 했음

  • 도시를 수십 개의 우편번호로 나누는 대신, 수십만 개의 육각형으로 나누고 동적으로 영역을 생성하는 방식이었음
  • 피닉스에서 첫 출시가 있었고, 팀은 수요 가격 시스템을 확장하기 위해 밤을 새웠음
  • 글로벌 출시가 지연되었음
  • Redis를 좋아하는 엔지니어들이 많았음
  • 가격 서비스는 Redis를 기반으로 했고, 수백만 건의 요청을 처리했음
  • 비용이 많이 들었고, 확장성 문제도 있었음
  • 알고리즘을 개선하여 단일 기계에서 여러 도시의 동적 영역을 계산할 수 있었음
  • Isaac이라는 엔지니어가 주말 동안 구현하고 배포했음

• Redis를 과도하게 사용하는 것에 대한 논쟁이 있었음

  • Redis는 멋지지만, 사용 시 네트워크 지연과 직렬화 오버헤드가 발생함
  • 데이터가 이미 분할되어 있다면, 일반적인 해시맵이 더 나을 수 있음
  • Java에서는 ConcurrentHashMap, Guava Caches, Caffeine Caches 등이 있음
  • 로컬 캐싱 구현이 네트워크를 사용하는 것보다 거의 항상 빠름
  • Redis는 과도하게 사용되는 경향이 있음

• Redis 사용 문화가 그 인기에 비해 발전하지 않았음

  • Redis는 다양한 데이터 구조를 지원하며, 회사 문화가 발전할수록 더 많은 패턴을 배울 수 있음
  • Redis의 패턴 모음집이 없다는 것이 아쉬움

• Redis와 비Redis의 문제가 아니라, 직렬화가 잘 되지 않는 데이터와의 작업 문제임

  • 카운터, 뉴스 피드, 채팅 메시지 등은 Redis가 더 효율적일 수 있음
  • 대부분의 경우 MySQL로도 충분히 처리 가능함

• 소프트웨어 개발은 종종 다른 사람의 방식을 반복하는 경향이 있음

  • Memcached에서 시작하여 Redis로 발전했음
  • 데이터베이스의 복잡성을 피하기 위해 캐시를 사용하는 경향이 있음
  • 데이터베이스는 여전히 복잡하고 어려움

• Redis는 유일한 프로덕션 준비된 "데이터 구조 서버"임

  • 여러 인스턴스에서 동일한 서비스를 접근할 때 유용함

• 캐시가 필요하지 않을 수도 있음

  • 캐시를 도입하지 않고 아키텍처 개선에 집중한 경험이 있음

• Redis의 API는 훌륭하지만, 운영상의 위험이 있음

  • 캐시로는 좋지만, 프로덕션 데이터 저장소로는 신뢰할 수 없음

• Redis 사용을 추천하지 않는 경향이 놀라움

  • Redis는 여전히 훌륭한 데이터 구조와 성능을 제공함

• Redis는 임시 캐시로는 괜찮지만, 트랜잭션이나 분산 저장소로는 부족함

  • 분산 잠금 문제에 대한 학습이 필요함