SOOJLE
수즐 커뮤니티
수즐 커뮤니티
  • SOOJLE Document
  • 프로젝트 요약
  • Untitled
  • 프로젝트 개요
    • 프로젝트 소개
    • 추진 배경 및 필요성
    • 프로젝트 내용
      • 기능적 요구사항
      • 비기능적 요구사항
    • 개발환경 및 팀 구성
    • 워크플로우
      • 계획 수립 & 설계
      • 데이터 수집 및 정규화
      • 인공지능 개발
      • 서비스 모듈 개발
      • 성능 평가 및 보고
    • 프로젝트 예산 내역
  • 사전조사 & 의사결정
    • 사전조사
      • 재학생 대상 사전조사
      • 수집 URL 대상 목록
        • 세종대학교 직할
        • 세종대학교 학과
        • 공식 공지사항
        • 세종대 평생교육원
        • 외부 웹사이트
      • 학습 모델 사전조사
        • LSA - 잠재 의미 분석
        • LDA - 잠재 디리클레 할당
        • Word2Vec - 워드투벡터
        • FastText - 패스트텍스트
    • 의사결정
      • 사용자 인증 방식 의사결정
      • 데이터베이스 의사결정
        • MySQL vs MongoDB 성능 분석
      • 토픽별 의사결정
      • 부가 기능 의사 결정
  • 프로젝트 설계
    • 시스템 구조 설계
    • 핵심 기능 설계
      • 데이터 크롤러 설계
      • 게시물 토픽 정의 및 분류
      • 사용자 관심분야 측정
      • 뉴스피드 설계
        • 사용자-문서 유사도(Recommendation Score)
        • FaS (관심 분야 및 유사도 측정 - 추가)
        • 토픽 뉴스피드 목록
      • 검색 알고리즘 설계
        • 검색 알고리즘 1차 설계
        • 검색 알고리즘 1차 개선안
        • 검색 알고리즘 2차 설계
    • 요구사항 목록
      • DB 요구사항
      • 기능 요구사항
      • 품질 요구사항
      • 관리 요구사항
  • DB
    • 구조 설계
    • 테이블 명세
  • 데이터 크롤러
    • 데이터 크롤러 개요
    • 크롤링 URL 선정
    • 크롤러 구현을 위한 사전조사
    • 크롤러 개발 과정
      • 크롤러 프로그램 설계
      • 크롤러 규격화
      • 크롤러 정규화
      • 데이터 정제 과정
      • 에러 핸들러 구현
      • 배포 환경 이식을 위한 Porting
    • Issue & Exception
    • 결과 보고
  • 인공지능 개발
    • 인공지능 개발 개요
    • NLP 스터디
      • Bag of Words(BoW)
      • Document Term Matrix(DTM)
      • TF-IDF(Term Frequency-Inverse Document Frequency)
      • 문서 유사도(Document Similarity)
    • 데이터 전처리 과정
    • 개발 과정
      • 토크나이저 구현
      • LDA 모델 학습 및 구현
    • LDA 학습 모델링
      • 1차 파라미터 튜닝 결과 (NUM_TOPICS)
      • 2차 파라미터 튜닝 결과 (NUM_TOPICS)
      • 3차 파라미터 튜닝 결과 (NUM_TOPICS)
      • NUM_TOPICS 파라미터 의사결정
      • 4차 파라미터 튜닝 결과 (PASESS, ITERATION)
      • 최종 학습 모델 명세
    • Word2Vec(FastText) 학습 모델링
    • Issue & Exception
    • 성능 분석 결과
  • BackEnd
    • 서버 구축 및 배포
      • SOOJLE 서버 구조
      • 상용 서버 (UWSGI + NGINX) 구축
      • HTTPS 서버 구현
    • API 문서 개요
    • API 목록
      • Analysis
      • Auth API
      • Newsfeed API
      • Post API
      • Search API
      • Admin API
    • 세종 Auth API
    • 통계 기능 설계
    • Issue & Exception
    • 성능 분석 결과
  • FRONTEND
    • 프론트엔드 설계 개요
    • 디자인 설계 의사결정
      • 디자인 컨셉 및 기능 정의
      • 컴포넌트 디자인
      • Logo Variation
    • 화면 흐름도
    • 페이지 UI 명세
      • Main Page
      • Header
      • Footer
      • Mobile Control Bar
      • Login Page
      • Timeline Page
      • Menu Page
      • Hyperlink Icons Page
      • Search Component & Mobile Search Modal
      • Search Page
      • Post Block
      • Snackbar
  • 프로그램 배포
    • 프로그램 개요
    • 시스템 아키텍쳐
    • 주요 기능 및 명세
    • 프로그램 테스트
    • 구현 결과물 배포
  • 마무리
    • References
  • SOOJLE AI
  • SEJONG AUTH
  • IML Tokenizer
  • SOOJLE Crawler
  • SOOJLE Frontend
  • SOOJLE Backend
Powered by GitBook
On this page
  • MongoDB Cursor connection error
  • MongoDB의 json화 처리
  • MongoDB 16Mbytes Limit

Was this helpful?

  1. BackEnd

Issue & Exception

Previous통계 기능 설계Next성능 분석 결과

Last updated 5 years ago

Was this helpful?

MongoDB Cursor connection error

Pymongo를 통하여 Python으로 DB의 정보를 불러오게 되면, 다음과 같이 cursor로 반환이 된다.

이는 현재 Pymongo 쿼리를 통하여 요청한 데이터 전부를 DB에서 불러온 것이 아니라, Pointer를 통하여 MongoDB의 해당 객체를 가리키고 있다. 따라서 이를 그대로 Front로 반환을 하게 되면 Error가 발생한다.

이를 해결하기 위해서는 다음과 같은 두 가지 방법이 존재한다.

  • Python 자체에서 list() 리스트화

  • dumps

list()화를 시키게 된다면, front에서도 온전한 딕셔너리 형({}) json 데이터를 그대로 받게 된다. 하지만 두 번째 방법인 dumps로 파싱을 시키고 보내게 되면 json형 데이터로 변경되긴 하지만 자료형은 string으로 처리되어서 하나의 string으로 받게 된다. 이럴 경우는 front에서 따로 파싱 작업이 요구된다.

MongoDB의 json화 처리

result = db['test_posts6'].find_one(
		{
			'_id': ObjectId(post_obi)
		}, 
		show_dict
	)

Pymongo에서 MongoDB와 커넥트 하여 데이터를 불러오게 되면, 기본적으로 MongoDB의 ObjectID, Date 등의 자료는 아래와 같이 오브젝트 형식으로 Python으로 불러오게 된다.

이들의 자료형은 Python에서는 인식을 하여 Backend에서 작업 시에는 크게 문제는 없다. 하지만 Front로 반환을 하면 Error를 발생한다.

이를 해결하기 위해서는 두 가지의 주된 방법이 있다.

  • 전체 dumps로 인한 string Json화

  • 특정 Object만 dumps 혹은 string화

SOOJLE은 Backend에서 사용자 추천을 위한 연산을 돌리기 때문에, 요청한 해당 API가 DB에서 불러온 데이터를 하나하나 반복문을 통하여 접근할 경우에는 특정 Object만 dumps를 시켜주었다.

애초에 Backend에서 DB에서 불러온 데이터들을 접근하지 않는다면, 바로 dumps를 시켜서 Front에 반환해준다.

MongoDB 16Mbytes Limit

Mongodb의 Document는 개당 최대 16Mb로 제한이 걸려있다.

따라서 Soojle의 Log기록에 문제가 발생한다. 특히, 사용자 검색기록, 좋아요 한 게시글, 접근한 게시글, 접근한 뉴스피드 등 다양한 log를 기록하는데, 이는 실시간으로 사용자의 액션에 따라 데이터 량이 증가하기 때문에 16Mb를 넘기는건 시간문제이다.

따라서, 이를 해결하기 위한 대책은 다음과 같다.

  • user테이블에는 특정 X개의 로그 개수를 맞춰놓는다.

  • 특정 X개의 로그가 기록 되었을 때에는 Queue형태로 로그가 기록된다. (FIFO)

즉, 특정 X개가 꽉 찼을 시에는 가장 오래된 것을 빼서 새롭게 들어온 log를 기록한다. 리스트에서 빠진 기존의 log는 새로운 Collection의 테이블로 이동하여 계속 보존하는 방식을 취한다.