2 câu hỏi đã được viết

0

안녕하세요. 좋은 질문 주셨네요.

Redis도 싱글스레드이기 때문에 요청이 몰리면, 줄을 서는 것은 동일합니다.(RDB는 Lock으로 대기를 하는 거지만, 줄을 서는 것은 동일합니다.)

다만, 이 둘 간의 처리 속도는 상당히 차이가 납니다.

• RDB: Lock 획득과 대기, Lock 해제 + Disk 쓰기(or WAL 기록) --> 수십 ~ 수백 마이크로초(µs) 소요

• Redis INCR: 메모리 연산 1회 --> 수백 나노초(ns) 소요

• (참고) 1 마이크로초 = 1,000 나노초

속도 차이가 100배~1000배 수준이라, 같은 수만 건을 처리할 때 RDB가 병목이 될 가능성이 더 큽니다.

물론 Redis도 감당 못 할 수준의 트래픽(초당 수백만 건 이상)이라면 뭔가 튜닝이 필요합니다.

0

안녕하세요, 인프런 AI 인턴입니다. portal.bj님.

좋아요 또는 조회수와 같은 단순 카운트 처리에서 Redis가 선호되는 이유에 대해 아주 좋은 질문을 주셨습니다. 실제로 이러한 카운트 작업에 RDBMS가 아닌 Redis를 사용하는 이유는 성능과 효율성에 큰 차이가 있기 때문입니다.

Redis 사용의 이유:

1. 메모리 기반의 데이터 저장소: Redis는 메모리 기반의 데이터베이스로, 데이터의 접근 속도가 매우 빠릅니다. 따라서 수많은 INCR 연산을 동시에 처리하는 데 있어 탁월한 성능을 보입니다.

2. 단일 스레드 모델: Redis는 단일 스레드로 작동하며, 이를 통해 데이터의 일관성과 동시성 문제를 효율적으로 해결합니다. 이는 특히 카운터처럼 잦은 갱신이 필요한 데이터에 유리합니다.

3. 부하 분산: RDBMS는 디스크 기반으로 동작하여 I/O 병목이 발생할 가능성이 있으나, Redis는 메모리에서 모든 작업을 처리하므로 이러한 병목 현상을 잘 관리할 수 있습니다.

4. 레이지 로딩 및 스냅샷: Redis는 데이터를 메모리에 올리고 주기적으로 스냅샷을 생성하여 비정상 종료 상황에서도 데이터 유실을 최소화합니다.

병목 현상에 대해:

INCR 명령어가 수만 개의 요청을 처리할 때 발생할 수 있는 병목 현상이 완전히 없는 것은 아닙니다. 하지만 Redis가 해당 연산을 처리하는 방식과 경량의 특성 덕분에 일반 RDBMS에서는 병목 현상이 날 상황에서도 보다 원활한 처리가 가능합니다. 저부하에서는 거의 문제없이 모든 요청을 소화할 수 있으며, 필요에 따라 샤딩(Sharding)을 통해 Redis 클러스터로 확장하는 방법도 고려할 수 있습니다.

질문하신 내용과 관련해 병목 현상 해결 방법 및 Redis 사용에 대한 더 많은 정보를 제공받을 수 있는 기존 질의응답을 확인해 보시면 유용할 것입니다:

• Redis Container 해킹: 이번 게시물에서는 Redis의 강점과 보안 설정에 관한 팁을 확인하실 수 있습니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.