mongoDB collection량에 따른 속도

한가지 더 첨언하자면...

예를 들어 크롤링한 데이터로 어떤 서비스를 구축한다고 했을때 크롤링한 데이터를 실시간 수집하는 DB(1)를 구축하고 이 서버에 스케쥴러가 동작하여 이를 최종 데이터로 검증(중첩처리, 오류처리... 등등) 하는 봇이 하나 동작하게 하고 여기서 검증된 데이터가 실제 DB서버(2)에 반영되는 방식으로 구축되는 경우도 있습니다.

이렇게 되면 DB서버가 2개가 되고 중간 브리지 역할을 하는 봇프로그램이 하나 있어야 하고 얘는 스케쥴러로 동작합니다. 

또한 제 경험상 한가지 더 말씀을 드리자면 뭔가 서비스를 최초 기획할때 DB의데이터양을 1년넘게 예상해서 당장 현재 쓸데 없는 시간을 낭비하는 경우도 많습니다. 서비스 오픈시 몇명이 쓸지 얼마나 많은 데이터가 수집될지 모르는데 1년뒤 2년뒤의 상황에 대비하기 위해 현재 인력과 자원이 부족한데도 여기에 올인하여 낭비를 하는경우가 많습니다. 이런 서비스는 보통 1년, 2년까지 못가는 경우가 많습니다. ㅎㅎㅎ 이런 부분도 한번 곰곰히 생각해봐야할 문제입니다. 

박사님! 친절한 답변 감사드려요 ^^ 이제 막 공부하는 초보라 궁금한 것들이 많네요~ ㅎㅎ 

DB의 궁극적인 부분은 질문하신것과 마찬가지로 DB의 퍼포먼스를 얼마나 효율적으로 사용하고 결과를 돌출해내느냐에 있습니다. 사실 그 부분은 정답도 없고 상당히 노하우가 많이 필요로 하는 분야기도 합니다. 그래서 DBA 라는 전문직종이 있고 실무에서 연봉이 하늘을 찌르는 금액을 받기도 합니다. ㅎㅎㅎ

제가 아는 선에서만 답변을 드리자면 일단 어떤 DB던 데이터의 양이 많아지면 그만큼 느려집니다. 그럼 개발자 혹은 DBA 입장에선 이를 어떻게 효율적으로 빠른 결과를 얻어낼지를 고민하게 되고 그때부터 점점 더 깊은 지식과 경험을 필요로 하게 됩니다.

일단 몽고DB는 하드웨어의 메모리 성능에 상당히 큰 영향을 받습니다. 웹서비스던 앱서비스던 어떤 서비스던 DB가 구동중인 서버의 하드웨어 스펙이 가장 좋아야 하는건 기본입니다. 

서비스예시를 들었던 부분을 생각해보자면 1000개/일 이면 30일이면 약 3만개정도의 데이터가 쌓이고 1년이면 365,000 개의 데이터가 쌓입니다. 이정도는 사실 데이터의 크기로 보면 큰 사이즈는 아니라고 생각합니다. 그런데 백만개가 넘어가고 이게 몇백만개, 몇천만개가 되면 이때부턴 DB 자체로만 소화하기엔 문제가 생길 수 있습니다. 또한 DB에 insert 하는 비중이 큰지 select 혹은 find 하는 비중이 큰지에 따라서도 구조를 생각해봐야 합니다. 몽고DB는 insert 시 데이터락이 걸리는데 만약 insert 되는 데이터가 엄청나게 많으면 다른 서비스에 지장을 줄 수 있게 됩니다.

내부적인 크롤링 데이터는 어떻게 수집을 할것인지 그리고 데이터의 생명력에 따라 말씀하신것처럼 월별 혹은 년별로 데이터베이스를 새로 갱신할지도 서비스의 특성에 따라 다르게 기획될 수 있습니다.

데이터베이스의 양이 많아 클라이언트쪽 검색에 영향을 미치는 경우에는 엘라스틱서치 같은 검색엔진을 따로 구현하여 검색에 드는 자원을 분산시키는 방법도 있습니다. 실제 많이 사용하는 방식중 하나입니다.