Redis 의 모든 자료구조는 Key-value 형식입니다. 저장과 조회는 key를 기준으로 합니다.
Key 는 binary sequence 로 binary-safe (키가 어떤 종류의 데이터를 포함하더라도 손실 없이 저장될 수 있음을 의미합니다.) 합니다.
즉, string(empty string포함) 이나 어떤 파일을 binary로 변환한 값이나 상관이 없습니다.
앞에서부터 byte단위로 비교합니다.
Key 설계와 관련해서 다음과 같은 것을 고려해야합니다.
Key의 길이(크기)가 크다면, 메모리를 더 많이 차지할 뿐만 아니라, key 비교 연산 등에서도 비용이 많이 듭니다.
예를 들어 10글자라면 워스트 케이스 같은 경우 열 번째에서 비교해서 찾겠죠. 만약 10000자리라면 비용이 더 많이 듭니다.
Key의 최대 사이즈는 512MB 입니다.
하지만 Key의 크기는 1K(1024bytes)가 넘지 않도록 하는 것이 좋습니다.
Key에 사용되는 데이터가 크다면, hashing을 통해서 key의 unique함을 보장하면서도 특정 길이로 줄이는 방법을 추천합니다.
대표적인 방식으로 SHA1(160bit, 20bytes), SHA256(256bits, 32bytes) 등을 추천합니다.
Avoid long key 가이드를 따르기 위해서 일부 사용자는 너무 짧은 키를 고안합니다.
예를 들어서 user:1000:followers(user id 1000 사용자의 follower를 저장하는 자료구조) 를 표현하기 위해서 u1000fw와 같은 식으로 줄이는 경우입니다.
이는 메모리를 조금이라도 더 적게 사용하기 때문에 좋은 선택같아 보입니다.
하지만 크게 차이가 없고, 비교연산 등에서도 큰 차이가 없습니다.
하지만 줄인 key 의 의미를 파악할 수 없는 경우 개발, 운영 과정에서 버그나 문제를 야기할 수 있습니다.
이것은 성능보다 더 큰 문제를 야기할 수 있습니다.
또한 의미를 알아보기 힘든 축약어로 한 자료구조의 키를 설계하면, Redis 클러스터를 이용하는 경우 key의 분산을 위해서 다른 키도 이와같이 설계해야 합니다.
MySQL의 스키마 안에 테이블이 있고 몽고디비도 database 안에 Collection이 있었습니다. 하지만 Redis는 이 같은 논리적인 단위가 없습니다. 모두가 key-value입니다. 그래서 분산할 때 전체 키를 대상으로 합니다. 특정 대상은 줄이고 어떤 건 풀어서 한다면 데이터가 편층될 수 있습니다.
그렇지 않으면 데이터의 분산이 골고루 이루어 지지 않고, 클라이언트의 요청이 한 노드에 몰려서 부하가 분산이 되지 않기 때문입니다.
여러 종류의 키를 이런식으로 설계하면 결국에는 어떤 키가 어떤 의미인지 따로 문서 등이 없다면 알아보기 힘들게 되고, 이것은 심각한 버그나 문제를 야기할 수 있습니다.
따라서 Key가 사이즈가 크지도 않은데 일부러 축약어 등으로 과도하게 줄이는 것은 바람직하지 않습니다.