안녕하세요 이미 커뮤니티에 올라온 글인데 제대로 이해를 못한 것 같아서요.redis를 사용할 때 기본적으로 메모리를 이용해 캐싱을 하고, AOF나 스냅샷을 저장하기 위한 용도로 SSD를 사용한다고 이해한 것이 맞을까요..? 강의 잘 듣고 있습니다 :) https://www.inflearn.com/community/questions/1400475/redis%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EC%A7%88%EB%AC%B8%EC%82%AC%ED%95%AD

안녕하세요 강의를 듣다가 잘 이해가 안가는 부분이 있어서 질문드립니다.비트맵을 사용할 때, 사용자 수가 100만명인데 실제 사용자 수는 100명인 경우 메모리 낭비가 발생한다는 부분은 이해했습니다.이를 위해 구분자가 있는 데이터를 지정하고 활용하는 것이 좋다고 말씀하셨는데 구분자가 있는 데이터가 어떤 것인지 제대로 이해가 안 가서 질문드립니다.. 섹션3 - BitMaps Collectionshttps://www.inflearn.com/course/redis-%EC%95%BC%EB%AC%B4%EC%A7%80%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EB%B0%A9%EB%B2%95-%EC%9D%B4%EB%A1%A0%ED%8E%B8/unit/244780

아키텍처 관련 설명하실때 듀퐁 라이터(?) 같은걸 열고 닫는 소리가 주기적으로나는데 생각보다 신경쓰여서요 다른 강의 예정이 있으시다면  영상 찍고나서 주변소음 관련해서 신경써주세요

강의를 들으며 공부하다 궁금한 점이 생겨 질문 드립니다.초반 부분에서 Redis는 RAM에 데이터를 저장한다고 말씀해주셨습니다.그리고 장바구니 구현 설명에서 set을 활용하여 쉽게 구현하는 방법을 설명해주셨는데장바구니라는 것이 담기만 하고 실제 구매로 이어지지 않을 수 있어 데이터를 계속 가지고 있어야 할 필요가 있는 반영구적인 기능이라 생각하는데, TTL 설정을 따로 하지 않는 식으로 구현하면 될지 궁금합니다.또한, 사용자가 늘어나면 늘어날수록 Redis, 즉 RAM에 저장되는 데이터 또한 늘어날 것이라 생각하는데 이와 관련하여 발생할 수 있는 메모리 문제 같은 것은 없는지 궁금합니다. 

현업에서의 부하테스트와 Ngrinder 사용에 대해 질문드립니다. 현업에서는 부하테스트용 서버(e.g. Stage 서버)를 두고 해당 서버에 부하테스트를 하는지, 아니면 로컬에 띄워두고 간략하게 테스트를 하는지 궁금합니다.Ngrinder를 어떤 서버에 설치하는지 궁금합니다.별도의 IDC 서버에 설치한 후, 팀 내 개발자가 모두 해당 Ngrinder를 사용해 부하테스트를 적용하는지, 아니면 Ngrinder는 로컬 컴퓨터(개인 노트북 등)에 설치 후 부하 테스트 대상 서버만 Stage 환경 등에 두고 해당 서버에 테스트를 하는지 궁금합니다.

강의의 내용중 3:35 즈음에인메모리 같은 ssd 같은 메모리를 사용을 한다고 하셨는데궁금증이 생겼습니다.ssd는 제가 알기로는 디스크로 알고 있는데메모리라고 하셔서 궁금하고,ssd를 언급하신 이유는 지속성 옵션 관련해서 말씀 하신건지이 두 부분이 궁금하여 질문 올려봅니다:)

안녕하세요. 강의 잘 듣고 있습니다 🙂. Vultr Payment로 등록할 카드가 알 수 없는 이유로 거절되고 있습니다. AWS EC2, RDS로 실습을 대체해도 문제가 없을까요?

안녕하세요? 끝까지 강의를 들었는데, 알차고 재미있는 강의였습니다. 강의를 보다보니 레디스를 사용해도 성능적인 차이가 많이 안나는 것을 보고 궁금한 점이 있어서 질문드립니다. 사실 주변에서 캐시로 레디스를 무조건적으로 사용을 하시는 경우를 많이 봤는데요, 제가 생각할때는 결국 I/O대기시간이 일반적인 api에서 큰 부분을 차지하고, 결국 레디스라는 것도 IO를 기다려야 하는 것은 동일하지 않나요? 그렇게 따지고 보면 강의에서 보여주신 것처럼 레디스를 사용하더라도 성능적 차이가 많이 안나는 경우가 꽤나 빈번할 것 같은데, 강사님의 의견이 궁금합니다. 레디스 내에서 해시값을 기반으로 데이터를 조회하는 속도야 빠르겠지만, 애초에 요청받았을 때 수행해야하는 [작업] 그 자체의 비중보다 [IO]를 대기하는 시간이 큰 경우가많은, 예를 들면 DB에서 단순히 레코드한줄을 조회한다든지 하는 기능이라고 하면 레디스를 쓰는 건 비용까지 고려했을 때 굳이 할 필요가 없는 선택처럼 느껴집니다.결국 레디스는 IO보다 요청에 따라 수행해야 하는 작업 그자체의 크기가 조금 클때 그제서야 유의미해 보이는데 어떻게 생각하시는지 의견이 궁금합니다! 추가로 강의 잘들었습니다. 혹시 다음 강의는 언제쯤 출시할 예정이신지 알 수 잇을까요?

안녕하세요? 강의쭉 잘 듣고 있습니다.강의에서 말씀해주시고자 하는 부분은 [IO대기시간이 있는 작업을 비동기로 돌려서 클라이언트쪽에 우선응답을 빠르게 주고, 나머지는 따로 알아서 처리하는 것]으로 이해했습니다. 말씀해주신 방법은 충분히 사용할 수 있는 방법이라고 생각합니다. 그런데 조금 논외로, 이렇게 분리하는 방식이 좋은 방향성인가?에 대해서 궁금증이 생기고 사실 이 부분에 대해 최근 현업에서도 꽤 고민하고 있어서 질문을 드립니다. 아무래도 쪼렙 주니어개발자다보니.. 이런 부분에서 부족함과 의문이 많이 있네요 ㅠㅠ 제 생각에, 단축 url을 만드는 api가 200을 내려준다고하면 저장까지 올바르게 완료됨을 전제해야한다고 생각합니다. 이렇게 생각하는 이유는, 단축 url을 저장하는 것까지가 일종의 핵심적인 로직에 포함되지 않나? 하는 생각입니다. 예를 들어 로그를 찍거나, 혹은 비즈니스로직이여도 그렇게 중요하지 않은 부분이라면 마음편하게 완료를 보장하지 않는 async로 돌려도 될것 같습니다.하지만 url저장처럼 핵심적인 로직에 관한 부분에 대해서는 200을 내려줄 거면 저장도 올바르게 보장되어야 하지 않나? 하는 생각이 듭니다. 다르게 말하면, 내려준 단축 url이 정상적으로 동작하지 않는데 200을 내려줘도 되나? 에 대한 궁금증입니다.(물론 핵심적인 로직에 대한 판단은 개개인마다 또 상황마다 다를 수 있지만요) 결론적으로 여쭤보고 싶은 부분은 아래와 같습니다1) 비동기로 나누는 부분의 기준이 강사님에게 있으실 것 같은데, 보통 어떤 기준으로 나누시나요?2) 추가로, 핸들링을 어떤식으로 하시는지도 궁금합니다. 예를 들면 위와 같이 저장하는 로직을 비동기로 뺏을 때, 실패한다면 보통 어떤식으로 핸들링을 하시나요?

Slack에 올라온 질문이 좋아서 인프런 커뮤니티에도 공유드립니다.

레디스 데이터 타입 별 사용방법 많은 도움이 되었습니다. 그러다 궁금한것이 있습니다. Q. 사이드 프로젝트로 쇼핑몰을 만드려고 합니다 프론트: 리액트 벡엔드 api서버: 스프링부트2.8 api서버에 레디스를 연결해 최근 검색어 캐싱 + 구매에 의한 재고 감소 동시성 처리를 하려고 합니다. 이때 벡엔드 api 서버(스프링부트)에 레디스를 연결하는게 맞나요 아니면 별도의 서버를 하나 더 구축해 레디스를 연결하는게 맞나요?? 사이드 프로젝트인 상황에 맞게 어떻게 하는게 바람직한지 궁금합니다

인덱스를 걸때 카디널리티 수치를 확인해 높은 컬럼을 인덱스로 설정하라고 강의에서 들었습니다. 이에 궁금한 점이 몇가지 있습니다.Q1 : WHERE 절에 검색조건으로 사용되는 컬럼이 5가지라고 가정하면 가장 카디널리티가 높은 컬럼 1개만 인덱스로 걸어야 하나요?? 아니면 카디널리티가 높은 순서대로 묶어서 하나의 복합 인덱스를 만들어 주어야 하나요?? 차이점이 궁금하고 어떤 방식이 더 나은 방식인지 궁금합니다 Q2 : WHERE 절에 사용되는 검색조건인 컬럼 한개가 있다고 가정했을때 해당 컬럼의 카디널리티 수치가 낮더라도 인덱스를 만드는게 낫지 않나요? Q3 : Mysql의 경우 범위검색의 경우 B-Tree 인덱스를 사용한다고 알고있습니다 . 강의에서 만든 인덱스도 날짜이고 범위검색이니 B-Tree 인덱스를 사용한거 같습니다. 정확한 일치 검색의 경우 해시 인덱스를 사용할 수 있다고 들었습니다. 이때는 인덱스를 만들때 코드를 어떻게 써줘야 해시 인덱스를 만들 수 있나요?

안녕하세요. 현재 프로젝트를 디벨롭하려고 수강한 학생입니다.현재 자바17버전을 사용하여서 프로젝트를 완료하였고 ngrinder에서 스크립트를 사용하기 위해 11버전으로 낮추었는데 프로젝트 코드의 많은 부분을 수정해야해서 17버전을 사용해서 적용할 수는 없을까요?

Rate Limiter 강의 그림으로 된 예제에 대해 질문있습니다!트랜젝션 시작을 알리는 "MULTI" 명령어 이후 "EXPIRE 1.1.1.1:10 60 / EXEC" 코드가 있습니다! 제가 잘못 이해한 걸 수도 있지만, 이렇게 하면 요청마다 만료 시간이 다시 1분으로 초기화되는 것이 아닌지 궁금합니다. 그러면 1분 안에 요청 수를 제한하는 것이 아니라 1분 안에 요청이 없으면 만료되는 형식이 될 것 같은데 제가 생각한 것이 맞을까요?

사용자가 온라인 된 경우 1로 bit를 업데이트 하고이후에 통신이 되지 않으면 비트값이 추가로 업데이트 되지 않는다 설명하셨는데그 사이에 어떤 동작으로 통신이 되지 않는지 여부를 확인하는지, 비트는 어떻게 처리되는지에 대한 설명이 없어 이해가 어렵네요.매 분마다 요청이 온다는 가정하에 비트값을 매분마다 1씩 업데이트 하는데, 해당 요청이 없어서 비트값이 더 이상 업데이트 하지 않게 되면, 해당 시간만큼 오프라인 상태였다이 시나리오가 맞을까요?그렇다면 서버에서 임의의 시간, 예시로 3분 이상 미 접속시 오프라인이라 평가하여 커뮤니티 웹, 온라인 게임이나 채팅 등의 사용자의 온라인 여부가 필요한 서비스에서 해당 값을 참고하여 특정 시간에서 부터 bit 증가가 없다면 오프라인이라 평가하게 된다고 보면 될까요?그런데 이렇게 하면 시:분으로 시작하는 key로 부터 bit는 접속하게 되는 분 단위가 되는거고, 다른 사용자가 이 사용자의 온라인 상태를 알고자 한다면, 현재 시간에서 key와 bit를 연산한 시간을 비교해야 온라인인지 여부를 알 수 있게 되는건데 제가 이해하고 있는게 맞는지 알고 싶습니다.

해당 클래스의 주된 내용은 동시 로그인 제한으로 이해를 했습니다.그런데 설명을 해주시는 부분에 있어서 set-cookie 부분에서 부터 이해가 잘 되지 않네요.먼저 설명 부분에 있어서set-cookie로 session id를 보내고갑자기 결제가 필요한 유료 api에 접근을 요청하고redis의 캐시에서 해당 유저가 프리미엄 등급임을 확인하고유료 api 요청을 처리한다 하셨는데동시 로그인 제한이라면 pc나 모바일 등 여러 장비에서 접속하는 session의 처리를 의미하는거라 생각이 됩니다.그리고 redis의 캐시로 프리미엄 등급을 확인한다는것도 이해가 되지 않는게 해당 데이터는 캐시로 다뤄질 데이터가 아니지 않나요?초반 설명하셨던 동시 로그인 제한이란 소주제의 목적이다이어그램을 통해 설명한 내용과 다른것 같습니다.혹시 제가 이해한게 잘못된 것인지 알고 싶습니다.n(로그인 세션)

1.1.1.1:10 으로 key가 만들어 졌을 때, 만료가 11분이 되는건가요?설명에는 10분에서 11분까지로 알려주시던데20이라는 요청 제한 수는 프로그램에서 관리하는 수가 되는거죠?다이어 그림에 expire 1.1.1.1:10 60 / exec 의 의미는 무엇인가요?

ZRANGE points 0 -1 REV WITHSCORES위 명령어를 입력하면 ERR syntax error가 발생합니다.gpt로 확인하니 ZREVRANGE points 0 -1 WITHSCORES를 제시해주고결과도 역순으로 출력이 됩니다.rev 지원이 안되는거 같은데 버전의 차이 등의 이슈가 있는 것인지 알고 싶습니다.

안녕하세요.  강의를 잘 보고 있는 와중에 온라인 상태 표시 관련한 궁금증이 생겨서 질문을 남기게 됐습니다. (※ 다른 분이 남겨주신 온라인 상태 표시 질문 글도 읽었습니다.) Bitamps의 장점은 하나의 key에서 offset을 사용하여 값을 비트별로 나눠서 읽고 쓰기 때문에 적은 메모리와 빠른 비트 연산을 제공한다고 생각이 되는데요.올려주신 예시를 보면 key는 계속해서 바뀌고 있고, offset도 전혀 사용하지 않는 것 같습니다.해당 상황에서도 일반적인 Strings 대신에 Bitamps를 쓰신 특별한 이유가 있는지 궁금합니다.   

다른 질문을 보니 www.nate.com으로 시도해보라하여 했지만 똑같이 되지 않습니다. Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during conversion: Unsupported class file major version 61 java.lang.IllegalArgumentException: Unsupported class file major version 61 Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during conversion: Unsupported class file major version 61 java.lang.IllegalArgumentException: Unsupported class file major version 61