현재의 데이터 수집 모델은 crossref api에서 제공하는 offset을 이용하여 데이터를 수집하였으나, offset지정이 최대 10000 이었습니다.
그러나 키워드 하나당 1만개 이상의 데이터는 대부분 넘으며, 40만, 50만에 근접하는 데이터를 가지고 있는 경우가 많습니다. 더 많은 데이터를 엘라스틱서치에 수집하기 위해 api에서 제공하는 cursor를 이용해 새롭게 api크롤링 하는 모델을 만들었으나, 기존의 큐에서 1초에 한번씩 꺼내어 크롤링 하는 방식으로는 아래 와 같이 순차적으로 request를 받지 못하는 모습을 보입니다.
(원인은 한번 지정된 cursor는 변하지 않으며, 해당 cursor로 데이터를 요청하고, 받고, 재요청 하는 경우 다음 페이지의 데이터를 제공해주는 방식으로 예상하고 있습니다.)
즉 response를 받기전에 request 요청을 날리면 해당 request 가 누락 되는 현상이 발생하였습니다.
다음은 약 40만개의 데이터를 크롤링 해왔으나, 다음과 같이 몇개의 api요청만 정상적으로 받은 상황입니다.
(한번에 1000개씩, 약 400개의 api 요청을 보냈으므로 1000 * 400의 로그가 찍힐것으로 예상)
기대 결과
그렇다면 뒤에서 데이터를 저장하는 과정에서 해당 api 요청이 response 받고 reqeust를 보내고 받고 보내고를 반복해야합니다. 대략 한 요청당 10초가 걸리는것으로 측정됩니다,(위의 40만개의 경우 4000초 => 대략 1시간이 예상됩니다..
이를 보완하거나, 상시 서버에서 계속 데이터를 누적하는 형식을 사용해야 할 듯 합니다.
JunYupK
commented
1 year ago
이슈 내용
현재의 데이터 수집 모델은 crossref api에서 제공하는 offset을 이용하여 데이터를 수집하였으나, offset지정이 최대 10000 이었습니다. 그러나 키워드 하나당 1만개 이상의 데이터는 대부분 넘으며, 40만, 50만에 근접하는 데이터를 가지고 있는 경우가 많습니다. 더 많은 데이터를 엘라스틱서치에 수집하기 위해 api에서 제공하는 cursor를 이용해 새롭게 api크롤링 하는 모델을 만들었으나, 기존의 큐에서 1초에 한번씩 꺼내어 크롤링 하는 방식으로는 아래 와 같이 순차적으로 request를 받지 못하는 모습을 보입니다. (원인은 한번 지정된 cursor는 변하지 않으며, 해당 cursor로 데이터를 요청하고, 받고, 재요청 하는 경우 다음 페이지의 데이터를 제공해주는 방식으로 예상하고 있습니다.) 즉 response를 받기전에 request 요청을 날리면 해당 request 가 누락 되는 현상이 발생하였습니다.
다음은 약 40만개의 데이터를 크롤링 해왔으나, 다음과 같이 몇개의 api요청만 정상적으로 받은 상황입니다.
(한번에 1000개씩, 약 400개의 api 요청을 보냈으므로 1000 * 400의 로그가 찍힐것으로 예상)
기대 결과
그렇다면 뒤에서 데이터를 저장하는 과정에서 해당 api 요청이 response 받고 reqeust를 보내고 받고 보내고를 반복해야합니다. 대략 한 요청당 10초가 걸리는것으로 측정됩니다,(위의 40만개의 경우 4000초 => 대략 1시간이 예상됩니다.. 이를 보완하거나, 상시 서버에서 계속 데이터를 누적하는 형식을 사용해야 할 듯 합니다.