Redis 데이터베이스의 일반적인 키-값 디자인은 무엇입니까?

　사용자 로그인 시스템

　사용자 로그인 정보를 기록하는 시스템으로 업무를 단순화하고 테이블 하나만 남겨두었습니다.

　 관계형 데이터베이스 설계

　 mysql>select*fromlogin;

　 +---------+---+------ ---------+---------+

　 |user_id|name|login_times|last_login_time|

　 +------ -----+---+-------------+-------------- -- -------+

　|1|kenthompson|5|2011-01-0100:00:00|

　|2|dennisritchie|1|2011-02-0100:00:00|

|3 |조암스트롱|2|2011-03-0100:00:00|

　 +---------+---+--- -- --------+---------+

　user_id 테이블의 기본 키인 name은 사용자 이름인 login_times를 나타냅니다. 는 사용자의 로그인 횟수를 나타내며, 사용자가 로그인할 때마다 login_times는 저절로 증가하고 last_login_time은 현재 시간으로 업데이트됩니다.

REDIS 설계

관계형 데이터를 KV 데이터베이스로 변환하는 방법은 다음과 같습니다.

키 테이블 이름: 기본 키 값: 열 이름

값 열 값

일반적으로 콜론을 구분 기호로 사용합니다. 기록되지 않은 규칙입니다. 예를 들어 php-adminforredis 시스템에서는 기본적으로 키가 콜론으로 구분되어 있으므로 user:1user:2 및 기타 키는 하나의 그룹으로 나누어집니다. 따라서 위의 관계 데이터는 kv 데이터로 변환되어 다음과 같이 기록됩니다.

Setlogin:1:login_times5

Setlogin:2:login_times1

Setlogin:3:login_times2

Setlogin:1:last_login_time2011-1-1

Setlogin :2 :last_login_time2011-2-1

Setlogin:3:last_login_time2011-3-1

setlogin:1:name"kenthompson"

setlogin:2:name"dennisritchie"

setlogin:3:name"JoeArmstrong"

기본 키가 알려진 경우 get 및 set 메소드를 사용하여 사용자 이름, 로그인 시간 및 마지막 로그인 시간을 얻거나 수정할 수 있습니다.

일반 사용자는 자신의 ID를 알 수 없고 사용자 이름만 알 수 있으므로 이름과 ID 간의 매핑 관계가 있어야 합니다. 여기서의 디자인은 위와 다릅니다.

　　set"login:kenthompson:id"1

　set"login:dennisritchie:id"2

　set"login:JoeArmstrong:id"3

　이러한 방식으로 사용자가 로그인할 때마다 비즈니스 로직은 다음과 같습니다. 다음과 같이(파이썬 버전) r은 redis 객체이고 name은 알려진 사용자 이름입니다.

　　#사용자 ID 가져오기

　uid=r.get("login:%s:id"%name)

　　#사용자 로그인 횟수 늘리기

다음은 가능한 다른 문장입니다. ret = r.incr("login:%s:login_times" % uid)

　　#사용자의 마지막 로그인 시간 업데이트

　 ret=r.set("login:%s:last_login_time"%uid,datetime.datetime.now ())

요구 사항이 사용자의 ID, 업데이트 또는 사용자의 마지막 로그인 시간 및 로그인 횟수를 아는 것뿐이라면 관계형 데이터베이스와 kv 데이터베이스 간에 차이가 없습니다. 하나는 btreepk를 통해서이고 다른 하나는 해시를 통해서인데, 둘 다 매우 잘 작동합니다.

　 최근 로그인한 N명의 사용자를 찾기 위해 다음과 같은 요구사항이 있다고 가정합니다. 개발자는 비교적 간단하며 단 하나의 SQL로 수행할 수 있습니다.

"login" 테이블에서 모든 열을 선택하고 "last_login_time" 열을 내림차순으로 정렬한 후 결과 집합 크기를 N으로 제한하세요.

DBA가 요구 사항을 이해한 후 테이블이 더 커질 것이라는 점을 고려하여 미래에는 last_login_time 인덱스를 기반으로 구축됩니다. 인덱스의 가장 오른쪽부터 시작하여 N개의 레코드에 접근한 후 N개의 테이블 반환 작업을 수행함으로써 실행 계획에 큰 영향을 미칩니다.

　 일반적인 Redis 데이터베이스 키 값의 설계는 무엇입니까 ​

　 이틀 후 또 다른 요구 사항이 왔는데, 누가 가장 많이 로그인했는지 알아야 했습니다. 동일한 관계 유형을 처리하는 방법은 간단하다고 DEV는 말했습니다.

　select*fromloginorderbylogin_timesdesclimitN

　DBA가 살펴보고 login_time에 대한 인덱스를 생성해야 합니다. 뭔가 문제가 있다고 생각하시나요? 테이블의 모든 필드에 큰따옴표가 있습니다.

문제의 원인은 관계형 데이터베이스의 데이터 저장이 충분히 유연하지 않고, 행으로 배열된 힙 테이블을 통해서만 데이터를 저장할 수 있다는 것입니다. 통일된 데이터 구조란 특정 컬럼에 빠르게 접근하기 위해 SQL 접근 경로를 변경하기 위해 인덱스를 사용해야 한다는 뜻이고, 접근 경로가 늘어난다는 것은 이를 보조하기 위해 통계 정보를 활용해야 한다는 의미이므로 많은 문제가 발생한다.

　색인도 없고 통계계획도 없고 실행계획도 없는 이것이 kv 데이터베이스입니다.

최신 N개의 데이터를 확보해야 하는 경우 Redis의 Linked List 기능인 후입선출(Last In First Out) 기능이 매우 적합합니다. 위의 로그인 코드 뒤에 코드 조각을 추가하여 로그인 연결 목록을 유지하고 가장 최근에 로그인한 N명의 사용자가 항상 여기에 저장되도록 길이를 제어합니다.

　　#현재 로그인 사용자를 연결 목록에 추가

　　ret=r.lpush("login:last_login_times",uid)

　　#연결 목록을 N 비트로만 유지

　　ret=redis.ltrim("login: last_login_times",0 ,N-1)

　이 방법으로 최신 로그인 사용자의 ID를 가져와야 합니다. 다음 코드로 충분합니다

　last_login_list=r.lrange("login:last_login_times",0,N- 1)

　또한 로그인 시간이 가장 많은 것을 찾습니다. 사람들, sortedset은 정렬 및 순위와 같은 요구에 매우 적합합니다. 우리는 sortedset에 사용자와 로그인 시간을 저장합니다.

Zaddlogin : login_times51 Zaddlogin : login_times12

zaddlogin : login_times23

이런 방식으로, 사용자 로그인하면 추가 정렬 세트가 유지되면 코드는 다음과 같습니다. 1

　 ret=r .zincrby( "login:login_times",1,uid)

　 그렇다면 로그인 횟수가 가장 많은 사용자를 얻는 방법은 무엇입니까? N번째 사용자를 역순으로 정렬하면 됩니다

　ret=r.zrevrange(" login:login_times",0,N -1)

　DEV는 2줄의 코드를 추가해야 하고 DBA는 인덱스 등을 고려할 필요가 없음을 알 수 있습니다.

　TAG 시스템

　 태그는 특히 인터넷 애플리케이션에서 일반적입니다. 기존 관계형 데이터베이스로 설계했다면 설명이 조금 부족할 것입니다. 이와 관련하여 redis의 장점을 알아보기 위해 책을 검색하는 예를 들어보겠습니다.

관계형 데이터베이스 설계

두 개의 테이블(책 세부 정보용 테이블과 태그용 테이블)은 각 책의 태그를 나타냅니다.

　 mysql>select*frombook;

　 +------+------------------- --+ --+

　|id|이름|작성자|

　+------+------------ --- ------+----------------+

　|1|TheRubyProgrammingLanguage|MarkPilgrim|

|1|Rubyonrail |DavidFlanagan|

　|1|ProgrammingErlang|JoeArmstrong|

　+------+------------ ------- ---+---+

　mysql>select*fromtag;

　+---------+- ------- -+

　|태그 이름|book_id|

　+---------+---------+

　|ruby|1|

　|ruby |2|

　|web |2|

　 |erlang|3|

　 +---------+---------+

　 그런 필요가 있다면 보세요 Ruby ​​와 웹의 책 모두 관계형 데이터베이스인 경우

　selectb.name,b.authorfromtagt1,tagt2,bookb

　wheret1.tagname='web'andt2.tagname='ruby'andt1 .book_id=t2.book_idandb.id=t1 .book_id

　태그 테이블은 자동으로 두 번 연결되고 책과 연결됩니다. 이 SQL은 여전히 ​​상대적으로 복잡하지만 요구사항이 Ruby라면 어떨까요?

실제로 관계형 데이터는 이러한 집합 작업에 적합하지 않습니다.

REDIS 디자인

우선 위와 마찬가지로 책 데이터가 저장되어 있어야 합니다.

　 Setbook:1:name"TheRubyProgrammingLanguage"

Setbook:2:name"Rubyonrail"

Setbook:3:name"ProgrammingErlang"

setbook:1:author"MarkPilgrim"

Setbook:2:author"David Flanagan "

　 Setbook:3:author"JoeArmstrong"

　tag table 세트는 교차점과 합집합을 찾는 데 능숙하기 때문에 세트를 사용하여 데이터를 저장합니다.

　 sadtag: ruby1

　그렇다면 Ruby에 속한 책은 무엇입니까 ​​하지만 웹에도 속해 있나요?

　inter_list=redis.sinter("tag.web","tag:ruby")

　즉, 웹에는 속하지 않고 Ruby에 속해 있는 책들인가요?

　inter_list= redis .sdiff("tag.ruby","tag:web")

루비와 웹에 속하는 책들의 모음?

inter_list=redis.sunion("tag.ruby","tag:web" )

단순 불가능합니다.

위의 두 가지 예에서 일부 시나리오에서는 관계형 데이터베이스가 적합하지 않다는 것을 알 수 있습니다. 요구 사항을 충족하는 시스템을 설계할 수는 있지만 항상 이상하고 기계적인 느낌이 듭니다.

특히 시스템에 로그인하는 경우 비즈니스에 대한 인덱스가 자주 생성됩니다. 복잡한 시스템에서는 ddl(인덱스 생성)이 실행 계획을 변경할 수 있습니다. 업무가 복잡한 기존 시스템의 SQL은 온갖 종류의 SQL이 이상해 다른 SQL이 다른 실행 계획을 사용하게 되므로 이 문제는 예측하기 어렵습니다. DBA에게 이 시스템의 모든 SQL을 이해하도록 요구하는 것은 너무 어렵습니다. 이 문제는 Oracle에서 특히 심각하며 모든 DBA가 이 문제를 경험했을 것입니다. 현재 온라인 DDL 방법이 있지만 DDL은 MySQL과 같은 시스템에서는 여전히 그리 편리하지 않습니다. 큰 테이블의 경우 DBA가 아침 일찍 일어나 업무시간이 짧은 시간에 작업을 하는 경우가 많습니다. Redis를 사용하여 이러한 수요를 처리하는 것은 매우 편리하며 DBA가 용량을 추정하기만 하면 됩니다.

위 내용은 Redis 데이터베이스의 일반적인 키-값 디자인은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!