공개 궤도 데이터(CelesTrak GP)로 재본 데이터 파이프라인의 신선도·증분 처리 실험 · 갱신 2026-09-13 08:21 UTC
각 객체의 EPOCH가 지금으로부터 얼마나 지났는지. 원천 데이터 자체가 이미 하루 가까이 묵어 있다는 뜻이고, 수집 주기를 늘리면 이 위에 지연이 더 얹힌다.
직전 스냅샷과 비교해 궤도 요소가 실제로 바뀐 객체의 비율. 낮을수록 증분 처리의 이득이 크다.
왼쪽은 통째로 지우고 다시 채우는 방식, 오른쪽은 새 버전에 다 쓴 뒤 포인터만 바꾸는 방식.
| 문서 수 | 통째 교체 공백 | 깨진 조회 | 버전 교체 공백 | 게시 소요(통째/버전) |
|---|---|---|---|---|
| 15,000 | 76ms | 10.87% | 0ms | 0.094s / 0.067s |
| 60,000 | 331ms | 35.85% | 0ms | 0.347s / 0.19s |
| 240,000 | 1,372ms | 72.86% | 0ms | 1.425s / 0.67s |
그냥 진행 — 3개 주기 동안 최대 6.0시간 낡은 데이터를 제공했고, 그 사실을 알리는 신호는 없었다
기록하고 표시 — 같은 상황에서 2번 경보가 발생했고, 응답에는 매번 기준 시각이 붙었다
403 재시도: 없음 — 데이터 제공처 정책(non-200 시 즉시 중단)을 코드가 강제한다
전체 16,564개를 7일치 1시간 간격으로 전파: 0.712초 (상태벡터 2,799,316개, 초당 3,933,677회). 샘플 간격을 1분으로 줄이면 42.4초 · 저장 시 7.5GB. 측정 환경: Python 3.12.12 · C++ 가속 True · arm64
| 수집 시각(UTC) | 상태 | HTTP | 객체 수 | 소요(s) | 예약 대비 지연(s) |
|---|---|---|---|---|---|
| 2026-09-13T08:21:22Z | ok | 200 | 16563 | 3.739 | 262 |
| 2026-09-13T02:52:02Z | skipped | – | – | – | – |
| 2026-09-13T02:38:40Z | skipped | – | – | – | – |
| 2026-09-13T02:29:09Z | ok | 200 | 16564 | 2.348 | – |
이 페이지는 무엇인가 — 시간 기반 일괄 처리와 데이터 기반 증분 처리의 차이를 공개 데이터로 직접 재보기 위한 실험입니다. 정밀 충돌분석이 아니며, 스크리닝은 계산 부하를 보기 위한 단순화 버전입니다.
한계 — ① EPOCH는 발행 시각이 아니라 궤도 상태의 기준 시각입니다.
② CelesTrak은 2시간마다 갱신되며, 다른 데이터 제공처와 갱신 주기가 다릅니다.
③ 원본 스냅샷은 레포에 보관하지 않습니다(용량). 재현은 collect/fetch_gp.py로 가능합니다.
데이터 이용 정책 — CelesTrak 정책에 따라 갱신 주기(2시간)당 1회만 요청하고, 200이 아닌 응답을 받으면 재시도하지 않고 직전 스냅샷으로 대체합니다.