A집합과 B집합이 있음
각 원소는 Id를 가지고 있음
어떤 원소가 집합에 속하면 y, 속하지 않으면 n이라고 하겠음
그러면 어떤 원소의 상태를 (A집합, B집합) 로 표시하면
(y,y), (n,y), (y,n), (n,n) 이렇게 네 개가 나옴 [여기선 (n,n)은 절대 나올일이 없으니 빼겠음]
이때 원소의 아이디가 같다면 (n,y)+(y,n)으로 (y,y)를 만들 수 있음
y랑 n이 만나면 y가 됨
이제 어떤 원소들을 1그룹, 2그룹으로 분류하고자함
각 그룹은 각 원소의 상태를 가지고 있음
원소들의 상태는 위와 같은 방법으로 (1그룹, 2그룹)으로 나타낼 수 있음
모든 상태는 다음과 같이 나올꺼임
((y,y), (y,y)), ((y,y), (y,n)), ..., ((n,y),(n,y)) ..., (null,(n,y))
null은 다른 그룹에 Id가 같은 원소가 없는 경우
1그룹은 중심그룹이며 2그룹의 데이터를 이용해 항상 최신상태를 유지해야함
그러니깐
(null,(y,y)) 상태라면 어떤 연산를 통해 ((y,y),(y,y))로 만들어야되고
((y,n),(n,y)) 상태라면 어떤 연산을 통해 ((y,y),(n,y))로 만들어야함
이제 상태가 업데이트된 1그룹 원소들을 어떤 연산를 통해 추출하고자함
이때 추출한 원소들을 3그룹이라고 하겠음
문제는 집합이 무한정 늘어날 수 있음 A,B,C,D,... 등등
집합이 늘어날 수 있다는 전재하에 코딩을 해야함
뭔가 어렵게 설명한 것 같은데
간단하게 말하면 A집합이 히토미, B집합이 익헨임
1그룹이 메인 디비고, 2그룹이 방금 크롤링한 최신 정보들, 3그룹이 업데이트된 부분임
1그룹은 서버에 저장하고 3그룹은 사용자한테 제공해야함
지금 최적화안한 3그룹 데이터 하나 평균 크기가 148kb정도 되는데
한시간에 1번, 하루에 24번, 한 달에 31번 이니깐 한달이면
100메가 정도됨
30분에 한 번, 10분에 한 번씩 한다면 몇 백메가로 늘어날꺼임
만약에 위에서 말한 최적화를 제대로 적용하면 평균 크기가 대폭 줄어들꺼임
히토미가 익헨데이터를 미러링하고 업데이트하는 주기가 대략 4시간에 한 번씩임
미러링도 전부다 하는게 아니고 위에서 빨간색으로 표시해둔 타입만 미러링함
전체가 965,348개고 빨간부분은 558,869임
익헨 작품은 대략 57.8% 확률로 히토미로 미러링된다는 말임
왜 히토미를 같이하냐? 익헨만 하면 되지 않냐라고 할 수 있는데
익헨에서 안보이는 작품들이 많음
근데 그게 히토미에는 있음
익헨에서 안보이는 작품들이 다시 보이는 경우도 있음
아래 20페이지를 긁는 것도 그 이유 중 하나임
또 미러링 중에 누락되는 것도 있기때문에 확인을 해야함
익헨은 전체 이미지 불러오는 속도가 느리고 아이디가 있어야 쓸 수 있음
히토미는 전체 이미지 불러오는 속도가 익헨보다 매우 빠르고 아무나 볼 수 있음
이걸 서버에서 확인안해주면 결국 클라에서 확인을 해야하는데
히토미에서 찾고 없으면 => 히요비 => 이/익헨
이렇게 대충 사용자가 설정한 순서대로 찾기 때문에 로딩이 매우 느려짐
익헨은 한 시간에 20개 정도의 게시물이 올라옴
20개의 데이터는 약 7.4kb임
한 시간에 한 번씩 데이터를 업데이트한다고하면
1시간째 20개 => 7.4kb
2시간째 20개 => 7.4kb
3시간째 20개 => 7.4kb
4시간째 20개+80*0.578개 => 24.5kb
5시간째 20개 => 7.4kb
...
이렇게 3그룹 데이터가 만들어짐
4시간당 약 46.7kb 데이터가 생산됨
만약에 최적화를 아예 안한다면
1시간째 400개 => 148kb (400개인 이유는 익헨 페이지를 한 번에 20페이지를 읽기때문)
2시간째 400개 => 148kb
3시간째 400개 => 148kb
4시간째 400개+80*0.578개 => 194kb
5시간째 400개 => 148kb
..
니깐 4시간당 638kb 데이터가 생산됨
최적화 안한거하고 14배가 차이가남
여기서 80*0.578을 없앨 수 있는데 4시간마다 데이터를 제공하면됨
근데 4시간마다 업데이트 되는건 너무 느림
그렇다면 네 시간마다 체크포인트를 만들어 놓고 이전 23시간 데이터를 요청하면
4시간*7개+1시간*3개, 총 10개를 넘겨주면 80*0.578*3개를 없앨 수 있음
80*0.578을 완전히 없앤다면 한달에 기존 33.9mb에서 8.3mb가 추가로 줄어들어서 25.6mb임
지금은 최적화 안한거 쓰는중 (메타데이터: https://koromo.xyz/version.txt)
아직 구현못했음
확장성있게 코딩해야되는데 어디서부터 건드려야될지 모르겠음
관련분야 뭐 공부해야됨?
백엔드가 원래 이런것도 하는 곳이냐
익헨에 안올라오는데 히토미에만 올라오는게있다고?
정확하게는 익헨에 올라왔다가 숨겨진거임
아
와;;
그리고 보통 현업에선 크롤링으로 서비스제공할일이 별로없으니 저런고민 안할듯...
너무 길어서 제대로 못 읽었는데 백엔드가 그런 거 하지 소위 빅데이터에 데이터 파이프라인 데이터 스트리밍 뭐 그런 것들
백엔드에경의를표하십시오프론트땔감
님 군대가는거임?
데이타 흐름을 그려봐야할듯.. 2 -> 1 -> 3그룹순으로가는거임? - dc App
ㅇㅇ [2 -> 1] [1,2 -> 3]
400개 읽고 중복 삭제는 안 함?
그걸 확장성있게 제대로 구현하는게 핵심임
디비에 히토미익헨 둘 다 있으면 무시, 익헨이나 히토미 둘 중 하나만 있다면 꺼내서 업데이트하고 디비에 넣어야함, 디비에 없는 작품이면 그냥 넣으면됨 두 개 있을땐 이거 세 개만 고려하면 될 듯
근데 글 읽으면서 궁금한게 짧은주기로 요청하면 안됨? 무슨 문제있나
서버가 구려서 그렇게 못굴림
아ㅋㅋ
그리고 히토미는 한 번에 8천개 요청하고, 익헨은 한 번에 20개 요청
이거 해결했음 미래의 코로모 선생님께서 해결한 문제니까 글 내려주세요.
야매로 대충 구현해둠