어젠 몸살 기운이 있었지만, 다행히 수집기를 아파지기 전에 완성하고 돌려놓고 있었기 때문에 나름 유의미한 양의 데이터를 수집 했다. 대충 로그를 봐도 이러하다.
status = 해당 윈도우의 수집 상황
start_timestamp = 해당 윈도우의 시작 timestamp
end_timestamp = 해당 윈도우의 끝 timestamp
window_millis = window단위(millis, 현재는 20초로 고정)
first_timestamp = 수집된 실제 데이터의 첫 timestamp
last_timestamp = 수집된 실제 데이터의 마지막 timestamp
tx_count = transaction 갯수
순서대로,
status, start_timestamp, end_timestamp, window_millis, first_timestamp, last_timestamp, size(blob의 byte크기), tx_count
약 6일 반정도, 거의 일주일 분량에 달하는 Tron 상의 테더의 움직임을 알 수있는 데이터가 확보 되었다. 저장 형식은 SQLite3, gzip을 이용해서 주요한 데이터는 json에서 압축하여 보관 되어 있다. 인덱싱은 딱히 신경 쓰지 않았다. 어짜피 flattening 코드를 만들어야하는데, 각종 edge-case(예외 상황)에 대응 하려면 이정도의 데이터는 있어야 실전에서 잘 쓸 수 있을 것이다.
현재 수집기는 Single-Thread, async기술 없이 구현되어 있다. 그럼에도 일단 할당된 free-tier의 절반 정도는 소비 가능하긴 하다. 하지만 당연히 반대로 이야기하면 잘만 하면 지금의 2배 속도로, 아니 가능하다면 수집 속도를 자유롭게 늘릴 수 있어야 할 것이다...
window의 현재 제일 첫 ts
window의 현재 마지막 ts
throughput ~ 4day data per day 정도 일 것이다. 아주 엄밀하진 않겠다만... 일단 그렇다고 하자. 보면 대부분은 잘 수집 되었지만 가끔 1000건에서 막힌 경우도 있다. 이런 경우는 재수집이 필요한데, 중간중간에 로그를 살펴보아서 이런 경우가 어떤 경우에 일어나는지는 알고 있다.
지금 로직에서는 end_time = last_time일때 edge-case처리가 되어 있지 않다. 이를 해결해야한다.
-- 추가 검증
SELECT status, start_time, end_time, window_millis, first_timestamp, last_timestamp, tx_count
FROM RawTronGridUsdtTransfer
WHERE status = 'partial' AND end_time != last_timestamp;
해당 query의 건수가 0건 임을 판명, 실제로 가설이 맞다는 것으로 보인다. chatgpt의 제안도 있는데, end_time을 exclusive하게 바꾸라는 이야기가 있어서 그렇게 구현을 바꿀 예정이다.