어제는 많은 진전이 있던 날이다. 지지부진하던 프로젝트에 나름 큰 발걸음이였다. 파싱에도 익숙해져 유플레이의 파싱페이지의 오류를 수정하고, 에픽스토어의 파싱도 마무리했다.
큰 성과라 하면 페이지네이션된 페이지를 복수파싱하는 방법을 알게 되었다.
whole_source = ""
for page_number in range(0, 3):
url = 'https://store.steampowered.com/search/?specials=1&filter=topsellers&page=' + str(page_number)
response = requests.get(url)
whole_source = whole_source + response.text
soup = BeautifulSoup(whole_source, 'html.parser')
games = soup.select('div#search_resultsRows > a')위는 스팀의 파싱페이지이다. whole_source는 크롤링할 페이지의 합산을 변수로 지정한것이다. for문을 사용해서 0,시작페이지부터 page=2, 3번째 페이지까지 합산한 된것이 whole_sorce로 들어간다. page의 최댓값을 파징하지 않은 이유는 불필요한 정보가 많이 들어갈것같아서이다.
애시당초 연쇄할인마는 나혼자 사용한다는 생각으로 시작한 프로젝트였다. 그러니 비주류 게임들은 굳이 추가할 필요가 없으니 총3페이지로 크롤링을 마무리한것이였지만, 만약 여러 사람들이 이용하게 된다면? 그렇다면 조금더 선택지를 늘려야한다. 그러면 스팀페이지 하나에서도 할인목록을 전부 긁어와야된다. 험블번들, 에픽스토어. 유플레이. 그리고 수많은 리셀러사이트..
db에 축적되는 양은 기하급수적으로 늘어날것이며 이것을 더 면밀히 관리해야한다. 지금은 단순히 key값을 platform으로 설정해 구별하고있지만, 수많은 db에서 key값으로 분류해서 정보를 가져오는건 굉장히 인내심이 필요할 사이트가 되지 않을까? 괜히 그런생각을 하면서 스승이 저번에 말했던
‘mongoDB는 nosql이다. mysql을 가르치고 싶었다.’
라고 말한게 떠올랐다. 혼자 살짝 들여다본건, 테이블형식으로 db를 효과적으로 정리하는 모습이였는데, 만약 후에 프로젝트를 수정할 일이 생기면 mysql을 좀더 공부해보고 통으로 바꾸는 방향으로 생각해봐야겠다.
또 하나, 재밌는 점은 여러 페이지를 크롤링하며 느낀건데 각 페이지마다, 그러니까 개발자마다 class 와 id를 지정하는 방식이 다르다. 스팀같은 경우는 굉장히 깔끔하고 구별하기 쉽게 정리되어 있었고, 유플레이는 그것보단 좀 난잡했지만 그래도 알아볼만 했다. 험블번들같은 경우는 최악이였다. id를 거의 사용하지 않고 클래스에 난수생성된 코드를 사용하는 것 같다.
모든 플랫폼에서 파싱하는 작업이 끝나면 본격적으로 html 작업에 들어갈텐데 고질적인 문제인 class와 id의 이름을 지정해주는 방식에 대해 자세히 검토해야겠다.
오늘의 작업도 여타 다를바 없다. 아직 긁어와야될 사이트가 수두룩하고, 사이트마다 html의 구성방식이 천차만별이니. 3개 사이트 크롤링을 목표로 잡는다.
