[noSql]Redis
- DB
- 2020. 7. 30. 01:00
https://zdnet.co.kr/view/?no=20131119174125
그에 따르면 레디스는 인메모리DB라 빠른 속도가 강점이지만 큰 용량의 데이터를 담기엔 공간 제약이 크다. 그래서 실시간 처리는 인메모리에서, 보관은 디스크 기반 스토리지로 하는 구조가 성능과 효율을 함께 달성할 수 있다. 트위터, 인스타그램, 페이스북처럼 대규모 사용자 기반을 갖춘 인터넷 서비스 업체들도 이런 식으로 서비스를 설계했다는 설명이다.
레디스는 32비트 환경에선 최대 3GB 메모리만 사용 가능하고 64비트 시스템에서는 그런 제약이 없어 운영체제(OS)의 가상메모리(스왑)까지 쓴다.
캐싱 전략 - Look Aside ( = Lazy Loading )
캐시를 옆에 두고 필요할 때만 데이터를 캐시에 로드하는 전략이다. ( key-value 형태로 저장됨 )
- 데이터 가져오는 요청
- Redis에 먼저 요청 -> 있으면 반환
- 없으면 데이터베이스에 데이터 요청
- 이 데이터를 레디스에 저장
텍스트 위주의 데이터라면 가능할 수 있으나 차라리 Expire 시점을 짧게 설정하는 편이 더 나을 것이다. 이는 뒤에 또 다루겠다.
어쨌든 Redis는 별도 서버로 구축되어 주서버와 지속적인 서비스를 주고 받는 방법이 효과적이다. 요즘은 하나에 모든 것을 관리 운영하기 보다 각각의 기능, 필요에 따른 마이크로 서비스(Micro Service)
# CRUD에 따른 Redis 데이터 처리
! Read 요청시- 방문자, 사용자의 새로운 데이터 서버에 요청- Redis 서버에서 요청 데이터가 있는지 확인
- 데이터가 존재하는 경우 만료여부 확인 후 이 정보를 반환
- 정보를 반환한 경우 시간을 현재로 업데이트 후 종료
- 데이터가 만료되었거나 없는 경우 삭제 후 주 서버에 요청
- 주 서버에서 받은 데이터를 캐싱, 데이터베이스에 저장
- 이 값을 방문자에게 반환 후 종료
! CUD Create, Update, Delete 요청시이 경우 앞의 과정과는 조금 다르다. 그 이유는 데이터에 변화가 생겼으므로 해당하는 값의 데이터는 캐싱 값이 아닌 현재 실시간 정보를 보내주는 것이 효과적이기 때문이다. 캐싱 만료시간이 아무리 짧게 설정되어도 없는 데이터를 사용자가 보게되는 일으도록 해야할 것이다. 그러기 위해 필요한 조치는 비교적 간단하다. CUD 요청시 아래와 같이 처리한다.
- 방문자가 CUD를 서버에 요청
- CUD 요청을 주서버에 반영하여 업데이트
- 변경된 데이터 값을 캐싱데이터인 Redis에서 찾아 삭제 후 종료
여기서 가장 중요한 점은 캐싱을 제공하는 경우 단순하게 정보를 제공하는 주분만 고려하는 것이 아니라 다양한 상황에 대처해야한다는 점이다. 이 중 한 가지가 위와같이 CUD처럼 데이터에 중요한 변경사항이 있는 경우 기존의 캐싱 데이터를 삭제처리하는 과정이다.
'DB' 카테고리의 다른 글
Query Optimize ( Where절 순서, join 순서 ) (0) | 2022.06.26 |
---|---|
[DB] Lock (0) | 2020.07.29 |
인덱스란? (0) | 2020.07.29 |