Redis를 처음 사용하거나 사용 가능한 기능을 다시 살펴보고 싶은 경우 이 가이드는 Redis가 제공하는 모든 데이터 구조를 이해하는 데 도움이 될 수 있습니다.
올바른 구조 선택
Redis 데이터 구조는 간단합니다. 그 중 어떤 것도 해결하려는 문제에 완벽하게 일치하지 않을 수 있습니다. 그러나 데이터에 적합한 초기 구조를 선택하면 Redis 명령이 필요한 것을 얻을 수 있는 효율적인 방법으로 안내할 수 있습니다. 많은 Redis 명령에는 작업할 기본 데이터 구조의 유형을 나타내는 접두사가 있습니다.
범용 데이터 구조
| 접두사 | 용도 | 주의 사항 및 일반적인 오용 | |
|---|---|---|---|
| 해시 | ㅎ | 객체 스토리지; 딕셔너리 객체를 사용할 수 있는 모든 것 | Redis 자체와 마찬가지로 사용자가 Hashes에서 직면하는 가장 큰 문제 중 하나는 키 계정입니다. 필요하지 않은 키와 값으로 해시를 채우지 않도록 시스템을 갖추고 있는지 확인하십시오. |
| 목록 | 엘 | 대기열, 스택 및 순환 목록 | 큰 목록에 대해 임의 액세스를 시도하지 말고 대기열 백업에 주의하십시오. |
| 설정 | S | 태깅 시스템, 시계열 데이터 버킷 | 교집합과 합집합은 주의해서 사용해야 합니다. 집합을 작게 유지하십시오. 세트는 고유한 수를 계산하는 가장 좋은 방법이 아닙니다. 대신 HyperLogLog를 사용하십시오! |
| 정렬된 집합 | Z | 스코어보드, 사전 검색, 랜덤 액세스 목록 | Zset은 가장 다재다능한 구조 중 하나이자 가장 비싼 구조 중 하나입니다. 당신의 큰 O를 면밀히 주시하십시오! 자동 완성을 위해 정렬된 세트를 사용하는 경우 사전 검색을 처리하는 ZRANGEBYLEX를 조사할 수 있습니다(그러나 UTF-8에 주의하십시오!) |
| 스트림 | X | 시계열, 대기열, 메시지 배포 | 스트림을 캡핑하지 못하는 것은 일반적이며 분산 메시징 시스템(특히 Apache Kafka)의 기능과 혼동되기도 합니다. |
| 문자열 | (없음) | 간단한 캐시, 카운터, 비트 조작 | 매우 큰 값에 주의하십시오. GETting 또는 SETting은 특정 네트워크 및 Redis 클라이언트에서 찾기 힘든 오류를 유발할 수 있습니다. SETNX를 사용하여 잠금 시스템을 구축하면 부상을 당하기 쉽습니다. |
특수 데이터 구조
Redis는 특정 유형의 특수한 경우를 조작하기 위한 여러 작업을 제공하지만 "under-the-hood" 유형은 위의 범용 데이터 유형 중 하나입니다.
| 접두사 | 기본 유형 | 용도 | 주의 사항 및 일반적인 오용 | |
|---|---|---|---|---|
| 비트맵 | 비트 | 문자열 | 분석을 위한 공간 효율적인 플래그 | 기능에 대한 혼란 또는 비트맵 기반 시스템에서 회계의 복잡성을 놓치고 있습니다. |
| 카운터 | 증가, 감소 | 문자열 | 공간 효율적인 분석 | 64비트 부호 있는 범위의 오버플로는 오류를 반환합니다. |
| 지오해시 | 지역 | 정렬된 집합 | 매장 찾기, 주변 사용자 찾기 | 장거리 계산, 전문적인 예측 또는 정교한 지리학적 기능이 필요한 모든 곳. |
| HyperLogLog | PF | 문자열 | 분석을 위한 고유 항목 계산 | 여러 HLL을 병합하는 것은 비용이 많이 들 수 있습니다. PFMERGE에 지정하는 매개변수 수에 제한이 있는지 확인하십시오. |
| 게시/구독 | 펍, 서브, PSUB | (없음) | 임시 메시지 전달 | 내구성이 없는 간단하고 빠른 메시지 전달. 스트림 유형은 대부분의 사용 사례에서 더 나은 선택입니다. |
귀하의 큰 O를 사용
데이터 구조의 액세스 패턴을 오용하는 것은 사전을 오용하는 것과 같습니다. 단어를 찾기 위해 모든 페이지를 넘기지 마십시오! 모든 Redis 명령의 시간 복잡도는 redis.io에 문서화되어 있습니다.
Big O는 어떤 것이 수행되는 방식에 대한 "제한적인 행동"을 표현하는 방법입니다. 간단한 사고 방식은 시스템의 데이터 양이 증가함에 따라 작업이 수행되는 방식입니다. 작업이 O(1)인 경우 관련 데이터의 양에 관계없이 완료하는 데 일정 시간이 걸립니다. O(n) 연산은 데이터에 따라 선형으로 확장되고 isO(n²) 연산은 데이터 양이 증가함에 따라 기하급수적으로 느려집니다.
보다 철저한 처리를 위해 샘플 코드와 그래프가 포함된 Big O에 대한 쉬운 소개를 참조하십시오.
좋은 시스템 디자인은 기본적인 알고리즘 분석보다 더 많은 것을 필요로 하지만, 때때로 기본 사항을 복습하고 앱에서 데이터 액세스의 전체적인 복잡성에 대해 생각해 볼 가치가 있습니다.
작은 운영
Redis는 단일 스레드이므로 추론하기 쉽지만 다중 스레드 데이터 액세스에만 익숙한 사람들에게 약간의 놀라움을 줄 수도 있습니다. Redis에서는 다른 데이터베이스보다 장기 실행 작업이 더 위험합니다. 시간, 장기 실행 작업으로 인해 시스템 전체 백업이 발생할 수 있습니다.
데이터 액세스 작업을 매우 세부적으로 유지하는 것이 Redis의 우수한 성능을 위한 핵심입니다. Redis에서 100,000 O(1) 작업은 100,000 요소 컬렉션에서 1 O(N) 작업보다 더 나을 수 있습니다. 비록 네트워크 및 프로토콜 구문 분석으로 인해 벌금을 지불해야 하지만
시스템의 문제점을 어떻게 찾을 수 있습니까? SLOWLOG를 정기적으로 확인하십시오(또는 RedisGreen 고객인 경우 대시보드의 "Slow Queries" 탭을 확인하십시오). 단일 작업이 오래 실행될수록 시스템이 수행하려는 다른 모든 작업의 속도가 느려지므로 짧게 유지하세요!