MongoDB 데이터베이스 조회 성능 40 배 향상 경력 공유

머리말
데이터베이스 성능 은 소프트웨어 의 전체적인 성능 에 중요 한 영향 을 미친다.본 고 는 MongoDB 데이터베이스 조회 성능 이 40 배 향상 되 었 다 는 경험 을 공유 하고 관심 이 있 는 친구 들 은 참고 학습 을 할 수 있다.
배경 설명
1.데이터베이스:MongoDB
2.데이터 세트:

A:필드 수가 일정 하지 않 습 니 다.여기 서 주로 사용 하 는 두 개의 UID 와 Date

B:세 개의 필드,UID,Date,Actions.그 중에서 Actions 필드 는 260 요소 JSON 배열 을 포함 하고 JSON 대상 마다 6 개의 필드 가 있다.모두 800 만 건 정도 의 수치 가 있다.
3.업무 장면:평균 수량 구하 기

조합 조건 을 통 해 A 데이터 시트 에서(UID,Date)목록 을 조회 하고 최대 수만 개의 기록 을 포함 할 수 있 습 니 다

4.567917.그리고 1 단계 결과 로 B 에서 해당 하 는 데 이 터 를 조회 합 니 다4.567917.두 번 째 결과 로 Actions 의 특정한 위치 에 있 는 요 소 를 계산 합 니 다.
진화 과정
여기 서 Python 프 리 젠 테 이 션 을 사용 합 니 다.
가장 직접적 으로 생각 나 는 방법.
위의 업무 장면 묘사 에 따 르 면 가장 생각 하기 쉬 운 해결 방법 은

from pymongo import MongoClient
#      
db = MongoClient('mongodb://127.0.0.1:27017')['my_db']

#         A   
filter = {...}
#   Collection A
a_cursor = db.a.find(_filter)
a_docs = [x for x in a_cursor]

#        
count = 0
total = 0
#            21 
index = 20
#   Collection B，     
for a_doc in a _docs:
 b_doc = db.b.find_one({'uid':a_doc['uid'], 'date': a_doc['date']})
 #            ，   
 if b_doc is not None:
 total += b_doc['actions'][20]['number']
 count += 1

 #     
 if count > 0 :
 avg = total/count

실현 난이 도 는 당연히 가장 낮 지만 전체 임무 가 첫 번 째 단계 에서 1 만 개 정도 만 되 돌 아 왔 을 때 소모 하 는 시간 은 놀랍게도 38 초 에 달 했다.물론 이것 은 이미 색인 을 추가 한 결과 이다.그렇지 않 으 면 결 과 를 얻 을 수 없 을 것 이다.
조회 횟수 감소
병목 이 뚜렷 하 다.순환 에서 Collection B 를 조회 하면 네트워크 비용 이 증가 하고 자 연 스 럽 게 시간 도 증가한다.만약 에 한 번 에 모든 결 과 를 조회 하면 자 연 스 럽 게 효율 을 크게 높 일 수 있다.즉,나 는 첫 번 째 결 과 를 조건 으로 한꺼번에 전달 하고$in 작업 을 할 것 이다.근 데 어떻게 해 야 돼 요?uid 와 date 에서 각각$in 작업 을 하면 되 돌아 오 는 결 과 는 두 사람 이$작업 을 단독으로 하 는 집합 입 니 다.이것 은 요구 와 맞지 않 음 이 분명 합 니 다.
위의 분석 을 통 해 막 다른 골목 으로 들 어간 것 같다.사실 답 도 기본적으로 나 타 났 습 니 다.위의 요 구 를 만족 시 킬 수 있 는 필드 가 필요 합 니 다.그러면 이 필드 는 uid 와 date 의 합 체 이 고 uid 라 고 명명 합 니 다.date。uid_date 는 새로운 필드 입 니 다.B 에 존재 하지 않 습 니 다.사용 하기 전에 데이터베이스 에 있 는 데 이 터 를 처리 해 야 합 니 다.
처리 완료 개조 프로그램:

#                 
uid_date_list = []
for a_doc in a_docs:
 uid_date_list.append(a_doc['uid'] + '_' + a_doc['date'])

#   B
b_cursor = db.b.find({'uid_date':{'$in':uid_date_list}})

#         ，    
...

이번 개 조 는 상당히 시간 이 걸 리 는데,주로 전기의 데이터 처리 이다.코드 개조 가 끝 났 으 니 실행 해 보 세 요.
그런데...그런데...45 초.
내 가 뭘 잘 못 했 는데?!
반환 레코드 수 증가
나 는 여전히 위의 최적화 사고방식 이 옳다 고 굳 게 믿는다.지금 데이터베이스 가 어떤 단 서 를 줄 수 있 는 지 보 자.
데이터베이스 서버 에 로그 인하 여 MongoDB 로그/data/mongodb/logs/mongod.log 를 찾 습 니 다.자세히 찾 아 보 니 데이터 세트 B 를 조회 할 때 getMore 명령 이 많 았 습 니 다.이상 하 다.나 는 일회 성 조회 인 데 왜 getMore 가 있 는 지.
빨리 찾 아 보 세 요공식 문서그리고 다음 내용 을 발 견 했 습 니 다.

batcSize 인 자 는 매번 되 돌아 오 는 개수,기본 101 개 를 지정 합 니 다.그럼 이게 문제 인 것 같 습 니 다.pymongo 문 서 를 찾 아 보 세 요.이 인 자 를 설정 할 수도 있 습 니 다.큰 것 으로 설정 하 세 요.10000.
재 개조 절 차 는 다음 과 같다.

#   batch_size
b_cursor = db.b.find({'uid_date':{'$in': uid_date_list}}, batch_size=10000)

이번 엔 됐 겠 다.
응,좀 나 아 졌어.20 초 정도 로 내 려 갔 어.하지만 1 초 만 에 20 배 밖 에 차이 가 나 지 않 는 다.
반환 값 마이너스
당일 포기 할 수 없습니다.로 그 를 통 해 단 서 를 계속 찾 아 보 니 getMore 가 많 습 니 다.각 방면 의 검색 을 통 해 mongodb 가 매번 최대 16M 의 기록 을 되 돌려 주 는 것 을 발견 하 였 으 며,getMore 로그 의 비 교 를 통 해 확실히 이와 같다 는 것 을 발견 하 였 다.B 에서 각 기록 의 과거 가 방대 하기 때문에 매번 수백 개의 기록 만 있 을 수 있 기 때문에 한 번 에 다시 돌아 가 려 면 매번 돌아 오 는 기록 수 를 줄 여야 한다.계산 할 때 특정 색인 위치 에 있 는 데이터 만 사 용 했 기 때문에 이 기록 만 되 돌려 주면 된다.
마지막 코드 는 더 이상 쓰 지 않 겠 습 니 다.구체 적 으로 참고 할 수 있 습 니 다공식 문서 의 인 스 턴 스
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 면 댓 글 을 남 겨 주 십시오.