다른 데이터 타입이 아닌 해시를 쓰는 이유가 무엇인가요?string도 있고 json도 있는데 선정하신 이유가 궁금합니다.

개인블로그에 인강 내용이나 자료개인적으로 정리하고 싶은데 괜찮으신지 문의드립니다. 출처는 남길 예정입니다.

이미 레디스 cli가 띄워져 있다고 해서요..

도커 컨테이너 > 레디스 서버 내에서 redis-cli 실행 후, BF.MADD 명령어를 실행하면, 아래와 같이 잘 실행됩니다.그러나, 외부(JDBC) 커낵션을 통한 접속에서는이처럼 명령 실행을 전혀 할 수가 없습니다.(BF.XX 명령어를 제외하고, 이전 강의내용의 명령어는 잘 실행됩니다)이걸 해결해보려 시도해본 것은 아래와 같습니다.docker-compose.yml 볼륨마운팅 설정/redis-stack.conf 파일 내용의 변경 부분:bind 0.0.0.0protected-mode nodocker-compose.yml 내용입니다.version: "3.8" services: redis: image: redis/redis-stack-server hostname: redis container_name: redis-stack-server command: /entrypoint.sh ports: - "6379:6379" volumes: - ../redis/conf/7.2.conf:/redis-stack.conf restart: always networks: - redis-network networks: redis-network: driver: bridge외부접속에서 명령 실행을 막는 기능을 어떻게 해제할 수 있을까요?

Multi 사용시 key 나 로그인한 세션에 lock 이 걸리진 않나요? 트랜잭션이 유지되는 시간이 있나요? 무한정 트랜잭션이 끝나길 기다리진 않을 것 같습니다.

예시 그림을 보면 새로운 요청을 add할때 ZADD 1.1.1.1 1693494130 1693494130 형식으로 add를 하던데 이러면 혹시 동일한 timestamp에 여러번 요청이 올 경우는 어떻게 구분하나요? 가령 1693494130에 3번의 요청이 동시에 발생한다면 스코어는 1693494130로 하고 item을 1693494130_0이런식으로 index를 추가해야할 것 같아서요

코드단에서 바라봤을 때, JSON Strings를 활용하면 약간의 메모리 낭비나 매번 JSON 전체를 불러와야 한다는 단점이 있지만 객체가 중첩될 경우 사용할 수 없고, 저장 및 불러오기 방식도 다소 번거로운 Hashes 데이터 타입을 굳이 사용할 이유가 있는지 잘 모르겠습니다..

안녕하세요. 강의 잘 보고 있습니다. LIST, Set, ZSet의 item을 정렬하여 반환하는 SORT 명령어의 시간 복잡도가 O(N)이라고 설명해주셨는데, 어떻게 O(N)이 나온건지 궁금합니다.

SET inflearn-redis:ko:price 200 은 어떤 명령어 인가요?OK 가 뜨긴 했는데다시 get inflearn-redis 해도 전이랑 변함 없이{\"price\":100,\"language\":\"ko\"} 가 리턴이 되서요asdf

@Entity내에서 one to one, many to one 등등 과 같은것들도 쿼리가 발생하자나요근대 이부분에 대해서 Cacheable을 적용할 방법은 없나요?찾아도 없는거같아서 문의드려봅니다 

logout과정에서 질문이 있습니다. 로그인을 할때 서버에서 클라이언트로 res .cookie("x_auth", user.token) .status(200) .json({ loginSuccess: true, userId: user._id });이렇게 json 형식으로 성공여부와 user_id값을 보냅니다. 로그아웃을 할때는 axios로 /api/users/logout" 에 요청을 보내기만 합니다. 그리고 server는 req로 user_id값을 받아서 로그아웃을 진행합니다. client에서는 userid를 보낸적이 없는데 서버는 어떻게 req를 통해 user_id에 접근할 수 있나요? client는 로그인시에 서버에서 json으로 데이터를 받았는데 이것은 어디에 저장되는 것인가요? 또한 저장되는 공간은 누가 정하게 되는 것인지 궁금합니다. 스토리지 종류가 여러가지 인데 말이죠.확인해보니 local storage, session storage, lndexeddb등은 다 비어있고 쿠키에만 x_auth가 저장되어있습니다. 음... 브라우저가 알아서 보내주는 건가요..?

ssr 적용한 페이지가 a.js 페이지라고 가정 한 후 a.js에서 b.js 간 후 뒤로가기 버튼을 누르면 a.js로 와질때 cache가 안먹던데 next.js 공식 문서들어가서       context.res.setHeader(         'Cache-Control',         'public, max-age=100, s-maxage=100, stale-while-revalidate=100'     ) 이런식으로 넣으면 캐싱이 된다는데 안되더라고요 혹시 이런 이슈에 대해서는 어떻게 생각하시는지 궁금합니다.

Nextjs 프로젝트를 배포했습니다. index.js에서 getServerSideProps()로 데이터를 가져와 next build 시에 index.html은 생성되지 않았습니다! Express로 next routing을 연결해 페이지가 보이도록 하고 있으며 pm2 로 무중단배포 중에 있습니다.!   메인 페이지에 접속했을 때 나타나는 페이지의 html 내용을 추출해 캐시파일로 생성하고 싶습니다. .  Express로 구현이 가능할지 궁금합니다!

안녕하세요. 해당 강의를 수강중인 김승수라고 합니다. 항상 좋은 강의를 제공해주심에 감사드립니다.   이번 강좌에서 Cache-Control: no-cache 부분을 들으며 이것을 사용하는 실제 사례가 궁금해서 문의드립니다.   Cache-Control: no-cache는 데이터를 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용해야한다고 설명들었습니다. 내용 자체는 이해가 가능하나 이 방식이 사용되는 실제 사례가 궁금합니다.   만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높으나, 데이터 자체의 크기가 커서 변경이 일어나지 않은 경우에는 데이터를 다시 가져오는 부하를 줄이기 위해 사용하는 것일까요? 만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높다면, 캐시 유효 시간을 짧게 설정하면 될 것인데... no-cache를 왜 만들었을까요? 캐시로 관리하는 데이터가 원 서버의 실제 데이터와 동일한지 매번 검증한다면 이 작업 자체도 오버헤드라고 볼 수 있지 않을까요? 아니면 드물게 사용하는 매우 큰 데이터를 캐시에 두고 캐시 유효 시간을 길게 가져가기 위해 사용하는 것일까요? 캐시 자체는 빈번하게 조회할 데이터를 빠르게 가져오기 위해 조회 데이터를 가까이 두는 기술로 알고 있는데요. 드물게 사용할 데이터를 캐시에 보관하는 것도 이상하다고 생각됩니다.   강사님의 답변 기다리겠습니다. 감사합니다.   김승수 드림

강의 잘 듣고 있습니다! 이번 강의 3:30 쯤에서 말씀하신 내용인데, 이전에도 다뤘지만 캐싱되는 방식이 애매하여 질문드립니다. 1. `COPY package.json ./` 과정이 생략된 경우 - 빌드 할 때마다 의존성 설치가 이뤄지는 것은 이해가 갑니다. 2. `COPY package.json ./` 과정이 추가된 후 `npm install` 을 실행한 후, `COPY ./ ./` 를 실행하는 경우 - 제 생각에는 npm install을 실행하는 시점에서 컨테이너의 working directory 에는 package.json 하나만 있는데 파일에 변경이 없으니 캐싱된 데이터(node_modules, package-lock.json)를 가져와서 복사해서 넣어준다. - 여기까지 수행하면 의존성이 설치된 상태이니, 나머지 모든 파일들을 복사해서 넣어준다. 다만 여기에는 package.json 이 겹치는 파일이나, 내용에 차이가 없기 때문에 문제가 발생하지 않는다. 위 작성한 내용 중 제가 잘못 이해한 부분이 있다면 지적해주시면 감사하겠습니다. 항상 감사합니다 :-) + 추가로 든 의문인데, 캐싱된 데이터는 이전에 생성했던 컨테이너에서 가져오는 걸까요?