"2015년 3월 ObjectRocket.com/blog에 처음 게시됨"
Redis®는 멋진 도구이며 기술 커뮤니티에서 사랑합니다! Antirezto의 소규모 개인 프로젝트가 업계 표준 인메모리 데이터 스토리지가 되기까지 먼 길을 왔습니다. 이를 통해 Redis를 올바르게 사용하기 위한 일련의 모범 사례가 제공됩니다. 이 기사에서는 Redis를 올바르게 사용하기 위한 10가지 간단한 팁을 살펴봅니다.
1. 키 사용 중지
좋아요, 그래서 당신에게 소리치는 것은 이 기사를 시작하기에 좋은 방법이 아닐 수도 있습니다. 하지만 가장 중요한 포인트라고 할 수 있습니다. Redis를 너무 자주 봅니다. 예를 들어, 빠른 commandstats를 불러옵니다. , 그리고 눈부신 KEYS를 봅니다. 나를 똑바로 쳐다보고 있다. 모든 공정에서 프로그래밍 방식의 관점에서 볼 때 다음과 유사한 의사 코드를 사용하는 것이 합리적일 것입니다.
for key in 'keys *':
doAllTheThings()
그러나 예를 들어 1,300만 개의 키가 있으면 상황이 느려질 것입니다. KEYS 이후 O(n)입니다. 여기서 n 는 반환된 키의 수이며 복잡성은 데이터베이스 크기에 따라 달라집니다. 또한 이 전체 작업 중에는 인스턴스에 대해 다른 어떤 것도 실행할 수 없습니다.
대신 증분으로 데이터베이스를 스캔할 수 있는 SCAN을 확인하십시오. 이것은 반복자에서 작동하므로 원하는 대로 중지하고 이동할 수 있습니다.
2. Redis의 속도를 늦추는 요인 알아보기
Redis에는 가장 장황한 로그가 없기 때문에 인스턴스 내부에서 정확히 무슨 일이 일어나고 있는지 추적하기 어려운 경우가 많습니다. 다행히 Redis는 commandstat를 제공합니다. 다음 예와 유사한 세부 정보를 표시하는 유틸리티:
127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10
이것은 모든 명령에 대한 분석, 실행한 횟수, 실행하는 데 걸린 마이크로초 수(호출당 총 및 평균)를 제공합니다. 재설정하려면 CONFIG RESETSTAT를 실행하십시오. , 그리고 당신은 완전히 새로운 슬레이트를 얻었습니다.
3. 복음 진리가 아닌 Redis-Benchmark를 기준으로 사용
Redis를 만든 Salvatore는 다음과 같이 강조했습니다. "GET/SET을 수행하여 Redis를 테스트하려면 비가 올 때 거울을 얼마나 잘 닦는지 알아보기 위해 페라리를 테스트하는 것과 같습니다.” 많은 사람들이 Redis-Benchmark 결과가 최적보다 낮은 이유에 대해 궁금해합니다. 그러나 다음과 같은 다양한 요인을 고려해야 합니다.
- 클라이언트 측 제한 사항
- 버전 관리의 차이점
- 진행 중인 테스트
Redis-벤치마크 redis-server 정상적으로 작동하지만 진정한 부하 테스트로 간주되어서는 안 됩니다. . 부하 테스트는 가능한 한 프로덕션에 가까운 환경에서 애플리케이션이 작동하는 방식을 반영해야 합니다.
4. 해시는 당신의 가장 친한 친구입니다
저녁 식사에 해시 오버를 초대하십시오. 와인과 식사 해시. 그들에게 기회만 준다면 얼마나 행복해질 수 있는지 알게 될 것입니다. 이전에 다음과 같은 핵심 구조를 너무 많이 보았습니다.
foo:first_name
foo:last_name
foo:address
이 예에서 foo 는 사용자의 사용자 이름일 수 있으며 각 줄은 별도의 키입니다. 이렇게 하면 오류의 여지가 추가되고 접기에 불필요한 키가 추가됩니다. 대신 해시를 고려하십시오. 갑자기 하나의 키만 갖게 되었습니다.
127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"
5. TTL(Time To Live)을 설정하세요!
가능하면 만료되는 키를 활용하십시오. 완벽한 예는 임시 인증 키와 같은 것을 저장하는 것입니다. OAUTH를 사용하여 인증 키를 검색할 때 예를 들어 만료 시간이 자주 발생합니다. 키를 설정할 때 동일한 만료 시간으로 설정하면 Redis가 자동으로 정리합니다! 더 이상 KEYS가 필요하지 않습니다. 모든 키를 반복합니다.
6. 적절한 퇴거 정책 선택
키 정리에 대한 주제에 대해 이야기하는 동안 축출에 대해 알아보겠습니다. Redis 인스턴스가 가득 차면 Redis는 키를 제거하려고 합니다. 사용 사례에 따라 volatile-lru를 적극 권장합니다. - 만료되는 키가 있다고 가정합니다. acache와 같은 것을 실행하고 만료 설정이 없는 경우 allkeys-lru를 고려할 수 있습니다. . 여기에서 사용 가능한 옵션을 확인하는 것이 좋습니다.
7. 데이터가 중요한 경우 시도/제외
데이터가 Redis 인스턴스에 전달되는 것이 절대적으로 중요한 경우 try/except를 입력하는 것이 좋습니다. . 대부분의 사람들이 Redis 클라이언트를 실행 후 삭제하도록 구성하기 때문입니다. , 키가 실제로 데이터베이스에 도달하지 않을 때를 항상 계획해야 합니다. 이 경우 Redis 호출에 추가되는 복잡성은 거의 없으며 중요한 데이터가 있어야 할 위치에 도달하도록 할 수 있습니다.
8. 하나의 인스턴스를 플러딩하지 마십시오
가능하면 여러 Redis 인스턴스 간에 워크로드를 분할합니다. Redis 클러스터 버전 3.0.0부터 사용할 수 있습니다.Redis 클러스터 키 범위를 기반으로 지정된 기본 및 보조 세트 간에 키를 분리할 수 있습니다. 여기에서 Redis 클러스터 이면의 마법에 대한 전체 분석을 찾을 수 있습니다. 튜토리얼을 찾고 있다면 더 이상 찾지 마십시오. 여기에서 찾을 수 있습니다. 클러스터링이 옵션이 아닌 경우 네임스페이스를 고려하고 여러 인스턴스에 키를 배포합니다. Theredis.io 웹사이트에서 데이터 분할에 대한 놀라운 글을 찾을 수 있습니다.
9. 더 많은 코어 =더 나은 성능, 맞죠?!
잘못된. Redis는 단일 스레드 프로세스이며 지속성을 활성화한 경우 최대 2개의 코어를 사용합니다. 동일한 호스트에서 여러 인스턴스를 실행할 계획이 아니라면(이 경우 개발 테스트를 위해서만 가능) Redis 인스턴스에 2개 이상의 코어가 필요하지 않습니다.
10. 하아!
Redis Sentinel은 이제 매우 잘 테스트되었으며 많은 사용자가 프로덕션 환경에서 실행하고 있습니다(Rackspace ObjectRocket 포함). 애플리케이션에 대해 Redis에 크게 의존하는 경우 온라인 상태를 유지하기 위해 고가용성(HA) 솔루션을 고려해야 합니다. 물론 이 모든 것을 직접 관리하고 싶지 않다면 Rackspace ObjectRocket은 연중무휴로 지원되는 HA 플랫폼을 제공합니다. 한 번 시도해 보세요.
Rackspace DBA 서비스에 대해 자세히 알아보십시오.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 영업 채팅을 클릭할 수도 있습니다. 지금 채팅하고 대화를 시작하세요.
Rackspace Cloud 서비스 약관을 보려면 여기를 클릭하십시오.