Redis로 애플리케이션을 개발하는 것은 매우 재미있지만 다른 기술과 마찬가지로 Redis 기반 또는 Redis 네임스페이스 애플리케이션을 디자인할 때 염두에 두어야 할 몇 가지 사항이 있습니다. 당신은 이미 관계형 데이터베이스 개발에 익숙할 것입니다. 그러나 많은 동일한 사례가 적용되지만 Redis는 메모리 내 데이터베이스이고 (대부분) 단일 스레드라는 점을 명심하십시오. Redis 키 모범 사례를 살펴보려면 계속 읽어보세요.
따라서 Redis를 사용할 때 주의해야 할 몇 가지 특성이 있습니다.
1. Redis 네임스페이스로 키 추적
데이터베이스는 데이터를 저장하지만 모든 개발자는 Redis에 넣는 데이터 중 일부를 추적하지 못할 수 있습니다. 애플리케이션의 요구 사항이 변경되거나 데이터를 저장하는 방식이 변경되기 때문에 이는 자연스러운 현상입니다. 일부 키를 EXPIRE하는 것을 게을리했거나 애플리케이션의 모듈이 사용 중지되었을 수 있습니다.
어떤 경우이든 Redis 데이터베이스의 일부 데이터가 더 이상 사용되지 않고 목적 없이 공간을 차지할 가능성이 있습니다. Redis의 스키마가 없는 특성으로 인해 키에 대한 확실한 명명법을 사용하지 않는 한 데이터 세트의 내용을 이해하기가 매우 어렵습니다. 키에 대해 Redis 네임스페이스와 함께 적절한 이름 지정 방법을 사용하면 데이터베이스를 훨씬 쉽게 관리할 수 있습니다. 애플리케이션 또는 서비스별로 키의 이름을 지정할 때 - 규칙은 콜론(':') 문자를 사용하여 키 이름의 일부를 구분하는 것입니다. Redis 네임스페이스 모범 사례. 이렇게 하면 데이터 마이그레이션, 변환, 삭제 또는 이동 중에 쉽게 식별할 수 있습니다. Redis 네임스페이스 및 Redis 네임스페이스 키는 이 식별에 도움이 됩니다.
Redis 네임스페이스 외에도 Redis의 또 다른 일반적인 사용 사례는 "핫" 데이터 항목에 대한 보조 데이터 저장소인 반면 대부분의 데이터는 다른 데이터베이스(예:PostgreSQL, MongoDB)에 보관됩니다. 이러한 경우 개발자는 기본 데이터 저장소에서 데이터를 이동할 때 Redis에서 데이터를 제거하는 것을 잊는 경우가 많습니다. 이러한 종류의 데이터 저장소 간 종속성에는 계단식 삭제가 필요하며, 이는 Redis 세트의 지정된 데이터 항목에 대한 모든 식별자를 유지하여 구현할 수 있습니다. 이렇게 하면 기본 데이터 저장소에서 삭제된 후 호출된 정리 절차가 모든 관련 복사본과 관련 정보(완료 시 집합 자체 포함)를 제거하기 위해 해당 집합의 내용을 반복하기만 하면 됩니다.
2. 키 이름의 길이를 추적합니다.
이는 Redis 네임스페이스와 관련하여 위의 내용과 모순되는 것처럼 보일 수 있지만 키 이름도 메모리를 차지하므로 키 이름을 짧게 유지하도록 노력해야 합니다. 분명히 이것은 수백만 또는 수십억 개의 키로 구성된 데이터 세트에서 문제가 되지만 사실 긴 키에는 해시 테이블에 대한 가격이 있습니다.
예를 들어 Redis 네임스페이스에 1,000,000개의 키를 저장하면 각각 32자 값으로 설정되어 6자 키 이름을 사용할 때 약 96MB를 사용하고 12자 이름을 사용하는 경우 111MB(32비트 Redis 서버에서)를 사용한다고 가정합니다. 15% 이상의 이 오버헤드는 키 수가 증가함에 따라 상당히 중요해집니다. Redis를 사용하면 접두사가 있는 키를 삭제할 수도 있습니다.
3. 올바른 데이터 구조 사용
메모리 사용량이나 성능 때문에 때때로 한 데이터 구조가 다른 데이터 세트보다 데이터 세트에 더 적합합니다. 다음은 명심해야 할 몇 가지 모범 사례입니다.
-
수천(또는 수백만)의 독립적인 문자열 값으로 데이터를 저장하는 대신 관련 데이터를 해시 데이터 구조로 그룹화하는 것을 고려하십시오. 해시는 매우 효율적이며 메모리 사용량을 줄일 수 있습니다(또한 해시는 일부 세부 정보를 추상화하고 코드를 더 읽기 쉽게 만드는 부가 가치를 제공합니다). 이에 대한 자세한 내용은 이 기사를 확인하세요.
-
해당되는 경우 집합 대신 목록을 사용합니다. 고유성을 확인하거나 구성원 자격을 확인하기 위해 집합의 속성이 필요하지 않은 경우 목록은 메모리를 덜 소모하고 삽입을 더 빠르게 수행합니다.
-
정렬된 집합은 메모리 소비와 기본 연산 복잡성(예:새 멤버 ZADD) 측면에서 가장 비용이 많이 드는 데이터 구조입니다. 점수를 조회하는 방법만 필요하고 순서가 중요하지 않다면 해시를 대신 사용하는 것이 좋습니다.
-
Redis에서 자주 간과되는 기능은 비트맵 또는 비트 세트(v2.2부터 사용 가능)입니다. Bitsets를 사용하면 Redis 값에 대해 여러 비트 수준 작업을 수행할 수 있습니다. 즉, 많은 양의 데이터를 효율적으로 저장할 수 있습니다. 예를 들어 일부 경량 분석에 사용할 수 있습니다.
4. 스캔을 사용하고 키를 사용하지 마십시오.
SCAN 명령은 Redis v2.8부터 사용할 수 있으며 커서를 사용하여 키 공간에서 키를 검색할 수 있습니다. 이 동작은 일치하는 모든 요소를 한 번에 반환하지만 Redis 서버를 차단하고 RAM 리소스를 소진시킬 수도 있기 때문에 프로덕션에서는 위험한 것으로 간주되는 (hiss) KEYS 명령과 다릅니다. 반면 SCAN을 사용하면 서버를 차단하거나 슬레이브에 의존할 위험 없이 데이터를 검사할 수 있습니다.
SCAN을 사용하려면 SCAN에 대한 후속 호출에 전달되는 커서 값을 읽어야 합니다. SCAN은 또한 키 이름 패턴과 선택적 count 인수를 허용합니다. SCAN과 KEYS의 또 다른 차이점은 SCAN을 사용하여 동일한 키 이름을 두 번 이상 얻을 수 있다는 것입니다.
SCAN은 SSCAN, HSCAN 및 ZSCAN과 함께 제공되므로 세트, 해시 및 정렬된 세트의 내용을 각각 반복할 수 있습니다.
5. 서버측 Lua 스크립트 사용
개발자로서 Redis의 Lua 스크립트 실행 기능을 수용하면 익숙한 영역을 탐색하게 될 것입니다. 선택하기 가장 쉬운 언어 중 하나인 Lua는 Redis 서버 자체 내에서 실행되는 코드로 창의력을 표현할 수 있는 기능을 제공합니다. 올바르게 적용되면 Lua 스크립트는 성능 및 리소스 소비 측면에서 큰 차이를 만들 수 있습니다. 데이터를 (응용 프로그램) CPU로 가져오는 대신 스크립트를 사용하면 데이터 근처에서 논리를 실행할 수 있으므로 네트워크 대기 시간과 데이터 중복 전송이 줄어듭니다.
Lua의 극적인 영향에 대한 전형적인 예는 Redis에서 많은 데이터를 가져와 애플리케이션에서 필터링하거나 집계할 때 발생합니다. 처리 워크플로를 스크립트로 캡슐화하면 훨씬 적은 시간과 리소스로 훨씬 더 작은 응답을 얻기 위해 호출하기만 하면 됩니다.
프로 팁: Lua는 훌륭하지만 일단 워크플로를 옮기면 오류 보고 및 처리가 더 어렵다는 것을 알 수 있습니다(결국 Redis 서버 내에서 실행 중임). 이를 우회하는 한 가지 현명한 방법은 Redis의 Pub/Sub를 사용하고 스크립트가 전용 채널에 "로그" 메시지를 게시하도록 하는 것입니다. 그런 다음 이러한 메시지를 받고 그에 따라 처리하도록 구독자 프로세스를 설정합니다.
Redis escapades 동안 선택하게 될 다른 많은 중요한 팁이 있을 수 있지만 이 목록은 가장 중요한 몇 가지를 시작하는 데 도움이 될 것입니다. 공유하고 싶은 다른 제안, 피드백 또는 질문이 있는 경우 언제든지 저에게 소리를 지르십시오. 저는 가용성이 높습니다. 🙂