기존에 Bundle의 정의는 "벌크로 수집된 데이터들"이였다. 예를 들어 "설치된 앱 리스트"라는 데이터 종류가 있다고 했을 때, 데이터를 유저 5000명씩 한번에 Ingestion 하면 번들 1,2,3...이 되고 데이터를 시간 단위로 올리면 시간 단위로 번들 1, 2, 3...이 생김. 이때의 번들 ID는 그냥 단순히 Ingestion 순서 (AUTOINCREMENT 인덱스)이다.
문제는 이러한 방식은 번들링을 통한 이점이 없고 데이터 관리가 매우 Sparse해진다는 단점이 있다. 물론 한번 블록체인에 ingestion한 데이터는 불변하다는 장점은 있지만...
그래서 목표는 데이터 수집 시간을 기준으로 번들을 날짜 단위로 파티셔닝하는 것이다. Bundle ID를 날짜와 시간 기준 (e.g. 2006-01-02/23)으로 잡고, Ingestion되는 데이터들을 데이터 수집 시간에 따라 각각의 번들로 파티셔닝해서 올린다. 예를 들어 2월 13일 하루동안 수집한 5000명의 데이터를 Ingestion한다면 기존에는 5000짜리 번들 하나가 튀어나왔지만, 이제는 시간별로 파티셔닝된 24개의 번들이 나와야 함.
고민사항은 MUD의 Merkle Root 업데이트가 필요하다는 것이다. 왜냐면 수집시간 기준으로 하면 예전 데이터도 뒤늦게 들어올 수 있다는 건데 (e.g. 3일전 데이터가 오늘 뒤늦게 들어옴), 이미 그 시간에 해당하는 번들이 블록체인에 올라가 있다면 해당 번들 정보를 업데이트해야하기 때문이다.
Background
기존에 Bundle의 정의는 "벌크로 수집된 데이터들"이였다. 예를 들어 "설치된 앱 리스트"라는 데이터 종류가 있다고 했을 때, 데이터를 유저 5000명씩 한번에 Ingestion 하면 번들 1,2,3...이 되고 데이터를 시간 단위로 올리면 시간 단위로 번들 1, 2, 3...이 생김. 이때의 번들 ID는 그냥 단순히 Ingestion 순서 (
AUTOINCREMENT인덱스)이다.문제는 이러한 방식은 번들링을 통한 이점이 없고 데이터 관리가 매우 Sparse해진다는 단점이 있다. 물론 한번 블록체인에 ingestion한 데이터는 불변하다는 장점은 있지만...
그래서 목표는 데이터 수집 시간을 기준으로 번들을 날짜 단위로 파티셔닝하는 것이다. Bundle ID를 날짜와 시간 기준 (e.g.
2006-01-02/23)으로 잡고, Ingestion되는 데이터들을 데이터 수집 시간에 따라 각각의 번들로 파티셔닝해서 올린다. 예를 들어 2월 13일 하루동안 수집한 5000명의 데이터를 Ingestion한다면 기존에는 5000짜리 번들 하나가 튀어나왔지만, 이제는 시간별로 파티셔닝된 24개의 번들이 나와야 함.고민사항은 MUD의 Merkle Root 업데이트가 필요하다는 것이다. 왜냐면 수집시간 기준으로 하면 예전 데이터도 뒤늦게 들어올 수 있다는 건데 (e.g. 3일전 데이터가 오늘 뒤늦게 들어옴), 이미 그 시간에 해당하는 번들이 블록체인에 올라가 있다면 해당 번들 정보를 업데이트해야하기 때문이다.
TODO