Redis가 메모리를 절약하는 방법

먼저 사진 ID를 통해 사용자 UID를 역으로 확인하는 이 애플리케이션의 요구 사항은 다음과 같습니다.

• 쿼리 속도가 충분히 빨라야 합니다.

• 데이터를 메모리에 저장할 수 있어야 하며, 바람직하게는 EC2입니다. 대용량 메모리 모델은 저장할 수 있습니다(17GB나 34GB, 68GB는 너무 아깝습니다)

• 지속성을 지원하므로 서버 재시작 후 워밍업이 필요 없습니다

우선 데이터베이스 스토리지 솔루션을 거부했고, 그리고 그들은 KISS 원칙(Keep It Simple and Stupid)을 채택했습니다. 왜냐하면 이 애플리케이션은 데이터베이스의 업데이트 기능, 트랜잭션 기능, 관련 쿼리 및 기타 멋진 기능을 전혀 사용하지 않기 때문에 선택하고 유지할 필요가 없기 때문입니다. 사용되지 않는 기능에 대한 데이터베이스입니다.

그래서 그들은 Redis를 선택했습니다. Redis는 지속성을 지원하는 인메모리 데이터베이스이며, 가장 간단한 구현은 Redis의 문자열 구조를 사용하여 키-값을 만드는 것입니다. .

SET media:1155315 939
GET media:1155315
> 939

여기서 1155315는 사진 ID이고 939는 사용자 ID입니다. 각 사진 ID를 키로 사용하고 사용자 uid를 값으로 사용하여 키-값 쌍으로 저장합니다. 그런 다음 위의 방법에 따라 테스트를 수행하고 데이터를 저장하면 1,000,000개의 데이터는 70MB의 메모리를 사용하고, 300,000,000개의 사진은 21GB의 메모리를 사용합니다. 17GB라는 예산에 비하면 여전히 과잉 지출이다.

(NoSQLFan: 사실 여기서 최적화 지점을 볼 수 있습니다. 키 값 앞의 동일한 미디어를 제거하고 숫자만 저장할 수 있습니다. 이렇게 하면 키 길이가 줄어들고 키의 메모리 오버헤드가 줄어듭니다. value [참고: Redis 키 값은 문자열에서 숫자로 변환되지 않으므로 여기에 저장되는 것은 미디어 6바이트의 오버헤드뿐입니다.] 실험 후에 메모리 사용량은 50MB로 줄어들고 총 메모리는 15GB면 충분합니다. 하지만 인스타그램의 후속 개선은 여전히 ​​필요합니다)

그래서 인스타그램 개발자는 Redis 개발자 중 한 명인 Pieter Noordhuis에게 최적화 계획에 대해 문의했고, 대답은 Hash 구조를 사용한다는 것이었습니다. . 구체적인 방법은 데이터를 분할하고 해시 구조를 사용하여 각 세그먼트를 저장하는 것입니다. 해시 구조는 특정 숫자보다 작은 단일 해시 요소를 압축하여 저장하므로 많은 메모리를 절약할 수 있습니다. 위의 문자열 구조에는 존재하지 않습니다. 구성 파일의 "hash-zipmap-max-entries" 매개변수는 특정 수를 제어합니다. 개발자의 실험 결과 hash-zipmap-max-entries가 1000으로 설정되면 성능이 더 좋아집니다. 1000을 초과하면 HSET 명령으로 인해 CPU 소비가 매우 커집니다.

그래서 그들은 계획을 변경하고 다음 구조로 데이터를 저장했습니다.

HSET "mediabucket:1155" "1155315" "939"
HGET "mediabucket:1155" "1155315"
> "939"

7자리 사진 ID의 처음 4자리를 해시 구조의 키 값으로 사용하여 각 해시에 3자리 키입니다.

또 다른 실험을 진행한 결과, 키 1,000,000개당 메모리가 16MB만 소모되는 것으로 나타났습니다. 총 메모리 사용량도 5GB로 줄어들어 애플리케이션 요구 사항을 충족합니다.

(NoSQLFan: 마찬가지로 여기서도 최적화할 수 있습니다. 먼저 해시 구조의 키 값을 순수한 숫자로 변경하여 키 길이를 12바이트로 줄입니다. 둘째, 해시 구조의 하위 키 값을 세 자리로 변경합니다. , 아래와 같이 오버헤드가 4바이트 더 줄어듭니다. 실험 후 메모리 공간은 10MB로 줄어들고 총 메모리 공간은 3GB가 됩니다.)

HSET "1155" "315" "939"
HGET "1155" "315"
> "939"

위 내용은 Redis가 메모리를 절약하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!