보통 read가 자주 발생하는 데이터들을 캐싱하면서 성능을 높이는 방법이 있잖아? 살짝 워킹셋 느낌으로
근데 redis로 캐싱하는 사례만 들어본거같아서. 서버 인메모리나 rdb에 캐시 테이블을 두면 안되나?
혹시 실무에서도 이 방법이 사용될 수도 있으려나?
그냥 생각으로는 장단이 있을거같은데 서버 인메모리를 썼을 때는 메인 서버의 메모리를 캐시에 써야한다는 점 정도? 서버가 다운되도 write 되는 쿼리는 없으니깐 문제는 없을거같고
rdb 테이블에 두는건 비용도 낮고 좋은거같은데. 메모리보다 접근속도가 느리긴하겠지만 캐싱하는 목적이 메모리의 접근속도 이점을 목표로 하는건 아니니깐
근데 redis로 캐싱하는 사례만 들어본거같아서. 서버 인메모리나 rdb에 캐시 테이블을 두면 안되나?
혹시 실무에서도 이 방법이 사용될 수도 있으려나?
그냥 생각으로는 장단이 있을거같은데 서버 인메모리를 썼을 때는 메인 서버의 메모리를 캐시에 써야한다는 점 정도? 서버가 다운되도 write 되는 쿼리는 없으니깐 문제는 없을거같고
rdb 테이블에 두는건 비용도 낮고 좋은거같은데. 메모리보다 접근속도가 느리긴하겠지만 캐싱하는 목적이 메모리의 접근속도 이점을 목표로 하는건 아니니깐
실제로 RDB도 인메모리 테이블이라는 기능도 지원하고 그냥 테이블의 데이터들도 메모리에 캐싱해서 사용함 - dc App
그래서 서비스 규모가 커질수록 메모리 자원할당에 대한 세심한 관리가 필요한데 이를 위해서는 - Adhoc 쿼리를 최소화 (실행계획 가짓수 줄이기) - 예상행 최적화 (실행계획에 필요보다 많은 메모리 할당 줄이기) - 스풀링 최적화 (메모리를 사용하는 플랜내 임시테이블 연산 줄이기) - 임시테이블 줄이기 등등이 있음 - dc App
디스크에서 읽는걸 피지컬io 메모리에서 읽는걸 로지컬io 라고하고 피지컬io비율이 높으면 높을수록 성능도 관리도 엉망인 DB - dc App
아 테이블 설계시 레코드의 크기를 타이트하게 하는것도 메모리관리에서 이점이 있을듯 - dc App
rdb메모리캐싱은 내부최적화용도 아니였어? 레디스는 캐시데이터를 통으로 쓴다는 느낌으로 알고있는데 그리고 결국 db의 성능을 위해서라도 외부캐시 사용은 결국 일어나는거 아니야? - dc App
내부캐시 외부캐시???란 용어를 내가모르는 건지 없는단어인건지 모르겠지만 여튼간에 실제로 데이터가 메모리에 캐시되어서 해제되기전까진 메모리의 데이터를 읽음 - dc App
아 미안 외부=redis 여기선 내부가 rdb - dc App
밑에 주딱용어는 결국 쿼리최적화 목적이고 redis는 빈번하는 데이터접근? 아 뭔가 말이같은데 . .좀따 질문할게 - dc App
미안 운체하다왔음.. 근데 결국 rdb도 메모리를 이용해서 캐싱을한다면 redis의 도입은 어떨때하는거야? 레디스의 주 목적이 캐싱으로 생각하고 있었는데 . .다중으로 메모리를 점유한다는건 그런 손해를 보더라도 redis를 도입하는 이유가 있을텐데.. - dc App
사실 그 늬앙스가 다른느낌인것같은데 정확히 모르겠음 - dc App
본인이 Redis를 사용까지는 안해봤지만 알기로는 RDB에 비해 동시처리 성능이 매우 뛰어나서 대규모 서비스나 실시간 서비스가 런타임일 동안 RDB에 저장될 필요 없는 휘발성 데이터들 혹은 거쳐갈 데이터들을 주로 Redis로 굴리는걸로 암 (ex - 게임, 채팅 등등) - dc App
https://naver.me/x7nLpQwz
스택오버
플로운데 네이버 링크로
랩핑됬네;; - dc App
댓글타고타고 들어가니 엄청자세한거있네 ㄱㅅ - dc App
redis는 단순한거야 작고 빠른 메모리 기반 저장소 rdb 메모리 캐시보다는 비교할 수 없이 크지만 rdb 데이터 저장소보다는 매우 작지 영속화도 돼서 휘발성 데이터가 아닌 정규 데이터용으로도 많이 씀
오랫동안 많이 읽는 데이터를 아예 redis에 계속 상주시키기도 하나보구먼 - dc App
그리고 내가 말한건 쿼리 최적화가 아니야 그렇게 치면 redis도 쿼리 최적화임 ㅋㅋ redis나 집계테이블이나 cqrs는 빠른 응답이라는 단 하나의 목적으로 귀결돼 redis로 감당이 안될 규모거나 가성비가 도저히 안나올때 선택하는 것이지
mysql jdbc 환경에서 커넥션풀 이슈에 대응하려고 redis를 쓰기도 해
서버 인메모리 저장도 자주 쓰이는 방법인데, 동기화 이슈가 존재해 서버를 여러개 띄웠을때 각각 캐시 타이밍이 다르면 조회되는 데이터도 달라질 수 있지 매우 짧은 시간동안 어긋나는건 괜찮은데, 길어지면 문제가 되지 동기화를 할 수는 있는데 구조가 좀 복잡해짐 그대신 분산 환경에서 redis 같은 중앙집중 캐시에 부하가 집중되는걸 막을 수 있음
와...블로그 읽다가 그냥 흠 그럼 실시간으로 write관련으로 쓰면좋을것같고 단순 read가많다면 굳이 비싼메모리를 쓸 필요없지 단순생각만했는데.. 커넥션풀같은 상황은 솔직히 예상도 안되고, 동기화 이슈같은것도 생각해서 쓰임새가 존재하군요 - dc App
대규모 서비스면 RDB에서 커넥셩 풀링도 빡빡할테니까 신박한 활용처네 생각도 못해봤다 - dc App
서버가 여러대이고 캐시동기화 문제해결로는 블로그에도 나오는구나.. 흠 결국 이러한 선택들이 우리가 공부하고 시니어로 깊어져가는 고민들인가 - dc App
비싼 메모리 쓸 이유는 있지 빠르니까..
애초에 그냥 99%의 서비스가 read가 중요한대 거기에 메모리 안쓰면 딴데쓸곳도없음 - dc App
예를 들어 홈 api는 db 쿼리가 여러개 날아가는데, 데이터는 매우 자주 안바뀜 대부분의 유저가 같은 데이터를 봄 이런 경우에 redis 질의 한방이면 1-2ms만에 서빙 가능하고 메모리도 얼마 안먹음 db로 하면 쿼리 횟수에 따른 응답 시간 증가에 풀 점유 시간이 길어지는 사이드이펙트까지..
이걸 한방쿼리 가능한 db테이블 하나로 놓자니 스키마 바뀌는거 관리가 골치아픔.. redis면 그냥 키 버전 올리면 그만
명확한 redis이점이군요..좋은 답변 정말감사합니다 - dc App
RDB에도 내부적으로 캐시 있어
우린 그걸 집계컬럼, 집계테이블, CQRS라고 부르기로 합의했어
근데 이건 자주사용되는거랑은 결이 좀 다르긴 하지
자주 사용되는거여야 집계컬럼, 집계테이블, aggregate 된 데이터로 만드는거니까 완전히 다른건 아니려나
다들 감사합니다 댓글 다 읽는데 1시간 걸렸어요.. 궁금증만 늘어난거같긴한데 더 공부하고 올게요..
궁금했던건 해결됐는데 궁금한게 더 많아짐 ㅇㅇ..
좋은 현상 꼬리에 꼬리를 무는 의문점을 하나하나 해결해나가는게 실력 좋은 개발자가 되는길 - dc App