[ward] 많은 수의 데이터 수집 관련 이슈

[egaoneko]

[URL : https://github.com/egaoneko/ward/issues/52 ]

현재 ward는 facebook graph api를 통해 페이스북 공개 그룹의 데이터를 가져오고 있습니다.

수집한 데이터를 Celery + Redis를 사용해 저장하는 방식으로 구현하여 사용하고 있습니다.

현재 이미 수집된 글의 경우 update의 경우, 큰 문제없이 작동하고 있지만,

새로운 그룹을 수집을 수집할 경우, 많은 메모리 사용으로 인해 서버에서 돌리지 못하고 수집 부분만 따로 개인 컴퓨터로 수행하는 상황입니다.

게시글(api의 call 제한을 피하기 위해 Celery를 사용하지 않고 있습니다.)이 순차로 저장되는 동안, Celery로 저장되는 댓글 부분이 부담되는 상태입니다.

게다가 Auto Scaling로 서버가 늘어나면, 각 서버의 Celery의 중복된 작업들 때문에 DB서버에도 무리를 주는 것 같습니다.

이 부분을 해결하기 위해 생각해보았는데, 데이터를 수집하는 서버와 데이터를 사용하는 서버를 분리하여 두고, 데이터를 사용하는 서버에서 데이터를 수집하는 서버로 요청을 보내는 식으로 변경하는 방식을 생각하고 있습니다.

또한, 수집 저장방법을 먼저 게시글을 전체 저장하고, 수집한 게시글을 순회하면서 댓글을 저장하는 방식을 생각하고 있습니다.

[egaoneko]

@Rumo-Arf 저희도 쿼리 회수 제한이 상당히 부담스러운 상황이에요. 쿼리 회수 제한을 피하면서, 최대한 속도와 정확성을 보장하는 방식이 어렵네요. :(

[egaoneko]

@Rumo-Arf facebook graph api도 페이스북 쪽에서 바꾸기만하면 :( 저희는 win32 API를 사용해본 적이 없어서 어느정도 속도 차이가 나는지를 모르겠네요. :) Parse라는 라이브러리는 처음 보네요. 한번 확인해보겠습니다~

[egaoneko]

@Rumo-Arf 재미있는 라이브러리네요. 참고해보도록 하겠습니다. 저는 이전에 가입자 수랑 언제 가입했는지 알아보기 위해서 celenium을 크롤링했었어요. Facebook이 해당 데이터는 제공을 안해주더라고요. 근데 이 경우에도 이 방법을 써도 페이스북이 전부 제공해주지 않으면 제한된 데이터를 문제가 있더라고요. 더보기 방식으로 내려갔는데 8000명에서 더 이상 버튼이 생기지 않더군요.

[egaoneko]

@Rumo-Arf 저는 타임라인 저 너머로 사라진 글 중에 주목 받았던 글이 어떤 글이 있었을까 궁금한 부분도 있어서요. 이 경우에는 facebook graph api에서 도망칠 수 가 없겠네요. 하하하..

[egaoneko]

@Rumo-Arf 정책이 바뀐다면... 오래된 데이터의 수집을 포기하고 말씀하신 방법들로 구현해야되는 상황으로 바꿔야겠네요. ㅠㅠ;;

[egaoneko]

@Rumo-Arf https://developers.facebook.com/products/parse/ 이거 말씀하시는게 맞으신가요? :)

https://developers.facebook.com/docs/graph-api/advanced/rate-limiting 이대로라면 유저 당 60분에 200이라는데... 대충 실험 했을 때는 매 쿼리마다 1초의 시간을 주면 block이 일어나지는 않더라고요. :)

[egaoneko]

@Rumo-Arf 앗.... 밑에 말씀하신게 facebook graph api를 말씀하시는 줄 알았어요. parse는 아직 사용방법을 보는 중이에요. :)