Redis 압축 목록에 대한 자세한 소개(예제 설명)

이 글은 Redis 압축 목록에 대한 자세한 소개(예제 설명)를 제공합니다. 필요한 친구들이 참고할 수 있기를 바랍니다.

이 글에서는 Redis의 데이터 저장 방식 중 하나인 압축 목록을 주로 소개합니다.

이 기사에서는

1, 압축 목록(ziplist) 사용 시나리오

2를 소개합니다.

3. 압축 목록의 저장 형식

4. 체인 업데이트 관련 문제

5.

실제로 주요 작업은 conf 구성 파일을 구성하는 것입니다. 정확한 값은 없지만 경험적인 값이 더 많습니다. 일부 프로젝트에서는 원래 기본값을 직접 사용합니다. 이 문서는 데이터베이스의 기본 저장소 논리를 더 잘 이해하는 데 도움이 될 것입니다. 에너지를 연구하고 저장하려면 폭넓은 지식과 심오한 지식이 모두 필요합니다. 이 글이 Redis를 배우고 있는 친구들에게 도움이 되기를 바랍니다. (추천 튜토리얼: Redis tutorial)

1. 압축 목록(ziplist) 사용 시나리오:

데이터 저장을 최적화하고 메모리를 절약하기 위해 Redis는 목록, 사전(해시 키) 및 순서 집합 압축 목록을 사용하는 최적화 방식을 구현했습니다.

예를 들어 해시 키에 저장된 문자열이 비교적 짧은 경우 Redis는 이를 압축된 목록 형식으로 저장합니다. 즉, 저장을 위해 바이트 배열로 변환합니다. 해시 키에 내부적으로 저장된 정수 값이 상대적으로 작은 경우 압축 목록의 노드로도 저장됩니다. 마찬가지로, 리스트 키로 작은 데이터를 저장하는 것은 해시 키의 작동과 유사합니다.

이와 같이 압축된 목록은 개발자가 직접 호출할 수 있는 Redis의 저장소 데이터 구조가 아니라 데이터 저장소를 최적화하기 위한 Redis의 기본 노력입니다. 이것을 이해하는 것이 여전히 중요합니다.

2. 메모리 절약 효과를 얻는 방법은 무엇입니까?

압축된 목록은 직렬화된 데이터 구조입니다. 이 데이터 구조의 기능은 일련의 데이터와 해당 인코딩 정보를 연속적인 메모리 영역에 저장하는 것입니다. 그러나 논리적으로 구성 요소, 즉 노드로 구분됩니다. 목적은 제어 가능한 특정 시간 복잡도 조건에서 불필요한 메모리 오버헤드를 최대한 줄여 메모리 절약 효과를 얻는 것입니다. 메모리 절약 효과를 얻는 방법을 이해해야 하며, 압축된 목록의 저장 형식도 이해해야 합니다.

3. 압축 목록의 저장 형식:

압축 목록(ziplist)은 Redis 목록 키, 해시 키 및 순서 집합 키의 기본 구현 중 하나입니다. 그 본질은 일종의 직렬화

입니다. 구조. 일반적인 상황과 달리 Redis는 양방향 연결 목록을 사용하여 목록을 나타내고, 해시 테이블을 사용하여 해시 키를 나타내고, 해시 테이블 + 점프 테이블을 사용하여 순서 집합을 나타냅니다. 목록 또는 해시 사전/정렬 집합에 소량의 콘텐츠만 포함되어 있고 각 목록 항목 또는 해시 항목/정렬 집합 항목이 작은 정수이거나 비교적 짧은 문자열인 경우. 그런 다음 Redis는 기본 구현에 압축된 목록을 사용합니다.

압축된 목록은 Redis에서 특별히 인코딩된 일련의 연속 메모리 블록

으로 구성됩니다. 각 메모리 블록을 노드(항목)라고 하며 압축된 목록에는 여러 노드가 포함될 수 있습니다. 각 노드에 저장되는 데이터 형식은 바이트 배열(중국어 문자열 등은 바이트 배열로 변환됨) 또는 정수 값일 수 있습니다.

바이트 배열의 길이는 다음 중 하나일 수 있습니다.

1. 길이는 63바이트(2의 6승)보다 작거나 같습니다.

2 길이는 16383바이트보다 작거나 같습니다. (2의 14승)

3. 길이는 4294967295바이트(2의 32승)보다 작거나 같습니다.

정수 값은 다음 6가지 유형 중 하나일 수 있습니다.

1. , 0~12 사이의 부호 없는 정수

3.3바이트 부호 있는 정수

4.int32_type 정수

6. 일반 저장 형식과 압축 목록 저장 형식의 차이점:

목록 저장 구조는 일반적으로 이중 끝 연결 목록입니다. 각 값은 노드로 표시되며 각 노드는 이전 노드와 다음 노드를 가리킵니다. node. 노드에 대한 포인터 및 노드에 포함된 문자열 값에 대한 포인터입니다. 문자열 값은 세 부분으로 저장됩니다. 첫 번째 부분은 문자열 길이를 저장하고, 두 번째 부분은 문자열 값에 사용 가능한 나머지 바이트를 저장하며, 세 번째 부분은 문자열 데이터 자체를 저장합니다. 따라서 노드는 포인터 3개, 문자열 정보를 기록하는 정수 2개, 문자열 자체 및 추가 바이트를 저장해야 하는 경우가 많습니다. 전체적인 추가 오버헤드가 상당합니다(21바이트).

압축 목록 노드의 형식:

각 노드는 이전_항목 길이, 인코딩, 콘텐츠의 세 부분으로 구성됩니다. 압축 목록을 순회할 때 뒤에서 앞으로 순회됩니다.

1.previous_entry_length는 이전 노드의 길이를 기록합니다. 현재 포인터에서 이 값을 빼면 이전 노드의 시작 주소에 도달합니다.

2. 인코딩은 노드 콘텐츠 속성에 저장된 데이터의 유형과 길이를 기록합니다

3. 콘텐츠는 노드의 값을 기록합니다

분명히 목록을 압축하면 저장 공간이 많이 절약됩니다. 그러나 다음과 같은 문제도 발생하게 됩니다.

4. 체인 업데이트 문제:

일반적으로 이전 노드의 전체 길이가 254바이트 미만인 경우 이전_entry_length 속성에는 이 길이 값을 저장하는 데 1바이트의 공간만 필요합니다. 이전 노드가 254바이트보다 큰 경우, Previous_entry_length 속성은 5바이트의 공간을 사용하여 길이 값을 기록합니다.

길이가 약 254바이트인 노드 앞에 새 노드가 삽입되면 이 노드의 오프셋을 새 노드에 기록하기 위해 이전_항목_길이를 추가해야 합니다. 이때 이 노드의 길이는 254바이트보다 커야 합니다. 따라서 이 노드 이후의 노드는 이 노드의 정보를 기록하기 위해 이전_entry_length의 1바이트만 사용할 수 없고, 기록하려면 5바이트가 필요합니다. 연속된 여러 노드의 길이가 약 254바이트인 경우 노드 중 하나의 전후에 노드 삽입 및 삭제가 발생합니다(삭제의 추론은 삽입의 추론과 반대이며 5바이트인 이전 노드의 원본 레코드는 1바이트가 됨) 체인 업데이트를 트리거할 수 있음은 물론 시스템의 운영 효율성에 매우 해로울 수 있습니다. 그러나 이러한 상황은 실제 응용에서는 여전히 거의 발생하지 않습니다.

이중 연결 목록은 노드 업데이트, 추가 및 삭제가 훨씬 "더 쉽습니다". 각 노드에 저장된 정보는 상대적으로 독립적이기 때문입니다.

실용적 의미:

노드가 차지하는 저장 공간 바이트 수를 추정하려면 저장된 필드 값이 254바이트의 저장 공간을 차지하지 않도록 필드의 저장 형식을 적절하게 조정합니다(encoding 속성 및 이전_entry_length 속성 제외). 에 대한.

Redis에서 문자열 및 해시 키 값의 길이를 보는 관련 명령:

1 문자열 키에 해당하는 값의 길이를 쿼리합니다.

명령:

Strlen

예:

127.0.0.1: 6379> strlen m_name

(정수) 8

2 해시 키의 필드 길이를 쿼리합니다.

명령:

Hstrlen

예:

127.0.0.1 :6379> hstrlen good_list good_list1

( 정수) 226

5.Conf 파일 구성:

구성 파일을 수정하여 압축 목록을 사용하여 최대 요소 수를 저장할지 여부를 제어할 수 있습니다. Conf 파일 구성: 1.

[] -max-ziplist-entries: 키의 최대 요소 수, 즉 키 아래의 노드 수를 나타냅니다. 키에 지정된 값은 압축된 목록에 저장됩니다

[] -max-ziplist-value: 압축된 목록에 있는 각 노드의 최대 크기를 바이트 단위로 나타냅니다.

실제 사용에서는 목록 키의 특정 요소/ 해시 키는 비교적 많은 양의 정보를 저장하는 경우가 많아 64바이트를 초과하므로 동시에 데이터의 실제 저장 용량과 이전_항목_길이의 크기를 고려하면 구성 중에 64바이트보다 클 가능성이 높습니다. 위에서 언급한 대로 [] -max-ziplist-value를 합리적으로 구성하세요.

구성 파일 내용:

############## ADVANCED CONFIG ##########################
哈希键
# Hashes are encoded using a memory efficient data structure when they have a
# small number of entries, and the biggest entry does not exceed a given
# threshold. These thresholds can be configured using the following directives.
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

有序集合键
# Similarly to hashes and lists, sorted sets are also specially encoded in
# order to save a lot of space. This encoding is only used when the length and
# elements of a sorted set are below the following limits:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

列表键，比较特殊，直接使用制定大小kb字节数表示（有些conf文件的列表键与hash键的表达式没太大区别）
# Lists are also encoded in a special way to save a lot of space.
# The number of entries allowed per internal list node can be specified
# as a fixed maximum size or a maximum number of elements.
# For a fixed maximum size, use -5 through -1, meaning:
# -5: max size: 64 Kb  <-- not recommended for normal workloads
# -4: max size: 32 Kb  <-- not recommended
# -3: max size: 16 Kb  <-- probably not recommended
# -2: max size: 8 Kb   <-- good
# -1: max size: 4 Kb   <-- good
# Positive numbers mean store up to _exactly_ that number of elements
# per list node.
# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),
# but if your use case is unique, adjust the settings as necessary.
list-max-ziplist-size -2

사례:

구성을 수정하기 전에 기본 구성을 사용하세요.

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

127.0.0.1:6379> 객체 인코딩 good_list

"hashtable"

구성 수정:

hash-max-ziplist-entries 512

hash-max- ziplist 값 25 4

참고: 구성을 수정한 후 서버를 다시 시작해야 합니다127.0.0.1:6379> hstrlen good_list good_list1

(integer) 226

127.0.0.1:6379>

"zip 목록 "

볼 수 있습니다. 저장 방법이 ziplist로 변경되었습니다.

더 많은 공식 스트레스 테스트 및 지침 제안:

압축된 목록의 요소 수가 수천 개로 증가하는 경우(실제 사용량은 다음보다 훨씬 적을 수 있습니다.) 이 값), 압축된 목록의 성능이 저하될 수 있습니다. Redis가 이 구조를 작동할 때 인코딩 및 디코딩에 일정한 압력이 가해지기 때문입니다.

압축된 목록의 길이는 500~2000으로 제한되며, 각 요소의 크기는 128바이트 이하로 제한됩니다. 압축된 목록의 성능은 합리적인 범위 내입니다.

위 내용은 Redis 압축 목록에 대한 자세한 소개(예제 설명)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!