my sql 페이지 에서 카 산 드 라,redis+카 산 드 라 까지.
글 이 사실 적 이어서 기술자 의 특징 에 매우 부합된다.게다가 작가 의 묘사 가 뚜렷 하고 이해 하기 쉽다.모처럼 의 가작.
페이지 조회 및 redis
문제.
나 는 포럼 을 할 때 다음 과 같은 문 제 를 만 났 다.포럼 에는 많은 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제 주제현재 어떤 topic 아래 reply Time 의 오름차 순 으로 배 열 된 페이지 No 페이지 의 reply 를 조회 하려 면 페이지 마다 page Size 의 reply 를 조회 해 야 합 니 다.
reply 는 my sql 에 저 장 됩 니 다.이전 구현 은 my sql 을 이용 한 limit 조회 입 니 다.
1
2
3
4
select * from reply where topicId = ? order by replyTime asc limit (pageNo - 1) * pageSize, pageSize 지금 은 많은 주제 의 답변 이 많아 서 수백,심지어 수천 페이지 를 조회 하 는 사람 이 있 을 때 my sql 성능 이 좋 지 않 습 니 다."selectlimit offset,size'는 offset 이 너무 크 면 전통 적 인 관계 형 데이터 뱅 크 의 성능 표현 이 좋 지 않다.
색인 이 있 는 조회 조건 을 이용 하여 일부 데 이 터 를 먼저 걸 러 낼 수 있다 면 성능 을 크게 향상 시 킬 수 있다.예 를 들 어:
1
2
3
4
5
select * from reply where topicId = ? and replyId > lastReplyIdOfCurrentPage order by replyTime asc limit (pageNo - currentPageNo) * pageSize, pageSize lastReply IdOfCurrent Page 는 현재 페이지 의 마지막 reply id 입 니 다.현재 페이지 의 페이지 번호 입 니 다.여기에 reply Id 필터 조건 을 사용 하여 앞 페이지 의 내용 을 필터 하여 offset 의 크기 를 줄 입 니 다.그러나 사용자 가 먼 페이지 로 이동 해 야 할 때 offset 은 여전히 크다.예 를 들 어 현재 10 페이지 입 니 다.1000 페이지 로 넘 어가 야 합 니 다.offset=990*pageSize 는 아직도 크 고 성능 이 좋 지 않 습 니 다.비록 현재 많은 제품 들 이 이러한 점프 능력 을 제공 하지 않 지만 우리 제품 팀 은 이 기능 이 우리 제품 에 없어 서 는 안 되 거나 없어 서 는 안 된다 고 생각 합 니 다.
카 산 드 라 로 이전
나중에 우 리 는 reply 데 이 터 를 모두 카 산 드 라 로 옮 겼 다.카 산 드 라 의 데이터 구 조 는 my sql 과 다르다.우 리 는 topic 를 만 들 었 습 니 다.reply 열 클 러 스 터,각 줄 의 줄 번 호 는 topic Id 입 니 다.각 열 은 이 topic 의 reply Id 입 니 다.이렇게 하면 다음 과 같은 구 조 를 얻 을 수 있 습 니 다
1:1,2,5,33,245,663,780...
2:36,78,89,94,235,345...
1
select * from topic_reply where replyId > ? limit size ,"limit offset,size"는 안 됩 니 다.이것 은 만약 천 페이지 를 조회 하려 고 한다 면,나 는 천 페이지 에서 시 작 된 reply Id 가 얼마 인지 모 르 고,나 는 이 천 페이지 의 데 이 터 를 꺼 내야 한 다 는 것 을 의미한다.이것 은 분명히 통 하지 않 는 다.그래서 내 가 찾 으 려 는 데이터 의 어느 reply Id 에 접근 해서 데 이 터 를 찾 아야 합 니 다.
reids 의 SortedSet
mysql 이 든 cassandra 든 긴 서열 에서 임의의 데 이 터 를 꺼 내 는 문 제 를 잘 해결 하지 못 한다.이 문제 의 근원 은 이 데이터 가 디스크 에 저장 되 어 있 기 때문에 디스크 가 이런 무 작위 읽 기 동작 에 적합 하지 않다 는 것 이다.그래서 프로그램 이 있 으 면 메모리 에 큰 배열 을 정렬 하 는 것 을 관리 하면 좋 겠 습 니 다.메모리 에 있 는 배열 에 다음 표 시 를 하 는 것 이 매우 빠 르 기 때 문 입 니 다.조 사 를 해 보 니 redis 가 이런 기능 을 제공 한 것 으로 나 타 났 다.
redis 는 데 이 터 를 메모리 에 저장 하기 때문에 무 작위 읽 기와 쓰기 도 매우 빠 릅 니 다.redis 가 지원 하 는 SortedSet 구 조 는 페이지 조회 에 적합 합 니 다.SortedSet 은 주어진 score 에 따라 member 에 게 정렬 하여 아래 표 나 score 를 통 해 조회 할 수 있 습 니 다.같은 topic 의 reply Id 를 member 로 하고 reply Id 자 체 를 score 로 Sorted Set 에 저장 하면 다음 표 시 를 통 해 값 을 추출 할 수 있 습 니 다.예 를 들 어
//
zadd tr:1 1 1
zadd tr:1 2 2
zadd tr:1 5 5
zadd tr:1 33 33
zadd tr:1 245 245
zadd tr:1 663 663//pageSize = 3 ， 3 5
zrange tr:1 3 5
그 중에서 tr:1 은 이 Sorted Set 의 key 입 니 다."tr:"는 다른 key 를 구분 하 는 접두사 일 뿐 입 니 다.1 은 topic Id 입 니 다.더 자세 한 내용 은 redis 홈 페이지 를 보 세 요.http://redis.io 이렇게 되면 임의의 페이지 조 회 를 실현 할 수 있 을 뿐만 아니 라 성능 도 매우 좋다.
캐 시 인덱스
redis 의 데 이 터 는 모두 메모리 에 저장 되 어 있 습 니 다.만약 에 모든 topic 을 reply 의 관 계 를 메모리 에 넣 으 면 많은 메모리 가 소모 되 고 이렇게 많은 메모리 가 실제로 낭비 되 는 것 입 니 다.왜냐하면 대부분의 topic 는 활성화 되 지 않 기 때 문 입 니 다.게다가 topic 에서 reply 까지 의 매 핑 관 계 는 매우 중요 하기 때문에 우 리 는 이러한 관 계 를 지속 시 켜 야 한다.마지막 으로 우 리 는 이 맵 관 계 를 색인 이 라 고 부 를 지,아니면 카 산 드 라 에 저장 할 지 결정 합 니 다.필요 할 때 만 카 산 드 라 에서 색인 을 redis 에 불 러 온 다음 에 redis 페이지 를 이용 하여 조회 합 니 다.이렇게 되면 redis 는 페이지 조 회 를 지원 하 는 강력 한 캐 시가 되 었 다.
블록 캐 시
아주 긴 주제 에 대해 redis 에 새로 불 러 오 는 것 도 상당 한 시간 이 걸 립 니 다.우 리 는 조각 을 나 누 어 이 문 제 를 해결 합 니 다.우 리 는 색인 을 4800 개의 값 으로 나 누 어 다른 데이터 구조 로 색인 길이 와 색인 을 두 번 째 조각 에서 시작 하 는 각 조각의 시작 값 을 기록 합 니 다.
업 데 이 트 된 색인 을 업데이트 할 때 이 분 편 정 보 를 업데이트 합 니 다.각 분 편의 머리 를 기록 하 는 것 은 카 산 드 라 에서 분 편 을 불 러 오 는 데 편리 하도록 하기 위해 서 입 니 다.
조회 할 때 페이지 조 회 를 특정한 영화 의 특정한 색인 값 으로 바 꿉 니 다.필름 의 크기 가 페이지 사이즈 보다 크 고 페이지 사이즈 에 의 해 정 제 될 수 있 을 때 이 전환 은 매우 간단 하 다.왜냐하면 페이지 가 모두 특정한 필름 에 떨 어 지기 때문이다.우리 가 필름 크기 를 4800 으로 설정 한 것 은 바로 이 값 이 1015,20,25,30,40,60,80,100 200 등 많은 상용 페이지 크기 로 정 리 될 수 있 기 때문이다.필름 을 너무 많이 나 누 면 메모리 가 낭비 되 고,필름 을 너무 작 게 나 누 면 필름 이 너무 많다.
이 페이지 가 있 는 조각 을 계산 한 다음 에 필요 한 색인 세그먼트 를 redis 에 불 러 오고 redis 의 페이지 를 이용 하여 결 과 를 찾 습 니 다.이렇게 하면 활성 화 된 색인 세그먼트 만 redis 메모리 에 불 러 옵 니 다.
my sql 로 색인 효 과 를 지속 시 키 는 것 도 유사 하 며,검색 이 더욱 편리 합 니 다.
총화
제품 이 받 아들 일 수만 있다 면 임의의 페이지 를 사용 하지 말고 임의로 이동 합 니 다.빠 른 페이지 조회 가 필요 할 때 redis 의 SortedSet 을 사용 할 수 있 지만 메모리 크기 와 지속 화 문 제 를 주의해 야 합 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
보조금 신청서 작성이 자습서에서는 사용자가 보조금을 신청할 수 있는 애플리케이션을 빌드하는 방법을 보여줍니다. 이 게시물에서는 MySQL 데이터베이스에 연결, SQL 연결, 암호 해싱 및 코드 기반 모듈화와 같은 개념을 보여줍니다. ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
